このページについて

このページでは、以下について記載している。

• 基本設計工程の定義
• 基本設計は、いつ実行されるべきか？
• そもそも、基本設計で何をするのか？
• なぜ、私は基本設計をしなければならないのか？

---

定義

基本設計工程とは、要件定義で正式に合意された業務要件、機能要件および非機能要件を受け、システム全体の方式、アーキテクチャ、UI 等の外部仕様、データ構造、開発制約、運用方針などを設計して、以降の詳細設計・開発フェーズで用いる「開発の指針（ベースライン）」を作る工程を指す。

基本設計工程の位置づけ

システム開発において、基本設計は要件定義の次、詳細設計の前

開発ライフサイクルの中で、基本設計工程は上流工程に位置し、要件定義の次、詳細設計の前に置かれる。

基本設計の成果は主に結合テスト（integration test）の検証基準に対応する。
つまり、基本設計で定めたインターフェースやデータフローが結合テストで検証される。

プロジェクトマネジメントにおいて、基本設計は見積の精度を向上させ、安定化させる

プロジェクト管理の観点では、基本設計は以下の役割を持つ：

• スコープと主要技術選定の安定化（以降の見積り精度向上に寄与）。
• 要員・スケジュール・コスト計画（ロードマップ）に必要な入力を与える（詳細設計／開発フェーズの見積り根拠）。
• リスク（技術・運用・移行）の主要な見積りと緩和策を明示するフェーズ。

  このため、基本設計完了はプロジェクトのマイルストーン（フェーズゲート）として扱われ、承認（レビュー・ベースライン化）後に下流工程へ進む。

基本設計工程のスコープ

基本設計は「システムの全体像」を描く工程である。
システム全体の方式や構造を明確にするとともに、外部仕様（External Spec）を定義してステークホルダーと合意する。

設計成果物は後工程（詳細設計・実装・テスト）の基準となる。

すること

• システム全体方式設計（アーキテクチャ、サブシステム分割、利用技術）。
• 機能の構造化（機能ブロック／画面の主要フロー）。
• UI 設計（画面、帳票、その他UXデザイン規約）。
• 外部インタフェース設計（API仕様の高レベル、データ交換フォーマットの定義）。
• データ設計（主要エンティティ／ER図の上位レベル、重要なデータ属性）。
• 運用／移行方針（運用アーキテクチャ、バックアップ、移行の大枠）。
• 主要設計上の選択肢とトレードオフ（選定した技術と理由、残課題）。
• 基本見積りの更新と下流工程の作業分解（WBS粗粒度・見積り）。
• レビュー・承認（関係者合意の取得）、ベースライン化

基本設計工程のゴール

基本設計工程の入出力

基本設計では、要件を制約の下で、開発のベースラインに変換する

工程の入力：要件定義書(Requirement Specification)、設計規約(Design Guideline)

• 承認済みで正式に合意された要件定義書が、基本設計の主要な入力となる。
• プロジェクトに設計規約（UI ガイドラインや技術標準など）がある場合は、それらも設計時に考慮に入れる必要がある。

工程の出力：基本設計書(Base Desgin Document)

• 📄2.3.2 基本設計書とは？

なぜ、適切な基本設計が重要なのか？

下流工程の手戻りとコスト増大を防ぐ

基本設計でインターフェースやデータ構造を明確にしないと、実装中や結合テストで重大な不整合が発覚し、手戻りが発生する。これはコストと納期に直結する。

基本設計書は次工程のベースラインとなり、開発するスコープと仕様を定義する。ベースラインからの変更は、変更管理プロセスで管理される。

見積りと計画の精度を高める

基本設計により技術的な不確実性が低下する。そのため、要員計画や工数見積りが現実的になり、計画的なマネジメントが可能になる。

品質の確保と検証の効率化

結合テストやシステムテスト時に「何を検証すべきか」が明確になるため、品質検証が効率的になる。

ステークホルダー合意の確立

画面、帳票、システム間連携などの外部仕様や、運用・セキュリティなどの非機能要素を、基本設計段階でステークホルダー間で合意しておく。これにより、本番導入時の齟齬や受け入れ拒否のリスクを下げられる。

---

次のページ → 🚧外部仕様と内部仕様の区別