プロジェクトマネージャ 2025年 午後1 問03

解答の導き方

1. まず、下線①は、規制緩和への対応に必要な追加予算について、経営会議で承認を得るために業務部門へ指示してもらう事項です。したがって、開発作業そのものではなく、予算の妥当性を説明するために必要な情報を考えます。
2. 本文では、経営層が「必要な追加予算は妥当性を評価して承認する」としています。追加予算を認めてもらうには、規制緩和に対応することでどのような効果が得られるのかを、費用に見合うものとして説明できる必要があります。
3. その根拠は、過去の改修で業務部門が要件変更を求めた際、「業務部門から定量的な効果の提示がなかった」ため、システム部が要件変更を受け入れなかったという経緯です。今回は、顧客価値の創出につながる規制緩和への対応について、効果を具体的な数値で示す必要があります。
4. したがって、D常務から業務部門に指示してもらう事項は、規制緩和に対応した場合の効果を定量的に算出することです。追加予算の額を算出することではなく、対応によって得られる効果を数値で示す点が重要です。

誤りやすいポイント

• 追加予算の見積りや確保そのものを答えにしないようにします。問われているのは、追加予算の承認に向けて業務部門に実施させる事項です。
• 規制強化への対応ではなく、顧客価値の創出につながる規制緩和への対応についての効果を考えます。
• 「顧客の利便性を向上させる」だけでは、効果を定量的に示すことになりません。本文の過去の経緯を踏まえ、効果を数値で算出するところまで答える必要があります。

FAQ

解答の導き方

1. 問われているのは、業務部門のメンバーが顧客価値の創出に向けて果たす役割です。プロジェクトに参加すること自体や、追加予算を確保することではありません。
2. 本文では、規制緩和によって「現在規制されている一部の決済方法」が可能になり、A社の顧客価値の創出につながるとされています。つまり、制度上可能になった決済方法を、顧客にとっての価値へ結び付けることが重要です。
3. さらにD常務は、他社に先行して規制緩和に対応し、「顧客の利便性向上を実現すること」が必要だと述べています。このことから、業務部門のメンバーには、規制緩和への対応を顧客の利便性向上につなげる役割が期待されています。
4. また、本文には、規制緩和への対応には「特に業務部門の協力が不可欠」とあります。技術的に規制緩和へ対応するだけでなく、業務面から顧客価値を実現することが、業務部門のメンバーに求められる役割です。

誤りやすいポイント

• 「プロジェクトに主体的に参加すること」だけでは、顧客価値を生み出すために何をするのかが示せていません。
• 「規制緩和に対応すること」だけでは、対応によって実現する顧客価値まで答えられていません。
• 顧客価値の具体的な内容は、本文にある「顧客の利便性向上」です。システムの品質向上やコスト削減に置き換えないようにしましょう。

FAQ

解答の導き方

1. まず、B氏が業務部門に所属していた頃の経緯に注目します。過去の改修では、要件確定後に顧客の利便性を高める機能が求められましたが、効果が定量的に示されず、システム部はリリース時期への影響を懸念して受け入れませんでした。その結果、「顧客価値の創出が実現できなかった」とあります。
2. この経験から、業務部門は、顧客価値を生み出すシステム開発を行うには、システム部にも顧客価値を考える組織風土が必要だと考えていました。つまり、本プロジェクトでも、システム部が従来重視してきたことだけを目標にするのでは不十分です。
3. 今回の法改正では、規制強化への対応が必達である一方、規制緩和への対応は、本文で「A社の顧客価値の創出につながるもの」とされています。規制緩和に対応するには、システム部だけでなく業務部門の協力も必要です。
4. そこでB氏は、QCD遵守を目標から外すのではなく、それに加えて業務部門が重視する目標もプロジェクトの目標に含めようと提案しました。狙いは、QCDを守ることだけにとどまらず、顧客価値の創出を目指すシステム開発を実現することです。

誤りやすいポイント

• 法改正への対応やリリース時期の厳守だけを狙いとしないようにします。これらはプロジェクトの条件や対応事項であり、下線③の提案の狙いそのものではありません。
• QCD遵守を不要とする提案だと捉えないようにします。本文では、これまでの目標に業務部門が重視する目標を加えることが提案されています。
• D常務をプロジェクトオーナーとし、業務部門が責任をもつことと、下線③の狙いを混同しないようにします。前者は責任体制に関する話であり、下線③はプロジェクトで目指す成果に関する話です。

FAQ

解答の導き方

誤りやすいポイント

• 追加予算の承認を得ることと混同しないようにします。本文では、D常務が追加予算と費用対効果を経営会議で説明し、承認を得た後に計画変更の検討に着手しています。
• D常務にプロジェクトオーナーになってもらうことだけを狙いと考えないようにします。設問が問うているのは、その役割と合わせて業務部門が責任をもつ体制をC部長に説明する狙いです。
• 業務部門がシステム部のQCD遵守の責任を引き受ける、という意味ではありません。本文では、業務部門が責任部署となり、その下でシステム部がQCDを遵守する責任分担とされています。

FAQ

解答の導き方

誤りやすいポイント

• スコープTの開発が遅れることを、直接のリスクとして答えてしまうことがあります。設問は、スコープSの一部を先行して進めることに起因するリスクを尋ねています。
• 「影響を受けないと考えられる」を「影響を受けないことが確定している」と読み違えないようにします。見込みに基づく判断なので、後から影響が判明する可能性があります。
• 手戻りによるスケジュール遅延ではなく、まずは開発済みの作業をやり直すことがリスクだと捉えます。

FAQ

解答の導き方

1. 下線⑥では、スケジュール短縮のためにプロジェクトメンバーを追加することから生じるリスクを問われています。追加する目的は、クリティカルパス上のタスクに人員を投入し、作業を早めることです。
2. ただし、メンバーを増やせば必ず作業が効率化するとは限りません。追加されたメンバーが取引管理システムや担当作業について十分な知識をもっていない場合、作業内容の理解不足や誤りが生じ、成果物の品質が低下するおそれがあります。
3. したがって、特定すべきリスクは、追加メンバーの知識不足によって品質が不足することです。

誤りやすいポイント

• 「メンバーを追加すると、説明や調整に時間がかかる」という点だけを答えると、追加要員に起因するリスクの一つではありますが、模範解答が示す品質面のリスクを捉えられていません。
• 「作業期間が延びる」と答えるのも不適切です。設問はメンバー追加によるスケジュール短縮策そのものではなく、その策に伴って生じるリスクを尋ねています。
• 「品質不足」だけでは原因が不足します。追加メンバーの知識不足が原因であることまで示す必要があります。

FAQ

解答の導き方

1. 問われているのは、スケジュールの遅延に備えるバッファを、個々のタスクとプロジェクト全体のどちらに持たせるかです。
2. C部長は、担当者が「作業期間にバッファを多く見込みがち」なので、バッファを注意して管理するよう助言しています。つまり、各担当者がタスクごとに余裕を加えると、バッファがタスクの中に隠れ、プロジェクト全体としてどれだけ余裕があるのか把握しにくくなります。
3. そこで、各タスクの作業期間には個別のバッファを含めず、遅延に備える余裕をプロジェクト全体のバッファとしてまとめます。プロジェクトバッファをまとめて管理すれば、その消費状況を確認しながら、リリース時期を守るための判断がしやすくなります。

誤りやすいポイント

• タスクごとに余裕期間を残したまま、さらにプロジェクトバッファを加えることです。バッファを二重に見込むことになり、スケジュールが長くなります。
• 「各タスクにバッファをもたせない」を「遅延に備える余裕を全く設けない」と解釈することです。余裕はプロジェクト全体のバッファとして確保します。
• バッファをどこに設けるかではなく、追加メンバーの投入やタスクの短縮方法を答えることです。この設問は、バッファの設定方法を問うています。

FAQ

解答の導き方

1. まず、法改正への対応を、期限が必須のものと導入時期を選べるものに分けます。本文では、規制強化は「全ての取引事業者は来年4月初めから遵守しなければならない」とされています。一方、規制緩和は「取引事業者の判断で来年4月初め以降の任意の時期に導入できる」とされています。
2. 開発スコープも分けられています。スコープSはハードウェアの更改対応の改修と規制強化への対応であり、スコープTは規制緩和への対応です。したがって、スコープTの開発が遅れても、期限を守らなければならないスコープSの対応まで遅らせるのは適切ではありません。
3. B氏は、スケジュール短縮策やスケジュールバッファを設定しても、スコープTの開発が予定どおりに進まない場合に備えています。その場合も規制強化への対応を期限内に実施できるよう、導入時期を選べる規制緩和への対応だけを後に回す計画が適切です。
4. そのため、コンティンジェンシー計画では、規制緩和への対応のリリース時期を延期します。これは規制緩和への対応を取りやめるのではなく、開発が遅れた場合に限ってリリースを後ろ倒しにし、必須の対応を優先する考え方です。

誤りやすいポイント

• 規制強化と規制緩和を同じ期限の対応として扱わないようにします。規制強化には期限がありますが、規制緩和は導入時期を選べます。
• プロジェクト全体のリリースを延期すると考えないようにします。延期する対象はスコープT、つまり規制緩和への対応です。
• 規制緩和への対応を中止する計画としないようにします。問われているのは、開発が予定どおりに進まない場合のリリース時期の調整です。

FAQ

• Q: スコープTの開発が遅れたら、プロジェクト全体のリリースも延期しますか？
  A: いいえ。規制強化への対応には期限があるため、スコープSの対応を優先し、規制緩和への対応のリリース時期を後にします。
• Q: 規制緩和への対応は、遅れても問題ないのですか？
  A: 導入時期を任意に決められるため、規制強化への対応を遅らせるよりも、規制緩和への対応のリリースを延期する計画が適切です。
• Q: リリース時期を延期するのは、リスク対応策ではなくコンティンジェンシー計画なのですか？
  A: 予定した対策を実施してもスコープTの開発が遅れた場合に備えて、あらかじめ実行する対応を決めているため、コンティンジェンシー計画に当たります。