私のチームは週の数時間をモブプログラミングに割り当てています。楽しみながら開発でき、しかも開発フローにまつわる悩みが解消されてとても良い感じです。

ただ、始めから上手くできたわけではなくて悩みもいろいろありました。その解決の糸口となったのが「モブプログラミング・ベストプラクティス」でした。

そこで今回はこの本の内容と感想、そして体験談をまとめつつ、モブプロを始めてみようと思う人・始めてみたばかりの人にモブプロの魅力を伝えてみようと思います！ レッツモビング！

モブまたはモブプログラミングとは？

本の中の言葉を借りるなら「チームで一緒に働く」ことがモブです。チームで一緒にひとつの開発をすれば、それはモブプログラミングです。

……こう考えて取り組むようにしたら、肩の荷がおりた感覚があったことを覚えています。チームメンバーにモブプロをしようと提案した手前うまくモブプロしていかねばと気を張っていましたが、やり方・進め方も含めてチームで一緒に決めていこうと気持ちを持ち直した記憶があります。

なぜモブプロをするの？

モブプロの良さはフロー効率の良さにあります。なので一緒にモブプロをしてもらうメンバーには、フロー効率とは何なのかを理解してもらい、フロー効率を良くしていこうという共通認識を持ってもらうと良さそうです。

リソース効率とフロー効率の違い

リソース効率とは「リソースの空きがいかに少ないか」です。チームメンバー全員が休みなく働いている状態、つまり稼働率100％の状態だと、リソース効率が良いといえます。

対してフロー効率とは「着手からリリースまでの時間(リードタイム)がいかに短いか」です。フローとは「流れていること」を指しているので、どの期間を切り取っても常にアウトプットがなされている状態だと、つまり案件が短い期間でリリースを繰り返せている状態だと、フロー効率が良いといえます。

リソース効率を追求した考え方では「どれくらい多くの機能を詰め込めるか」と考え、フロー効率を追求した考え方では「どれくらい細かく刻めるか」と考える傾向があります。後者は変化に強く、アジャイルな考え方にも通じるわけですね。

フロー効率を良くしていくためのモブとは

モブはフロー効率が良い手法です。それがわかる側面として

  • 全員で課題に取り組むのでスペシャリストは生まれず、ゼネラリストが生まれる。結果的にキーパーソンへの依存度が下がり、一人が欠けたときの影響が下が少ない
  • 全員で課題に取り組むので、スキルや考え方や知見を共有し合う機会が多く、各々のスキルアップが早い
  • 集団で取り組むことで判断がより良くなり、品質の大きな欠陥が減る。ちなみに優秀な一人より3人の集団のほうが良い決断ができることが科学的に検証済み

といったことが挙げられます。

つまり複数人でひとつの案件や課題に取り組むモブプロは、長期に渡って保守・改善していくプロダクト開発などのフロー効率を良くしていきたい現場でのGood Practice(のひとつ)というわけです。

モブプロの始め方

モブプロの準備

モブプロを始めるにはいくつか準備が必要です。なんせ複数人が同時に、そして快適に仕事する必要があるので、それなりの準備をしておかないとですね。

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

モブプロの登場人物と役割

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

モブプロの進行

トライアルに向いている2時間半のモブプロの例を挙げます。

  1. 準備(30分)
    • モブプロの意義の説明
    • モブプロの役割分担の説明
    • モブで解決する問題の概要の説明
    • タイピストの順番決め(ランダムでも可)
    • おやつの配布
  2. モビングインターバル(1.5時間程度)
    • 10分〜20分毎にタイピストを交代していく
    • 途中で休憩をはさんでもOK
  3. ふりかえり(20分)
    • 事実をもとに成果を振り返る
    • 肯定的意見、否定的意見を集める
    • 軌道修正するべきことを決める(次回試す)
    • 必要に応じて、今後も継続していくか決める(どちらでも可なら継続しましょう！)

モブプロの心がけ

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

モブプロの成果の測り方

モブプロの成果がひと目で判断できる基準はなくて、計測が難しいのが実情です。ただ、明確にやってはいけないのは「短期間のアウトプット量で成果を測ること」です。先述の通り、フロー効率の考え方は「いかにリードタイムを短くリリースを繰り返せるか」であり、「1度のリリースにいかに詰め込めるか」ではないからですね。

