フロー効率重視のモブプロ・チーム開発制施策の振り返り

# 概要
リソース効率重視の1人1タスクの体制から、フロー効率重視の3人×3チームの体制に変更した際の、解決したかった課題、やってみてどうだったかを書きます。上長の許可を貰ったので実測値も少し載せてあります。

# 対象読者
複数名の開発組織で、以下の課題に心当たりのある人

### 課題
* レビューがなかなか進まず、不確定な待ち時間が発生する為にリリース日が確約できない
* インシデント等の突発的な事案で、プロジェクトが遅延してしまう
* 大胆なリファクタリングに挑戦出来ない
* 知識が開発担当者に属人化する
* 新入社員のシステムの知識獲得のコストが高い
* 体制の変更について上司を説得したい

# 何をやったか
少し前に「[フロー効率性とリソース効率性について](https://www.slideshare.net/i2key/xpjug)」という、黒田さんというリクルートの方のスライドが社内で注目を集めました。これは機能リリースまでのリードタイムをできるだけ短くし顧客への価値提供やチームの学びのサイクルを速く回すこと、これは稼働率100%のリソース効率を高めるより良いのではないか、というものです。

もう少し噛み砕くと、人が空いているときにタスクを割り当てることは一見すると効率的に見えるが、ウェブのモノづくりの世界で「ユーザーに価値のあるものを迅速に小規模に提供し、フィードバックを得る」という視点からは、実は非効率だよね、というはなし。

我々のチームでは、「[モブプログラミング](https://zenn.dev/mossan_hoshi/articles/20230613_mob_programming)」を採用し、3人×3チームの体制に変更し、上述の課題に対して解決を試みました。

* 変更前
  * 各自がプロジェクトに関わるタスクを並行して進行する
  * 障害やトラブルが発生したら、適任者が対応にあたる
* 変更後
  * 3人×3チームで「モブプログラミング」で1つのプロジェクトを進行する
  * 障害やトラブルが発生したら、適任者がチームを抜けて対応にあたる

![teams.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87716/563215f3-342d-81db-c0b1-3fa95203328a.png)


# どうだったか
#### レビューがなかなか進まず、不確定な待ち時間が発生する為にリリース日が確約できない、のその後
我々のチームでは品質のために2人のレビューと承認(Approve)を必須としています。
自分のタスクを抱えている状態で、どうしても他人のレビューの優先度が下がったり、コンテキストスイッチのコストがかかり、レビューが進まず「レビューが通り次第のリリースとなります」という、完了日を担当者自身でコントロール出来ない状態が常態化しており、プロダクトマネージャーとの信頼関係において課題となっていました。

モブプログラミングでは、設計、実装、テスト、レビュー、リリースまで同期的にその場で完了していくので、理論的には「レビューにかかる時間」はゼロとなります。

[merged-pr-stat](https://github.com/shibayu36/merged-pr-stat)というツールを使わせて頂き測ってみたところ体制を変更した2021年頃から、PullRequestのレビューにかかる時間がおおよそ半分になったことを確認しました。

* leadTimeSecondsMedian = 最初のコミットからマージまでの秒数の中央値
* timeToMergeSecondsMedian = PullRequest作成からマージまでの秒数の中央値

![review-leadtime.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87716/f9eab15a-1b79-d0a2-14f2-64d540527e05.png)

実際には、チーム外の個人タスクが多少発生したり、リリースを翌日にまわす、などがあるためゼロにはなりませんでしたが、チーム作業をする中で体感としては「レビュー時間」は存在しなくなりました。

一方で、スピードを上げたため、別の問題として「視点が狭まり抜け漏れや見落としによるバグ」が発生しやすくなってしまいました。そのため意図的にPullRequestを寝かせたり、異なるプロジェクト間で「チーム間レビュー会」を週に数回実施することで、スピードと品質のバランスを取るようにしていきました。

#### インシデント等の突発的な事案で、プロジェクトが遅延してしまう、のその後
今までは、突発的な事案が発生した際は、いちばん詳しい人など適任者が都度抜けて対応にあたっていました。障害だけではなく、顧客からの問い合わせに伴う調査も含めると、頻度はそれなりとなっていて、その都度、不確定な期間でタスク進行が停止していました。

モブプログラミング体制ではチーム全員で同じことをやっているため、チームから１人抜けてもプロジェクトが停止することなく進行でき、計画をコントロールしやすくなりました。

ただし、インシデント対応のような緊急かつ心理的な負担が高いものに関しては、"ひとり" というわけに行かず、チームで取りくんでもらい、プロジェクト進行を止めたこともありました。これもバランスですが、全体としては以前より計画のコントロールが可能になりました。

#### 大胆なリファクタリングに挑戦出来ない、のその後
「本当はやるべきだが、スケジュール遅延やバグ混入のリスクを考えてそっとしておこう...」となりがちな少し挑戦的なリファクタリングについても「チームで取り組む」ことで、心理的な安全性が増し実施される量が増えました。

これは、[gilot](https://github.com/hirokidaichi/gilot)というツールで、コードの追加行数と削除行数の両方の数値が向上していることが分かったため、そのような傾向に変化したと判断しました。加えてシニアエンジニアが主導して「機能実装前のお掃除」をしてくれることも実際に増えていました。

![before.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87716/df023e06-972c-4dfc-cf76-7c4e73f4bbba.png)

![after.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87716/760dbf64-a393-7d07-afba-14e3f2b2d5f6.png)

#### 知識が開発担当者に属人化する、新入社員のシステムの知識獲得のコストが高い、のその後
約10年経っているサービスのため、システムが複雑化し、開発者が覚えなければいけない知識領域がとても増えていました。

チームで取り組むことで「属人化」リスクを多少軽減できたのではないかと考えています。一方で「属チーム化」という別の問題も発生してきます。

上述の「チーム間レビュー会」の際に、関わっていない別のチームメンバーに「背景や実装内容」などが伝わりやすい説明を行うよう心がけることで、属チーム化の軽減に加え、自分たちも改めて理解出来ているか確認することや後世にドキュメントとしても残る、という副次的な効果も狙っていました (これに関しては数値に現せず...)

#### 体制の変更について上司を説得したい
「9人にお願い出来ていたことが、3つになるの!? 効率落ちるでしょ」という話にほぼなると思います。我々は自社サービスで、周囲の理解もあるので「とりあえずやってみよう」が通用しましたが、やはり数値で確認しておくことの必要性は感じています。リンクしたツールなどを使って傾向を見ておくことで「少なくとも効率は落ちて無さそうだが、メリットは多いので継続しよう」という判断材料にもなるかもしれません。


# 気をつけたこと
* 理想、予想通りにはいかないので、バランスを取りながら継続的に調整する必要がある
  * 一方を改善すると他方で問題が発生することはしょっちゅうなので、その都度チューニングしていく必要はあります
  * あまり理想にこだわりすぎると危険です  
* 数値はひとつだけで判断しない、評価にも使わない
  * どれかひとつの数値を見て結論を出せないので、長期で複数見て「傾向や仮説に使う」くらいがちょうどいいです
  * 本記事で添付した画像も特徴的な時期を載せており、実際には時期によってプロジェクトの性質にも大きく左右されていました 
  * 本質ではない心理状態を作り出さないためにも、評価指標(特に個人!)に使うのはやめた方が良いと考えています
  * 実際にチームメンバーに実状をヒアリングするのも大切です

# おわりに
最終的な目的である「ユーザーへの価値提供」に対して、開発チームの組織力をどう測るのか、引き続きテーマになりそうです。

# 参考
* [フロー効率性とリソース効率性について](https://www.slideshare.net/i2key/xpjug)
* [開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った](https://qiita.com/hirokidaichi/items/ceece347f808cc9d14dd)
* [PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた](https://qiita.com/hirokidaichi/items/ceece347f808cc9d14dd)
* [モブプログラミング入門](https://zenn.dev/mossan_hoshi/articles/20230613_mob_programming)