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

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

問題文および設問

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

問題文

問３　システム開発プロジェクトにおける進捗管理について

　プロジェクトマネージャには、プロジェクトのスケジュールを策定し、これを遵守することが求められる。クリティカルパス上のアクティビティなど、その遅れがプロジェクト全体の進捗に影響を与えるアクティビティを特定し、重点的に管理することが必要となる。
　このようなアクティビティの進捗管理に当たっては、進捗遅れの兆候を早期に把握し、品質を確保した上で、完了日を守るための対策が求められる。例えば、技術的なリスク要因が存在するアクティビティに対してスキルの高い要員を配置したり、完了日までの間にチェックポイントを細かく設定して進捗を確認したりする。また、成果物の完成状況や品質、問題の発生や解決の状況などを定期的に確認することによって、進捗遅れにつながる兆候を把握し、進捗遅れが現実に起きないような予防処置を講じたりする。
　こうした対策にもかかわらず進捗が遅れた場合には、原因と影響を分析した上で遅れを回復するための対策を実施する。例えば、進捗遅れが技術的な問題に起因する場合には、問題を解決し、遅れを回復するために必要な技術者を追加投入する。また、仕様確定の遅れに起因する場合には、利用部門の責任者と作業方法の見直しを検討したり、レビューチームを編成したりする。進捗遅れの影響や対策の有効性についてはできるだけ定量的に分析し、進捗遅れを確実に回復させることができる対策を立てなければならない。

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

設問ア

あなたが携わったシステム開発プロジェクトの特徴と、プロジェクトにおいて重点的に管理したアクティビティとその理由、及び進捗管理の方法を、８００字以内で述べよ。

設問イ

設問アで述べたアクティビティの進捗管理に当たり、進捗遅れの兆候を早期に把握し、品質を確保した上で、アクティビティの完了日を守るための対策について、工夫を含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた対策にもかかわらず進捗が遅れた際の原因と影響の分析、追加で実施した対策と結果について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と進捗管理の概要

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

　私が担当したプロジェクトは、製造業Ａ社のＣＲＭシステム新規開発である。目的は、既存刷新による営業効率化と顧客満足度向上であり、Ａ社の経営戦略に資するものであった。
　本プロジェクトは、「時間的制約（短期リリース）」「人的リソース制約（新技術の経験者不足）」「外部連携の複雑性（レガシーシステムとのＡＰＩ連携）」という特徴があった。

１．２．重点的に管理したアクティビティ

　以下の理由から、「販売管理システムとの連携機能」開発を最重要アクティビティとした。
１）クリティカルパス上にあり、遅延が全体に直結する。このＣＲＭコア機能の遅延は致命的と判断した。
２）外部ＡＰＩ仕様の不確実性や相手調整等の外部依存性が高く、コントロール困難なリスクを内包している。
３）新技術適用箇所で技術的難易度と品質リスク（性能等）が高い。
　これらの複合リスクから最優先での管理が必要と考えた。

１．３．重点管理アクティビティの進捗管理方法
　進捗管理では、可視化、早期課題検知、客観データに基づく迅速な意思決定を重視し、ＥＶＭの概念も活用した。
　具体的には、以下の管理策を実行した。
１）ＷＢＳと成果物ベースの進捗定義
　タスクを細分化し、「設計書レビュー承認」等の明確な完了基準で客観的評価を目指した。
２）高頻度な進捗確認
　週次定例に加え、デイリースタンドアップミーティングで課題・進捗を共有し、問題の早期発見と迅速な対策を促した。これは迅速な対応サイクル確立が狙いであった。
３）課題管理表の活用
　「外部仕様回答待ち」等の課題を登録・追跡し、特に外部連携課題は私が直接フォローし解決を推進した。これは、問題の深刻化を避け、迅速な解決を図るためである。

（７８６文字）

設問イ

２．重点アクティビティの進捗管理

２．１．進捗遅れの早期把握

　連携機能の開発は、プロジェクトの成否を左右する最重要アクティビティであるため、進捗遅れの兆候を早期把握することが特に重要と考え、次の対策を実施した。
　
１）チェックポイント細分化と進捗報告の質向上
　連携機能は外部依存と仕様複雑性から、進捗の実態把握にリスクがあるため、ＷＢＳを２～３日作業単位に細分化した。それぞれの完了をチェックポイントとすることで、問題発生時の影響を極小化し、早期の修正を可能にする狙いがあった。実態に基づいた正確な進捗把握のため、以下の工夫を行った。
・進捗報告は、成果物の完成（例：ＡＰＩ仕様書のレビュー承認済）を基準とし、事実に基づく進捗把握を行った。
・日々の進捗把握のため、サブタスクの未解決件数を、バーンダウンチャートによってチームで共有した。計画からの逸脱した際は即日、原因分析と対策検討を行うこととし、自律的な問題解決を促した。

