プロジェクトマネージャ 2013年 午後1 問02

解答の導き方

1. 問われているのは、T課長へのヒアリングを受けて、S課長が経営会議メンバへのヒアリングで何を確認しようと考えたかです。後に経営会議メンバから実際に出た要望そのものではなく、ヒアリング前に確認事項として考えた内容を答えます。
2. T課長からは、「業務プロセスの整理が十分に行われていない」ことや、「データ項目間の整合性は必ずしも取れていない」ことが伝えられています。この状況では、既存システムのデータを集めてレポートを作成するだけで、経営会議メンバが必要とする情報を提供できるとは限りません。
3. そのため、システムの機能をデータ集計やレポート作成に限定する前に、最終利用者が何のためにモニタリングシステムを必要としているのかを確認する必要があります。あわせて、システムに何を求めているのかも確認しなければ、必要な機能やスコープを適切に定められません。
4. したがって、確認する内容は、最終利用者にとってのシステム開発の目的と、モニタリングシステムに対する要望です。後のヒアリングで社長から具体的な要望が出ていますが、ここではそれら個別の要望を先取りするのではなく、確認すべき内容の種類を答えます。

誤りやすいポイント

• 「データ項目間の整合性を取ること」だけを答えると、T課長の情報から分かった課題と、経営会議メンバに確認する内容を混同してしまいます。
• 社長が後に述べた具体的な要望だけを挙げるのも不十分です。問われているのは、ヒアリングで明らかになった要望ではなく、S課長が事前に確認したいと考えた内容です。
• 「要求内容」だけで済ませず、利用者がシステムを必要とする目的も確認対象に含めます。目的が分かることで、機能や対象範囲を適切に検討できます。

FAQ

解答の導き方

誤りやすいポイント

• 「業務プロセスを整理すること」だけを答えにしないようにします。業務プロセスの整理は関係しますが、本文で具体的に示された問題は、複数システムにあるデータ項目の整合性が取れていないことです。
• 「レポートを作成すること」や「データを集計すること」は、モニタリングシステムの機能です。設問が問うているのは、その開発前に解決すべき課題です。
• システムを開発すれば、元データの不整合も自動的に解消されると考えないようにします。データの定義や更新状況がそろっていなければ、集計結果の正確性も確保できません。

FAQ

解答の導き方

誤りやすいポイント

• 経営会議メンバを答えてしまう誤りです。経営会議メンバはモニタリングシステムへの要望を示す利用者ですが、各事業部の業務プロセスを具体的に整理する担当者とは限りません。
• システム部や開発担当者を答えてしまう誤りです。システムの技術面を担う人だけでは、各事業部で異なる業務の進め方やデータの扱いを確認できません。
• 「各事業部」だけで止めてしまうと、参加が必要な人が明確になりません。問われているのは組織ではなく、ステークホルダとなる担当者です。

FAQ

解答の導き方

1. まず、モニタリングシステムの実現には、当初想定していたデータ集計やレポート作成だけでなく、「業務プロセスの整理と、既存システムの改修」も必要だと分かります。そのため、既存システムを改修する作業が新たに発生します。
2. 次に、本文には「開発の作業工数が大幅に増加するので、開発要員の追加が必要となる」とあります。一方、各事業部向けの開発・改修業務はR社が継続的に受託しており、「次年度予算の決定を受けて、既に要員計画は固まっている状況」です。つまり、追加の作業にそのまま対応できる要員が確保されているとは限りません。
3. したがって、D部長から各事業部に依頼してもらうのは、まずモニタリングシステムの実現に必要な既存システムの改修を、他の作業より優先してもらうことです。加えて、各事業部のシステム開発計画を見直し、モニタリングシステムに必要な要員を振り向けてもらうことも必要です。単に「要員を追加する」とするのではなく、改修作業の優先順位と、既存計画に割り当てられた要員の再配分まで含めるのがポイントです。

誤りやすいポイント

• 「開発要員を追加してもらう」だけでは不十分です。要員計画が既に固まっているため、各事業部の既存の開発計画を見直して要員を割り当ててもらう必要があります。
• 依頼内容を「各事業部に協力してもらう」とだけ書くと、何に協力するのかが不明確です。改修業務の優先順位を上げることと、モニタリングシステムへの要員配分を具体化します。
• 改修作業の優先順位だけを述べても、増加する作業工数に対応する要員の確保が抜けてしまいます。作業の優先順位と要員配分の両方を押さえます。

FAQ

解答の導き方

1. 開発要員の手配
   「C社内にW社のミドルウェアについて詳しい要員がいない」ため、C社内だけでは新基盤の開発に必要な知識を補いにくい状況です。また、R社の要員計画は既に固まっています。W社から派遣されている要員も、ミドルウェアの仕様確認や検証を行っています。したがって、新基盤に詳しい開発要員を必要な時期に確保できないおそれがあります。
2. システムの品質
   W社のミドルウェアは「最近リリースされたばかり」であり、「利用する予定の機能が正常に動作しない事象」が発生しています。この状態で新基盤を採用すると、ミドルウェアの不具合が残ったままシステムに組み込まれる可能性があります。その結果、正確で整合性のある情報を提供するというシステムの品質目標を達成できなかったり、システム品質が低下したりするリスクがあります。
3. 開発スケジュール
   「新基盤を利用する場合の開発標準」は3か月後の完成を目標に作成中です。一方、プロジェクトでは、業務プロセスの整理などを経て6月から開発を開始する方針です。開発標準の完成を待てば、予定どおりに開発へ着手できないおそれがあります。さらに、ミドルウェアの検証が「なかなか進まない」ため、検証や不具合対応が長引けば、遅くとも年内という完了時期にも影響します。

誤りやすいポイント

• 要員リスクを、単に要員数の不足と考えること
  本文では、W社のミドルウェアに詳しい要員がC社内にいないことや、R社の要員計画が固まっていることが示されています。人数だけでなく、必要な知識をもつ要員を適時に確保できるかがポイントです。
• 品質リスクとスケジュールリスクを同じ内容にすること
  ミドルウェアの不具合は、システムの品質を損なう可能性がある一方、検証や修正が長引けば開発日程も遅らせます。同じ事象が、品質とスケジュールの別々のリスクにつながります。
• 「開発標準が未完成」という事実だけでスケジュールリスクを説明すること
  6月から開発を開始する方針との関係を示し、標準の完成を待つ場合に着手が遅れる可能性まで述べる必要があります。

FAQ

• Q: W社から要員が派遣されているのに、要員手配のリスクがあるのはなぜですか。
  A: 派遣された要員はミドルウェアの検証を行っています。そのことだけでは、開発作業に必要な知識をもつ要員を開発期間中に確保できるとはいえません。
• Q: ミドルウェアの不具合は、品質とスケジュールのどちらのリスクですか。
  A: 両方です。不具合がシステムに残れば品質に影響し、検証や修正に時間が掛かればスケジュールに影響します。
• Q: 開発標準の完成が遅れると、なぜ開発スケジュールに影響しますか。
  A: 標準を確認してから開発する場合、完成が予定していた開発開始時期より遅いと、着手が後ろにずれるためです。