要求定義の進め方｜要件定義との違いと外注準備

要求定義とは、システムの機能を決める前に「なぜ開発するのか」「誰のどの課題を解決するのか」「何を実現すれば成功か」を整理する工程です。発注前に目的、対象業務、優先順位、制約を明確にすると、不要な機能と見積もりのばらつきを抑えられます。

• 要求定義とは？要件定義との違い
  • 要求・要件・仕様の違い
• 要求定義で決める内容と成果物
  • 1. 背景・目的・成功指標
  • 2. 対象者・対象業務・利用場面
  • 3. 現状と導入後の業務
  • 4. 要求一覧と優先順位
  • 5. 制約条件と対象外範囲
  • 要求定義の成果物チェックリスト
• 要求定義の進め方と依頼前の準備
  • ステップ1. 責任者と関係者を決める
  • ステップ2. 現状の事実を収集する
  • ステップ3. 課題を原因まで掘り下げる
  • ステップ4. 導入後の状態と要求を整理する
  • ステップ5. 優先順位と初回範囲を決める
  • ステップ6. 合意し、要件定義へ引き継ぐ
• 要求定義の費用・期間と外注先の選び方
  • 費用・期間の一般的な目安
  • 見積もりで確認する項目
  • 要求定義を外注するときの役割分担
  • 外注先を選ぶポイント
  • よくある失敗と回避策
• まとめ
• よくある質問
  • 要求定義は誰が担当するべきですか？
  • 要求定義をせずに要件定義から始めてもよいですか？
  • 要求定義の外注費用はいくらですか？
  • 要求定義では何を成果物にすればよいですか？

要求定義とは？要件定義との違い

要求定義で決めるのは、事業や業務の立場から見た「実現したいこと」です。一方、要件定義（＝作るシステムの条件を決める工程）では、その要求を満たすために必要な機能、性能、運用方法などを具体化します。

たとえば「電話による予約受付の負担を減らしたい」は業務上の要求です。それを受けて、「顧客がスマートフォンから空き枠を確認し、予約・変更・キャンセルできるようにする」とシステムの条件へ落とし込むのが要件定義です。

実務では、要求定義と要件定義の境界が明確に分かれていないこともあります。開発会社によって工程名や成果物の呼び方も異なります。そのため、名称だけで判断せず、「誰が、何を決め、どの文書を納品するのか」を契約前に確認することが重要です。

要求・要件・仕様の違い

発注時に混同されやすい三つの言葉を整理すると、次のようになります。

• 要求：事業や利用者が実現したいこと
• 要件：要求を満たすためにシステムが備えるべき条件
• 仕様：要件を実装する具体的な振る舞いや構造

予約業務でいえば、「予約受付の負担を減らしたい」が要求、「オンライン予約を受け付ける」が要件、「予約可能期間は90日先までとし、確定時にメールを送る」が仕様です。

ただし、発注者が最初から詳細な仕様まで決める必要はありません。むしろ、解決方法を早く固定すると、より安価なSaaS（＝インターネット経由で利用する既製サービス）や業務変更という選択肢を見落とす場合があります。要求定義では、まず目的と必要な成果を固定し、手段には検討余地を残します。

要求定義で決める内容と成果物

要求定義の成果物は、立派な文書を作ることではなく、関係者が同じ目的と優先順位で判断できる状態を作ることです。少なくとも、次の項目は記録に残します。

1. 背景・目的・成功指標

「老朽化したから刷新する」「業務を効率化する」だけでは、開発中の判断基準になりません。背景にある事実と、達成したい状態を分けて整理します。

例として、次のように具体化します。

• 背景：受注情報を複数の表計算ファイルへ重複入力している
• 課題：転記作業と確認作業に時間がかかり、入力漏れも発生している
• 目的：受注から請求までの情報を一元管理する
• 成功指標：重複入力の廃止、処理時間の短縮、入力漏れの減少
• 確認方法：導入前後の作業時間、差し戻し件数、利用率を比較する

成功指標はKPI（＝進捗や成果を測る指標）として、測定方法まで決めます。数値目標をすぐに置けない場合も、「何を観測すれば成否を判断できるか」は合意しておきます。

