基本設計工程で最も重要なのは、作業開始前に基本設計書の構成を明確化し、関係者全員で合意を得ることです。

基本設計工程に入る前に、最も重要なことは「最終的に何を作るのか」を明確にすることです。
つまり、基本設計書の構成を事前に決め、関係者全員で合意を得ることが不可欠です。

1. ゴールが曖昧だと、作業の無駄が発生する

基本設計書の構成が決まっていない状態で設計作業を始めると、「何をどこまで書けばよいのか」が不明確になり、手戻りや重複作業が発生します。結果として、プロジェクトの遅延やコスト増につながります。

• 作成者の迷いをなくす: 構成が明確であれば、設計者は「何をどこに書くべきか」で迷うことなく、設計作業に集中できます。これにより、設計書の作成効率が大幅に向上します。
• 手戻りの削減: 作成途中で構成が変更されると、既に書いた内容の移動や修正、再構成が必要となり、大きな手戻りが発生します。早期に合意することで、このような無駄な作業を避けることができます。

2. コミュニケーションが円滑になる

• 共通認識の形成: 関係者（顧客、開発者、テスト担当者、運用担当者など）が、設計書がどのような情報を、どのような順序で提供するのかを事前に理解できます。これにより、レビュー時の議論がスムーズになり、認識のずれを防ぎます。
• レビュー効率の向上: レビューアは、どこに何が書かれているかを把握しているため、効率的にレビューを進めることができます。また、レビューの観点も構成に沿って明確化しやすくなります。

3. 進捗管理がしやすくなる

• 見積もり精度向上: 各セクションの作成にかかる工数をより具体的に見積もることが可能になり、プロジェクト計画の精度が向上します。
• 進捗状況が把握しやすい: 構成項目ごとに作成状況を管理できるため、設計フェーズの進捗をより正確に把握できます。

4. 品質の担保

• 網羅性の確保: 必要な項目が事前に定義されていれば、設計内容の抜け漏れを防ぐことができます。特に、非機能要件や運用・保守に関する項目など、見落とされがちな重要な要素を確実に盛り込めます。
• 一貫性の維持: 複数の設計者が関わる場合でも、統一された構成に従うことで、文書全体の一貫性を保ち、品質を安定させることができます。

基本設計書の構成は、それを作成するベンダ側と、受領する顧客側の共同作業によって決定され、合意されます。

ベンダ側において、構成を決める最終的な責任者は、プロジェクトマネージャー（PM）です。PMは、エンジニアの意見を参考にしながら、プロジェクトの特性、制約条件、チームのスキル、顧客の要求などを総合的に判断し、最適な基本設計書の構成を決定します。

基本設計書の構成を決める際には、以下のレベルまで事前に明確化しておくことが推奨されます。

• 第1階層(章レベル): 必須。どのような大項目(章)が必要かを明確にします。これは構成のルートとなる基本設計書テンプレートの目次を決めることでもあります。例:「文書情報」「外部仕様設計」「移行設計」「テスト方針・計画」など。
• 第2階層(節レベル): 推奨。各章にどのような節が含まれるかを定義します。例:「外部仕様設計」配下に「UI仕様設計」「バッチ処理仕様設計」「外部IF仕様設計」など。
• 第3階層以降(項レベル): 任意。プロジェクトの複雑性や重要度に応じて、より詳細な構成を事前に決めることもできますが、柔軟性を残すため、設計作業の進行に応じて調整することも可能です。

基本設計書の構成を決定する際は、以下のステップに従って進めることを推奨します。

1. 標準テンプレートの確認:
   • を確認し、それをベースに検討します。
2. プロジェクト固有の特性に基づくカスタマイズ案の作成:
   • プロジェクトの規模（単一システムである）、顧客の要望（外部仕様合意の重視）、技術スタック、非機能要件、開発体制などを考慮し、テンプレートをカスタマイズします。
3. 関係者間でのレビューと議論:
   • 作成した構成案をまずは開発チーム内でレビューを行い、実現可能性や作業工数の妥当性を検証します。
   • 構成案を顧客に提示し、レビュー会議を通じて合意を形成します。この際、各章・節の目的と記載内容を明確に説明することが重要です。
   • 各関係者の視点から、抜け漏れがないか、分かりやすいか、必要な情報が網羅されているかなどを議論します。
   • 特に、顧客には「この構成で、必要な情報が全て提供され、承認できるか」を確認します。
4. 最終的な合意とベースライン化:
   • レビューでの指摘事項を反映し、最終的な基本設計書の構成を確定します。

標準テンプレートは、多くのプロジェクトに適用可能な汎用的な構成として設計されていますが、すべてのプロジェクトに完全に適合するわけではありません。プロジェクトの特性や制約に応じて、テンプレートをカスタマイズ（テーラリング）することが重要です。以下に、テーラリングを行う際の主な指針を示します。

• プロジェクト規模による調整: 小規模プロジェクトでは、詳細すぎる構成は過剰になるため、必要最小限の項目に絞り込みます。逆に大規模プロジェクトでは、より詳細な分類や追加の章が必要になる場合があります。
• 顧客要求への対応: 顧客が特定のドキュメント形式や構成を要求する場合、それに合わせてテンプレートを調整します。例えば、外部仕様の詳細化を重視する場合は、画面設計や帳票設計の章を充実させます。
• 技術スタックの特性: 使用する技術やアーキテクチャによって、必要な設計項目が異なります。例えば、マイクロサービスアーキテクチャの場合は、サービス間連携の設計項目を追加する必要があります。

基本設計書は、その章構成や記載内容、表現について、標準規格によって品質基準が定められています。これは相応の理由がない限り、遵守しなければなりません。

📄基本設計書の完成条件

以下の要素は、どのようなプロジェクトにおいても基本設計書に含めるべき必須項目です。これらを省略すると、設計の品質や後工程への引き継ぎに重大な影響を及ぼす可能性があります。
顧客側が担当する場合は、その品質を開発側でも確認する必要があります。

• 文書情報
• システム方式設計
• 外部仕様設計
• レビュー・承認欄

次のページ → 🚧基本設計のプロセスモデル