半年間実施してきたモブプロについて
WEB+DB PRESS vol. 102にてt-wadaさんが執筆されていた記事 『はじめてのペアプロモブプロ』を読んで振り返ってみました。

記事の感想ですが、必要十分な内容で非常に素晴らしかったです 😄

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

WEB＋DB　PRESS　Vol．102【1000円以上送料無料】
価格：1598円（税込、送料無料) (2017/12/23時点)

Table of Contents

はじめに

経緯

読もうと思ったきっかけはt-wadaさんがリツイートされていた下記ツイートを目にしたからです。

会社のチームが半年前からモブプロを推進しているため、振り返る良い機会になりました。

筆者のスペック

JIRAを全社導入した経緯でアジャイルを軽く推進していました。

  • 社会人8年目
  • アジャイル歴2年
  • ペアプロ/モブプロ歴 6ヶ月

モブプロは現プロジェクトのPMが推進しており、私自身も半年前から実践しています。

記事について

本記事では元記事(WEB+DB PRESSの記事)の内容について、以下3点を振り返ります。

  • 紹介されていた内容がチームとして実施できているか
  • 紹介されていた内容が個人として実施できているか
  • 備考

チームと個人の評価方法は以下とします。

  • ⭕ できている
  • ❓ できていないこともある
  • ❌ できていない

本記事は感想であるため、元記事の説明はしません。
逆に言うと、元記事をご覧になった方でなければ伝わらない内容も多いと思います。

気になった方は本を購入して読んでみて下さい。

ペアプロ

前半はペアプロの話です。

ペアプロのメリット

メリットに対する項の内容です。
個人は問題ないと思っていますが、チームは聞いてみないと分からない部分もあります。

項目 チーム 個人 備考
集中力向上 ❓ ❓ 集中できるかは人によるかなと
質の向上 ⭕ ⭕ 品質は確実に上がっている
発話による思考整理 ❓ ⭕ 独り言が苦手な人は躓くと沈黙することも
コードの可読性/保守性向上 ⭕ ⭕ リアルタイムFBによる心理的安全性はGOOD
2人以上の目と脳 ⭕ ⭕ その場での間違い修正でテンポもUP
知識と学びの共有 ⭕ ⭕ 真っ先に感じるメリットの1つ
技術力の底上げと高い教育効果 ⭕ ⭕ 真っ先に感じるメリットの1つ
結果だけでなく過程から学ぶ ❓ ⭕ 個人的には情報の整理方法で実感
コードの共同所有 ⭕ ⭕ 誰かが休みでも滞りなく進む
暗黙知の共有 ⭕ ⭕ ネガティブなイメージが強いが害は今のところ無い

私は個人作業で集中力が切れることは滅多にありませんので、ペアプロによる集中力向上のメリットは実感できませんでした。

ペアプロが再注目される理由

世の中の流れに関する記事と問題点の移り変わりです。
チーム(組織)、個人共に追従できていると思います。

項目 チーム 個人 備考
リリースサイクルの高速化 ⭕ ⭕ 少なくとも数ヶ月単位ではない
クラウドやDevOpsの促進 ⭕ ⭕ 作業は早いけど社内の仕組みはやや複雑かも
並行開発やPRの一般化 ⭕ ⭕ 2014～2016にかけてBitbucketを導入しました
PR渋滞 ⭕ ⭕ PR渋滞の記事は全てに同意できた。。
そしてペアプロ/モブプロへ ⭕ ⭕ まさに今年やりました

ペアプロをはじめる前に

ペアプロといえど、目標とやることを見える化することは大事です。
これを怠るとダラダラしてしまい、集中力が低下すると思っています。

項目 チーム 個人 備考
目標を明確化する ❓ ⭕ 続きから.. と惰性になることも
TODOの作成 ❓ ⭕ 頭の中にタスクを作って進めてしまうことも

ペアプロの作業について

項目 チーム 個人 備考
ドライバは考えていることを口に出す ❓ ⭕ たまに沈黙がある
ナビゲータは傾聴しサポートする ❓ ❌ ドライバが躓くまではあまりできていない
ナビゲータはプログラミングをしている ⭕ ⭕ コードを書かなくても設計を考えられている
ナビゲータが設計をする方が上手く行く ⭕ ⭕ ナビゲータがホワイトボートに書くことは多い
ロールは自然に交代するのが理想 ❓ ❓ 必要に応じて交代しているが長時間になることもある
適宜休憩をする ❌ ❌ 時間オーバーすると早く終わらせたい焦りから..

