モブプログラミングで「一緒に働く」を戦略的に仕事に取り入れよう

みなさん、こんにちは。「制御不能なアジャイルモンスター」こと及部敬雄(@TAKAKING22)です。私は現在、 Silver Bullet Club というソフトウェア開発チームに所属していますが、チームでは2017年5月にモブプログラミングを採り入れ、現在も継続しています。こうした経験のなかで得られたモブプログラミングに関する知見を、書籍、記事、コミュニティ活動などを通して発信してきました。また、アジャイルコーチとしてチームや組織へのモブプログラミングの導入支援もしています。

本稿では、モブプログラミングを実際の現場で活用する際に直面しがちな悩みポイントを抑えつつ、個人やチーム、そして組織がモブプログラミングとどう向き合っていけばよいのかについて、ご紹介します。

モブプログラミングとは

さて、ご存じの方も多いとは思いますが、モブプログラミングとは、チーム全員で、

  • 同じ仕事を
  • 同じ時間に
  • 同じ場所で
  • 同じコンピューターで

実施するソフトウェア開発のアプローチの1つです。

モブプログラミングはペアプログラミングと構図がよく似ています。ペアプログラミングでは2人が1台のコンピューターの前に座って共同作業をしますが、モブプログラミングでは3人以上が1台のコンピューターの前に座って共同作業をします。一見するだけでは、ペアプログラミングよりも参加人数がただ多いだけですが、モブプログラミングはチーム全員にコラボレーションの範囲が拡がっている、という点が最大の特徴です。

モブ“プログラミング”という名称から、エンジニアのためのプラクティスだと思われがちです。しかし、エンジニアの仕事内容を見てみると、設計、テスト、レビュー、議論など、プログラミング以外のことをたくさんしています。つまり、モブプログラミングは「複数人で共通の目的をもって協力してアウトプットする」手法であり、エンジニアの間だけに閉じず、さまざまな場面で活用できる手法なのです。

実際のモブプログラミングの様子は、同手法を生み出したHunter Industries社が公開している「モブプログラミングをしている1日」をまとめた動画をご覧いただくのが分かりやすいでしょう。

私たちのモブプログラミングの様子。

また、リモートワークが定着しつつある昨今、前述のモブプログラミングの定義を

モブプログラミングとは、チーム全員で、

  • 同じ仕事を
  • 同じ時間に
  • 同じ空間
  • 同じ環境

実施するソフトウェア開発のアプローチの1つです。

と、このように、リモートワークに適応させることができます。リモートワークに適した環境を整えて、ツールをうまく使うことで、参加者がリアルで同じ場所にいなくとも、モブプログラミングを行うことができます。

リモートでのモブプログラミングの様子。

モブプログラミングの流れ

モブプログラミングでは、キーボードを操作する1人を「タイピスト」、タイピスト以外のその他すべての人々を「その他のモブ」と呼びます。

ペアプログラミングにおけるドライバー(タイピング担当)とナビゲーター(ドライバーへの指示出し担当)という言葉を聞いたことがあるかもしれません。モブプログラミングにおいても、タイピストは「ドライバー」、その他のモブは「ナビゲーター」と呼ばれることがありますが、モブプログラミングの場合、仕事をドライブする中心はタイピングする人ではなく、それ以外の参加者なので、ドライバーとナビゲーターという表現は実は適切ではありません。

モブプログラミングの登場人物。

また、モブプログラミングはタイピストが作業しているのをその他のモブが見ているというイメージを持ってしまいがちですが、それは誤りです。 モブプログラミングでは、その他のモブが問題解決の中心となって目の前の問題をどうやって解いていくのか考えます。チームで話し合って合意したことをタイピストに伝え、タイピストは代表してタイピングします。

そして、タイピストを順番に交代していくことでモブプログラミングは進んでいきます。基本的にはすべてのメンバーにタイピストになる機会が与えられます。

モブプログラミングのイメージ

なぜモブプログラミングが必要なのか

モブプログラミングについて一番よく聞かれる質問は、「複数人で1つの作業をするモブプログラミングは生産性が低いのではないか?分担作業した方が効率がよいのではないか?」です。いくつかの観点でこの問いについて考えてみます。

