見出し画像

開発組織のフロー/リソース効率性に向き合い続けた1年を振り返る

tobb422

メダップで取締役CTOをしている馬場です。
約1年前に「開発組織と効率性のマトリックス」というエントリーをあげたのですが、今回はその1年後について赤裸々に書き起こしてみました。
「フロー効率」「リソース効率」という概念に向き合い続けた結果、組織としてどういった学習が進んだかをまとめてみます。

(↑↑↑ 元の記事はこちらです)

概念のおさらい

本題に入る前に、今回取り上げる概念について簡単に整理しておきます。
詳しくは、「This is Lean」 という書籍をご覧ください。(私の整理の数億倍詳しく理解できますw)

ソフトウェア開発という文脈で簡易的にまとめると、それぞれ以下のような整理になります。

- フロー効率性が高い状態
  → TODOに入ってからデプロイされるまでの時間が短い(= リードタイム)
  (機能開発がスムーズに行われている状態)
- リソース効率性が高い状態
  → エンジニアが誰もタスク待ち等がなく100%稼働できている
  (エンジニアリソースを余すことなく稼働できている状態)
- 効率性のマトリックス
  → フロー効率の高低とリソース効率の高低を基準に四象限に分類した図
効率性のマトリックスのイメージ図

このテーマを取り上げた前回、開発組織がどういった状態だったか？というと、
まずは1機能あたりのリードタイムを短くすること(フロー効率を上げる)を目標に取り組んでおり、
ある程度フロー効率が上がったなと思ったところで、リソース効率も上げに行くいこうとしているという状態でした。

今回はその先1年間この2つの効率性と向き合い続けたことでどんな学びがあったか？という内容になります。

組織のレベルを数段上げることに成功した 2021.07 ~ 2021.10

まず結論からお伝えすると、
開発組織が発足した2021年1月から約半年間の2021年6月までの生産性と比較すると、フロー効率性の指標にしていたリードタイム/ポイントが約2倍, リソース効率性の指標にしていたポイント/スプリント/FTE(= 1スプリント内でフルタイムエンジニア1人あたりでどれだけのポイントをリリースできているかの指標)が約2 ~ 3倍に伸びました。

この期間の効率性のマトリックスにおける遷移

単純ですが、数字がみるみる良くなっていくので、この期間はめちゃくちゃ楽しかったですw 開発チームの馬力がぐいぐい上がっているな〜という感覚がありました。

実は、この期間はフロー効率性をチーム全体で意識はしていたもののリソース効率性をそこまで意識していたわけではありませんでした。
なので、フロー効率性の向上は狙った結果ですが、リソース効率性の向上は結果そうなったという理解をしています。

具体的に効果があった施策をピックアップしてみます。

This is Lean の輪読会を全員で行う

実際のところ、輪読会を行ったのは 2021.04  ~ 2021.06 であり、この生産性爆上げ期間の前なのですが、
輪読会の効果が顕著に現れたのがこの期間だったなと感じています。
開発組織では、週次で振り返りを回していましたが、その際に如何にフロー効率性を上げるか？という観点で密度濃くディスカッションをできたことがこの結果につながったと思っています。
結果として、Opsの改善やコミュニケーションの取り方を工夫するなど様々な施策が出ていました。こうした施策を打ち続けられた背景には、輪読会を通じてフロー効率性への共通理解を深めることができたというのがあると考えています。

機能ごとにリリースまでのプロセスを可視化する

開発組織伝家の宝刀「タスクマップ」

前述の通り、この期間に数多くの施策を出し続けましたが、その中でも最もインパクトが大きかった施策をこの「タスクマップ」です。
メンバーの1人が提案してくれた施策ですが、このタスクマップによって、機能開発を進める際に必要となるタスクを可視化、依存関係や作業工程のすり合わせが可能となりました。

タスクマップがあることで、どの作業を平行して行えるか？どこがボトルネックになりがちか？を全員でディスカッションしやすくなり、機能を最速でリリースするためにどんな工夫/進め方があるかを模索する型が作れたと思っています。

フロー効率の限界が見え始めた 2021.11 ~ 2022.01

非常に順調に開発生産性を引き上げることに成功していたのですが、さらなる進化を目指して、この期間(2021.11 ~ 2022.01)でもフロー効率性を重視した開発を推し進めることにしていました。

