プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例【平成２２年度：問１】

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

問題文および設問

具体的な問題はIPAにてご確認ください。

問題文

問１　システム開発プロジェクトのリスク対応計画について

　プロジェクトマネージャ（ＰＭ）には、システム開発プロジェクトのリスクを早期に把握し、適切に対応することによってプロジェクト目標を達成することが求められる。プロジェクトの立上げ時にリスク要因が存在し、プロジェクト目標の達成を阻害するようなリスクが想定される場合、リスクを分析し、対策を検討することが必要となる。
　プロジェクトの立上げ時に存在するリスク要因と想定されるリスクとしては、例えば、次のようなものがある。
・採用した新技術が十分に成熟していないことによる品質の低下
・未経験の開発方法論を採用したことによるコストの増加
・利用部門の参加が決まっていないことによるスケジュールの遅延
　ＰＭは想定されるリスクについては定性的リスク分析や定量的リスク分析などを実施し、リスクを現実化させないための予防処置や、万一現実化してもその影響を最小限にとどめるための対策などのリスク対応計画を策定し、リスクを管理することが重要である。

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

設問ア

あなたが携わったシステム開発プロジェクトの特徴とプロジェクト目標について、８００字以内で述べよ。

設問イ

設問アで述べたプロジェクトの立上げ時に存在したリスク要因とプロジェクト目標の達成を阻害するようなリスクは何か。また、リスク分析をどのように行ったか。８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べたリスク分析に基づいて策定した予防処置や現実化したときの対策などのリスク対応計画と、その実施状況及び評価について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と目標

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

　私がＰＭを担当したプロジェクトは、老朽化した現行システムの刷新と、営業プロセスの標準化・効率化及び戦略的営業支援を目指す、次期営業支援システムの構築である。本プロジェクトの期間は約１２ヶ月、予算規模は約１億円であった。
　本プロジェクトには、次のような特徴があった。
１）技術面
　社内実績のない特定の顧客関係管理（ＣＲＭ）パッケージ製品の導入と、当社の独自業務プロセスへの大規模カスタマイズ開発が必要であった。加え、専門知識を持つ社内技術者不足、及び既存の基幹システムとの複雑な双方向データ連携要件も存在した。
２）体制面
　情報システム部門が主体で、複数営業部門と外部システムインテグレーションベンダー複数社が関与し、関係者の調整が複雑であった。
３）業務面
　各部門で個別最適化された既存業務フローを本システム導入を機に標準化する必要があり、一部門からの業務変更への抵抗も予想された。経営資源の制約は、約１２ヶ月というタイトな納期、追加予算確保の困難さ、ＣＲＭ専門知識を有する社内ＳＥ不足という状況があった。

１．２．プロジェクト目標

　本プロジェクトの主要目標は、以下のとおりである。

１）品質
　本稼働後３ヶ月以内にクリティカルな影響を与える障害を０件とすること、及び主要な顧客情報参照画面の平均レスポンスタイムを３秒以内とすること。
２）コスト
　承認予算である１億円の範囲内でプロジェクトを完了させることである。
３）納期
　次年度の営業活動開始に合わせ、３月末までに本システムを本番稼働させること。
４）その他
　営業担当者の日次報告作成に関わる業務時間を平均で２０％削減し、データに基づいた営業戦略立案を推進する。

（７７６文字）

設問イ

２．プロジェクト初期のリスクと分析

２．１．主要なリスク要因

　本プロジェクトの立上げ時に特定した、主要なリスク要因は、技術面では社内実績のないＣＲＭパッケージ導入と大規模カスタマイズ、特に当該パッケージのカスタマイズ経験や特定連携技術の知見を持つＳＥ不足であった。スケジュール面では約１２ヶ月というタイトな納期が各工程を圧迫する可能性があった。業務プロセスの標準化に対する利用部門の抵抗は、合意形成の難航による要件定義の遅延や個別要求によるスコープ肥大化に繋がりうるため、これもリスク要因であった。追加予算確保の困難さも、対応策の選択肢を狭める要因として認識した。

２．２．目標達成を阻害する想定リスク

　上記リスク要因から、目標達成を阻害する重要な想定リスクとして、以下を特定した。

１）最重要リスク
　ＣＲＭパッケージのカスタマイズにおける品質低下と、それに伴うスケジュール遅延及びコスト増加を、最重要リスクとして識別した。これは、技術的要因とスケジュール的要因が複合し、発生確率が非常に高いと考えた。具体的には、カスタマイズ部分の設計ミスや潜在バグの多発、期待した性能が出ないといった品質問題が続出し、その修正と再テストに多大な手戻り工数を要する事態を想定した。この品質低下は手戻りを生み、スケジュールを直接的に圧迫する。遅延を取り戻すための追加リソース投入や、長期化による間接費増加がコスト超過に繋がり、結果として品質・納期・コスト全ての目標達成が困難となる。私は、プロジェクトの成否を左右する最も深刻なリスクと判断した。なぜならば、システムの中核機能開発に直結し、影響範囲がプロジェクト全体に及び、他のリスクを誘発する可能性も高いためである。
２）その他の主要リスク
　上記以外の主要リスクとして、「要件定義の遅延」（遅延が後続工程に伝播し最終的に納期目標未達となる）、「既存システムとのデータ連携不具合」（システム全体のデータ不整合や業務停止、信頼性低下に繋がる）を特定した。