分担作業とモブプログラミングの比較

まず分担作業で起きていることを考えます。分担作業と聞くと、バラバラに作業を進めているタイミングだけをイメージしてしまいがちです。しかし、実際には実作業の前後に「同期のための作業」が発生します。分担作業の前のタイミングでは、キックオフ、設計、タスク分割、アサイン、認識合わせなどを行い、「分担作業できる状態をつくる時間」が必要です。分担作業の後のタイミングでは、レビュー、承認、引き継ぎなど、「仕事のアウトプットを1つにまとめる時間」が必要です。もちろんこのタイミングでミスが見つかった場合は、手戻りになります。

チームや仕事の状況によりますが、同期する作業に費やされる時間は自分たちが想像している以上に多いです。チームの中に同期する作業専門の役割を置くことも多く、彼らはプロジェクトマネージャーと呼ばれていたりします。

次に、モブプログラミングで起きていることを考えます。モブプログラミングでは、チーム全員で1つの作業を進めていくので至ってシンプルです。分担作業の際は「同期のための作業」が必要でしたが、モブプログラミングの場合、常に同期をしながら作業を進めていく、というイメージです。チーム全員で認識を合わせて、設計し、タスク分割して、実際に作業します。これら一連の流れがメンバーの目の前で行われているので、チーム全員でリアルタイムレビューをしていることになります。また、チーム全員で作業を進めているので、アウトプットだけでなくそこに至るプロセスも含めて、チームメンバー全員が把握していることになります。

ここだけを切り取ると、「モブプログラミングが高効率な手法」と感じられるかもしれませんが、分担作業とモブプログラミングでは向いている仕事が異なります。

たとえば、定型の運用タスクのように、誰がやってもある程度同じ結果になりやすく、同期作業のコストが小さい仕事は、分担作業が向いています。一方で、プロジェクト初期の環境構築や技術検証のように、仮に分担して誰かが一人で取り組んだとしてもその結果や過程をチーム全員が知っていたほうがよい仕事は、モブプログラミングが向いています。

2つの生産性、アウトプットとアウトカム

また、生産性という言葉には注意が必要です。同じ言葉を使っていても、人によってイメージしているものが違うことがあるからです。生産性とはアウトプット(生産されるもの自体)とアウトカム(アウトプットによって生まれた価値の大きさ)の2つに大きく分けて考えられます。

アウトプット(生産されるもの自体)の生産性、つまりコードを書いた行数やドキュメント量を求めるのであれば、たいていの場合は分担作業をした方が生産性は高くなります。

一方で、アウトカム(アウトプットによって生まれた価値の大きさ)の生産性を求めているのであれば、効率だけでなく効果に着目して、より高い価値が出る方法を選択した方が生産性は高くなります。たとえコードを書いた行数が多くても、それがプロダクトコードとして1つにマージされてユーザーに価値が届かなければアウトカムはゼロです。

そして、私たちがプロダクト開発をしているときに求められる生産性は、たいていの場合アウトプットではなくアウトカムの生産性です。

分担作業とモブプログラミングを使い分ける

このように、分担作業とモブプログラミングのどちらが適しているのかは、単純比較することはできません。

そもそも分担作業とモブプログラミングのどちらか1つだけを選択する必要はありません。チームや仕事の状況に合わせて分担作業とモブプログラミングを使い分けることが、チームの求めている生産性を高めることにつながります。

これからのチームに求められるのは変化に強いチーム

コロナ禍に入って、モブプログラミングを導入するチームがとても増えました。

同じオフィスに通い、同じ席に座って、決まったリズムで仕事をしていた頃は、いつもどおり仕事をして成果を出すことがチームに求められていました。ところが、慣れないリモートワークに適応しながらもチームで成果を出すことが求められる状況になり、チームの仕事の進め方をアップデートする必要が出てきました。そこで改めて注目されたのが、モブプログラミングです。

オフィスで働くのかリモートで働くのかという違いは、ここでは重要ではありません。本当になにが起こるかわからない世の中であると誰もが気づいた今、そしてこれからは変化に強いチームが必要とされています。

