👨🏼‍💻

立ち上げ初期のチームとモブプログラミング

2023/12/06に公開

はじめに

この記事は モニクル Advent Calendar 2023 の 6 日目の記事です。この記事では、立ち上げ初期のチームにモブプログラミングを取り入れてみたら、チームビルディングが促進されたり、チームの課題と感じていた属人化が防げるようになった話を紹介したいと思います。

対象読者

  • 立ち上げ初期のチーム[1]で、これからチームをよくしていきたいと考えてる人
  • 個人分担で開発が進み担当者の属人化が課題と感じてる人

モブプロとは

モブプログラミングとは、複数人で一つのコンピューターの前に集まって、みんなで協力しながら問題を解決していくことです。タイピスト(ドライバー)その他モブの2つの役割があり、タイピストはキーボードを操作しコードを書き、その他モブは問題を解決する方法を考えてタイピストに説明します。ロールをローテションしながら進めます。

モブプロ導入前のチームの課題

モブプロを導入する前は、以下のようなチームの課題がありました。

  • 分担作業でタスクを進めていたが、分担作業前後でメンバー間で分担した作業の同期がうまくできず、担当したメンバーに属人化され気味であった
  • 新しいメンバー構成のチームだったので、メンバー同士お互いのことをよく知らず、もっとコミュニケーションをとった方がいいなと思いつつコミュニケーションの取り方を模索してた

モブプロを導入

このような課題がある中で、モブプログラミングをするのはどうですか[2]、とアドバイスしてもらったことをきっかけにモブプログラミングを導入することにしました。実際にモブプロを導入する際には以下のことを整理しました。

  • 開発の進め方が変わるので PM などエンジニアメンバー以外のメンバーと調整
  • なぜモブプロを導入するのかチーム内で共通認識を持つ
  • モブプロをいつするのか決める
  • モブプロする対象を決める
  • モブプロの具体的なやり方を決める

導入当初は、毎日、全てのタスクを対象にモブプログラミングを開始しました。

モブプロの具体的なやり方

基本的な流れは以下の通りです。状況に応じてタイピストとモブの交換する時間を変えたり、誰も実装方法がわからない場合は一旦調べる時間をとり実装方針を決めてから開始するなど、適宜調整しながら進めました。

  1. モブプロで開発する内容を決め進め方を整理する
  2. タイピストをやる順番を決める
  3. 最初のタイピストの人が VSCode の LiveShare のリンクを発行・共有する
  4. モブプロ開始
  5. タイピストとモブを 20 分ずつで交換する
  6. モブの人は指示を出したり、調べたことをメモしたりする
  7. 一周まわったら休憩する
  8. 最後に今日できたことと振り返りをして終わり

モブプロを導入した結果

以下、モブプロを導入した結果良かったことです。

1. 属人化がなくなった

担当した特定のメンバーが詳しく知っていて、他のメンバーはよく知らないということがなくなりました。モブプログラミングをしていると、メンバー間で作業内容が常に同期されている状態なので、分担作業の場合と比べて作業前後で発生する同期のコミュニケーションが必要なくなります。元々のチームの課題として、この同期がうまくいかず属人化され気味ということがあったのですが、解消することができました。

2. コミュニケーション量が増えた

モブプログラミングを始めると、自然とコミュニケーションを取る時間が増えます。立ち上げたばかりのチームで、そもそもメンバー間のコミュニケーションが足りてない課題は自然と解消されました。設計の考え方やノウハウの共有、お互いにフィードバックしあう場面が増え、とても良い改善だったと感じています。属人化気味だった課題も根本はコミュニケーションが足りてないところにあったと思うので、自然とコミュニケーションが増えるモブプロはとても効果がありました。

モブプロをうまくすすめるために

モブプロはとてもいいプラックティスですが、実際にモブプロをはじめてみると、いろいろと進め方を見直した方がいいなと思う点が多かったです。スムーズに進めるために重要だと感じた点を紹介します。

1. 時間を区切って役割を交換することを忘れない

日常的にモブプロをやっていると、タイピストとその他モブのロールをローテションで回す際に、役割の交換を忘れてしまう場合がよくありました。一度交換し忘れると区切るタイミングを見失ったり、ずっと俺のターンみたいな状況になってしまいがちです。役割を交換するタイミングは、あらためて現状を整理するタイミングになったり、メリハリがついて作業のテンポがよくなったりするので、注意して進めていくことをおすすめします。

2. 長時間のモブプロは控える

通常のプログラミングだと何の制約もなく自由に書けることが、モブプロだと常にコミュニケーションをとり、共通認識を持ちながら作業を進めることになります。このような作業は単純にとても疲れます。そのため、長時間のモブプロはあまりおすすめしません。私たちのチームでは、始めた当初は全てのタスクを毎日モブプロで作業していましたが、途中からモブプロする作業と分担で作業するものをタスクの性質でわけ、長時間のモブプロを避けるように見直していきました。

3. モブプロで作業するタスクと分担で作業するタスクを分ける

体力に余裕があれば全てのタスクをモブプロで作業してもいいと思いますが、モブプロは疲れるので重要なものにリソースを使うようにしたいです。長時間のモブプロの話にも繋がりますが、ある程度は分担しないと体力が持たないし効率が悪いため、不確実性が高いものや設計、方針を決めながら一緒に作業した方が効率が良いものをモブプロで作業し、分担作業しても同期作業にコストがかからない、属人化されにくようなタスクは分担して作業する、といったルールで切り分けて作業するようにしました。

4. チーム内に知見がない場合の対策を考える

チームメンバーの誰にも知見がない場合、迷走しがちなので誰もわからない場合のアクションを決めておくことをおすすめします。例えば、ひとまず 30 分わからないことについて調べる時間を設けて、その後モブプロを再開するだったり、誰か詳しい人を呼んできて教えてもらうなどです。進行を妨げる要因を想定しておくで、スムーズにモブプロを進めることができるので事前に対策を用意しておくことをお勧めします。

5. 理解できるまで質問する

モブプロのは複数人で作業するので、タイピストと特定のその他モブ一人が理解して先に進んでしまうと、他のその他モブが理解できず置いてけぼりになる可能性があります。これはあまりよくない状態なので、自分が理解できてないと感じたら理解できるまで質問することをお勧めします。

おわりに

モブプロはとてもおすすめなプラックティスですがとても疲れます。疲れないように効率よくモブプロをするにはどうしたらいいか、そもそもモブプロ以外で冒頭に書いたチームの課題を解決する選択肢はあるのか、工夫や改善の余地は常にあると思うので、今後もチームでブラッシュアップしていい感じに開発を進めていけたらと思います。

明日は @colt45s さんです!よろしくお願いします!!!

参考

https://speakerdeck.com/bonotake/ge-ren-fen-dan-xing-gasutatoatupunocheng-chang-wosha-su-xie-dong-detimugametutiyajin-hua-suruhua?slide=14

https://speakerdeck.com/mtx2s/internal-quality-issues-caused-by-organizational-design?slide=83

https://speakerdeck.com/kawaguti/mob-programming-at-cedec-2018?slide=43

https://speakerdeck.com/masuyama13/pair-mob-programming-kaigi-on-rails-2023

https://engineering.mercari.com/blog/entry/20211130-52e6d96087/

https://kakehashi-dev.hatenablog.com/entry/2023/12/02/091000

脚注
  1. タックマンモデルのステージ 1 の形成期と呼ばれるようなチームのイメージです。 ↩︎

  2. このアドバイスは同僚の @k2 さんに教えてもらいました。ありがとうございます! ↩︎

GitHubで編集を提案
株式会社モニクル

Discussion