はじめまして、LODEOでサーバーサイドエンジニアをやっている陶山と申します。先日エンジニアチームで「モブプログラミング」をやってみる機会があり、そのときに感じたことや考えたことをお話しします。

LODEO（ロデオ）とは

LODEOはスマートフォン動画に特化したアドネットワークサービスです。ユーザーの動線を邪魔しない画期的な“タテ”動画の配信フォーマットで、「人の記憶に強く残る」新しい動画広告の視聴体験を可能にしました。

縦型のスマートフォン向け動画広告では国内最大級の在庫を持つアドネットワークです！オリジナルアドフォーマット「タテフル」など、ユーザー体験を阻害せず、印象に残る動画広告を配信出来るよう日々開発を行っています。

モブプログラミング Mob Programming とは

とりあえずこの動画を見ましょう。

Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer

ーMob Programming A Whole Team Approach

一言で言うと、「チーム全員でペアプロするやつ」です。以下、「モブプロ」と略します。

2014年にWoody Zuill氏がAgile Allianceで発表されたMob Programming A Whole Team Approachこちらがおそらく原著です。Scrum Gathering 2017 Tokyoで言及あったらしく、日本でもちょくちょく「モブプロやってみた」的な記事を見かけるようになりました。

ちなみに私は omoiyari.fm の中の人@miuranobuakさんから教えてもらいました。

ちょっとググると日本語記事がわんさか出ますね！

MS牛尾さんの記事はかなりバズっていたので、だいぶ認知度も上がったのではないでしょうか。

モブプロのやり方・プラクティス

まず、最低限準備するものです。 ↑の写真を見ていただければだいたい分かるのですが、

騒いでもいい部屋（大事）
チーム全員がストレスなく見れるディスプレイかプロジェクタ
作業マシン一台
快適なキーボード

やり方もだいたい写真から想像がつくかと思いますが、Mob Programming A Whole Team Approach#5. A FEW IMPORTANT WORK PRACTICES より、大切と感じたことを抜粋します。

5.1 The Principle of Treating Each Other with Kindness, Consideration and Respect

「優しさ、配慮、敬意をもってお互いに対処する」原則

We express ideas, discuss problems, explore possible solutions, and share thoughts all day long.

We are rarely in agreement on most things until we have had a chance to hear from everyone who has something to contribute, and have had the back and forth discussions that expand our understanding.

To make it possible to keep this high level of communication happening throughout the day we have adopted a principle to always treat each other with kindness, consideration, and respect.

アイデアを表現し、問題を議論し、解決策を検討し、考えを共有します。
議論していない殆どのことについて同意していません。
この高度なコミュニケーションを維持するため、優しさ、配慮、敬意の原則を採択します。

よく言う心理的安全に言及しているものと思われます。これはもちろんモブプロに限った話ではないですが、効果的なモブプロを行うためには、問題に対して常に複数人が議論を行っている状態が必要となるため、コミュニケーションの前提としてチームメイトへの優しさ、配慮、敬意が特に重要であると考えられます。

というか、この前提がないとモブプロ自体が機能しない可能性が高いです。

5.2 The Driver/Navigators Pattern of Programming

Driver / Navigator パターン

Llewellyn Falcoの “strong” ペアプログラミングスタイルである、とあります。

The basic rule is that “for an idea to go from your head into the computer it MUST go through someone else’s hands.”

考えたことをコードを落とすときは自分以外の誰かの手を通す、という基本ルールに則って、チームはDriver/Navigatorの２つのロールに分かれます。

Driver/Navigatorのそれぞれのロールについては、以下のように紹介されています。

Driver

Driver sits at the keyboard and types in the code.

The Driver listens to the Navigators, and must trust the Navigators.

The Driver is focused on the typing/coding.

ドライバーはキーボードの前に座り、コードを入力します。

ドライバーはナビゲーターに耳を傾け、信頼しなければなりません。
ドライバーはタイピング/コーディングに集中します。

私の解釈も入りますが、ドライバーはいま解決しようとしている問題、及びその実現方法、実現順序などメタな情報を頭から追い出して、ナビゲーターが指示する粒度の機能をコードで実現することに集中することが大切です。

これはナビゲーターを信頼していないとなかなか出来ません。（えっそんな方針で実装しちゃって良いんだっけ…とか）

Navigator

The Navigators discuss the idea being coded and guide the Driver in creating the code.

We discuss and work out the possibilities verbally and at the white board so everyone is gaining a full understanding of the idea.

It is important for the Navigators to speak at the highest level of abstraction that the Driver (and the rest of the team) is able to digest at the moment.

