プロマネ午後Ⅱ論文の書き方がわからない人へ｜一発で合格した実務経験者のサンプル解答【平成２７年度：問２】

プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　情報システム開発プロジェクトにおける品質の評価、分析について

　プロジェクトマネージャ（ＰＭ）には、開発する情報システムの品質を適切に管理することが求められる。そのために、プロジェクトの目標や特徴を考慮して、開発工程ごとに設計書やプログラムなどの成果物の品質に対する評価指標、評価指標値の目標範囲などを定めて、成果物の品質を評価することが必要になる。
　プロジェクト推進中は、定めた評価指標の実績値によって成果物の品質を評価する。特に、実績値が目標範囲を逸脱しているときは、その原因を分析して特定する必要がある。例えば、設計工程において、ある設計書のレビュー指摘密度が目標範囲を上回っているとき、指摘内容を調べると、要件との不整合に関する指摘事項が多かった。その原因を分析して、要件定義書の記述に難解な点があるという原因を特定した、などである。また、特定した原因による他の成果物への波及の有無などの影響についても分析しておく必要がある。
　ＰＭは、分析して特定した原因や影響への対応策、及び同様の事象の再発を防ぐための改善策を立案する。また、対応策や改善策を実施する上で必要となるスケジュールや開発体制などの見直しを行うとともに、対応策や改善策の実施状況を監視することも重要である。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わった情報システム開発プロジェクトの目標や特徴、評価指標や評価指標値の目標範囲などを定めた工程のうち、実績値が目標範囲を逸脱した工程を挙げて、その工程で評価指標や評価指標値の目標範囲などをどのように定めたかについて、８００字以内で述べよ。

設問イ

設問アで述べた評価指標で、実績値が目標範囲をどのように逸脱し、その原因をどのように分析して、どのような原因を特定したか。また、影響をどのように分析したか。重要と考えた点を中心に、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで特定した原因や影響への対応策、同様の事象の再発を防ぐための改善策、及びそれらの策を実施する上で必要となった見直し内容とそれらの策の実施状況の監視方法について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と目標を逸脱した工程

１．１．プロジェクト概要

　私がＰＭとして参画したプロジェクトは、金融機関のＣＲＭシステム刷新であった。目標はコスト削減、営業支援強化、法規制準拠、及び１年半後の安定稼働であり、複雑なデータ移行、多部門間の調整、短納期、要員のスキル不足という特徴があった。

１．２．品質評価指標を設定した工程と目標を逸脱した工程

　高品質なシステム提供のため、Ｖ字モデルに基づき各開発工程で品質評価指標を設定した。これらの工程のうち、詳細設計に基づき実装されたモジュール間の連携を確認する結合テスト工程において、設定した品質評価指標値の目標範囲からの逸脱が発生した。

１．３．結合テスト工程における品質評価指標、目標範囲とその設定根拠

　結合テスト工程では主要な品質評価指標として「バグ密度」と「重要バグ率」の二つを設定した。

１）バグ密度
　バグ密度はテストケースあたりのバグ数（件／テストケース）と定義し、テスト十分性と潜在バグ数を測る指標とした。目標範囲は結合テスト完了時０．５件／テストケース以下とした。これは、過去の類似プロジェクト実績値を参照し、本プロジェクトの短納期制約を考慮して設定した。後工程への手戻り遅延リスクを最小限に抑えるため、結合テストでの品質作り込みと早期バグ検出が重要と判断し、挑戦的な値を設定した。

２）重要バグ率
　重要バグ率は全検出バグ中の重要・致命的バグの割合（％）と定義し、システム安定稼働リスクを評価する指標とした。目標範囲は結合テスト完了時１０％以下とした。これは、本プロジェクトが顧客情報を扱う基幹システムであることに起因している。法規制準拠と安定稼働が最優先課題のため、重大バグの割合を厳しく管理する必要があると考え、特に厳しい目標値を設定した。

（７９０文字）

設問イ

２．評価指標の実績値の逸脱状況と原因・影響分析

２．１．評価指標の実績値の逸脱状況

１）実績値の逸脱状況
　結合テスト工程開始３週間後の中間レビューで、バグ密度は目標０．５件／テストケース以下に対し０．８件に達した。さらに深刻だったのは重要バグ率で、目標１０％以下に対し２５％と大幅に超過した。これは検出バグの４件に１件が重要・致命的レベルであり、品質目標達成に重大な懸念が生じた。このままでは品質確保は困難で、後続工程への影響は必至と判断した。
２）逸脱の傾向と問題点
　検出したバグを分析した結果、バグ発生には偏りがあり、特にデータ移行処理と新規営業支援機能に関するモジュール群で集中していた。バグ内容では、モジュール間のインターフェース仕様の認識齟齬やエラー処理漏れに起因するものが約４割を占め、これらが重要バグ率を押し上げる主要因となっていた。問題の根源は上流の設計や連携仕様の定義にあると推測した。

２．２．原因分析

