要件定義とは何か。見積もり前に必要な理由

「要件定義書を作ってください」と開発会社から言われて、正直何をどこまで書けばいいのか分からず手が止まった、という現場責任者は少なくありません。社内にシステム開発の知識がある人がいないまま、経営層からは「早く進めて」と急かされ、開発会社からは専門用語混じりの資料を求められる。板挟みの中で、そもそも「要件定義」という言葉の意味すら曖昧なまま話が進んでいくことに、漠然とした不安や焦りを覚えるのは、決して珍しいことではありません。

実はこの戸惑いは、要件定義という工程が「発注側の業務理解」と「開発側の技術知識」の橋渡し役だと理解すると、少し整理がつきます。何を作るべきかを決める工程であって、作り方を決める工程ではない、という切り分けができれば、自分たちが何をどこまで担うべきかも見えてきます。

この記事では、要件定義が業界の商慣習としてどう位置づけられているか、なぜ曖昧なまま進めると後々のトラブルにつながりやすいのか、そして発注側として最低限押さえておきたい判断基準を整理していきます。

要件定義とは、そもそも何を決める工程なのか

要件定義とは、平たく言えば「何のために、何を、どこまで作るか」を言葉にする作業です。情報処理推進機構（IPA）が公開しているシステム開発の見積もりやプロジェクトに関する資料でも、要件定義は開発の初期段階で発注者側の関与が求められる工程として扱われており、実務では業務要件・機能要件・非機能要件（性能やセキュリティなど）に整理して進めるという考え方が一般的です（出典：IPA「非機能要求グレード」関連資料）。

ここで大事なのは、要件定義は「開発会社が考えること」ではなく「発注側が主導して整理すべきこと」だという点です。開発会社は技術的にどう実現するかのプロではありますが、現場の業務がどう回っているか、何にどれだけ困っているかを一番知っているのは発注側です。実務上はここがポイントで、開発会社に丸投げすればするほど、出来上がったものが「聞いていた業務と違う」というズレが起きやすくなります。

要件定義の中身は、一般的な調達ガイドラインの考え方を踏まえると、大きく分けて次のような要素で構成されることが多いとされています。

• 業務要件：どの部署の、どの業務を、どう変えたいか（例：経理の請求書処理を月次から週次に）
• 機能要件：システムに具体的にどんな機能が必要か（例：承認フロー、自動集計、通知機能）
• 非機能要件：性能・セキュリティ・保守のしやすさなど、目に見えにくいが後で効いてくる条件

このうち非機能要件は特に見落とされがちです。「動けばいい」で進めてしまうと、後からアクセス集中時の速度低下やセキュリティ面の不備が発覚し、追加対応のコストが発生することがあります。

なぜ要件定義が曖昧なまま契約が進んでしまうのか

理屈では分かっていても、実際の商流の中では要件定義が十分に固まらないまま契約や見積もりが先行してしまう場面が少なくありません。これにはいくつかの構造的な理由があります。

一つは、経営層が「早く形にしてほしい」というスピード優先の意識を持ちやすく、要件定義にかける時間を「準備期間の無駄」と捉えてしまいがちなことです。もう一つは、現場責任者側にシステム開発の知見がなく、開発会社から提示された要件定義書の内容を精査しきれないまま「専門家が言うことだから」とそのまま承認してしまうケースです。

さらに、開発会社側にも事情があります。要件定義に十分な工数をかけると、その分の費用や期間が発生します。発注側が「まずは安く早く」を求めると、開発会社も簡易的なヒアリングで見積もりを出さざるを得ない場合があり、結果として双方が「詳細は後で詰めましょう」という曖昧な合意のまま契約に進んでしまうことがあります。

この構造は、どちらか一方が悪いというより、双方の思惑が噛み合った結果として起きやすいものです。ここは、次に開発会社とやり取りをするときに思い出してほしい視点で、要件定義にかける時間を「コスト」ではなく「後工程のコストを減らす投資」として捉え直せるかどうかが、実務上の分かれ目になります。

要件定義が曖昧だと、なぜ見積もりが崩れやすいのか

要件定義と見積もりは、本来セットで動くべきものです。何を作るかが決まっていない段階での見積もりは、あくまで「概算」にすぎません。それにもかかわらず、概算見積もりが「確定金額」であるかのように扱われてしまうことが、見積もりの二転三転につながる大きな要因の一つです。

具体的には、次のような流れでズレが生じやすくなります。

1. 概算段階での見積もり提示：要件がまだ粗い状態で、経験則ベースの金額が提示される
2. 開発着手後の詳細化：実際に手を動かす中で「この機能も必要だった」という項目が増える
3. 仕様変更・追加費用の発生：当初の見積もりに含まれていなかった作業が「追加」として計上される

このプロセス自体は、システム開発という性質上ある程度避けられない部分もあります。ただし、要件定義の精度を上げておくことで、この「後から増える」幅をあらかじめ小さくしておくことは可能です。見積もりが不安定に感じられるときは、金額そのものよりも、その根拠となった要件がどこまで固まっていたかを振り返ってみると、原因が見えてくることがあります。

発注側として要件定義にどこまで関わるべきか

ここまでの内容を踏まえると、発注側が要件定義にどう関わるべきかという判断基準が見えてきます。すべてを自社で書き上げる必要はありませんが、最低限「業務の困りごと」と「優先順位」を自分たちの言葉で整理しておくことは、開発会社に任せきりにしない上で欠かせません。

選択肢としては、大きく次の3つの関わり方が考えられます。

• 自社で要件定義の骨子を作り、開発会社に精査してもらう：業務理解が深い場合に向くが、社内に時間的余裕が必要
• 開発会社の要件定義支援サービスを利用する：ヒアリングを通じて整理してもらえるが、その分の費用と期間がかかる
• 要件定義を外部の専門家（ITコーディネーターなど）に依頼する：中立的な立場で整理してもらえるが、別途費用が発生する

どの選択肢を取るにしても共通して言えるのは、「何にどれだけ困っているか」を自分たちの言葉で言語化しておくことだけは、外部に任せきりにできない部分だという点です。発注する側が意識しておきたいのはここで、業務の当事者にしか分からない機微は、どれだけ優秀な開発会社であっても、代わりに言語化することは難しいものです。

まとめ

要件定義は、開発会社に丸投げする工程ではなく、発注側が主導して「何のために、何を作るか」を言葉にする工程です。この記事のポイントを振り返ります。

• 要件定義は業務要件・機能要件・非機能要件の3つで構成されることが多く、発注側の業務理解が土台になる
• 要件定義が曖昧なまま契約が進みやすい背景には、スピード優先の意識と双方の思惑のズレという構造がある
• 見積もりの二転三転を防ぐには、要件定義の精度を上げ「後から増える」幅を事前に小さくしておくことが有効

要件定義の位置づけを理解しておくことは、開発会社とのやり取りをスムーズにするだけでなく、社内での説明責任を果たす上でも役立つ視点になります。