システム開発における要件定義

要件定義は、事業・業務上の要求を、システムで実現する内容と条件へ整理し、関係者で合意する工程です。

文書を完成させること自体を目的にせず、設計・見積もり・テストで判断できる具体性と、発注者・利用者・開発者の共通理解を作ります。

要件定義の目的

要件定義の目的は、誰のどの課題を、システムでどこまで解決するかを明確にすることです。

利用者の要望、事業上の目的、予算、納期、技術・制度上の制約を整理し、開発対象と対象外を決めます。

合意した要件は、設計の入力となり、見積もりやテスト条件の根拠にもなります。

「要件定義書を作った」だけでは完了とは限りません。

必要性の低い機能を作ることや、完成後に利用できないと判明することを防ぐ役割もあります。

関係者が同じ内容を理解し、優先順位と判断基準を共有できている状態を目指してください。

出典：IPA DX SQUARE「要件定義とは？」

企画・要求・設計との違い

企画では、事業や業務の課題、システム化の目的、投資の方向性を決めます。

要求は関係者が実現してほしいこと、要件は要求を分析し、制約や優先順位を含めて合意した条件です。

基本設計では、合意した要件を画面、データ、外部連携などの仕様へ落とし込みます。

ただし、要件定義と設計の境界は組織によって異なり、画面イメージを要件確認に使う場合もあります。

開発工程全体との関係は、開発エンジニアが関わる工程も参考にしてください。

開発手法による違い

ウォーターフォール型では、要件定義の期間と成果物を区切り、承認後に設計へ進む形が一般的です。

変更が生じた場合は、費用、納期、品質への影響を確認して扱います。

アジャイル開発では、最初から全機能を固定するのではなく、優先順位の高い要求を小さな単位へ分け、開発・確認を繰り返します。

要件定義がなくなるのではなく、必要な詳細度と合意のタイミングが変わると考えましょう。

各反復で扱う要求には、目的、受入条件、優先順位を持たせ、確認結果を次の要求へ反映します。

要件定義前に準備すること

要件定義を始める前に、関係者、現行業務、対象範囲、制約を整理すると、聞くべき内容と意思決定の順番が明確になります。

準備不足のままヒアリングを始めると、個別要望が増え、目的との対応や優先順位を判断しにくくなります。

関係者と意思決定者を整理する

最初に、システムの利用者、業務責任者、経営・事業部門、情報システム部門、開発・運用担当などの関係者を洗い出します。

役割ごとに、情報を提供する人、要件を確認する人、最終決定する人を区別してください。

利用部門だけでも、管理者と実務担当者では見ている課題が異なります。

全員の希望を同じ重みで採用するのではなく、事業目的と責任範囲に照らして決めます。

レビューへの参加時期、連絡方法、承認に必要な期間も確認し、決定待ちで開発が止まる事態を防ぎます。

意見が分かれたときに誰が決めるかを先に合意しておくと、検討が止まりにくくなります。

現行業務と課題を可視化する

新しいシステムの機能を考える前に、現在の業務フロー、使用する帳票・データ、担当者、処理量、例外作業を整理します。

利用者の説明だけでなく、実際の手順や資料を確認すると、暗黙のルールを見つけやすくなります。

課題は「作業が大変」といった表現で終わらせず、どの作業で、誰に、どのような負担や誤りが生じているかまで分解します。

現行業務を残す部分と変える部分を分け、システム導入後の業務像を描いてください。

対象範囲と制約を確認する

対象範囲では、今回の開発で扱う業務・利用者・拠点・データ・外部システムと、対象外を明確にします。

境界が曖昧だと、後から「含まれていると思った」という認識違いが起こります。

あわせて、予算、期限、既存契約、法令・社内規程、利用できる技術、保守体制などの制約を確認します。

前提条件と依存関係も記録し、変わった場合の影響を追えるようにしてください。

外部システムとの境界では、連携方式、提供元、利用可能時間、変更時の連絡先まで確かめます。

要望を断るためではなく、実現可能な選択肢と優先順位を判断するための範囲設定です。

要件定義で決める項目

要件定義では、業務要件と機能要件だけでなく、性能、可用性、セキュリティ、移行、運用なども確認します。

すべてを同じ細かさで決めるのではなく、事業への影響とリスクが大きい項目から合意し、未決事項は担当者と期限を記録してください。

業務要件を整理する

業務要件では、システム導入後に誰がどの業務をどの手順で行い、どの状態を達成するかを決めます。

業務フロー、役割、権限、処理の開始・終了条件、例外対応などを整理してください。

業務要件は、個別機能を決める前の土台です。

現在の作業をそのまま画面へ置き換えるのではなく、業務自体を統合・廃止できないかも検討します。

利用者と開発者が同じ業務像を確認できるよう、文章だけでなく業務フローや用語集を併用すると認識を合わせやすくなります。

繁忙期の処理量、承認ルール、担当者不在時の代替手順も確認し、通常時だけを前提にしないことがポイントです。

機能要件を具体化する

機能要件では、利用者の業務を支えるためにシステムが提供する機能を決めます。

利用者、入力情報、処理、出力結果、権限、例外時の動作を組み合わせて記述してください。

「検索できる」のような短い表現だけでは、対象項目、検索条件、件数、並び順、権限制御が分かりません。

利用場面と期待結果を確認し、受入テストで合否を判断できる形へ具体化します。

機能一覧には識別番号を付け、業務要件や画面、テストとの対応を追えるようにすると管理しやすくなります。

入力誤り、重複処理、権限不足、外部連携の失敗など、正常に完了しない条件の動作も要件として確認してください。

非機能・移行・運用を決める

非機能要件では、性能、可用性、セキュリティ、保守性など、機能をどの品質で提供するかを決めます。

「高速」「安全」といった表現ではなく、対象、条件、目標値、測定方法を確認してください。

移行要件ではデータ・利用者・切替手順、運用要件では監視、バックアップ、問い合わせ、障害対応の体制を整理します。

IPAの非機能要求グレードは、確認項目と要求レベルを整理するための参考資料です。

すべての項目を均一に決めず、事業影響が大きいものから優先します。

出典：IPA「非機能要求グレード」

要件定義の進め方

要件定義は、要求を集め、背景と影響を分析し、優先順位と受入条件を決め、関係者と合意する流れで進めます。

一度の会議で完成させず、図や試作品を使って確認し、決定事項・未決事項・変更点を記録しながら具体性を高めてください。

ヒアリングで要求を集める

ヒアリングでは、欲しい機能だけでなく、その要望が生まれた業務、困りごと、頻度、影響を確認します。

「なぜ必要か」を聞くと、別の方法で解決できる場合や、複数部門に共通する課題が見つかります。

質問は、現状、理想、差分、例外、優先順位の順に整理すると進めやすくなります。

会議後は、決定事項、宿題、担当、期限を共有してください。

業務の観察、既存帳票、問い合わせ記録、操作ログなども利用すると、発言だけでは見つからない実態を確認できます。

発言をそのまま仕様にせず、ほかの利用者や既存システムへの影響を確認してから要件候補として扱います。

優先順位と受入条件を決める

要求が予算や期限を超える場合は、事業価値、緊急性、リスク、依存関係を基準に優先順位を決めます。

必須、優先、将来対応などの区分を使い、採用しない要求の理由も記録してください。

受入条件は、完成した機能を利用部門が確認し、合否を判断する基準です。

業務場面、前提、操作、期待結果を明確にします。

要件間に依存関係がある場合は、単独の価値だけでなく、先に提供すべき基盤機能との順序も考慮します。

初回リリースに必要な最小範囲を決め、残りは将来候補として分ける方法もあります。

文書化して関係者と合意する

要件は、関係者が確認できる形で文書化し、レビューで認識をそろえます。

レビューでは、目的との対応、範囲、用語、抜け、矛盾、実現性、検証方法を確認してください。

合意は署名や承認操作だけを指すのではなく、決定内容と責任を共有することです。

未決事項が残る場合は、決定者、期限、次工程への影響を明記します。

文書の版、レビュー日、承認者、変更履歴を管理し、どの内容を基準に設計するか分かる状態を保ちます。

要件変更を禁止するのではなく、変更理由と費用・納期・品質への影響を確認して合意し直せる仕組みを作ります。

要件定義の成果物

要件定義の成果物は、関係者の合意内容を設計・見積もり・テストへつなぐために作成します。

単一の要件定義書へすべてを詰め込む必要はなく、本文、図、一覧、用語集、課題管理表などを組み合わせ、更新責任と参照関係を明確にしてください。

要件定義書を作成する

要件定義書には、背景・目的、対象範囲、関係者、業務要件、機能要件、非機能要件、移行・運用、制約、前提などを記載します。

プロジェクトによっては、複数の文書や管理ツールへ分けます。

項目を埋めることより、誰が読んでも同じ判断ができる具体性が必要です。

各要件に識別番号、根拠、優先度、確認方法を持たせると、変更やテストとの対応を追いやすくなります。

デジタル庁も政府情報システム向けの標準ガイドラインで、要件定義書の標準テンプレートを公開しています。

出典：デジタル庁「デジタル社会推進標準ガイドライン」

図や一覧で認識をそろえる

文章だけでは関係を把握しにくい内容は、業務フロー、システム構成図、データ一覧、機能一覧、画面イメージ、用語集で補います。

図を使うと、処理の順序やシステムの境界をレビューしやすくなります。

画面イメージは操作の認識合わせに役立ちますが、色や配置だけに議論が偏らないよう注意してください。

確認したい要件と図の目的を明記します。

IPAの要件定義事例集には、機能一覧、画面・帳票、運用、移行などのサンプルが公開されています。

出典：IPA「超上流から攻めるIT化の事例集：要件定義」

変更管理の方法を決める

要件定義後も、法制度、事業方針、利用者の確認、技術的制約によって要件が変わることがあります。

変更をすべて問題と考えず、影響を確認して判断できる状態を作ります。

変更要求には、理由、対象要件、優先度、費用、納期、品質、関連機能への影響を記録します。

承認者と反映時期を決め、要件定義書、設計、テスト項目を同時に更新してください。

承認済みの基準版と検討中の変更を区別し、関係者が誤った版を参照しない保管方法も決めます。

最新版と決定理由を追えることが、古い前提で作業するリスクを減らします。

要件定義を成功させるポイント

要件定義の質は、文書量よりも、曖昧さを減らし、目的からテストまでのつながりを保てるかで判断します。

要件定義案件へ参画するときも、肩書きだけで判断せず、自分が担当する作業、意思決定の範囲、成果物、顧客との接点を確認してください。

設計・テストとの対応を保つ

要件は、設計で実現方法を決め、テストで満たしたかを確認できる必要があります。

要件ごとに設計項目とテスト項目を対応づけると、抜けや変更影響を見つけやすくなります。

要件が変更されたら、関連する画面、データ、外部連携、テストを確認してください。

逆に、設計や実装で新しい制約が判明した場合は、要件へ戻って関係者と判断します。

対応表や管理ツールを使い、要件番号から設計・テストへ、テストから根拠となる要件へたどれるようにします。

要件定義を閉じた文書にせず、後工程から参照・更新できる状態を保ちましょう。

案件ごとの担当範囲を確認する

「要件定義から参画」と記載された案件でも、議事録作成、現行調査、要件書作成、顧客折衝、承認管理など、任される範囲は異なります。

面談では、決定権を持つ人、使用する成果物、レビュー体制、設計までの担当範囲を確認してください。

業務知識が求められる領域、要件変更の頻度、既存メンバーの支援も判断材料です。

要件定義・上流工程を含む案件一覧で、必要経験と担当業務を比較してみましょう。

経験の伝え方や案件選びを整理したい方は、無料相談も利用できます。