SRE兼スクラムマスターのブログ

チーム開発が好きなエンジニアブログです。検証した技術やチームの取り組みを書いていきます。

モブプログラミング を2年間続けて気づいたこと

モブプログラミングを始めてから2年ほど立つが、この2年間の間でチームが3回ほど変わっている。 チームの形成期から機能期まで何度か経験したおかげで、 その時々でモブプログラミングを行っている経緯が違うことに気づいたので、まとめておこうと思う。

モブプログラミングとは

簡単にまとめると「チーム全員でペアプロする」みたいなこと 2014年にWoody Zuill氏がAgile Allianceで発表されたMob Programming A Whole Team Approachが原著になる。

www.agilealliance.org

環境

  • チーム規模:4~6人
  • 場所:比較的大きなモニターがある部屋、スペース
  • PC:作業用のPC1台、各自調査用のPC
  • 内容:要件定義、設計、開発(TDD)、ドキュメント作成、バグ修正など
  • ツール:

Mobster

モブプロ用のタイマー。(ペアプロMTGでも効果あり) github.com 一部動作しないPCもあったのでその場合は下記のサイトを利用するのもおすすめ。 agility.jahed.dev

Visual Studio Live Share

VSCodeで複数人でコードの編集・デバッグが行える拡張機能。 複数人で同時にファイルを編集できる。ファイルの移動、プロジェクト内検索も可能 ホストマシンのローカルサーバーをシェアし、ゲストマシンからブラウザでアクセスすることができる。 ホストマシンのターミナルをシェアし、ゲストがコマンドを実行することができる。

visualstudio.microsoft.com

モブプログラミングの経緯と成果

ここではチームの成長に伴う、モブプロを行った経緯とそのときの結果をまとめていく 少し特殊な条件として、個人で行っていたプロダクトが人数が増えてチームになっているので 初めからナレッジが多いメンバーがいる。

経緯

チーム形成期

  • オンボーディング
  • メンバー間のプロダクトに対するナレッジ差が激しい

チーム混乱期

  • コードレビューやレビューの取込みにやたら時間がかかる
    • いつまでもマージされないプルリクエス
  • チーム形成期にふわっと決めたルールにひずみが生まれ始めた
    • ルールの理解がメンバーによってマチマチ

チーム統一期

  • プロダクトスキルやナレッジが偏ることでタスク担当者に偏りがでる
    • バス因子の増加

チーム機能期

  • 設計の背景や意図を伝えるのに時間がかかる
    • ドキュメントを作成してみたが作成に時間がかかり、かつ保守が大変
  • 開発チームで決定したことを顧客に合意を得るまでに時間がかかる
    • プロセスタイムは短いけど、リードタイムがやたら長い

成果

チーム形成期

  • オンボーディングに必要な形式知を作成できた
    • オンボーディング対象の人と一緒に作るため一方的なドキュメントではなくなった

チーム混乱期

  • コードレビューの観点を統一出来るようになった

    • 指摘事項もその場で全員で修正するのでそのままマージされる
    • プルリクエストが溜まらない
  • 暗黙知のすり合わせが出来るようになった

    • 必要に応じて暗黙知形式知に変換できるようになった
      • 全員で作成するドキュメントなので後々も保守される

チーム統一期

  • スキル共有することで相互理解が深まる

    • 有識者:スキル共有することで理解を深める
    • 初心者:スキル共有され且つ実際に手を動かしていくので理解を深める
  • 保守体制に心理的安全性が生まれた

    • この機能で問題が起こったら○○さん!状態から脱出できた

チーム機能期

  • PdMとのコラボレーションにより共通言語が出来、プロダクトのブレが少なくなった
    • 都度、確認および決定が出来るのでリードタイムが短くなり素早く価値を提供できるようになった

まとめ

2チームで1年ずつモブプロに取り組んだが、ふりかえってみると その時々でモブプロを導入している経緯は概ね同じようなものだと分かった。 成果としても導入する経緯に対して課題を解決出来ていることが多いので非常に効果的だと感じる。

モブプログラミングの課題とカイゼン

モブプログラミングの経緯と成果の内容だけ見ると モブプロ最高とかモブプロやろう!!みたいな感じになるかもしれないが、もちろん全て順調に進んだわけではない。 ここでは、私たちのチームが失敗したこととカイゼン内容についてまとめる。

生産性が低いと指摘される

課題

これは多くのモブプロ実践者の方が通過するであろう課題で、私は「生産性おじさん」問題と呼んでいる。 管理する人から見れば、シングルスレッドでタスクを行うよりマルチスレッドで行う方が 効率的だし、生産性が高いと指摘された。ちなみに私たちのチームでは、チームメンバーからも同様の声が上がった。

やったこと

私たちのチームでは実際にモブプロとソロプロの「開発時間」と「テストによる手戻り」と「デリバリー後の保守工数」を指標として 数スプリントデータを取って比較した。結果として、「テストによる手戻り」と「デリバリー後の保守工数」でモブプロがソロプロでやるときに比べて 格段に低くなっているとわかったので、総合的に見て有用であること証明してモブプロを理解してもらった。

ただ漠然とモブプロしていた

課題

モブプロに慣れてきて、形骸化してしまう状態のときにぶつかった課題である。 PdMにも認めてもらいモブプロのやり方も慣れたが故に、その作業に対して本当にモブプロが必要かどうかを 考えずに漠然をモブプロをしている状態だった。 この状態に陥った時はモブプロ本来の良さであるスループットの速度も落ちて全員で悶々と悩んで1日消費してしまうこともあった。

やったこと

この問題に対しては自分たちのモブプロについてしっかりふりかえってみた。 モブプロに対して理解していない部分が多いことが分かり、チームでモブプロについて学習しなおした。 学習の中で自分たちのモブプロルールを作成した結果、しっかり目的意識をもって作業し成果を出せるようになった。

参考までに自分たちのモブプロルールを載せておく

  • 1日の上限時間

    • モブプログラミングによるコーディング: 2h ※コーディング作業に限る
  • 人数上限

    • モブプログラミングによるコーディング: 3名 ※コーディング作業に限る
  • フロー

    • 目標を決める
    • タスクの全体像のすり合わせ
    • mobsterを使って交代する
    • ふりかえり - 15 min
    • その後の作業分担
  • 組み合わせ

    • スキルシートを作って、チームの状態を可視化しておくこと
    • 熟練者 : 熟練者

      • 品質を向上させたい
        • コーディングの書き方
        • テストケースの提案
      • 心理的に安全になりたい
    • 初心者 : 熟練者

      • 情報共有/ノウハウ伝授
        • コーディングの暗黙知を共有
        • 知識を共有してオーナーシップを持ってほしい
          • 責任感を持ってもらう
      • ノウハウを伝授される側は知識が疎い分野に対して教えを請いたい
      • やったことがないタスク
        • オンボーディング

ちなみに、上記のルールはあくまで自分達のリズムで仕事をするために 最適だと思っているルールなので何が正解などは特にないと思う。 かつ、チームの成熟度が上がると自然の応用できるようになるので あくまで目安程度のものとして考えた方が良いかもしれない。

メンバーのスケジュール調整が大変だった

課題

これは環境特有の問題な気もするが、ぶつかるチームもあると思うので書いておく。 私たちのチームではメンバーが複数のプロジェクトにアサインされているケースが多く全員が100%集中できる状態ではなかった。 本来であれば、プロジェクトを減らすなど対応を取りたいところだが、重要なプロジェクトもあるのでそれが出来なかった。 その場合、各プロジェクトの定例MTGなどがバラバラなため、関係者を集めるのが非常に困難な状態になっていた。

やったこと

自分たちのモブプロルールでも書いたが、スプリント毎に当プロジェクトに避ける割合が低いメンバーは 一時的に他プロジェクトに集中してもらう方法を採用した。つまりスプリント毎にキャパシティを変更したのである。 これにより、特定の作業に集中できるのでスケジュールも合わせやすく、調整コストが軽減できた。

リモートが多いとシンドイ

課題

これも環境特有の問題な気もする。 チームメンバーが在宅ワークをしていることも多く、同じ部屋で同じPCを使って行うというのが難しかった。 物理的に同じPCを使うのも困難だし、同じ部屋で参加しているメンバーに対して温度差があると感じた。

やったこと

リモートが多い問題については2つのカイゼン策をとった。 1つめはツールの力を活用することだ。私たちのチームでは「Visual Studio Live Share」を使って物理的な問題を解決した。

Visual Studio Live Share

VSCodeで複数人でコードの編集・デバッグが行える拡張機能。 複数人で同時にファイルを編集できる。ファイルの移動、プロジェクト内検索も可能 ホストマシンのローカルサーバーをシェアし、ゲストマシンからブラウザでアクセスすることができる。 ホストマシンのターミナルをシェアし、ゲストがコマンドを実行することができる。

visualstudio.microsoft.com

2つめは、リモートのドライバー率を高くしたことだ。 そうすることで、参加率が高くなって疑問を発言しやすくなって 同じ部屋で参加しているメンバーとの温度感をそろえていくようにした。

めっちゃ疲れる

課題

1日みんなでモブプロするとめっちゃ疲れる。 ずっと考えているし、喋っていることが多いので1人でやるときより遥かに疲れる。

やったこと

疲れる問題に関しては、疲れる原因を考えるとコーディングを挙げるメンバーが多かったので モブプロルールで示したように1日の上限を設けることで自然と解決できた。 集中出来ると感じる時間は人によって違うので回数をこなしてチームの最適な形を探すと良いかもしれない。

まとめ

様々な場面でみんながぶつかると思う課題を挙げてみたが、参考になればと思う。 私たちのチームでもまだまだ課題が多いが日々の振り返りによって徐々にカイゼンされているので 今後も何かあれば追記してきたい。。

総括

2年間続けてきたが、やっぱりモブプロは良いと思った。 数値的に考えるとリードタイムが短くなるとか、ムダな部分がなくなるなどいろんな効果があるのだが 個人的には、失敗する作業を経験してそこから成功体験になるまでのプロセスをチーム全員で 経験できることが一番大切だと感じた。 チームで成功体験できることで一体感が増すし、貢献できる部分が増えてくると メンバーのモチベーション向上にも繋がるので、これからモブプロをやってみようと思う人は是非チャレンジしてみてほしいと思う。

参考

モブプロを学習するうえで参考にした資料です

speakerdeck.com