要件定義を"商品"にしたら、プロジェクトが変わった

プロジェクト失敗の根本原因は、技術ではない

システム開発が失敗する最大の原因は、技術選定でもエンジニアの力量でもない。「何を作るべきか」の合意が曖昧なまま始めることだ。

建築であれば、施主は設計事務所に数百万円を払って図面を依頼し、その図面を持って工務店に見積もりを取る。設計と施工は別の契約だ。ところがシステム開発では、要件定義がしばしば「受注のためのおまけ」として扱われている。これは個人の問題ではなく、業界の構造的な慣習だ。

私たちはこれまで100社を超える企業のDX・AI・システム開発を支援してきた。その中で確信したのがこの一点だ。だから私たちは、要件定義を無料の付帯サービスではなく、独立した商品にした。それが「Discovery」だ。

「意味のズレ」が静かにプロジェクトを壊す

Discoveryが何であるかを説明する前に、まずそれが解こうとしている問題を共有したい。

私たちが「意味のズレ」と呼んでいるものがある。

従業員300名規模のあるB2B SaaS企業で、「売上」というKPIの定義が部門ごとに異なっていた。営業は受注ベース、経理は入金ベース、経営企画は契約ベース。毎月の経営会議で「どの数字が正しいか」の議論に30分が消えていた。Discoveryの初週でMeaning Mapを作成する過程で、この事実が可視化された。

別のケースでは、年商80億円規模のEC企業がBI基盤を導入したものの、ダッシュボードを見る人がいなかった。現場の業務フローとデータの導線が繋がっていなかったからだ。データはある。ツールもある。しかし「意味」が繋がっていない。これも、Discovery開始2週目の業務ヒアリングで発覚した。

私たちの支援先でも、DX予算の大半が「検討」と「PoC」に消耗され、本番実装に至らないケースは珍しくない。私たちが経験したケースでは、要件が曖昧なまま開発を始めて3ヶ月後に方向転換を余儀なくされ、修正設計に1ヶ月、手戻り実装に2ヶ月、工数にして300〜500万円分が追加で飛んだことがある。しかも、3ヶ月分の「間違った方向に進んだ時間」は二度と戻らない。

450万円で何が手に入るのか

Discoveryは、4〜6週間で完結する独立したプロジェクトだ。標準価格は450万円。クライアントが受け取るのは、6つの固定成果物である。

1. Meaning Map
データ×意思決定×業務×体験の対応表。「どのデータが、どの意思決定に、どう使われているか」を一枚の地図にする。先ほどのSaaS企業のケースのように、「この数字、部門ごとに定義が違っていた」という事実が浮かび上がる。

2. KPI定義書
主要KPIの定義・算出式・参照元・注意点を統一する文書。KPIの「意味」が組織内で割れている限り、どんなシステムを作っても会議の消耗は止まらない。

3. To-be業務・体験設計
画面設計ではない。「この業務が将来どういう流れで動くべきか」のユーザー体験を設計する。

4. 価値KPI設計
北極星KPI（私たちは「意思決定リードタイム短縮」を推奨している）とドライバーKPIの定義、計測方法、ベースライン。「何がどう変わったら成功なのか」を開発前に合意する。

5. 価値レバー順ロードマップ
機能単位ではなく、価値インパクトの大きい順に開発の優先順位を決める。同じ予算でも、作る順番を変えるだけで得られる成果は大きく変わる。

6. 依存条件・リスク・意思決定ログ
プロジェクト成功のための前提条件（データ提供、権限者の参加、運用変更への協力）を明示し、合意の履歴を残す。

この6つは「資料」ではない。合意形成装置であり、実装の優先順位を決める仕組みだ。

なぜ他のアプローチではなく、Discoveryなのか

課題の解き方はDiscoveryだけではない。

クライアント側で要件を固めてから持ち込む方法がある。しかし、これは「作り手の視点」が欠落しがちだ。実装可能性やデータの実態を踏まえない要件は、結局やり直しになる。

コンサルティングファームに戦略だけ依頼する方法もある。しかし、コンサルは戦略を描くが実装への責任を持たない。戦略書と実装の間に落ちるものが多い。

アジャイルで走りながら固める方法もある。スプリントの反復自体は有効だが、「何の価値を出すか」が未定義のまま反復しても収束しない。方向が定まらないまま走り続けるリスクがある。

Discoveryは、これら3つの隙間を埋めるために設計した。要件と実装を繋ぐ合意形成装置であり、戦略と実行の間を埋める「実行可能な設計」を、4〜6週間で作る。

従来の要件定義とは何が違うのか

従来のSIerが作る要件定義書は、基本的に「仕様の羅列」だ。どんな画面を作るか。どんな機能が必要か。データベースをどう設計するか。

Discoveryの成果物はその手前にある。「そもそもこのプロジェクトは何の価値を生むのか」を定義する。

最後の2行が決定的な違いだ。

Discoveryの成果物は、私たちへの発注を前提としていない。成果物を持って他社に開発を依頼してもいい。それでも、プロジェクトの成功確率は構造的に上がる。

この自由度を保証できない要件定義は、おそらく「要件定義」ではなく「提案の延長」だ。

提供する私たちにとっての合理性

ここまでは顧客にとっての価値を書いた。しかし、事業として持続可能かどうかも重要だ。

Discoveryを商品化したことで、提供側にも4つの合理性が生まれた。

第一に、無料提案の消耗がなくなった。 従来型の受託では、受注するために無料で要件をまとめることがある。これは1件あたり数十万円のコストを提供側が吸収している。Discoveryを有料商品として切り出すことで、この構造的な損失がなくなる。

第二に、クライアントの本気度がフィルターされる。 Discoveryの費用を投じて課題を定義するという判断ができる企業は、プロジェクトを本気で成功させる意思がある。「とりあえず見積もりだけ」という案件を構造的に排除できる。

第三に、開発フェーズの手戻りが減り、利益率が安定する。 Discoveryで合意形成と優先順位が決まっているから、Delivery（実装）フェーズで「やりたいことが違った」という事故が起きにくい。結果として、見積工数と実績工数の乖離が小さくなる。

第四に、価格競争に入りにくい。 Discoveryは他社が提供していない商品だ。「同じ仕様をもっと安く作れます」という比較が成立しない。価値の独自性が、値引き圧力を構造的に防ぐ。

Discoveryが機能しないケース

すべての企業にDiscoveryが必要なわけではない。私たちはこれも正直に伝えている。

仕様が完全に固まっている場合。 やるべきことが明確で、あとは実装するだけなら、Discoveryに費用を使う意味はない。

意思決定者がプロジェクトに参加できない場合。 Discoveryの成否は、権限を持った人が4〜6週間のプロセスに関与できるかどうかに懸かっている。現場担当者だけで進めても、合意形成装置として機能しない。

予算が極端に小さい場合。 全体予算が500万円以下のプロジェクトでは、Discoveryの費用比率が高すぎる。そうした場合は、率直に「Discoveryなしで進めた方がいい」と伝えることもある。

こんな企業に、Discoveryは最も効く

逆に、以下の条件に当てはまる企業には、Discoveryが最も高い効果を発揮する。

• 複数のシステムが混在している。 基幹、会計、SFA、CS、BI、そしてExcel。データが散在し、統合が手作業で行われている
• KPIの定義が部門で割れている。 会議が「数字の正しさ」の議論で消耗している
• 意思決定が遅い。 月次の確定、承認、レポートのリードタイムが長い
• 意思決定者がプロジェクトに参加できる。 権限を持った人が、4〜6週間のDiscoveryに関与できる体制がある

もしこの4つのうち3つ以上に該当するなら、いきなり数千万円の開発に踏み込む前に、一度立ち止まって考える価値はあると思う。

最も高くつくのは、「間違ったもの」を「正しく」作ることだ。