令和4年秋期試験午後問題 問8

問8 情報システム開発

⇱問題PDF
設計レビューに関する次の記述を読んで,設問に答えよ。
 A社は,中堅のSI企業である。A社は,先頃,取引先のH社の情報共有システムの刷新を請け負うことになった。A社は,H社の情報共有システムの刷新プロジェクトを立ち上げ,B氏がプロジェクトマネージャとしてシステム開発を取り仕切ることになった。H社の情報共有システムは,開発予定規模が同程度の四つのサブシステムから成る。
 A社では,プロジェクトの開発メンバーをグループに分けて管理することにしている。B氏は,それにのっとり,開発メンバーを,サブシステムごとにCグループ,Dグループ,Eグループ,Fグループに振り分け,グループごとに十分な経験があるメンバーをリーダーに選定した。

〔A社の品質管理方針〕
 設計上の欠陥がテスト工程で見つかった場合,修正工数が膨大になるので,A社では,設計上の欠陥を早期に検出できる設計レビューを重視している。また,レビューで見つかった欠陥の修正において,新たな欠陥である二次欠陥が生じないように確認することを徹底している。

〔A社のレビュー形態〕
 A社の設計工程でのレビュー形態を表1に示す。
pm08_1.png
 外部設計や内部設計が完了した時点で行うレビュー会議の手順を表2に示す。
pm08_2.png
〔モデレーターの選定〕
 B氏は,グループのリーダーにモデレーターの経験を積ませたいと考えた。しかし,グループのリーダーは自グループの開発内容に精通しているので,自グループのレビュー会議にはモデレーターではなく,レビュアとして参加させることにした。
 また,B氏自身は開発メンバーの査定に関わっており,参加者が欠陥の指摘をためらうおそれがあると考え,レビュー会議には参加しないことにした。
 B氏は,これらの考え方に基づいて,各グループのレビュー会議の③モデレーターを選定した

〔レビュー会議におけるレビュー結果の評価〕
 A社の品質管理のための基本測定量(抜粋)を表3に示す。
pm08_3.png
 レビュー会議における設計書のレビュー結果を,基本測定量から導出される指標を用いて分析する。設計書のレビュー結果の指標を表4に示す。
pm08_4.png
 レビュー工数密度には,下方管理限界(以下,LCLという)と上方管理限界(以下,UCLという)を適用する。
 ④レビュー指摘密度(第1群)にはUCLだけ適用する。レビュー指摘密度(第2群)には,LCLとUCLを適用する。レビュー指摘密度(第1群)が高い場合,設計途中に実施したグループのメンバーによるレビューが十分に行われていないことが多く,レビュー指摘密度(第2群)も高くなる傾向にある。
 H社の情報共有システムの内部設計が完了して,内部設計書のレビュー会議の集合ミーティングの結果は,全てのグループについて"条件付合格"であった。指標の集計が完了して,フォローアップミーティングも終了した段階で,B氏は,次の開発工程に進むかどうかを判断するために,内部設計書のレビュー結果の詳細,及び指標を確認した。
 開発グループごとに,レビュー工数密度を横軸に,レビュー指摘密度を縦軸にとった,レビューのゾーン分析のグラフを図1に示す。
pm08_5.png
 B氏が,各グループのモデレーターにレビュー会議の状況について確認した結果と,B氏の対応を表5に示す。
pm08_6.png
 B氏は,表5の対応後に,対応状況を確認して,次の工程に進めると判断した。

設問1

〔A社のレビュー形態〕について答えよ。
  • 表1中の下線①及び下線②で採用されているレビュー技法の種類をそれぞれ解答群の中から選び,記号で答えよ。
  • 表2中のaに入れる適切な役割を本文中の字句を用いて答えよ。
  • 表2中のbに入れる適切な字句を本文中の字句を用いて答えよ。
解答群
  • インスペクション
  • ウォークスルー
  • パスアラウンド
  • ラウンドロビン

解答例・解答の要点

  • 下線①:
    下線②:
  • a:モデレーター
  • b:二次欠陥

