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

解答の導き方

1. 問われているのは、N氏が標準スケジュールを提案した時点で、詳細なフィット＆ギャップ分析をしていないために確定できていなかった内容です。
   本文には、これまでに聞いている業務要件から「業務に対するERPの適合率が高く、標準機能で大部分を実現できそう」とあります。ただし、これは現時点での見込みであり、個々の業務要件をERPの機能と照らし合わせて確認した結果ではありません。
2. フィット＆ギャップ分析では、業務要件のうちERPの標準機能で対応できるものと、対応できないものを明らかにします。したがって、分析前には、標準機能で対応できる業務要件がどの範囲なのか、また標準機能と業務要件との間にどのようなギャップがあるのかが、まだ確定していません。
3. この不確定要素がスケジュールに関係する理由は、本文に「ERPの適合率が一定以上であれば追加開発の規模で開発の期間が決まる」とあるからです。標準機能で対応できる範囲やギャップの内容によって追加開発の規模が変わり、開発期間にも影響するため、N氏は要件定義工程の完了後にスケジュールを見直す前提で提案しています。

誤りやすいポイント

• 「ERPの適合率が高い」という見込みだけを答えにしないようにします。問われているのは、その適合率を具体的に判断するための、対応可能な業務要件の範囲とギャップです。
• 追加開発の規模だけを挙げるのも不十分です。追加開発の規模に影響する前段階の不確定要素として、標準機能で対応できる範囲と、標準機能とのギャップの両方を押さえます。
• 経理部の繁忙期や要件定義作業の遅れは、別のリスクや進捗上の問題です。この設問が問う未確定要素とは区別します。

FAQ

解答の導き方

1. まず、要件定義作業を誰が担うのかを確認します。本文では「要件定義作業は、D社の各利用部門が実施する」とあります。したがって、利用部門の担当者が作業に参加できないと、要件定義の進捗に影響します。
2. 次に、要件定義の期間と各部門の状況を照らし合わせます。N氏は要件定義工程を2か月で完了させる計画であり、図1では4月から5月末までが要件定義の期間です。一方、経理部は「3月初～5月末は年度決算の時期」で、多忙になるとされています。
3. この決算時期は要件定義の期間と重なっています。経理部のメンバは通常業務に多くの時間を取られ、要件定義作業に参加できなくなるおそれがあります。その結果、経理部が担当する作業の進捗が遅れる可能性があるため、N氏はその進捗を注視する必要があると考えました。

誤りやすいポイント

• 経理部が「多忙」であることだけでなく、その時期が要件定義の期間と重なる点まで結び付けて考えます。
• 問われているのは、遅延が発生した後の影響ではなく、N氏が事前に注視すべきリスク要因です。
• 他の利用部門には特に繁忙期がないため、すべての部門に共通する問題として捉えないようにします。

FAQ

解答の導き方

誤りやすいポイント

• 「M社がドキュメントを作成すること」と「M社が要件定義書を完成させる責任を負うこと」を混同しないようにします。本文では、M社がドキュメントを作成してD社に提示することは合意されています。
• 責任分担の問題は、D社が決めるべき業務要件を誰が決定するかに関するものです。契約との整合性の問題は、準委任契約で成果物の完成責任を負うことが適切かどうかに関するものです。
• 「M社は要件定義に関与できない」と考えるのは誤りです。M社はヒアリングやドキュメント作成などを支援できますが、要件定義書の完成責任はD社にあります。

FAQ

解答の導き方

1. 問われているのは、N氏が「M社側の要因で」要件定義作業の手戻りが起きないように、指摘事項を監視する際の原因です。したがって、D社側の事情ではなく、M社メンバの作業に起因する指摘に注目します。
2. 作業分担の調整後は、M社メンバがD社の担当者にヒアリングし、その内容を基に業務要件のドキュメントを作成します。D社の担当者がレビューして指摘事項を挙げ、その後、協議結果をM社メンバがドキュメントに反映します。
3. この流れでは、M社メンバが業務内容を十分に把握できていない、または誤って理解したままドキュメントを作ると、D社のレビューで修正を求められ、手戻りが発生します。また、業務に関する知識やスキルが不足している場合も、適切な要件を記述できず、同様に修正が必要になります。
4. したがって、監視対象となる原因は、業務要件への理解不足や理解の誤り、または業務に関するスキル不足です。なお、ERPの標準機能に対する業務部門の抵抗感は、後の販売管理業務で明らかになったD社側の事情であり、この設問が問うM社側の原因とは区別します。

