「詳細設計書を確認してください」と言われても、何を見ればよいのか迷いますよね。
詳細設計では、画面や機能を実際に動かすために、プログラム内部の処理を具体化します。この記事では、ネットショップの商品検索を例に、基本設計との違いや決める内容、設計書の確認ポイントを解説します。
💡 このページでわかること
- 詳細設計の意味と、基本設計との違い
- 商品検索を例にした、内部処理の具体化
- データ・エラー処理・単体テストとの関係
- 詳細設計の進め方と、設計書の確認ポイント
詳細設計とは？
詳細設計とは、基本設計などで決めた仕様をもとに、実装に必要な内部の処理やデータの扱いを具体化する作業です。実装とは、プログラムや設定を使って、設計したものを動く形にすることです。
たとえば、「商品名と価格帯で商品を検索できる」という機能について、入力内容の確認、商品データの取得、画面へ返す結果の作成を、プログラム内でどう組み立てるかを考えます。
目的は、実装する人が処理の意図や守るべき条件を理解し、テストで確かめられる状態にすることです。処理の抜けや矛盾を見つけやすくし、後から修正するときの手がかりにもなります。
設計の結果を詳細設計書にまとめることはありますが、詳細設計という作業と、詳細設計書という資料は別のものです。資料の名前や形式、どこまで詳しく決めるかは、会社やプロジェクトによって異なります。
基本設計と詳細設計の違い
基本設計と詳細設計は、どちらも要件を実現する方法を考える作業です。主に、具体化する対象と詳しさが異なります。
| 比較する点 | 基本設計 | 詳細設計 |
|---|---|---|
| 主な役割 | 要件をどのような画面や仕組みで実現するか具体化する | 実装に必要な内部の処理をさらに詳しくする |
| 商品検索の例 | 入力欄、結果一覧、入力誤りや該当商品がない場合の表示を決める | 入力の確認、データの取得、表示用の結果作成をどう組み立てるか決める |
| 確認したいこと | 必要な機能や使い方が、関係者の認識と合っているか | 決めた仕様を実装でき、各処理の動きを確かめられるか |
基本設計は画面の見た目だけでなく、扱うデータやシステム全体の仕組みも対象になります。詳細設計は、それらを踏まえて実装に近い内容へ具体化します。
ただし、表は役割を理解するための例であり、工程の境界を固定するものではありません。 入力を受け付ける条件や検索結果の並び順などは、要件定義や基本設計で決まっている場合もあります。
たとえば、「価格の下限が上限を超えたら、入力を直す案内を表示する」と決まっていれば、詳細設計では、その判定をどの処理で行い、画面へどう結果を渡すかを具体化します。
基本設計と詳細設計を分けない場合や、機能ごとに設計・実装・確認を繰り返す場合もあります。
具体例｜商品検索の内部処理を設計する
商品名と価格帯で検索するネットショップを例に考えましょう。
基本設計では、検索結果に商品の名前・価格・画像・在庫状況を表示し、商品を選ぶと詳しい情報へ進めるようにすると決まっているものとします。該当商品がない場合や、価格の下限が上限を超える場合の案内も決まっています。
ここでは説明用に、関係者と次の条件も確認できているとします。
- 商品名は、入力した文字を含む商品を探す
- 価格は円単位の0以上の整数とし、下限・上限の金額を含めて探す
- 空欄の項目では条件を絞らない
- 結果は価格の安い順にし、同額なら商品を識別する番号の小さい順にする
これらは商品検索に共通する決まりではなく、この例で採用した仕様です。未決定の条件は、設計担当者が独断で補わず、関係者と確認します。
決めた仕様を内部の処理へ具体化する
利用者が商品名に「シャツ」、価格の下限に「2000」、上限に「5000」と入力した場合を考えます。
| 処理 | 詳細設計で具体化する内容の例 |
|---|---|
| 入力を受け取る | 商品名、価格の下限・上限を受け取る。空欄と金額の0を区別する |
| 入力を確認する | 入力された価格が0以上の整数として扱えるか確認し、下限と上限の両方がある場合は大小関係を確認する |
| 商品を探す | データを保存・検索する仕組みである「データベース」から、名前に「シャツ」を含み、価格が2,000円以上5,000円以下の商品を取り出す |
| 結果を返す | 決められた並び順になるよう取得処理を組み立て、名前・価格・画像・在庫状況と、詳細表示に必要な商品番号を画面へ渡す |
さらに、これらをどのプログラムの部分が担当するか、部分同士で何を渡すかを決めます。表の1行が、そのまま1つのプログラムになるとは限りません。
実際の設計では、大量の結果を何件ずつ表示するかや、必要な速さで検索できるかなども検討します。ここでは、基本の流れに絞っています。
入力の誤り・0件・処理の失敗を分ける
正常に商品が見つかる場合だけでなく、次のような分岐も具体化します。
| 状況 | 内部の処理と画面への伝え方の例 |
|---|---|
| 下限が上限を超えている | 商品を探す処理へ進まず、入力誤りの情報を画面へ返し、修正を案内する |
| 条件に合う商品が0件 | 検索は正常に完了したものとして、空の検索結果を返す。画面には「条件に合う商品がありません」と表示する |
| データベースに接続できない | 検索失敗を画面へ伝え、利用者向けの案内を表示する。内部には原因調査に必要な記録を残す |
「商品が見つからない」と「検索できなかった」は別の結果です。接続の失敗を0件として扱うと、利用者は条件を変えても検索できない理由が分かりません。
失敗時の処理は、成功した処理の最後に必ず行うものではなく、問題が起きた箇所から分かれる処理として考えます。
詳細設計で決める代表的な内容
商品検索以外でも、処理・データ・失敗時の動きをつなげて考えることが大切です。
プログラムの役割と処理の流れ
大きな機能を扱いやすい部分に分け、それぞれが何を担当するかを決めます。処理する順番や、条件によって進む先が変わる箇所も具体化します。
商品検索なら、入力確認、商品データの取得、表示用の結果作成などが考えられます。役割を整理すると、どこを実装・確認するのか、変更がどこに影響するのかを追いやすくなります。
データの形式と受け渡し
プログラムが受け取る情報と返す情報について、項目や形式、値の扱いを決めます。
たとえば、価格を数値として扱うことに加え、「下限が指定されていない状態」と「下限が0円の状態」を区別できるようにします。プログラムの部分ごとに空欄の意味が違うと、検索条件を正しく伝えられません。
データベースに保存する表や項目、保存できる値の種類・範囲を詳しく決めることもあります。ただし、データベースの設計をすべて詳細設計で行うとは限りません。すでに決まっている構造やルールを確認し、それに合わせます。
エラー処理と記録
処理に失敗した場合に、どこで処理を止め、呼び出した側へ何を返し、どの情報を記録するかを決めます。
利用者への案内と、調査担当者が見る記録は分けて考えます。利用者には状況や次に取れる行動を伝え、内部では発生時刻や失敗した処理などを記録します。このような記録を「ログ」と呼びます。
内部の詳しいエラー情報をそのまま画面へ出したり、パスワードなどの秘密情報をログへ残したりしないようにします。表示内容が基本設計で決まっている場合は、その表示につながる判定と情報の受け渡しを具体化します。
単体テストで確かめる条件
単体テストとは、個々のプログラムの部品が、単独で意図した動きをするか確かめるテストです。詳細設計で入力と結果を具体化しておくと、何を確かめるべきか考えやすくなります。
たとえば、価格の入力を確認する部分なら、次のように整理できます。
| 入力の例 | どうなればよいか |
|---|---|
| 下限2000、上限5000 | 正しい条件として扱う |
| 下限5000、上限2000 | 入力誤りとして扱う |
| 下限2000、上限2000 | 同じ金額の範囲として受け付ける |
| 価格に「abc」を入力 | 金額として扱えない入力を知らせる |
| 下限が空欄／下限が0 | 「下限の指定なし」と「0円以上」を区別して渡す |
設計書だけでなく、要件や基本設計とも照らして、正しい結果を決めることが大切です。設計自体に誤りがあれば、その誤りをテストでも見逃すおそれがあります。
また、画面から実際のデータベースまでつないだ検索全体の確認を、すべて単体テストと呼ぶわけではありません。部品同士の連携やシステム全体の動きは、結合テストやシステムテストでも確かめます。
詳細設計の進め方と設計書のまとめ方
進め方はプロジェクトによって異なりますが、次のように整理できます。
- 要件と基本設計を確認する：何を実現し、どの条件を守る必要があるかを確認する。
- 内部の処理を具体化する：各部分の役割、処理の順番、データの受け渡し、失敗時の動きを決める。
- 共有できる形に残す：文章、表、処理の流れを示す図などにまとめる。
- 関係者と確認する：抜けや矛盾、実装の難しい点を確認し、必要な修正を行う。この確認を「レビュー」と呼ぶ。
詳細設計書には、プログラムの構成、処理の流れ、入出力の項目、データの構造、エラー時の対応などを記載します。すべてを1冊にまとめる必要はなく、設計ツールや複数の資料で管理することもあります。
レビューでの指摘を直すだけでなく、要件や基本設計、関連する機能との整合も確かめます。実装中に設計の変更が必要になった場合も、影響を関係者と確認し、資料やテストを更新します。
初心者が詳細設計書を確認するポイント
最初は機能を1つ選び、次の順に追うと理解しやすくなります。
- どの要件や基本設計を実現する設計か
- 何を入力として受け取るか
- どの部分が、どの順番で処理するか
- 正常な場合に何を返し、入力誤りや失敗の場合にはどうするか
- ほかの機能や資料と、項目名・形式・条件が食い違っていないか
「適切に処理する」「必要に応じて記録する」だけでは、人によって解釈が変わります。「下限が上限より大きいとき、検索を止めて何を返しますか」のように、条件と結果をセットで確認しましょう。
書かれていない内容があっても、すべて不足とは限りません。共通ルールや別の資料で決まっている場合があります。まず参照先を確認し、不明な点は担当者へ相談します。
詳細設計でよくある疑問
詳細設計書を見れば、誰でも同じコードを書けますか？
同じコードになるとは限りません。同じ仕様を満たす書き方が複数あるためです。
大切なのは、処理の目的と守るべき条件が伝わり、チームのルールに沿って実装・確認できることです。設計の詳しさは、使う技術や担当者の分担などに合わせます。
詳細設計書は必ず必要ですか？
「詳細設計書」という名前の独立した文書が、すべての開発で必要なわけではありません。短い資料や図、コードなどを組み合わせて設計内容を共有する場合もあります。
ただし、契約や組織のルールで作成が必要な場合は、それに従います。形式にかかわらず、後から処理の意図や変更理由を確認できるように残すことが大切です。
まとめ
詳細設計は、基本設計などをもとに、内部の処理やデータの扱いを実装・確認できるところまで具体化する作業です。
- プログラムの役割、処理の順番、データの受け渡しを具体化する
- 入力の誤り、検索結果0件、処理の失敗などを区別する
- 単体テストで確かめる入力と結果を考える材料になる
- 基本設計との境界や資料の形式、作業の進め方はプロジェクトによって異なる
設計書を読むときは、まず1つの入力から処理と結果を追い、「何を、どう実現するのか」を確認してみましょう。