私達のチームでは数ヶ月前からモブプログラミング（以下モブプロ）を導入しました。導入した理由は、チーム内の知識の偏りという課題を解決するためです。
導入するにあたって、私達は「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」という本を参考にしました。この本は具体的なモブプロのやり方などについて詳しく説明されており、やったことがない人もどうやればいいかが分かるようになっています。
しかし、最初からスムーズに行ったわけではなく、毎回のセッションごとに振り返りを行い、改善をしてきました。この記事では導入後にどのような工夫をしてきたかを説明します。
モブプロの概要
モブプロについての説明記事はたくさんあるので、概要だけ説明します。
モブプロは、複数の開発者が一緒に同じ画面を見ながらアイディアを出し合って開発を行う開発手法です。
モブプロには、以下2つの役割があり、一定間隔で役割を交代しながら開発を進めます。
- タイピスト
- 実際にキーボードを使ってコードを入力する役割
- タイピストは他のメンバーの指示を受けてコードを書く
- タイピストは1人のみ
- モブ
- タイピストに対して、どのように進めるかを指示する役割
- 私達のチームでは通常2〜4人程度で、モブの間にはキーボードを操作しない
モブプロを導入した効果
私達のチームでは、モブプロを行うことで、以下のような効果を得られています。
1. 知識の共有とキャッチアップ
モブプロはメンバー間の知識差を埋めるのに効果的です。同じ画面を見ながら作業することで、知識の共有や疑問解消が同時に行うことができます。また、他のメンバーの実装方法を見ることで、コーディングスタイルや実装場所、ツールの便利な使い方などといった発見にも繋がります。
「知識差」は新メンバー限らず、異なる分野を担当しているメンバー間でも発生します。この差はその分野の共有会でも一定埋められますが、モブプロでは全員が手を動かすため、より効果的だと感じています。
これらの知識の共有を通じて、チームのボトルネック解消、開発スピードの向上、コードの可読性や保守性の改善が期待できます。
2. 課題解決の迅速化
モブプロには次のような考えがあります。
機能を安く作るのではなく、早く完成させることを目標としている。
モブプロは、実装着手からリリースまでのリードタイムを短縮します。特に、実装中に課題に直面したとき、モブの知識を集めることでより速く解決できるようになります。事前に開発方針が決まっていても、開発中に問題が見つかることも多々あり、その際、モブプロならリアルタイムで議論が可能で、方向転換や相談がスムーズに行えます。
ただし、短期的にはプロジェクト全体の進捗が早くなるわけではありません。1つのタスクに複数人の時間を投下するため、並行作業が減り、リードタイムが長くなる場合があります。
しかし、モブプロは知識の共有を通じてチーム全体の開発スピードを向上させ、ボトルネックを解消します。また、誰かが休んでも作業が止まることがないことで、結果的にリードタイムの低下を防ぐ効果もあります。
3. 課題解決の発見と品質向上
モブプロで議論しながら開発を進めると、潜在的な課題を発見し解決できることがあります。
1人で開発する場合、例えば本筋とは違う部分で違和感を見つけても目の前の課題を解決するためにそれを回避することもあります。私達はモブプロ中にこのような点を何度か見つけて、短時間で解決方法を見つけたということがありました。
全員で言語化しつつ進めることで、小さな違和感も見逃さず、原因特定につながります。その結果、1人での開発よりも創造的で高品質な開発が実現できます。
具体的にどうやっているか
定期的にモブプロに適したIssueを見つけたら開催しています。まずはフロントエンドエンジニアのチームで導入したので、フロントエンドエンジニア3、4人で開発を行うことが多いです。
最低2時間程度の時間を確保して以下のような流れで行います。（最長、1日で7時間モブプロを行ったこともあります）1つのIssueを複数回に分けて実施することもありますが、完了までできるように近くの日程をあらかじめ確保します。
- 最初の説明 15〜30分
- Issueの概要の説明
- 大まかな方針のみ決定
- モビングインターバル 1時間20分以上
- 10分程度の間隔でローテーションを行う
- レトロスペクティブ (KPT) 10分
- 毎回必須ではない
オンライン、オフラインともにどちらでも開催しています。どちらも各自の画面を共有しながら開発し、ローテーションします。
工夫してきたこと
ここからは各セッションごとに行ったKPTでTryとして改善してきたものです。一度できたものでも別のセッションで議論が白熱すると忘れてしまうので、お互いに意識し合うようにしています。
■ 議論と実装について
1. タイピストはモブに指示されてから実装をする
タイピストが勝手に実装やファイル移動を行うと、ついていけないメンバーが出ることがありました。特に詳しい人がタイピストのときには、勝手に進めないように注意が必要です。モブ側もタイピストが独断で進めないように、止めたり質問をしたりするように心がけています。
2. できる限りコードに書くこと
議論が白熱すると認識のズレや理解が追いつかないメンバーが出ることがあります。また、議論ばかりで実装が停滞してしまうこともありました。
そのため、まずは意見を元にとにかくコードを書き、それを見ながら改善していきます。議論が加熱した際は、周りのメンバーが冷静に指摘するようにしています。
3. 詳しい人「以外」の意見も取り入れる
詳しい一部の人に発言が固定され、その意見だけで進み、他のモブが発言しづらくなることがあります。本でも「モビングの価値は意見の多様性から生まれる」とありますが、発言が少ないメンバーに積極的に質問し、少数意見も取り入れるように配慮します。
議論をしている本人は無意識なことも多いので、他のモブが意識的に発言が少ない人に話を振るなどの工夫が必要です。
■ タスクのサイズと時間について
4. 連続して時間を取ること
できる限りモブプロ中に開発着手からマージまで完了するように、タスクを選び、時間を確保します。モブプロを行うことでレビューの負荷を下げる効果を得る目的もあります。
もし2回以上に分ける場合も翌日に行うなどのように間隔を空けすぎないように時間を確保します。
5. モブプロに適したIssueを選ぶ
モブプロの効果をより効率的に発揮するにはIssueの選択が重要です。
「誰がやっても同じ結果になる」Issueは適していません。たとえば似たコードがあり、それを変更するだけの単純な内容はモブプロをやっても持て余してしまいます。
逆に複雑で難易度の高いIssueはモブプロとして全員で取り組む価値がありますが、誰もその実装方法について詳しくないものになってしまうと、モブプロの効果が低くなってしまいます。
一方、チーム内に、特定の領域に詳しくないメンバーや新しいメンバーが「一部のみ」いる場合は知識差を埋める絶好の機会です。
それ以外にも、プロジェクト開始時に認識を揃えるといったモブプロも効果的です。
■ 進行方法の改善について
6. コーディングを行う環境
本にはオフラインがおすすめとあったので、オフラインからトライしましたが、今ではオンラインでやる方が多いです。また本には、1台のPCとキーボードを順番に交代で使う方法が書いてありました。
しかし、実際にこの方法で試したところ、エディタやキーボードの違いから開発効率がとても落ちることがわかりました。そのため、私達は各自のPCとエディタを用いて開発を行っています。オンラインではZoomの画面共有、オフラインではディスプレイの切り替えで交代します。
切り替え方法を工夫することで、1分のインターバルにおいても余裕をもって交代できるようになりました。
7. タイピストのスムーズな交代
上記のように、ローテーションのタイミングには、実装内容を共有する必要があるので、即座に手を止めてcommit, pushして交代します。
本にも、この交代をスムーズにする重要性が書かれていたので、できるだけすぐに交代できる工夫をしています。具体的には、モブプロが始まる前にブランチをpullしておいて、storybookやtestですぐに動作チェックできる準備を整えています。
8. Issueの内容に詳しくない人から優先してタイピストを行う
タイピストとして自分で手を動かすと理解が深まりやすいです。そのため、詳しくないと思う人から率先して最初にタイピストを経験するようにローテーションを組んでいます。
できる限り速く全員の理解度を高められることで活発な議論を行うことができます。
9. ｢タイムボックス付きの探求｣の活用
コードを書きたいけど誰もいい実装方法を誰も思いつかずに手が止まってしまったり、手元でデバッグをしたいときには、｢タイムボックス付きの探求｣を利用します。
これは本で紹介されていた手法ですが、一定の時間、探求内容を決めて個別で調査を行い、時間が終わった後に共有をします。これにより短時間で深く議論を行い、その後の方法決定ができます。
まとめ
モブプロを成功させるにはとてもたくさんの要素が絡み合っていますが、特にコミュニケーションがとても重要です。活発な議論ができるように工夫をし続けることが大事です。
これらは今まで改善してきたことですが、モブプロに集中してしまうと自分でも気付かないうちにこれらの点を破ってしまうこともまだまだ多々あります。なんども繰り返して自然にこれらのことができるように改善を続けていきたいと考えています。