開発の基本概念

基本設計きほんせっけい

システム設計外部設計要件定義詳細設計ウォーターフォール画面設計

基本設計について教えて

簡単に言うとこんな感じ！

家を建てる前に「リビングはこのくらいの広さで、窓はここ、キッチンはこっち」って間取り図を決める作業だよ！システム開発でいうと「画面はこんな見た目で、どのボタンを押したら何が起きるか」をユーザー目線でまとめる工程なんだ。

基本設計とは

基本設計とは、システム開発の工程のひとつで、要件定義で決めた「何を作るか」を、「どう作るか」に落とし込む作業です。ユーザーが実際に目にする画面の構成・操作の流れ・他システムとのデータのやり取りなど、システムの外側から見える部分を具体化していきます。「外部設計」とも呼ばれるのはこのためです。

要件定義がお客様との「約束書」だとすれば、基本設計はその約束を実現するための「設計図の骨格」にあたります。この段階で決めた内容をもとに、続く詳細設計（内部設計）やプログラミングが進んでいくため、ここでの決定がプロジェクト全体の品質とコストを大きく左右します。

発注側のビジネスパーソンにとっては、基本設計書のレビュー（確認・承認）が最も重要な関与ポイントのひとつです。この時点で認識のズレを修正しておかないと、後工程での手戻りコストは数倍〜数十倍に膨れ上がります。

基本設計で決めること

基本設計では、主に以下の5つの領域を定義します。

設計領域	内容の例
画面設計	各画面のレイアウト・入力項目・ボタン配置・遷移先
帳票設計	印刷物・PDFの様式・出力項目・集計ロジック
データベース設計	テーブル構成・項目名・データ型・関係性（ER図）
機能設計	各機能の処理概要・業務フロー・条件分岐
インターフェース設計	外部システムとのデータ連携方法・ファイル形式・タイミング

「外部設計」という別名の覚え方

「外」＝ユーザーから外から見える部分、と覚えましょう。画面・帳票・外部連携はどれも「外から見える」ものですね。逆に、詳細設計は「内部設計」とも呼ばれ、プログラムの内側（処理ロジック・クラス構造など）を定義します。

成果物（ドキュメント）の例

基本設計フェーズで作られる主なドキュメントは以下の通りです。

基本設計書（外部設計書）
├── 画面一覧・画面遷移図
├── 画面レイアウト定義書
├── 機能一覧・機能概要説明書
├── データベース定義書（ER図）
├── 帳票レイアウト定義書
└── 外部インターフェース定義書

歴史と背景

1960〜70年代：大型コンピューター（メインフレーム）時代。開発工程の管理手法が体系化され始め、「設計→製造→テスト」の分業が定着
1970年代：ウィンストン・ロイスがウォーターフォールモデルを提唱。要件定義→基本設計→詳細設計→製造→テスト→運用という直線的な工程が標準化
1980〜90年代：日本のSIer（システムインテグレーター）文化の中で「基本設計書」「詳細設計書」という形式が業界標準として定着
2000年代〜：アジャイル開発の台頭により「重厚な設計書を先に全部書く」スタイルは見直されつつあるが、大規模・官公庁・金融系では今も基本設計フェーズは必須
現在：クラウドやノーコードツールの普及で設計の一部が自動化・省力化されているが、「何を作るか → どう見せるか → どう動かすか」という思考の順序は変わらない

開発工程における位置づけ

基本設計は、ウォーターフォール型開発の中間に位置します。前後の工程との関係を図で確認しましょう。

基本設計と詳細設計の違い

比較軸	基本設計（外部設計）	詳細設計（内部設計）
視点	ユーザー・発注側目線	エンジニア目線
対象	画面・帳票・外部IF	クラス・関数・DB処理
レビュアー	発注側が中心	開発チーム内
変更コスト	比較的低い	高い
成果物	画面設計書・機能概要	プログラム仕様書

発注側が積極的に関わるべきは基本設計まで。 詳細設計以降は技術的な話が中心になるため、確認ポイントを絞って委任するのが現実的です。

発注側が基本設計でチェックすべきポイント

実務で発注者がレビューする際の確認観点を整理します。

業務フローと合っているか：現場の実際の業務手順を正しく反映しているか
抜け漏れがないか：要件定義で合意した機能がすべて設計に盛り込まれているか
例外処理は考慮されているか：エラー時・入力ミス時の動作が定義されているか
非機能要件（速度・セキュリティ）は反映されているか：「1000人同時接続に対応」などの要件が設計に落ちているか
用語が社内用語と一致しているか：「顧客」「得意先」「取引先」など呼称の統一ができているか