基本設計とは？システム開発での位置づけと成果物、要件定義・詳細設計との違い

基本設計とは、要件定義で決まった「何を作るか」を、画面・帳票・データ・外部連携・非機能といった実現方式へ翻訳し、発注者が内容を承認できる形の設計書にまとめる工程です。システム開発でこの工程が曖昧なまま進むと、詳細設計以降で仕様の解釈違いが噴き出し、手戻りがコストとして跳ね返ります。この記事では、基本設計の範囲、成果物、要件定義や詳細設計との境界、そして発注者が承認前に確認すべき観点までを、IPA「共通フレーム2013」の原文を引きながら整理します。

まとめ：基本設計で決まることと、発注者が握るべき三点

• 基本設計は「何を作るか」から「どう実現するか」へ移る最初の工程で、成果物は発注者がレビューできる粒度で書かれます。
• IPAの共通フレーム2013 第3部には「基本設計」という工程名がありません。範囲は各社の社内標準で決まるため、着手前に成果物名で合意する必要があります。
• 承認前に確認すべきは、要件が漏れなく設計へ反映されているか、性能や稼働率が数値で書かれているか、そして未確定事項が誰の宿題として残っているかの三点です。

以降で、工程としての位置づけ、紛らわしい呼び名の対応関係、成果物の中身、承認の観点の順に見ていきます。

基本設計の定義とシステム開発工程での位置づけ

システム設計全体のなかで基本設計が担う範囲

要件定義が答えるのは「業務をどう変えたいか」「システムに何をさせたいか」です。基本設計が答えるのは「その要件を、どの画面で、どのデータ構造で、どの外部システムと連携して実現するか」になります。決めごとの粒度が一段下がり、記述の主語が業務からシステムへ移るのが本質的な違いです。

「システム設計」という語は、基本設計と詳細設計を合わせた設計工程全体の総称として使われるのが一般的です。基本設計はその前半、つまり発注者と合意しながら外側の仕様を固める側にあたります。社内で「システム設計を進めています」と報告が上がってきたら、それが前半なのか後半なのかを確認しないと、進捗の意味を取り違えます。

この移行が雑だと、後工程の判断根拠が消えます。共通フレーム2013 第3部は、システム要件の評価について「開発者に対し、次のステップであるシステム方式設計段階でシステム要件が実現できるかどうか、さらにシステムの運用が可能かどうか、また、システムの保守を可能とする内容であるかどうかを見極めることを課している」と説明しています。要件が実現・運用・保守の三つの観点で成立するかを、設計に入る前に見極めよという指示です。

共通フレーム2013 第3部に工程名として存在しない基本設計

ここが実務でいちばん誤解されている点です。IPAが公開している「共通フレーム2013 第3部 共通フレームとガイダンス」の全文をPDFから抽出して機械的に数えたところ、「基本設計」という語の出現は0件でした。「内部設計」「概要設計」「実施設計」も同じく0件です。同文書のテクニカルプロセス一覧に並ぶのは、2.3.3 システム方式設計プロセス、2.4.2 ソフトウェア要件定義プロセス、2.4.3 ソフトウェア方式設計プロセス、2.4.4 ソフトウェア詳細設計プロセス、2.4.5 ソフトウェア構築プロセスという名前です。

規格側も同様です。JIS X 0160:2012（ISO/IEC 12207:2008と一致する規格）では、7.1.3 ソフトウェア方式設計プロセス、7.1.4 ソフトウェア詳細設計プロセスという名称が使われていました。この規格は2021年2月22日にJIS X 0160:2021（ISO/IEC/IEEE 12207:2017と一致）へ改正されて置き換えられ、現行版ではテクニカルプロセスが箇条6.4に整理されています。いずれの版でも、工程名として立っているのは「方式設計」です。

つまり「基本設計」は国内SI業界の慣用語であって、標準規格に定義された工程ではありません。だからこそ、A社の基本設計にはデータベース物理設計まで含まれ、B社では論理設計までで切る、といった食い違いが平然と起こります。他社の工程表や見積書を読むときに、工程名だけで範囲が一致していると考えるのは危険です。合意すべきは工程名ではなく成果物名です。

