詳細設計とは？目的と決めることをわかりやすく解説

はじめに

基本設計で注文履歴の表示項目や検索機能を決めても、実装に必要な判断がすべて終わったわけではありません。

入力された検索条件をどこで確認するのか、どの処理が注文情報を取得するのか、取得したデータをどのような形式で画面へ返すのかを決める必要があります。これらを決めずに実装を始めると、担当者によって処理の分け方やエラーへの対応が異なってしまいます。

こうした実装上の判断を、プログラムを作り始める前に整理する必要があります。

詳細設計とは、基本設計で決めた仕様を、実装に必要な内部構造や処理へ具体化する工程です。

基本設計では、利用者や他システムから見た仕様を決めます。詳細設計では、その仕様をどの処理が担当し、どのようなデータを受け渡し、どの条件で処理を分けるのかを決めます。

詳細設計の目的は、機能の実現方法に影響する主要な判断を共有し、担当者が変わっても同じ前提で実装、レビュー、テストを進められる状態にすることです。

詳細設計で決める内容は、大きく三つに整理できます。

一つの機能は、役割の異なる複数の処理によって実現されます。

注文履歴を表示する機能であれば、検索条件を受け取る処理、入力内容を確認する処理、注文情報を取得する処理、画面へ返す情報を作る処理などが必要です。

詳細設計では、これらの処理をどの単位に分け、それぞれにどの役割を持たせるのかを決めます。必要に応じて、プログラムを構成するモジュール、クラス、メソッドなどの役割も整理します。

ここで決めるのは、機能を実現する処理の構成と、それぞれの責任範囲です。

処理の役割を分けたら、各処理がどのデータを受け取り、何を返すのかを決めます。

注文履歴であれば、認証された利用者のID、検索期間、商品名などを入力として受け取ります。その条件を使って注文情報や商品情報を取得し、注文日、商品名、個数、金額などの表示用データへ変換します。

詳細設計では、入力と出力、データを取得・更新する方法、処理間で受け渡すデータの形式などを具体化します。

ここで決めるのは、機能の内部をデータがどのように流れるのかです。

システムの処理は、常に同じ結果になるわけではありません。

例えば、検索期間が許可された範囲を超えている場合、注文履歴が存在しない場合、データの取得に失敗した場合では、それぞれ異なる対応が必要です。

検索結果が0件であることと、データを取得できなかったことを同じ結果として扱うと、利用者も運用担当者も状況を判断できません。

詳細設計では、入力値の不正、対象データの有無、処理の失敗、期間や件数の境界などを整理します。そのうえで、処理を継続するのか、結果を返すのか、エラーとして扱うのか、記録を残すのかを決めます。

基本設計では、注文履歴機能を次のように定義していたとします。

ログインした利用者は、自分の過去3年分の注文履歴を確認できる。一覧には商品名、個数、注文日、金額を表示し、日付や商品名で検索できる。

履歴がない場合はその旨を表示し、情報の取得に失敗した場合はエラーを表示する。他の利用者の注文履歴は閲覧できないようにする。

詳細設計では、この仕様を実現するために必要な内部の判断を具体化します。

基本設計で決めた仕様	詳細設計で具体化する内容
ログインした利用者が自分の履歴を確認できる	認証情報から利用者IDを取得し、注文情報の取得条件に必ず含める
過去3年分を確認できる	検索開始日と終了日を受け取り、許可された期間内か確認する
日付や商品名で検索できる	受け取る検索条件、未入力を許可する条件、データ取得時の検索条件を決める
商品名、個数、注文日、金額を表示する	各情報の取得元と、画面へ返すデータの形式を決める
履歴がない場合はその旨を表示する	取得件数が0件の場合に、正常な検索結果として0件を返す
情報の取得に失敗した場合はエラーを表示する	取得処理の失敗を0件と区別し、エラーとして記録して画面へ返す

詳細設計では、新しい機能を追加しているわけではありません。

基本設計で決めた一つひとつの仕様に対して、どの処理と条件によって実現するのかを対応付けています。

基本設計と詳細設計では、判断する対象の粒度が異なります。

観点	基本設計	詳細設計
主な問い	何を作るか	どう作るか
主な対象	画面、機能、データ、外部連携、権限、性能条件	処理の分担、入出力、データの流れ、分岐条件、エラー時の処理
外部から見える内容	利用者や他システムから見た仕様	原則として見えない内部の実現方法
次工程へ渡す内容	システムが満たすべき仕様	実装と単体テストの基準となる設計