「基本設計を確認してください」と言われても、何を見ればよいのか迷いますよね。
基本設計は、要件定義で決めた必要なことや条件を、画面、機能、データの扱い、システムの仕組みへ具体化する作業です。
この記事では、ネットショップの商品検索を例に、基本設計で決める内容と、要件定義・詳細設計との違いを解説します。
💡 このページでわかること
- 基本設計の意味と目的
- 基本設計で決める内容と具体例
- 要件定義・詳細設計との違い
- 基本設計書の使い方と確認するポイント
基本設計とは？
基本設計とは、要件定義で決めた内容を、どのような画面や仕組みで実現するか具体化する作業です。
たとえば、「商品名や価格帯で商品を検索できる」という要件があっても、それだけでは入力欄や結果の表示方法までは分かりません。そこで、利用者が何を入力し、どのような結果を受け取るかを設計します。
画面だけでなく、扱うデータや、ほかのシステムとの情報のやり取り、システムを構成する各部分の役割を決めることもあります。
基本設計の目的は、関係者が完成イメージを確認し、より細かな設計や実装へ進めるようにすることです。実装とは、プログラムや設定を使って、設計したものを動く形にする作業を指します。
なお、「基本設計」の名前や範囲は会社・プロジェクトによって異なります。「外部設計」と呼ぶ場合もありますが、常に同じ意味とは限りません。
要件定義・基本設計・詳細設計の違い
3つの違いは、主に「何を決めるか」です。商品検索を例にすると、次のように整理できます。
| 工程 | 主に決めること | 商品検索の例 |
|---|---|---|
| 要件定義 | 何が必要か、どの条件を満たすか | 商品名と価格帯で商品を検索できるようにする |
| 基本設計 | 要件をどのような画面や仕組みで実現するか | 入力欄、結果一覧、画面の移動、該当商品がない場合の表示を決める |
| 詳細設計 | 実装に必要な内部の処理を、さらに詳しく決める | 入力を確認し、条件に合う商品データを取り出し、表示用にまとめる処理の組み立てを決める |
要件定義では、依頼側と開発側が必要なことや条件を整理し、合意します。基本設計と詳細設計では、それを実現する方法を段階的に具体化します。
ただし、表は役割を理解するための例であり、工程の境界を固定するものではありません。 画面や入力条件を要件定義で詳しく決める場合もあれば、基本設計と詳細設計を分けない場合もあります。
たとえば、入力ミスを利用者へどう知らせるかは基本設計で扱い、その判定処理をプログラム内にどう組み込むかは詳細設計で扱うことがあります。「エラーはすべて詳細設計で決める」とは限りません。
要件の集め方や合意の進め方は、要件定義の意味と進め方で詳しく解説しています。
具体例｜ネットショップの商品検索
「商品名や価格帯で商品を検索できる」という要件を、基本設計で具体化してみましょう。以下は説明用の例です。
| 確認すること | 設計の例 |
|---|---|
| 何を入力するか | 商品名と、価格の下限・上限を入力できるようにする |
| いつ検索するか | 検索ボタンを押すと、入力した条件で検索する |
| 何を表示するか | 条件に合う商品の名前、価格、画像、在庫状況を一覧にする |
| 次に何ができるか | 商品を選ぶと、その商品の詳しい情報を表示する |
| 商品が見つからないとき | 「条件に合う商品がありません」と表示し、条件を変えて検索できるようにする |
| 入力に誤りがあるとき | 価格の下限が上限を超えていたら、入力を直す案内を表示する |
こうして具体化すると、依頼側は「この画面で必要な商品を探せそうか」、開発側は「何を作る必要があるか」を確認しやすくなります。
入力欄を空にしたときの扱いや、検索結果の並び順なども確認が必要です。すでに要件で決まっている内容は設計に反映し、未決定の内容は関係者と確認します。設計する人が独断で必要な機能を増やすわけではありません。
基本設計で決める代表的な内容
基本設計の内容は、画面のあるシステムか、ほかのシステムと連携するかなどによって変わります。代表的な内容を見てみましょう。
画面と操作の流れ
入力欄、表示する情報、ボタン、画面間の移動などを決めます。画面の見本や、画面同士のつながりを示す図にまとめることがあります。
見た目だけでなく、利用者が目的の作業を完了できるかを確認します。
機能の動き
検索、登録、変更、削除などについて、どの条件で何が起こるかを整理します。
正常に動く場合に加え、入力不足や処理の失敗が起きた場合の扱いも検討します。注文を受け付けられなかったときに、利用者へ何を伝えるかも設計の一部です。
データの扱い
保存する主な情報と、その関係を整理します。ネットショップなら、顧客、商品、注文を結び付け、誰が何を注文したか分かるようにします。
データを保存・検索する仕組みである「データベース」の細かな構造をどこまで決めるかは、プロジェクトによって異なります。
システムの構成と外部との連携
システムをどのような部分に分け、それぞれが何を担当するかを整理することがあります。たとえば、画面の表示、注文の処理、データの保存といった役割です。
決済サービスなどと連携する場合は、いつ、どの情報を送り、どの結果を受け取るかを決めます。相手から返事がない場合や、支払いに失敗した場合の扱いも確認します。
利用できる範囲や品質を保つ仕組み
「権限」とは、誰が何を見たり操作したりできるかという範囲です。たとえば、一般の購入者には自分の注文だけを表示し、店舗スタッフには担当する注文を表示する仕組みを考えます。
速さ、安全性、使いやすさなどの条件を、設計でどう満たすかも検討します。条件そのものを決める要件定義と、その実現方法を考える設計をつなぐ部分です。これらを別の設計書にまとめる場合もあります。
基本設計書は誰が、何に使う？
基本設計書は、設計した内容を関係者で共有するための資料です。1冊にまとめる場合も、画面・機能・データなどに分ける場合もあります。
関係者で完成イメージを確認する
業務を知る人や利用者は、画面や操作の流れが仕事に合っているかを確認します。設計・実装担当者は実現できるか、運用担当者は利用開始後も扱えるかを確認します。
このように内容を読み合わせて、抜けや食い違いを探す確認を「レビュー」と呼びます。担当者の分け方はプロジェクトによって変わります。
詳細設計・実装・テストにつなげる
開発担当者は基本設計書を手がかりに内部の処理を詳しく決め、プログラムなどを作ります。テスト担当者は、入力に対してどのような結果になればよいかを考える材料にします。
ただし、設計書どおりに作るだけで、必要なシステムになるとは限りません。設計自体が要件を満たしているかも確認します。利用開始に向けた受入テストでも、利用者の目的や、受け入れてよいと判断する条件に照らして確かめます。
設計を変更したら、関連する機能、データ、テストへの影響を調べ、必要な資料も更新します。
初心者が基本設計書を確認するポイント
最初は、機能を1つ選び、次の順に追うと理解しやすくなります。
- どの要件を実現する機能かを確認する
- 誰が、どの場面で使うかを考える
- 入力や操作から、表示・保存される結果までを追う
- 入力ミスや処理の失敗が起きたときの動きを見る
- 別の画面や資料と、項目名・条件が食い違っていないか確認する
「普通に表示する」「必要に応じて処理する」では、人によって受け取り方が変わります。分からないときは、「何を入力したら、何が表示されるのですか」のように、具体的な場面で確認しましょう。
基本設計でよくある疑問
基本設計書に共通の書式はありますか？
すべての会社で共通する1つの書式はありません。会社の標準や開発するシステムに合わせて、必要な資料を用意します。書式を埋めることより、決めた内容が関係者に伝わることが大切です。
一度決めた設計は変更できますか？
変更できます。ただし、実装、テスト、費用、期限などへ影響する可能性があります。理由と影響を確認し、関係者で合意して記録します。要件にも影響する場合は、要件から見直します。
まとめ
基本設計は、要件定義で決めた内容を、画面や機能、データ、システムの仕組みへ具体化する作業です。
- 要件定義では、必要なことや満たすべき条件を整理して合意する
- 基本設計では、それを実現する画面や仕組みを具体化する
- 詳細設計では、実装に必要な内部の処理をさらに詳しくする
- 基本設計は画面だけに限らず、扱う範囲や詳しさはプロジェクトによって変わる
設計書を見るときは、まず「どの要件を、どのように実現する設計か」を追ってみましょう。