モブプログラミングという選択肢を持っていることは、チームにとって大きな武器になることでしょう。

モブプログラミングを現場で運用する

モブプログラミングは、試してみることはとても簡単です。しかし、実際にモブプログラミングを現場で運用するとなると悩むポイントがいくつか存在します。

モブプログラミングをするタイミング

モブプログラミングをいつするのか。モブプログラミングをするタイミングは大きく分けて3つのパタンがあります。

  • 常にモブプログラミングで仕事をする
  • 時間枠を決めて実施する
  • 仕事に合わせて実施する

「常にモブプログラミングで仕事をする」では、読んで字のごとく働いている時間は常にモブプログラミングで仕事をします。私たちのチームでは、Hunter Industries社のモブプログラミングと同じ「常にモブプログラミングで仕事をする」を始めて、5年経った現在も続けています。いきなりこの選択ができるチームはあまり多くないと思いますが、得られるものはとても多いのでぜひ挑戦してみて欲しいです。

実際にモブプログラミングを運用している現場の多くは、「仕事の一部」にモブプログラミングを取り入れています。

「時間枠を決めて実施する」は、毎週火曜日の午後はモブプログラミングをする、といったように、時間枠を設けてモブプログラミングを実施します。時間枠が決まっているため、仕事の計画が立てやすく、一番導入しやすいパタンかもしれません。また、兼務や副業など多様な働き方をしているメンバーを含むチームでは、時間枠が決まっていたほうがメンバーが参加しやすいというメリットがあります。このパタンの場合、モブプログラミングの時間にどのような仕事をするのか選択することがとても重要になります。導入初期は、仕事を選択する過程もモブプログラミングの中に組み込むと、仕事の内容によって仕事の進め方を選ぶという発想や、選択基準や考え方がチームの共通認識になっていくのでおすすめです。

「仕事に合わせて実施する」では、仕事の計画をする際、仕事の内容に応じて分担作業かモブプログラミングかをチームで選択します。私がこれまで支援してきたチームの中には、たとえ分担作業をしていたとしてもメンバーが必要だと感じたらモブプログラミングに切り替えるという柔軟なケースも存在します。仕事の計画をする難易度は高くなりますが、チームの練度が高く自分たちで仕事の進め方を選ぶことに慣れているチームであればうまく活用できるでしょう。

モブプログラミングが活きやすい仕事や状況

仕事の一部にモブプログラミングを取り入れる場合、モブプログラミングで取り組む仕事を選ぶ必要が出てきます。参考までに、モブプログラミングが活きやすい仕事や状況を以下にいくつか挙げてみます。

  • プロジェクトの立ち上げ時期
  • 新メンバーのオンボーディング
  • レガシーコードのリファクタリング
  • トラブルシューティング
  • 全体的な設計
  • 技術検証
  • 新しい技術の導入

チームのコミュニケーションを密にしておきたい状況や、複雑で正解がわからない問題解決に取り組むとき、問題解決のプロセスの中で得た学びをチーム全員で共有しておきたいときは、特にモブプログラミングが活きやすいです。

チームで仕事をする上で、コード、ドキュメント、ルールなどの形式知だけでは伝わらない暗黙知をチームで共有することがとても重要です。モブプログラミングを通して、形式知だけでなく、コードの組み立て方、文化、価値観、息遣いといった暗黙知もチームで共有することができます。共有された暗黙知が増えていくことで、メンバー同士のズレが起きる可能性が減り、分担作業をしているときも仕事がしやすくなっていくでしょう。

モブプログラミングの学習サイクルをまわす

なにか新しいことを始めて、最初からすべてがうまくいくことはまずありません。モブプログラミングのように、従来の働き方と差分が大きいものの場合は、特にその傾向が強いです。ですから、モブプログラミング導入初期は、「うまくいったかどうか」を評価することよりも、モブプログラミングを実施する中で起きたことをありのまま受け止めて、調整とチューニングを行い、少しずつチームに適応させていくことが大切です。モブプログラミングも学習サイクルをまわして、少しずつうまくなっていく、というイメージで取り組むのが重要です。