ドライバのサポートはあまりできていないので今後は意識したいですね。あと休憩。

効果の実感

効果は誰もが実感できています。

項目 チーム 個人 備考
チームに新メンバが入ってきたとき ⭕ ⭕ 凄くメリットを実感する
デバッグや不具合修正 ⭕ ⭕ 視野が狭くなり精神的にも辛いのでこちらも大事
新機能の作成 ⭕ ⭕ 新機能を1人で実装することは無いですね

タイミングと頻度

疲弊するのは同感です。私は午前に各種業務を片付けて、午後に優雅にモブプロしたい派です。

項目 チーム 個人 備考
疲弊するのでやりすぎない ❓ ❓ 多い日は1日中やっているので やりすぎかも?
午前の方がオススメ ❓ ❓ 個人的には午後にゆったりとやりたい

組み合わせ

デキル人を1人は入れることが大事だと思います。

項目 チーム 個人 備考
ベテランと新人は理想 ⭕ ⭕ 教育効果は抜群
ベテラン同士は生産性が高い ⭕ ⭕ ガンガン進みますね
新人同士は難しい ❓ ❓ このケースはやったことないです..

開発環境のバラツキ

ペアプロ/モブプロでは同じマシンを使用するとされていますが、別々のマシンを使用して外部ディスプレイに出力しています。
いくらチームの為とはいえ、マシンを揃えるのはやりすぎだと思っています。

下記は別々のマシンを使用するという前提にした上での振り返りです。

項目 チーム 個人 備考
ハードソフト面での統合 ❌ ❌ これはやりすぎ(と元記事でも)
ノートPCではなく外部モニタを使う ⭕ ⭕ さすがにノートPCのモニタは嫌だ
キーボードは各自繋げる ⭕ ⭕ 各自持参している
IDE環境を統一する ⭕ ⭕ IDEに依存しないよう設定が共有されている
リアルタイム編集可能な開発環境 ❌ ❌ Atom試しましたがチームで実践はしていない

その他のハードル

2割の人はそもそもペアプロ/モブプロを受けつけないとも言われているので、そこが最大のハードルですね。
食わず嫌いの場合は試させるべきですし、試すべきだと思います。

項目 チーム 個人 備考
パーソナルスペースへの侵入 ⭕ ⭕ 各自適当に距離感を取っていると思う
ペアハラ ❓ ❓ １人でやるべでないと思った時に推奨してしまうので…
個人の貢献が分かりにくい ❌ ❌ 会社として今はそういう体制にはなっていない
コードへの愛着が無くなる ⭕ ⭕ 主導者がドライバすることが多いので問題なさそう
ペア以外に知識が残らない ⭕ ⭕ モブプロ主体なので問題なし

ハードルへの対応ができている場合に ⭕ としています。

モブプロ

ペアプロの問題点を解消する方法としてモブプロが紹介されています。

全体

モブプロはペアプロよりも難易度が高いと思います。
チームの環境やメンバが上記を完璧にこなすのは難しいので、適宜フォローが必要だと思います。

項目 チーム 個人 備考
画面 50インチ×2 は欲しい ❌ ❌ 23インチ1画面とストレスが溜まる環境です..
ドライバは独り言が大事 ❓ ⭕ 発言による思考整理と同じ
ナビゲータは調査でドライバを支える ❓ ❌ これも人によりますね
作業時間を最小化する ❓ ⭕ ドライバによっては作業から始まることも

私はナビゲータ時のサポートがあまりできていなかったと思いました。
あまり口出しせずに見守る方針もあるのですが、モブプロの目的を考えると全力でサポートすべきですね。

モブプロの進め方

進め方について踏み込んだ話がされています。

