⚠️ この記事について
この記事はAI（Claude）を活用して作成しています。
以下の点にご注意ください：
- 情報の鮮度: 記事作成時点（2026年7月）の情報です。ガイドラインは改定される場合があるため、最新情報は必ず一次情報でご確認ください
- 適用範囲の確認: 紹介する内容は主に政府情報システムを対象としたガイドラインですが、上流工程の考え方は民間の開発案件にも応用できるものが多く含まれています。ご自身のプロジェクトの規模・性質に合わせて取捨選択してください
- 出典の確認: 重要な実務判断は本文中の参考リンクや公式ドキュメントで必ず一次確認をお願いします
- 誤りの可能性: AI生成コンテンツには誤りが含まれる場合があります。お気づきの点はコメントでご指摘ください
はじめに
前回は、デジタル庁の実践ガイドブックをもとに「要件定義」の進め方を整理しました。今回はその次の工程である「基本設計」を取り上げます。
要件定義が「何を実現すべきか」を決める工程だとすると、基本設計は「それをどういう仕組みで実現するか」の全体像を決める工程です。この記事では、デジタル庁（旧内閣官房IT総合戦略室）の「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（第３編第７章 設計・開発）」の内容をもとに、基本設計を含む設計・開発工程で発注者（PJMO）が押さえておくべきポイントを整理します1。
先にお伝えしておくと、実践ガイドブックには「要件定義書」のような基本設計書のテンプレートは用意されていません。設計・開発工程は専門性が高く、事業者に委ねる部分が大きいためです。そのため本記事では、「発注者側が基本設計工程で何を理解し、どう関与すべきか」という管理の視点を中心にまとめています。
この記事を読むとわかること：
- 基本設計とは何か、要件定義とどう違うのか
- デジタル庁のガイドラインにおける設計・開発工程の位置づけ
- 発注者（PJMO）が設計・開発工程で押さえるべき管理のポイント
- 基本設計書に一般的に含まれる内容
- 基本設計と詳細設計の切り分け方についての考え方
基本設計とは何か
基本設計とは、要件定義で明らかになった「システムに求められること」を受けて、そのシステムを実現するための全体構造や、利用者から見える部分（画面や帳票など）の仕様を具体化する工程です。一般的には、外部から見える仕様（画面・帳票・外部インタフェースなど）を定める「外部設計」と、システム内部の処理やデータ構造を定める「内部設計」の一部を含む形で「基本設計」と呼ばれます。
要件定義との違いをシンプルに整理すると、次のようになります。
| 工程 | 主な問い | 主な検討者 |
|---|---|---|
| 要件定義 | 何を実現すべきか（What） | 発注者（業務担当者含む）が主体 |
| 基本設計 | どういう仕組みで実現するか（How の全体像） | 事業者が主体、発注者は監理 |
| 詳細設計 | 具体的にどう実装するか（How の詳細） | 事業者が主体 |
デジタル庁のガイドラインにおける位置づけ
デジタル庁の実践ガイドブックでは、基本設計・詳細設計という区分ではなく、「設計・開発」という1つの工程としてまとめて扱われています。ガイドブックでは、設計・開発の具体的な活動を行うのは調達によって選定された事業者であり、事業者は発注者が作成した調達仕様書及びその附属資料である要件定義書をインプットとして、設計・開発工程の活動を計画し実行するとされています1。
つまり、要件定義書の品質がそのまま基本設計以降の工程の出発点になるということです。ここでも要件定義工程の重要性が改めて浮き彫りになります。
発注者が「関与しない」と何が起きるか
設計・開発は専門的でわかりにくい作業が多いため、「事業者に任せておけばよい」と考えたくなりますが、ガイドブックでは、一般的に職員（発注者側の担当者）の関与が低いほど、設計・開発の成功確率は低下する傾向があると述べられています1。専門的でわかりづらい工程だからこそ、発注者が関与することで効果がある作業が何かを理解しておく必要があるとされています。
また、要件定義の際に多くの関係者の意見を集約し、新しい業務のあり方を決定した経緯やその全体像を理解している職員は、要件定義に関わったメンバーの中でも限られていることが多く、そうした職員は設計・開発工程においても非常に貴重な存在になるとガイドブックは指摘しています1。要件定義担当者が設計・開発工程まで継続的に関与できる体制を作ることが、プロジェクトの安定につながるということです。
進捗・品質管理の要は「定点観測」
設計・開発を担う事業者の活動状況は定例会などで共有されますが、専門的な内容が多くなると、発注者側はただ説明を聞くだけになりがちです。ガイドブックでは、情報システム整備プロジェクトの経験がなくても、まずは作業の状況を定量値で管理し、継続してその値を把握する「定点観測」が進捗・品質管理の要になるとされています1。定量的な指標を定点観測することで、現場の状況の変化に気づきやすくなり、問題の早期発見につながります。
設計・開発実施計画書とプロジェクト計画書の整合
事業者との設計・開発工程の活動は、「設計・開発実施計画書」として計画されますが、これはPJMOが作成するプロジェクト全体のプロジェクト計画書を具体化・詳細化したものと位置づけられています1。事業者との活動やコミュニケーション、変更管理は、あくまでプロジェクト計画に従って行う必要があり、設計・開発実施計画書はプロジェクト計画書と整合性が取れていなければならないとされています。なお、事業者が作成する「プロジェクト計画書」と必ずしも別のドキュメントに分ける必要はなく、事業者が作成したものをPJMOがプロジェクト全体の計画と整合を確認して確定する、という進め方でもよいとされています1。
基本設計書に一般的に含まれる内容
前述の通り、実践ガイドブックには要件定義書のような基本設計書の標準テンプレートは用意されていませんが、ガイドライン本編（第３編第７章）には基本設計書の構成例として、システムの全体像、外部設計（画面系）、内部設計（インタフェース・バッチ処理系など）を記載する構成が示されていると、実際にガイドラインを参照して基本設計書を作成した事例がQiitaで紹介されています2。
一般的な基本設計書に含まれる代表的な項目を整理すると、次のようになります（項目名や粒度はプロジェクトや事業者によって異なります）。
| 分類 | 主な内容の例 |
|---|---|
| システム全体像 | システム構成図、サーバ・ネットワーク構成、他システムとの関係 |
| 外部設計（画面系） | 画面一覧、画面レイアウト、画面遷移、入出力項目 |
| 外部設計（帳票系） | 帳票一覧、帳票レイアウト |
| 内部設計の一部 | 外部インタフェース仕様、バッチ処理の設計方針 |
| データ設計 | テーブル定義、ER図（要件定義段階のデータモデルを詳細化） |
要件定義の段階で作成した「情報システム機能一覧」「画面一覧」「データモデル」などの成果物が、基本設計工程でより具体的なレベルまで詳細化されるイメージを持つとわかりやすいと思います。
基本設計と詳細設計の切り分けについて
実務でよく悩ましいのが「どこまでが基本設計で、どこからが詳細設計か」という線引きです。実践ガイドブックには、この切り分けを明確に定めた指針はなく、設計工程をどう分けるかは会社（事業者）によって異なる例が示されているにとどまります2。
一般的な目安としては、次のように整理されることが多いです。
- 基本設計（外部設計）：利用者や他システムから見える仕様（画面、帳票、外部インタフェースなど）を確定する
- 詳細設計（内部設計）：プログラム内部の処理ロジック、モジュール構成、データベースの物理設計などを確定する
ただし、この区分けは絶対的なものではないため、プロジェクトの開始時点で、発注者と事業者の間で「どの工程で何を確定させ、何をレビューするか」を明確に合意しておくことが重要です。特に、確定した仕様の変更が後工程に与える影響の大きさは工程が進むほど増していくため、基本設計の完了時点でのレビューは特に丁寧に行う価値があります。
基本設計でよくあるつまずきと対策
デジタル庁のガイドラインが示す考え方を踏まえると、基本設計工程で起きやすい問題と対策は次のように整理できます。
-
発注者が内容を理解しないまま承認してしまう
→ 専門的な内容でも、要件定義との対応関係（この画面はどの機能要件に対応するか等）を確認しながらレビューする -
要件定義の担当者が設計・開発工程に関与しなくなる
→ 要件定義の背景や経緯を知る職員が、少なくともレビューには継続して関与できる体制にする -
進捗状況が「事業者の説明を聞くだけ」になる
→ 定量的な指標（設計書の完成率、レビュー指摘件数など）を定点観測し、変化を継続的に把握する -
画面や帳票を細かく決めすぎて工数が膨らむ
→ 要件定義の段階から、「実現手段ではなく求める結果を記載する」という考え方を意識し、基本設計工程で事業者の専門性を活かせる余地を残しておく
まとめ
- 基本設計とは、要件定義で明確になった「何を実現すべきか」を受けて、「どういう仕組みで実現するか」の全体像を具体化する工程
- デジタル庁のガイドラインでは「基本設計」を独立した章として扱わず、「設計・開発」という工程の中で管理のポイントが解説されている
- 設計・開発の実作業は事業者が担うが、発注者側の関与度合いがプロジェクトの成功確率に影響する
- 要件定義の背景を理解した職員が設計・開発工程にも継続的に関与することが、知識の断絶を防ぐ
- 進捗・品質管理は「定点観測」、つまり定量的な指標を継続的に把握することが基本
- 基本設計と詳細設計の明確な線引きはガイドライン上定められておらず、プロジェクトごとに発注者と事業者で合意しておく必要がある
要件定義と同様、基本設計もまた「事業者に任せきりにしない」ことが成功の鍵になります。ガイドラインの管理の観点を参考にしながら、自分たちのプロジェクトに合った基本設計の進め方を検討してみてください。