要件定義で「発注側がやること」を整理する｜ベンダー任せにしていい範囲といけない範囲

業務システムの開発を外注するとき、「要件定義はベンダーがやってくれるもの」と思っている発注側は多い。実際には、要件定義の核心部分は発注側にしかできない。ここを間違えると、完成したシステムが「思っていたものと違う」という事態が起きる。

本記事では、業務システムの開発を外注する際に、発注側（依頼する会社の担当者）がやるべきことと、ベンダー（開発会社）に任せていい範囲を整理する。

なぜ「ベンダー任せ」の要件定義は失敗するのか

ベンダーは、あなたの業務を知らない。

ヒアリングを重ねることで業務を理解しようとするが、「毎月末に起きる例外処理」「担当者しか知らない暗黙のルール」「3年に1度しか使わない機能」——こうした現場固有の文脈は、外部の人間が短期間のヒアリングで把握しきれるものではない。

ベンダーが要件をまとめてくれる場合でも、その内容は「聞いたことをそのまま整理したもの」になる。発注側が「言ったこと」と「本当に必要なこと」はしばしばズレている。そのズレを埋める作業が要件定義であり、それは発注側の仕事だ。

「お客様の言う通りに作りました」という開発は、プロの仕事ではないと私たちは考えている。だが、それ以上に「聞かれたことしか答えなかった」という発注側にも責任がある。要件定義は双方が能動的に動いて初めて機能する。

発注側がやるべきこと

1. 「何のために作るか」を言語化する

システムを作る目的を明確にする。「業務を効率化したい」は目的ではなく、手段の方向性だ。「月3日かかる請求書発行を半日に短縮したい」「担当者が休んでも業務が止まらない状態にしたい」——このくらい具体的に言語化できると、要件が絞れる。

目的が曖昧なまま開発を進めると、機能が膨らみやすい。「あれもできたほうがいい」「これも必要かもしれない」という追加が繰り返され、スコープが広がりすぎる。最初に「何を解決するか」を絞ることが、コストとスケジュールを守る最も有効な手段だ。

2. 現状の業務フローを書き出す

現在の業務がどのような流れで動いているかを、担当者と一緒に書き出す。ベンダーにヒアリングされてから答える形式ではなく、事前に整理しておく。

書き出す際に意識すること：誰が、何のために、どんな操作をするか。例外的な処理（「Aの場合だけBの担当者が対応する」など）は特に漏れやすいので、明示的に書き出しておく。ベンダーが気づけない業務固有の事情は、この段階で洗い出しておくしかない。

3. 優先順位をつける

「必須機能」「あれば便利な機能」「将来的に欲しい機能」を分類する。これをやらないと、開発スコープが無限に広がる。

最初のリリースに何が必要かを絞ることで、開発コストと期間を現実的に抑えられる。追加機能は、システムが動き始めてから考えればいい。完璧なシステムを最初から作ろうとするほど、スタートが遅くなり、ズレも大きくなる。

4. 誰が使うかを明確にする

システムのユーザーを具体的に想定する。社内の経理担当者だけが使うのか、営業も使うのか、外部のパートナーにもアカウントを付与するのか。ユーザーの種類によって、画面の設計や権限管理の要件が変わる。

利用者の年齢層やITリテラシーも伝えておくと、UIの方向性がずれにくい。「うちの社員はあまりシステムに慣れていない」という情報は、ベンダーにとって設計上の重要な判断材料になる。

5. 「検収」の基準を先に決める

完成したシステムをどう確認するかを、開発が始まる前に合意しておく。「動いていればOK」では、細かい仕様の齟齬が後から出てくる。「この業務フローが一通り問題なく動くこと」という形で、受け入れテストの基準を決めておく。

検収基準が曖昧だと、発注側・ベンダー双方にとって「完成」の定義が違う状態が続く。契約上のトラブルにもなりやすいため、仕様と並行して検収基準も文書化しておくことを勧める。

ベンダーに任せていい範囲

発注側がやるべきことを整理したところで、逆にベンダーに委ねていい範囲も明確にしておく。

技術選定・アーキテクチャ

「どの言語で作るか」「どのデータベースを使うか」「クラウドかオンプレか」——これは基本的にベンダーが決めることだ。発注側が技術仕様に過度に介入すると、ベンダーの責任範囲が曖昧になる。「○○を使ってください」という指定は、明確な理由がある場合（既存システムとの連携など）に限定したほうがいい。

UI・デザインの細部

操作の流れと画面に必要な情報は発注側が決めるが、具体的なボタンの色や配置はベンダーに任せていい。「この画面でこの情報が確認できること」というレベルで要件を伝えれば、細かいデザインはプロに委ねたほうが結果が良くなることが多い。

セキュリティ・性能要件の実装

「同時に100人が使える状態にしてほしい」「個人情報を扱うので適切なセキュリティ対策をとってほしい」という要求水準は発注側が伝える。ただし、その要求を満たすための具体的な実装方法はベンダーが決める。

要件定義で特につまずきやすいポイント

「現場の声」を拾いすぎる

要件収集で社内の各部署にヒアリングをすると、「あれも欲しい」「これも必要」という声が集まる。それをすべて要件に入れると、肥大化する。誰が何のためにその機能を必要としているかを確認し、必須かどうかを判断するのは発注側の責任だ。

「あとで決める」が積み重なる

要件定義の段階で「この部分は開発しながら決めましょう」という先送りが積み重なると、開発中盤で手戻りが発生しやすくなる。「どうしても今は決められない」という部分は、そのことを明示した上でベンダーと合意しておく。暗黙の先送りは、後で揉める原因になる。

既存業務の「例外」を見落とす

業務フローを整理すると、「通常はこう流れるが、月末だけこうなる」「この取引先だけ別の処理が必要」という例外が出てくる。これを見落としたまま開発が進むと、リリース後に「この処理ができない」という問題が発生する。例外こそ重点的に洗い出しておく。

よくある質問

要件定義書は発注側が作るものですか？

要件定義書を文書化する作業はベンダーが担当することが多いです。ただし、その内容の正確さを確認・承認するのは発注側の仕事です。「ベンダーが作ったから合っているはず」という確認省略が、後の齟齬を生みます。

業務フローを整理する時間がとれない場合はどうすればいいですか？

担当者が忙しくてフローを書き出す時間がないというケースはよくあります。その場合でも、「1日でよいので集中して整理する時間を確保する」ことを勧めます。開発後半での手戻りにかかるコストと比べれば、この時間投資は確実に元が取れます。

要件定義に費用はかかりますか？

ベンダーによっては要件定義フェーズを有償で提供しているところがあります。「要件定義込みで見積もりを出してほしい」と依頼することで、コストを先に把握できます。要件定義に費用をかけることは、開発費全体を下げる投資でもあります。