2. 対象者・対象業務・利用場面

同じシステムでも、利用者によって必要なことは変わります。利用者を「社員」「顧客」のように大きくまとめず、役割と利用場面を整理します。

• 日常的に入力する担当者
• 内容を確認・承認する管理者
• 設定を変更するシステム管理者
• 問い合わせへ対応するサポート担当者
• 社外から申し込みや照会を行う顧客
• 集計結果を経営判断に利用する責任者

例外的な業務も確認が必要です。通常処理だけでなく、取消、差し戻し、代理操作、月末処理、障害時の代替運用などを洗い出すと、後から重要な要求が見つかるリスクを減らせます。

3. 現状と導入後の業務

現状業務を把握せずに機能を考えると、非効率な手順をそのままシステム化しがちです。現在の手順、担当者、利用ツール、入力情報、承認経路、例外処理を確認したうえで、導入後の業務を設計します。

ここで重要なのは、システム化する範囲と、人が判断する範囲を分けることです。すべてを自動化すると、開発費だけでなく、保守費や例外対応の負担も増えます。頻度が低い処理は当面手作業に残すなど、費用対効果を踏まえて判断します。

4. 要求一覧と優先順位

要求は、部署ごとの要望を並べただけでは意思決定に使えません。各要求について、理由、対象者、優先順位、成功指標との関係を記録します。

優先順位は、たとえば次の4段階で整理できます。

「利用部門から要望された」という理由だけで、すべてを必須にしないことが大切です。必須とする場合は、「実現しないと何が止まるのか」「手作業による代替が可能か」を確認します。

5. 制約条件と対象外範囲

要求定義では、実現したいことだけでなく、変更できない条件も明らかにします。

• 公開・稼働を希望する時期と、その理由
• 初期費用と年間運用費の上限
• 利用を継続する既存システムや外部サービス
• 社内のセキュリティ基準
• 法令、業界ルール、社内規程
• 対応が必要な端末、拠点、言語
• データ移行の有無
• 発注者側で確保できる担当者と作業時間
• 今回は扱わない部署、業務、機能

特に「対象外範囲」は重要です。対象外を記録しなければ、見積もりに含まれていると発注者が考え、開発会社は含まれていないと考える認識違いが起こります。

要求定義の成果物チェックリスト

案件規模にかかわらず、次の成果物があれば要件定義へ引き継ぎやすくなります。

• プロジェクトの背景と目的
• 解決したい課題と根拠となる事実
• 対象となる利用者・部署・業務
• 現状業務と導入後業務の概要
• 業務要求・利用者要求の一覧
• 各要求の理由と優先順位
• 成功指標と測定方法
• 予算、納期、既存環境などの制約
• システム化する範囲と対象外範囲
• 前提条件、未決事項、検証が必要な仮説
• 意思決定者と承認方法

要求定義の進め方と依頼前の準備

要求定義は、資料作成だけでなく、関係者から情報を集めて矛盾を解消する合意形成の工程です。一般的には、次の6ステップで進めます。

ステップ1. 責任者と関係者を決める

最初に、プロジェクト責任者と最終決定者を明確にします。関係者全員の満場一致を目指すと、判断が遅れやすくなります。意見を出す人、内容を確認する人、最終決定する人を分けてください。

関係部署として見落としやすいのは、現場部門以外の経理、法務、情報システム、カスタマーサポート、セキュリティ担当です。開発の終盤で新しい条件が出ないよう、影響を受ける部署を早期に洗い出します。

ステップ2. 現状の事実を収集する

担当者へのヒアリングだけでなく、実際の帳票、入力画面、データ、問い合わせ記録、業務マニュアルも確認します。「頻繁に起きる」という認識と、記録上の発生頻度が異なることもあるためです。

依頼前に用意できる資料は次のとおりです。

• 現在使用している帳票や表計算ファイル
• 既存システムの画面・マニュアル・構成資料
• 月間の処理件数、利用者数、データ量
• 問い合わせやミスの記録
• 組織図と承認経路
• 外部サービスとの連携状況
• 現在の運用費と作業時間
• 契約上・法令上の制約

