予算会議で新システムの稟議が上がる。手元の資料は、ベンダーが作った仕様書と見積もり。100ページ超のドキュメントを全員が読み込んでいるわけもなく、話題は金額に集中する。「300万は妥当か」「半年で回収できるのか」。そういう議論だけでGo/No-Goが決まっていく場面を、僕は何度も見てきた。
珍しいケースではない。多くの会社でごく普通に起きている。ただ、この判断プロセスには構造的な穴がある。
仕様書は「合意の記録」であって「完成予想図」ではない
仕様書には機能の説明が書いてある。画面構成、データの流れ、権限設計。読めば何を作るかはわかる。でも、それを実際に触ったときどう感じるかは、文字からは読み取れない。
「検索結果の一覧画面があります」と書かれていても、そこにたどり着くまでに何クリック必要なのか。結果が多すぎて使い物にならないのか。そういうことは画面を触らないと判断できない。仕様書は機能の存在を約束するけれど、使い勝手までは約束しない。
仕様書でGoを出しても、それは「こういう機能を作る」に合意しただけだ。「使えるものができる」という確証とは違う。この認識のズレが、プロジェクト後半に牙を剥く。
認識ズレの代償は、手戻りコスト30-50%増
IPAの調査によると、開発後半での手戻りは初期段階の修正と比べて5倍以上の工数がかかる。僕が関わった案件でも、認識ズレが後から発覚して当初予算から30-50%超過したケースは珍しくなかった。
300万の見積もりが、手戻りで400万、450万になる。その追加コストは最初の稟議に載っていない。予算会議で想定していなかった出費が、プロジェクトの途中で黙って積み上がっていく。
厄介なのは、誰もミスを犯していないことだ。仕様書通りに作っている。見積もり通りの工数で進めている。それでも「思ったのと違う」が起きる。仕様書という媒体そのものの限界が、経営リスクに直結している。
見積もり金額が判断を支配する
もうひとつ、繰り返し目にする光景がある。見積もりの数字が意思決定を丸ごと支配してしまうパターンだ。
300万という数字が出た瞬間、議論は「回収期間」に集中する。機能の優先順位や、現場のスタッフが使いこなせるかという話は後回しになる。複数社から相見積もりを取ったら、比較軸は金額だけになる。
考えてみれば、何を作るか曖昧な段階でROIを議論しても精度は低い。100万円安くても使われなければ全額がサンクコストだし、50万円高くても定着すれば半年で元が取れることもある。金額を比較する意味が出るのは、作るものが具体的に見えてからだ。
予算の前にデモを挟む
こうした問題に対する僕の答えは単純で、本開発の前に動くデモを作ることだ。
ブラウザで触れるWebアプリのプロトタイプを7日で作る。仕様書を何回レビューしても見えなかったことが、デモを5分触るだけで見えたりする。「この画面、情報多すぎて使えない」「この機能は月次でしか使わないからもっとシンプルでいい」。そういう判断は、実物がないと絶対に出てこない。
デモの費用は本開発の10分の1以下に収まることが多い。300万のプロジェクトなら、デモに10-20万かけるだけで「本当に進めるべきか」の判断精度が格段に上がる。保険として考えれば安い投資だと思う。
「やめる」判断の経済合理性
デモを見た結果「これは違うな」と判断して中止する。これを失敗だと感じる必要はない。
本開発に300万投じた後で「使われない」と気づくのと、デモの段階で「進めるべきではない」と判断できるのとでは、280万の差がある。早期撤退は判断能力の高さの証拠であって、失敗ではない。
予算会議に「触れる材料」を持ち込む
判断精度を上げたいなら、予算会議の材料を変えるのが一番早い。仕様書と見積もりに加えて、動くデモを議題に載せる。触れる材料がひとつ増えるだけで、会議の議論の質が変わる。
確認してみてほしいポイントが3つある。
ひとつ目は、仕様書だけで「使い勝手」まで判断しようとしていないか。機能の有無と操作感は別の話だ。
ふたつ目は、見積もり金額だけで比較していないか。安さに引っ張られて、定着しないシステムに投資するリスクを見落としていないか。
みっつ目は、撤退コストを計算しているか。本開発に入ってからの方向転換は、想像以上に高くつく。
この3つにひとつでも心当たりがあるなら、本開発の前にデモを挟む価値は十分にあると思う。