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

解答の導き方

1. 下線②では、R社のエンジニアの特長を生かしながら、R社標準の試案を浸透させる方針が示されています。本文によると、エンジニアは「遅れはエンジニアとして恥ずかしいことであり、自らの努力でリカバリする責任がある」と考えています。この責任感を否定するのではなく、遅れへの対応に生かすことがポイントです。
2. 一方で、担当者が遅れを認識していても「予定どおり」と報告するケースがあり、過去には「進捗遅れのリカバリ策に具体的な裏付けが不足していた」ことも問題になっています。そのため、単に担当者の努力に任せるのではなく、遅れを事実として共有し、根拠のある対応につなげる必要があります。
3. T主任の提案では、各自が成果物の出来高実績、担当部分のSPI、今後の見通しを報告することになっています。また、見直し後は、遅れを認識しているチームメンバがリカバリ策を検討して進捗会議に臨みます。ここから、遅れた担当者自身が具体的なリカバリ策を提案し、その進み具合も定量的な進捗データで報告することを促すと分かります。
4. したがって、求められる対応は、担当者自身に、具体的な裏付けのあるリカバリ策を提案してもらうことと、そのリカバリの進捗状況を定量的に報告してもらうことです。「頑張って遅れを取り戻す」といった精神論だけでは、裏付けと進捗状況の把握が不足します。

誤りやすいポイント

• 「担当者が自力でリカバリする」とだけ答えると、具体的な計画や進捗の定量報告が抜けます。
• 「T主任がリカバリ策を決める」とすると、担当者の自負や責任感を生かす方針と合いません。
• 遅れの原因を共有するだけでは不十分です。根拠のあるリカバリ策を提案し、その実施状況も報告するところまで含めます。
• 「定期的に報告する」だけでは、何を報告するのかが曖昧です。リカバリの進捗状況を定量的に報告することが要点です。

FAQ

解答の導き方

1. まず、改善対象となるレビューの問題を確認します。本文では「初回のレビューの実施時期は、レビューイの判断で決定している」とあります。つまり、初回レビューをいつ行うかがあらかじめ定まっていません。
2. 次に、その問題が進捗に与える影響を考えます。初回レビューで成果物の品質のギャップが分かる場合があり、その検出が遅いほど「リカバリは難しくなる」とされています。レビューの時期が担当者の判断任せだと、品質の問題を見つけるのが遅れるおそれがあります。
3. そこで、すぐに行える改善として、初回レビューを成果物作成の早い段階に置き、実施時期を事前に決めておきます。早期にレビューすれば品質のギャップを早く検出でき、あらかじめ時期を定めておけば、レビューの実施が遅れるのを防ぎやすくなります。

誤りやすいポイント

• 「レビューを増やす」とだけ答えると、問題となっている初回レビューの時期が改善されることを示せません。
• レビューで品質を確認すること自体は従来から行われています。問われているのは、初回レビューの実施時期をどう改善するかです。
• 品質上の問題が起きた後の修正方法ではなく、問題を早く発見できるようにレビューの計画を見直すことがポイントです。

FAQ

解答の導き方

1. 問われているのは、T主任に試案を具体化させたこと自体の目的ではなく、チームメンバと議論させることで期待した効果です。
2. 本文では、試案の導入に「少なからず抵抗や反発もある」と予想されています。そのため、S課長が一方的に決めた方法を伝えるだけでは、チームメンバが受け身になり、実際の運用につながらないおそれがあります。
3. 一方で、R社のエンジニアには「自らの努力でリカバリする責任がある」という意識があります。この自負や責任感を生かし、チームメンバ自身が議論に参加して改善策を考えれば、試案を自分たちのものとして受け止めやすくなります。
4. したがって、期待されたのは、チームメンバが自ら改善策を検討することで、実際に取り組もうとする意欲が高まることです。

誤りやすいポイント