スクラムを導入しているチームであれば、スプリントレトロスペクティブの中で学習サイクルをまわしていくこともできますが、そのサイクルとは別に、モブプログラミングの学習サイクルをまわしていくのも効果的な方法です。モブプログラミングのセッションの最後、チームメンバーの記憶が新鮮なうちに、その日のモブプログラミングのふりかえりを行います。

ふりかえりの手法はたくさんあり、どれを使ってもよいですが、アクションアイテムを探しましょう。次回セッションで少しだけモブプログラミングを改善するためのアクションアイテムを1つか2つに絞って、チームで合意します。モブプログラミングは詳細なルールや進め方が定義されていません。自分たちに適したモブプログラミングを形作るためには、学習サイクルをまわしながら模索していくことが重要になってきます。

個人とモブプログラミング

私たちはチームのメンバーである前に一個人です。参加している各個人がいきいきと活動できるモブプログラミングをつくるという視点も大切です。

たとえば学習に最適なペースは人によって違います。モブプログラミングに参加することで、体験を通して学習できる人もいます。一方で、モブプログラミングで体験したことを、個人の時間で復習することで学習できる人もいます。参加者それぞれが学習しやすいように、モブプログラミング内外の時間の使い方を設計できるとよいでしょう。

先にご紹介したとおり、モブプログラミングを構成するのは「タイピスト」と「その他のモブ」という2つの役割です。同じ「その他のモブ」でも、メンバーによって知識もスキルも得意・不得意も違います。モブプログラミングに参加しているメンバーは、自分ができる方法でチームに貢献します。

また、モブプログラミングに参加したくないメンバーがいるかもしれません。すべてのメンバーにモブプログラミングへの参加を強制することは避けるべきです。すべてのメンバーを招待しますが、モブプログラミングに参加するかどうかを決めるのは個人だと考えるといいでしょう。

リモートでのモブプログラミングのコツ

先にご説明したとおり、コロナ禍以降、リモートワーク環境下でモブプログラミングを実施するチームが増えてきています、以降は、メンバーがリアルで対面しなくても、モブプログラミングを円滑に進めるために便利なツール、コツをいくつか紹介します。

良質なマイクを用意する

オンラインでのコミュニケーションにおいて、誰かの声が聞こえづらいことは小さなストレスにつながります。ミーティングのように短時間であれば我慢することができても、モブプログラミングのような長時間のやり取りでは、小さなストレスが積み重なって不快感を感じてしまいます。

コストはかかりますが、それほど高価でないマイクでも性能がよいマイクはたくさんあります。ぜひチーム全員分の良質なマイクを用意しましょう。

カメラは常にオン

モブプログラミングをしているときは、参加者は基本的にカメラをオンにします。顔や体の動きが見えることで、相手の状況を理解するための情報が増えます。また、離席していることも画面を見るだけで伝わります。

もちろん働いている環境によって、カメラを起動できない場合もあると思うので、カメラオンを強制する必要はありません。

シームレスなタイピスト交代

タイピストを交代するときに、スムーズに交代できると、集中力が途切れにくいです。

モブプログラミングをするときの開発環境は、Visual Studio Codeを使うことがとても多いです。Visual Studio Codeには「Visual Studio Live Share」という機能があります。この機能を使うと、1つのソースコードを複数人で同時に編集でき、さらにはターミナルやサーバーの共有もできるので、デバッグやWebブラウザ上での確認まで共同で作業できます。

他の開発環境を使う場合も、できるだけ交代がシームレスにできるような仕組みを用意しておきましょう。

同じ画面を見る

モブプログラミングをするときは、タイピストが自分の操作している画面を共有することをおすすめします。画面共有をしてモブプログラミングに参加している全員がまったく同じ画面を見ている状況をつくることで、「右上のボタン」「もうちょっと下」といった感覚的な言葉を使うことができます。

いつもの場所(URL)をつくる

リモートモブプログラミングでは、ビデオ会議ツールなどを使ってモブプログラミングを行います。セッションのたびにビデオ会議の予約をしたり、そのURLをメンバーに連絡したりするのは手間がかかります。できるだけURLが変わらないようにしておくことで、リモートでもチームにモブプログラミングをする「いつもの場所」ができます。

