こちらは、公式アドベントカレンダー2024_A IT技術関連トピック Day.25 の記事です。
公式アドベントカレンダー2024_B 仕事術・キャリア・体験記も毎日記事を公開していますので、ぜひあわせてご覧下さい。

★Day24のアドベントカレンダー記事
「私の駆け足レビュー！Salesforce新機能で1年間をふりかえる 2024 Day.24｜【Lightningアプリケーションビルダー】」（南梨紗）
「IT未経験が半年間でIPA資格３つに合格した方法」（ニシダ）

はじめに

こんにちは、SHIFTのいしいです。
去年のアドカレは１つのコンテンツを深堀して、前後編に分けて投稿しましたが、今年は2つのトピックで2記事投稿させていただいております。

ひとつ前の記事でも触れておりますが、ただいま、開発未経験の中途、新卒を集めて、模擬開発プロジェクトを推進中です。その中でモブプロにも取り組もうということで、手始めに「モブプログラミング・ベストプラクティス」を読んだのですが、非常に良く整理された素敵な書籍でした。

そこでモブプロ実践前ですが、「モブプログラミング・ベストプラクティス」で学んだこと、加えて、自身の経験から特に気を付けたいこともあわせて今回ブログで皆さんと共有することで、一緒にモブプログラミングに挑戦できたらと思い執筆させていただきました。

また来年、年度末くらいにやってみた感想を投稿しようと思いますので、ぜひ、みなさんも私たちと一緒にモブプログラミングに取り組んでみて結果を比較してもらえると嬉しいです！

この記事を読んで実践してみて、継続してみよう！となった時には、皆さんもぜひ「モブプログラミング・ベストプラクティス」を購入してみてくださいね！

モブプログラミングとは

ご存知とは思いますが、モブプログラミングは、チーム全員が一つのコンピュータを使って一緒にコードを書く手法です。
※「プログラミング」とついてはいますが、設計や執筆といった多様な業務でも使える手法です。

全員が同じ場所に集まり、リアルタイムで協力しながらプログラミングを行います。なお、ぺアプログラミングが二人で行うのに対して、モブプログラミングは３人以上で行います。

…というのが基本ですが、こと場所に関していえば、「モブプログラミング・ベストプラクティス」が出版された2018～2019年に比べて、今はIntelliJのCode With MeやVSCodeのLive Shareといったコーディングコラボレーションツール、またMiroなどのオンラインホワイトボードに、SlackやDiscordなどのコミュニケーションツールなど、オンラインでのペア、モブプログラミングのためのツールが充実しています。

オンラインでの開催ハードルがかなり低くなってきたので、必ずしも対面開催の必要性はなくなってきているのではないかと感じています。
とはいえオンライン/オフラインのメリット/デメリットがありますので、チームの状況に応じて、どちらかではなく、どちらも併用していけるとよいでしょう。

モブプログラミングは、円滑なコミュニケーションができる状態を前提として、チームのコミュニケーション活動を活性化し、知識の共有を促進してくれる手法です。前提や活性促進効果が十分ではないなと思ったときは、オンオフ開催を切り替える、モブとは別にきちんとみんなの考えや方向性を揃えるための会話のタイミングを作るといった工夫が必要です。

モブプログラミングのメリット

モブプログラミングのメリットは以下の通りです。

• フロー効率の向上 → 価値を小さく素早く届ける

• 知識・スキルの共有 → 属人性の排除、メンバー育成

• チームの一体感向上 → コミュニケーションの活性化

順に説明していきます。

フロー効率の向上

モブプログラミングはフロー効率を重視した作業です。リソース効率を重視して、メンバーがそれぞれ別の作業を進めてWork In Progress（WIP）を複数同時に進めるのとは反対に、複数人で一つの取り組みを行い、WIPを一つに絞り込む手法です。

それだけ聞くと生産性は大きく下がるのでは？と思われるかもしれませんが、複数の視点から早期に問題・課題を検知できるため、バグの早期発見や解決による品質向上が期待できますし、常に一緒に作業しているので、チーム内での情報共有作業（説明のためのMTGや情報整理や図示化などの引継ぎ作業）が不要になります。

結果的に、デイリースクラムやコードレビュー、テストなどのプロセスに加えて、レビューやテストでの指摘による手戻り作業、 あるいは同時並行作業によって発生したマージコンフリクトの解決のための作業時間も減りますので、リソース効率を重視する場合に比べて生産効率が大きく劣る、ということはなくなります。

