システム基本設計書とは
システム基本設計書(System Basic Design Document)は、要件定義で決まった「何を作るか」を受けて、「どのように作るか」を具体化する最上位の設計文書です。後続するすべての設計書(画面設計・DB設計・インターフェース設計など)はこの文書の方針に従って作成されます。
この文書が曖昧だと、担当者によってアーキテクチャの理解が異なり、詳細設計・実装フェーズで矛盾が生じます。特に大規模プロジェクトや複数ベンダーが関与する案件では、システム基本設計書が「設計の憲法」として機能します。
💡 要件定義書との違い
要件定義書は「業務的に何が必要か」を定義します。システム基本設計書は「システム的にどう実現するか」の方針を定義します。要件定義の内容を受けて、技術的な実現方法を選択・決定するのがシステム基本設計書の役割です。
① システム概要・目的
まず「このシステムは何のために存在するのか」を明確に記述します。ステークホルダー全員が同じ認識を持てる文章にすることが重要です。以下の項目を定義します。
| 項目 | 定義すべき内容 | 記述例 |
|---|---|---|
| システム名称 | 正式名称・略称・英字コード | 受注管理システム(OMS) |
| システムの目的 | 導入で解決する業務課題 | 受注処理の手動作業を自動化し、リードタイムを50%削減する |
| 利用者・ユーザー | 主要なユーザー種別・想定人数 | 営業部門(50名)・物流担当(20名)・管理者(5名) |
| 稼働開始予定 | 本番リリース目標日 | 2027年4月1日 |
| システムの位置づけ | 既存システムとの関係・後継・新規 | 既存EXCELベース運用の完全刷新。基幹システム(SAP)と連携。 |
② システム対象範囲(スコープ)
スコープの定義は「何を含むか」だけでなく「何を含まないか(Out of Scope)」を明示することが重要です。曖昧なスコープは仕様追加の温床になります。
以下の観点でスコープを定義します。
- 業務スコープ:どの業務プロセスをシステムが担うか(受注受付〜出荷指示まで、請求・入金は対象外 など)
- システムスコープ:新規開発するシステム範囲・既存システムを流用する範囲
- データスコープ:移行対象データ・移行対象外データ(何年分の履歴を移行するか)
- 組織スコープ:対象拠点・部門・組織(本社のみか、全国拠点含むか)
⚠️ よくある失敗パターン
「対象外」の記載を省略した結果、プロジェクト後半で「あの機能も含まれると思っていた」という認識齟齬が発生するケースは非常に多い。Out of Scopeリストは必ず明記し、ステークホルダーの署名を得ること。
③ アーキテクチャ方針
システム全体のアーキテクチャ方針を定義します。後続のすべての設計判断がここで決まる方針に基づくため、最も重要なセクションの一つです。
| 定義項目 | 選択肢例 | 決定すべき内容 |
|---|---|---|
| アーキテクチャスタイル | モノリス / マイクロサービス / モジュラーモノリス | 選定理由・移行計画も含めて記述 |
| デプロイ形態 | オンプレ / クラウド(AWS・Azure・GCP)/ ハイブリッド | コスト・規制・セキュリティ要件との関連を記述 |
| フロントエンド方式 | SPA / SSR / MPA / ネイティブアプリ | 想定デバイス・ユーザー環境・SEO要件を考慮 |
| バックエンド方式 | REST API / GraphQL / gRPC / 画面サーバーサイドレンダリング | クライアント連携方式・外部システム連携方式を考慮 |
| 認証・認可方式 | 独自実装 / OAuth2.0+OIDC / SAML / LDAP連携 | セキュリティ要件・既存認証基盤との関係を記述 |
| データ管理方針 | RDB中心 / NoSQL / CQRS / イベントソーシング | データの性質・規模・整合性要件を考慮 |
④ 技術スタック・ミドルウェア選定
アーキテクチャ方針を受けて、具体的な技術コンポーネントを選定します。選定理由も必ず記述します。「なぜその技術を選んだか」が分かることで、将来の技術選択時の判断軸になります。
| レイヤー | コンポーネント | 採用技術例 | バージョン |
|---|---|---|---|
| フロントエンド | UIフレームワーク | React 18 / Vue 3 | 確定版を記載 |
| バックエンド | 言語・FW | Java 21 + Spring Boot 3.x | 確定版を記載 |
| Webサーバー | HTTPサーバー | Nginx 1.26 | 確定版を記載 |
| APサーバー | アプリケーションサーバー | 組み込みTomcat / WAS | 確定版を記載 |
| DB | RDB | PostgreSQL 16 / Oracle 19c | 確定版を記載 |
| キャッシュ | インメモリDB | Redis 7.x | 確定版を記載 |
| メッセージング | MQ | RabbitMQ / Apache Kafka | 確定版を記載 |
| コンテナ | オーケストレーション | Docker + Kubernetes / ECS | 確定版を記載 |
| CI/CD | パイプライン | GitHub Actions / Jenkins | 確定版を記載 |
⑤ 環境設計(本番・検証・開発)
環境分離の方針を定義します。環境ごとのデータ管理・リリース手順・アクセス権限が明確でないと、本番障害につながるリスクがあります。
一般的には以下の環境を定義します。
- 本番環境(Production):実際のビジネスデータを扱う環境。最も厳格なアクセス管理が必要。
- 検証・ステージング環境(Staging):本番同等の構成でリリース前検証を行う環境。本番データのマスキングコピーを使用。
- 結合テスト環境(Integration):他システムとの連携テスト用。スタブ・モックとの切り替え方針を定義。
- 開発環境(Development):開発者のローカル環境。Docker Compose等でのローカル再現方針を定義。
⑥ 制約・前提条件
システム設計における制約と前提条件を明示します。これらは後から変更が困難なため、プロジェクト開始時に確定させておく必要があります。
| 制約種別 | 定義すべき内容 |
|---|---|
| 技術制約 | 社内標準技術・禁止ライブラリ・OS制約・セキュリティポリシー上の制約 |
| 法規制制約 | 個人情報保護法・金融規制・業界固有の規制対応要件 |
| インフラ制約 | 既存インフラの流用・ネットワーク帯域・クラウドリージョン制約 |
| 外部システム制約 | 連携先システムのAPI仕様・バージョン・メンテナンス時間帯 |
| 組織制約 | 承認フロー・ベンダー選定基準・セキュリティ審査要件 |
Python Tips — 実機から環境情報を取得する
システム基本設計書の「技術スタック」や「環境設計」を記述する際、既存システムや構築済み環境の情報を自動収集するとドキュメント作成が効率化できます。以下に Python で実機情報を取得するサンプルを示します。
OS・ハードウェア情報の取得
import platform
import subprocess
import json
import os
def collect_system_info() -> dict:
"""
実機のOS・ハードウェア・Python環境情報を収集して返す。
設計書の「環境設計」セクション作成に活用できる。
"""
info = {}
# ── OS情報 ─────────────────────────────────────
info["os"] = {
"system": platform.system(), # Windows / Linux / Darwin
"release": platform.release(), # カーネルバージョン
"version": platform.version(), # 詳細バージョン
"machine": platform.machine(), # x86_64 / aarch64 など
"node": platform.node(), # ホスト名
}
# ── Python環境 ─────────────────────────────────
info["python"] = {
"version": platform.python_version(), # 3.12.x
"compiler": platform.python_compiler(),
}
# ── CPU情報(Linux / macOS) ───────────────────
if platform.system() != "Windows":
try:
result = subprocess.run(
["nproc"], capture_output=True, text=True, timeout=5
)
info["cpu_cores"] = result.stdout.strip()
except FileNotFoundError:
# macOS では nproc がない場合がある
result = subprocess.run(
["sysctl", "-n", "hw.logicalcpu"],
capture_output=True, text=True, timeout=5
)
info["cpu_cores"] = result.stdout.strip()
# ── メモリ情報(Linux) ─────────────────────────
if platform.system() == "Linux":
try:
with open("/proc/meminfo") as f:
for line in f:
if line.startswith("MemTotal:"):
kb = int(line.split()[1])
info["memory_gb"] = round(kb / 1024 / 1024, 1)
break
except OSError:
info["memory_gb"] = "N/A"
# ── ディスク使用状況 ────────────────────────────
usage = os.statvfs("/") if platform.system() != "Windows" else None
if usage:
total_gb = round(usage.f_frsize * usage.f_blocks / 1024**3, 1)
free_gb = round(usage.f_frsize * usage.f_bfree / 1024**3, 1)
info["disk"] = {"total_gb": total_gb, "free_gb": free_gb}
return info
if __name__ == "__main__":
data = collect_system_info()
print(json.dumps(data, ensure_ascii=False, indent=2))
インストール済みパッケージ一覧の取得
import subprocess
import json
def collect_installed_packages() -> list[dict]:
"""
pip でインストール済みパッケージ一覧を取得する。
設計書の「技術スタック」記述の素材として活用できる。
"""
result = subprocess.run(
["pip", "list", "--format=json"],
capture_output=True, text=True, timeout=30
)
packages = json.loads(result.stdout)
# 代表的なパッケージだけ抽出する場合
important_keywords = [
"django", "flask", "fastapi", "sqlalchemy",
"requests", "numpy", "pandas", "psycopg2",
"boto3", "redis", "celery"
]
filtered = [
p for p in packages
if any(kw in p["name"].lower() for kw in important_keywords)
]
return filtered
def collect_java_version() -> str:
"""Java バージョンを取得する(java コマンドが存在する場合)"""
try:
result = subprocess.run(
["java", "-version"],
capture_output=True, text=True, timeout=10
)
# java -version は stderr に出力する
return result.stderr.split("\n")[0]
except FileNotFoundError:
return "Java not found"
def collect_node_version() -> str:
"""Node.js バージョンを取得する"""
try:
result = subprocess.run(
["node", "--version"],
capture_output=True, text=True, timeout=10
)
return result.stdout.strip()
except FileNotFoundError:
return "Node.js not found"
if __name__ == "__main__":
print("=== 主要Pythonパッケージ ===")
for pkg in collect_installed_packages():
print(f" {pkg['name']} {pkg['version']}")
print("\n=== ランタイム ===")
print("Java:", collect_java_version())
print("Node:", collect_node_version())
✅ 活用シーン
既存システムの移行案件では、移行元環境のOS・MW・Javaバージョンを自動収集してドキュメント化することで、設計書作成工数を大幅に削減できます。複数サーバーに対して SSH経由(paramiko ライブラリ)で実行すれば、環境一覧表を一括生成できます。
定義チェックリスト
システム基本設計書完成前に以下の項目を確認してください。
| チェック項目 | 確認ポイント |
|---|---|
| □ システム目的の明確化 | 解決する業務課題と期待効果が数値で表現されているか |
| □ スコープの境界定義 | Out of Scope リストが明記され、ステークホルダーの合意が得られているか |
| □ アーキテクチャ選定理由 | なぜそのアーキテクチャを選んだか、代替案との比較が記述されているか |
| □ 技術スタックのバージョン確定 | ライブラリバージョンが確定しており、EOLを考慮しているか |
| □ 環境分離方針 | 本番・検証・開発の各環境の差異と移行方法が定義されているか |
| □ 制約・前提条件の文書化 | 後から「そんな制約があるとは知らなかった」が起きないよう全制約を網羅しているか |