ログを残す

モブプログラミングで作業した内容のログをチャットツールに残しておきましょう。「その他のモブ」の中からログを残す担当者を決めておくとやりやすいです。ログを残しておくことで、振り返りや過去の作業の思い出す際に便利ですし、モブプログラミングに参加できなかったメンバーにも作業の進捗が伝えやすくなります。

プライベートを大切にする

リモートワークでは、自宅を仕事場にする人が多いでしょう。「Work From Home」とは、いわば参加者の自宅に仕事がお邪魔している状態なので、お互いに相手のプライベートを尊重しなければなりません。急に宅急便が来てしまった、家族に声をかけられた、など、プライベートな用事が発生した場合は、気兼ねなく離席できる雰囲気をつくっておくと、モブプログラミングに参加するための心理的ハードルが低くなります。

ハイブリッドモブプログラミングではコミュニケーションの機会を均等にする

働き方が多様になり、数人のメンバーはリアルで集まり、数人のメンバーはリモートで参加するようなハイブリッドな状態でモブプログラミングをする機会があるかもしれません。ハイブリッドモブプログラミングのときには、コミュニケーションの機会を均等にすることをいつもより強く意識をして準備します。

コミュニケーションの機会を均等にするというのは、全員が同じ会話量になるようにすることではありません。リアルで参加しているメンバーもリモートで参加しているメンバーも、同じレベルでチームの会話を聞くことができ、話そうと思ったときに話し始められる状態にします。

リアルで集まっているメンバーだけで盛り上がってしまったり、一部のメンバーの声が遠くて聞きづらくなってしまったりしないように、集音マイクを使うなど環境面にも配慮が必要です。手っ取り早い方法としては、リアルで集まっているメンバーもそれぞれのPCからモブプログラミングに参加するのもよいでしょう。

モブプログラミングはチームのリトマス試験紙である

「モブプログラミングがうまくいかない」という相談をよく受けます。実際にチームでモブプログラミングを試してみたが、うまくいかずにやめてしまったチームも多くありました。そのときになぜうまくいかなかったのか理由を尋ねてみると、以下のような問題が出てくることが多いです。

  • メンバーごとのスキルにばらつきがあって、経験者に負荷が偏ってしまった
  • チーム内の合意形成に時間がかかり、議論ばかりになってしまった
  • チーム内のコミュニケーションがうまくいかないので、モブプログラミングの場にいること自体が苦痛だった

こうした問題の多くは、チームがもともと持っていた、あるいは潜在的に抱えていた問題である可能性が高く、まず解決すべき課題といえます。なぜならモブプログラミングをしていたとしても、分担作業をしていたとしても、チームにとってはこれらの問題は解決した方が望ましいものだからです。

モブプログラミングはチームのリトマス試験紙のようなものです。モブプログラミングをすると自分たちの行動がすべてチームみんなの目に触れることになるので、よくも悪くもチームのありのままの状態がすべてそこに現れます。分担作業をしていたときにはたまたま顕在化しなかった問題や、誰かが我慢することで見つからなかった問題が、モブプログラミングをすることで明らかになることがあるかもしれません。

こうした問題に直面した際、「モブプログラミングは自分たちには合わなかったんだ」と短絡的に受け止めてしまうのは、とてももったいないです。問題が見つかったこと自体はネガティブな事象ではありません。むしろ「モブプログラミングを試したことでチームの問題が見つかった!やったー!!」とポジティブに捉えるべきです。

私がモブプログラミングのことを好きである理由の1つは、チームメンバーのメンタルモデルをたくさん発見できるところです。まったく同じ体験をしても、人によって受け止め方や言葉や行動の選択の仕方が異なります。モブプログラミングをしていると、こういった参加しているメンバーのメンタルモデルがたくさん見つかります。メンタルモデルは、認知することで、他人のメンタルモデルを自分にインストールすることもできます。ぜひみなさんもモブプログラミングがうまくいかなかったときには、「モブプログラミングを試したことによってチームの問題が見つけることができた!やったー!!」と言ってみてください。