とはいえ、何かしらの方法で効果測定する必要がありますよね。ですので、いくつか影響のある指標を挙げてみます。

  • リードタイム
  • マージコンフリクトの解消にかかる時間
  • 本番システムに入り込むバグの量
  • 経験の浅いメンバーの学習度
  • レビュー時間、レビューの待ち時間

これらを総合的に見て、成果の有無を判断するのがオススメです。

よくある悩み

エキスパートがいる場合にうまく進行するには？

エキスパート(ベテランエンジニア)がいること自体は問題ではないですが、以下のような副作用に注意する必要があります。

  • エキスパートがタイピストのとき、エキスパートが一人で作業を進めてその他のモブが眺める(従う)だけになってしまう
  • エキスパートがその他のモブのとき、エキスパートのみが発言する状況になってしまう
  • 上記のような状態が続き、エキスパートでない人が発言しにくく感じてしまう
  • エキスパートがその他のモブに教えるばっかりの状態になってしまい、それをエキスパートがストレスに感じてしまう

こうならないためのひとつの方法として、「エキスパートにモブプロのファシリテーターになってもらう」というのがあります。エキスパートは例外的に常にその他のモブになってもらい、メンバーに質問や発言を促したり、メンバーが理解できていない箇所をフォローして回ったり、といった役割を担ってもらう方法です。

モブプロは短期的に開発物を仕上げる手法ではないので、「モブプロがうまく進行しエキスパートの暗黙知がチームに浸透すること」をエキスパートの目標にしてもらうよう事前に説得しておくことも大切です。

新人や知識のない人がいる場合にうまく進行するには？

モブプロには、ドメイン知識の有無はあまり関係ありません。新人さんも巻き込んで一緒にモブプロをしましょう！

オススメの進め方は、ドメイン知識が少ない人にタイピストになってもらう方法です。 タイピストの役割に「理解する」と「質問する」があったように、分からないことがあったときに手を止め、質問し、自分の(そして場の)理解を深めるよう導くことでチームに貢献することができます。

そして、タイピストやその他のモブが質問しやすい環境を保つことが、各メンバーの責務となります。

手探りで進めていく案件の場合にうまく進行するには？

誰も試したことがなく、どこから手を付けてよいかわからない状況になり得る課題に取り組む場合、「個々で調べる時間」「個々で考える時間」が必要なケースがあります。その場合は時間を区切ってモブを中断しその場で各々が作業するのもOKです。本の中では「タイムボックス付きの探究」と呼んでいました。定めた時間が経過したら成果を共有しあい、モブプロを再開しましょう。

アンチパターン

「その他のモブ」のアンチパターン

まだコードで表現されていないことを議論すること。同様に、タイピストがまだコードで表現されていないことについて質問すること。

コードで表現されていない状態では「検証」ができないのと、その他のモブ全員が同水準で状況理解できない可能性があります。なのでまずタイピストへコードで表現することを依頼し、それを見ながら議論するようにしましょう。そうすることで議論が理論的なものから実践的なものに変わっていきます。

もしコードで表現したいアイデアが複数出てしまい、タイピストにどれを依頼するか迷ったときは、一番単純なもの(はやく検証できるもの)を採用すると良さそうです。そうすることで「コードを見ながら議論する」というモブプロの土俵に上がれます。

「タイピスト」のアンチパターン

こっそり自分のコードを書き込むこと。または勝手に自分の意志で進めること。

キーボードに触れる人は、誰よりも自由に自分の考えを暗黙的にコードに反映できます。それをやってしまうと、上のアンチパターン同様にその他のモブ全員が同水準で状況理解できなくなります。

もしタイピストがアイデアを持っている場合は、自分がその他のモブの番になるのを待つか、その場でタイピストを交代する等し。その他のモブに回ってからアイデアを出すようにすると良さそうです。

ハッピーモビング

「モブプログラミング・ベストプラクティス」にはモブプロの初心者・中級者が従うべきプロセスがまとめてあります。プロセスに従ったほうがスムーズに進むケースが多いと思われますが、ルールを守ることが絶対ではない、とも書かれていました。

振り返りを通じてチーム全員でモブプロを改善しながら、チームに合ったモブライフを送っていきたいですね！ ハッピーモビング！