- 合格レベルの論文がどんなものか、具体的な完成形を知りたい方
- 自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
- 設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題文および設問は、下記にてご確認ください。
解答例
設問ア
１．プロジェクト概要とコストに関するステークホルダの要求事項
１．１．プロジェクトの目的とコストに関する要求事項
私が担当したプロジェクトは、１５年間稼働した基幹業務システムの全面再構築である。私はプロジェクトマネージャ（ＰＭ）として、保守性の課題解決を責務として担っていた。本プロジェクトでは、経営陣が中期経営計画に不可欠な投資と位置づけ、予算５億円、納期１２ヶ月という厳格な制約条件を設けていた。この予算には、将来的な運用保守費削減への強い期待も含まれていた。
１．２．不確かさの内容、コストへの影響、及び認識共有
１）コスト見積りに影響を与える不確かさ
本プロジェクトのコスト見積りには、性質の異なる二種類の不確かさが存在した。第一は、長年の改修で既存システムの仕様書が現存せず、技術的負債も不明という、多くの関係者が認識済みの「技術的な不確かさ」である。
一方で私は、これとは別に、より検知が困難な第二の「ビジネスプロセスに起因する不確かさ」の存在を強く懸念していた。１５年の運用の中で、公式手順とは異なる非公式な業務ルールが定着し、それに伴うデータの非整合性が蓄積されている可能性を危惧していた。
２）不確かさの影響と認識共有のために実施したこと
ステークホルダ説明会において、私は二つのリスクを段階的に提示した。まず、技術的リスクだけでもコストが予算を超過する可能性が高いという分析結果を、三点見積りを用いて示した。その上で、「この試算は、業務ルールが論理的に一貫しているという前提に立つ。もし業務プロセス自体に根深い問題が発見された場合、コストはこれを更に上回る」と明確に注意喚起した。
この報告の狙いは、安易な楽観論を牽制し、プロジェクトが抱える課題は技術面だけでなく業務面にも存在するという共通認識を、初期段階でステークホルダと形成することにあった。
（７９７文字）
設問イ
２．不確かさに関する計画段階でのステークホルダとの合意事項
２．１．予測活動の内容とステークホルダとの協力内容
１）技術的な不確かさを解消するための予測活動
前述の二種類の不確かさに対し、私は計画段階でまず、具体的に着手可能な「技術的な不確かさ」の解消を優先する方針を立て、ステークホルダと合意した。そのための予測活動として、技術リスクを体系的に評価するため、第一に３か月間をかけた現行システムの詳細調査を、第二にＰｏＣ（概念実証）の実施を定義した。調査では仕様や技術的負債を、ＰｏＣでは性能要件や移行方式のリスクを定量化することが目的であった。重要な点は、これらの活動目的を「ＩＴ側面における見積り精度向上」に主眼を置くと定義し、ビジネスプロセスに内在する課題までを保証するものではない、という前提を確立したことである。
２）予測活動における協力体制
予測活動における協力体制では、各ステークホルダとの役割を明確にした。業務部門には、現行業務フローの説明に加え、データの品質や例外処理の実態に関する情報提供も依頼した。しかし、日常業務に追われる担当者レベルでは具体的な問題として認識されておらず、協力を得ることに困難が伴った。私は、この情報不足が将来的な手戻りの原因となりうる重大なリスクであると月次の報告会で繰り返し指摘し、部門長との交渉の末、月次の定例会で必ず状況を確認することを約束させた。情報システム部門には、技術調査における専門知識の提供と環境準備で協力を取り付けた。経営陣には、月次報告会での迅速な意思決定、特に部門間の調整が難航した場合のトップダウンでの判断を期待すると伝えた。
２．２．再見積りの条件とコスト差異への対応方針
１）コストの再見積りのタイミングを決める条件
見積り精度を段階的に向上させるため、再見積りのタイミングとして五つの条件を設定し、合意を得た。計画的なタイミングとして、①現行システム調査完了時点、②ＰｏＣ結果評価完了時点、③要件定義書承認時点、④基本設計完了時点の四つを設定した。
これに加え、私は前述のビジネスプロセスへの懸念から、⑤「予測活動で想定していなかった重大なビジネス課題が発覚した場合」にも緊急で再見積りを実施するという条件の追加を提案した。当初、経営陣からは「予測活動で全てを明らかにするべきだ」との意見も出たが、私は数年前に同様の課題で頓挫した他部門のプロジェクトの失敗事例を提示した。その上で、初期調査の網羅性には限界があり、未知のリスクを許容しない計画はかえって非現実的であること、そしてリスク顕在化時の迅速な再計画こそがプロジェクトの損失を最小化する、と説得し最終的に承認された。これは、私が最も危惧していた潜在リスクへの対応をプロジェクトの正式な管理手順に組み込む、重要な取り決めであった。
２）再見積りコストと予算との差異への対応方針
差異発生時に備え、４段階の対応方針を定義し合意した。第一に、差異が１０％以内の場合は、私の裁量で優先度の低い機能の延期等で吸収する。第二に、差異が１０％超２０％以内の場合は、段階的リリースにより費用を複数年度に分散させる。第三に、差異が２０％を超える場合は、ステアリングコミッティで、スコープ調整や予算見直し、最悪の場合にはプロジェクトの中止も含む、総合的な経営判断を仰ぐ。第四に、これらの対応とは別に、コンティンジェンシー予算を１０％確保した。ただしこの予算は、主に予測活動で特定が見込まれる技術的リスクを対象とすると明確化した。ビジネスプロセスに起因する課題は、その影響規模が事業そのものに影響を与えるため、経営層が判断すべき重大事項であると定義したためである。この事前合意が、後の円滑な意思決定に繋がった。
（１５７５文字）
設問ウ
３．実行段階における再見積りと差異への対応
３．１．ビジネスリスク顕在化に伴う再見積りの実施
１）再見積りの実施タイミング
データ移行テストのフェーズにおいて、かねてから危惧していたビジネスプロセス上のリスクが顕在化した。新旧システムで計算結果が合わない事象が多発し、原因を詳細に調査した結果、ＩＴシステムの不具合ではなく、長年の運用で現場に定着した非公式な業務ルールと、それに起因するデータの不整合が根本原因であると特定した。これは、もはやＩＴチームだけでは解決不可能な、全社的な業務プロセスの見直しを要する問題であった。この重大な業務課題の発覚を受け、私は計画時に合意した条件に基づき、緊急でコストの再見積りを実施した。
２）再見積りしたコストと予算との差異の内容
再見積りの結果、このビジネス課題を解決するには、非公式ルールを整理し業務プロセスを再定義した上で、大規模なデータクレンジングと追加開発が必要だと判明した。これは実質的なスコープ追加であり、この解決に１．２億円の追加コストが発生した。結果、総コストは６．２億円となり、当初予算５億円に対し２４％の超過となった。私は、このコスト増は当初のＩＴ開発における見積りの失敗ではなく、解決すべき業務上の課題が明らかになったことによるものと分析の上で報告した。
３．２．承認を得た対応策と組織的改善への貢献
１）困難な合意形成を経て承認された差異への対応策
ステアリングコミッティにおいて、経営陣からは当初、「見積りの甘さではないか」と厳しく追及された。しかし、私は初期に注意喚起していたビジネスリスクが顕在化した事実をデータに基づき説明し、本プロジェクトを単なる「システム刷新」から会社の業務そのものを見直す「業務改革プロジェクト」へと再定義することを提案した。これにより、目先のコストではなく、将来の事業競争力強化という、より高い視点での投資対効果を訴えた。このロジックが功を奏し、プロジェクト中止という最悪の事態を回避し、段階的リリースを主軸とする対応策について最終的な承認を得た。
２）仕組みの課題分析と組織への提言
私は、今回の予算超過という結果を、まず自身の課題として真摯に受け止め反省した。その上で、これを個人の問題に留めず、根本原因は技術リスクだけでなく業務プロセスに内在するリスクを初期段階で体系的に評価する「仕組み」が、我々の組織に欠如していたことにあると結論付けた。この学びに基づき、私は再発防止策として、今後の大規模プロジェクトでは計画フェーズの前に、専門チームによる事前の業務プロセス評価を必須プロセスとして導入することを、ＣＩＯに正式に提言した。この提言は承認され、本プロジェクトの教訓は、組織全体のプロジェクトマネジメント標準を一段引き上げるという、大きな成果に繋がった。
（１１９４文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント