前提

この記事は社内でモブプロを導入する際に説明用に作った資料です。
これからモブプロを導入する時にちょっとでも役立てばいいなと思います。

モブプログラミング導入目的と効果

導入目的

メンバー間での技術的・事業的知識の共有
- デバッグテクニックや調査のコツ、ノウハウなど個々人で持っている知識を共有する事により、モブプログラミングに参加しているメンバーのスキルや知識レベルを素早く上げる。
コミュニケーションコストの低減
- コーディングからテスト、リリース当の作業間で発生するコミュニケーションコストを低減する。
新規メンバーの教育コスト削減
- 既存メンバーと同じ画面を共有する事により知識等を共有できるため、新規メンバーが一人で考えたり調べたりする時間が削減できる。
- 必要最低限の教育で不足分はモブプログラミングをしながら適切にフォローできる。
特定の個人に仕事が依存する事を防ぐ
- 全員で課題に取り組むのでスペシャリストは生まれず、ゼネラリストが生まれる。結果的にキーパーソンへの依存度が下がり、一人が欠けたときの影響が少ない。
リードタイムの短縮
- モブプログラミングではフロー効率が高くなるため、一つの機能を提供するまでのリードタイムが短縮される。
品質の向上
- 集団で取り組むことで判断がより良くなり、品質の大きな欠陥が減る。ちなみに優秀な一人より3人の集団のほうが良い決断ができることが科学的に検証済み。

リソース効率とフロー効率

リソース効率とは「リソースの空きがいかに少ないか」です。チームメンバー全員が休みなく働いている状態、つまり稼働率100％の状態だと、リソース効率が良いといえます。
フロー効率とは「着手からリリースまでの時間(リードタイム)がいかに短いか」です。フローとは「流れていること」を指しているので、どの期間を切り取っても常にアウトプットがなされている状態だと、つまり案件が短い期間でリリースを繰り返せている状態だと、フロー効率が良いといえます。
リソース効率を追求した考え方では「どれくらい多くの機能を詰め込めるか」と考え、フロー効率を追求した考え方では「どれくらい細かく刻めるか」と考える傾向があります。後者は変化に強く、アジャイルな考え方にも通じるわけですね。

効果計測

マージコンフリクトの解決にかかる時間の短縮
バグの減少
チーム内の経験の浅いメンバーの学習度の上昇

※あくまでも一例です、環境にあったKPIを選択することがよいと思います。

モブプログラミングの始め方

前提

フィジビリティの位置づけとして以下の条件で行う。
回数
- 5回を目標に行う。
時間
- 1回2時間程度
参加者
- メンバー名
対応する課題
- 適当な案件を選択する。
- プログラミングサイトから適当なお題目を選択する。

タックマンモデル

チームは機能するまでに形成期、混乱期、統一期、機能期という4つの段階を経るとする理論で、1965年にBruceTuckmanが初めて提案した。
私たちの仕事の進め方はみな少しずつ異なっており、それらの違いが意見の対立やメンバーの不満を引き起こすことがある。メンバーたちがそういった違いを見つけ、対立を解決し、うまく折り合いをつける方法を見つけていく時期を混乱期と呼ぶ。
モブプログラミングでは、混乱期は人々が作業スタイルの違いに気付く比較的早い時期に始まる。メンバーがそれぞれの仕事をするチームと比べれば混乱期の始まりはかなり早い。
そして、混乱期はスタイルの違いが解決されるまで続く。
混乱期はつらい時期になり得るが、悪いことばかりではない。ものごとがうまく回るようになった時には、混乱期を乗り越えた分、親近感が増し、周囲の人々との理解が深まっている。混乱期のどたばたの度合いを抑えるためには、最初にメンバーをよく知るようにすると良い。モブを立ち上げた時や新しいメンバーがモブに加わった時には、必ず混乱期が起きる。
その事を意識して注意を払うようにする。

モブプログラミングの準備

参加者が窮屈に感じず、平等にモニターが見える空間、会議室
モブの進行や決めごと、TODOなどを書き出せるホワイトボード
モブ用マシン(タイピストの交代でのロスを少なくするのが目的なので、なくてもOK)
参加者全員にとって馴染みのあるエディタ
モブタイマー(できればサブディスプレイなどを用意して常に見える状態にしておく)
- Agility の Mobbing & Retrospective Timer
- Pluralsight の Mob Timer 等

初回のタイムテーブル

この資料を基にモブプロの概要を説明（30分）
モブプロ実践（1時間30分）
モブプロの振り返り（20分）

役割の説明

タイピスト(ドライバー)
- キーボードを触る唯一の人。
- 10分などのサイクルで交代し、原則全員がタイピストになるように回す。
- その他のモブがしてくれと頼んだことを理解する。
- 指示が理解できないときはわかるまで質問する。
- 頼まれたことをコードとして実装する。
- その他のモブを信頼し、自分ではしないような実装も躊躇せず試す。
- その他のモブ(ナビゲーター)
- キーボードを触らない人。2〜5人くらいがおすすめ。
問題解決につながる次の論理的ステップを見つけるために協力する。
- 理解できるまで質問する。
- モブ全体の理解の水準を上げるために貢献する。
- 眼の前の問題に集中する。
- 他のメンバーの意見に傾聴する。
- システムの中に改善すべき部分を探す。

振り返り

事実をもとに成果を振り返る。
肯定的意見、否定的意見を集める。
軌道修正するべきことを決める。(次回試す)
必要に応じて、今後も継続していくか決める。(どちらでも可なら継続しましょう！)
振り返りの手法
- KPT
- YWT
- Fun! Done! Learn!
- シンキングハット

モブプログラミングの心がけ

自分がしないような他のメンバーのアプローチを受け入れましょう！それをコードにし検証することにも意義があります
対立的にならないようにしましょう！モブは「わたしたち」で行うもの。主語は「わたし」や「あなた」ではなく、常に「わたしたち」を意識しましょう
人ではなくコードを批判しましょう！負債に対しても、それを実装した人ではなく実装せざるを得なかった状況と向き合いましょう

グランドルール

1サイクル回ったら5分休憩する。
グランドルールは毎回見直す
あるチームのモブプログラミング風景

※グランドルールは、毎回ふりかえりを行って自分たちに合うものを追加していく

実際のモブプログラミングの風景

参考資料