資料がそろっていなくても要求定義は始められます。ただし、「資料なし」とするのではなく、存在する資料、存在しない資料、正確性が不明な資料を分けて伝えると、調査工数を見積もりやすくなります。

ステップ3. 課題を原因まで掘り下げる

現場から出た要望を、そのまま要求として採用しないことが重要です。たとえば「検索機能が欲しい」という要望の背景には、分類ルールが統一されていない、登録時の項目が不足している、既存画面の導線が分かりにくいなど、別の原因があるかもしれません。

次の順序で整理すると、手段と目的を分けられます。

1. どの業務で何が起きているか
2. 誰にどのような影響があるか
3. 発生頻度と影響の大きさはどの程度か
4. なぜ起きているか
5. 現在はどのように回避しているか
6. どの状態になれば解決といえるか

ステップ4. 導入後の状態と要求を整理する

課題ごとに、導入後に実現したい業務や利用者体験を記述します。この段階では、画面のボタン配置などの細部より、「誰が、何を、どのような条件で行える必要があるか」を優先します。

要求には識別番号を付け、目的や課題とのつながりを追えるようにします。これをトレーサビリティ（＝要求から機能やテストまでの対応関係を追跡できる状態）といいます。見積もり調整で機能を削るときも、どの目的に影響するかを確認できます。

ステップ5. 優先順位と初回範囲を決める

予算と期間には限りがあるため、すべての要求を一度に実現する前提にしないことが大切です。事業への効果、緊急性、実現コスト、依存関係、代替手段の有無を比較し、初回リリースへ含める範囲を決めます。

この時点の費用は詳細見積もりではなく、概算になるのが一般的です。要求が固まる前から固定金額を求めると、開発会社は不確実性をリスクとして上乗せするか、多数の前提条件を置かざるを得ません。

ステップ6. 合意し、要件定義へ引き継ぐ

最後に、責任者と関係部署が次の点を確認します。

• 目的と成功指標に合意しているか
• 初回の対象範囲と対象外範囲が明確か
• 必須要求の理由を説明できるか
• 未決事項に担当者と期限が設定されているか
• 予算・納期の制約に現実性があるか
• 要件定義で検討する内容が区別されているか

この合意後に、機能や非機能の詳細を決めます。要件定義そのものの外注範囲や成果物は、要件定義の費用相場｜外注範囲と依頼方法でも詳しく解説しています。

要求定義の費用・期間と外注先の選び方

要求定義を外注する場合の費用と期間は、システムの機能数より、調査対象の業務数、関係者数、合意形成の難しさ、必要な成果物によって変わります。発注者側で資料整理や意思決定ができるかどうかも影響します。

費用・期間の一般的な目安

上記は一般的な目安です。全国拠点への調査、複雑な法令対応、大量データの分析、新規事業の仮説検証などが必要な場合は、さらに費用と期間が増えることがあります。

一方、対象業務が限定され、発注者側で現状資料と責任者の判断時間を確保できれば、短期間で進められる可能性があります。単純に会議回数を減らすより、事前資料と意思決定の期限を整えるほうが効率的です。

見積もりで確認する項目

要求定義の見積書では、合計金額だけでなく、何を調べて何を納品するのかを確認します。

「要求定義一式」としか書かれていない見積もりは、各社の範囲がそろっていない可能性があります。安価な見積もりでも、現状調査や優先順位付けが含まれていなければ、後続工程で追加費用が発生します。

要求定義を外注するときの役割分担

外注できるのは、調査、議論の進行、論点整理、文書化、選択肢の提示です。事業上の判断そのものは発注者に残ります。

発注のご相談を受ける開発会社の立場では、「要望を伝えれば、最適なシステムをすべて決めてもらえる」という誤解をよく見かけます。しかし、優先する顧客、変更可能な業務、許容できる運用負担は、開発会社だけでは判断できません。外注先は意思決定を支援できますが、発注者の代わりにはなれません。

外注先を選ぶポイント

要求定義の外注先は、技術力だけでなく、業務を理解して合意形成を進める力で選びます。

• 現状の要望をそのまま機能へ置き換えず、背景を質問するか
• 経営層と現場の双方へヒアリングできるか
• 業務変更、SaaS、スクラッチ開発など複数案を比較するか
• 要求、課題、機能の対応関係を管理できるか
• 未決事項や仮説を、確定事項と分けて記録するか
• 成果物のサンプルや目次を提示できるか
• 後続開発を受注するために、過剰な開発案へ誘導しないか
• 発注者側に必要な作業と判断を明確に説明するか
• セキュリティや法令など、業務外の制約も確認するか

自社だけでは要求の整理や部門間の合意形成が難しい場合は、開発のご相談はこちらからご相談ください。相談時点で要求が完成している必要はなく、現状資料と解決したい課題が分かれば、整理すべき論点から確認できます。

よくある失敗と回避策

1. 最初から製品・機能を決めてしまう

「AIを使いたい」「アプリを作りたい」など、手段から始めると目的に合わない投資になる可能性があります。まず課題と成功条件を整理し、その後に手段を比較してください。

2. 現場担当者だけで決める

現場の使いやすさは重要ですが、経営上の優先順位、法務、セキュリティ、運用体制も必要です。関係部署を洗い出し、最終決定者を置きます。

3. すべての要望を必須にする

優先順位がなければ、予算超過時に合理的な範囲調整ができません。必須要求には理由を付け、代替運用の有無も確認します。

4. 要求定義で細部まで固定する

早い段階で画面や仕様を細かく決めすぎると、要件定義でより良い案が見つかっても変更しにくくなります。要求定義では目的、業務、成果、制約を中心に合意します。

5. 未決事項を曖昧なまま残す

その場で決められない事項があること自体は問題ではありません。未決事項には、決定者、期限、判断材料、未決による影響を記録します。

6. 要求定義直後の概算を確定見積もりと考える

要求定義後の金額は、詳細な機能や非機能要件が未確定であれば概算です。前提条件、変動幅、要件定義後に再見積もりする項目を確認してください。

まとめ

• 要求定義は、開発する機能ではなく、事業目的、課題、対象業務、成功条件を決める工程です
• 要求定義で「何を実現したいか」を整理し、要件定義で「システムが何を備えるか」を具体化します
• 成果物には、目的、要求一覧、優先順位、成功指標、制約、対象外範囲、未決事項を含めます
• 現状資料、関係者、決裁者、予算・納期の制約を事前に整理すると、外注費と期間を抑えやすくなります
• 外注費の一般的な目安は、スポット支援で30万〜80万円、中小規模で80万〜200万円、中規模で200万〜500万円程度です
• 外注先には整理や文書化を依頼できますが、事業目的と優先順位の最終判断は発注者が担います
• 見積もりでは、調査範囲、ヒアリング回数、成果物、対象外、発注者側の作業を確認してください

よくある質問

要求定義は誰が担当するべきですか？

最終的な責任は発注者側の事業責任者やプロジェクト責任者が持つべきです。開発会社やコンサルタントへ整理・文書化を依頼できますが、事業目的、優先順位、許容できる変更範囲などの判断まで委ねることはできません。

要求定義をせずに要件定義から始めてもよいですか？

目的や対象業務、関係者、優先順位がすでに明確であれば、要求定義を独立した工程にせず要件定義の前半に含める方法もあります。ただし、関係部署が多い案件や新規事業では、要求の整理を省くと手戻りが起きやすいため注意が必要です。

要求定義の外注費用はいくらですか？

一般的な目安は、小規模な整理支援で30万〜80万円、中小規模案件で80万〜200万円、中規模以上で200万〜500万円程度です。業務調査、関係者数、成果物、会議回数によって変わるため、金額だけでなく作業範囲を確認してください。

要求定義では何を成果物にすればよいですか？

最低限、プロジェクトの目的、現状の課題、対象業務と利用者、実現したい業務、要求一覧、優先順位、成功指標、制約条件、対象外範囲、未決事項を残します。案件によって業務フローや画面イメージ、概算予算、ロードマップも追加します。