基本設計とは？工程の目的と位置づけ

要件定義との関係：なぜ基本設計が必要なのか

基本設計とは、要件定義で整理された機能や要件をもとに、実際にシステムとして実現するための設計方針を具体化する工程です。ウォーターフォール型の開発では「要件定義で一旦整理した内容」を前提に進めますが、実務上は基本設計の途中で要件の見直しや追加が入ることも少なくありません。
要件定義が「何を実現するか」を定義するのに対し、基本設計では「どのように実現するか」をユーザー視点で整理します。

たとえば、要件定義の段階で「売上データを集計できる仕組みが欲しい」と記載されていても、

・どの単位で集計するのか（期間別／部門別）

・どのように表示・出力するのか（画面表示／CSV出力）

・誰が利用するのか（管理者／一般社員）

が明確になっていなければ、詳細設計や実装で齟齬が発生します。

このような曖昧さを解消し、開発者・ユーザー双方が同じ方向を向けるようにするのが、基本設計の役割です。

この工程を省略して詳細設計に進むと、システム全体の構成や仕様に不整合が生じるリスクが高まり、後工程で大きな手戻りが発生する可能性があります。
基本設計は要件定義を実装へと橋渡しする「設計の設計」として欠かせない工程です。

詳細設計との違いと境界の考え方

基本設計と詳細設計の違いは、設計の粒度にあります。
基本設計では、システム全体の構造・データの流れ・画面や帳票の設計など、外部仕様レベルでの設計を行います。
一方、詳細設計では、実際にコーディング可能なレベルまで掘り下げた内部仕様を定義します。

簡単に言えば、基本設計は「ユーザーが触れる部分をどのように見せるか」を中心に、システム全体の構成やデータの流れなど“外部仕様レベル”を決める段階です。

一方、詳細設計は、それを実装できるようにプログラム単位の内部仕様まで落とし込む段階です。

この境界線をあいまいにすると、実装時に「どの資料を参照すればいいのか」が不明確になり、結果としてドキュメントが形骸化するケースもあります。

プロジェクト初期に「基本設計のスコープ」をチーム内で共有しておくことが重要です。

基本設計のアウトプットで決まること

基本設計のアウトプットでは、以下の要素が明確になります。

• システム全体の構成（サブシステム・モジュール構造）
• 画面・帳票・インターフェースの仕様
• データ設計の基本構造（テーブル・項目定義）
• 非機能要件（セキュリティ、性能、可用性など）

プロジェクト規模や開発プロセスにもよりますが、APIの設計方針（RESTかGraphQLか）、共通コンポーネントの利用ルール、ログ・監査の設計方針などを、基本設計またはアーキテクチャ設計の段階で方向性として固めておくと、後工程の手戻りを大幅に減らせます。

これらを明確にすることで、開発者・テスター・顧客間の共通理解を確立し、後工程の詳細設計・実装・テストをスムーズに進めることができます。

基本設計の主な成果物一覧

機能設計書・画面設計書

機能設計書は、要件を満たすためにどの機能をどの画面で提供するかを定義する成果物です。

UI/UXの設計を含め、ユーザー操作の流れを明確にすることが目的です。

ワイヤーフレームや画面遷移図を用いることで、ユーザーと開発側の認識を揃えやすくなります。

最近では、FigmaやAdobe XDなどのデザインツールで画面設計を行い、そのまま基本設計書にリンクを埋め込む手法も増えています。

「ドキュメント」と「実際のUIプロトタイプ」を一体化させることで、設計と実装の乖離を防ぐ効果があります。

外部インターフェース設計書・帳票設計書

他システムとの連携仕様や、出力帳票の形式を定義するのがこれらの成果物です。
データ項目、通信方式、エラーハンドリング方法などを明確にすることで、結合テストや本番運用時の不具合を未然に防ぐことができます。
帳票設計書は、請求書やレポートなどの出力イメージを含め、実際の業務フローに直結する重要な設計資料です。