前期間(2021.07 ~ 2021.10)で、平均値としてはフロー効率性が2倍に跳ね上がったのですが、取り扱うバックログアイテム(機能開発)によっては、より高いフロー効率性を実現できていたので、まだまだ開発組織としてポテンシャルを感じていたというのが背景にはあります。
加えて、この期間では開発組織の人数増加があったこともあり、リソース効率性も一定に保つことにも挑戦したいなと考えていました。

結果としては、フロー効率性・リソース効率性ともに約1.4倍と前期から引き続き順調に開発生産性をあげることができた期間となりました。

この期間の効率性のマトリックスにおける遷移

フロー効率性を考えることに対してだいぶ慣れてきたこともあり、1つのバックログアイテム(機能開発)だけではなく、複数のバックログアイテムの関係性やリソース配分に対して組織でディスカッションができるようになっていました。
その結果として、リソース効率性に関してもより高い数値に持っていくことができたのかなと思っています。

今回も具体的に効果があった施策をピックアップしてみます。(1つだけ)

毎デイリーで各バックログアイテムのボトルネックを確認するフローを入れる

各機能開発は、ナマモノのようなもので、絶えず状況が変化します。その変化に対してチーム全体で解決に向けて動けるように、それぞれの機能開発がいまどういう状況なのか？より進捗を出す/ビハインド分を取り返すためにチームで何ができるか？を毎日確認するようにしました。

毎日/毎週の開発の強度がフロー効率性には直結するので、如何に毎週行われるスプリントでやりきれるか？そのためにも毎日どれだけ目標に向き合ったコミュニケーションを取ることができるか？が、非常に大切であると再認識できた期間でもありました。

徐々に見えてきたフロー効率性の限界…

人数は増加しましたが、コアメンバーは前期間から変化しておらず、チームとしての練度が上がっていました。そして、そのチームが絶えず密なコミュニケーションの取りながら開発を進めることができたので、フロー効率性・リソース効率性ともに純増させることに成功したのかなと考えています。

ただ、この期間を詳細に振り返りしていく中で、フロー効率性をいま以上に上げるイメージがあまり持てなくなってきました。。。
その背景としては、この期間で行った機能開発のリードタイム/ポイントのばらつきがほとんどないことや、平均値を上回った機能開発の多くは、ポイントが小さなものであり、これ以上の期間の短縮の目処が見えづらいことなどがあります。

「フロー効率性」・「リソース効率性」ともに低下した 2022.02 ~ 2022.04

この期間で、とうとう開発組織としての生産性はデグレしてしまいます。
実際にこの期間を走りきった開発生産性は、以下のような結果になりました！
リードタイム/ポイント(フロー効率性の指標) → 前期間に比べ約2割低下
ポイント/スプリント/FTE(リソース効率性) → 前期間に比べ約1割低下

この期間の効率性のマトリックスにおける遷移

大前提として、この期間で計測された生産性は、1年前の同時期と比べると数倍改善が回っている状況ではあるので、決して組織としてパフォーマンスが悪いというわけではありません。
実際に、この期間の開発総量は過去最高であり、アウトプットとしては非常に高水準を維持できていると考えています。

そんな中でそれぞれの効率性が意味しているところとしては、人数増加に伴った開発生産性に対する投資対効果の低下です。少し解説入れてみていきます。

開発組織のスケールと投資対効果

人数増加に伴う各指標の遷移

上記グラフは、開発組織を立ち上げてからこれまでの期間の生産性をその期間の平均人数と対応させる形で可視化してみました。

グラフから読み取れる通り、
人数の増加に伴ってポイント/スプリント(1スプリントで出せる開発量)は、増加しています。
一方で、フルタイム換算のエンジニア1人あたりの1スプリントで出せる開発量(ポイント/スプリント/FTE)は、2022.02 ~ 2022.04 の期間で低下しており、エンジニアを1人増やしたときに見込める生産力の伸びが低下していることがわかります。
また、リードタイム/ポイントに関しても同様に低下しています。

ここから医療業界に対してより大きな価値提供を絶えず行っていくためには開発組織のスケールが必須ですが、開発組織がこの規模で既に投資対効果が低下しているようでは、(このままでは)今後の雲行きが相当怪しいといえます。

さらにそれぞれの効率性がなぜ低下していったのか？を深堀りしたところ、以下のような要因がありそうでした。

リードタイム/ポイント(フロー効率性)の低下

