こんにちは！！ freeeのあるプロジェクトの開発リーダーをしているMです。

チームメンバーに異動があったり、メンバー間のプロジェクトに関するナレッジやプログラミングスキルにむらがあったために、プロジェクトの進捗が遅れ気味で困っていました。メンバー個別では開発が進まず、メンバーのナレッジとスキルが合わさって初めて進められる状況で、どうしたらいいか頭を抱えていたときにメンバーの一人がモブプログラミングを紹介してくれました。Kさんに感謝！

先にやってみた結果を紹介すると、モブプログラミングによって次のような恩恵を受けることができました。

メンバーの長所が相乗効果で発揮された。
仕様についての知識がメンバーごとに断片化されていたが、全員でコミュニケーションしながら作ることで理解が進み結果として開発がとても早く進んだ。
ハマって一人で頭を抱える時間が無くなった。
超長いパラメータを間違いなく入力しないといけないときに、次のパラメータを読み上げる人、パラメータの間違いが無いかチェックする人、パラメータを入力する人で分担作業ができたのは感動。一人でやってたらめげてた。
ストレスフリーのプログラミング。早い！！楽しい！!美しい(コードが)！!

モブプログラミングとは

モブとは以下のようなグループの事を言います。

A small group of developers working together in real time on one task, on one computer.
リアルタイムで一つのタスクをみんなで一緒に一つのコンピュータ上で行う小さなデベロッパーのグループ

モブプログラミングは、二人で開発を行うペアプログラミングにルーツがあります。モブで開発することで、それぞれのメンバーの専門性を合わせることで集合知を発揮することができます。

モブプログラミングでは、モブに２つの役割があります。ナビゲーターとドライバーです。

ナビゲーター

モブとコミュニケーションを取りながら、ドライバーにどのようなコードを書くか指示する役割です。ドライバー以外の全てのメンバーがナビゲーターです。

ドライバー

キーボードを叩いてコードを書くただ一人の人です。ドライバーは、ナビゲーターからの指示を理解して、コードを書く責任があります。指示が曖昧だったり、分からなかった場合はナビゲーターに質問して理解をしながらコードを書きます。

ドライバーは交代制で、ローテーションを組んで7分から10分間隔で交代することがベストプラクティスになっています。

従来の開発における問題点

従来の開発では、例えば開発者が5人だとすると、5人がバラバラに別のタスクを行います。このとき、単純に人数倍スループットが上がるかというと、そんなことはなく、「調査」、「情報収集」、「合意形成」、「コードレビュー」などがボトルネックとなって、スループットは大きくは上がりません。特にコミュニケーションの回答待ちのキューがスループットを大きく阻害してしまいます。また、コードレビューと開発が分離しているため、レビューでNGとなると手戻りが発生することになります。せっかく書いたコードを削除して、書き直す作業は非常にロスが多いと言えます。

モブプログラミングの肝はコミュニケーションにあり

モブプログラミングの肝はコミュニケーションにあります。モブプログラミングではナビゲーターとドライバーが明確に分けられているところが実は優れた仕組みです。

ナビゲーターとドライバーが分けられているため必然的に、ドライバーが何をすればいいかナビゲーターからの指示を理解しなければなりません。

ナビゲーターはドライバーが理解できるように明確な指示を出す必要があり、理解とモブ全体の合意がリアルタイムで行われることになるのです。

また、メンバーの意見を聞いたりコードをみることで、自分の専門外を含む学習が行われます。学習効果はプロジェクトが進むに従ってレバレッジとなり大きな効果が期待できます。

モブプログラミングによって、下記のことが実現します。

継続的学習
リアルタイムレビュー
メンバーのそれぞれの弱みを明らかにし、それを克服できる
モブからの素早いフィードバック
継続的なコーディング作業
ハードスキルとソフトスキル※の成長

※ ハードスキルとはツールや技術や専門知識など、習得してできるようになったことや使えるようになったもののことを指します。ソフトスキルとは効果的なコミュニケーション能力や信頼性の高さ、寛容さなど、時間をかけて身に着けた対人関係の特性。

モブプログラミングはTOC(Theory of Constraints)の教科書のような、パフォーマンス改善ソリューション

TOC(Theory of Constraints)というシステムのスループット改善手法があります。システムのスループットはボトルネックによって制約されるという理論で、いまは亡きエリヤフ・ゴールドラット博士が提唱したサプライチェーンマネジメントの基礎理論です。 TOCでは、次のようなステップでシステムを改善します。

システムの制約を特定する。
多額の投資を行うことなく制約を取り除ける場合には、直ちにそれを行い、ステップ1に戻る。できない場合には、システムの制約を活用する方法を編み出す(ゴールドラットのステップ2:システムの制約を活用する方法を決める)
他の全ての事柄を上記の決定に従属させる。
制約の一つ、あるいはいくつかの制約の能力(キャパシティとケイパビリティ)を高める代替案を見積もる。最初の3ステップの理論的活用が今後の制約、及び全体のパフォーマンスに与える影響を予測する(ゴールドラットのステップ4:システムの制約を高める)
ステップ1に戻る。現在の制約は当初に予測したものとは異なっているかもしれない。制約の特定においては、惰性に注意する。

(ケースで学ぶTOC思考プロセスエリ・シュラーゲンハイム著より)

このTOCの視点で、モブプログラミングを眺めると、モブプログラミングが非常に理にかなっていて、TOCの教科書通りにスループットを改善した結果であることがわかります。

