監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
基本設計書は、要件定義で合意した業務要件・機能要件を、システムとして「どう実現するか」の全体像に落とし込んだ設計成果物です。画面・帳票・外部インターフェース・データ・機能の一覧といった、利用者や発注側から見える範囲を中心に記述します。ウォーターフォール型の開発では、要件定義書の次、詳細設計の手前に位置づけられ、以降の工程の土台になります。
基本設計書の役割は、要件定義で固めた「何を作るか」を「どう作るか」の外形へ翻訳し、発注側とベンダー側の双方が同じ完成イメージを持てる状態を作ることにあります。外部設計と呼ばれることもあり、利用者や業務担当から見える範囲を扱う点が特徴です。
ここで扱う軸は大きく分けて三つあります。第一に、画面レイアウトや操作の流れといった「使う人から見える振る舞い」。第二に、他システムやファイル連携などの「外部との接点」。第三に、扱うデータの構造や項目定義といった「情報の器」です。
記載する内容はプロジェクトや開発標準によって差がありますが、外部から見える設計という軸で整理すると、いくつかの定番があります。誰が読み手かを意識しながら、粒度をそろえて書いていきます。
これらは相互に関係するため、画面で使う項目とデータ項目、外部連携の内容が食い違わないよう、横のつながりを確認しながら書き進めます。
作成の主体は、SIerやベンダー側の設計担当が中心になることが多く、発注側の業務担当やPMがレビューと合意の役割を担います。進め方には、要件から設計へ橋渡しする一定の順序があります。
PMが関わるつまずきどころとして、レビューが形式的な確認で終わり、発注側が完成イメージを持てないまま先へ進んでしまう形があります。画面のサンプルや業務シナリオを添えて、読み手が判断できる材料を用意すると認識のずれを減らせます。もう一つは、要件が固まりきらないうちに設計を進め、後から要件が変わって基本設計へ戻る形です。
基本設計書は、前後の工程の成果物と混同されやすいため、「誰から見た内容か」「抽象度」という軸で位置づけを整理しておくと役立ちます。
基本設計書を読み解き、レビューを設計できることは、PMにとって工程間の橋渡しの力に直結します。要件定義から実装へ移る局面で、外形の合意が曖昧なまま先へ進むと、下流で手戻りが積み上がりやすくなります。基本設計のどこに合意の勘所があるかを押さえておくと、進捗管理や変更管理の判断がしやすくなります。
とくにSIerやITコンサル系のプロジェクトでは、発注側とベンダー側の認識のずれが基本設計の段階で表面化することが多く、ここでの調整役を担えるPMは重宝されます。設計そのものを書けなくても、読み手が判断できる材料を用意させ、レビューを実質的な合意の場にできるかが、キャリアの幅を広げる一つの軸になります。
基本設計書は誰が読むことを想定して書きますか。
利用者や業務担当を含む発注側と、後工程を担う開発チームの双方が読み手です。発注側が完成イメージを確認して合意でき、かつ詳細設計の入力にもなる粒度が求められます。業務の言葉と設計の言葉を両立させ、専門用語だけで固めないことが目安になります。
基本設計と詳細設計はどう違いますか。
基本設計は画面や外部連携など利用者から見える外形を扱う外部設計、詳細設計は処理ロジックや内部構造など開発者が実装するための内部設計です。基本設計で決めた外形を、詳細設計が実装可能な粒度へ具体化する関係にあり、記述の抽象度と読み手が異なります。
アジャイル開発でも基本設計書は作りますか。
基本設計書はウォーターフォール型の工程で明確に位置づけられる成果物です。アジャイル開発では同じ形の文書を厚く作るとは限らず、必要な範囲を軽い設計メモやプロダクトバックログの形で扱う場合もあります。開発手法や契約の前提によって、求められる詳しさは変わります。