帳票仕様が曖昧なまま開発が進むと、納品直前に「出力されるExcelフォーマットが違う」といった手戻りが起きやすいため、基本設計段階で帳票サンプルを確定させるのが理想です。

非機能要件設計書（性能・セキュリティなど）

非機能要件設計書は、性能要件（処理速度・同時接続数など）やセキュリティ要件（アクセス制御・暗号化方式など）を具体的な構成・方式として整理するドキュメントです。

非機能要件の目標値や制約（例：稼働率99.9％、同時接続〇〇件など）は本来は要件定義段階で整理しておき、基本設計では「その要件をどのような構成・方式で満たすか」を具体化していきます。監視・ログ出力・障害復旧手順といった「運用設計」もこの段階で方向性を定義しておくと、リリース後の安定運用につながります。

基本設計成果物の目的と作成ポイント

成果物を作る目的：品質・共有・再現性

成果物は単なるドキュメントではなく、設計の品質を保証し、チーム全体で共通認識を持つためのツールです。

明確な成果物があれば、設計者が変わっても同じ品質で再現でき、システムの保守や改修もスムーズに行えます。

基本設計書はレビュー・監査・後工程の教育資料としても利用されます。

「読む人」が誰か（開発者か、顧客か、品質管理担当か）を意識した構成にすることが、成果物の価値を高めるポイントです。

作成時のポイント：粒度・形式・レビュー性

基本設計書を作成する際は、以下の3点が重要です。

• 粒度：後工程で迷わないレベルまで具体化する
• 形式：チーム全体で統一されたテンプレートを使用する
• レビュー性：第三者が理解できる明瞭な構成にする

特に、レビュー性を意識した構成は、開発効率を大幅に向上させます。レビューの際には、「なぜこの仕様にしたのか」という設計意図をコメントとして残すと、後からの変更時に判断が容易になります。

成果物テンプレートの活用方法

社内標準や過去プロジェクトのテンプレートを活用すると、ドキュメント品質の平準化が可能です。
成果物一覧を整理し、目的別にフォーマットを用意しておくことで、設計作業を効率化できます。

基本設計と詳細設計の関係性を理解する

設計の分業とトレーサビリティの確保

基本設計の成果物は、詳細設計や実装工程の基礎となる“共通言語”です。
設計工程を分業化する際は、各成果物間の**トレーサビリティ（追跡可能性）**を確保することが極めて重要です。
これは、要件定義 → 基本設計 → 詳細設計 → 実装 → テストの各工程で、どの要件がどの設計要素に対応しているかを明確にしておく仕組みを指します。

たとえば、要件管理ツール（Jira、Backlogなど）や設計書管理ツール（Confluence、SharePointなど）を活用すれば、
「この機能要求はどの画面設計に対応しているのか」「このDB項目はどのAPI仕様で使われるのか」といった紐付け運用を構築しやすくなります。

適切なルールや運用フローを整えることで、仕様変更時の影響範囲を追跡しやすくなります。
これにより、仕様変更や要件追加が発生した場合でも、影響範囲を正確に特定でき、手戻りを最小限に抑えられます。

基本設計の成果が詳細設計にどう引き継がれるか

基本設計は、いわば「設計全体の骨格」を定める工程です。
詳細設計では、それを基にプログラム単位で内部ロジックを定義していきます。
たとえば、基本設計書に「顧客情報管理機能」として以下の項目が定義されていた場合：

• 顧客情報の登録・更新・削除
• 顧客ランクの自動判定
• 顧客データのCSV出力

詳細設計では、これらの要件を具体的に「どの関数・クラスで処理するのか」「どのテーブルに格納するのか」まで落とし込みます。
このとき、基本設計書の機能構成図や画面遷移図、ER図などが整備されていると、詳細設計作業がスムーズに進みます。