項目 チーム 個人 備考
分散よりスウォーミング ⭕ ⭕ 開始時はなかなかシフトできず苦労しました..
3～5人がちょうど良い ⭕ ⭕ 3～4人でやることが多いのでOK
チーム内で完結させる ⭕ ⭕ 必要な人は直接呼びに行ったりしています
喜びを分かち合う ⭕ ⭕ 期待通り動いた時はチームに笑みが出ます
責任を分散させる ⭕ ⭕ 皆が安心できると言っています
利用者と動くモノでモブする ❓ ❌ プロダクトと人によってはできていないかも
定期的に振り返る ⭕ ⭕ 週1で振り返ってます
成果を顧客が欲しいモノで現す ⭕ ⭕ コンスタントに成果が出ていると思います
大規模チームへの適応 ❌ ❌ まだそのフェーズまで行ってないと思います

大規模チームへの適応は組織の都合もありますが、利用者と動くモノでモブ(その場で開発)はできていないですね。
使い方を共有する場(モブ)はありますが、実際に作業している所に付き添うのは少し抵抗があります。
組織が違うのも理由の1つかもしれません。

楽天の事例

この章はt-wadaさん執筆ではありませんが、楽天での事例が紹介されています。
楽天と同じであるかという観点での振り返りです。

項目 チーム 個人 備考
モニタは20インチ強が2台 ❌ ❌ やっぱり2台は欲しいですよねえ..
Feature Branchはない ❌ ❌ プルリクを出す必要がないのでいらないよねとのこと
本番リリースのサイクルが早い ❌ ❌ 検証へのデプロイは早いですが本番は月数回ですね..
既知の不具合はゼロに保つ ❌ ❌ 個人的には優先度が低いものは後回しでいいかなと
見学を受け入れる ⭕ ⭕ 見学に来る人がいるかは別の話
顧客に会いに行く ⭕ ⭕ 顧客や顧客候補には能動的にコンタクトをとっている
顧客とリアルタイムで協調する ❓ ❓ 顧客によってはできていない
プロセスやツールより対話を重視する ⭕ ⭕ 別組織の相手発信だとツールになることはある
ドキュメントよりも動くモノ ⭕ ⭕ 後から必要なタイミングでドキュメント化もできている
契約より協調 ⭕ ⭕ 価値の無いエビデンスは意識していない
計画に従うより変化への柔軟さ ⭕ ⭕ アジャイルで最も大事な考え方の1つ
詳しくない人がドライバーをやる ⭕ ⭕ 完璧にできる人はやらないようにしている
タスクボードは必要 ❓ ⭕ 頭の中は限界があるので欲しい
目的を達成した皆で賞賛 ⭕ ⭕ 『おおー！！』という感じw

前半のモブプロ環境やリリースサイクルについて、チーム/個人共に改善の余地があるなと感じました。
それ以外の部分は大体できていると思います。

既知の不具合ゼロは『出してしまった不具合には対処しましょう』ということであれば同意します。
『不具合出さないように開発しましょう』はサイクルを回すスピードが低下するリスクがあるため、プロダクト次第かなと思っています。

まとめ

開発環境面を除けば、ほとんどのケースはチーム/個人共に実施できていると感じました。
半年間取り組んできて思うところもありましたが、振り返ってみると自信になりますね。

ただ、足りないと感じたものが3つあります。

モブプロに適した物理的環境

主に以下2点ですね。

  • 圧倒的モニタの不足
  • キーボードをセットできるスペースの不足

開発環境の統合などはやりすぎだと思いますが、モニタとスペースは何とかしたいです。

組織としてのモブプロ受け入れ体制

以下は別組織と仕事をする場合、個人による分散が求められてやりにくいというものです。

  • スウォーミングより分散を求められる
  • Slackでやりとりした方が早いと思い込まれる (そんなことはほぼ無い)

また、評価制度もそれを前提に作られています。(当たり前ですが)

  • 計画通りの遂行を求められる個人重視の評価制度

幸い、会社としてはモブプロを推進しておりますので割と早期に解決すると思っています。

個人としてのナビゲータ力

モブプロの由来通り、モブキャラとして参加していたので以下の意識が弱かったと思います。

  • ドライバの思考や失われた視野をホワイトボードに視覚化する
  • ドライバが疑問に感じたことは即座に調べて解決する

これからナビゲータとして参加するときは特に意識してみます。
ただ、1日中モブの日だと疲れてしまうので、本当にモブキャラとして参加する時間も必要だと思います。(アサインされていないモブとか)