Part5では,基本設計フェーズにおける成果物の品質を向上させる施策について解説する。カギは,欠陥を除去するとともに欠陥を防止する仕組みを確立すること。重要な成果物については有識者を交えて「インスペクション」を実施することも大切だ。

 「考慮していない外部システムとの連携が詳細設計で見つかった」,「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても,その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し,進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。

 そこでPart5では,基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。

「欠陥防止」を徹底する

 改めて言うまでもないが,基本設計の成果物の品質を向上させるプロセスは,(1)設計作業を実施する,(2)成果物をレビューして欠陥を洗い出す,(3)発見した欠陥を除去する――という3つのステップを踏む。このサイクルを繰り返し,すべての成果物に欠陥がないことを確認してユーザーからの承認を得られれば,基本設計が完了する。

 ところが,この品質向上プロセスにとらわれすぎて,逆に品質が上がらないプロジェクトが目立っている。と言うのも,設計作業の後でレビュアー(評価者)が成果物を評価するため,設計した本人が「どうせ後でレビューしてくれるのだから,これぐらいの内容でいいだろう」と考えてしまうことがあるからだ。つまり品質向上プロセスを徹底させることで,逆に設計者自身の成果物に対する責任を低下させ,問題を先送りにする体質が身に付く可能性がある。

 こうした問題を招く最大の原因は,品質向上プロセスの目的を「欠陥を除去する」ことだけに置く点だ。より大切なのは,「欠陥の除去」とともに「欠陥の防止」のための仕組みを確立することである。防止策を施すことで,設計者の品質に対する意識も変わってくる。

7つの準備を怠らない

 欠陥を防止する仕組みとは,「欠陥を作り込ませないための施策」を意味する。具体的には,次の7つの事前準備を基本設計フェーズの初期段階で実施する必要がある(図1)。

図1●レビュー効果を高めるために実施すべき主な事前準備
図1●レビュー効果を高めるために実施すべき主な事前準備
これらの事前準備を怠ると,時間をかけてレビューしてもなかなか欠陥の除去や発生防止につながらない。まずは事前準備を徹底することを心掛けるべきだ

 1つ目は「レビュー体制の明確化」である。これは,ユーザー企業側,ベンダー側双方のレビュアーや,成果物を承認するためのルートを明らかにする作業だ。

 2つ目は「進ちょく管理方法の確認」である。ここでは,EVMをはじめとする進ちょく管理手法や,基本設計のマイルストーン(終了基準)を明確にする。

 3つ目は,「レビュー・ミーティングの種類と進め方の決定」である。これは,どんなレビューをどの時期に実施するのかを決める作業だ。レビューには,(1)設計者自身で成果物を検証する「セルフチェック」,(2)プロジェクト内で成果物を検証する「デザインレビュー」,(3)品質保証部門が抜き取りで成果物を検査する「ドキュメント探針」,(4)品質保証部門が全ドキュメントの合否を判定する「ドキュメント検査」,(5)設計プロセスとマネジメント・プロセスが正しく機能しているかどうかを検証する「プロセス評価」,そして(6)ユーザーが成果物の内容を承認する「顧客レビュー」――の6種類がある(表1)。これらのレビューをどのタイミングで実施するのかを明らかにする。

表1●基本設計フェーズにおける6つのレビュー
(1)~(4),および(6)については成果物(ドキュメント)に対するレビューを行うが,(5)については設計プロセスおよびマネジメント・プロセスに対する評価を行う。これらのレビュー作業をプロセスに埋め込むと同時に,基本設計フェーズ終了後に実際にうまく機能したかどうかを検証することが重要である
[画像のクリックで拡大表示]

 4つ目は,「入力情報の確認と品質の確保」だ。基本設計の入力情報は,要件定義で作成した機能要件や非機能要件,制約条件である。だが,こうした入力情報が基本設計フェーズの初期段階で詳細になっているケースはまれだ。そこで設計作業に入る前に要件定義書を吟味し,不足している部分については改めて作成する。

 5つ目は,「キックオフミーティングによるメンバー同士の意思統一」。これは,メンバー全員がプロジェクトの目的や基本設計の役割を共有し,コミュニケーションをスムーズに取れるようにするのが目的だ。

「設計ルール」を確立する

 6つ目の「各種基準の整備」と,最後の「書き方に関するメンバー教育の実施」は,事前準備の中で最も重要なので特に詳しく説明しよう。

 基本設計における各種基準とは,設計に関する「ルール」のことである。プログラミング時に「コーディング規約」があるように,基本設計にも守るべき「ルール」が存在する。書き方に関するメンバー教育は,このルールに従って成果物を作成することを周知徹底するために実施する。

 基本設計の基準には,「成果物の種類」や「モデルの表記法」,「設計書のフォーマット」のほか,システム開発上使用するビジネス用語の意味をまとめた「ネーミングルール」,単語の表記(漢字・カナ・ひらがなの使い分けなど)を示した「用字・用語集」などがある。このうち成果物の種類やモデルの表記法については,ほとんどのケースで定義できているだろう。また,設計書のフォーマットについても,全社・グループ標準のフォーマットや,ユーザーから指定を受けたフォーマットを用いれば問題ない。

 忘れられがちなのは,ネーミングルールと用字・用語集をきめ細かく整備することだ。ネーミングルールや用字・用語集を侮る人がいるが,これほど重要なものはない。なぜなら,DFD(Data Flow Diagram)やER(Entity Relationship)図,クラス図など基本設計で作成すべき成果物のほとんどが,モノ(プロセスやデータ,オブジェクト)が何か,モノとモノの関係(リレーション)がどうなっているのかを示す。当然,モノを表す言葉が本来の意味と違っていたり,成果物間で表記がバラバラになっていたりすると,詳細設計以降で必ず問題が発生する。

この先は会員の登録が必要です。今なら有料会員(月額プラン)が2020年1月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら