他のプラクティスと同じくモブプログラミングに関しても、たった1つの正しいやり方というものはないと思います。

チームの状況や目的により、やり方は変わってくるでしょう。

とはいえ、非常に重要なポイントというものも存在し、もしそれを破るなら、それ相応の理由が必要というものもあるかと思います。

今日は、1か月以上フルにモブプログラミングをしてみて、今、私が最も重要だと思っているモブプログラミングのやり方に関することを書きたいと思います。

ドライバーをタイピストにする

通常、モブプログラミングでもキーボードを持つ人は「ドライバー」と呼ばれます。

ドライバーは運転手で、これは車の運転のメタファーです。通常は、ドライバーは自分の行きたい場所に自分で運転して行くことができます。

プログラミングでも同じく、ドライバーは自分の考えたコードを自由に入力できます。

このようなモブプログラミングのスタイルもありえるとは思いますが、もっとよい方法があります。

それが、ドライバーをタイピストにする方法です。

タイピストは考えない

タイピストの役割はタイプするだけです。原稿は別の人が考えます。

モブプログラミングでは、ナビゲーターがどう実装するかを考えます。タイピストはナビゲーターの指示をコードに翻訳します。自分で勝手に考えてコードを書き進めてはいけません。

タイピストは、ナビゲーターの指示が理解できればコードをタイプします。理解できなければ、コードが入力できるようになるまで質問します。

ナビゲーターが考え指示する

ナビゲーターがどう指示するかは、タイピストの理解できるレベル（スキル）によりますが、タイピストが理解できる最も高い抽象度で指示を与えることが理想です。

高い抽象度の指示が理解できなければ、より抽象度を下げて指示をします。

タイピストのスキルが低ければ、最終的に、

「x行目の上に何々を入力して…」 「y行目をコピーして、z行目の上にペーストして…」 「どこどこを選択して、ctlキーとcキーを同時に押して…」

のような指示になるかも知れません。

何がいいのか？

この方法だと、あるアイデアがコードになるために、必ず、他人を通す必要があります。ナビゲーターがタイピストに言葉や図などで実装方法を説明しなければなりません。

タイピストを含む他のメンバーは必ず、その説明を聞くことになります。

チーム全員のコードや設計についての理解度が向上し、レビューの質も高まります。

ドライバーが勝手にコードを書いて、他のメンバーは見ているだけ。さらに見ているだけで実はよく理解できていなかったというが、モブプログラミングでのアンチパターンです。

そのようなアンチパターンを自動的に防いでくれるのがこのスタイルです。

また、タイピストはキーボードが打てさえすれば誰でもできます。例えば、使っている言語をよく知らない人でもタイピストをすることは可能です。

コードが実装された後

タイピストは基本的にナビゲーターの指示をコードにするだけですが、一区切りのコードが実装された後になっても、そのコードが理解できない場合は、ナビゲーターに質問する必要があります。

タイピストもモブの一部です。役割を交代すればナビゲーターになります。よく理解できずに言われたままにタイプすることもあるでしょうが、それは好ましいことではありません。

まして、コードが完成した後も理解できないままなら、モブプログラミングの意義は相当薄れます。そのような状態は放置すべきではありません。

タイピストだけど実装したいアイデアがある

タイピストは勝手にコードを実装してはいけません。もし、こう実装すべきだというアイデアがある場合は、次の人に交代し自分はナビゲーターになります。

まとめ

• ナビゲーターはどう実装するかをタイピストに指示する
• タイピストは考えない
• タイピストは指示をコードに翻訳する