また、リソース効率を重視すると、レビュー活動などの分だけ１つ１つの成果物の作成時間が伸びますので、結果的に、フロー効率を重視すればある期間内で3個中2個完了できたのに、リソース効率を重視した結果全て完了できなかった。あるいは、今回の作業が完了しないことで、後続作業の見積もできなくなり、計画が立てづらい、というようなリスクも抱えることになります。

今回は深く言及しないものの、リソース効率を重視するメリットももちろんいろいろあるので、使い分けが重要にはなってきますが、このようにフロー効率を重視した動きには多数のメリットがあります。

ただ、AIの成長著しい昨今ですので、AIが「複数視点からの検討・提案」「トランススクリプトから自動で情報整理・要約」といったフロー効率を重視したときのメリットとなる動きを一定以上の品質で提案できるようになれば、リソース効率重視の時代が来るかもしれないですし、反対に「コード生成」などの成果物作成の面で強力になれば、フロー効率重視の時代が来るかもしれません。正直、未来に関してはどうなっていくか予測がつかないですね 笑

知識・スキルの共有

チームメンバー全員が同じコードを見て議論するため、その案件・プロジェクトの知識の共有が最速で行われます。これにより、属人性（バス因子）の排除が可能となり、急な体調不良によるメンバーの不在が起こっても、作業がペンディングしてしまうリスクが下がりますし、有休もとりやすくなります。

また、他の人の作業工程も見えるので、効率的な業務を行うためのTipsの共有も行われます。この知識・スキルの共有という点において、非常に大きなアドバンテージがあるモブプログラミングですが、だからこそ注意が必要な面もあります。

というのも、この知識の共有は嫌でもやらないと、みんなで会話ができない状況に陥ります。一番知識の少ない人には特に情報共有のリソースを割いて対応していく必要があるわけです。

それゆえ、モブプログラミング時の生産性は一番スキルの低い人の生産性に大きく依存します。効率的、強制的に知識の少ない人を引っ張り上げれるのは価値である一方で、業務でモブプログラミングを行う場合は、この教育効果と、生産性とのバランスをとっていく必要もあります。いつでも、だれとでも行うことが出来るわけではない、効率的だからと言って、そこだけを重視するわけにはいかないことには注意が必要です。

チームの一体感向上

一緒に作業することで、コミュニケーションが活発になり、チームの結束力が高まります。

ペアプログラミングは1対1なので、対立構造になってややもめやすく、またキャリアや肩書などの立場によって結論が変わってしまう場合がありますが、モブプログラミングは誰かの意見がぶつかった時に客観的に状況を把握できる人がいてくれる、最低でも多数決で方向性が決まっていくことになるので、何かの決定がチームの総意として行われるようになるのも魅力かと思われます。

ただし、こちらに関しても、「知識・スキルの共有」の項目でも書いた、
スキルギャップが問題になってきます。スキルが低すぎると、会話に入り込めない、足を引っ張っているようで委縮してしまう、逆にスキルが高すぎると、みんなをリードしていかなければ！という意識が強すぎて、実質的な一人作業になって、モブプログラミングの価値を活かしきれない、という事象が発生します。

モブプログラミングはコミュニケーションがうまく回っていることが何よりも重要です。

可能であればモブプログラミング活動前に、Big5などの性格診断による相性や予期されるリスクの確認やスキルセットの確認といった、チームビルディングをきちんと行うこと。

モブプログラミング活動中に、やたら相手を批判しないように表現に気を付けること、わからないものはわからないと勇気をもって伝えること、聞かれた側は質問に誠実にきちんと答えること。
（ただし、回答のタイミングはモブプログラミング中に答えるべきものだけでなく、終わってから答えた方が良いものもある点には、聞く側も答える側も注意が必要）

モブプログラミング活動後、特に導入初期はモブプログラミングのふりかえりをきちんと行うこと、モブプログラミング活動外で、自身が感じていること不安や懸念、他の人にお願いしたい要求を敬意をもって伝えること、チーム内でスキル差が大きい場合は積極的に自己研鑽や情報収集も行うこと。

などといった、コミュニケーションを円滑にするための活動は手を抜くことなく進める必要があります。これらをぬかりなく行うことで、モブプログラミング外でのコミュニケーション自体も活発になり、円滑な業務遂行が実現できるようになるでしょう。

モブプログラミングのやり方

基本的な進め方

基本的な進め方として、ボードやマウスを操作する一人の作業者（タイピスト）とその人に指示を出す指示者たち（その他のモブ）の二つのロールで構成されるチームが一つの場所（オンラインでも、オフラインでも）に集まって作業をしていきます。タイピストはタイムボックスを切って交代することで、機会均等にタイピストを担当します。

個別の事項について次の流れで細かく説明していきます。

• それぞれのロールで意識すること

  • タイピスト

  • その他のモブ

