2022年 秋期 応用情報技術者試験 問8
設計レビュー
A社は、中堅のSI企業である。A社は、先頃、取引先のH社の情報共有システムの刷新を請け負うことになった。A社は、H社の情報共有システムの刷新プロジェクトを立ち上げ、B氏がプロジェクトマネージャとしてシステム開発を取り仕切ることになった。H社の情報共有システムは、開発予定規模が同程度の四つのサブシステムから成る。
A社では、プロジェクトの開発メンバーをグループに分けて管理することにしている。B氏は、それにのっとり、開発メンバーを、サブシステムごとにCグループ、Dグループ、Eグループ、Fグループに振り分け、グループごとに十分な経験があるメンバーをリーダーに選任した。
A社の品質管理方針
設計上の欠陥がテスト工程で見つかった場合、修正工数が膨大になるので、A社では、設計上の欠陥を早期に検出できる設計レビューを重視している。また、レビューで見つかった欠陥の修正において、新たな欠陥である二次欠陥が生じないように確認することを徹底している。
A社のレビュー形態
A社の設計工程でのレビュー形態を表1に示す。
| 実施時期 | レビュー実施方法 |
|---|---|
| 設計途中（グループのリーダーが進捗状況を考慮して決定） | グループのメンバーがレビューアとなる。 ①設計者が設計書（作成途中の物も含む）を複数のレビューに配布又は回覧して、レビューアが欠陥を指摘する。誤字、脱字、表記ルール違反は、この段階でできるだけ排除する。誤字、脱字、表記ルール違反のチェックには、修正箇所の候補を抽出するツールを利用する。 |
| 外部設計、内部設計が完了した時点 | グループ単位でレビュー会議を実施する。必要に応じて別グループのリーダーの参加を求める。設計書の読み上げ、設計上の欠陥（予備、不足、重複など）を検出することである。設計途中のレビューで検出された欠陥の対策は、欠陥の検出とは別のタイミングで議論する。設計途中のコードレビューの結果、次の工程に進むか判断基準の一つになっている。 |
外部設計や内部設計が完了した時点で行うレビュー会議の手順を表2に示す。
| 項番 | 項目 | 内容 |
|---|---|---|
| 1 | 必要な文書の準備 | 設計者が設計書を作成してモデレーターに送付する。 モデレーターがチェックリストなどを準備する。 |
| 2 | キックオフミーティング | モデレーターは、設計書、チェックリストを配布し、参加者がレビューの目的を達成できるように、設計内容の背景、前提、重要機能などを説明する。 |
| モデレーターは、集合ミーティングにおける設計書の評価について、次の基準に基づいて定性的に判断することを説明する。 "合格"……軽微な修正が必要かもしれないが、フォローアップミーティングは不要である。 | ||
| "条件付合格"……小規模な修正が必要で、フォローアップミーティングで修正を検証する。 | ||
| "やり直し"……大規模な修正が必要、又は、次階や課題の検出が十分でないのでレビュー会議をやり直す。 | ||
| 3 | 参加者の事前レビュー | 評価を導く意思決定のルール（モデレーターによる決定、多数決、全員一致）について、参加者全員の合意を得る。 モデレーターは、集合ミーティングにおける読み手、記録係、レビューアを指名する。 集合ミーティングまでに、レビューアが各自でチェックリストに従って設計書のレビューを行い、欠陥を洗い出す。 |
| 4 | 集合ミーティング | 読み手がレビュー対象の設計書を参加者に説明して、レビューアから指摘された欠陥を記録係が記録する。 aは、集合ミーティングの終了時に、意思決定のルールに従い"合格"、"条件付合格"、"やり直し"の評価を導く。 |
| 5 | 発見された欠陥の解決 | 集合ミーティングで発見された欠陥を設計者が解決する。 |
| 6 | フォローアップミーティング | 評価が"条件付合格"の場合に、モデレーターと設計者を含めたメンバーとで実施する。 欠陥が全て解決されたことを確認する。 設計書の修正がbを生じさせることなく正しく行われたことを確認する。 |
モデレーターの選定
B氏は、グループのリーダーにモデレーターの経験を積ませたいと考えた。しかし、グループのリーダーは自グループの開発内容に精通しているので、自グループのレビュー会議にはモデレーターではなく、レビューアとして参加させることにした。
また、B氏自身は開発メンバーの査定に関わっており、参加者が欠陥の指摘をためらうおそれがあると考え、レビュー会議には参加しないことにした。
B氏は、これらの考え方に基づいて、各グループのレビュー会議の③モデレーターを選定した。
レビュー会議におけるレビュー結果の評価
A社の品質管理のための基本測定量（抜粋）を表3に示す。
| 対象工程 | 基本測定量 | 単位 | 補足 | |
|---|---|---|---|---|
| 設計工程 | 設計書の規模 | ページ | ||
| レビュー工数 | 人時 | 表2のレビュー会議の手順の項番3と項番4に要した工数の合計を測定する。 工数を標準化するために、青成目的などで標準的なスキルをもたないレビューを参加させる場合は、その工数は合めない。 | ||
| レビュー指摘件数 | 第1群 | 件 | 誤字、脱字、表記ルール違反の件数を測定する。 | |
| 第2群 | 件 | 誤字、脱字、表記ルール違反以外の、設計上の欠陥の件数を測定する。 | ||
レビュー会議における設計書のレビュー結果を、基本測定量から導出される指標を用いて分析する。設計書のレビュー結果の指標を表4に示す。
| 指標 | 説明 |
|---|---|
| レビュー工数密度 | 1ページ当たりのレビュー工数 |
| レビュー指摘密度（第1群） | 1ページ当たりの第1群のレビュー指摘件数 |
| レビュー指摘密度（第2群） | 1ページ当たりの第2群のレビュー指摘件数 |
レビュー工数密度には、下方管理限界（以下、LCLという）と上方管理限界（以下、UCLという）を適用する。
④レビュー指摘密度（第1群）にはUCLだけ適用する。レビュー指摘密度（第2群）には、LCLとUCLを適用する。レビュー指摘密度（第1群）が高い場合、設計途中に実施したグループのメンバーによるレビューが十分に行われていないことが多く、レビュー指摘密度（第2群）も高くなる傾向にある。
H社の情報共有システムの内部設計が完了して、内部設計書のレビュー会議の集合ミーティングの結果は、全てのグループについて"条件付合格"であった。指標の集計が完了して、フォローアップミーティングも終了した段階で、B氏は、次の開発工程に進むかどうかを判断するために、内部設計書のレビュー結果の詳細、及び指標を確認した。
開発グループごとに、レビュー工数密度を横軸に、レビュー指摘密度を縦軸にとった、レビューのゾーン分析のグラフを図1に示す。
凡例: ○：第1群の数値、●：第2群の数値、-----：しきい値、_____：同じグループの数値
B氏が、各グループのモデレーターにレビュー会議の状況について確認した結果と、B氏の対応を表5に示す。
| グループ | 確認結果 | 対応 |
|---|---|---|
| C | 特に課題なし。 | c |
| D | 計画した時間内にチェックリストの項目を全て確認した。 | しきい値内であり、問題なしと判断した。 |
| E | 集合ミーティングの時間中に、一部の欠陥の修正方法、修正内容の議論が始まってしまい、会議の予定時間を大きくオーバーした。 レビュー予定箇所の全てでチェックしたもののの、集合ミーティングの後半部分で取り上げた設計書のレビューがかなり駆け足になった。 | レビュー会議の進め方についてレビュー効率向上の観点から⑤改善指針を示した上で、レビュー会議のやり直しをモデレーターに指示した。 |
| F | 指摘件数が多かったので、欠陥の指出は十分と考えて、集合ミーティングの終了予定時刻より前に終了させた。 | レビューが不十分なおそれが大きく、追加のレビューを実施するようにモデレーターに指示した。 |
B氏は、表5の対応後に、対応状況を確認して、次の工程に進むと判断した。