　客観的データに基づき原因特定のため、まずパレート図でバグ集中箇所を特定し、これを対象に「なぜなぜ分析」で、表面的な事象の背後にあるプロセスや組織要因等の根本原因を深掘りした。分析はＰＭ、品質担当、開発リーダー、担当者らでチームを組み、関連情報を基に実施した。この分析にあたって特に重要と考えたのは「対症療法に留まらず、プロセスや組織に起因する根本原因まで掘り下げること」だった。なぜなら、根本原因への対策なしには再発防止は不可能だからである。
　分析の結果、特定した直接原因と根本原因として以下を特定した。
直接原因１）対象モジュールの詳細設計書における、インターフェース仕様やエラー処理が曖昧だった。
　⇒根本原因：複雑な業務要件に対する一部設計者の理解が十分でなく、不足による考慮漏れや曖昧さを生んだ。
直接原因２）詳細設計レビューでの設計書の曖昧さやミスの見逃し。
　⇒根本原因：短納期のプレッシャーからレビュー工数が不足し、形式的な確認に留まった。また、レビューアのスキル・理解度ばらつきにより、設計ミスの見逃しがあった。
直接原因３）単体テストでのインターフェース呼び出しや異常系テストケースの、網羅性が低かった。
　⇒根本原因：単体テストの網羅性基準（例：カバレッジ目標）が不明確で、テスト品質が担当者のスキルに依存していた。

２．３．影響分析

　根本原因がプロジェクト全体に及ぼす影響を、スケジュール、コスト、品質、リソース等の観点で評価するため、影響度マトリクス等を用いて発生可能性と影響度を分析した。その際、特に重要と考えたのは「短期的な遅延やコストだけでなく、長期的な品質、信頼性、顧客・要因への影響まで考慮すること」だった。これにより、対策の優先順位付けやステークホルダーへの説明を的確に行うべきと考えたからである。
　分析の結果、以下の重大リスクが認識された。
・スケジュール（発生可能性：高、影響度：大）
　バグ修正、再テスト等の対応に時間を要し、結合テストは最低２～３週間は遅延すると予想。後続工程にも波及し、最終納期達成は極めて困難になる。
・コスト（発生可能性：高、影響度：中）
　手戻り作業で開発工数が計画を大幅に超過し、予算を超過する。
・品質（発生可能性：高、影響度：大）
　類似の潜在バグが、他モジュールに残存する。本番稼働後に顕在化すると、最悪の場合業務が停止し、顧客満足度低下に繋がる。
・人的リソース（発生可能性：中、影響度：中）
　追加作業が要員の負荷増大を招き、要員の疲弊やモチベーション低下に繋がる。

（１５３０文字）

設問ウ

３．是正処置とリスク対策および再発防止策

３．１．是正処置とリスク対策

　本プロジェクトでは、以下の対策を実施した。

１）是正処置
・バグが集中したモジュールの、設計書修正（曖昧箇所の是正）と再レビュー。
・修正した設計書に基づくソースコード修正。
・該当モジュールの単体テストのカバレッジ強化（インターフェース、異常系）と再テスト。
・該当モジュールと関連するインターフェースのデグレード確認を行うよう、結合テスト計画を修正。
２）リスク対応
　分析の結果明らかになったリスク、以下の対応を行った。
・結合テスト期間を２週間延伸し、経験豊富なテスト要員２名を一時的に応援要員として追加し、品質確保を図る。
・手戻り作業と要員追加に伴う工数を試算し、ステークホルダーへ報告。追加予算の承認を得る。
・総合テスト以降のテストケースの中で、リスクが高いと判断した領域のテスト密度を高める。・特定要員への負荷集中を避けるよう、タスクを再配分。週次ミーティングや個別面談で精神的なケアを行う。
・顧客・関連部署へ臨時説明会で状況と対策を報告し、理解・協力を取り付ける。
３）対応策実施のための見直し内容
　上記対応のため、下記の計画を見直した。
・スケジュール
　結合テスト期間を２週間延伸し、後続テスト開始を後ろ倒しした。最終納期への影響を最小化するため、全体スケジュールを再計画した。
・体制・リソース
　テスト要員２名を補充し、品質管理強化のため品質担当者を専任化した。
・コミュニケーション
　日次のショートミーティングで品質状況を確認し、ステークホルダーへの適時報告を可能にした。
４）監視方法
　日次で消化テスト数、新規検出バグ・修正済みバグ数を追跡。週次でバグ密度・重要バグ率の推移をバグ収束曲線で監視し、特に再発バグ件数による、是正処置の有効性を評価した。データの収集や分析は品質担当者が行い、リーダー、ＰＭへ報告。指標逸脱時は即時エスカレーションする体制とした。

３．２．再発防止策

　今後の再発防止策として、以下の対策を実行する。改善策の定着度合いと効果の度合いは、関連指標を用いて継続的に確認し、品質会議等で効果測定と改善要否を判断した。
１）プロセス改善策
・設計レビュー強化（チェックリスト、時間確保、必須レビュアー）。これらの定着度はレビュー指摘内容の変化や設計品質指標で月次確認する。
・単体テストカバレッジ基準定義と完了時レビュー導入。この効果はテストカバレッジ測定結果で月次確認する。
２）組織的・技術的改善策
・担当者向け研修実施。研修後のスキル向上度や設計・レビュー品質への反映度を評価する。
・有識者による早期設計支援体制の強化。支援実績や設計品質への貢献度を評価する。

（１１９４文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。