シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義
- システム要件定義の成果物〜設計へのインプットを作成する
- 要件定義とソフトウェアアーキテクチャ設計
- 要件定義とクラス設計
- 要件定義とデータベース設計
- 要件定義と画面設計
- 要件定義とAPI設計
- 要件定義とバッチ処理設計
- 要件とは何か
- 非機能要件とは何か
- 要件定義を学ぶ人におすすめの書籍まとめ
- 移行要件とは何か
- 要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】
- 要件定義と設計の関係を体系的に理解する【全体像まとめ】（本記事）
TRACERYプロダクトマネージャーの haru です。
システム開発において、要件定義と設計は密接に連動するプロセスです。
要件定義で整理された「何を作るか（What）」という要件を基に、設計では「どのように実現するか（How）」を具体化していきます。
本記事では、これまでの連載で解説してきた内容を整理し、要件定義と各種設計（ソフトウェアアーキテクチャ設計、クラス設計、データベース設計、画面・API・バッチ処理設計）との関係を体系的に説明します。
- 要件定義と設計の関係、全体像
- 要件定義とソフトウェアアーキテクチャ設計の関係
- 要件定義とクラス設計の関係
- 要件定義とデータベース設計の関係
- 要件定義と画面設計、API設計、バッチ処理設計の関係
- システムの視座から業務・事業の視座へ
- 最後に
要件定義と設計の関係、全体像
下図に、本連載で説明してきた要件定義と設計の関係を示します。
要件定義の目的とゴールは『設計プロセスを円滑に進めるための明確で具体的なインプットを提供すること』です。
以降で要件定義で作成された成果物をもとに、ソフトウェアアーキテクチャ設計、クラス設計、データベース設計、画面・API・バッチ処理設計といった各設計にどのようにつなげていくのかを順に解説します。
要件定義とソフトウェアアーキテクチャ設計の関係
ソフトウェアアーキテクチャは、システム構成図に示された各アプリケーションの構造を設計したものです。
コンポーネント間の連携方法、モジュールの責務分割、データの流れなど、ソフトウェア内部の構造を体系的に設計します。
この設計は、単に機能を実現するだけでなく、保守性・性能効率性・使用性・セキュリティといった非機能要件を実現することを目的とします。
適切なアーキテクチャ設計により、将来的な拡張や変更への柔軟性、安定した運用性が確保されます。
詳しくは、以下の記事をご参照ください。
要件定義とクラス設計の関係
クラスは、システム内で扱う「対象（オブジェクト）」を表現する基本単位です。
対象の性質を示す属性と、その動作を定義するメソッドによって構成されます。
クラス図は、これらのクラス同士の構造や関係を可視化したもので、システムの静的な設計構造を理解するための重要な設計図です。
その中でも、業務の中で扱う実体（顧客・注文・商品など）とその関係、業務ルールや振る舞いを表現したものを「ドメインモデル」と呼びます。
ドメインモデルは、システムが再現すべき業務の仕組みを明確にし、設計全体の中核となるモデルです。
これを適切に設計することで、業務ロジックが整理され、変更や拡張にも強い構造を実現できます。
また、ドメインモデルは要件定義と密接に結びついています。
要件定義で作成された成果物から、クラス・属性・メソッドの候補を抽出できます。
たとえば、概念モデルや機能要件からはクラスや属性を、ロバストネス図や状態遷移図からはメソッドや状態変化を導き出します。
このようにして、要件の意図をクラス図（ドメインモデル）として構造化し、業務の仕組みをシステム上で再現できる形に具体化していきます。
詳しくは、以下の記事をご参照ください。
要件定義とデータベース設計の関係
データベース設計（ER図）は、クラス図を基盤として体系的に進めることができます。
クラス図で定義されたクラスのうち、永続化が必要なものをテーブルとして設計し、属性やリレーションを具体的なスキーマに落とし込みます。
また、要件定義で作成された成果物（概念モデル、機能要件の記述、状態遷移図）は、クラス設計に反映されるだけでなく、データベース設計にも密接に関わります。
これらの要件の意図が、データ構造や制約設計にまで意図通りに反映されているかを検証することが欠かせません。
さらに、データベース設計では、性能効率、データ品質、セキュリティ、保守性といった非機能要件を十分に考慮する必要があります。
これらが軽視されると、応答遅延、データ不整合、情報漏えい、改修コストの増大など、運用上の重大な問題を引き起こすリスクが高まります。
詳しくは、以下の記事をご参照ください。
要件定義と画面設計、API設計、バッチ処理設計の関係
画面設計、API設計、バッチ処理設計はいずれも、要件定義で作成された機能要件、非機能要件一覧、システム構成図を基に進めます。
これらの設計では、システム構成図に示された技術要素（プログラミング言語、ミドルウェア、フレームワークなど）や通信方式を設計のベースとして進めます。 そのうえで、機能要件や非機能要件に定義された条件を満たすよう、処理内容・性能・セキュリティ・運用性などの観点から設計を具体化します。
処理の入力・処理・出力を設計する際には、設計プロセスで作成されたクラス図（ドメインモデル）やER図を参照し、処理とデータの整合を確保します。
また、画面設計、API設計、バッチ処理設計を進める過程で、クラスや属性・メソッドの追加・修正、テーブルやカラムの追加・修正などが発生する場合は、クラス設計やDB設計にフィードバックし、全体の設計を精緻化していきます。
詳しくは、以下の記事をご参照ください。
システムの視座から業務・事業の視座へ
設計、特に画面やAPI、バッチ処理といった機能単位の設計をする際には、その機能がどのような業務で利用され、誰の課題を解決し、事業全体としてどのような価値を生み出すのかまでを見通すことが重要です。
つまり、システムの視座*1から業務の視座へ、さらに事業の視座へと移動し、考えることが求められます（下図）。
これにより、事業の成果や顧客価値*2の創出につながるシステムを設計できるようになります。
視座を移動するためには、要件定義の重要ポイント〜要望・要求・要件を見極める - TRACERY Lab.（トレラボ）で説明したように、以下の２つの問いが有効です。
- ユースケースはなにか？（業務レベルの視座に引き上げる問い）
- その機能によって解決される問題や生まれる価値はなにか？（事業レベルの視座に引き上げる問い）
最後に
本連載で示したように、プロセスと成果物の関係を俯瞰し、頭の中に地図のように描いておくと、開発を進める中で「どの情報が足りないのか」「どの工程に戻るべきか」を素早く判断できるようになります。
それは、部分最適に陥らず、プロジェクト全体を見渡して判断する力につながります。
今回で「要件定義とはそもそも何か」全18回の連載は完結です。
本連載では、要件定義の考え方や進め方を体系的に整理し、現場で実践するための道筋を示してきました。
要件定義は、システム開発の成否を左右する重要なプロセスです。
この連載の内容が、皆さまのプロジェクトをより確かな成果へ導く一助となることを願っています。