なお共通フレーム2013 第3部は、同じ文書のなかで「ソフトウェア構築」について「いわゆるプログラミングのことを指す」と注記し、「ソフトウェア設計」については「ソフトウェア方式設計（2.4.3.1）及びソフトウェア詳細設計（2.4.4.1）の結果を指す」と定義しています。標準側は、慣用語との対応を読者が自分で引き受ける前提で書かれています。

BD・UIなど工程記号の揺れと、標準規格の英語名

現場では基本設計をBD、詳細設計をDDと略したり、UI・SSといった工程記号を使ったりします。これらは各社の社内標準であり、共通フレーム2013 第3部の本文には出てきません。他社の工程記号を見たときは、記号の意味を推測せず、その工程で何という設計書が納品されるかを聞くのが確実です。

英語表記は、慣用語と標準用語で事情が分かれます。JIS X 0160:2012が一致規格として対応するISO/IEC 12207:2008では、7.1.3が Software Architectural Design Process、7.1.4が Software Detailed Design Process と定義されています。英語名が与えられているのは「方式設計」であって、慣用語の「基本設計」ではありません。海外ベンダーに basic design とだけ伝えても範囲は伝わらないため、architectural design という標準用語を使うか、画面設計書・テーブル定義書・外部インタフェース仕様書といった成果物名を列挙して認識を合わせてください。

要件定義・詳細設計との境界線の引き方

決める主体が移る点で分かれる要件定義との境界

要件定義の責任者は発注者側です。共通フレーム2013 第3部が参照する「超上流から攻めるIT化の原理原則17ヶ条」も、原理原則[9]として「要件定義は発注者の責任である」と明記しています。対して基本設計では、要件を満たす実現方式の選択を開発者が主導し、発注者はその妥当性を確認する側に回ります。

境界が崩れる典型は、要件が固まらないまま基本設計に着手するケースです。原理原則[3]は「プロジェクトの成否を左右する要件確定の先送りは厳禁である」と述べています。未確定要件を設計で吸収しようとすると、設計書に条件分岐が増え、詳細設計以降で組み合わせ爆発を起こします。要件定義書の書き方や記載項目の詰め方は要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説で整理しています。

読み手の違いで切り分ける詳細設計との境界

基本設計書の読み手には発注者が含まれます。したがって、業務用語で書かれ、画面イメージや業務フローで内容を確認できる必要があります。詳細設計書の読み手はプログラマで、クラス構成やモジュール内部のロジック、エラー処理の分岐まで踏み込みます。同じ「設計」でも、レビューに呼ぶ人が違うと考えると切り分けやすくなります。

読み手の違いは、画面設計の進め方にも表れます。共通フレーム2013 第3部は「画面の設計では、画面の原案を利用部門が作成して、それを開発者が実装可能なレベルに変換することが望ましい。また、画面の遷移についても利用部門が確認するとよい」としています。画面を開発者だけで作って承認をもらう進め方は、標準が想定する順序とは逆です。外部設計と内部設計の呼び分けを含めた詳細は外部設計とは？内部設計との違いと成果物、発注者が承認すべき観点を解説を参照してください。

紛らわしい「◯◯設計」と基本設計の対応関係

検索でよく並ぶ「概要設計」「実施設計」「構想設計」などは、分野が違うだけで同義の場合と、明確に別工程の場合が混ざっています。分野を先に確認しないと議論がかみ合いません。

特に注意したいのが「実施設計」です。建築・土木では基本設計の次に実施設計が来るため、「基本設計と実施設計の違い」という問いは建築分野の文脈で語られることがほとんどです。IT側でこの語を使う相手がいたら、建築出身か建設系プロジェクトの経験者である可能性が高く、詳細設計と読み替えて会話するとずれません。

基本設計書に含める成果物

標準規格が工程名を定めていない以上、成果物リストも自動的には決まりません。実務では次の六系統をそろえるのが一般的で、どれを作りどれを省くかを着手前に一覧で合意します。

この六系統のうち、抜けが致命傷になりやすいのは外部連携です。連携先の担当者は自社プロジェクトの体制図に載っていないことが多く、仕様確認の往復に数週間かかります。基本設計の初期に連携先を洗い出し、確認の締切を先に押さえておくと、後工程のスケジュールが崩れにくくなります。

コード定義書も軽視されがちですが、区分値の定義が設計書間でずれると、詳細設計とテストの両方で修正が発生します。データ系の成果物は、詳細設計に入る前に値レベルまで確定させておく価値があります。

