スクラムチームにモブプロを導入してみた
エンジニアチームの和山です。
私たちのチームでは、開発にモブプログラミング（以降モブプロ）を導入しています。
※モブプロについては、以下の資料で詳しく説明しておりますので、詳しい説明は割愛いたします。
今回は、なぜモブプロを導入しようとしたか、導入してどんな効果があったかを皆さんに共有したいと思います。
導入してみようかなと思っている方がいればぜひ参考にしてください！
導入経緯
年明け頃、開発メンバー3人+PO+マネージャー（兼スクラムマスター）の5人で新チームを発足して開発することになりました。
私がそれまで所属していたチームではスクラムを採用していて、タスクの進め方は、個人がタスクを選択・実施し、それを他の人がチェックするという方式でした。
新しいチームでも、スクラムは継続したいと考えましたが、タスクの進め方について、次の3点に課題を感じていました。
課題1: チェック工程がボトルネックになる
チェック方式の場合、基本的に手が空いた人がチェックしますが、スプリントに余裕が無かったり、タスクのチェック量が多いとチェック終了までに時間がかかってしまいます。
チェックが行われないと次のタスクに進めない状態のため、ボトルネックになる可能性もあります。
課題2: 属人化が進む
タスクは簡単なものもあれば、特定の知識・技術がないと時間がかかるものもあります。
スプリント内に終わらせようとするとタスクに関連する知識に長けている人が担当しがちです。
この状況が続くと、元々スキルや経験がある人がそのタスクを主として担当することが増えます。
その結果、その人しか担当できない領域が増え、属人化が進むことに繋がります。
タスクを任された当人も、他の人に任せたいケースもあり、そういった状況が続くとモチベーション低下につながる可能性があります。
課題3: 知見・技術共有が気軽に行えない
同じスキルをもっていても開発速度が速い人と遅い人がいます。
これには次のような違いがあると考えます。
単にタイピング速度が早い
ターミナル環境をカスタマイズし、快適な開発環境を整えている
VisualStudioCodeやVimなどのエディタに関わるショートカットキー・拡張機能を使いこなしている
エラー時の対応が早い
本人からしたら当たり前のことと感じているかもしれません。しかし、他人から見たらその知見は実はとても有用である可能性があります。
これらは技術を共有する時間をとってもあまり共有されることはない（本人が共有するほどでもないと思っている）埋もれた知見になりがちです。とても勿体ないと感じます。
導入方法
先ほど挙げた課題をモブプロで解決できると考え、チームでモブプロを導入することにしました。
導入するにあたり、私たちは次の2点を実施してからモブプロを始めました。
手順1: 開発メンバー全員と合意を取る
モブプロで開発を進めても問題ないか改めて開発メンバー全員で合意を取ります。 導入経緯であげた課題をあげつつ、同時にTryであることも共有します。
モブプロは私たちの発意からでてきたTryであり、上司から言われて始めることではありません。モブプロをやってみてメンバーの誰かが合わないと感じたり、デメリットが大きいと思えばいつでも止めていいことにしました。
手順2: モブプロの概要を理解する
私たちは今までモブプロに取り組んだことがありませんでした。
開始するにあたり概要を掴めそうなスライドを見たり、本を読んだりしてモブプロの進め方を把握することにしました。
使用したスライドはこちらになります。
スライドを作成された及部さんが解説として書かれている書籍も購入して読みました。
私を含めた開発メンバーの2人でTDDワイワイ会®様が実施している、「TDD＋モブプログラミングでワイワイする会」にも参加して実際にモブプロを体験しました。
導入効果
モブプロを導入してどのような変化が起きたのか。
導入して感じられたメリットとデメリットをそれぞれ3つ挙げます。
メリット1: チェック工程が作業中に行われる
私たちのチームでは、ひとつのストーリーに対する開発・調査・議論など、あらゆるタスクに対してすべてモブで取り組みました。
結果、課題となっていたタスクのチェック工程を不要としました。
全員でタスクに取り組んでいるため、その場でコードレビューや問題共有をすることになるからです。
これはフロー効率が良い状態といえます。
メリット2: 技術共有がしやすくなった
個人が保有していた知見を共有しやすくなりました。
例: VisualStudioCodeのショートカット、有用な拡張機能、使ったことのないライブラリの紹介等…
画面共有しながら作業を行うため、誰がどんな風にコーディングしているかが分かります。
また、ライブラリやツールの導入に関しても、会話しながら作業をするため気軽に相談できる状態となっています。
何気ない会話から知見を共有しやすい環境になり、知見の属人化という課題をクリアできていると感じました。
メリット3: 成果物に対して全員が責任を持つようになった
スプリントで達成される成果物に対して開発メンバー全員が責任を持つようになりました。
個人で進めている時は「その件は、◯◯さんが知っています」という会話がたまにあり、チーム内でプロダクトに対する知見の差が生まれていました。
モブプロにすることで、全員がその成果物に関わっている状態となるため、開発メンバーの誰が質問されても答えられる状態になりました。
他人事にせず、主体的に良いプロダクトにするためにどうすればよいか、保守性・拡張性が保たれた設計をどうすればよいか考え、実践することができるようになりました。
デメリット1: 発言力が大きい人に意見が集約されがち
タイピストはナビゲーターが指示した通りに実装します。
人数によってはナビゲーターが複数人いる場合があります。
複数人だと、どうしても発言力がある人（意見をすぐ伝えられる人）の声が大きくなりがちです。
ここは対策する必要があります。
私たちはタイピスト・ナビゲーターの他にモブのロールを新設し、ナビゲーターは原則一人にしました。モブはナビゲーターから相談を受けるまで見守ることにして、全員がナビゲーターとして発言する機会を設けることにしました。
デメリット2: 短期的効率の悪さを感じる
モブプロで進めていると「ここ一人だったらすぐ実装できるなあ…」と思う瞬間があります。
モブプロはフロー効率は良いですが、リソース効率は良くありません。
特に手をたくさん動かしたい人にとって効率が悪いと感じるときが多いと思います。
この問題の解決は難しいですが、一日のうち、モブプロをする時間と個人で進める時間を分けるといった対策が挙げられます。
私たちのチームでは、一人でやっても問題なさそうなタスクがあれば、それをタスク化させ、モブのロール中に取り組むようにして手を動かす機会を増やすようにしています。
デメリット3: 個人作業の時間を作るのが大変
私たちのチームは全タスクをモブプロで取り組んでいます。そうなると、個人が受け持っているタスクを進める時間の確保が大変だと感じました。（例：ブログ執筆作業）
この対策は、下記で挙げる施策を試しながら、チームの状況に合った方法を模索中です。
Planning時に個人タスクを進める時間を確保する
デイリー時に個人タスクを進めてよいかチームに合意を取る
毎日特定の時間を個人タスクを進める時間として固定化させる
導入するにあたっての注意点
私たちのチームでは導入してとてもメリットが大きいと感じられました。
この記事を読み、導入しようと思った方がいれば、次のポイントを抑えて始めることをオススメします。
有志のメンバーで実施する
少人数(3~5人くらい)
2ローテーション以内で完了できるタスク
参加者のうち、一人以上が確実にナビゲートできるタスク（初領域だと調査時間が増え、モブプロの魅力が分からず終わる可能性がある）
タイピスト交代の時間を厳守する（10~15分で交代とする）
振り返りをする（良かった点・課題点・課題に対する対策をそれぞれ3分程度で出してもらう）
まとめ
今回はモブプロを導入した経緯と効果を整理してみました。
最後に本記事のまとめを整理します。
タスクチェックのボトルネックを解消できる
個人が持っていた知見を共有することができ、チーム全員の開発スキル向上につながる
成果物に対して全員で責任を持ち、全員が主体的にプロダクトを良くする方法を考えることができる
フロー効率の良さ・リソース効率の悪さを考え、最初は1~2時間程度で終わる小さなタスクに対して導入するのがオススメ
私たちのチームではこれからもモブプロを取り組み続けながら、変化に強いチーム作りをしていきたいと思います！
最後に、noteの更新情報やスペクティの最新情報は公式Xにて発信しています。ぜひフォローをお願いします！
次回もお楽しみに！