プロジェクトマネージャ試験の午後2問題で論文を書かないけない。論文苦手だよ〜〜
論文問題は苦手意識がある人は多いですよね。でもしっかりと準備をすることで、安心して本番を迎えることができますよ！
プロジェクトマネージャ試験の最大の難関と言われるのが、論述形式で出題される「午後2問題」です。
限られた時間の中で、自身の経験を整理し、論理的に構成し、採点基準を満たす文章へまとめ上げる必要があります。
しかし、多くの受験者は「書き始めるまでが遅い」「途中で話がぶれる」「時間が足りない」といった課題に直面します。
そこで有効なのが、あらかじめ「モジュール（文章パーツ）」を準備し、論文の型を作っておく学習アプローチです。経験事例、課題、対応策、成果と学び――これらを汎用的に整理しておくことで、本試験では内容を当てはめながらスムーズに展開できます。
本記事では、午後2問題を安定して書き切るための“モジュール活用術”を、具体的なステップとともに解説します。
PM試験の午後2問題の内容
論文の書き方・対策のコツ
論文作成に使えるモジュール一覧のサンプル
プロジェクトマネージャ試験の勉強は、ほぼこの論文対策に時間を使います。
午後2問題で安定して高得点を狙うためには、その場の思いつきに頼らない「再現性のある書き方」が不可欠です。
本試験ではテーマの読み取り、構成の組み立て、文章化をすべて120分以内で完結させなければならず、ゼロから構想すると必ず時間不足と構成の乱れが発生します。そこで役立つのが、事前に整理した論文モジュールです。
自分の経験事例を、使い回し可能な文章パーツとして準備しておくことで、試験当日はテーマに合わせて取捨選択・微修正するだけで論理的な骨子が完成します。
結果として、内容の一貫性が高まり、採点者に伝わる論述が短時間で構築できるようになります。
みんなその場で考えて書いてると思っていたけど、しっかりと事前に準備しているんですね！
論文モジュールを効率よく作成するうえで、もっとも活用価値が高いのが「午後1問題」です。
午後1では、システム開発やプロジェクト管理の具体的な事例が提示され、その中から課題、要因、対応策を読み取り整理する力が求められます。
これは午後2の論文構成そのものと親和性が高く、「どのような背景で」「どんな課題が発生し」「どのように解決し」「どのような成果を得たか」というストーリーを学習する格好の素材です。
午後1を解く際に、単に正解を確認するだけでなく、問題文や回答解説を参考にしながら自分の経験に置き換えて書き起こしていくと、そのまま論文モジュールのテンプレートになります。
自分が書きたいプロジェクトに沿ったモジュールを一通り準備しましょう。
午後1問題や自分の経験をもとに作成したサンプルです。
これを参考に、本番で自分が書きやすいようにアレンジして下さい。
プロジェクトメンバーは社内公募によって集めた。プロジェクトの推進に意欲を持ったメンバーを集めるためである。
CDO直下にプロジェクトチームを配置することで、全社からプロジェクトへ参加できる体制とした。
現業と兼務しているメンバーがいたため、本プロジェクトの遂行が最優先であることを明記したうえで、プロジェクト憲章の説明を経営陣からしてもらった。
これは、プロジェクトの承認を全社に伝え、協力体制を確立するためである。
定性的リスク分析を行い、各優先度に対する対策を決めた。
リスクの発生確立（1〜5）と、影響度（1〜5）を掛け合わせ、10以上のリスクに対しては対策案を策定した。10未満のリスクはモニタリング指標を定め、リスク顕在化してから対策を検討することとした。
要件定義に先立ち、システム化の方針説明会を実施した。各部署の責任者を集め、経営陣から必要性を説明してもらった。
パッケージの標準サービスのみを利用するという方針である。要件の膨張を防ぎ、費用を削減する狙いがあったため。
プロトタイプを作成して利用者が具体的なイメージをできる環境を整えた。プロトタイプは簡単な入力や画面遷移が確認できるものとした。
また、過去プロジェクトのチェックリストを活用することで漏れがないかを確認した。
変更管理委員会で変更の承認を行う前に、プロジェクトに参加する書くベンダーによる共同レビューを実施した。
X社の開発に影響がないと考えて実施したY社の設計変更が、実施には影響があったという事象を防止するためである。
システム移行のリハーサルは2回実施した。
1回目は移行作業手順や移行に伴うシステム停止時間の妥当性確認をし、2回目は1回目で見つかった不備の修正の妥当性確認をした。
導入実績のない技術を採用しているため、作業項目の漏れによる移行作業時間超過のおそれがあったためである。
・納期目標を達成するため、週次で進捗会議を行うことにした。
・効率的に進捗管理できるように進捗報告様式を統一し、WBSとガントチャートを併用した形で報告してもらうようにした。
・進捗評価の基準を明確にするため、ドキュメント完了、内部レビュー完了などのマイルストーンごとの進捗率を定めた。
各社の開発箇所の接続機能の開発について、各工程の開始・終了を合わせるようにした。
X社の詳細設計中に修正が発生した場合、Y社が製造工程を終了していると、Y社開発に多くの手戻りが発生するため。
使用するサービスの種類やリソースの量に応じて課金されるクラウドサービスを利用することにした。
顧客のニーズや他社動向の急激な変化に対応するため。また、新規事業の運営は不確実なことが多いため、初期投資を抑える狙いがあった。
最新技術の活用にあたり、多くの仮説と検証を繰り返す必要があるが、多くのコストや時間を割くことはできない。
A社のサービスは、見込み顧客にフルスペックで検証できる環境を無償提供しており、効率よく仮説・検証を進めることができると判断した。
開発規模の見積もりには、ファンクションポイント法と類推見積りを併用した。
システム入出力データやデータベースの項目数などから開発規模を試算し、今回のプロジェクトのようにコスト見積りがしづらかったプロジェクトの生産性を掛け合わせて試算した。
想定外のリスク対応のために、プロジェクト進行中に追加予算の承認を得ようとすると、経営陣との調整により遅延が生じてしまう。
あらかじめマネジメント予備を確保するよう経営陣の了承を得た。
バグ表の書き方と仕様書のバグ計測方法の統一をした。バグの分類方法も統一することで、特定原因のバグが多くなった場合に対応できるようにした。
全体の品質を把握し、サービスイン後の品質目標を確保するため、品質管理の均一化を行なった。
具体的には外部設計から製造工程ではグループ間において、ウォークスルー形式でのレビューを重視した。グループにまたがるコンポーネント間のインターフェースの不整合を防止し、バグレベルの均一化を図ることが目的だった。
メンバーの本音の意見を聞き出すために匿名アンケートでのヒアリングを行った。
様々なステークホルダが関わるため、ステークホルダ俯瞰図を作成して意思決定者の見極めを行なった。
ステークホルダ俯瞰図には、組織名・意思決定者・ステークホルダ間の相関を記載した。
プロジェクトの意思決定を迅速化するためにステアリングコミッティを活用した。
経営者や主要ステークホルダの代表者に参加してもらい、重要事項の審議・決定を行なってもらうようにした。
経営陣の中にはベンダのX社派とY社派が存在しており、それぞれに配慮した指示が出ており、プロジェクトの阻害要因となっていた。
そこで、経営陣からのプロジェクトへの要求や指示は経営会議で決定した上でCIOが指示がする。プロジェクトから経営陣に対してはCIOを通して了承を得る。というように、経営陣からの指示ルートを一本化した。
主要ベンダの責任者が参加する合同会議を週次で開催し、ベンダ責任者のプロジェクトへの関与度を高めるようにした。
説明資料の作成により、現場の稼働がひっ迫するという事象が起きていた。
PM以下にプロジェクトオフィス（＝PO）を設置し、説明資料はPOが作成することとし、説明資料の種類も減らせるように工夫した。ただ、専門知識を要する画面遷移図などの技術資料はPOでの対応は難しいので、WBSにあらかじめ組み込むようにした。
ユーザー部門の担当者が異動し、レビュー遅延の発生と合わせて新任から機能追加の要求が出た。
主張が通ると多くの仕様変更でコスト超過、スケジュール遅延が発生してしまうため、最低限の変更でサービスインし、追加要件はリリース後に対応をする整理とした。
責任者に対してミーティングで運用ルールを説明し、メンバーに対して周知してもらうようにした。
また、研修動画を作成して背景と共に説明し、最後にWebテストで理解を確かめるテストも実施するようにした。メンバーはこれに合格することを義務付けた。
複製されたデータにはIDを付与して管理できるようにした。
開発環境にコピーされてから削除されるまでの操作をIDで追跡可能とした。
・システムテストのみの利用となるため、システムテスト時に受け取り、終了後には確実に消されることを確認する。
・必要項目以外はマスクする。
・担当者以外は使用しない。
・不要なコピーや印刷はしない。
・特定サーバルームのみで利用する。
従来のプロジェクト事例発表会は総括的に行われていたため、再発防止策への検討と共有が不十分と感じていた。
そこで私は、今回の重大課題であった設計工程で発生した指摘や機能変更の多発によるコスト増に焦点を当てた事例紹介を行なった。
直接原因・根本原因・再発防止策まで含めた教訓を共有することで、再発防止を確実とすることが狙いだった。
従来のPM研修はインプット中心だったため、研修強化として、失敗事例を教材としたグループ討議を行い、発表する形式を取り入れることで、より定着ができると考えた。
また、各部門から横断的に事例を集めて実施することで、幅広い事例を定着できるようにした。
午後2問題で安定して結果を出すためには、場当たり的な文章力ではなく、あらかじめ設計された “書き方の仕組み” が重要です。
論文モジュールを準備しておけば、テーマが変わっても骨子づくりに迷わず、限られた時間内で論理的かつ一貫性のある文章へ落とし込めます。
さらに、午後1問題を活用してモジュールを磨き上げることで、実務経験と試験要求との接続が明確になり、採点基準に沿った論述へ自然に寄せられます。
事前準備によって「何を書くか」を体系化しておくことが、午後2攻略の最短ルートです。継続的にモジュールを更新し、自分だけの論文資産として育てていきましょう。
論文に苦手意識があるのは準備ができていないからなんですね。頑張ります。
論文に慣れている人はなかなかいないからね。でもここさえ乗り越えれば合格は目前です！
以上です！
自分の市場価値と目標を確認する方法：
【スキルの棚卸し】転職サイトで市場価値と目標スキル（＝伸ばすべきスキル）を確認しよう
自分の年収をアップさせる方法：
【年収アップを狙う】転職サイトではなく転職エージェントがおススメな理由
AWS資格一覧：