要件定義で決めた非機能要件を基本設計へ落とし込む六つの分類

機能の設計だけを進めて非機能を後回しにすると、性能要件を満たさないアーキテクチャで詳細設計まで進んでしまい、作り直しになります。共通フレーム2013 第3部は、要件定義プロセスの記述として非機能要件に書く内容を次の六分類で例示しています。出所は要件定義側ですが、そのまま基本設計のレビュー観点として使えます。

• 品質要件：JIS X 0129-1（ISO/IEC 9126-1）の品質特性を援用し、機能性・信頼性・使用性・効率性・保守性・移植性を扱う
• 技術要件：システムの実現方法、システム構成、システム開発方式（言語等）、開発基準・標準、開発環境
• 運用・操作要件：運用手順、運用形態、運用スケジュール、監視方法と監視基準、サービス提供条件（障害復旧時間等）、災害対応策、業務継続策、データの保存周期と量、エンドユーザ操作方法
• 移行要件：移行対象の業務・ソフトウェア・ハードウェア、移行手順、移行時期
• 付帯作業：環境設定、端末展開作業、エンドユーザ教育、運用支援
• その他要件：費用と納期の目標値、電力量、作業環境、フロア面積

この分類で目を引くのは、セキュリティが独立した品質特性として立っていない点です。共通フレーム2013 第3部が援用しているJIS X 0129-1はISO/IEC 9126-1に対応する旧世代の品質モデルで、後継のモデルとは特性の構成が異なります。現行のモデルに沿って整理したい場合はISO/IEC 25010とは？品質特性の一覧と2023年改訂（安全性の追加）まで解説を、可用性や性能の目標値を段階的に決めたい場合は2018年4月にIPAが公開した非機能要求グレード2018を扱った【非機能要求グレードとは何か？】IPAが提唱するフレームワークの概要と非機能要求定義の目的を詳しく解説するを併用してください。機能要件と非機能要件の切り分け自体に迷う場合は機能要件とは？非機能要件・業務要件との違いと定義する5つの事項が出発点になります。

基本設計を進める手順と発注者の承認責任

着手条件と作業の順番

着手条件は、要件定義書が承認済みであることと、成果物の一覧が合意されていることの二つです。作業の順番は、全体構造（機能一覧と業務フロー）を先に固め、次に画面とデータを並行で進め、最後に外部連携と非機能を詰める流れが現実的です。画面から先に着手すると、業務フローの見落としが画面設計のやり直しとして跳ね返ります。

基本設計で決めた内容は、V字モデルでは結合テストの検証対象と対応します。設計とテストの対応づけはシステム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸で整理しているので、テスト計画を同時に走らせるときの参考にしてください。

承認前に確認する三つの観点

共通フレーム2013 第3部が参照する原理原則17ヶ条から、基本設計のレビューにそのまま使える三つを挙げます。

• 原理原則[12]「表現されない要件はシステムとして実現されない」：要件定義書の各項目が、設計書のどこに対応するかを追跡できる状態にする
• 原理原則[13]「数値化されない要件は人によって基準が異なる」：応答時間、同時接続数、稼働率、復旧時間を数値で書き切る
• 原理原則[4]「ステークホルダ間の合意を得ないまま、次工程に入らない」：未確定事項を一覧化し、担当者と期限を付けてから詳細設計へ進む

「レスポンスは快適に」「運用しやすく」といった評価語が設計書に残っていたら、それは原理原則[13]に照らして未完成です。承認印を押す前に数値へ置き換えてください。あわせて原理原則[16]「機能要求は膨張する。コスト、納期が抑制する」も意識しておくと、基本設計中の要望追加をどこで止めるかの判断がぶれません。

契約の区切りとしての外部設計書作成業務

発注者にとって基本設計は、単なる作業工程ではなく契約の区切りでもあります。共通フレーム2013 第3部は、経済産業省の「情報システム・モデル取引・契約書」について「個別契約書で工程毎に委託料を定める多段階契約と再見積りのプロセスモデルを採用している」と紹介し、そのモデルが「要件定義作成支援業務、外部設計書作成（支援）業務、ソフトウェア開発業務、ソフトウェア運用準備・移行支援業務に分割する」ものだと説明しています。

