基本設計書 書き方

基本設計書を書く目的は、要件定義書で言語化された要求を、開発チームが実装できる粒度まで落としつつ、発注側が内容を確認できる抽象度に保つことにあります。外部設計とも呼ばれ、利用者から見える範囲、つまり画面の遷移や帳票の様式、他システムとのやり取りを中心に据えます。内部のクラス構造やモジュール分割は、後段の詳細設計に委ねます。

位置づけを整理する軸は「誰が読むか」です。基本設計書は、開発リーダーやエンジニアだけでなく、業務部門の担当者やテスト設計者も読み手になります。そのため、プログラムの内部事情ではなく、入力・処理・出力の対応関係を業務の言葉で説明できる状態にしておく必要があります。

PMがここで担うのは、合意形成の管理です。要件定義で決めたスコープと基本設計の記述がずれていないか、決めきれていない論点が設計書の中に曖昧なまま残っていないかを点検します。設計者が技術的な最適解を書いていても、発注側が確認できない書き方になっていれば、受け入れ時の認識違いの火種になります。

書く順番は、利用者に近い外側から内側へ進めると整理しやすくなります。先に全体の処理方式やシステム構成を押さえ、次に個別の画面・帳票・インターフェース、最後にそれらが読み書きするデータ、という流れです。いきなり項目を列挙するのではなく、代表的な業務シナリオを一本通してから細部を詰めると、抜けに気づきやすくなります。

• 方式・構成の設計
  システム構成図や処理方式、ハードウェアやミドルウェアの前提をまとめ、全体の骨格を先に固めます。
• 画面・帳票の設計
  画面一覧と画面遷移図、各画面のレイアウトと項目定義、帳票の様式を定義します。入力チェックやエラー時の振る舞いもここに書きます。
• インターフェースの設計
  他システムや外部サービスとのデータ連携について、連携方式・項目・タイミング・エラー時の扱いを決めます。
• データの設計
  エンティティの関連や主要なテーブルの項目定義、コード体系を整理し、画面や帳票が参照する元を揃えます。

これらの担い手は、設計者が原案を書き、業務部門が内容を確認し、PMが要件とのつながりを検証する、という分担が一般的です。成果物名は現場によって差がありますが、画面定義書・帳票定義書・インターフェース仕様・テーブル定義といった単位でまとまることが多いです。

個別項目を書くときの軸は「後工程の誰が、何を判断に使うか」です。詳細設計者が実装を起こせること、テスト設計者がテスト条件を導けること、業務部門が自分の業務と照らせること。この三者が読めるかどうかで、書くべき粒度が決まります。

• 画面項目は定義表で揃える
  項目名、型、桁数、必須か任意か、初期値、入力チェック内容を表にします。チェックの条件を言葉で曖昧に書くと、実装とテストで解釈が割れます。
• 画面遷移は分岐まで描く
  正常系だけでなく、入力エラーや権限不足のときにどこへ戻るかまで示します。分岐の抜けは、結合テストで初めて露見しがちです。
• インターフェースは異常時を先に決める
  連携が失敗したとき、再送するのか、保留するのか、誰に通知するのかを正常系と同じ重さで書きます。
• データ項目は出どころを明記する
  画面で入れる値か、他システムから来る値か、計算で導く値かを区別し、コードの意味も対応表で添えます。

つまずきやすいのは、文章で雰囲気だけ書いてしまうことです。「適切にチェックする」「必要に応じて通知する」といった表現は、読み手ごとに想像が分かれます。条件と結果をセットで、表や箇条書きの形に落とすと、認識の幅が狭まります。

基本設計書で起きやすいつまずきは、抽象度の管理です。詳細設計に踏み込みすぎてクラス構造まで書き込むと、発注側が確認できなくなり、レビューが形骸化します。逆に要件定義書と変わらない抽象度のままだと、詳細設計者が実装判断の材料を得られません。外から見える振る舞いまでは言い切り、内部実装は書かない、という線を引くことが目安になります。

もう一つのつまずきは、トレーサビリティの欠落です。要件定義書のどの要求が、基本設計書のどの項目に対応するのかをたどれないと、仕様変更が入ったときに影響範囲を追えなくなります。要求と設計項目を対応づける一覧を持っておくと、変更管理の精度が上がります。

隣接する成果物との違いを押さえる軸は「抽象度と読み手」です。要件定義書は「何を実現するか」を業務側の言葉で書き、基本設計書は「利用者から見える振る舞いと構造」を書き、詳細設計書は「内部でどう実装するか」を開発側の言葉で書きます。同じシステムを三段階の解像度で記述していると捉えると、どこに何を書くかの迷いが減ります。

基本設計書を読み書きできることは、PMにとって開発チームと発注側の間に立つための共通言語になります。設計者が書いた内容を、要件とのずれや抽象度の崩れという観点で点検できると、レビューの場で論点を具体的に指摘できます。これは進捗管理や変更管理の精度にも直結します。要求と設計項目の対応をたどれる状態を保っておけば、仕様変更が入ったときに影響範囲を素早く見立てられるからです。

キャリアの観点では、上流の設計工程に踏み込めるかどうかが、任される範囲の広さを左右します。実装の細部まで書けなくても、どこに何が書かれているべきかを判断でき、抜けや曖昧さを見つけられるPMは、要件定義から設計、テストまでの一貫した品質に責任を持てます。設計書を介した合意形成の経験を積むことが、担当領域を広げる足がかりになります。

基本設計書と詳細設計書は何が違いますか。

基本設計書は、画面や帳票、外部連携など利用者から見える振る舞いと構造を、発注側も確認できる言葉で書きます。詳細設計書は、その振る舞いを実現する内部のモジュール構成やロジックを開発側の言葉で書きます。読み手と抽象度が異なると捉えると整理しやすくなります。

基本設計書を書くとき、最初に何から着手すべきですか。

個別項目を列挙する前に、全体の処理方式とシステム構成を固め、代表的な業務シナリオを一本通すとよいでしょう。外側の骨格を先に決めてから、画面・帳票・インターフェース・データへ降りていくと、項目の抜けや分岐の漏れに気づきやすくなります。

PMは基本設計書にどこまで関わればよいですか。

設計の細部を自分で書くより、要件定義書との対応が取れているか、曖昧な記述が残っていないか、発注側が確認できる書き方かを点検する役割が中心になります。要求と設計項目のトレーサビリティを保つことが、後の変更管理や受け入れの精度につながります。