従来の開発におけるボトルネックの原因はコミュニケーションの回答待ちキューでした。これはモブプログラミングでエンジニア全員がリアルタイムでコミュニケーションを取るようにすることで解消されます。すると、ボトルネックはコミュニケーションの回答待ちキューからドライバーの理解と入力スピードに移ります。ボトルネックがドライバーに移ることで、ナビゲーターには余裕が生まれ、ナビゲーターは思考とコミュニケーションに集中できます。システムではボトルネックはフル稼働になりますが、他の部分は遊び時間の余裕ができます。この時間がより深い洞察にとても重要な影響を与えるのです。

今は、ドライバーの入力スピードのボトルネックはGitHub CopilotなどのAIを利用することでかなり高速にすることができます。GitHub Copilot等のAIソリューションを利用することで、更にスループットを向上させることができます。

開発リーダーは、TOCの視点を持つことで、モブのパフォーマンスを改善、維持することができます。

現在直面している課題やモブプログラミングのゴールによっては、ドライバーではなくナビゲーターがボトルネックになってしまうことが有りえます。その場合、チームが直面しそうな課題を事前に察知して、適切な人材をモブに投入すれば、ボトルネックを解消することができます。

また、モブのコミュニケーションを観察することで、ファシリテーションの介入をすることができます。従来の開発ではできなかったことです。

モブのメンバー構成を調整することはチーム間のメンバーの流動性が十分確保されている必要があり、ピラミッド型の組織では困難でしょう。

ボトルネックの特定には、5で指摘されているように惰性に注意する必要があります。モブの中にはいって、モブをよく観察することで、本当のボトルネックを見つけていく必要があります。リーダーだけでなくモブ全員がこのような視点を持つことができればより効果が期待できます。

体験談

メンバー構成

M(私) チームリーダーは初めて。開発対象のプラットフォームはさわったことがある。開発言語の経験あり。全体は把握しているが、Tさんほど仕様の細部に明るくない。

Kさん開発経験豊富で、優秀なプログラマー。開発対象のプラットフォームに関する知識はなし。開発言語の経験あり。

Tさん別プラットフォームでプロトタイプを作成しているので、仕様に明るいが開発言語の経験なし。オンラインで参加。

プロジェクト半ばでメンバー構成が変わったため、メンバーそれぞれが持っている情報が、統合されない状態で開発がスタートしていました。また、メンバーのスキルレベルもわかっておらず、どのようなサポートをすればいいのかも当初わかりませんでした。

開発が始まったものの、なんだか進まないなぁ。なんでだろう、まぁなんとかなるだろうと思っていました。

githubのリポジトリができて、ディレクトリ構成を整えて、コードを共有できる状態になった時点で、まだ何もコードが書けていないことが判明しました。

このままいくとプロジェクトが終わらないことがわかったので、急遽ペアプロならぬトリプロで開発を行えば開発スピードが上がるのではと提案したところ、Kさんからモブプロというものがあると情報をいただき、すぐにモブプロについて調査することにしました。その日のうちにメンバーの予定を調整し、翌日にモブプロの時間を3時間確保してスタートしました。

開発に使ったツール

オンライン参加のメンバーがいたので、Visual Studio CodeとMicrosoft公式のLive Shareプラグインを利用しました。 1回目、2回目は全員オンラインで行いましたが、3回目は2人はオフラインで開発を行いました。その時も、Live Shareプラグインを利用しました。

感想

ナレッジの共有は驚きの効果。それまで停滞していたことが一気に片付きました。また、メンバーの意見を聞きながら方針を決定できるので、でてきた意見をもとにベターな決断が素早くできます。リアルタイムで全員の合意を伴う意思決定ができることの効果は絶大です。

一人ではハマってしまって、数日失ってしまうような可能性がある問題も、知恵を合わせることで即解決したのには感動しました。

オンラインでもオフラインでも、モブプログラミングの効果は十分感じられますが、オフラインのほうが、発言にネットワークの遅延がない分コミュニケーションがスムーズで良いです。オフラインで集まれることはベストですが、マストではありません。オンラインの場合は、マルチディスプレイは必須です。

大量の設定項目をヌケモレなくコーディングしないといけないときは、設定項目を読み上げる人、設定項目をチェックするひと、コーディングするひとに役割分担ができたことはとてもよかったです。一人で作業していたら、ドキュメントとコードを行ったり来たりしながらチェックする必要があり、それだけでめげてしまったでしょうし、一発でテストがグリーンになることもなかったでしょう。

これまで、モブプログラミングをする前は、確かに疑問点を誰に聞いたらよいのか分からず、とりあえず知っていそうな人に聞いて、回答を待つことが多かったです。そういったことが起こらず、作業に集中できることはとても楽しいことです。

課題

3人のチームでは、プロジェクトに関する知識や開発言語に関する知識にばらつきがあると、ローテーションがうまく回らないことがあり、人によってはナビゲーター中心でやってもらったほうがうまくいく場合がありました。おそらく、もう少し人数が多ければ、ローテーションがうまく機能していたと思います。

メンバーの感想

K『ペアプロ・モブプロは行うメンバーでどうしても成果にバラツキが出てしまうと思っています。今回の3人での作業は非常に効果的で提案してよかったと安心しました。別の機会にも活かしていきたいです。』

T 『モブプロを行うことで、段階的ではなく、同時進行的にすべてか解決していき、その効率に感動しました。』

まとめ

従来のプログラミング手法のボトルネックは、コミュニケーションの回答待ちキューにありました。
リアルタイムのフィードバック・ナレッジ共有と意思決定・合意形成ができることは開発のボトルネックを「調査」、「情報収集」、「合意形成」、「コードレビュー」からキー入力に移します。ボトルネックであることから開放されたナビゲーターはより深い洞察にリソースを使うことができます。
ドライバーのスループットをあげるにはgithub copilotはとても役に立ちます。