すべてのチームがモブプログラミングをやるべきだと言っているわけではありません。モブプログラミングをすることで、関係性が悪化してしまうチームもあるかもしれません。ただし、分担作業に戻したからといって、そのチームが抱えている問題が解決したわけではありません。チームワークに課題があるチームは、分担作業をしていてもなにかがうまくいかず、どこかで問題に向き合わねばならないのです。

「一緒に働く」を戦略的に仕事に取り入れる

仕事の中でなにかしらのトラブルが発生した際に、誰かの机のまわりに集まって全員で問題解決に取り組んだという経験は、多くの方に共通する者でしょう。

集まった全員で同じ画面を見ながら、問題を分析し、解決策を検討し、その場で解決策を試し、実行可否を判断し、実行する。そこに集まった人たちの叡智を結集して、問題解決に全力で取り組みます。このときにやっていること・起きていることは、モブプログラミングとまさに同じです。

なぜトラブルが発生したときに、自然とモブプログラミングと同じ状況が生まれるのか。それがチームにとって問題を解決するまでの最短距離だからです。

最速でトラブルを解決しなければいけない状況で、タスクを分割して、仕事のアサインをして、レビューのプロセスをまわして、上司に報告して判断をもらい、ようやく実行する、といったプロセスではとても時間がかかってしまいます。メンバーひとりひとりが持っている知識、経験、スキル、役割、権限、それらすべてを同じ場に集めて問題解決に集中してコラボレーションする。これがこのチームにとっての最高速度です。

トラブルが発生したときだけではなく、通常時においてもこの仕事の進め方を活用しようという考えから生まれたのがモブプログラミングです。

私たちのチームでは「常にモブプログラミングをしている」とよく言っています。しかし、実際に仕事している時間のすべてを使ってモブプログラミングをしているわけではありません。仕事の内容によっては、分担作業をすることもありますし、もっと細かい単位でモブプログラミングと分担作業を切り替えて仕事を進めています。たとえばモブプログラミングをしている中で問題にハマったときは、自然とそれぞれ手元の環境で検索して、解決策を試して、誰かが解決策を見つけるとまたモブプログラミングに戻る、といった具合です。

私たちのチームにとっての「常にモブプログラミングをしている」は、Gitのブランチのようなイメージです。必要に応じてmainブランチから分かれることもありますが、最終的にはmainブランチにmergeします。このように、私たちは形式として一緒に作業をすることをモブプログラミングと呼んでいるのではなく、仕事のアウトプットも学びもすべてをチームに集約させていく全体の営みをモブプログラミングと呼んでいます。

モブプログラミングは「一緒に働く」ただそれだけです。その「一緒に働く」をもっと戦略的に自分たちの仕事に取り入れ、変化に強いチームに近づけるために、解像度高くモブプログラミングに取り組んでいます。

それでは、本稿がみなさんのよりよいモブプログラミングとチームワーク模索の一助になれば幸いです。

編集:はてな編集部

及部 敬雄(およべ・たかお) @TAKAKING22
Silver Bullet Club所属。
株式会社ホロラボ 歌って踊れるエンジニア。
AGILE-MONSTER.COM アジャイルコーチ。
制御不能なアジャイルモンスター。

エンジニアとして、さまざまなドメインのプロダクト開発・運用・新規事業立ち上げを経験。アジャイル開発との出会いをきっかけに、最強のチーム・組織をつくることを目標に日々奮闘し、そこで得た実践知をアジャイルコミュニティなどで発信し続けている。2019年と2022年にチーム移籍を実現した。新しいチームのかたちを模索している。また、アジャイルコーチ(個人事業主)として様々なチームや組織の支援もしている。著書に、野中 郁次郎氏と平鍋 健児氏との共著『アジャイル開発とスクラム』。『モブプログラミングベスト・プラクティス』解説。

アジャイル開発、スクラム、モブプログラミングなどの研修や支援についてのご相談は、こちら からお気軽にお問い合わせください。
AGILE-MONSTER.COM
Silver Bullet Club
銀の弾丸ラジオ