平成27年度 プロジェクトマネージャ試験 午後問題
午後II（論文）は、IPAが公式の解答例を公表していません。そこで当サイトでは、公表されている出題趣旨と採点講評を手がかりに、設問ア・イ・ウそれぞれで何を書くべきかを整理した論述の骨子例を独自に作成しました。想定シナリオ付きなので、自分の実務経験に置き換える際の型としてお使いください。午後I（記述）はIPA公式の解答例と、解答を導く着眼点を併記しています。
午後II（論文）
問1 情報システム開発プロジェクトにおけるサプライヤの管理について
設問ア（800字以内）：あなたが携わった情報システム開発プロジェクトの特徴、成果物を請負契約で調達したサプライヤ、及びそのサプライヤに調達を依頼した成果物について述べよ。
設問イ（800字以上1,600字以内）：設問アで述べたサプライヤの管理について、あなたが作成した進捗管理の仕組みと品質管理の仕組み、及びそれらを作成する際に工夫した点を、具体的に述べよ。
設問ウ（600字以上1,200字以内）：設問イで述べた進捗管理の仕組みと品質管理の仕組みについて、その実施状況と評価、及び今後の改善点を、具体的に述べよ。
reveal
出題趣旨：システム開発の成果物を請負で調達する場合、発注者のPMはサプライヤの要員を直接指揮命令できないため、サプライヤの責任者を通じた間接的な進捗管理・品質管理の仕組みが必要となる。この仕組みの立案・運用を通じて、サプライヤを適切に管理するPMの実践力を問う。
採点講評：発注者とサプライヤの間で作成した進捗管理・品質管理の仕組みを具体的に論述できたものが多かった。一方、請負では要員へ直接指揮命令できないにもかかわらず、直接配下のメンバに指揮するような管理の仕組みを論述したものも見られた。設問アでは、以後に論述する内容と関連性のない、又は整合しないプロジェクトの特徴の論述も見られた。
📝 論述の骨子例（参考・IPA非公式）
【想定シナリオ】中堅小売業の基幹システム再構築で、開発工程の一部（サブシステムの設計〜結合テスト）を請負契約でサプライヤX社に発注したプロジェクト。
設問ア：短納期で品質確保が重要な再構築案件という特徴。請負で調達したサプライヤX社と、依頼した成果物（特定サブシステムの設計書・プログラム・結合テスト）を提示。
設問イ：進捗管理はサプライヤの責任者を窓口に、成果物単位のマイルストーンとEVMによる週次報告・合同進捗会議で間接的に管理。品質管理は工程完了時のレビュー・品質評価指標の合意と成果物検査で担保。工夫として、指揮命令ではなく責任者を通じた合意ベースの管理とし、指標の目標範囲と是正手順を契約時に取り決めた点を論述。
設問ウ：仕組みにより進捗遅延と品質問題を早期に検知・是正できたことを評価。改善点として、報告粒度の適正化と、サプライヤ責任者との情報共有をさらに前倒しする仕組みの必要性を論述。
※論文式のためIPA公式の解答例はありません。上記は出題趣旨に沿って作成した骨子の一例で、正解ではありません。必ずご自身の実務経験に置き換えて論述してください。
問2 情報システム開発プロジェクトにおける品質の評価、分析について
設問ア（800字以内）：あなたが携わった情報システム開発プロジェクトの特徴、開発工程において定めた品質の評価指標、及びその目標範囲について述べよ。
設問イ（800字以上1,600字以内）：設問アで述べた品質の評価指標について、目標範囲から逸脱した状況、その原因、及び影響を分析した内容を、具体的に述べよ。
設問ウ（600字以上1,200字以内）：設問イで述べた原因及び影響への対応策、再発を防ぐための改善策、及びそれらの実施状況の監視方法を、具体的に述べよ。
reveal
出題趣旨：開発工程で定めた品質の評価指標が目標範囲から逸脱した状況を捉え、その原因と影響を分析し、対応策・再発防止策を立案してその実施状況を監視するという、定量的な品質管理を実践するPMの能力を問う。
採点講評：品質の評価指標の目標範囲からの逸脱の状況や逸脱の原因の分析を具体的に論述できたものが多かった。一方、逸脱による影響の分析がプロジェクトの目標や特徴との関連で具体性に欠ける論述や、対応策・改善策とその実施状況の監視方法との関係がPMの視点で不適切な論述も見られた。設問アでは、以後の論述と整合しないプロジェクトの特徴の論述も見られた。
📝 論述の骨子例（参考・IPA非公式）
【想定シナリオ】保険会社の契約管理システム開発で、設計工程のレビュー指摘密度とテスト工程のテスト密度・バグ検出率を品質評価指標として管理したプロジェクト。
設問ア：高信頼性が求められる基幹システム開発という特徴。指標としてレビュー指摘密度・テスト密度・バグ検出率と、その目標範囲（上下限）を提示。
設問イ：結合テストでバグ検出率が目標範囲を下回った逸脱状況を提示。原因を特定モジュールの設計レビュー不足と分析。影響として、後工程での欠陥流出リスクと稼働品質・スケジュールへの波及をプロジェクト目標と関連づけて分析。
設問ウ：対応策として当該モジュールの再レビューと追加テストを実施。再発防止策としてレビュー観点の標準化とチェックリスト強化を実施。監視方法として、以後の工程で指標をダッシュボードで週次に追跡し、目標範囲からの逸脱を早期に検知する仕組みを論述。
※論文式のためIPA公式の解答例はありません。上記は出題趣旨に沿って作成した骨子の一例で、正解ではありません。必ずご自身の実務経験に置き換えて論述してください。
午後I（記述）
問1 生産管理システムを導入するプロジェクトのステークホルダマネジメント
製薬企業H社が米国大手X社の傘下に入り、米国基準に適合するX社標準の生産管理システムをH社主導で導入する事例。PMのK氏が、テンプレートに不足するWBS項目の追加、ステークホルダの関与度・影響度分析、望ましい状態へ向けた対策（PMO設置、アドバイザの役割付与など）をどう立案したかを問う。設問文の全文はIPA公式PDFを参照。
reveal
設問1(1) 現システムからの移行作業／(2) X社の監査員による監査
設問2：関与度、影響度がともに高い領域にステークホルダがいない状態
設問3(1) ステークホルダとプロジェクトとの一体感を形成すること／(2) プロジェクトの推進役（関与度・影響度ともに高いステークホルダ）／(3) 事前に正確な理解を得て対策を共有したいから／(4) X社標準システム稼働後の運用業務をT社に担当してもらう必要があること／(5) Y氏とX社の関与度と影響度を望ましい姿に変える（X社の影響力の行使をY氏を通して行う形に変える）
問2 ソフトウェアパッケージ（倉庫管理）の導入
衣料品メーカD社が既存2倉庫を新倉庫に統合し、倉庫管理用ソフトウェアパッケージ（MWS）を初めて導入する事例。PMのE課長が、システム化の方針に沿ったパッケージ選定・支援依頼、利用者トレーニング前倒しやプロトタイプ公開を含むプロジェクト計画の立案、投入可能工数を踏まえた追加開発の再検討をどう進めたかを問う。設問文の全文はIPA公式PDFを参照。
reveal
設問1：D社はソフトウェアパッケージの導入経験がないから
設問2(1) MWS導入による新しい業務プロセスへの理解を深めてもらうこと／(2) 性能の検証（非機能要件の検証）
設問3(1) キーパーソンが、業務プロセスの変更が現場に受け入れられるか不安を抱いているから／(2) MWSの標準機能及び標準プロセスで業務が運用できることを確認すること／(3) 追加開発の要件を把握させ、追加開発チームをスムーズに立ち上げたい（工数を見積もらせたい）から
設問4(1) MWSの標準機能を使って実現できないか検討する（標準機能に合わせて業務プロセスを見直す）／(2) 業務の効率向上が図られていること
問3 システムの再構築（スコープ変更への対応）
金融機関A社の事務サポートシステム更改で、内部設計終盤に業務部C課長から帳票のシステム化追加（スコープ変更）依頼が入る事例。PMのB課長が、他に外部設計の漏れがないかの確認、開発標準への確認項目追加という再発防止、案1・案2の比較と品質面のメリット、並行運用短縮下でのリスク対策をどう検討したかを問う。設問文の全文はIPA公式PDFを参照。
reveal
設問1(1) 最新の現行事務マニュアルと外部設計書との突合せ／(2) 変更予定があるかどうかの確認（未反映の項目がないかどうかの確認）
設問2：追加要員の教育に想定以上の時間が掛かる。
設問3(1) 当初開発分のプログラムバグ・設計ミスへの対応結果の取込み漏れ／(2) 追加開発分の影響を受けない部分の洗い出しを行う。／(3) 上流工程での品質の確保（テストでのバグ発生の抑止）
設問4(1) 操作訓練を円滑に立ち上げられる（内容を事前に理解した上で操作訓練に参加できる）から／(2) 質問や改善要望が多発して並行運用が進まない（現状どおり手作業で処理してしまう）