これまでは、人数が増えた場合にある機能の開発を分割し並行して進めることができていました。
ただ、こうした機能の並行開発も限界があり、エンジニアの数だけ並行して開発ができるわけでもなく、並行開発によるリードタイムの短縮は既にこれ以上のできない状況でした。加えて、今回に関しては、技術的にチャレンジングな開発も多く存在し、誰でも同じようにこなせるというよりは、解決が個人によってしまったため、結果として平均リードタイムが伸びてしまったと判断しています。

既に非常に高水準までフロー効率性を引き上げられていると考えており、ここからさらに効率性を上げていくためには、如何に使い回すことができるコード/設計を増やしていくか？やwiki等含めて開発作業自体は標準化していくことができるか？がキーになってくると考えています。

ポイント/スプリント/FTE(リソース効率性)の低下

前期間と比較して人数は増加していますが、並行して進められている機能開発の数自体に差がないことが主な要因であると考えています。単に、1機能あたりに投下されるエンジニアが増えただけであって(かつ、だからといってそこまでのフロー効率性も出せていない)、特定の期間で並行に進められる機能開発は頭打ちになってしまっているという状況です。

認知負荷の問題で、同じチーム内でこれ以上並行に機能開発を進めることは不可能であると判断し、並行に進める数に制限をかけたことが原因ですが、これ自体は間違った判断ではなかったと考えています。
仮に並行に進める数の制限をかけなかった場合は、おそらく1機能あたりのリードタイムが伸びてしまい、フロー効率性をより一層下げることになってしまっていたと考えています。
これはなかなか難しい判断ですが、開発組織としてまずはフロー効率性を上げることにこだわってきたこともあり、並行機能開発数に制約を設けました。

これからの開発組織

1チーム10人(FTE)がいまの我々のケイパビリティとしては限界であり、適切な人数は7 ~ 8人ということが1年間のプロセスを経て行き着いた結論です。

今後の会社・事業のスケールを支えられる開発を行っていくためには、もちろん開発組織を拡大させていくことは必須です。
こうした中で、フロー効率性・リソース効率性ともに高い状態を保ったまま開発組織を拡大させていくためには、7 ~ 8人の開発チームが分散して動ける環境を構築することが重要になってくると考えています。

今月(2022.05)からは、早速チームを2つに分割しそれぞれで目標を立て開発を進める体制に切り替えました。

現状では、闇雲にチームを分割することは良くないかなと考えており、各チーム生産性の計測とともに効率性を見極めて、適切なタイミングでのチーム分割を進められると良いかなと思っています。
そして、そのためには実際にチーム分割を適切なタイミングで行えるアーキテクチャを構築できているか？が非常に重要なポイントにもなってきます。
(逆に適切な単位ではないアプリケーション/チームの分割はかえって生産性を下げ、チーム間コミュニケーション増加に伴う認知的負荷だけが上がっていくことになる)

結局の所、チームとしてのスケールを支えるのは、アーキテクチャ(/アプリケーション)のスケールだなと思いますし、そうしたアーキテクチャの構築のためにもCTOとして日々の開発の中で適切な境界線を見極めていくことが重要なミッションであると考えています。
(この辺り、組織/アーキテクチャのスケール戦略に関しては、いま私が考えていることをいずれnoteにまとめていきたいなと思っています。。。)

まとめ

これまで This is Lean を参考に、「フロー効率性」「リソース効率性」という観点から開発組織の生産性を可視化してきました。
明確な基準があったからこそ、改善サイクルを高速に回すことができているのが非常に良いなと私自身感じています。
また、絶対値としての数値にただ一喜一憂するのではなく、日々の振り返りの中で、なぜこの数値は上がったのか/下がってしまったのかを言語化することで、開発組織の生産性に対して深く現状理解をすることができます。

また、効率性に向き合っていく中で投資対効果の低下を適切に検知でき、開発組織のスケールに向き合うことができると考えています。
メダップの開発組織としては、投資すれば & 頑張れば生産性が向上するというボーナスタイムが残念ながら終わってしまったので、ここからはエンジニアらしく技術を使って、より一層効率性を高く保ち続ける仕組みを構築していくことにチャレンジしていきたいなと思います！

何だこの組織、面白そう！/ 開発組織のスケールを技術力でハックしたい！って思っていただけた方いましたら、ぜひ一度お話しましょう！