基本設計とは？詳細設計との違い・成果物と発注者の確認ポイント

基本設計とは、要件定義で合意した目的・対象範囲・制約を、利用者の操作、業務の流れ、外部システムとの接点から確認できる仕様へ具体化し、実装・テスト・受入れにつなげる活動です。Webサービスやスマホアプリでも、画面だけでなく、データ、権限、連携、例外時の対応まで扱うことがあります。

本記事では、要件定義・詳細設計との違い、基本設計で参照できるべき成果物、未決事項を残す際の判断を順に解説します。読後には、工程名ではなく、決定事項・記録先・確認者・承認条件でレビュー範囲を判断できるようになります。

基本設計では、要件を業務や利用者から確認できる仕様へ整理し、詳細設計・実装・受入れ確認へつなげます。

01Section基本設計とは何をする工程か

基本設計の役割は、要件を実装担当者だけが理解できる表現に置き換えることではありません。利用者や業務部門、運用担当、連携先を含む関係者が、「システムがどのように振る舞うか」を確認できる状態に整えることです。

開発プロセスの名称や活動の順序は、対象サービス、規模、実施環境、整備内容、開発手法によって一様ではありません。デジタル・ガバメント推進標準ガイドライン解説書（DS-110）も、プロジェクト特性に応じて進め方を捉える考え方を示しています。民間の開発案件では、工程名だけを合わせるよりも、何を決め、どこへ記録し、誰が確認・承認するかを最初にそろえることが重要です。

基本設計で具体化する対象

対象や文書の分け方は案件によって異なりますが、基本設計では次のような対象を具体化します。

要件定義とのつながりと完了の見方

要件定義では、なぜそのシステムが必要なのか、何を対象にするのか、優先順位や制約を主に合意します。要件定義の考え方は、要件定義の記事で詳しく確認できます。

基本設計では、その合意内容をもとに、利用者・業務・外部との接点で確認できる仕様へ進めます。したがって、完了を「基本設計書」という名称の文書が完成したか、何冊の資料があるかだけで判断するのは適切ではありません。少なくとも設計対象ごとに、次の状態を追えることが目安になります。

• 決定した内容と対象外の範囲が明確である
• 最新の仕様を参照できる記録先が分かる
• 業務・情報システム・運用・開発など、影響を受ける確認者が分かる
• 承認時に確認する条件と、受入れで確かめる結果がつながっている
• 未決事項があれば、影響と後続の扱いを識別できる

IPA「共通フレーム2013」は、構想から開発、運用、保守、廃棄に至るライフサイクルの作業項目と役割を整理するための参照軸です。特定の工程名や必須成果物を一律に決めるものではありませんが、関係者間で活動と役割を整理する際の参考になります。

アジャイル開発での扱い

アジャイル開発では、全機能の仕様を一度に固定せず、機能、反復、リリース単位で具体化する場合があります。その場合も、対象範囲、利用者、画面・データの変更、権限、連携への影響、受入れ条件を確認する点は共通です。

特に、外部連携、権限、保護対象データ、セキュリティの前提など、変更時の影響が広がりやすい内容は、反復の開始前または早期に合意が必要になりやすい領域です。アジャイル開発実践ガイドブック（DS-121）も、反復型の進め方を検討する際の公式資料として参照できます。

02Section基本設計・要件定義・詳細設計の違い

工程名だけでなく、何を決め、誰が確認し、何を承認するかで役割を整理します。

要件定義、基本設計、詳細設計の区分は、一般的な分担例です。プロジェクトによっては、基本設計を外部設計、詳細設計を内部設計と呼ぶこともありますが、常に一対一で対応する用語とは限りません。

比較する際は、名称ではなく、目的、何を決めるか、どこへ記録するか、誰が確認するか、承認時に何を見るかで整理します。

基本設計と詳細設計は「何を確認できるか」が異なる

基本設計では、利用者がどの画面で何を入力するか、どの役割が承認できるか、外部システムと何をいつ受け渡すかといった、業務や外部から見える振る舞いを具体化します。レビューでは、実務への適合、例外時の扱い、受入れで確認できるかを見ます。

詳細設計では、その仕様を内部でどう実現するかを具体化します。モジュール構成、内部処理、物理データ設計、接続方式などは開発側が主導しやすい領域です。ただし、性能、保守、セキュリティ、連携の条件が業務・利用者・運用に影響する場合は、役割分担に沿って確認対象に含めます。