It can also be at a very detailed level if necessary, even at the level of keystroke instructions when needed.

This will change … depending on the idea being worked on, and the ability of the Driver to understand the instructions.

ナビゲーターはコード化されたアイデアについて議論し、ドライバーをコード作成に導きます。

口頭で、ホワイトボードで可能性を議論し、全員がそのアイディアを理解しています。
ナビゲーターはその時点でチームが理解できる最高レベルの抽象化で話すことが重要です。
必要に応じて、キーストロークを指示するような、非常に詳細なレベルにすることもできます。
実現しようとしているアイディアやドライバーの指示の理解度によって、都度レベルを変更します。

全員が今のコンセプトを理解・同意していること＝チームとしての合意、意思決定がその場でなされていることを目的とし、その手段として指示の粒度を変えよという程度で理解しています。

指示の粒度については5.1にも則するものと思われますが、ドライバーが指示を完遂できることと、その場にいる全員が今起こっていることを理解できること、が大切です。

これらDriver/Navigator分担と、背景にある仲間への敬意・信頼こそがモブプロ成功の秘訣である(ハズ)です！！

5.3 Driver Rotation using a Timer

タイマーでドライバーをローテーションする

We rotate the Driver every 15 minutes, so no one is attached to the keyboard for very long.

そのままです。区切りの良いところではなく、時間で区切ってドライバーを交代するというルールです。

原著では15分おきに交代しているとありました。高い集中力の持続や作業の離散化など、ドライバーに対してポモドーロテクニックに近い効果が期待できます。

後述しますが、ドライバーの交代は基本的には割と大きなコンテキストスイッチになるはずなで、モブプロで成果を出すにはこのコストを最小化する必要もあると考えます。

LODEOでの実践

LODEOでモブプロやってみよう、となったのは、KPTミーティングで「T:モブプロ面白そうなのでやりたい」と提案して採用されたのが発端でした。ペアプロの類をやりたいと言ってやってくれたチームが今までなかったのでそれなりに理論武装していたのですが、意外とすんなり採用されてしまいました。。LODEOの皆さんありがとうございます！

LODEOでは月一くらいの頻度で、技術的負債や細かい要望、担当をつけるほどではない瑣末な不具合などをまとめて片付ける「ピットインデイ」を設けています。ちょうどいいのでピットインでやってみようと話が進んで、今回はトライアルとして、ピットインデイの時間半分４時間をつかって実施してみました。

前日までの準備

モブプロという言葉自体の知名度は上がってきているように思いますが、何？何故？どうやって？等まだまだ実態は浸透していないように思います（牛尾さんの記事でそうでもなくなったかも。。）。開始時点では説明必要と判断したので、ピットイン棚卸し会議（ピットインの前日に行う、ピットインデイで対応するアイテムを決める会議）の時間を少しもらってモブプロの紹介と、LODEOでのやり方を提案させてもらいました。

といっても私も実施したことはなかったので、

モブプロとは・面白そうなこと
LODEOではこうやると良いんじゃないか

という提案でした。

HOW TOでオリジナルと大きく異る点として、PCは共有せず、ドライバーの人のものを使う方針を提案・採用しました。

これは、キーボード(US vs JP)やキーバインド、エディタやその設定差異によるストレスを最小化するねらいがあったのですが、結果としてはスイッチングのコストが増加したと思っています。

また、事前にメンバ間でコンテキストをある程度揃えるため、ブリーフィングを行うことを提案しました。

それ以外はほぼオリジナルのやり方を踏襲しています。

メンバー

LODEOサーバーサイドエンジニア・インフラエンジニアの計６名で行いました。今年配属された新卒の２名も巻き込んで、実装スキルやビジネス・既存システムの理解度も様々なチームになり、トライアルとしては十分に多様性のある上々のチーム構成でした。

LODEOは普段からランチをよく食べに行ったり、コミュニケーション量は多いチームだと思います。インフラエンジニアが普段Scala書かないにも関わらず違和感なく参加してくれた・参加できたことをみても、チームの Kindness, Consideration and Respect の素養が伺えます。

白熱した議論になることは殆ど無いですが、業務においても必要十分量、一定以上の議論を行う習慣はあり、以下の例や感想は、そのような下地があるチームでの実施例、というバイアスを念頭においていただければと思います。

環境

CyberAgentには開発合宿等に利用できるシャトーアメーバという施設があります。この１部屋を一日抑えました。