解説

  • 解答群にあるレビュー技法の特徴は以下のとおりです。
    インスペクション
    事前に役割を決められた参加者が責任のある第三者(モデレーター)の下で成果物を確認し、正式なレビュー記録を残す、最も公式なレビュー技法。通常3人から6人が参加して実施され、議長・司会を務める「モデレーター」、レビュー対象となる成果物の作成者である「オーナー」、評価者としてレビュー対象となる成果物の問題発見を行う「インスペクター」、ミーティングにて参加者に資料の説明を行う「プレゼンター」、書記としてレビューで発見された問題などを記録する「スクライブ」などの役割がある。
    ウォークスルー
    開発者や開発チームが主体となり、エラーの早期発見を目的としてプログラムのステップごとにシミュレーションを行いながら確認をしていくレビュー技法。ウォークスルーは演劇用語で「(気軽に行われる)立ち稽古」。
    パスアラウンド
    レビュー対象の成果物をメールやグループウェアを利用して複数の評価者(レビュア)に配布・回覧し、指摘やフィードバックを依頼するレビュー技法。同じ時間・場所に集まって会議を開くのが難しい場合に有効で、レビュアの負担も少ないが、他のレビュアとの意見交換ができず議論を深めることが難しいというデメリットもある。
    ラウンドロビン
    レビュー参加者が持ち回りで責任者を務めながら全体のレビューを進めていくレビュー技法。説明や発言などの機会が均等に割り当てられるので、参加者の知識レベル向上、チームメンバーの意思疎通や参加意欲の向上に有効とされる。
    下線①は、成果物を複数のレビュアに配布又は回覧とあるので「ウ:パスアラウンド」、下線②は、モデレーターによって主催され、正式な記録を残すとあるので「ア:インスペクション」が適切です。

    ∴下線①=ウ:パスアラウンド
     下線②=ア:インスペクション

  • aについて〕
    空欄には、集合ミーティングの終了時に、意思決定のルールに従って評価を導く者が当てはまります。本問ではインスペクションを実施する際の役割として、モデレーター、読み手、記録係、レビュアが挙げられているので、この中のいずれかということになります。

    表2項番2の"キックオフミーティング"を読むと、モデレーターが評価の判断基準を参加者に説明することや、評価を導く意思決定ルールの合意形成を行う旨の説明があります。モデレーターはレビュー会議を主催し、会議を進行する役割をもちますから、評価の結論を出す人物として適任です。したがって、空欄aには「モデレーター」が当てはまります。

    a=モデレーター

  • bについて〕
    ①設計書の修正によって生じる可能性がある、②欠陥の解決後に確認すべき事象という2点を踏まえて本文中から探します。

    〔A社の品質管理方針〕には、「レビューで見つかった欠陥の修正において,新たな欠陥である二次欠陥が生じないように確認することを徹底している」とあります。この記述より、品質管理方針を順守するため、修正後に二次欠陥が生じていないことを確認するプロセスが必要と判断できます。したがって、空欄bには「二次欠陥」が当てはまります。

    b=二次欠陥

設問2

本文中の下線③において,モデレーターに選定した人物を,本文中又は表中に登場する人物の中から20字以内で答えよ。

解答例・解答の要点

別グループのリーダー (10文字)

解説

〔モデレーターの選定〕に記載されているB氏の考え方は次のとおりです。
  • 各グループのリーダーにモデレーターの経験を積ませたい
  • リーダーは自グループのレビュー会議にはモデレーターとして参加させない
  • B氏はレビュー会議に参加しない
3つの条件を踏まえると、レビュー会議を実施するグループとは別のグループのリーダーをモデレーターに選ぶのが適任であると判断できます。仮に、Cグループがレビュー会議を実施するなら、Dグループ・Eグループ・Fグループのリーダーのいずれかがモデレーターになるということです。本文中又は表中に登場する人物でこれに合致する字句を探すと、表1中にある「別グループのリーダー」という字句が最も適切です。

∴別グループのリーダー

設問3

〔レビュー会議におけるレビュー結果の評価〕について答えよ。
  • 本文中の下線④でLCLを不要とした理由を20字以内で答えよ。
  • 表5中のcに入れる最も適切な対応を解答群の中から選び,記号で答えよ。
  • 表5中の下線⑤の改善指針を,25字以内で答えよ。
