モブワークでチームの仕事の質を上げる

こんにちは Graatアサキです。今回は、私のユニットで取り組んでいる 「モブワーク」 を紹介します。

GxPで開発に携わっている方にとっては、「ペアプログラミング」（ペアプロ）は馴染みのあるプラクティスではないでしょうか？
ペアプロは2名で実施しますが、これをもっと多くの人数（通常は4~5名）で行うことを 「モブプログラミング」（モブプロ）と言います。
私たちTSU（Team Solution Unit）は、システム開発を行うチームではなく、コードを書くこともないので、私たちが実施しているのは、「モブプロ」というよりはむしろ「モブワーク」ということになります。

モブワークで何を作るか、なぜ作るか

私たちがモブワークで作成するのは、いわゆる「プレゼン資料」です。
その中身は、コンサルティングやコーチングサービスの提案であったり、 マネジメント層向けの支援報告であったり、ワークショップやセミナーの教材であったりと、様々です。

こうした文書の特徴として、書き方の自由度が極端に高い点が挙げられます。
（システム開発の仕事に携わっている方は「要求仕様書」などの上流工程の文書に置き換えて考えると、わかりやすいと思います）

自由度の高さゆえに、書く人によって品質がばらつく、所要時間もまちまち、という課題を抱えていました。
この課題への対処として、モブワークを導入してみた、というわけです。

モブワークの進め方、２つのパターン

私たちのチームのモブワークには、今のところ２つのやり方があります。

パターン１は、いわば「教科書通り」の進め方です。
しかし、実際にモブワークをやってみた実感としては、パターン１がうまく機能しないケースがあります。

それは、取り組む問題に対する習熟度に大きなバラツキがある場合です。
ナビゲーターの指示をドライバーが十分に咀嚼できず、言われた文言をそのままタイプするような状況に陥りがちです。
こうなっては、学習効果を得ることが難しくなります。

そこで、パターン２のやり方を試してみたところ、非常に難易度の高い問題、たとえば新規顧客向けの提案書作成などには、こちらの方が適していそうと思えました。

アンチパターンに陥らない工夫

ここで、「パターン２って、ダメなやつでは？」と思った方がいたら、鋭いです！
先に挙げた『モブプログラミング・ベストプラクティス』でも、「これはやっちゃダメ」と言われている進め方に近いのが、パターン２です。

エキスパートをタイピストに据えると、問題は瞬時に解決され、ほかのメンバーはただそれを見てうなずくだけになってしまう。

『モブプラグラミング・ベストプラクティス』 （ マーク・パール著 、長尾高弘 訳 、日経BP社、2019年） より引用

この問題を避けるために、私たちが取った対処が「ドライバー兼ナビゲーター」です。

最も習熟度の高いメンバーは、自分の思考の過程を口に出して説明しながら、実際に文書を作って行きます。

• 「このページで伝えたいことを一言で言うと、こう。だからそれを３つの文章で展開する」
• 「顧客企業の市場ポジションや、カウンターパートとなる担当者の部署・役職を考えると、この言い回しが良い」
• 「このページのこの箇所は3ページ後のここで回収するための伏線」
  等々…

実際にやってみると、聞く側にとっての学習効果はもちろん、話す側にとっても、頭の整理になり、作業効率が上がります。
また、メンバーからの質問や提案をきっかけに、自分では思いつかないアイディアが生まれることも少なくありません。

レッツモビング！

「良い文書を作る」という、抽象的で言語化しにくいスキルを、効率よく伝える方法としては、私の知る限り、モブワークはかなり優れています。

そればかりか、チームの仕事のパフォーマンスも向上すると実感しています。

• 誰かが文書を作る
• それをレビューしてコメントを返す
• レビュー結果反映して修正
• それをまたレビュー

という過程が省略できるのは、時間の節約以上に、ストレスフリーで文書ができるという大きなメリットを生みます。

一緒に文書を作っていますから、プレゼン本番前に読み合わせをして認識を揃える、という手間も要らなくなります。
（このあたりは、モブプロでコードレビューが要らなくなっていく、開発チームの成長過程と通じるものがあります）

皆さんのチームでも、試してみてはいかがでしょうか。