解説

• 【体制について】
  問題文には、「現行の会計パッケージを導入したときは、C社自らは管理責任を負わず，要件定義から本番稼働までを一括してベンダに委ねる体制とし…その結果、本番稼働後の業務効率を低下させ、改善に想定外の費用を要した」と記述されていることから、現行の会計パッケージの本番稼働後に業務効率が低下した原因を整理します。
  
  〔契約形態の検討〕には、現行の会計パッケージを導入したときのスケジュールの進め方について以下のことが記述されています。
  • 要件定義から本番稼働まで固定額の一括請負
  • プロジェクトは、ベンダがスケジュール遵守を最優先に進めた
  • （ベンダが）要件定義の際に、利用部門の経理課の担当者から、C社独自の業務手順を十分聞き取らないまま、次の導入工程に進んでしまった
  この3点から「ベンダに丸投げ」で進めたことがわかります。一括請負が全てダメというわけではありませんが、ユーザ側の心理として「ベンダにすべてお任せ」という意識が強くなり、ユーザ自身のシステム化計画や要件定義におけるステークホルダとの調整を行う責任等が曖昧になる傾向があります。その結果、ユーザの対応不足を補完するために、ベンダがユーザ内のステークホルダ（本問で言えば利用部門である経理課担当者）とのコンタクトを取り始め、さらにユーザの自律的な調整機能が発揮されずに、要件定義上の見落としも生じやすくなります。現行会計パッケージの導入プロジェクトでは正に一括請負の弊害が現れています。
  
  要件定義とは、どのようなシステム、何ができるシステムを作りたいのかを定義することであり、ユーザ自らが情報システムに求める要件（機能要件、非機能要件）を明確に定義する責任があります。また、本番稼働前の受入・運用テストもユーザ側主導で行い、ユーザ側の責任で検収可否を判断することが推奨されます。IPA「超上流から攻めるIT化の原理原則17ヶ条」においても「要件定義は発注者の責任である」と明記されています。
  
  そこでD氏は、C社が真に求めるシステムを得るため、2つの工程についてはC社自らの責任で実施することを決めたと考えられます。設問ではC社の体制について問われているので、「C社の責任で実施する」「両工程をC社が管理する」などの解答が考えられます。模範解答では「C社が管理責任を負う」としています。
  
  ∴体制：C社が管理責任を負う
  
  【契約形態について】
  ユーザ企業がベンダと締結する契約の形態として以下の2つがあります。

  請負契約

  ベンダは仕事（成果物）の完成に責任を負います。

  準委任契約^※

  ベンダは善管注意義務をもって委任された事務を処理する責任を負います。請負契約と異なり、仕事の完成についての責任は負いません。

  前述のとおり、要件定義と受入・運用テストについてはC社の責任で実施し、ベンダにはそれを支援する事務を依頼することになります。成果物の完成ではなく事務を委託するので「準委任契約」が適切です。
  
  経済産業省「情報システム・モデル取引・契約書」では、ユーザ側の業務要件が具体的に確定していないシステム化計画や要件定義のフェーズでは、契約時点で成果物の内容を具体的に特定することは通常不可能ですから、請負には馴染みにくく、準委任契約が適切としています。
  
  ∴契約形態：準委任
  
  ※民法上、委任契約は法律事務を委託する契約と規定されています。準委任契約は法律行為以外を委託する契約で、委任契約の規定が準用されます。
  
  
• 要件定義や受入・運用テストの期間を延長可能にした場合に発生確率が高まると考えられるリスクについて適切な記述を選択します。
  • 誤り。スケジュール延長を可能にした理由として、より優れたシステムを導入しようという考え方であるため、スケジュールを固定にする場合と比較して、稼働後に障害が発生する確率は低くなると考えられます。
  • 正しい。要件定義や受入・運用テストの期間が延長すれば、それに応じてコストも増えるため、スケジュールを固定にする場合と比較して、コストが予算を超過する確率は高くなると考えられます。
  • 正しい。今回のプロジェクトでは、C社が完了を判断するため、固定スケジュールのようにプロジェクトの各項目の完了予定日が明確ではありません。C社が工程の期間を延長すると、プロジェクト全体の遅れに繋がるため、本番稼働開始が計画よりも遅れる確率は高くなると考えられます。
  • 誤り。現行のパッケージソフト導入時に、業務効率が悪くなった原因として「ベンダがC社独自の業務手順を十分聞き取らないまま、次の導入工程に進んでしまった」と記述されています。今回のプロジェクトでは、C社が主体となって行うことで利用部門との連携も取れやすくなるので、スケジュールを固定にする場合と比較して、要件の取込み漏れが発生する確率は低くなると考えられます。
  したがって適切な組合せは「イ，ウ」です。

解説

解説

• 提案の1次評価において、表1のような提案評価表を用いるメリットとして最も適切な記述を選択します。一般的に、提案依頼をする際には、提案の評価基準および要件適合への重み付けを含めた選定手順を確立しておき、ユーザ側の受入れ基準および条件に沿ったベンダ選定を行うことが望まれます。提案評価表を用いた選定には選定者の主観性や意思を排除できるメリットがあります。
  • 過去のプロジェクトにおいて、「PMが自分の意思を優先し，…アドオンの開発費用が予算を大幅に超過した」と記述されていることから、今回のプロジェクトでも、PMの意思を優先して評価を行った場合、同様のトラブルが発生すると考えられます。
  • 正しい。D氏が提案評価表を作成した目的は客観的な評価を行うためです。事前に用意した基準に沿って評価を行うことで、プロジェクトに直接的に関わっていない人に対しても、選定の客観的根拠を明確に示すことができます。
  • 過去のプロジェクトにおいて、「自分が強い関心をもつ一部の機能だけに注目してパッケージを選定した結果、…アドオンの開発費用が予算を大幅に超過した」と記述されていることから、今回のプロジェクトでも、評価する機能を絞った場合、同様のトラブルが発生すると考えられます。
  • 過去のプロジェクトにおいて、「提案を見積金額だけで評価した結果、…多大な手戻りが発生した」と記述されていることから、今回のプロジェクトでも、見積金額を低く抑えることを優先した場合、同様のトラブルが発生すると考えられます。
  提案評価表を用いるメリットを記述しているのは「イ」だけで、それ以外は提案評価表を用いないデメリットについて記述しています。
  
  ∴イ：判定の根拠を経営者など重要なステークホルダに対して明確に示すことができる。
  
  
• 過去のトラブル事例として〔提案の1次評価〕に、「提案を見積金額だけで評価した結果，業務知識が不足したベンダを選んでしまい，受入・運用テストで要件のくい違いが発覚して多大な手戻りが発生した」と記述されています。したがって、見積金額が最も低いという理由だけで納入先ベンダを選定した場合、今回のプロジェクトにおいても同様に「要件のくい違いによる多大な手戻り」が発生するリスクが懸念されます。同じトラブルを繰り返さないため、今回の提案評価表では「ベンダの業務知識」が評価の1つとして取り入れられています。
  
  ∴要件のくい違いによる多大な手戻り

解説

• 〔提案の依頼〕には、納入候補であるベンダ3社に対して、「要件定義から本番稼働までの概算見積を含む提案を依頼した」と記述されています。今回のプロジェクトは、一括請負契約ではなく工程ごとに個別に契約を行う多段階契約なので、不確定要素が多い最初の段階で導入工程部分の詳細な見積もりを得る必要はありません。要件定義の結果次第ではパッケージの導入作業の範囲やボリュームが変わることが予想され、要件定義が終わった段階で改めて導入工程の正式な見積りを依頼すれば良いからです。多段階契約は発注側・受注側双方のリスクを低減します。
  
  ∴要件定義の結果で正式見積もりを行うため
  
  
• 〔最終評価と決定〕には「オプション帳票の価格は50万円で，L社の見積金額に含まれている」とあるので、オプション帳票の価格を除いたL社の見積金額を求めます。
  
  　4,700万円－50万円＝4,650万円
  
  次に、月次の管理帳票について、オプション帳票を採用しないでアドオンで開発する場合の見積金額を求めます。問題文には「アドオンで開発する場合でも総合評価の評点は変わらなかった」と記述されているので、アドオン開発費を加えた場合でも、L社の評点は、表1で次点のM社の提案（総合評価280）を上回っていたことがわかります。全体の見積金額が5,000万円を超えてしまうと、見積金額の評点が0点になりM社と並んでしまう（340－60＝280点）ので、アドオン開発費はL社の全体の見積金額が5,000万円以下に収まる金額でなければなりません。
  
  よって、総合評価の順位が変わらないアドオン開発費の上限は、
  
  　5,000万円－4,650万円＝350万円
  
  ∴350