要求定義 (Request Definition)

概要#

• ソフトウェア開発プロセスという記事の子要素となる記事です。
• 要求定義の進め方とアウトプットの例を説明します。
• 要求と要件を区別せずに使っている人が多いので要注意です。
  • 要求は、発注側が「何をしたいか」を表したもの。
  • 要件は、その要求を開発側が実現可能な形に具体化したもの。
  • 本記事で扱うのは前者の要求です。

要求定義とは#

• 発注側が何をしたいのかを形に表した図や書類です。
  • ビジネス側の人が頭の中で思い描いているゴールを、図やドキュメントに書き起こす作業です。
• 図やドキュメントに書くことで、空中戦の議論ではなく、図やドキュメントをベースとしたディスカッションを行えるようになります。
• 図をベースに議論することで、MECEな視点でエンティティを捉えられるようになり、欠陥も見つけやすくなります。
• 作るのはビジネス責任者です。
• 書き方やディスカッションにはプロダクト開発の責任者もアドバイザとして参加し、クリティカルシンキングを用いて質問することで、具現化や問題のあぶり出しを行います。

アウトプット例#

• ユースケース図
  • 頭の中で思い描けているため普通はドキュメントとして残さないかもしれませんが、必須です。
  • 途中からプロジェクトに参加した人への引き継ぎや、ビジネスサイドとプロダクトサイドでゴールを共通化するために使います。
  • 5分から10分で書ける図なので、コストパフォーマンスは高いです。
  • 以下にユースケースの例を貼り付けます。
    • とあるシステムのユースケース図です。
    • シンプルなので図を書くほどではないと思われがちですが、情報量はとても多いです。システムのステークホルダーが明確になり、どのようなインタラクションがあるかが一目でわかります。
    • これは、もっとも抽象度の高いユースケースです。各アクターごとにユースケースを整理した図を書いても良いでしょう。
  • UMLはAstah UMLを使っています。
    • 個人向けは期間ライセンスで、3ヶ月¥3,300・6ヶ月¥5,940・1年¥10,120（いずれも税込、2026年5月時点）です。コストパフォーマンスが高いので導入する価値があります。
    • Cacooやdraw.ioもあります。Cacooは執筆当時は無料枠がありましたが、現在は有料（スペースプラン¥19,800/月、30日間の無料トライアルのみ）です。いずれにしても、追加・変更の操作性はAstahが一番です。

ユースケース図の例

• 要求定義書
  • ユースケースを見ればシステムのゴールはおおよそわかるので、ユースケースで網羅できない機能などはドキュメントで補足します。
  • スコープ
    • 予算
    • 期間
      • 場合によってはマイルストーン
    • ユーザ数
    • 対応端末
      • アプリ、Web、PC、スマホ、ブラウザ種別
• シーケンス図
  • ユースケースだけではビジネスのフローが見えないので、正常系のメインの流れについてはシーケンス図を書いておきます。ユースケース図だけではわからないユースケースの順番がわかるようになります。
  • 上記のユースケース図と同じシステムについて、ビジネスレベルのユースケースがどのような順番で行われるかを抜き出したシーケンス図です。
  • まだ上流工程なので細かい部分は割愛し、ビジネスレベルのユースケースを決めることにフォーカスしています。この時点で、より少ないシーケンス・同期処理・インタラクションを心がけてブラッシュアップします。
  • 要求定義の段階では、同期処理・タイミング・排他・例外処理については割愛しています。
  • 明記はしませんが、このシーケンス図を見ればプロダクト開発責任者の頭の中で考えられているはずです。ビジネスサイドの合意が必要な例外処理は記載しておきます。

• 類似サービス・システムのサーベイ
  • 類似サービスがあれば、その実在するサービスを見ることでゴールを明確に想像できるようになります。
  • ドキュメントにはその差分だけを書けば良いので、ドキュメンテーションのコストをかなり減らせます。

要求定義のゴール#

• プロジェクト責任者の合意
• ビジネス責任者の合意
• プロダクト開発責任者の合意

要求定義の使われ方#

• 要求定義書をプロダクト開発責任者が合意したら、要件定義へ進みます。
• 要求定義がそのまま要件定義になることは考えづらいですが、システム開発の視点からより具体化していき、最終的にビジネス責任者と合意できれば要件定義が完成と言って良いと思います。
• このプロダクト開発に関わるビジネス関係者・開発関係者が最初に見るドキュメントになります。
• 要求定義書は、そのままRFP（Request For Proposal：提案依頼書）として流用できます。
• 自社で要件定義書を作成できない場合、ベンダーに要求定義書を渡して要件定義書を作成してもらう、といったことも可能です。

余談#

• 要件定義をRD（Requirements Definition）と略すことがありますが、Request DefinitionもRDなので、どうしてRDと略すのか謎です。略さないでください。