綺麗だしおしゃれだしコーヒー飲み放題だし個人用ディスプレイ完備だし共有用のディスプレイもあるしちょっと騒いでも文句言われないし、空調がちょっと賢くない 事を差し引いても最強のモブプロ環境であるといえます。

なお実際業務で導入しようとすると、チームが専有できる個室がないと不可能ですね。うるさすぎて確実に同居チームから苦情が来ます。

当日の流れ

0. 準備

準備でモタついてせっかくの期待感(?)がさめちゃうのを危惧したので、集まったらスグ始められるよう朝ちょっと早く行ってディスプレイの接続セッティングを行いました。

シャトーアメーバにはAppleTVが設置してあるので、これで画面キャストしたら最高にCool、と思ったのですがうまく表示されなかったり解像度の問題があったりしたので、ちょっとダサいですが有線接続を選択しました。こんなかんじです。

HDMIスプリッタと長いHDMIコードがあったので、ちょろちょろっと配線を変えて前方２枚のディスプレイに同じ画面が投影されるようセットアップし、有線接続であることに目を瞑ればそれなりにCoolな環境ができました。

1. ブリーフィング

私が適当にファシリテートして、これから実装しようとするフィーチャーの共有と、現時点で考えられる実装方針を全員で話し合ってリスト化し、共有を行いました。

また、ローテーション順をその場の並びで適当に決めました。ここは戦略は必要ないと思います。

2. 実施

10:30頃からローテーションを開始し、休憩・ランチ休憩を挟んで２周めの最初のドライバーで実装完了しました。

だいたい以下のような流れで実装が進みました。

影響範囲・改修箇所の特定/Repositoryに仮実装を追加
Repositoryの実装
Service/Routerへの影響を実装
Repositoryに不具合があったので修正
UTを追加・不具合箇所特定
不具合箇所を修正
ちょっと調整してDONE

実測 2h20minで実装完了したことになります。この時間が絶対値として早いか遅いかを評価することにあまり意味はありませんが、個人的には本番環境リリースまでのトータルリードタイムでは私が一人で実装するよりは早かったんじゃないかな？と思っています。

3. レトロスペクティブ

最後に、簡単な振り返りとしてチーム全員から感想を聞いてみました。概ね好感触な反応が得られ、みんなが楽しめたのではないかと思います！

もう一度やっても良いと思う方？

Yeah!

チームの感想

Pros

IntelliJのショートカットしれてよかった
他のエンジニアの実装を見れるのが良い
他のエンジニアの環境(ターミナルとか)見れるのが良い
Hands Onがよかった
Navigatorの議論を聴いて、一人でやるより早く理解できた
みんな同じようにトライ＆エラーで実装していることがわかって安心した
リアルタイムに合意が取られて進むのが良かった

大別すると、

開発環境や手順などのエンジニアリング面の伝承・共有　~Driverのメリット
ひとところに集まって意思決定が行われる ~Navigatorのメリット

に分けられ、チームの満足度含めモブプロで一定の成果が得られた、と考えて良さそうです！

Cons

遅い

これはシンプルに、今回の枠組みの中では慣れた人が一人で実装したほうが早かった、というのがおそらく真実で、６人で別々のタスクをやったほうがトータルのアウトプット量も多かったことが容易に想像がつく、という内容の指摘でした。この問題については次章で考察します。

個人の感想と考察

以下は個人の主張・感想であり、所属する組織・チームとしての意見ではありません。

考察：「生産性」~モブプログラミングは “早い” のか~

まずはじめに明確にしておきたいのですが、モブプログラミングはチームで行う開発プロセスの一環であり、ペアプロのような単なるコーディングスタイルではありません。チームとしての意思決定の速度と精度の向上、コミュニケーションコストの低減が価値とされる環境において初めて効果を発揮する手法であり、単体の機能開発においてスポットでモブプログラミングを実施した場合の生産性のみを比較して論じることにあまり意味は無いと考えます。

モブプログラミングの「生産性」については、Mob Programming A Whole Team Approachの８章 # 8. PRODUCTIVITY でも論じられています。

While we feel we have become a great deal more productive working in this manner, there is no easy way for us to prove this is due solely to Mob Programming.

私たちはこの方法で生産性の向上を感じていますが、この要因がモブプログラミングのみであることを証明する簡単な方法はありません。

として、ソフトウエア開発に於ける生産性の定義の難しさに触れながら、モブプログラミングの画一的な導入や流布には慎重な姿勢を取っています。しかしながら、彼らがモブプログラミングを行う上での生産性についての立場は明確で、

While productivity is important, it is not more important than working on the right things

生産性は重要ですが、それは正しいことに取り組むことより重要ではありません。

