プロジェクトで、こんな課題が話題になりました。

過去に作ったシステムにおいて、「将来こうなるだろう」「ビズからこういう要件来るだろう」で作った部分が、実際にどれくらい的中したのか統計が知りたい。

備えて作らないというのがYAGNIの原則ですが、備えて作ることに価値があるのかをデータで語りたい、という背景があるようです。

これは良いテーマだと思ったので、自分なりに考えてみたのですが、正直まとまりきってないところもあります。

問題の本質（だと思うこと）

このテーマで本当に知りたいのは、こういうことなのかなと思います。

過去に「将来こうなるだろう」と予測して作った実装は、どのくらいの確率で現実になったのか？

これを分解すると、評価したい軸は3つあるように見えます。

観点 具体
① 予測 「将来◯◯要件が来るだろう」という仮説
② 実装 それに備えて作ったコード／設計
③ 現実 実際にその要件は来たか／使われたか

つまり、「予測 × 的中率」 を測りたいということだと理解しています。

YAGNIと先読み設計の間

YAGNI（You Aren't Gonna Need It）は「今は要らない」という原則であって、「一生要らない」という意味ではないはずです。

問題は、予測の精度が低いのに、重いコストを先に払ってしまうことなんだと思います。

では、先読みが許される領域とNGな領域はどう分けるのでしょうか。ここは少し考えてみました。

先読みが比較的許されそうな領域

→ コストが低くて、外れたときのダメージが小さそう

先読みNGな領域

→ 外れたら作り直し確定

このあたりの線引きは、正直まだ自信がないです。

見積もりの精度問題

ここで詰まりました。

先読み設計の価値を、こう表現できるのではないかと考えました。

価値 = (起きる確率 × その時に節約できるコスト) − 先に払うコスト

でも、よく考えるとこれ、正確に見積もれないですよね。

しかも、もし正確に見積もれるなら、そもそもこんな仕組み要らない可能性すらあります。

じゃあ、どうするのか。

完璧じゃなくても、相対的な判断はできるかもしれない

見積もりが正確である必要はないのかなと思います。

重要なのは

例えば、こういう感じで

領域 的中率 傾向
テーブル設計 70% 先読みOK？
UI仕様 20% YAGNI推奨？
外部連携 10% 絶対YAGNI？

こういう組織知が溜まることに価値があるのかなと。

ただ、本当にこれでいいのかは、やってみないとわからないです。

数字は「絶対値」じゃなく「学習材料」

ですから、見積もりの精度を上げることが目的ではないんだと思います。

判断を記録して、結果と照らし合わせて、学習することが目的なのかなと。

こういうズレを知ることが、次の判断を良くするんじゃないかと思います。

測定可能にする設計（案）

先読み実装を明示的にタグ付けする

まず、先読み実装を「意図付きで残す」必要がありそうです。

例えば、ADR（Architecture Decision Record）にこんな形で記録するとか

## Context
将来、顧客ごとの権限管理が必要になる可能性がある

## Decision
現時点では単純なロールモデルに留める

## Forecast
- 発生確率の予想: 30%（営業ヒアリングベース）
- 後追いコストの予想: 20人日（ざっくり）
- 先払いコストの予想: 4人日（ざっくり）
- 判断: 今は作らない（期待値がマイナスっぽい）

見積もりはざっくりでいいと思います。重要なのは、判断の根拠を残すことかなと。

予測と現実を突き合わせる

半年〜1年後に、こういう棚卸しをしたらどうでしょうか。

予測ID 内容 予想確率 実際 予想コスト 実際のコスト 結果
F-001 CSV一括登録 30% 6ヶ月後に来た 後追い15人日 実際1人日で済んだ 的中＆過大見積
F-002 多言語対応 50% 来てない - - 不発
F-003 権限管理強化 20% 3ヶ月で来た 後追い20人日 実際25人日 的中＆過小見積

ここで見るべきは、絶対的な正確さではなく、傾向とズレの理由なのかなと思います。

このあたりの分析がちゃんとできるのか、正直わからないですが。

数値化すると議論が進む（はず）

例えば

