Zenn
📚

要望・要求・要件・仕様のような、あいまいに使われがちな用語を統一的に扱うための整理

2025/02/23に公開
アジャイル開発
要件定義
idea

ソフトウェア開発現場では、「要望」「要求」「要件」「仕様」などという用語の定義があいまいなまま都合よく扱われることが多い。これが関係者間の認識のずれや後工程での手戻りリスクを高める原因となる。

英語であれば、User Requirements, System Requirementsなど、要求という言葉で統一されるらしく、シンプルで定義が明確なのがうらやましい。

本記事では、ソフトウェア要求 第3版 の内容に則り、各フェーズを明確に定義した統一的な整理をし、初期段階から実装指針へと一貫した流れを構築する方法について言及する。

※本記事は主に自社内製開発に照準を合わせて記述している。自社内製開発では、社内の各部門との連携、迅速なユーザフィードバックの取り込み、そしてアジャイルな反復プロセスが特に重要となる。これらの現場経験に基づいたスコープで、要求定義の各フェーズを整理したい。

1. 用語の整理とあいまいさのリスク

  • 要望
    プロジェクトの初期段階に提示される大まかな希望やコンセプト。

    • 経営層やマーケティングが掲げる漠然とした期待、プロダクトビジョン、プロジェクトスコープなどが含まれる。
    • 例：いつまでにどの水準の売上・利益を実現するか、主要KPIの目標値など。

  • 要求
    要望をもとに、目的を整理し、作るべきものを具体化したもの。

    • ここでは、企業戦略（ビジネス要求）と実際の利用者が抱える課題やニーズ（ユーザ要求）が明確にされる。
    • 例：顧客ヒアリングやデータ分析から導かれる、解決すべき課題の定義や、実施すべき施策の概要。

  • 要件・仕様
    作るべきものを開発者が実装可能な形に落とし込んだもの。

    • 実装指針として、ユーザが直接体験する部分と、システム内部で実現すべき内容に分かれる。
    • 例：API設計、エラーケースを含むユーザとシステムの相互作用、画面デザインやUX、通知や表示速度などの品質基準。

あいまいな定義は後工程での大幅な手戻りや開発費の増加につながるため、各段階での明確化が必須である。

2. 初期段階の明確化：　ビジネス要求とユーザ要求

初期の「要望・要求」段階では、以下の2つの観点で整理することが重要である。

2.1 ビジネス要求

  • 定義:
    組織がシステムを作る根拠となる、プロダクトビジョンやプロジェクトスコープに基づいた戦略・目標設定。
    • 例：売上や利益の目標、主要KPIの達成目標、成果を出すための戦略や勝ち筋。
  • 意義:
    組織全体の方向性を定め、プロジェクトの成功基盤を形成する。

2.2 ユーザ要求

  • 定義:
    実際にシステムを利用する顧客が抱える課題やニーズを抽出し、整理したもの。
    • 例：ユーザインタビューやデータ分析、営業ヒアリングを通じて抽出される、解決すべき課題や施策の概要、勝利条件の設定。
  • 意義:
    顧客の実際のニーズに即した機能設計を可能にし、優れたユーザ体験の実現を支える。

3. 要件・仕様としての具体的要求の明確化

ビジネス要求とユーザ要求で定義された初期の要求を、実際のシステム設計と実装に落とし込むため、以下のように整理する。

3.1 システム要求

システム要求は、ユーザ要求を実現するために必要な具体的な実装指針として定義され、次の3つの要素に分けられる。

  • デザイン要求

    • 内容:
      システムの見た目や操作性、ユーザとのインタラクション、利用フローを定義する。
    • 意義:
      ユーザが求める使いやすさや体験を実現するため、ユーザ要求から導かれる設計指針として実装に組み込む。

  • 機能要求

    • 内容:
      エンジニアが実装すべき具体的な機能や操作フローを定義する。
      • 例：APIの設計、エラーやエッジケースを含むシステムとユーザ間のインターフェース、フロントエンドの動作仕様など。
    • 意義:
      ユーザ要求を具体的な操作に落とし込み、システムの動作を明確にする。

  • 非機能要求

    • 内容:
      システムの品質、性能、セキュリティ、可用性など、動作以外の制約条件を定義する。
      • 例：リアルタイム通知、ページ表示の応答時間、信頼性、保守性。
    • 意義:
      システム全体の運用やユーザ体験に直結するため、明確な制約条件として文書化する。

4. アジャイルによる段階的明確化のアプローチ

初期段階で全ての要求を完璧に明文化するのは困難なことも多い。その場合、アジャイル開発の反復プロセスを活用することが有効である。

  • 反復とフィードバック:
    ユーザーストーリー、プロトタイプ、デモを活用し、顧客からのフィードバックを即座に取り入れる。
    • 例：プロトタイプ的な機能やデモにより、顧客の理解が深まり、要求が段階的に具体化される。
  • 意義:
    初期のあいまいな要求が短いイテレーションで洗練され、最終的なシステム要求として確定される。

5. 統一的な要求定義のフレームワークと構造サマリ

全体として、以下の統一的な構造で要求定義を整理することで、各フェーズ間の整合性を保ち、ぶれのないプロジェクト進行が可能となる。

  • 要望・要求

    • ビジネス要求:
      プロダクトビジョンやプロジェクトスコープに基づく戦略・目標設定
      （例：売上、利益、主要KPI、戦略的勝ち筋）
    • ユーザ要求:
      顧客が抱える課題やニーズの明確化
      （例：ユーザインタビュー、データ分析、施策概要、勝利条件）

  • 要件・仕様

    • システム要求:
      • デザイン要求:
        インターフェースや操作性、ワイヤーなど、ユーザ体験を実現するための設計指針（ユーザ要求から導かれるが、実装上はシステム要求に含んでおく）。
      • 機能要求:
        エンジニアが実装すべき具体的な機能や操作フロー。
      • 非機能要求:
        品質、性能、セキュリティなどの制約条件。

6. まとめ

  • 用語のあいまいさの排除:
    要望、要求、要件、仕様の各フェーズの定義を明確にし、段階的に具体化することが不可欠である。

  • 初期段階の明確化:
    ビジネス要求とユーザ要求として整理し、プロダクトビジョンや戦略、顧客の課題を具体化する。

  • 最終段階の具体化:
    ユーザ要求を実現するため、ユーザ体験とシステム内部で満たすべき要求（デザイン要求、機能要求、非機能要求）を明確なシステム要求として具体化する。

  • アジャイルによる反復的明確化:
    特に新規事業など、ユーザ要求の完全な明文化が難しい場合は、短いイテレーションと顧客フィードバック (アジャイル開発)を通じて要求を段階的に洗練させる。

  • 統一的な構造サマリ:

    • 要望・要求 ->【ビジネス要求】【ユーザ要求】
    • 要件・仕様 ->【システム要求】
      （システム要求は【デザイン要求】【機能要求】【非機能要求】に分かれる）

このアプローチにより、要求定義の各フェーズでどこが不明瞭なのかを捉え、関係者間の共通認識を形成していけると良い。

参考

Discussion