逆に、基本設計段階で仕様の粒度が曖昧だった場合、後工程で不整合が発生しやすく、プログラマ個人の解釈による“仕様のズレ”が生じるリスクがあります。
したがって、両工程の間には**「明確な引き継ぎルール」**を設けることが重要です。
たとえば、「基本設計書の章立てに合わせて詳細設計書を構成する」「設計レビュー時に双方の整合性を確認する」といった運用が効果的です。

設計工程間のレビューの重要性

基本設計書は、システム開発の方向性を定める“契約書”のようなものです。
そのため、レビューを形式的に終わらせず、実際に開発や運用を想定した視点から検証する必要があります。

レビューの観点には、以下のようなポイントがあります。

• 要件定義で示された機能がすべて網羅されているか
• 各画面やAPIの入出力が整合しているか
• 処理の流れがユーザー体験や業務プロセスに適しているか
• 非機能要件（セキュリティ・性能・可用性など）に具体的な設計対応があるか

また、レビュー工程には開発者だけでなく、テスト担当者・運用担当者も参加すると、実行性の高い設計に仕上がります。
「設計者が正しいと思って書いたが、テスト時に実現できない」――こうしたギャップを事前に解消できるのが、クロスレビューの大きな利点です。

現場で使える基本設計成果物の作成フロー

成果物一覧の作成手順とWBSへの落とし込み

プロジェクト開始時に、基本設計で作成すべき成果物一覧を明確に定義し、WBS（作業分解構造）に落とし込みましょう。

作業スコープが可視化されることで、タスクの漏れ防止やスケジュール精度の向上が期待できます。

ドキュメント管理・レビュー体制の構築

基本設計書・詳細設計書は、一度作って終わりではありません。
開発が進むにつれて仕様変更や機能追加が発生するため、ドキュメントを“生きた設計書”として継続的に更新管理する体制が求められます。

おすすめの運用方法としては：

• バージョン管理ツール（Git、SVNなど）でドキュメントを管理
• 承認フローを設け、変更時に必ずレビュー・承認を通す
• 差分を明示できる形式（Markdown、Confluenceなど）を活用

こうしたルールを設けておくことで、プロジェクト全体の透明性が高まり、属人化を防止できます。

成果物品質を高めるチェックリスト例

成果物の品質を担保するためには、形式的なテンプレートだけでなく、実務に即したチェックリスト運用が効果的です。
以下の観点をベースに、プロジェクト特性に応じてカスタマイズして運用するとよいでしょう。

1. 構造・整合性チェック

• 設計書の章立てや命名規則が統一されているか
• 図・表・データ定義が他文書と矛盾していないか
• 機能構成とデータフローが論理的に整合しているか

2. 内容の妥当性チェック

• 要件定義の全項目が設計内に反映されているか
• 想定外のケース（例外処理・異常系）が考慮されているか
• パフォーマンス・セキュリティ要件に具体的な対策が記載されているか

3. 運用・保守視点のチェック

• 将来の拡張・改修を見越した設計になっているか
• ログ設計・監視設計など運用に必要な項目が含まれているか
• テスト仕様書・マニュアルとの整合性が保たれているか

4. ドキュメント品質チェック

• 図表や説明が第三者にも理解できる粒度か
• 用語の使い方・フォーマットが一貫しているか
• 変更履歴が記録されているか

こうしたチェックをプロジェクトごとにレビューシート化しておけば、品質の均一化と再現性の高いドキュメント作成が可能になります。

まとめ

基本設計は、システム開発の方向性と品質を決める重要な工程です。
この段階で構成や仕様を明確にしておくことで、後工程の手戻りを防ぎ、開発全体をスムーズに進められます。

成果物を作る目的は「形式を整えること」ではなく、チーム全体で共通理解を持ち、再現性のある開発を行うことです。
テンプレートやチェックリストを活用し、レビュー体制を整えることで、品質と効率の両立が実現します。

これから設計を学ぶ方は、まず「なぜこの成果物が必要なのか」を理解することから始めましょう。
現場のエンジニアや管理者は、既存の設計プロセスを見直し、より実践的で共有しやすい形に整えることで、プロジェクト全体の完成度を高められます。