ここでも契約単位の名称は「基本設計」ではなく「外部設計書作成（支援）業務」です。一括請負で全工程を一本の契約にまとめると、基本設計の結果として工数見積りが変わったときに再見積りの根拠を出しにくくなります。設計の結果で規模が動く前提なら、工程を分けて再見積りの機会を契約に組み込む方が、双方のリスクは下がります。

基本設計書一式を作らない方がよい場面

ここまで基本設計の重要性を書いてきましたが、あらゆるプロジェクトで設計書一式を作るべきだとは考えていません。次の条件に当てはまるなら、成果物を絞る判断のほうが合理的です。

第一に、SaaSの設定で要件を満たす案件です。標準機能の設定値を決めるだけの領域に対して、画面設計書やテーブル定義書を新規に起こしても、製品側の仕様変更で陳腐化します。この場合は設定パラメータ一覧と業務フロー、そして標準機能で満たせない差分の設計書だけに絞るほうが保守性は高くなります。

第二に、要件が探索的で仮説検証が主目的の案件です。作った機能の半分を捨てる前提の開発で、捨てる部分の設計書を先に完成させるのは投資として合いません。ただしこの場合も、データモデルと外部連携インタフェースだけは先に固めるべきです。後から変更したときの影響範囲が、画面ロジックとは比較にならないほど広いためです。

逆に、複数ベンダーが分担する開発、既存基幹システムとの連携が多い案件、監査や法令対応で設計根拠の説明責任がある案件では、成果物を削る判断は勧められません。原理原則17ヶ条の[17]は「要件定義は説明責任を伴う」と述べています。同じ説明責任は、その要件をどう実現したかを記した設計書にも及ぶというのが弊社の考え方で、後から根拠を示せない設計は、トラブル時に費用負担の議論を長期化させます。

よくある質問

基本設計と要件定義の違いは何ですか？

要件定義は「何を作るか」を発注者の責任で決める工程、基本設計は「それをどう実現するか」を開発者が主導して設計する工程です。共通フレーム2013 第3部が参照する原理原則17ヶ条でも「要件定義は発注者の責任である」と明記されています。境界の実務的な目安は、業務用語だけで書ける内容が要件定義、画面・データ・外部連携といったシステム側の構造に踏み込む内容が基本設計です。

基本設計と詳細設計の違いはどこにありますか？

レビューに呼ぶ人が違います。基本設計書は発注者が読んで承認できる粒度で書き、詳細設計書はプログラマが実装できる粒度で書きます。共通フレーム2013 第3部では前者に相当するのがソフトウェア方式設計プロセス（2.4.3）、後者が同じくソフトウェア詳細設計プロセス（2.4.4）で、この二つの結果をまとめて「ソフトウェア設計」と呼ぶと注記されています。

基本設計はシステム開発のどの時期に実施しますか？

要件定義書が承認された直後です。着手条件は、要件定義書の承認と、作成する成果物一覧の合意の二点がそろっていることです。要件が未確定のまま設計へ進むと、設計書に条件分岐が増えて詳細設計以降で手戻りします。原理原則[3]も「要件確定の先送りは厳禁である」としています。

基本設計と実施設計の違いは何ですか？

「実施設計」は主に建築・土木で使われる工程名で、その分野では基本設計の次に実施設計が来ます。ITの工程に置き換えると詳細設計に近い位置づけです。IPAの共通フレーム2013 第3部にはこの語が一度も登場しないため、ソフトウェア開発の会話で出てきた場合は、相手がどの分野の慣習で話しているかを先に確認してください。

基本設計は英語で何と表現すればよいですか？

直訳の basic design が使われますが、ISO/IEC 12207:2008で工程名として定義されているのは 7.1.3 Software Architectural Design Process です。英語名が付いているのは慣用語の基本設計ではなく方式設計なので、海外ベンダーとやり取りするなら architectural design を使うか、画面設計書・テーブル定義書・外部インタフェース仕様書といった成果物名を列挙するほうが確実です。

関連記事

• 外部設計とは？内部設計との違いと成果物、発注者が承認すべき観点を解説
• 要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説
• システム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸
• 機能要件とは？非機能要件・業務要件との違いと定義する5つの事項
• 【非機能要求グレードとは何か？】IPAが提唱するフレームワークの概要と非機能要求定義の目的を詳しく解説する