誤りやすいポイント

• 指摘事項の数だけに注目し、どの原因による指摘かを考えないことです。設問は、手戻りにつながる指摘の原因を尋ねています。
• ERPの標準機能と業務要件とのギャップを、そのまま答えにすることです。ギャップへの対応は協議事項ですが、設問の焦点はM社側の要件把握や記述に関する問題です。
• 販売部の担当者が業務プロセスの変更に抵抗したことを答えることです。これはD社側の事情であり、M社側の要因ではありません。

FAQ

解答の導き方

1. 問われているのは、作成したドキュメントの情報から早期に見積もる、開発期間に影響する数値です。まず、本文で開発期間が何によって決まるとされているかを確認します。
2. 本文には、M社のERPの追加開発では「ERPの適合率が一定以上であれば追加開発の規模で開発の期間が決まる」とあります。つまり、開発期間を見積もるには、追加開発の規模が必要です。また、その規模に応じて期間を決める条件を満たすかどうかを判断するため、ERPの適合率も必要になります。
3. では、これらをドキュメントからどう把握するかを考えます。要件定義では、ERPの標準機能で対応できる項目とギャップ項目を整理し、ギャップへの対応策を検討します。さらに、追加開発が必要な業務要件については、「画面、帳票、機能などの追加開発の規模を見積もるために必要な情報」をドキュメントに記載します。これらを集計すれば、追加開発の規模を見積もれます。
4. したがって、ドキュメントから抽出・集計するのは、追加開発の規模とERPの適合率です。ギャップ項目の件数だけでは、業務プロセスの変更で解消するものと追加開発が必要なものを区別できないため、開発期間の見積りには不十分です。

誤りやすいポイント

• 「開発の期間に影響する数値」を、標準スケジュールにある開発期間の「6か月」と取り違えないようにします。問われているのは、要件定義書の情報を集計して見積もる数値です。
• ギャップ項目の件数だけを答えるのは不十分です。ギャップへの対応には業務プロセスの変更などもあり、すべてが追加開発になるとは限りません。
• 追加開発の規模だけでなく、ERPの適合率も必要です。適合率によって、追加開発の規模を基に開発期間を決める条件を満たすかどうかが変わるためです。

FAQ

解答の導き方

1. 図1では、要件定義の後に開発工程が置かれ、標準スケジュールでは要件定義が5月末まで、開発が6月から11月までの6か月間とされています。したがって、要件定義の完了を6月末に変更すると、当初の計画より約1か月遅れることになります。
2. 一方、本文には、標準スケジュールの開発期間について「開発の期間には20％のスケジュールの余裕を含んでいる」とあります。この余裕を後続の工程の調整に使えば、要件定義の遅れを吸収できる可能性があります。
3. さらに、販売部以外の要件定義作業は順調であり、追加開発の規模も中規模開発の範囲を超えないことが条件として挙げられています。このため、開発工程に含まれる余裕を利用して調整すれば、来年4月の運用開始を維持できると考えたのです。

誤りやすいポイント

• 「販売部の担当者の意識を変えること」だけを理由にしないようにします。これは要件定義を進めるための対応であり、スケジュール調整を可能にする余裕そのものではありません。
• 20％の余裕があるのは、全体の1年間ではなく、開発の期間です。
• 追加開発の規模が中規模開発の範囲を超えないことも重要な条件ですが、設問が尋ねているスケジュール調整の理由は、開発期間にあらかじめ確保された余裕です。

FAQ

解答の導き方

誤りやすいポイント

• 「要件定義作業を急ぐこと」だけを指示内容にすると、販売部の抵抗感に対処できていません。作業の遅れの背景にある、標準機能の利用や業務プロセスの変更への考え方に触れる必要があります。
• 追加開発を抑えることだけに注目すると、再構築の目的である業務の効率向上が抜けてしまいます。標準機能の利用と業務効率の向上を関連付けて考えます。
• 「販売部に業務プロセスを変更させる」とだけ述べるのも不十分です。変更を求める理由となる再構築の目的を理解し、ERPの標準機能を活用する方針を社内で共有することがポイントです。

FAQ