スコープが決まらなければ、値札も決まらない——開発選択を稟議の構造から考える

システム導入の稟議が差し戻される。担当者が費用の根拠を問われ、返せるのは「複数社から見積もりを取り、これが最安値でした」という一言だけ——そんな場面は珍しくない。

怠慢ではない、と思う。構造の問題だ。なぜその価格になるのかを自分たちで試算できなかったのではなく、試算できる状態に、そもそも辿り着けていなかった。

「なんでも作れる」が、価格を宙吊りにする

開発は、極論すれば何でも作れる。それがこの問題の出発点になる。

何でも作れるということは、どこまで作るかを自分たちで決めなければならないということでもある。スコープが決まらなければ工数が出ない。工数が出なければ費用が出ない。稟議に必要な「値札」が、最後まで決まらない。

これはベンダーの問題でも、担当者の力量の問題でもない。要件定義が稟議の前工程に置かれる構造上、スコープを社内で確定させるという重労働を引き受けなければ、見積もりに辿り着けない。

仕様書を書いたとしても、それが適切な粒度で書けているか、後から実際に使えるものになっているかは別の話だ。「仕様書がある」が安心の根拠にならない理由は、スコープ定義の難しさと地続きの問題でもある。

稟議が受け付けるのは、値札の言語だけだ

SaaSやパッケージが選ばれる理由は、機能が優れているからだけではない。値札が先にある、という事実が大きい。

SaaSは、できることもできないことも決まっている。機能の上限がプロダクトとして設定されているから、価格もあらかじめ存在する。「月額○○円で、こういったことができます」という一文で、稟議の場に乗せられる。

一方、開発には値札がない。あるのはスコープが確定してから出てくる見積もりだけで、そのスコープの確定に時間と判断力を要する。

パッケージが普及したのは、機能が優れていたからだけではない。値札が先に存在したから、意思決定の場に乗せられたのだ。

稟議という手続きは、値札のない提案を通す設計になっていない。金額が決まっているものは通り、決まっていないものは通らない。これは意思決定の場の本質的な制約であり、変えようとするより、理解して使う方が現実的だ。

開発の前に、まずSaaSに「当ててみる」

開発が必要な場面は当然ある。ただ、要件を並べてベンダーに相談する前に、一度立ち止まる価値はある。

よく設計されたSaaSに、自社の業務を当てはめてみる。この作業が教えてくれるのは「合う部分」だけではない。「どうしても合わない部分」が明確になることで、初めて開発スコープが絞れる。ゼロから線引きをするのではなく、プロダクトが引いてくれた線を借りて、その差分だけを開発対象にする。

進め方の目安は次の通りだ。

1. SaaSに業務を当てはめる — 要件を並べる前に、既存プロダクトで何割が対応できるか確認する。
2. 合わない理由を言語化する — 「この機能がない」ではなく、「なぜ自社には必要か」を記述する。この言語化が開発スコープの定義につながる。
3. 開発はその差分だけに絞る — SaaSで賄えない箇所だけを開発対象にする。値札のない範囲を最小化することで、稟議に乗せられる形になる。

AIへの指示が書けない状態と同様に、スコープを自力で定義できない場面は、業務の輪郭がまだ曖昧なサインでもある。優れたプロダクトという「外から借りる構造」が、業務整理のきっかけになることも多い。

システム選択を費用の比較だけで終わらせる前に、「誰がスコープを決めているか」を問い直してほしい。値札が先にある選択肢には、意思決定のコストを肩代わりしてもらっている価値が含まれている。その価値を意識的に使うことが、稟議を通す現実的な手段になる。

アルゴラのDX伴走支援「しぼる」では、どこまで作るかの整理から支援している。線引きを一緒に考えることが、値札を作る第一歩になる。