とあり、なるほど確かにと思いました。正しいことを最速で行うための一つの解として、フィードバックループの時間を最小化する、というソリューションを取るとモブプログラミングになる…のかもしれません。

というわけで、再掲になりますが、モブプログラミングは「早い」のかという問いに対する個人的な見解は「従来の手法と生産性のみを比べることには意味がない」となります。

考察：スポットでモブプログラミングを実施する恩恵

先に述べたように、モブプログラミングは開発プロセスであり、スポットでの実施に留まる場合はその本来の目的の達成や効果を得る事は難しいといえます。ですが、今回実践してみて、スポットでの実施でも以下の点でメリットが出るケースがあると感じました。

リードタイム（特定機能のリリースまでの時間）・スループット（チームの単位時間あたりのアウトプット総量）
技術・仕様の伝播

1. リードタイム・スループット

まずスループットについてです。リードタイムは単一機能の実装であればチームのスループットが大きい方が短くなるので、スループットについてのみ考察します。モブプログラミングでは、Driverは、Navigatorの指示を理解して最速で実装を進めることのみにフォーカスします。コーディングの手がとまってしまう障害を取り除くのに必要な思考リソースをNavigatorが肩代わりしてくれるため、純粋に必要な機能を実現すること自体に最大限の集中と能力を注ぐことができます。

このメリットは実際に自分がDriverでコーディングしているときに感じることができました。ビジネス的な問題やチーム内のコード規約のような社会学的な問題を考えるためのリソースが開放されて、純粋にコードを生み出すことのみに集中できました。

さらに、Driverはタイマーによって強制的にローテーションされるため、集中力が切れる前に交代できます。つまり、チームとしての成果が常に個人の最大集中度でアウトプットされる状態となります。個人でこれを行うことはたとえ定時８時間内であっても不可能です（※陶山調べ）。わかりやすくドラゴンボールで例えると、チーム全体として「精神と時の部屋に入ってずっと超サイヤ人」みたいな状態であるといえます。わかり易くなかったですごめんなさい。

このgifのほうが分かりやすかったです。

MOB PROGRAMMING CONFERENCE – Mob Programming Getting the Best ここから拝借しました。

つまり、一つの機能について

個人の単位時間あたり出力の平均 × チーム人数 × 時間 - プルリクエストなどレビューのコスト＜個人の最大集中状態での単位時間出力 × 時間 - スイッチングコスト

の条件が成り立てば、モブプログラミングのほうがチーム全体で高いスループットになるのではないでしょうか！

…この条件をみたすために今回一つ大きな障害となったのが、前述したPC変更によるドライバーのスイッチングコストです。ある程度は仕方ないと考えていましたが、予想以上に高かったです。

ただでさえ20分しか実装できる時間がないのに、ドライバーが変更される度にその人のマシンで

さっきまで実装してたファイルを開く
ローカルサーバー起動する
push / pullする、マージする
ショートカットのキーバインドが変更されてて教えられない

etcetc…みたいな実装と関係ない作業に数分取られてイラッとします。スイッチング時のコストを最小限にするためには、やはりマシンは同一のものを利用するのが望ましいです。

働き方・チームの多様化が叫ばれる昨今、逆説的に

どんな環境・エディタでも最大限にパフォーマンスを発揮できる
デフォルト設定で戦える

スキルが必修、なのかもしれません。私は今回の実施で、JISキーボードでキーコンフィグやショートカットを自己流に変えまくっている自分の環境を反省しました。

まとめると、「周到に準備されている等の条件が整えば、開発プロセスとしてモブプログラミングを採用していない場合であっても、スループットの向上という恩恵を得られる可能性がある」となります。

2. 技術・仕様の伝播

次に技術や仕様の伝播についてですが、とにかく低コストに・かつ高速にこの目的を達成できます。メンバー間で技術スキルや仕様理解度に大きな隔たりがある場合は継承、特定の得意分野を持つ集団である場合は相互作用によるスキルトランスファになるわけですが、どちらの場合でも同様に機能すると考えられます。

というのも、モブプログラミングでは機能実装を行うこと自体に技術と仕様の伝播を内包するため、実質これらのコストがゼロとみなせるためです。

技術については環境を晒してのライブコーディングがとにかく強力です。目の前で起こっていることは説得力と情報密度が違います。わざわざ教えようと思わないであろうTipsなど、本当に多くの気付きがあります。長く同じメンバーでチームが構成されている場合でも、環境を晒す機会やライブコーディングする機会はめったにないと思うので、必ず新しい発見ができると思います。

