要件定義で発注者がやるべきこと｜丸投げしてよい範囲・いけない範囲

要件定義は、開発会社に任せきりにすると失敗しやすい工程です。一方で、発注者がすべてを決める必要もありません。この記事では、要件定義で発注者が担う役割を、要求定義との違い、発注者が決めるべき範囲と開発会社に任せてよい範囲、発注者の作業量、要件定義を別契約にする考え方の順に解説します。

要件定義の前に知っておきたい「要求定義」との違い

要件定義の話に入る前に、似た言葉の違いを整理します。

要求定義は「何をしたいか」、要件定義は「システムとして何を備えるか」です。要求があいまいなまま要件定義に入ると、機能の議論が目的からずれていきます。

IPA（情報処理推進機構）のユーザのための要件定義ガイド 第2版も、ビジネス全体や業務の要求を正しく把握・分析し、それに貢献する要件を定義することに重点を置いています。要件定義は、発注者の要求から始まる工程です。

発注者が決めるべきこと、開発会社に任せてよいこと

発注者が決めるべきなのは「業務とビジネスの判断」、開発会社に任せてよいのは「技術の判断」です。

丸投げしてはいけない範囲

左の列を開発会社に任せると、開発会社は推測で埋めるしかありません。推測が外れると、完成後に「思っていたのと違う」となり、作り直しが発生します。業務ルールは特に注意が必要です。「通知をメールでも送るか」「無料会員はどこまで使えるか」といった細かなルールは、業務を知っている発注者にしか決められません。

任せてよい範囲

右の列は、発注者が細かく指定しない方がうまくいくことが多い部分です。技術の選び方を発注者が指定すると、開発会社の得意な方法が使えず、費用が上がる場合があります。任せる代わりに、「なぜその技術を選んだか」「将来ほかの会社でも保守できるか」の説明を求めましょう。説明が分かりやすいかどうかも、開発会社を見極める材料になります。丸投げの全般的なリスクはシステム開発を丸投げするリスクで解説しています。

要件定義フェーズで発注者に求められる作業量の目安

要件定義の期間中、発注者には次のような作業が発生します。

• 定例の打合せ: 週1回、1時間半程度の打合せ枠を確保する
• 社内の確認: 打合せで出た確認事項を、現場や関係部門に聞いて回答する
• 資料とデータの準備: 現在の帳票、業務の件数、既存システムの資料などを集める
• 画面の確認と承認: 画面イメージ（モック）を見て、使い方と見た目を確認し、承認する
• 意思決定: 優先順位や範囲の判断を、意思決定者から得る

作業量は、決めることの多さで変わります。すべての機能について例外の扱いまで詰めるほど、発注者の確認も増えます。最初から完全な要件を目指すより、主要な機能に絞って要件定義を行い、残りは次の段階で決める方が、発注者の負担も費用も抑えられます。

決まっていない事項は、課題管理表にまとめておくと便利です。「何が決まっていないか」「誰がいつまでに決めるか」を一覧にし、定例のたびに更新します。要件と仕様が確定してから、開発の範囲と正式な見積を確定させる流れにすると、後からの追加費用を防げます。

開発会社側に、仕様の質問を一元管理する担当者がいるかも確認してください。質問がばらばらに届くと、発注者の確認の手間が増えます。

要件定義を別契約にする考え方

要件定義を、開発とは別の契約にする方法があります。

IPAと経済産業省が公開している情報システム・モデル取引・契約書は、工程ごとに個別契約を結ぶ多段階契約の考え方に基づいています。法律事務所の解説でも、完成の基準を決めにくい企画や要件定義には準委任契約がよく用いられる傾向があるとされています。準委任は、作業の遂行に対して費用を払う契約です。

別契約にする利点は次のとおりです。

注意点もあります。別の会社に開発を引き継ぐ場合、要件定義書は正常な流れだけでなく、エラー時の扱いまで書かれている必要があります。成果物の権利が発注者にあるかどうかも、契約時に確認してください。

受託開発の現場から

受託開発の現場では、要件定義を別フェーズとして提案することも多くあります。そこでの考え方を紹介します。

発注者は「体験」と「価値の定義」に集中する

要件定義で発注者が力を注ぐべきなのは、ユーザー体験、主要画面のモックとデザイン、ビジネス上の価値の定義です。そこが決まれば、APIの細かな仕様などの内部実装は開発会社に任せられ、発注者は画面のレビューに集中できます。

要件定義の前に「要求設計」を置く

要件定義の前には、「何のために、どの機能から作るか」を決める要求設計が必要です。課題が明確か、解決策が設計できているか、プロダクトで実現できるかを順に確かめ、最初に作る範囲を決める手前まで仮説を整理します。

勇気を持って機能を絞るために、データを見る

機能を絞り込む判断材料としては、すでに動いているアプリの利用ログや顧客行動の分析が有効です。収益モデルから見込める転換率が分かれば、勇気を持って機能を絞り込めます。

完全版とミニマム版では工数が約3倍違う

要件定義を「完全対応版」で行う場合と「主要機能に絞ったミニマム版」で行う場合では、外部設計や非機能要件の検討の差から約3倍の工数差が出るという例があります。また、別の会社が詳細設計できる水準を求めるなら、エラー処理まで書き切る必要があります。

まとめ

• 要求定義は「何を実現したいか」、要件定義は「システムで何を備えるか」
• 業務ルール、優先順位、画面の確認は発注者が決め、技術の判断は開発会社に任せる
• 発注者には定例への参加、社内確認、資料準備、画面の承認といった作業が発生する
• 要件定義を別契約にすると、見積が正確になり、開発会社を選び直す余地も残る

本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。

要件定義の前に、自社の要求を整理しておきたい場合は、FastProposal の無料AI相談が使えます。質問に答えるだけで、案件の整理と費用の目安を数分で確認できます。