平成28年春期試験午後問題 問9
問9 プロジェクトマネジメント
⇱問題PDF
品質評価に関する次の記述を読んで,設問1,2に答えよ。
品質評価に関する次の記述を読んで,設問1,2に答えよ。
広告
P社は,衣料品を全国の店舗で販売している。P社の情報システム部は,競争力強化を目的とした販売アイテムの大幅な増加と販売ポイントサービスに関する機能の拡充のために,商品販売管理システムのサブシステムX,Y,Zへの追加機能の開発を,短期間で行うことになった。商品販売管理システムは,在庫管理システム,経理システムなどの社内システムとデータの送受信を行っている。情報システム部のQ課長は,今回の開発プロジェクトのプロジェクトマネージャ(PM)として,R主任を指名した。
〔プロジェクト開始準備〕
R主任は,サブシステムの開発に関わる詳細設計・詳細設計レビュー・コーディング・単体テスト・結合テストを請負契約で一括して開発請負会社に発注することにした。サブシステムX,Yの開発については,それぞれ,以前からP社の開発案件を受託しP社の業務仕様を理解しているL社,M社と契約し,サブシステムZの開発については,新規に参加するN社と契約した。N社の実施責任者に現在のコーディング規約を渡して,その内容を説明した。
R主任は,詳細設計書,ソースプログラム,単体テスト項目,結合テスト項目は,各社の手順書に従ってレビューするよう各社の実施責任者に依頼した。各社での結合テスト完了後に,各工程別のテスト成績書による品質判定と納品物の確認を行い,全ての結果が良好と判断された後に,総合テスト工程へ進むことにした。
各サブシステムは,開発規模が同程度の二つのモジュールで構成され,モジュール別の開発の難易度は,表1のとおりである。 詳細設計に着手する直前に,次の2項目に変更が入ったので,各社の実施責任者に変更箇所を電子メール(以下,メールという)で通知し,開発メンバーに周知するように依頼した。
情報システム部が手掛けてきた過去の開発実績のデータに基づき,基本となる工程別の品質判定基準を表2のとおり設定した。 R主任は,品質判定基準を盛り込んだ開発計画書を作成し,Q課長の承認を得てから,自社のプロジェクトメンバー及び各社の実施責任者に開発着手を指示した。
〔品質の評価〕
各社の結合テストが完了後,R主任は,プロジェクトの品質管理担当のメンバーから,各社から提出された工程別の品質実績のデータをサブシステム別に整理した表3の報告を受けた。 R主任は,表2の品質判定基準と表3の品質実績から,次のように考えた。
R主任は,N社に対して,モジュールZ1の欠陥について改修し,原因に基づいて単体テストの項目を見直して,再テストを行うよう依頼した。さらに,モジュールZ2について,コーディング規約の違反が原因で発生した欠陥と同種の欠陥の摘出を行うことによって,品質の確保を行うよう依頼した。
その後,R主任が詳細を調査すると,今回の開発直前に変更した箇所に関係する欠陥が90%であることが判明したので,その結果をQ課長に報告した。
Q課長から,再発防止策を検討するよう指示があったので,まず,R主任は,根本原因分析の技法(以下,なぜなぜ分析という)を使って,分析を実施した。なぜなぜ分析の一部を図1に示す。 そこで,R主任は,根本原因の再発防止策として,コーディング規約などの変更を開発請負会社に通知した場合には,PMが,開発請負会社の実施責任者に,cを確認するよう,開発プロジェクトのルールとして定めることをQ課長に説明した。
Q課長は,次の点についても見直しを行うようR主任に指示した。
〔プロジェクト開始準備〕
R主任は,サブシステムの開発に関わる詳細設計・詳細設計レビュー・コーディング・単体テスト・結合テストを請負契約で一括して開発請負会社に発注することにした。サブシステムX,Yの開発については,それぞれ,以前からP社の開発案件を受託しP社の業務仕様を理解しているL社,M社と契約し,サブシステムZの開発については,新規に参加するN社と契約した。N社の実施責任者に現在のコーディング規約を渡して,その内容を説明した。
R主任は,詳細設計書,ソースプログラム,単体テスト項目,結合テスト項目は,各社の手順書に従ってレビューするよう各社の実施責任者に依頼した。各社での結合テスト完了後に,各工程別のテスト成績書による品質判定と納品物の確認を行い,全ての結果が良好と判断された後に,総合テスト工程へ進むことにした。
各サブシステムは,開発規模が同程度の二つのモジュールで構成され,モジュール別の開発の難易度は,表1のとおりである。 詳細設計に着手する直前に,次の2項目に変更が入ったので,各社の実施責任者に変更箇所を電子メール(以下,メールという)で通知し,開発メンバーに周知するように依頼した。
- 在庫管理システムとのインタフェース
- コーディング規約
情報システム部が手掛けてきた過去の開発実績のデータに基づき,基本となる工程別の品質判定基準を表2のとおり設定した。 R主任は,品質判定基準を盛り込んだ開発計画書を作成し,Q課長の承認を得てから,自社のプロジェクトメンバー及び各社の実施責任者に開発着手を指示した。
〔品質の評価〕
各社の結合テストが完了後,R主任は,プロジェクトの品質管理担当のメンバーから,各社から提出された工程別の品質実績のデータをサブシステム別に整理した表3の報告を受けた。 R主任は,表2の品質判定基準と表3の品質実績から,次のように考えた。
- サブシステムX及びYは,テスト密度及び欠陥数が,全ての工程で品質判定基準内であった。しかし,サブシステムXは,①表2の工程別の品質判定基準を適用して,追加の分析を行った上で品質を判定すべきである。
- サブシステムZは,aでのテスト項目不足,又はbの可能性がある。
- モジュールX1:テスト密度は品質判定基準内であり,欠陥数は品質判定基準を超えているが,開発の難易度を考慮すると品質は良好である。
- モジュールX2:テスト密度と欠陥数は品質判定基準内であり,品質は良好である。
- 特定の開発メンバーの力量不足が,欠陥の原因ではなかった。
- 欠陥の82%はモジュールZ1であった。
- モジュールZ1の欠陥の作り込み原因別の分析では,コーディング規約の違反による欠陥が,単体テストで2件,結合テストで32件抽出された。
- モジュールZ1の欠陥の工程別分析結果は表4のとおりであった。
R主任は,N社に対して,モジュールZ1の欠陥について改修し,原因に基づいて単体テストの項目を見直して,再テストを行うよう依頼した。さらに,モジュールZ2について,コーディング規約の違反が原因で発生した欠陥と同種の欠陥の摘出を行うことによって,品質の確保を行うよう依頼した。
その後,R主任が詳細を調査すると,今回の開発直前に変更した箇所に関係する欠陥が90%であることが判明したので,その結果をQ課長に報告した。
Q課長から,再発防止策を検討するよう指示があったので,まず,R主任は,根本原因分析の技法(以下,なぜなぜ分析という)を使って,分析を実施した。なぜなぜ分析の一部を図1に示す。 そこで,R主任は,根本原因の再発防止策として,コーディング規約などの変更を開発請負会社に通知した場合には,PMが,開発請負会社の実施責任者に,cを確認するよう,開発プロジェクトのルールとして定めることをQ課長に説明した。
Q課長は,次の点についても見直しを行うようR主任に指示した。
- 結合テスト完了時に品質不足が発覚すると,詳細設計やコーディングにまで遡って対処する必要があるので.dやeを起こすおそれがある。したがって,今後,新規に開発に参加する会社と請負契約を締結する場合には,各工程が完了するごとに品質評価結果を提出させることを検討すること。
- 品質が良好であるにもかかわらず,欠陥数が工程別の品質判定基準を超えてしまうという事象が発生した。適切に品質判定ができるよう,fと開発請負会社のスキルレベルを考慮した品質判定基準となるように見直すこと。
広告
設問1
〔品質の評価〕について,(1)~(3)に答えよ。
- R主任がL社に,本文中の下線①を依頼した理由を40字以内で述べよ。
- 本文及び図1中のaに入れる適切な字句を10字以内で答えよ。
- 本文中のbに入れる適切な字句を15字以内で答えよ。
解答例・解答の要点
- モジュールごとに品質の偏りがないかどうかを確認する必要があるから (32文字)
- a:単体テスト (5文字)
- b:詳細設計での品質不足 (10文字)
解説
衣料品販売会社の商品販売管理システムの開発を題材に、品質管理計画と実施、欠陥の分析と対応、再発防止策について問われています。ソフトウェア開発のプロジェクトにおいては、各工程の品質確保がQCDの順守に大きく影響を及ぼすことを理解しておく必要があります。- 「サブシステムX及びYは,テスト密度及び欠陥数が,全ての工程で品質判定基準内であった」にも関わらず、サブシステムXは下線①のように考え、サブシステムYは考えなかったのですから、XとYで何が違うのかを本文から読み解きます。
表1を見ると、サブシステムXは、難易度:高と難易度:低のモジュールで構成されており、モジュールごとの難易度が大きく異なることがわかります。そして表2からは、テスト密度も欠陥数も品質判定基準の最大値に近いことがわかります。ここから、サブシステムX全体としては品質判定基準内だったとしても、個々のモジュール単位でみた場合に、いずれかのモジュールが品質判定基準から大きく外れている可能性が疑われます(特に難易度:高のX1)。
したがって、サブシステムXについてはモジュール別にテスト密度と欠陥数を分析して、モジュールごとの品質を確認する必要があります。もし、品質判定基準から大きく外れていれば、そのモジュールのみに対して何らかの対策を講じる必要があるからです。
∴モジュールごとに品質の偏りがないかどうかを確認する必要があるから - 〔aについて〕
文脈から工程名が入ることがわかります。そして「テスト項目不足」は、単位ステップあたりのテスト項目数であるテスト密度が不足していることを意味しています。表3の工程別の品質実績と表2の工程別の品質判定基準を見比べると、テスト密度が設定されているサブシステムZの2つの工程のうち、単体テストにおいては、テスト密度の実績値118は、150~250の品質判定基準に収まっていません。∴a=単体テスト - 〔bについて〕
(2)と同様に表3と表2を見比べると、単体テストのテスト密度の他に、結合テストの欠陥数も品質判定基準に収まっていません。ここでは、「なぜ結合テストで想定以上の欠陥が判明したのか」を考察することになります。
単体テストのテスト項目数が品質判定基準より少なかったことで、単体テストの欠陥数は品質判定基準内に収まっていたとしても、本来は単体テストで検出されるべき欠陥が次工程である結合テストに持ち越されてしまったというのがありますが、この問題は(2)で解答していますので、これ以外を考えます。結合テストの主なテスト対象はモジュール間のインタフェースですから、ここに品質不足があったのではないかと考えられます。モジュール間インタフェースは詳細設計で決められますから、詳細設計での品質不足が正解の候補となります。サブシステムZの詳細設計レビューでの欠陥数3.5は、品質判定基準の最小値に近く、他のサブシステムと比較しても低い数値ですので、本来はここで判明しなければならなかった欠陥が結合テストに持ち越されてしまったと考えられます。∴b=詳細設計での品質不足
広告
設問2
〔原因分析と再発防止〕について,(1)~(3)に答えよ。
- 本文及び図1中のcに入れる適切な字句を20字以内で答えよ。
- 本文中のd,eに入れる適切な字句を10字以内で答えよ。
- 本文中のfに入れる適切な字句を15字以内で答えよ。
解答例・解答の要点
- c:開発メンバーが正しく理解したこと (16文字)
- d:開発コストの増大 (8文字)
e:納期の遅延 (5文字)
- f:モジュールの開発の難易度 (12文字)
解説
- 〔cについて〕
脈より、コーディング規約に関わる事項が入ることがわかります。コーディング規約について何があったのかに絞って本文を再度読み込みます。
〔プロジェクト開始準備〕の説明では、詳細設計に着手する直前に、コーディング規約に変更が入り、R主任は、各社の実施責任者に変更箇所を電子メールで通知し、開発メンバーに周知するように依頼しています。ところが、図1「なぜなぜ分析」によると、開発メンバーがコーディング規約の変更を知らなかったことが原因3として挙げられています。通知はしたものの、通知を受けた開発メンバーがそれを読んで正しく理解したかを確認する手順(プロセス)がなかったために、このようなことが起きたと考えられます。
∴c=開発メンバーが正しく理解したこと - 〔d、eについて〕
結合テスト完了時に品質不足が発覚して、詳細設計やコーディングにまで遡って対処する結果として起きることが2点問われています。
Q課長からR主任への指示では、「起こすおそれがある」と言っていますので、本文中にはこの2点は記載されていないことがわかります。そこで受験者が自ら何が起きるのかを考えて解答しなければなりません。結合テスト完了後に、前の工程に戻って対処するということは、終わったはずの前工程の作業を再び行うということです。すなわち、本来は必要でなかった作業が発生してしまうということです。予定外の作業が発生すれば、その作業のために進捗が遅れます。さらに場合によれば納期が遅れる可能性があります。また、予定外の作業から生じるコスト増、進捗遅れを取り戻すために追加で要員を投入するコスト増も考えられます。この2点は、プロジェクトのQCDのうちC(コスト)とD(納期)に該当します。
本問のようなウォーターフォールモデルでは、手戻り作業が発生すると大幅な工数増となります。
∴d、e=開発コストの増大、納期の遅延(順不同) - 〔fについて〕
「品質が良好であるにもかかわらず,欠陥数が工程別の品質判定基準を超えてしまうという事象が発生した」と本文で記載されていますので、これに該当するモジュールを本文から探します。モジュールX1について、「テスト密度は品質判定基準内であり,欠陥数は品質判定基準を超えているが…」と記載されているので、これが該当します。同じ箇所に「開発の難易度を考慮すると品質は良好である」との記載があることから、たとえ品質判定基準を超えていても開発の難易度を考慮すると良好とすべきケースがあると読み取れます。よって、fで考慮すべきは開発の難易度であることがわかります。品質判定基準を機械的に適用するのではなく、開発の難易度と開発要員のスキルレベルに応じて柔軟に適用すると、より効果的に品質評価を行えます。
∴f=モジュールの開発の難易度
広告
広告