この点については、むしろスポット・経験浅での実施のほうが（実施前との差分という意味で）高い効果が得られるはずです。

仕様についても同様で、自分が実装担当する機能と付随する既存仕様の議論をリアルタイムに行える場合の情報量と理解度は、何十何百のドキュメントに勝ります（ドキュメントがいらないと言っているわけではありません）。ドキュメントのような一方向のコミュニケーションと、相互作用である議論やコミュニケーションとでは情報伝達の質・量ともに後者が優るであろうことは言わずもがなです。

これもスポット・経験薄での実施のほうが高い効果が期待でき、特にチームメンバ間で仕様理解度やスキルに乖離がある際に、威力を発揮するのではないでしょうか。

まとめると、「リアルタイムなインタラクション以上の情報伝達手段はなく、この点においてモブプログラミングは最強の方式であり、スポットでの実施であってもこの恩恵をうけることが出来る」となります。

考察：モブプログラミング導入の障壁

モブプログラミングはその思想・方法論から、明らかに

「小さなフィーチャーを、短いリードタイムで出荷する」

ことに特化した手法です。

これは言い換えると、モブプログラミングが十分にその威力を発揮するには、実施する開発チームにおいて

開発プロセスが仮説検証型であること（短いプロセスで設計と出荷を繰り返していること）
稼働率よりリードタイムを重要視していること

上記を是とする文化が前提として必要である、と言えます。私の知りうる限りで「開発プロセスにスクラムを採用していること」は十分条件であると言えそうですが、アジャイル・リーンな思想が根付いている組織と相性が良いことは明らかかと思います。

ここで言う「組織」とは、開発チームのみならず、ビジネス・顧客含め説明責任のある全てのステークホルダーの集合を指します。

モブプログラミングでは、チームメンバー全員で1つのタスクに取り掛かるため、必然的にアクティブなタスクの並列度が１となり、稼働率を「タスクの総見積り時間／割当たっているメンバーの総空き時間」と定義※した場合に殆どの場合で100%にならず、外部的に見ると「タスクにアサインされていないメンバーが居る」とみなされてしまう恐れがあります。 ※厳密ではないですが、一般的な現場での使用法から大きくは外れないと思います

稼働率について、少なくとも今までに私が経験してきたソフトウェア開発の現場では「稼働率100%」が是とされることがほとんどでした（「あの人は今何のタスクをやってるんだっけ。」）。

開発チームにすら、稼働率を戦略的に100%にしないことに対して「実感として受け入れがたい」「余裕を持つことに後ろめたさがある」という強い負の精神的バイアスがあるように思います。

これはソフトウェア開発現場に根強く残る人月計算の弊害とも考えられますが、とにかく、この稼働率問題はモブプログラミングの導入において大きな、おそらく一番の障壁であると考えます。特に開発チームの意思決定者においては、ビジネスメンバ・エグゼクティブクラスへの説明責任を果たすという点において困難があろうことは容易に想像できます。

この問題に対する画一的なソリューションはない…ように思われるのですが、いくつか挙げるとすると

開発チーム以外のステークホルダーには、プロセスと成果を切り離して報告・議論する
- ステークホルダーとの信頼関係と、開発プロセスについての意思決定件の移譲が大事
- エグゼクティブから「あいつはチームを守っている」と思われないようなさじ加減が必要
開発チームには、稼働率を100%にしないことの意図と安全性をまず浸透させる

といったところでしょうか。私が不勉強なだけで、もっと良いやり方があるような気もします。

なお稼働率とリードタイムの話はエッセンシャルスクラム 3章、特に「作業者の手待ちではなく、作業の手待ちに注目せよ」に詳しいです。稼働率を100％にすることは損害である、と明記されています。

この問題は現実のソフトウェア開発の現場においてまだまだ超えなくてはならない壁、といったところではないでしょうか。

まとめ

前述したように、モブプロで既存スキームと同等以上の成果を出すにはいくつかの前提条件が必要であると考えます。ですが、今回のLODEOの例のようにスポットで実施したとしても、スキルトランスファやドメイン知識の共有でメリットが得られると感じました。

何よりモブプロすること自体がとても楽しいですし、新たな気づき・発見が得られたり、チームの結束をより深める結果となったと思っています！

モブプロ気になっている方、許可より謝罪、挑戦無くして成功なしの精神で、まずやってみてから考える、のも大切ではないでしょうか。

Enjoy Mob Programming!!

参考

AbemaTVで機能がユーザーに届けられるまで。

FRESH! における Web プッシュ通知機能〜実装編〜