２．３．リスク分析の実施方法

　これらの想定リスクに対し、初期段階でリスク分析を実施した。

１）定性的リスク分析
　まず、プロジェクト主要メンバーとのブレーンストーミングでリスクを網羅的に洗い出した。次に、識別した各リスクに対し、発生確率（過去の類似プロジェクトでの発生頻度等を参考に高・中・低で評価）と影響度（業務影響の深刻度や目標未達時の損失規模を考慮し大・中・小で評価）を評価するリスク評価マトリックスを用いて分析し、対応の優先順位を決定した。その結果、前述のリスク（カスタマイズ品質低下と遅延・コスト増）が「確率：高、影響：大」と評価され、最優先で対応すべき最重要リスクとして特定された。この手法を選択したのは、客観的かつ効率的に優先度を付けるためである。

２）定量的リスク分析
　潜在的影響を具体的に把握し、対策の必要性をステークホルダーに理解させるため、最重要リスクに対して、簡易的な期待金額価値分析を試みた。定量的アプローチを試みた理由は、対策の合意形成をより強力に推進するには、リスクの深刻度を客観的データで示す必要があると考えたからである。具体的には、カスタマイズ部分のコスト増とテスト期間延長を想定した、悲観シナリオ（開発工数２０％増、テスト期間１ヶ月延長）での影響を試算した。この悲観シナリオの発生確率を、社内外の類似プロジェクトデータや、当該パッケージ導入経験を持つ外部専門家の意見を参考に１５％と設定した。この分析により、リスク顕在化による金銭的インパクトと致命的な納期遅延の可能性が数値で示唆され、予防策とコンティンジェンシープラン両方の準備が必要と認識された。

（１５７５文字）

設問ウ

３．リスク対応計画の実施状況と評価

３．１．リスク対応計画の策定

　最重要リスクとその他の主要リスクに対し、予防処置と顕在化時対策を策定した。私の基本方針は、影響度と発生確率に基づき、限られたリソースを効果的に配分し、プロジェクト目標達成を確実にすることだった。
１）最重要リスクへの対応
・予防処置
　懸念点である技術力不足と品質低下に対し、ＣＲＭ導入・カスタマイズ経験豊富な外部専門技術者を要件定義段階から確保し、設計レビュー体制を強化した。これは品質主導権を握り、技術課題を早期に特定・解決する狙いがあった。また、主要機能のプロトタイプ開発と早期ユーザーレビューを実施し、手戻り防止を図った。
・顕在化時対策
　テストフェーズでの問題多発による、深刻な遅延発生に備え、外部の専門テストチームを予め準備しておき、追加投入を可能とする計画とした。
２）その他の主要リスクへの対応
・要件定義の遅延防止策
　業務プロセス標準化への抵抗等に対し、全部門代表者参加の集中的ワークショップを複数回開催し合意形成を促進した。現場の納得感を醸成する狙いがあった。遅延時は経営層へエスカレーションし、トップダウンでの判断を仰ぐことにした。
・データ連携不具合
　インターフェース仕様不備やデータ不整合による、コスト増や遅延を想定し、データ移行作業のバッファを確保する計画とした。

３．２．リスク対応計画の実施状況
　策定した計画は、プロジェクト進行に合わせ順次実行した。
・最重要リスク
　外部専門技術者は設計レビューで的確な指摘を行い品質確保に大きく貢献し、プロトタイプ開発もユーザーからの具体的フィードバックを得て手戻りを削減できた。
・要件定義遅延リスク
　ワークショップは一部門から抵抗があったものの、役員の協力を得て粘り強く開催し、主要な業務プロセスの基本方針について合意形成に至った。
・データ連携不具合リスク
　連携テストで実際に未公開仕様に起因するデータ不整合が発生したが、確保していたバッファ期間内で原因究明と対処ができ、プロジェクト全体への影響は最小限に抑えられた。

３．３．リスク対応計画の評価
　最重要リスクに対する予防処置は、致命的な問題の未然防止に効果的に機能した。ワークショップによる合意形成は、経営陣へのエスカレーションはあったものの、概ねＱＣＤ確保に貢献した。
　一方、データ連携不具合リスクの分析精度がやや甘く、顕在化した際の影響は想定以上だった。
　今後の教訓として、リスク分析では客観的データに加え関係者の経験則や潜在的懸念をより深く引き出し、複数の代替案を含む予防策を準備する。状況変化に応じ定期的にリスク対応計画を見直し、プロジェクト成功をより確実していく。

（１１７９文字）

まとめ

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

参考図書

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

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