平成24年度 プロジェクトマネージャ試験 午後問題
午後II(論文)は、IPAが公式の解答例を公表していません。そこで当サイトでは、公表されている出題趣旨と採点講評を手がかりに、設問ア・イ・ウそれぞれで何を書くべきかを整理した論述の骨子例を独自に作成しました。想定シナリオ付きなので、自分の実務経験に置き換える際の型としてお使いください。午後I(記述)はIPA公式の解答例と、解答を導く着眼点を併記しています。
午後II(論文)
問1 システム開発プロジェクトにおける要件定義のマネジメントについて
設問ア(800字以内):携わったシステム開発プロジェクトにおける、プロジェクトとしての特徴、及びシステム化に関する要求の特徴。
設問イ(800字以上1,600字以内):要件を定義する際に、要件の膨張を防ぐために計画した対応策は何か。対応策の実施状況と評価を含めて具体的に。
設問ウ(600字以上1,200字以内):要件を定義する際に、要件の定義漏れや定義誤りなどの不備を防ぐために計画した対応策は何か。実施状況と評価を含めて具体的に。
reveal
出題趣旨:複雑化・多様化した要求を要件として明確に定義するため、要件の膨張を防ぐ対応策(要求の優先順位を決める仕組み、要件確定の承認体制など)と、定義漏れ・定義誤りを防ぐ対応策(チェックリストの整備・活用、プロトタイプの活用など)を計画・実施できるかを問う。
採点講評:要件の膨張を防ぐ対応策や、定義漏れ・定義誤りを防ぐ対応策についての具体的な論述が多かった。一方で、要件が膨張してからの対策や、要件ではなく要求の膨張を防ぐ対応策の論述も見られた。設問アでは、システム化の背景や機能・期待、自分の経歴に終始し、プロジェクトとしての特徴が論述できていないものが目立った。問題文の工夫・対策を単に引用するだけの、具体性・説得力に乏しい論述は評価されない。
📝 論述の骨子例(参考・IPA非公式)
【想定シナリオ】複数部門が利用する販売管理システムの刷新プロジェクト(予算・完了時期が個別システム化計画書で確定)。利用部門の要求が多様で、詳細化の過程で要件が膨張しやすい特徴があった。
設問ア:プロジェクトの特徴=予算限度額と完了時期が承認済みで超過が許されない。要求の特徴=利用部門が多く、業務改善要望が次々と追加され膨張しやすい。
設問イ:要件の膨張を防ぐ対応策=(1)要求に優先順位(Must/Want)を付ける仕組みを構築し、Wantは別枠管理 (2)要件確定の承認体制(部門責任者による確定会議)を設置。工夫=変更は影響度と効果を定量評価してから承認、確定後の追加は次期開発へ振り分けた。実施状況・評価=膨張を予算内に抑制でき、承認プロセスが定着した。
設問ウ:定義漏れ・定義誤りを防ぐ対応策=過去プロジェクトを参考にチェックリストを整備・活用し、画面や帳票はプロトタイプで利用部門と早期に確認。評価=後工程での不備の判明が減り、手戻りを抑制できた。改善点=チェックリストの継続的な更新。
※論文式のためIPA公式の解答例はありません。上記は出題趣旨に沿って作成した骨子の一例で、正解ではありません。必ずご自身の実務経験に置き換えて論述してください。
問2 システム開発プロジェクトにおけるスコープのマネジメントについて
設問ア(800字以内):プロジェクトとしての特徴と、遂行中に発生したプロジェクト目標の達成に影響を及ぼすスコープの変更に至った原因。
設問イ(800字以上1,600字以内):その原因によってスコープを変更した場合、プロジェクト目標の達成にどのような影響が出ると考えたか。どのような検討をして変更の要否を決定したか(協議に関わった関係者と協議内容を含めて)。
設問ウ(600字以上1,200字以内):スコープの変更を円滑に実施するために、どのような点に留意して成果物の範囲と作業の範囲を再定義したか(変更点を含めて)。
reveal
出題趣旨:成果物の範囲と作業の範囲を定義・管理し、予算・納期・品質の目標を達成するため、業務要件やシステム要件の変更に伴うスコープ変更の影響を把握し、関係者と協議して変更の要否を決定し、成果物の不整合や特定担当者への集中を防いで再定義できるかを問う。
採点講評:スコープの変更に至った原因とプロジェクト目標達成への影響、変更の要否の決定、再定義の際の留意点についての具体的な論述が多かった。一方で、変更に至った原因を明確にせず結果だけの論述や、成果物の範囲と作業の範囲の変更点が不明確な論述も見られた。設問アで背景・機能・経歴に終始する論述や、問題文の対策を単に引用するだけの具体性に乏しい論述は評価されない。
📝 論述の骨子例(参考・IPA非公式)
【想定シナリオ】基幹系刷新プロジェクトで、遂行中に連携対象システムの追加というシステム要件の変更が発生し、予算超過と納期遅延のおそれが生じた。
設問ア:特徴=予算・納期・品質の目標が明確な予測型プロジェクト。スコープ変更の原因=事業側の要請で連携対象システムが追加され、成果物・作業の範囲拡大が必要になった。
設問イ:影響=そのまま取り込むと予算超過と納期遅延で品質確保も困難と判断。検討=影響を定量把握し、代替案(対象を段階分割、優先度の低い機能を後送り)を用意。関係者と協議=発注者・利用部門・開発リーダーと協議し、優先度と予算枠を根拠に段階分割で変更を実施することを決定。
設問ウ:留意点=成果物の不整合を防ぐため関連ドキュメントを一括改訂し整合を確認、特定担当者への集中を防ぐため作業を平準化して再配分。変更点=連携機能を第2フェーズの成果物・作業として明確に切り出し、関係者に周知した。
※論文式のためIPA公式の解答例はありません。上記は出題趣旨に沿って作成した骨子の一例で、正解ではありません。必ずご自身の実務経験に置き換えて論述してください。
問3 システム開発プロジェクトにおける利害の調整について
設問ア(800字以内):プロジェクトとしての特徴、利害の調整が必要になった問題とその際の関係者。
設問イ(800字以上1,600字以内):その問題に関する関係者それぞれの利害は何か。どのように利害の調整をして問題を解決したか(工夫したことを含めて)。
設問ウ(600字以上1,200字以内):その利害の調整に対する評価、調整を行った際に認識した課題、今後の改善点。
reveal
出題趣旨:プロジェクト遂行中、関係者間で利害が対立する問題に対し、対立の背景を把握して関係者が何を望み何を避けたいかを十分に理解し、個別相談や複数の解決策の準備などの工夫をしながら、関係者が納得する解決策を見いだして問題を解決できるかを問う。
採点講評:対立した利害を調整しながら問題を解決したことについての具体的な論述が多かった。一方で、利害が不明確あるいは利害が対立していない論述や、利害調整という言葉を使いながら実態は単なる話し合いにすぎない論述も見られた。設問アでプロジェクトの特徴が論述できていないものや、問題文の工夫を単に引用するだけの具体性に乏しい論述は評価されない。
📝 論述の骨子例(参考・IPA非公式)
【想定シナリオ】複数の利用部門が関わる業務システム開発で、共通機能の仕様を巡り部門間の利害が対立し、意思決定が遅延した。
設問ア:特徴=納期が厳しい全社共通システム。問題=共通機能の仕様で利用部門間の利害が対立し意思決定が遅延。関係者=A部門、B部門、情報システム部門。
設問イ:関係者の利害=A部門は現行業務の維持を望み変更を避けたい、B部門は効率化を望み標準化を避けたくない、情報システム部門は保守性を重視。調整と工夫=各部門に個別相談して本音(譲れない点)を把握し、事前に複数の解決策を用意。共通部分は標準化し、差異は限定的なオプションで吸収する折衷案を提示して合意形成。解決=意思決定を前進させ、仕様を確定した。
設問ウ:評価=双方が納得できる着地点を見いだし遅延を最小化できた。認識した課題=利害対立の兆候の把握が遅れた。改善点=早期に関係者マップと期待事項を整理し、対立を予見して先手で調整する運営を計画する。
※論文式のためIPA公式の解答例はありません。上記は出題趣旨に沿って作成した骨子の一例で、正解ではありません。必ずご自身の実務経験に置き換えて論述してください。
午後I(記述)
問1 外部設計の状況確認とステークホルダとの合意形成
システム構築の外部設計を題材に、内部設計以降にスコープの変動が起きないよう、ステークホルダとのコミュニケーションや合意形成の円滑化、外部設計の状況・見通しの把握、変更要望への対応の優先度判断を問う。設問文の全文はIPA公式PDFを参照。
reveal
設問1(1) 他チームが担当する業務との整合性/他チームが担当する業務とのインタフェース/(2) a:外部設計の内容/レビュー結果/(3) b:営業部の責任者/営業部長
設問2(1) 各成果物に同じ基準値を適用しているから/各成果物の難易度に差がないから/(2) c:レビューの効率/作業の効率/(3) 要件定義の内容に不明確な点があることによる指摘/要件定義の内容に矛盾する点があることによる指摘/要件定義の品質の確保が不十分であることによる指摘
設問3(1) 月次処理に関連しない作業を先に行う/問題1の影響を受けない作業を先に行う/(2) スケジュールの見直しに対応した要員の確保の可否/内部設計の期間に追加要員を投入することの可否
設問4(1) 変更要望に対応することによる業務上の効果/スケジュールどおりに変更要望に対応する必要性/変更要望に対応しなかった場合の業務への影響/(2) 変更要望への対応時期を後ろにずらす/稼働開始の時点では前月末時点の情報を画面Fに表示する
問2 プロジェクトの立て直しと実行可能な計画の策定
途中から新任PMが任命されたプロジェクトの立て直しを題材に、全体状況の把握と問題点の洗い出し、真の原因の掘り下げ、関係者との協力を得ながらの実行可能な計画策定を問う。設問文の全文はIPA公式PDFを参照。
reveal
設問1(1) 経営管理レポートを翌月5営業日以内に提出すること/(2) 経営管理レポートのデータ項目の洗い出しとH社社長の承認/(3) システム化の要求内容を確認するたびに範囲が拡大していること
設問2(1) 業務管理レポートの項目が各部門の業務担当者の判断に任されているから/(2) プロジェクト開始から1年後に稼働開始する約束が一部守られないから/(3) H社社長の要求を来年1月までに完了させたいから/(4) 業務管理レポートの要件を収束させる根拠とするから
設問3業務担当者の要求を取りまとめる責任者を決めてもらう
問3 EVMによるプロジェクト管理(WBSと実績集計)
EVM(Earned Value Management)の基本知識と、その前提であるWBSの作り方や実績集計の必要要件を題材に、プロジェクト管理の実務能力を問う。設問文の全文はIPA公式PDFを参照。
reveal
設問1(1) 完了予定日を明確に把握して進められるから/早い段階で進捗の遅れを把握できるから/(2) 利用部門のニーズを早く的確に把握するため/利用部門のプロジェクトへの参加意識を高めるため
設問2(1) コストとスケジュールをWBS(又はWP)単位に設定できるから/実績と予想をWBS(又はWP)単位に比較する必要があるから/(2) a:プロジェクト管理/プロジェクトマネジメント
設問3(1) タスクが完了したかどうかで週次の進捗が把握できるから/(2) 客観的な進捗管理を確実に行うため/(3) 工程別の管理からタスク(又はWBS又はWP)単位の管理に変更する
設問4(1) SPI(遅れ):帳票チーム・DBチーム/CPI(超過):DBチーム/(2) 帳票チーム:総時間が予定範囲を超えないようにする/DBチーム:遅れの影響を調査しリカバリプランを策定する
問4 組込みシステム結合テストのデータ・メトリクス活用
組込みシステム開発の結合テスト計画を題材に、プロジェクトの状態を適切に把握するためのデータ・メトリクスの選定と活用、応援要員投入や障害改修の見通し管理について問う。設問文の全文はIPA公式PDFを参照。
reveal
設問1投入直後は応援メンバの立上げの負荷が掛かるから/応援メンバにプロジェクトの情報を伝える時間が必要になるから
設問2(1) 他チームへの影響が大きな障害/他チームのテストが進まなくなる障害/(2) 見通しの変化を速やかに通知すること/(3) a:遅延チームの進捗の早期回復
設問3(1) 障害の摘出が収束する傾向/(2) b:障害の改修能力/1件当たり障害改修工数/(3) c:改修済障害の改修に要した総工数、d:改修完了予定日に対する遵守率/遅延率/(4) e:改修完了予定日を遵守した改修済の障害数(遵守率の場合)/改修完了予定日に遅延した改修済の障害数(遅延率の場合)/(5) f:4、g:2