4.3 入口と出口を生産性を抑えてから個別最適化をする
いま述べた工数データは、いわゆる生産性の「入口」と「出口」となるものです。生産性を「労働時間当たりの成果」だとすると、最終的に入出力は1日を何に使ったか（入力）とその結果どうだったか（出力）です。
入出力の変数に入る値は工数なのか金額なのか、はたまた付加価値の数値（作り出した売上など）なのかは適材適所に判断していきますが、ここまでの流れでいうと、予測としての工数や工期を入力し、開発が終わったときに予実がどうなったかを出力として記録します。
ここを抑えて初めて生産性向上の中身の議論が有効になります。チームによっては採用を頑張るチームもあれば、トランクベース開発でブランチ戦略を変更したりデザインシステムといったエコシステムを導入したりして、生産性を上げるチームもあるでしょう。フェーズによっても変わってくると思います。
そして、結果として「常に自分たちの"予測"を超えられたか」を入出力のデータから観測していけばよいのです。そうすれば複数チームが存在する組織全体で共通した数値を追いかけつつ、ゆらぎが多く、改善プラクティスが標準化しにくい各チームの課題解決を個別最適化しやすくなります。
4.4 開発プロセスを階層化して、傾向を知る
予測をする上でプロジェクトごとの傾向値を探るには、これだけだと不十分なので開発プロセスを階層化していきます。プロダクトチームによってプロセスは変わりますが、大まかに次のプロセスを踏んでいるチームがあったとします。
- 企画
- 設計（PRD / DesignDoc）
- UIデザイン
- 開発
- テスト
- リリース
- 効果検証
細かいプロセスはともかく、PRDやDesign Docの中で情報設計・WFやユーザーストーリー、システム的な処理のシーケンスは確定させていくとします。これらのプロセスをトラッキングする際、1点注意すべきことがあります。あまり細かくプロジェクトコードを分けすぎても、各々がプロジェクトコードにつける作業が難しくなってしまいます。大まかに小規模なものは「企画」「開発」の2つ、中規模以上は「企画」「設計」「開発」の3つに分けることが多いです。また、入力の手間を少しでも削減するために、Googleカレンダーと勤怠管理ツールを連携することで、カレンダーに予定があれば自動でプロジェクトコードが紐づく仕組みなども導入しています。
これを分析していくと、工程ごとの癖が見えてきます。例えば次の表で言うと、プロジェクトAが決済系関連のプロジェクトだとすると、「設計」に多くの時間をかける必要があることが分かります。逆に、プロジェクトBが身軽な仮説検証であれば、ほとんど設計に時間をかけることもなく、開発もほぼいらないため低コストで実験していることが分かります。
4.6 1人月あたりの工数価値を上げていく
こうした形で工数ベースで記録と予測を繰り返していくと、最終的に行き着くのは1人月あたりの工数値のスループットを上げることです。当然、同じ1人月でも継続的に開発が早いチームと遅いチームでは出せる価値が変わります。もちろん単価が高い、低いはあるので他とは比較せずに自分たちが同じ単価を基準に、以前よりも工数価値が上がっている状態を作り上げるのが理想です。
以上が、開発生産性の入口と出口を記録しながら予測を繰り替えし学習していくという流れでした。次回は、開発組織から少し拡大させて、仮説検証とその周辺で起こるPM/PdMのペインについてお話します。
