Part5では，基本設計フェーズにおける成果物の品質を向上させる施策について解説する。カギは，欠陥を除去するとともに欠陥を防止する仕組みを確立すること。重要な成果物については有識者を交えて「インスペクション」を実施することも大切だ。
「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。
そこでPart5では，基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。
「欠陥防止」を徹底する
改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，（1）設計作業を実施する，（2）成果物をレビューして欠陥を洗い出す，（3）発見した欠陥を除去する――という3つのステップを踏む。このサイクルを繰り返し，すべての成果物に欠陥がないことを確認してユーザーからの承認を得られれば，基本設計が完了する。
ところが，この品質向上プロセスにとらわれすぎて，逆に品質が上がらないプロジェクトが目立っている。と言うのも，設計作業の後でレビュアー（評価者）が成果物を評価するため，設計した本人が「どうせ後でレビューしてくれるのだから，これぐらいの内容でいいだろう」と考えてしまうことがあるからだ。つまり品質向上プロセスを徹底させることで，逆に設計者自身の成果物に対する責任を低下させ，問題を先送りにする体質が身に付く可能性がある。
こうした問題を招く最大の原因は，品質向上プロセスの目的を「欠陥を除去する」ことだけに置く点だ。より大切なのは，「欠陥の除去」とともに「欠陥の防止」のための仕組みを確立することである。防止策を施すことで，設計者の品質に対する意識も変わってくる。
7つの準備を怠らない
欠陥を防止する仕組みとは，「欠陥を作り込ませないための施策」を意味する。具体的には，次の7つの事前準備を基本設計フェーズの初期段階で実施する必要がある（図1）。
1つ目は「レビュー体制の明確化」である。これは，ユーザー企業側，ベンダー側双方のレビュアーや，成果物を承認するためのルートを明らかにする作業だ。
2つ目は「進ちょく管理方法の確認」である。ここでは，EVMをはじめとする進ちょく管理手法や，基本設計のマイルストーン（終了基準）を明確にする。
3つ目は，「レビュー・ミーティングの種類と進め方の決定」である。これは，どんなレビューをどの時期に実施するのかを決める作業だ。レビューには，（1）設計者自身で成果物を検証する「セルフチェック」，（2）プロジェクト内で成果物を検証する「デザインレビュー」，（3）品質保証部門が抜き取りで成果物を検査する「ドキュメント探針」，（4）品質保証部門が全ドキュメントの合否を判定する「ドキュメント検査」，（5）設計プロセスとマネジメント・プロセスが正しく機能しているかどうかを検証する「プロセス評価」，そして（6）ユーザーが成果物の内容を承認する「顧客レビュー」――の6種類がある（表1）。これらのレビューをどのタイミングで実施するのかを明らかにする。
4つ目は，「入力情報の確認と品質の確保」だ。基本設計の入力情報は，要件定義で作成した機能要件や非機能要件，制約条件である。だが，こうした入力情報が基本設計フェーズの初期段階で詳細になっているケースはまれだ。そこで設計作業に入る前に要件定義書を吟味し，不足している部分については改めて作成する。
5つ目は，「キックオフミーティングによるメンバー同士の意思統一」。これは，メンバー全員がプロジェクトの目的や基本設計の役割を共有し，コミュニケーションをスムーズに取れるようにするのが目的だ。
「設計ルール」を確立する
6つ目の「各種基準の整備」と，最後の「書き方に関するメンバー教育の実施」は，事前準備の中で最も重要なので特に詳しく説明しよう。
基本設計における各種基準とは，設計に関する「ルール」のことである。プログラミング時に「コーディング規約」があるように，基本設計にも守るべき「ルール」が存在する。書き方に関するメンバー教育は，このルールに従って成果物を作成することを周知徹底するために実施する。
基本設計の基準には，「成果物の種類」や「モデルの表記法」，「設計書のフォーマット」のほか，システム開発上使用するビジネス用語の意味をまとめた「ネーミングルール」，単語の表記（漢字・カナ・ひらがなの使い分けなど）を示した「用字・用語集」などがある。このうち成果物の種類やモデルの表記法については，ほとんどのケースで定義できているだろう。また，設計書のフォーマットについても，全社・グループ標準のフォーマットや，ユーザーから指定を受けたフォーマットを用いれば問題ない。
忘れられがちなのは，ネーミングルールと用字・用語集をきめ細かく整備することだ。ネーミングルールや用字・用語集を侮る人がいるが，これほど重要なものはない。なぜなら，DFD（Data Flow Diagram）やER（Entity Relationship）図，クラス図など基本設計で作成すべき成果物のほとんどが，モノ（プロセスやデータ，オブジェクト）が何か，モノとモノの関係（リレーション）がどうなっているのかを示す。当然，モノを表す言葉が本来の意味と違っていたり，成果物間で表記がバラバラになっていたりすると，詳細設計以降で必ず問題が発生する。
