- 合格レベルの論文がどんなものか、具体的な完成形を知りたい方
- 自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
- 設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
解答例
設問ア
１．プロジェクトの概要と目標未達成の経緯及び影響
１．１．プロジェクトの概要と独自性
私が担当したプロジェクトは、１０年以上稼働するオンプレミス環境の基幹業務システムをクラウド環境へ移行するものであった。私は本プロジェクトのプロジェクトマネージャ（ＰＭ）を担った。本プロジェクトには、組織の標準案件と比べ、三つの顕著な独自性があった。第一に、１０ＴＢ超という未経験規模のデータベースを移行する点。第二に、厳しい時間制約下で一斉移行を完遂させる必要があった点。第三に、長年の改修で仕様書の最新性が失われ、特に夜間バッチの全容把握が困難であった点である。
１．２．未達成となった目標と目標未達成となった経緯
本プロジェクトでは、「計画した週末４８時間内でのシステム切替完了」という最重要目標が未達成に終わった。
移行作業当日、データベースの移行自体は計画通りに完了した。しかし、移行データの整合性検証バッチにおいて、深刻な性能劣化が発生した。テストでは数百万件の抽出データを用いていたため、本番の数十億件というデータ量に起因する性能問題を事前に検知できていなかった。検証完了の見通しが立たず、週明けの業務停止リスクを回避するため、私は経営層と協議の上でシステムの切り戻しを判断し、移行は延期となった。
１．３．目標未達成がステークホルダに与えた影響
目標未達成は各ステークホルダに多大な影響を及ぼした。経営層・事業部門には、移行延期に伴う追加コストと、新機能リリース遅延による事業機会の損失をもたらした。システム利用者である現場担当者には、旧システムでの業務継続を強いることになり、現場の混乱と新システムへの不信感を招いた。そして週末を通して作業したプロジェクトチームは、失敗という結果により士気が大きく低下し、再計画と再実行という多大な追加作業を担うことになった。
（７９２文字）
設問イ
２．目標未達成の原因究明
２．１．目標未達成の直接原因
目標未達成の直接原因は、データ移行後の整合性検証バッチの性能がクラウド環境で想定を大幅に下回ったことであった。技術的には、旧データベースに最適化されたＳＱＬが、データ量に応じて実行計画を動的に変更するクラウドデータベースの特性に合わず、非効率な実行計画を生成した。特に数十億件のデータに対するソートや結合処理でフルスキャンが多発し、処理時間が想定の５０倍以上に増大した。この性能問題は、本番より大幅に少ないデータ量でテストしたため、事前検知できなかった。
２．２．根本原因を究明するために行ったこと
私は、今回の失敗を組織の教訓とするため、三つの行動をとった。背景にあるマネジメントやプロセスの課題究明が重要だと判断したためである。
１）客観性を担保した分析チームの編成
私や各リーダー等の当事者に加え、利害関係のない他部署のベテランＰＭに第三者レビューアとして参加を依頼した。なぜならば、我々の組織の「常識」を疑い、客観的な指摘を得るためには、利害関係がない第三者によるレビューが不可欠と判断したためである。
２）なぜなぜ分析を用いた構造的な課題抽出
「なぜなぜ分析」を用いて、構造的な課題を特定するようにした。分析が個人の過失に帰着しがちなため、私は「個人を責めるのではなく、同様の事態を防ぐ仕組みに目を向けたい」と目的を共有した。その上で、「この見落としを防ぐプロセスはあったか」と問題を深掘りするようにした。
３）情報の伝達経路の重点的な確認
ドキュメントレビューに加え、関係者へ個別にヒアリングした。特に、データベース管理者（ＤＢＡ）への確認を重視した。なぜならば、性能問題を技術的視点で唯一予見できたＤＢＡの指摘が、なぜ計画に反映されなかったのかという点に、本質的な課題があると考えたからである。この情報の伝達プロセスこそが、一つの技術的な問題がマネジメントの問題に発展した主な要因と判断した。
２．３．特定された根本原因
これらの究明活動と分析の結果、相互に関連する以下の三つの根本原因を特定した。
１）「本番相当」のテスト環境に関する定義の欠陥（技術・プロセス）
性能劣化を検知できなかったのは、本番相当のデータ量でのテスト未実施が原因であった。我々はスキーマ構造が同じであれば「本番相当」と定義していたが、データ量で実行計画が変わる以上、データ「量」こそが最も考慮すべき要素であった。この認識が、小規模案件の経験則に依存していた組織のテスト標準プロセスでは、見落とされていた課題であった。
２）リスク評価プロセスの構造的な欠陥（マネジメント）
リスクが見過ごされたのは、既存のリスク評価プロセスに限界があったからである。当組織では、発生確率と影響度を「高・中・低」で評価する定性的なリスクマトリクスを用いていた。性能問題は、切り戻しが可能という理由で影響度「中」と評価されたが、この評価では切り戻しに伴う数千万円規模の追加コスト等の財務インパクトが全く考慮されていなかった。このため、プロジェクトオーナや事業部門長といった意思決定権者はリスクの本当の深刻さを認識できなかった。
３）専門家の知見を反映する仕組みの不在（組織・文化）
リスク評価を誤ったのは、専門家の知見を活かせなかったからであった。進捗や予算を評価するゲートレビューは存在したが、高度な技術的妥当性を評価する専門的な仕組みはなかった。ＤＢＡは計画段階で性能への懸念を表明していたが、その指摘が公式な検討事項にならず、私がリスクとして管理しなかった。当時の私はスケジュール遵守を優先し、顕在化していない性能問題の優先度を低く見積もっていた。この判断の誤りが、専門家の知見を活かせなかった直接的な要因であった。
（１６００文字）
設問ウ
３．再発防止策と組織への定着
３．１．根本原因を基に立案した再発防止策
三つの根本原因に対し、プロジェクトマネジメントの観点から、より適切な意思決定を支援する目的で以下の再発防止策を立案した。
１）性能検証ガイドライン策定
第一の根本原因に対し、「大規模データ移行向け性能検証ガイドライン」を策定した。このガイドラインで「本番データ量の９０％以上を用いた検証」を必須とした。技術的、コスト的に実施が困難な場合は、そのリスクと代替策を明示した上で、ＣＩＯレベルの権限者による公式なリスク受容の承認を得ることを例外プロセスとして定めた。
２）定量的リスク分析の限定的導入
第二の根本原因に対し、「定量的リスク分析手法」を導入した。形骸化を防ぐため、適用範囲をプロジェクトの成否に影響する重要リスクに限定し、ＥＭＶ分析で影響度を金額換算することを義務付けた。例えば、「切り戻し」リスク（影響額１，５００万円、発生確率３０％）を４５０万円と可視化し、客観的な判断を促すことを目的とした。
３）技術的ゲートレビューの制度化
第三の根本原因に対し、既存のマネジメントレビューとは別に「技術的ゲートレビュー」を制度化した。具体的には、要件定義・基本設計・テスト計画の完了時に、プロジェクト外部の専門家がＰＭの計画の技術的妥当性を評価し、承認がなければ次工程に進めない仕組みとした。個人の判断を組織的に補完することが狙いだった。
３．２．再発防止策を組織に定着させるための工夫
再発防止策が形骸化し、管理負荷の増大で終わる事態を避ける必要があった。私は、これらの策を実効性ある文化として定着させるため、工夫として以下の二つを実施した。
１）実行しやすさを重視した展開
複雑な手順書ではなく、既存のプロジェクト計画書テンプレートに「重要リスクのＥＭＶ分析」等の項目を組み込んだ。ＰＭの日常業務に組み込むことで、特別な意識なく再発防止策が実践される状態を作り、形骸化を防ぐ狙いであった。また、技術的ゲートレビューでは、移行判断に関わる項目に絞った「工程移行判断チェックリスト」を配布し、運用負荷を低減させた。
２）有効性の実証による自発的な普及促進
まず、リスクが高いプロジェクト類型から適用するスモールスタート方式を選択した。そして、最も説得力のある事例として、再挑戦となった当プロジェクトでこれらの策を実践し、移行を成功させた。失敗から成功へのプロセスを具体例としてまとめ、全社ＰＭ向けの共有会で発表した。その際、改善効果（手戻り工数ゼロ等）を具体的なデータで示すことで、新プロセスが「やらされ仕事」ではなく、「プロジェクトを守る価値あるベストプラクティス」であるという納得感を醸成し、組織全体への自発的な定着を促し、組織全体のプロジェクト遂行能力の向上に貢献した。
（１１９６文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント