要件定義
要件定義とは、システムで実現する業務や機能などを定義することです。
事業目標達成のために、システムで実現したいこと（要求）を、システムとして「どの範囲を」「どのように」実現するかを具体的に整理します。
要件定義を実施する主な目的は、システム開発を依頼する開発会社側に、抜け漏れなく要望を伝え、システム開発作業を効率よく実施してもらうためです。
要件定義では、「業務要件」「機能要件」「非機能要件」の3種類を定義します。
「業務要件」の定義では、新しいシステムを導入した後の業務実施手順や、システムで対応する（しない）業務の範囲などを定義します。
「機能要件」の定義では、導入するシステムの機能や画面などを定義します。
「非機能要件」の定義では、導入するシステムの性能やセキュリティなど、「システムに関する機能以外の事項」を定義します。
なお、「要求定義」とは、発注側がシステム開発会社へ発注する前に、システムで実現したいことを具体化することです。
要件定義は、要求定義で発注側が実現したいと定義した要求に対して、発注側と開発側で協議しながら、システムでの実現方法を整理することであるといえます。
目次
よくある質問
要件定義を誤ると、プロジェクト全体の予算や納期に重大な影響が出る可能性があるでしょうか？
要件定義が不十分な場合、予算超過や納期遅延といった重大なリスクが発生しやすくなります。
発注者としては、要件を曖昧にせず契約や進行管理に反映させることが不可欠です。
特に「範囲の明確化」「追加費用の防止」「進捗管理」「責任分担」の4点を意識する必要があります。
1. 成果物や範囲の明確化
・要件が曖昧なまま進めると、発注者の期待とベンダーの認識がずれやすい。
・想定外の修正が発生し、追加費用・納期延長につながる
2. 追加費用発生のリスク
・契約時に仕様を固めていない場合、変更や追加要件ごとに追加費用を請求される。
・結果として総コストが膨らむ
3. 納期遅延のリスク
・進捗管理指標や遅延時の対応策が明確でないと、問題発覚が遅れやすい。
・発見時には手遅れとなり、大幅な納期遅延を招く
4. 進捗・コスト統制の困難さ
・計画と実績の乖離を早期に把握できないと、調整が遅れ、コストや納期が制御不能になる。
・発注者の意思決定タイミングを逸し、ベンダー依存が強まる
要件定義を誤ると「追加コスト」「納期遅延」「品質低下」といった形で発注者自身が直接的な不利益を被ります。
発注者は要件定義の段階で範囲や責任を明確にし、契約・進行管理に反映させることで、プロジェクト全体の安定性を確保する必要があります。
要件定義の段階で発注者が決定すべき要件と、ベンダーに任せてよい要件の境界を曖昧にするとリスクが高まるでしょうか？
要件定義の段階で発注者とベンダーの役割分担を曖昧にすると、システムの目的や範囲が不明確となり、納期遅延や追加コストの発生といったリスクが高まります。
発注者は「業務上の目的・要件・優先度」を決定し、ベンダーはそれを実現するための「技術的な手段」を検討するという役割を明確に分けることが重要です。
主なリスクと対応策
1. 目的・範囲の不明確化
・リスク：システム導入の目的が曖昧になり、不要な機能追加や本来の目的からの逸脱が発生する。
・対応策：発注者が「何を解決したいのか」「どの業務を対象にするのか」を明確に定義する。
2. 追加コストの発生
・リスク：要件が後から変更・追加され、開発工数が増大する。
・対応策：必須要件と望ましい要件を区別して定義し、契約に反映する。
3. 品質・使い勝手の低下
・リスク：業務要件をベンダー任せにすると、実務に合わないシステムとなる可能性がある。
・対応策：業務フローや利用シナリオは発注者が責任を持って提示する。
4. 責任の所在不明確化
・リスク：不具合や不満が生じた際に「要件の解釈が異なっていた」と責任の押し付け合いになる。
・対応策：要件の決定権限を明確にし、議事録や承認プロセスを残す。
要件定義においては、「発注者＝目的と業務要件を定める」「ベンダー＝技術的な実現手段を検討する」 という役割分担が基本です。
境界を曖昧にすると、追加コスト・品質低下・責任不明確化といったリスクが高まるため、発注者が主体的に判断すべき領域を明示しておくことが望まれます。
要件定義の成果物に曖昧さが残っていると、契約や調達の交渉において発注者が不利になるでしょうか？
要件定義の成果物に曖昧さが残っていると、契約や調達交渉の場面で発注者に不利に働く可能性が高まります。
成果物が不明確なままでは、ベンダーに解釈の余地を与えてしまい、追加費用や納期遅延の原因となるためです。
主なリスクと影響
1. 契約範囲の不明確化
・リスク：どこまでが契約内の作業か判断できず、追加費用請求を受けやすい。
・影響：発注者が本来想定していた機能やサービスが契約外と扱われる可能性。
2. 納期や成果物品質の低下
・リスク：要件の解釈がベンダー任せになり、最低限の機能で納品される恐れがある。
・影響：ユーザー部門が期待した品質や利便性が確保されない。
3. 交渉力の低下
・リスク：契約交渉で「要件が定義されていない」と反論され、調整の主導権を失う。
・影響：ベンダーに有利な条件での合意を強いられる。
4. 責任所在の不明確化
・リスク：不具合発生時に「仕様が明確でなかった」とされ、責任の所在が曖昧になる。
・影響：発注者が修正費用や工数を負担するリスクが増す。
要件定義に曖昧さを残すことは、契約交渉時の不利・追加費用・品質低下に直結します。
発注者は契約前に成果物の要件を明文化し、誤解の余地を残さないことが望まれます。
要件定義で非機能要件を軽視すると、運用フェーズでシステム障害やユーザー不満に直結するでしょうか？
非機能要件を軽視すると、システム稼働後に性能不足やセキュリティ欠陥、操作性の問題が表面化し、システム障害やユーザー不満に直結する可能性があります。機能要件だけでなく、非機能要件も契約や設計の初期段階で明確化することが不可欠です。
主なリスクと影響
1. 性能要件を軽視した場合
・リスク：同時アクセス時の応答遅延、処理能力不足。
・影響：業務停滞やユーザーの利用回避につながる。
2. 可用性要件を軽視した場合
・リスク：障害時に復旧が遅れ、長時間のシステム停止が発生。
・影響：業務継続に支障、サービス提供の信頼性低下。
3. セキュリティ要件を軽視した場合
・リスク：脆弱性を突かれ、情報漏洩や不正利用が発生。
・影響：法令違反や企業信用の失墜。
4. 運用性・操作性を軽視した場合
・リスク：操作が複雑で利用者が使いにくい。
・影響：現場がシステムを敬遠し、利用定着しない。
非機能要件を軽視すると、障害・業務停滞・セキュリティ事故・ユーザー不満に直結します。発注者は要件定義の段階で、機能要件と同じ重みで非機能要件を明示し、契約や検収条件に反映させることが望まれます。
あわせてこの用語と記事をチェック
・要求定義
・システム発注者側が要件定義の際に実施すべきことやポイントを解説
この記事の編集者
武田 祥太郎
大学時代法学部で労働基準法の研究を進める中で日本の労働生産に課題を感じ、ITによる企業体質の健全化を目指して（株）グローバル・パートナーズ・テクノロジーに新卒入社。 民間企業のITガバナンス、マネジメント支援業務に従事し、同社のナレッジ活用知見を活かしてIT調達ナビで記事の展開にも携わる。