03Section基本設計書の主な成果物と確認方法

成果物の名称や保管場所が分かれていても、関連仕様を横断して参照・照合できる状態が重要です。

基本設計書は、単一の文書とは限りません。仕様書、図、管理表、チケットなどに分かれていても、必要な仕様の参照先、確認者、変更履歴、受入れ条件を追えるなら、案件に応じた構成として運用できます。

政府情報システム向けのデジタル社会推進標準ガイドラインには、要件定義書のテンプレートや工程レビューの参考資料が公開されています。民間案件で同じ文書名や構成を必須とするものではなく、確認観点を洗い出す際の参考として活用するとよいでしょう。

設計対象別に確認する成果物・記録先

成果物の名称よりも、対象ごとに必要な仕様が参照できるかを確認します。以下は代表例です。

文書名ではなく横断して確認する

文書を単体で確認しても、画面、データ、権限、連携の間に矛盾があれば、実装や受入れで認識違いが起こり得ます。特に次の3組は、関連する資料を並べて照合します。

04Section基本設計の一般的な進め方と未決事項の扱い

基本設計では、仕様の具体化や横断レビューを通じて前提を再確認し、未決事項の扱いと受入れへの引継ぎを整理します。

基本設計は、要件定義の完了後に一方向で進むとは限りません。画面、連携、運用の検討によって要件の曖昧さや対象外の範囲が見つかり、前段の合意内容を確認し直すことがあります。工程全体での位置付けは、システム開発の流れの記事も参照してください。

入力確認から承認・引渡しまで

未決事項を残す場合の判断

未決事項は、記録しただけで後続工程へ進めてよいわけではありません。対象機能、関連文書、影響範囲を識別し、次の2つに分けて扱います。

実装開始前に決定が必要になりやすい事項は、画面、データ、連携、テストの前提を左右します。対象範囲、権限・承認、法令・セキュリティ、保護対象データ、外部連携の責任分界などが該当します。これらが未決だと、実装・確認の対象を定めにくくなります。

一方、影響範囲が特定でき、実装・テスト・運用の暫定対応を定められる内容は、条件付きで管理できる残課題になり得ます。この場合は、責任者、決定期限、影響、暫定対応、決定後の再確認手順を必ず残します。承認者や残課題を許容する基準は、契約、体制、対象システムの重要度により異なります。

受入れ確認へ引き継ぐ内容

基本設計のレビューで合意した内容は、受入れ確認の場で検証できる形に変換します。画面が表示されるかだけで終わらせず、通常業務を開始から完了まで通した場合、差し戻し・取消・入力不備などの例外が起きた場合、役割ごとに操作した場合、外部連携が正常・異常となった場合に、期待する結果を確認します。

この接続を設計時から用意しておくと、「仕様には書かれているが、受入れで何を確認すればよいか分からない」という状態を避けやすくなります。

05Section基本設計で見落としやすい点と受入れ確認への引継ぎ

設計の曖昧さや漏れは、実装中だけでなく、テスト、移行、運用、変更時の認識違いとして現れることがあります。優先して確認したいのは、業務停止の影響が大きい、外部への依存度が高い、保護対象データを扱う、復旧が難しい、後から変更しにくいといった条件を持つ仕様です。

権限・承認、外部連携、データ、例外時運用、停止許容や監視・復旧などの非機能・運用条件は、こうした条件に当てはまりやすい領域です。セキュリティについても、技術実装の細部を一律に確認するのではなく、誰がどの情報を扱うか、どの業務を継続する必要があるか、障害時にどう対応するかという業務・運用上の条件を、役割分担に沿って確認します。セキュリティ・バイ・デザインガイドライン（DS-200）は、企画から運用まで一貫して対策を扱うための参考資料です。民間案件の役割や責任を固定するルールではありません。

受入れ確認では業務の流れで確かめる

受入れ確認では、設計書のページ単位ではなく、実際の業務シナリオで確かめます。通常時と例外時の業務フローに沿って、利用者、画面、帳票・通知、権限、連携結果を確認すると、文書間の矛盾や運用上の不足を見つけやすくなります。

設計変更の影響は、変更時期、対象規模、契約条件、連携・移行の有無、既存資産などで変わります。承認後の変更も想定し、対象外、前提条件、未決事項、連絡先と再確認範囲を残しておくことが大切です。

レビュー前後の確認ボックス