以前の記事
4.1 比較することの無意味さ
まず「開発生産性」は、他のチームと相対的な比較ができません。扱っている事業環境やプロダクト、システム環境を持つ組織間での開発生産性を比較するのは難しいからです。その組織が直面する固有の課題や使用している技術、チームの経験、組織文化、給与などいろいろな変数が存在します。
例えば、同じ事業境域、同じプロダクト、同じ開発メンバーでも、20年経っているシステムに機能追加をするのと、0→1でゼロから機能追加するのでは雲泥の差があります。既存のコードベース、依存関係、既知のバグ、ドキュメントの欠如など、多くの挑戦が存在するのと対照的に、新しいシステムでは技術の選択や設計における自由度があります。
「あの企業の開発生産性がすごい」といった評判をソーシャルメディアで目にすると、自分たちのチームと比較してモチベーションが下がってしまうこともありますが、厳密に言えば比較ができないので、結局のところ他がすごいのかどうかは分かりません。
つまり、他と比較するのはあまり意味がないのです。ただし、ノウハウや考え方のインストールは効果的です。自分が考えたことはすでに先人が答えを出しているのがほとんどで、組織に取り入れてアップデートするのは良いことでしょう。
一方、あらゆる方法論やプロセスは決して"成功"を保証するものではありません。ある種、「型」であり、このプロセスや方法論さえ守っていれば開発組織は必ず成長する銀の弾丸ではありません。プロセスや方法論は、手段であり目的ではありません。
「型」を何も考えずに組織へ導入すると、思考停止になり、導入すること自体が目的となりがちなので、実際には「型」を組織に適用して現場の環境とマージ（併合）させ、型に当てはまらない例外を観察します。その差分を組織としてどう馴染ませていくのかが肝になります（パターン・ランゲージに落とし込んでも良いと思います）。
開発生産性の領域において、Four KeysやSPACEといった「型」を導入しても、例外やハードルに出くわすと「このフレームワークではダメだ」「私たちの組織には合わなかった」といった結論に至りがちです。その判断は半分くらいは正しいのですが、基本的にはそういうもので型を馴染ませて独自のパターンを作っていくしかありません。
こうした組織固有の独自性が必要になる中で、他の開発組織との比較はほとんど意味がなく、銀の弾丸もないとなると、自分たちを主語に観察と改善をするしかありません。他と比較するよりも、過去の自分たちを越えていくことに専念したほうがメリットは大きいです。昨日までの自分たちにはできなかったことができるようになっているので、モチベーションにもなっていきます。
4.2 記録→予測ベースの開発計画へ
そうなると、開発生産性を上げていくというのは、常に自分たちを超えることで実現できますし、もっと言えば、自分たちのケイパビリティにもとづく予測を常に超えていけばよいわけです。
ある機能開発に「1人月」かかっていた事実を工数ベースで記録します。同じような機能を予測として実装したときに、「0.5人月」になった事実を継続的に作ることができれば、その開発チームは間違いなく成長していると言えるでしょう。
では、どうやってその世界観を作っていくのか？
4.2.1 工数の予実を"記録"していく
肝になるのは、自分たちの開発スピードをログとして記録しておくことです。何を記録していくのかと言うと、「どのプロジェクトにどれぐらいに工数がかかるかを予測したか」「実際にどのぐらいかかったか（予実）」です。
ここについては、第1回で述べた通り、BigQueryをDWHとしてデータを格納し、SQLで分析できるようにしておくと便利です。どの企業もソフトウェア資産をB/S（バランスシート）で経理や財務部門が管理しているはずです。何かしらのBPM（Business Process Management）システムで、「どの資産にどのぐらい時間をかけたか」と、一意のコードで管理しているはずです。そのログを使っても良いですし、別で何かを管理しているのであればそれを使っても良いでしょう。
また、なぜ工数ベースかというと開発組織外との共通言語として有効だからです。PdMや事業責任者への説明変換がいらず、かつコスト計算が工数×単価で計算しやすいからです。さらに、スケジュールについても工期で表せます。これをスクラムチームだと工数＝ストーリポイント、工期＝スプリント（イテレーション）で会話してしまうことがよくあると思いますが、組織全体を見たときに独自の基準・指標になってしまうので変換コストがかかります。
例えば、工数の予実を計画と実測でプロットして散布図を作るとします。傾向を見ると、20人月を超えたあたりから精度が低くなることが分かるなどインサイトを提供してくれます。
4.2.2 類推見積りで"予測"を作る
予測を作り出すアプローチの1つとして、「類推見積もり」を導入します。ソフトウェア工学として予測を作り出す見積もり方法はたくさんありますが、大枠2つのアプローチがあり、ストーリーポイントによる架空の単位での見積もり、もしくは時間での見積もりになると思います。
類推見積もりは、過去の類似プロジェクトのデータにもとづき時間を見積もる方法です。つまり、チームが蓄積した経験と実績にもとづいて予測をしていきます。これは記録が溜まるほど正確になる上、早く見積もることができます。特に一定規模以上（1人月以上）であれば効果は高くなります。
"どの程度"類似しているかを見定めることは大事になりますが、例えば業務ドメイン（ex. 決済系システム）や使用技術、領域（フロントエンド、インフラなど）、スキルレベル（担当者のスキルグレードや単価）などで比較していきます。
いわゆる経験にもとづいた見積もりになりますが、ストーリーポイントでの相対見積もりも同じように経験にも続く見積もりではあります。違いとしては、ストーリーポイントはそのチーム独自の単位であり、同じ「estimate＝3」でもチームごとに解釈が変わっていきます。
これは予測性を上げるという観点だと、対象チームの経験のみに紐づくのと大規模なプロジェクトを見積もるのに時間がかかります。「ボトムアップ見積もり」と呼ばれる手法で、1つの機能を作るのに3つやることがあるとすると、一つひとつを見積もって結合することで機能を作るときに「合計〇〇日かかる」という計算をするため、時間的にスプリントプランニングが長引く原因になります。
一方、一定規模のプロジェクトを見積もる際は、「類推見積もり」のほうがスピード感が出てきます。それ以上のメリットとしては、チーム数が多ければ多いほど 「工数」という共通言語をもとにログが溜まるので、予測の精度が向上することです。さらに、記録としてBigQueryなどSQLライクに分析しやすいとより柔軟になります。
