解説

• 解答群にあるレビュー技法の特徴は以下のとおりです。

  インスペクション

  事前に役割を決められた参加者が責任のある第三者（モデレーター）の下で成果物を確認し、正式なレビュー記録を残す、最も公式なレビュー技法。通常3人から6人が参加して実施され、議長・司会を務める「モデレーター」、レビュー対象となる成果物の作成者である「オーナー」、評価者としてレビュー対象となる成果物の問題発見を行う「インスペクター」、ミーティングにて参加者に資料の説明を行う「プレゼンター」、書記としてレビューで発見された問題などを記録する「スクライブ」などの役割がある。

  ウォークスルー

  開発者や開発チームが主体となり、エラーの早期発見を目的としてプログラムのステップごとにシミュレーションを行いながら確認をしていくレビュー技法。ウォークスルーは演劇用語で「（気軽に行われる）立ち稽古」。

  パスアラウンド

  レビュー対象の成果物をメールやグループウェアを利用して複数の評価者（レビュア）に配布・回覧し、指摘やフィードバックを依頼するレビュー技法。同じ時間・場所に集まって会議を開くのが難しい場合に有効で、レビュアの負担も少ないが、他のレビュアとの意見交換ができず議論を深めることが難しいというデメリットもある。

  ラウンドロビン

  レビュー参加者が持ち回りで責任者を務めながら全体のレビューを進めていくレビュー技法。説明や発言などの機会が均等に割り当てられるので、参加者の知識レベル向上、チームメンバーの意思疎通や参加意欲の向上に有効とされる。

  下線①は、成果物を複数のレビュアに配布又は回覧とあるので「ウ：パスアラウンド」、下線②は、モデレーターによって主催され、正式な記録を残すとあるので「ア：インスペクション」が適切です。
  
  ∴下線①＝ウ：パスアラウンド
  　下線②＝ア：インスペクション
  
  
• 〔aについて〕
  空欄には、集合ミーティングの終了時に、意思決定のルールに従って評価を導く者が当てはまります。本問ではインスペクションを実施する際の役割として、モデレーター、読み手、記録係、レビュアが挙げられているので、この中のいずれかということになります。
  
  表2項番2の"キックオフミーティング"を読むと、モデレーターが評価の判断基準を参加者に説明することや、評価を導く意思決定ルールの合意形成を行う旨の説明があります。モデレーターはレビュー会議を主催し、会議を進行する役割をもちますから、評価の結論を出す人物として適任です。したがって、空欄aには「モデレーター」が当てはまります。
  
  ∴a＝モデレーター
  
  
• 〔bについて〕
  ①設計書の修正によって生じる可能性がある、②欠陥の解決後に確認すべき事象という2点を踏まえて本文中から探します。
  
  〔A社の品質管理方針〕には、「レビューで見つかった欠陥の修正において，新たな欠陥である二次欠陥が生じないように確認することを徹底している」とあります。この記述より、品質管理方針を順守するため、修正後に二次欠陥が生じていないことを確認するプロセスが必要と判断できます。したがって、空欄bには「二次欠陥」が当てはまります。
  
  ∴b＝二次欠陥

解説

• 各グループのリーダーにモデレーターの経験を積ませたい
• リーダーは自グループのレビュー会議にはモデレーターとして参加させない
• B氏はレビュー会議に参加しない

解説

• 一般的に、レビュー指摘密度が低くなる原因としては、品質が高い場合とレビューが適切に行われていない場合があります。
  
  レビュー会議においてLCL（下方管理限界）が不要となっている第1群は「誤字，脱字，表記ルール違反の件数」を対象としています。表1を見ると「誤字，脱字，表記ルール違反」は、設計途中のレビューにおいて、修正箇所の候補を抽出するツールを使ってできるだけ排除する手順となっています。つまり、レビュー会議を行う前に一定程度取り除かれていることになるので、レビュー会議での指摘数が少ないのは当然のことであり、少なくても品質上の問題はないと言えます。逆に多すぎる場合は、設計途中のレビューが適切に行われていないということなので、UCL（上方管理限界）は適用されているというわけです。
  
  LCLを不要とした理由としてはいくつか答え方があると思いますが、レビュー会議をする前段階で既に排除されていることを説明すればよいので、レビュー会議の前に排除されているから、設計途中のレビューで排除されているから、ツールを使って抽出しているから、などの解答が適切と言えます。
  
  ∴・ツールの利用で抽出可能だから
  　・設計途中のレビューで排除されているから
  
  
• 〔cについて〕
  図1のグラフを各軸ごとに見ると以下のように判定されます。Cグループは、レビュー工数（第1群）は問題ありませんが、レビュー指摘密度（第2群）がLCLを下回っていることがわかります。
  
  • 誤り。レビュー指摘密度がLCLを下回っているので、しきい値内ではありません。
  • 誤り。レビュー指摘密度がUCLより高ければ設計不良となりますが、Cグループの値は低すぎるので直ちに設計不良と判断することはできません。
  • 誤り。レビュー工数はしきい値内に収まっているため、指摘件数が少なかったのは、レビューにかけた工数が不足していたからではありません。したがって、何の対策も行わずに追加のレビューを実施するのは不適切です。
  • 誤り。レビュー指摘密度には、LCLとUCLの両方が適用されます。値はLCLとUCLの間に収まっていなければならないので不適切です。
  • 正しい。レビュー会議に十分な工数をかけたのに、欠陥を十分に洗い出せていない可能性が考えられます。それにもかかわらず、Cグループに対する確認結果ではレビュー会議の状況を「特に課題なし」としています。レビューの方法、レビューの進め方に問題がある可能性があるので、改善を指示するのは適切な対応となります。
  ∴c＝オ：レビューの進め方，体制に問題がないか点検するようにモデレーターに指示した。
  
  
• 表5のグループEの確認結果には、「集合ミーティングの時間中に，一部の欠陥の修正方法，修正内容の議論が始まってしまい，会議の予定時間を大きくオーバーした」とあります。表1中に「レビュー会議の目的は、設計上の欠陥（矛盾、不足、重複など）を検出することである。検出した欠陥の対策は、欠陥の検出とは別のタイミングで議論する」としているように、集合ミーティングでは欠陥の検出こそ重要であり、Eグループのように集合ミーティング内で欠陥の修正まで議論するのはルール違反であることがわかります。したがって改善指針としては、集合ミーティングで欠陥の修正を議論するのをやめる、集合ミーティングでは欠陥の指摘だけを行う、などの解答が適切となります。
  
  ∴集合ミーティングでは欠陥の指摘だけ行う