• 最初に決めておくルール

  • タイムボックスを決める

  • 誰がどのような順番でタイピストを行うか決める

• 最初に決めなくても良いその他のルール

  • オンライン、オフライン開催について

  • 途中入退室のルール

それぞれのロールで意識すること

タイピスト（ドライバー）

その他のモブに指示された通りに実際にコードを入力する役割です。指示された内容を正確に入力することに集中します。

言われたとおりに行うことが仕事なので、エンジニアである必要はありません。タイピストが書けなかったとしたら、タイピストのスキルの低さの問題ではなく、タイピストにきちんと説明できないその他のモブの問題です。
（とはいえ、いずれにしてもやたら他責にならないように注意しましょう。
チームの数だけ異なる正解があります）

また、基本的にはまんべんなくタイピストを行うことが理想ですが、開催時間の都合などで、誰かを優先的にタイピストにするならスキルの低い人を優先的に指定して、その人のスキルアップを目指しましょう。

注意点として、タイピストは勝手にコードを書いてはいけません。指示待ち人間になりましょう。
※自分が伝えたいことを伝えるために補助的に書くのはOKですが、最終手段です。

もしなにか面白いアイデアを思い付いたら、自分の手元にメモだけしておいて、提案するのは自分がその他のモブになった時にしましょう。また、書く前から、あれこれ反論するのもいけません。口頭のコミュニケーションは誤解も生まれやすいです。まずは書いて、書いたものをベースに話を進めましょう。

繰り返しになりますが、タイピストの仕事はあくまで指示通りに書くことです。そうすることで、以下のような価値が生まれます。

• 指示通りに素直に書いて、指示者の想定外のモノを生み出すことで、曖昧な個所をあぶりだす。

• 指示が分からなかった際の質問で、目の前の作業の解像度を上げる。
  （全く書けない場合は仕方ないが、基本は分からないなりにとりあえず書いてみた後で質問しよう）

• 自分なりのやり方をみんなに見せて、作業のアドバイスをもらって成長する。
  （あるいはみんなに言われたとおりにやってみて、自分の普段のやり方との違いを体感する）

その他のモブ（ナビゲーター）

タイピストに指示を出す役割。コードの設計や実装方法について考え、タイピストに具体的な指示を出します。

タイピストの項目で、タイピストが書けなかったとしたら、タイピストにきちんと説明できないその他のモブの問題だと書きましたが、タイピストもまたエンジニアである必要はありません。QAやPOがその他のモブを行うことにも意義があります。

その他のモブは、タイピストにエンジニア目線で指示を出すだけでなく、自分が持ってる知見を提供して、目の前の問題解決や、将来発生しうる問題に関する情報提供を行ったり、みんなと議論して、あるいはみんな（あるいは自分）が議論に参加できるようにファシリテーションを行い、情報の解像度をあげたり、きちんと議論を深めていくためにホワイトボードに図示したりするのも仕事になります。

そうすることで、以下のような価値が生まれます。

• タイピストを育てる。

• コミュニケーションを活性化させて、情報を発見する。

• 多面的な視点の提供を行い、知識を共有する。

• 情報。知識を多数並べることで、実装・仕様の抜け漏れを予防し品質を担保する。

最初に決めておくルール

タイムボックスを決める

ポモドーロテクニック…を使わないといけないわけではないですが、ポモドーロで作業時間を区切るとタイピストの交代タイミングとしてちょうどよいです。

また、モブプログラミングはそれなりに疲れます。その価値はありますが、長時間の集中作業が続くと、無視できない疲労につながるでしょう。そういう意味でも、ポモドーロの1セット終わった後の長めの休憩は都合が良いです。

加えて、導入を決めたからと言って一日中何セットも行う必要はありません。1日のうちに１セット（約2時間）だけポモドーロを行う、週に3回だけ行う、など無理のないように設定しましょう。

誰がどのような順番でタイピストを行うか決める

一定の時間ごとにロールを交代することで、全員が異なる視点から作業を経験し、スキルを向上させることができます。均等・公平にタイピストを行えるように進めるとよいでしょう。

どうしてもタイピストをやりたくない人がいる場合、無理にやらせる必要はありませんが、どういう理由でやりたくないのか、それは自分やチームのためになることなのか、明らかにするとよいでしょう。

また、極端にスキルの高い人がタイピストを行うと、その人だけで自己完結してしまう場合があります。モブプログラミングが上手く回せない場合には、スキル差がありすぎる人をみんなで話し合ってスキップするのも選択肢です。

基本的には、知っているのと経験するのは大いに違うということを踏まえて、挑戦していけるとよいですね。

最初に決めなくても良いその他のルール

オンライン、オフライン開催について

• オンライン開催は場所の確保の手間がなく、まわりに気遣う必要がない

• 様々な理由で出社ができないメンバーともコラボレーションできる

• といったメリットがある一方で、誰に話しかけているのかわかりにくい（モブで議論しているのか、タイピストに指示しているのかなど）

• 環境差分が発生しやすい

• Tipsについてはオフライン開催の方がより気付きやすく、共有もしやすい

• 深いコミュニケーションはやりづらい

といったデメリットもあります。どちらかだけをひたすら続けるのではなく、チームの課題や状況に合わせて臨機応変にアプローチを変えていけるとよいですね。

途中入退室のルール

MTGやチャットでのやり取りが多い人は、どうしても途中退室や話を聞けていなかった、という状況が発生しやすいです。
モブプログラミング中は他の作業を禁止するのが理想ですが、どうしても難しい場合は、中断方法を決める、メンバー選定を再考する、途中退室しても今の状況が分かるようなテキストを残す、といった何らかの工夫を行う必要があります。

導入プロセス（導入時に気を付けること）

明確な目的設定

なぜモブプログラミングを導入するのか、目的を明確にすることが重要です。これまでに書いたことをきちんと意識して、自分たちがどうなっていくことが理想なのか、まずはモブプログラミングを実際にメンバー間で認識合わせをしましょう。

ルール説明

前述した、モブプログラミングのやり方を確認し、自身がどこで活躍できそうか、懸念点は何か、事前に考えて、チームビルディングの時に共有しておきましょう。

チームビルディング

モブプログラミングはコミュニケーションが命です。コミュニケーションが非常に重要なポイントになるため、自己紹介や自身の目的、考え、懸念に加えて、事前にBig5などの性格診断を行って、チームとしての相性や将来的に直面する課題について整理しておくのも良いでしょう。

性格診断については「モブプログラミング・ベストプラクティス」に細かく言及があったので、気になる方は是非ご購入ください

環境準備

チーム全員にモブプログラミングの基本を理解してもらったら、必要なツールや環境を整えます。

タイピストの交代を円滑にするためのPCやキーボード＆マウス、スイッチングハブ、議論や情報共有を円滑にするためのホワイトボード、大きいモニター、運営を円滑にするためのポモドーロ用のタイマー、場所、オンラインでの実施を可能にするための各種ソフトウェア…全てをそろえる必要はありません。自分たちの現状で可能な範囲で用意しましょう。

また、モブプログラミングで解決するのに適したタスクを探してきたり、モブプログラミング中に邪魔が入らないようにMTG設定したりするのも重要です。

小さくやってみる

モブプログラミングに正解はありません。集まったメンバーの数だけ正解があって、よいモノ、よい環境をそろえれば上手くいくものでもありません。
自分たちのチーム状況で効果が出るためのやり方を模索する時間がしばらく必要です。期待値が高すぎると、効果が出る前にモチベーションがなくなってしまいます。

まずは短時間、少人数のトライアルセッションを実施し、フィードバックを収集しましょう。ふりかえり、フィードバックはその日に行ったセッションの最後に行うことを推奨します。（スプリントレトロスペクティブでは、当時の感覚や課題感が抜け漏れてしまうためです。）
トライアルセッションで得たフィードバックを元に、プロセスやルールを調整し、効果が出るまである程度の期間はかかることを見越しつつ、挑戦しましょう。

軌道に乗り始めたら、きちんとふりかえる

ある程度、感覚値で上手くいき始めたら、継続（周囲や自分たち自身の納得、説得）のために長期的な評価も重要です。以下の評価軸を参考に定量的な評価の準備もしていきましょう

評価軸例：

• 生産性：リリースサイクルや作業チケット着手からクローズまでの期間の短さ

• 品質：本番障害の少なさ

• 属人性：知識が共有され、いつも同じ人が似た作業チケットに着手していないか、誰か一人だけ生産性が極端に悪かったり、よかったりしないか

• 継続性：週にどのくらいモブプログラミングをやったか（やらなかったのはなぜか）

おわりに

モブプログラミングは、チームのコミュニケーションを活性化し、
知識の共有を促進する素晴らしい手法です。

しかし、導入には慎重な準備と継続的な改善が必要です。この記事が、皆さんのチームでのモブプログラミング導入の一助となれば幸いです。

最後までお読みいただき、ありがとうございました。

このブログが参考になれば幸いです。
私たちもこれから挑戦していきます。 皆さんのモブプログラミングの導入も一緒に成功することを願っています。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）

SHIFTのサービスについて（サービスサイト）

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら

PHOTO：UnsplashのDrew Beamer