• 「試案への理解が深まること」だけにすると、議論に参加することで生まれる効果が不足します。理解だけでなく、実行に向けた意欲の高まりまで述べます。
• 「チームメンバの意見を集めること」を目的とするのではありません。意見を集めること自体より、メンバ自身が改善策を考えることが重要です。
• 試案の管理手法の効果を検証することや、進捗遅れを防ぐことは、この指示によって期待した直接の効果とは異なります。

FAQ

解答の導き方

• レビュアがレビュー済のページ数／計画ページ数
• 担当者がレビュー指摘対応済のページ数／計画ページ数

誤りやすいポイント

• 作成済のページ数だけを数えると、ページの品質確認や指摘対応の状況が進捗に反映されません。
• レビュー済のページ数だけでは、レビューで見つかった指摘への対応が完了したかどうかが分かりません。
• 「計画ページ数」を分母にする点を落とさないようにします。表1では、分母は計画見直しの段階で更新し、完成の段階で実績値に置き換えるとされています。

FAQ

解答の導き方

1. まず、進捗会議で何をするのかを、見直し前後で比べます。T主任の当初の案では、各自が進捗を会議で報告し、その後にT主任がプロジェクト全体の状況や課題を分析する流れでした。
2. 見直し後は、「各自の成果物の出来高実績、担当部分のSPI及び今後の見通しの報告は会議前に実施する」とされています。さらに、T主任も会議前にプロジェクトの状況や課題を分析します。つまり、会議の時間を使って報告や分析を始めるのではなく、分析結果を持ち寄って共有できる状態にしておきます。
3. 会議で行うことは、「その内容を共有する」ことです。また、遅れを認識しているメンバは「リカバリ策を検討して会議に臨む」とあります。したがって、会議では、把握した課題や遅れをチーム全体で共有し、各自が事前に考えた対策を基に、適切なリカバリ策やメンバ間の調整を話し合います。
4. 以上から、この進捗会議は単なる進捗報告の場ではなく、分析結果と課題を共有し、プロジェクトチームとしての対処やリカバリ策を合意する場として活用する、と考えられます。

誤りやすいポイント

• 会議の目的を「各自が進捗を報告する場」とだけ捉えないようにします。報告は会議前に行うことになっています。
• 「T主任が分析する場」とするのも不適切です。分析は会議前に実施し、会議ではその結果を共有します。
• 遅れの発生を共有するだけでなく、チーム全体での対処や関係メンバ間の調整まで行う点を押さえます。

FAQ

解答の導き方

1. まず、下線⑤では、チームメンバ別のSPIとは異なる「切り口」で、プロジェクト全体の遅れにつながる問題の予兆を捉える方法が問われています。
2. 過去の遅れの原因として、チームメンバが「クリティカルパス上の活動を認識していない」ため、問題の検知と対応が遅れ、マイルストーンに間に合わないことが挙げられています。つまり、納期に直結する活動を早めに把握し、重点的に監視する必要があります。
3. 改善方針にも「クリティカルパス上の活動を識別し、重点的に監視する」とあります。したがって、SPIも個人単位ではなく、クリティカルパス上の活動をまとめた単位で確認するのが適切です。
4. プロジェクト全体のSPIだけでは、納期への影響が大きい活動の遅れが、ほかの活動の進捗によって見えにくくなる場合があります。クリティカルパス上の活動群に着目してSPIを算出すれば、プロジェクト全体の遅れにつながる兆候を捉えやすくなります。

誤りやすいポイント

• 各チームメンバが報告するSPIを答えることです。これは本文ですでに提案されているチームメンバ別の切り口であり、下線⑤が求めるものとは異なります。
• プロジェクト全体のSPIを答えることです。下線⑤では、全体の進捗を示すだけでなく、遅れの予兆を捉えるための切り口が必要です。
• クリティカルパス上の活動を「重点的に監視する」だけで答えることです。問われているのは監視対象に加えてSPIの切り口なので、活動群のSPIまで示します。

FAQ