c に関する解答群
  • しきい値内であり,問題なしと判断した。
  • 設計不良なので,再レビューをモデレーターに指示した。
  • レビューが不十分なおそれが大きく,追加のレビューを実施するようにモデレーターに指示した。
  • レビュー指摘密度(第2群)がUCL(第2群)より十分に小さいので,設計上の欠陥はないと判断した。
  • レビューの進め方,体制に問題がないか点検するようにモデレーターに指示した。

解答例・解答の要点

  • ・ツールの利用で抽出可能だから (14文字)
    ・設計途中のレビューで排除されているから (19文字)

  • c:
  • 集合ミーティングでは欠陥の指摘だけ行う (19文字)

解説

  • 一般的に、レビュー指摘密度が低くなる原因としては、品質が高い場合とレビューが適切に行われていない場合があります。

    レビュー会議においてLCL(下方管理限界)が不要となっている第1群は「誤字,脱字,表記ルール違反の件数」を対象としています。表1を見ると「誤字,脱字,表記ルール違反」は、設計途中のレビューにおいて、修正箇所の候補を抽出するツールを使ってできるだけ排除する手順となっています。つまり、レビュー会議を行う前に一定程度取り除かれていることになるので、レビュー会議での指摘数が少ないのは当然のことであり、少なくても品質上の問題はないと言えます。逆に多すぎる場合は、設計途中のレビューが適切に行われていないということなので、UCL(上方管理限界)は適用されているというわけです。

    LCLを不要とした理由としてはいくつか答え方があると思いますが、レビュー会議をする前段階で既に排除されていることを説明すればよいので、レビュー会議の前に排除されているから、設計途中のレビューで排除されているから、ツールを使って抽出しているから、などの解答が適切と言えます。

    ∴・ツールの利用で抽出可能だから
     ・設計途中のレビューで排除されているから

  • cについて〕
    図1のグラフを各軸ごとに見ると以下のように判定されます。Cグループは、レビュー工数(第1群)は問題ありませんが、レビュー指摘密度(第2群)がLCLを下回っていることがわかります。
    pm08_7.png
    • 誤り。レビュー指摘密度がLCLを下回っているので、しきい値内ではありません。
    • 誤り。レビュー指摘密度がUCLより高ければ設計不良となりますが、Cグループの値は低すぎるので直ちに設計不良と判断することはできません。
    • 誤り。レビュー工数はしきい値内に収まっているため、指摘件数が少なかったのは、レビューにかけた工数が不足していたからではありません。したがって、何の対策も行わずに追加のレビューを実施するのは不適切です。
    • 誤り。レビュー指摘密度には、LCLとUCLの両方が適用されます。値はLCLとUCLの間に収まっていなければならないので不適切です。
    • 正しい。レビュー会議に十分な工数をかけたのに、欠陥を十分に洗い出せていない可能性が考えられます。それにもかかわらず、Cグループに対する確認結果ではレビュー会議の状況を「特に課題なし」としています。レビューの方法、レビューの進め方に問題がある可能性があるので、改善を指示するのは適切な対応となります。
    c=オ:レビューの進め方,体制に問題がないか点検するようにモデレーターに指示した。

  • 表5のグループEの確認結果には、「集合ミーティングの時間中に,一部の欠陥の修正方法,修正内容の議論が始まってしまい,会議の予定時間を大きくオーバーした」とあります。表1中に「レビュー会議の目的は、設計上の欠陥(矛盾、不足、重複など)を検出することである。検出した欠陥の対策は、欠陥の検出とは別のタイミングで議論する」としているように、集合ミーティングでは欠陥の検出こそ重要であり、Eグループのように集合ミーティング内で欠陥の修正まで議論するのはルール違反であることがわかります。したがって改善指針としては、集合ミーティングで欠陥の修正を議論するのをやめる、集合ミーティングでは欠陥の指摘だけを行う、などの解答が適切となります。

    ∴集合ミーティングでは欠陥の指摘だけ行う
模範解答

Pagetop