要件定義を、独立した商品として売っている

アルバコネクトでは、要件定義を本開発の付属作業ではなく、独立した商品として提供している。

理由はシンプルで、ここを曖昧にしたまま始める開発は、ほとんどの場合あとで高くつくからだ。

なぜ要件定義を切り出したのか

受託開発の典型的な流れはこうだ。

提案 → 受注 → 要件定義 → 設計 → 実装 → テスト → 納品。

この流れの中で、要件定義は「受注後の最初のステップ」として扱われる。
本開発に含まれる作業の一部だ。
場合によっては提案段階で無料でやってしまうこともある。

僕は100社以上のプロジェクトに関わってきて、この構造自体に問題があると気づいた。

要件定義が「本開発の一部」として埋もれると、ほぼ必ず後工程で歪みが出る。

3ヶ月のプロジェクトで、要件定義に使えるのは2〜3週間だ。
その間に、業務全体を理解し、データ構造を把握し、KPIを定義し、優先順位を決め、
ステークホルダーの合意を取る。無理がある。

結果、「要件が浅いまま開発に突入する」→「認識のズレが発覚する」→「手戻りが発生する」→「追加費用が発生する」→「信頼関係が毀損する」という連鎖が起きる。

これは顧客が悪いわけでも、開発チームが悪いわけでもない。構造の問題だ。要件定義に十分な時間と予算が割かれていないから、後工程で矛盾が噴出する。

これは机上で思いついたモデルではない。100社以上の案件の中で、うまくいく案件と崩れる案件を見比べた結果、構造的に必要だと分かったやり方だ。

Discoveryという商品

僕たちのモデルはシンプルだ。

要件定義をDiscoveryフェーズとして独立した商品にする。
期間は4〜6週間。この間に、顧客のデータ構造、業務フロー、
意思決定プロセスを徹底的に理解し、6つの成果物を納品する。

これは案件ごとに変わる報告書ではなく、
再現可能な形で提供している設計パッケージだ。

1.Meaning Map

データ・意思決定・業務・体験がどう対応しているかの全体図

2.KPI定義書

主要KPIの定義・算出式・参照元を一意に確定させる

3.To-be業務/体験設計

システム導入後の業務フローとユーザー体験の設計

4.価値KPI設計

何を計測すれば「成功」と言えるかの定義

5.価値レバー順ロードマップ

価値への貢献度が高い順に並べた実装優先順位

6.依存条件・リスク・意思決定ログ

前提条件、合意履歴、リスクの記録

この6点は「資料」ではない。合意形成装置であり、そのまま実装の入力になる仕様だ。

顧客にとっての合理性

Discoveryを独立させることで、3つのことが起きる。

1. 初期リスクを大きく下げられる。

いきなり数千万円の開発を発注する代わりに、まず実行可能な設計パッケージを買える。それを見た上で、開発に進むかどうかを判断できる。極端に言えば、Discoveryだけ買って、開発は別の会社に頼んでもいい。

この選択肢があること自体が信頼になる。

2. 開発の成功確率が上がる。

4〜6週間かけて要件を固めた後のDeliveryは、走り出しが全く違う。KPIの定義が一意になっている。優先順位が合意されている。ステークホルダーの関係図が見えている。

「何を作るか」をめぐる迷いが、開発の初速を鈍らせにくくなる。

3. 「何が変わったか」を計測できる。

成果物の4番目、価値KPI設計がこれに当たる。多くのDXプロジェクトは、終わった後に「で、何が変わったの？」と聞かれて答えられない。
うちのモデルでは、Discoveryの段階で計測指標を決めてしまう。
意思決定にかかる時間、手戻りの発生率、KPI定義の一意性。
ベースラインを取り、改善を計測する。

プロジェクトの価値が数字で見える。

提供側にとっての合理性

このモデルは、顧客のリスクを下げるだけでなく、
提供側にとっても粗利・成功確率・顧客選別の観点で健全な構造になっている。

無料提案の延長で曖昧な要件を抱え込まずに済む。
要件定義が有償であること自体が、顧客の本気度を見極めるフィルターになる。
意思決定者が出てこない案件、予算感が合わない案件は、
Discovery契約の時点で自然に見える。

合意された仕様をもとにDeliveryに進むため、開発フェーズの手戻りが減る。
上流が固まっているプロジェクトと、固まっていないプロジェクトでは、
同じ工数でも結果がまったく違う。

値引き競争に入りにくい。 Discoveryの価値は「工数」ではなく「設計の質」で決まる。人月単価の比較にならないから、安さで選ばれるのではなく、設計力で選ばれる。

双方が正しいインセンティブで動ける構造を作ること自体が、設計の仕事だと思っている。

コンサルでもない、普通のSIでもない

ここがよく聞かれるところだ。

Discoveryだけ見ればコンサルティングに近い。だが、決定的な違いがある。僕たちは設計もするし、作りもする。

コンサルファームの成果物は、多くの場合、実装チームに引き渡す前提で書かれている。報告書として美しいが、そのまま実装の入力にはならない。設計意図がコンサルタントの頭の中に残っていて、引き渡しの過程で失われる。

では普通のSIとはどう違うか。普通のSIは、仕様を受け取って開発を請ける。
スコープを守り、納品する。ただし、「何を作るべきか」の定義は顧客任せだ。
上流が曖昧なまま始まるリスクを、構造的に解消する仕組みがない。

うちのモデルでは、問題定義から入る。
データの意味構造を設計し、KPIと価値レバーまで定義し、そのまま実装する。
計測までつなぐ。

設計した人が、そのまま実装する。だから設計意図が翻訳の過程で消えない。

アルバコネクトではこれを「Semantic SI」と呼んでいる。

失敗のパターンも正直に書く

このモデルは万能ではない。失敗しやすいパターンは大きく2つある。

意思決定者がDiscoveryに参加しない。

Discoveryの本質は合意形成だ。データの構造を明らかにし、KPIの定義を統一し、
優先順位を決める。現場担当者だけでは決められない。

権限を持つ人間が参加しなければ、成果物は「よくできた報告書」で終わる。
だから僕たちは、Discovery契約の前提条件として「意思決定者の参加」を明記している。満たされないなら、受けない判断をすることもある。