→ 要件的中率: 30%、早期化率: 50%

この数字自体に意味があるというより、**「うちは予測が楽観的すぎる」とか「この領域は予測しやすい」**という学習に繋がるんじゃないかと思います。

経営層が見たい指標（たぶん）

CTOや経営層が本当に見たいのは、設計の詳細ではないはずです。

おそらく見たいのは

  1. 先読み成功率
    先読みした要件のうち、実際に要件化した割合

  2. コスト削減効果の傾向
    先読みによって、どれくらいの工数を節約できたか（ざっくり）

  3. 先読みの学習曲線
    時間とともに、予測精度が上がっているか

このあたりだと思うのですが、実際どうなんでしょうか。

実装イメージ（うちの環境だと）

うちの環境だと、こういう形が現実的かなと思います。

全体の流れ

各リポジトリ（ADR + metadata.json）
  ↓
Jenkins（横断走査・差分収集）
  ↓
S3（集計JSON）
  ↓
Microsoft Fabric（分析・可視化）
  ↓
ダッシュボード

すでにJenkinsでリポジトリごとのコード複雑度を集計して、全体レポートを作る仕組みがあります。これを応用できるんじゃないかと。

メタデータ設計

ADR本文は自由に書けばいいと思います。ただし、集計用のメタデータは標準化する必要がありそうです。

最小限、こういう項目があれば集計できるはず

これをJSON形式で保存する感じでしょうか。

見積もりはあくまで"estimate"として扱って、正確さではなく判断の記録として残すイメージです。

差分収集

毎回フルスキャンすると重くなりそうなので、差分だけを収集する形にしたいです。

このあたりは既存の複雑度集計の仕組みを参考にできそうです。

「先読みしてよかった」はいつわかるのか

これも少し考えました。

「ユーザーが使った瞬間」は結果の一部であって、それだけでは「先読みしてよかった」とは言えない気がします。

判定タイミングは3つに分けて考えた方がいいのかなと。

① 要件が発生した瞬間

「その要件、実際に来た？」

この時点で言えるのは

まだ「よかった」とは言えません。

② 実装・リードタイムを見た瞬間（ここが重要そう）

「その要件に、どれくらい早く・安く対応できたか？」

ケース 追加対応
先読みあり 1人日
先読みなし（想定） 10人日

この瞬間に初めて、「先読みして正解だった」と言えるんじゃないでしょうか。

ユーザーが使ったかどうかは、まだ関係ない気がします。

③ ユーザー価値に繋がった瞬間

これは「先読み設計が価値創出に貢献したか」の評価ですが、マーケティング・営業・タイミング・競合も絡むので、技術判断としては遅すぎる評価になりそうです。

技術判断としてフェアなのは、②の要件発生時の対応コスト差分なのかなと思います。

Excel管理は破綻する（たぶん）

「ADR書いて更新まで管理するだけでは可視化できないし、それらを集めてExcel管理するの？」という疑問がありました。

Excel管理が破綻する理由は

Excelは「一度作ったら終わり」になりがちです。

ですから、ADRを「入力装置」、可視化を「別レイヤー」として、システムとして回す必要があるんじゃないかと。

完璧を目指さない

この仕組みの目的は、完璧な見積もりや完璧な予測ではないと思います。

目的は

見積もりが外れることは悪いことではないです。外れたことを知らないまま次も同じ判断をすることが問題なんだと思います。

数字は「絶対値」ではなく「学習材料」として扱うイメージです。

次のアクション

ここまで考えたので、プロジェクトに提案してみようと思います。

具体的には

  1. metadata.json のスキーマを確定
  2. 2〜3リポジトリでPoC
  3. Jenkins → S3 → Fabric の流れを構築
  4. まず「的中率」と「見積もりとのズレ」を出してみる
  5. 3ヶ月回して、学習に繋がるか確認

本当にうまくいくかはわからないですが、先読み設計を「属人技」から「組織能力」へ変えていく仕組みになればいいなと思います。

関連書籍

組織としての意思決定や技術戦略については、こちらの書籍も参考になります。

[📦 商品リンク: moshimo-card-TxhLL]