要件定義ってベンダーがやるものじゃないの？

「要件定義はベンダーがまとめてやってくれるもの」と思っている発注者は少なくありません。しかし、その考え方がプロジェクトを失敗に向かわせる入口になっていることがあります。発注者が担うべき範囲を整理します。

よくある誤解：「全部ベンダーに任せればいい」

発注者にとって、ベンダーはIT開発のプロです。「お金を払うのだから、要件も含めて全部やってほしい」という気持ちは自然です。

実際、ベンダーの中には「ヒアリングから要件定義書の作成まで一式対応します」と案内しているところもあります。それ自体は問題ではありませんが、「ベンダーに全部任せれば自分たちは何もしなくていい」という理解には落とし穴があります。

ベンダーが「知らないこと」がある

ベンダーはシステム開発のプロですが、あなたの会社の業務のプロではありません。

たとえば、「受注から出荷までの業務フロー」「どの部署がどのデータを使っているか」「現場でどんな例外処理が日常的に起きているか」——こうした情報は、発注者側にしかありません。

ベンダーがヒアリングをしてくれるとしても、それは発注者が情報を持っていることが前提です。「わからないから教えてください」というスタンスでヒアリングに臨むと、ベンダーも答えようがなく、推測と仮定で要件定義書が埋まっていきます。その結果できたシステムは、現場の実態と乖離している可能性が高くなります。

発注者とベンダー、それぞれの役割

要件定義における役割分担を整理すると、おおむね以下のようになります。

発注者が担うこと

自社の業務フローの説明と整理
現状の課題・不満・改善したい点の洗い出し
優先順位の決定（何を先にやるか、何はやらないか）
社内の関係者（経営者・現場・IT担当）の合意形成
出来上がった要件定義書の確認と承認

ベンダーが担うこと

ヒアリングの設計と進行
聞いた内容を要件として整理・構造化する作業
技術的な実現可能性の判断（この要件はシステムで実現できるか）
要件定義書の作成と文書化
コスト・スケジュールとの整合性確認

発注者が関与しないと何が起きるか

発注者が要件定義にほとんど関与しないまま進めると、以下のような問題が起きやすくなります。

「誰も使わない機能」が作られる：現場の実態を知らないベンダーが定義した機能は、実務の流れに合わない場合があります。リリース後に「この機能、結局使っていない」となるのは珍しくありません。

後から追加要望が山積する：開発が進んでから「そういえばこれも必要だった」が続出します。要件定義の段階で考えていなかった分、後になって降ってくる形になります。

「言った・言わない」が起きる：発注者の確認が薄いまま進んでしまうと、完成後に「こんな仕様になるとは聞いていない」という認識の違いが表面化します。

変更コストが跳ね上がる：発注者の関与が少ないまま開発が進むと、「やっぱり違う」と気づいたときにはすでに作り込まれており、修正コストが大きくなります。

発注者はどこまで関与すべきか

「では、どこまで関与すればいいのか」という疑問も自然です。発注者がシステムの技術的な詳細を理解する必要はありませんし、毎日打ち合わせに参加しなければならないわけでもありません。

ポイントは「業務の専門家として関与する」ことです。

「この業務では、なぜこの手順が必要なのか」を説明できる
「こういう例外が現場ではよく起きる」を事前に伝えられる
「この要件は重要度が高い、これは後回しでいい」と判断できる
完成したドキュメントを読んで、現実と合っているかを確認できる

この4点を発注者側で担えれば、要件定義の品質は大きく変わります。

「ベンダーに丸投げ」が通じるプロジェクトの条件

一方で、ベンダーへの依存度が高くても問題ないケースもあります。

同種のシステムを数多く手がけた実績のあるベンダーに、業界標準に近い業務を依頼する場合は、ベンダーの経験が要件定義を補ってくれることがあります。たとえば、飲食店向けのPOS導入や、一般的な勤怠管理システムの導入などは、ベンダーが業務パターンをある程度知っているため、ヒアリングで引き出してくれる部分が多くなります。

ただし、自社独自の業務フローや、業界特有のルールが絡むシステムでは、経験豊富なベンダーでも発注者の関与なしには要件を正確に定義できません。

まとめ

要件定義はベンダーと発注者の共同作業です。ベンダーは整理と文書化のプロですが、業務の知識は発注者が持っています。発注者が「業務の専門家」として関与することで、要件の精度が上がり、後からの追加変更を減らすことができます。

「任せておけば大丈夫」という姿勢ではなく、「一緒に作る」という関係を最初から意識しておくことが、プロジェクトの成功につながります。