２）先行指標の監視
　遅延の予兆を把握するため、下記のような将来に影響する活動を、先行指標として監視した。
・外部システム担当者とのＱ＆Ａ発行件数・回答リードタイム等を定量監視した。「質問が３日以上ない」等を検知した場合、仕様理解不足や協力体制が停滞していると判断し、私が介入してボトルネック解消を図った。外部連携のコミュニケーション不備が、致命的遅延を招いた過去の経験を踏まえて重要視した。
・新技術に関する技術課題の未解決件数や、滞留日数を週次チェックした。重要課題が１週間以上未解決の場合、スキルミスマッチや技術的障壁が発生していると捉え、シニア技術者支援や代替技術検討を迅速に開始することとした。限られたシニア技術者の効果的投入に不可欠な対策と判断した。

２．２．品質確保と完了日遵守策

　品質確保の上で完了日を遵守するため、以下の対策を実施した。

１）工程移行判定と体系的レビュープロセスの確立
　各工程の成果物の品質を担保するため、主要成果物に品質基準とレビュー・承認プロセス（工程移行判定）を設定、判定未実施の場合は次工程に進めないルールとした。後工程での大規模品質問題と、手戻りの回避のため必須プロセスと考えた。工程移行判定の実効性を高め、レビューの質を向上させるための工夫として、以下の対応を行った。
・アーキテクトは非機能、業務リーダーは業務整合性など、役割によってレビューの観点を分けた。各役割ごとの専用のチェックリストでレビューを行い、網羅性を高めた。
・外部システム連携の仕様書は、初期のドラフトから相手ベンダー技術担当者と共有し、レビュー参加を依頼した。文書で伝わらない細部や暗黙知を、早期に共有・確認することで認識齟齬を解消し、結合テストでの大規模な手戻りを防いだ。相手リソースに配慮し、重要箇所に絞って協力を仰ぐことにした。

２）戦略的バッファと柔軟なリソース管理
　本アクティビティは、複雑さや新技術採用による不確実性が高く、コンティンジェンシープランとして、以下の「バッファ」と「体制」の確保を行った。
・過去実績やリスク評価に基づき、管理用内部バッファ（総工数の１０～１５％目安）をＰＭ直轄で確保した。消費状況を週次で監視し、５０％消費時点でタスクの優先度見直し等の予防策の検討を開始する、といったトリガー条件を設定した。問題が深刻化する前の、対処時間の確保が目的だった。
・新技術スキル要員不足を考慮し、キーパーソン病欠等の事態に備え、チーム内スキルマップ（保有技術、業務経験等）を事前作成・更新した。これに基づき交代候補をリスト化した。これにより、問題発生時の迅速なリソース再配置と、影響の最小化を目指した。

（１５７９文字）

設問ウ

３．対策実施後の進捗遅延とその対応

３．１．進捗遅延の影響と原因の分析

１）発生事象と影響分析
　連携機能の結合テスト中盤で、特定取引パターンでのデータ不整合が多発し、テストが約３営業日停滞した。この状況は、プロジェクト全体への影響が懸念された。具体的には「最低５営業日の追加工数（１０人日）」「総合テストと最終リリースが５営業日遅延」が見込まれた。短納期のリリースが経営層からの指示であるため、遅延は許容されない状況だった。
２）原因分析
　直接原因は「外部連携仕様におけるチーム間の認識齟齬」と、直ちに特定された。例えば、リトライ処理に関して、当方のチームでは「リトライ処理成功によって、データ整合性が担保される」仕様と認識していたのに対し、実際には、リトライ処理によってもデータ整合性は担保されない仕様だった。このように、エラー発生時のトランザクション管理について、当方のチームと連携先システムの開発チームとの理解が異なっていた。
　この認識齟齬の根本原因は、外部連携における仕様確認プロセスと、合意形成の仕組みの不備と結論付けた。具体的には、短納期という環境下で、複雑な異常系シナリオの網羅的検討や、双方の挙動確認を体系的に行う仕組みが欠如し、正常系疎通が優先された。加えて、公式な合意形成プロセスが一部軽視され、口頭確認に依存した結果、認識のズレが拡大した。

３．２．追加対策と実施結果

　プロジェクトの遅延回復のため、以下の追加対策を実施した。
１）合同仕様検討会による連携仕様の再確定
　認識齟齬の根本的解消と仕様の曖昧さ排除を最優先とし、関係者と緊急仕様検討会を連日開催し、問題の仕様を図やシーケンス図等で可視化した。結果、３日で仕様を再定義し、双方の責任者署名の合意文書で正式確定させ、これ以上の手戻りが出ないようにした。
２）修正作業の集中化とリカバリー計画の実行
　確定した仕様に基づいて修正範囲を特定したところ、幸い特定の処理部分に限定できた。修正と再テストには、当初の担当者に加えシニア技術者１名を応援投入した。３名体制での集中的な対応により、技術的ボトルネックを解消する中で、修正期間の短縮と品質確保を両立させた。並行して、後続テスト計画を、ビジネスインパクトとリスクに基づいて優先順位を見直し、クリティカルな業務シナリオを最優先とした。また、一部影響が小さいテストは、顧客合意の上でリリース後対応とした。最終的に、リリース日を遵守することができた。

３．３．今後の課題
　今回の経験から、外部連携時の仕様合意形成プロセスの標準化と、関係者のコミュニケーションスキル向上が今後の課題だと認識した。これらに取り組み組織的な改善に繋げたい。

（１１５６文字）

まとめ

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

参考図書

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

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