要件定義の進め方｜発注者側が押さえるべき7つのポイント発注者（非IT企業）がベンダーに伝えるべき要件定義の進め方を7つのポイントで解説

要件定義の失敗は「発注者側の準備不足」から始まる

システム開発のプロジェクトが失敗する原因の多くは、最上流工程である要件定義に潜んでいます。「発注先に要件を伝えたつもりなのに、出来上がったシステムが想像と違った」「開発途中で仕様変更が頻発し、予算も納期も大幅に超過した」——こうした問題の根本原因は、発注者側がベンダーに伝えるべきことを伝えきれていないケースがほとんどです。要件定義は開発工程全体のおよそ20%を占める工程ですが、ここでの不備は後工程に進むほど修正コストが膨らみ、テスト段階での手戻りは要件定義段階の数十倍のコストがかかるとも言われています。要件定義はベンダーが作成する工程ですが、その品質を決めるのは発注者側の準備と関与の度合いです。本記事では、非IT企業の発注者が要件定義で押さえるべき7つのポイントを、実践的な視点で解説します。

そもそも要件定義とは何か

要件定義とは、これから開発するシステムが「何を実現すべきか」を明確にする工程です。システム開発の全工程のうち約20%を占める上流工程であり、ここで定義した内容が以降のすべての工程（設計、実装、テスト、リリース）の土台となります。

重要なのは、要件定義は「要求定義」とは異なるという点です。要求定義は「発注者がシステムに何を求めているか」という要望を整理する工程であり、要件定義はその要望を「システムとしてどう実現するか」という仕様に変換する工程です。つまり、発注者の役割は要求定義を的確に行い、ベンダーが要件定義に落とし込める状態を作ることにあります。

ポイント1：「何を作りたいか」ではなく「何を解決したいか」を伝える

発注者がベンダーに最初に伝えるべきは、「どんなシステムが欲しいか」ではなく「どんな業務課題を解決したいか」です。「顧客管理システムが欲しい」と伝えるのと、「現在、顧客情報がExcelで属人管理されており、担当者不在時に対応履歴が追えず、顧客対応の品質にばらつきが出ている。この問題を解決したい」と伝えるのでは、ベンダーが提案できる解決策の幅がまったく異なります。

課題起点で伝えることで、ベンダーは技術的な観点から最適な解決手段を提案できます。発注者がシステムの機能を指定してしまうと、より良い解決策が存在しても提案の余地がなくなってしまいます。

ポイント2：現在の業務フローを「見える化」して渡す

ベンダーがシステムの要件を正しく定義するには、発注者の現在の業務の流れを正確に理解する必要があります。しかし、業務フローが口頭説明のみだと、ベンダーの理解にどうしても齟齬が生じます。

要件定義に入る前に、現在の業務フロー（As-Is）を図や文書で整理しておくことを強く推奨します。フローチャートのような本格的なものでなくても、「誰が」「何を」「どの順番で」「どのツールを使って」処理しているかを箇条書きでまとめるだけでも大きな効果があります。たとえば「営業担当が受注情報をExcelに入力→経理担当がExcelを集計→月末に請求書を手作業で発行」という流れをメモするだけで、ベンダーはボトルネックの所在と自動化の可能性を具体的に検討できます。あわせて、既存システムの設計書やマニュアル、現在使用しているExcelテンプレートやフォーマットが残っていれば、それもベンダーに渡してください。ベンダーにとって最も助かるのは「現場の実態がわかる生の資料」です。

ポイント3：「やりたいこと」と「やらなくていいこと」の両方を明確にする

要件定義で見落とされがちなのが、スコープ（開発範囲）の「外側」を定義することです。「この機能は必要」と伝えるだけでなく、「この機能は今回のプロジェクトでは不要」「この業務は従来のやり方を維持する」と明確に線引きすることで、ベンダーは開発範囲を正確に見積もることができます。

スコープが曖昧なまま開発が始まると、「この機能も入っていると思っていた」「このケースは想定していなかった」という認識の齟齬が後工程で発覚し、仕様変更と追加費用の原因になります。具体的には、「スマートフォン対応は今回のスコープに含まない」「既存の会計システムとの連携は第2フェーズで対応する」「過去3年分のデータは移行するが、それ以前は対象外とする」といった形で、明確に対象外を宣言しておくことが効果的です。「やらないこと」を決めることは「やること」を決めることと同じくらい重要です。

ポイント4：非機能要件を忘れない

多くの発注者は「どんな機能が必要か」（機能要件）には関心を持ちますが、「どれくらい速く動くべきか」「何人が同時に使うか」「データはどこまで安全に守るべきか」（非機能要件）は後回しにしがちです。

しかし、非機能要件がシステムの使い勝手と信頼性を大きく左右します。たとえば「顧客検索機能がある」だけでは不十分で、「検索結果が2秒以内に表示されること」「同時に50人がアクセスしても動作が遅くならないこと」「個人情報は暗号化して保存すること」まで定義して初めて、実用に耐えるシステムの仕様が決まります。非機能要件として検討すべき代表的な項目は、性能（レスポンス時間、スループット）、可用性（稼働率、障害時の復旧目標）、セキュリティ（認証方式、データ暗号化）、拡張性（将来のユーザー数増加への対応）、移行性（既存データの移行方法）です。

ポイント5：曖昧な表現を排除する

要件定義書に「～など」「適宜」「なるべく」「できれば」といった曖昧な表現が含まれていると、その解釈はベンダーに委ねられ、発注者の意図とズレる原因になります。

「主要な帳票を出力できること」ではなく、「月次売上レポート、顧客別売上レポート、在庫一覧の3帳票をPDF形式で出力できること」と具体的に書く。「レスポンスが速いこと」ではなく「画面遷移が2秒以内に完了すること」と数値で定義する。このように、誰が読んでも同じ意味に解釈できる記述を徹底することが、要件定義の品質を担保する基本原則です。

ポイント6：発注者側の体制と意思決定者を明確にする

要件定義は発注者とベンダーの共同作業です。発注者側が「すべてお任せで」というスタンスでは、要件定義の品質は上がりません。

発注者側で最低限必要な体制は、業務に精通した現場担当者（業務の実態を正確に伝えられる人）、プロジェクトの意思決定者（仕様の取捨選択を判断できる人）、窓口担当者（ベンダーとの連絡を一元管理する人）の3つの役割です。特に重要なのは意思決定者の明確化です。「この機能は入れるか入れないか」「予算をオーバーしそうな場合、機能を削るか予算を追加するか」といった判断が求められる場面で、意思決定に時間がかかるとプロジェクト全体が停滞します。

ポイント7：要件定義書を「合意文書」として扱う

要件定義書は単なる技術文書ではなく、発注者とベンダーの間の「合意文書」です。要件定義書に記載された内容がシステムの仕様となり、開発はその内容に基づいて進められます。要件定義書に書かれていないことは「要件として合意されていない」とみなされるため、後から追加すれば仕様変更として追加費用と工期延長が発生する可能性があります。

要件定義書の最終版が完成したら、内容を隅々まで確認し、不明点や違和感があれば必ず質問してください。「専門用語が多くてよくわからないが、ベンダーが作ったものだから正しいだろう」という姿勢は危険です。要件定義書はベンダーの専門用語で書かれることが多いですが、発注者として理解できない部分は平易な言葉で説明してもらう権利があります。疑問を残したまま合意してはいけません。確認の際に特に注意すべきは、「画面一覧」「帳票一覧」「データ項目一覧」といった具体的な成果物のリストです。ここに漏れがあると、開発完了後に「この画面が足りない」「この帳票が出力できない」という事態になります。

GXOの要件定義支援

要件定義は、発注者側の準備と関与がプロジェクトの成否を左右する最重要工程です。GXOは180社以上の支援実績と92%の成功率を持つDX・システム開発のパートナーとして、非IT企業の発注者に寄り添った要件定義支援を提供しています。業務課題のヒアリングからAs-Is/To-Beの整理、要件定義書のレビューまで、発注者側の立場に立ってプロジェクトを支援します。

「初めてのシステム発注で要件定義の進め方がわからない」「過去に要件定義の不備でプロジェクトが失敗した経験がある」「ベンダーとのコミュニケーションに不安がある」という方は、お気軽にご相談ください。

お問い合わせはこちら

まとめ

システム開発の要件定義は、ベンダーが作成する工程ですが、その品質を決めるのは発注者側の準備と関与です。課題起点で目的を伝え（ポイント1）、業務フローを見える化し（ポイント2）、スコープの内と外を明確にし（ポイント3）、非機能要件を忘れず（ポイント4）、曖昧な表現を排除し（ポイント5）、発注者側の体制と意思決定者を明確にし（ポイント6）、要件定義書を合意文書として責任を持って確認する（ポイント7）。この7つのポイントを押さえることで、要件定義の品質は格段に向上し、プロジェクト全体の成功確率を高めることができます。