はじめに
tanukitiです。
社内で定期的に行われている研究発表会にて、モブプログラミングの話をしました。
私が現在携わっている案件では頻繁にモブプログラミングが行われている一方、社内の別プロジェクトではモブプログラミングに取り組んでみたいが、どう取り組んでよいか悩んでいる。という声を聞き、今回の発表に至りました。
テーマとしては、「モブプロに少しでもポジティブなチームの背中をそっと押す」ことですので、もし今回の発表の発端のように、モブプロやってみたいけどなかなか実施できない、一度試してみたけど、うまく行かなかった、というチームにとって有意義な情報となると嬉しいです！
発表資料は本記事の一番下においておきます。
この記事では発表資料についてご紹介したり、今回の発表を機にいただいた質問やフィードバックについてご紹介していこうと思います。
モブプログラミングと効率の考え方
モブプログラミングを始めようかどうか、やってみたけど効果がいまいち感じられなかった。という背景には、思っていたより効率が上がらなそう、または上がらなかった、というところがよく話題になるのではないかと思っています。
この感覚はある種納得できるものであり、ある種弁明の余地があります。
フロー効率とリソース効率
発表中、私の方では下記の定義を行いました。
- フロー効率: 仕事の流れを最大限に良くする
- リソース効率: リソースを最大限に利用する
モブプログラミングにおいては、相対的にリソース効率は落ちるもののフロー効率を上げるような開発手法であり、もし「モブプログラミングが効率的だったか？」を評価するのであれば、フロー効率の方に着目していただきたいです。
プロジェクトやチームにより、一つ一つのフィーチャーが、速く、品質高く、市場に届けられるか、が大きな指標であり、個々のメンバーがどう振る舞ったか、というところを追い求めすぎないことが重要だと考えています。（組織やチームとしてどう動けたかが重要）
モブプログラミングによる恩恵
一見して同期での作業時間が増え、非効率に見えるモブプログラミングですが、恩恵もあります。
- モブプログラミングにより書いたコードはレビュー不要！
- どういう意図で書かれたコードなのかはモブにて会話できる。気になる点もモブの最中に解消可能
- デイリーでの進捗確認が短くなる！
- 一緒に作業を進めていれば、今の作業状態は同期不要になり、デイリーが短くなる効果も
- チームで実装したドメイン周辺の知識はそのままチームのものに！
- 誰かにドメイン知識が偏ったりせず、追加機能開発や障害発生時にも属人性低く課題に対処できます
- もちろんチームメンバーのスキルアップにも！
こういった恩恵もあり、モブプログラミングとしての同期時間は増えるものの実は他のシーンで同期時間が減るということも考えられ、長期で見ると時間効率的にもよくなることも考えられます。
モブプログラミングのはじめ方
上記で恩恵の話もしてきましたが、それでもやはり取っ掛かりにくい部分があるかもしれません。モブプロを導入する前に、自分やチームにその開発手法がぴったりかはなかなか分からないものです。
なので、あまり気構えず実験的に始めてみることをオススメします。
良さそうなら続けていくと良いですし、やっぱり合わなそうだな。という場合には辞めるといいというスタンスで臨むことで、始めることへの心理負荷はだいぶ下がるかと思います。
また、実験的に始める際にオススメなのは以下のポイントです
- 参加するメンバーは、参加したい人だけで構成し、3〜5人程度
- 1,2 回の実施ではなく、数週間はやってみる
- １回のモブごとに、振り返りをし、チームに合うやり方に調整していく
具体的なモブの流れ
下記に示すのは、モブプログラミングにおける流れの一例です。
- モブプログラミングで取り組む内容を参加者たちで決定する
- タイピスト（ドライバー）を決める
- タイピストは10分ごとに交代する
- 1時間〜1時間半くらいで休憩を挟む
- トータルでも3時間程度でモブプログラミングを終え、振り返りをする
タイピストの役割
実際にキーボードを操作し、コードを書く人をタイピストと読んでいます。（参考書籍より）
タイピストは、参加者であるその他のモブが行ったことを理解し、実際にコードを書く人です。
実際にタイピストを担当すると、なにかコードを書かなきゃ！スキルが低いと思われたくない！という強迫観念から、コーディングをゴリゴリと進めたくなりがちですが、役割としては、自力でコーディングすることではないので、実装方針や具体的なコードの書き方は周囲に委ね、打鍵することに集中しましょう。
周囲の指示がよくわからないときは、率直にどう書くのか聞いてしまうのもオススメです。
簡単なことであっても、そのほかのモブが実装方法を言語化する力がつきますし、タイピストと同じように実装方法に不安のある参加者の理解を助けることにもなります。
タイピスト以外（その他のモブ）の役割
実装方針を議論し、実際にどのように実装するかを決めるのがその他のモブの役割です。
タイピストが指示を理解できていなそうだったら、より詳細に具体的に指示を出してあげるようにしましょう。
ちょっとしたコツ
モブプログラミングをやる場合に、参加者の中でのスキル差があることはよくあります。
比較的作業スピードが速い人がタイピストになると、作業スピードは上がり、参加者もなんかわかったような気持ちになってしまいがちです。そしていざ、タイピストを変わると、実は理解が追いついていなかった。。ということも。
作業スピードが速い人はタイピストをスキップし、その他のモブとして参加することで、チーム全体のスキルアップに貢献できる可能性があります
逆に比較的作業スピードが遅い人は積極的にタイピストを務めるとよいでしょう。 実際に手を動かすことで、どうやってコーディングするのか、どこにどんなファイルがあるのかがわかりやすく、頭に浸透しやすくなります。
ただし、どうしても心理的ハードルがあり、タイピストを務めたくない。という場合には無理にやる必要はありません。その旨、チームに伝えて、その他のモブとして参加しましょう。
モブプログラミングを実施する上で最も大切なこと
開発手法としてのモブプログラミングですが、チームとしての成果を最大化することが目的であり、最も大切なのはチームとして最良の振る舞いができる雰囲気作りにあると考えています。
- タイピストとして心理的負荷なく、コーディングができ、不明点を率直に聞ける雰囲気
- その他のモブとして、自分とは意見の異なる実装方針に率直に疑問や質問できる雰囲気
- モブプログラミングでの開発体験や生産性をより高めていこうという雰囲気
他にも書き出すとキリが無いですが、誰しもが個人としてのアウトプットではなく、チームとしてのアウトプットに注目し、よりよくしていくことが大切です。
このことはモブプログラミングをやるにあたり、プログラミングスキル以上に重要なポイントだと私は考えています。
今回、発表資料を元に本記事を書かせていただきました。
皆様のモブプログラミングへの感じ方が少しでもポジティブになれたら、嬉しいです。
最後に、発表や資料に対して頂いた質問やフィードバックについてご紹介し、本記事を締めさせていただきます。
頂いた質問やフィードバック
💭: プログラミングだけでなく、設計だったり顧客提案資料を作ったりするときにも良さそうですね！
🦝: いただいたコメントの通り、プログラミングだけに限らず、多数の有識者が集まり同時に作業すると、モブプロと同じような効果を得られているケースを最近目にしました。
RSGT2024でトヨタの方が発表されていた内容はまさにそれに近いです。
参考) プリウス開発に見るアジャイル開発要素と今時の進め方：続編
💭: モブプロ好きだけどたまにマンツーマンの塾の気持ちになります
🦝: 一方的にもらうインプットが多くなってしまったり、逆に教えるアウトプットが多くなることがありますよね〜。（あるある）
❓: モブプロ中にリードするのはタイピストですか？モブが指示して動く方がいいのでしょうか
🦝: 発表資料にも記載しましたが、基本はモブが指示して、その内容をタイピストがコーディングしていくと良いと思います。タイピストは必要以上になにか書かねば。と緊張することも無いです。ただし、モブが指示していない実装をモブへの相談無しにこっそり書き進めるのはNGです。
❓: tanukiti は何人チームで、どれくらいの頻度でモブプログラミングしてるのでしょうか
🦝: 普段は4人チームで開発をしています。週3〜4回ほどは時間に長短あれどモブプログラミングしています。
❓: 10分でタイピストを交代という話でしたが、なぜ10分なのでしょうか
🦝: 10分で交代となると、タイピストのターンがすぐに順番回っていくのでめちゃ集中していないといけない。というのが大きい気がします。集中してないと、突然交代！となったときにコード書けなかったりします。もちろん、10分でなくても20分とかにカスタマイズするのも全然良いかと思います。
発表資料はこちら
