ITパスポート 2017年 春期 問09

業務システム開発の発注で求めるべき提案事項【ITパスポート 解説】

正解の理由

解法ステップ

1. 問題文の主語と目的を確認する
   • 「発注元企業がベンダ企業に対して求めるべき提案事項」→ 発注側（依頼する側）がベンダに求めるものを選ぶ。
2. 各選択肢が「誰の責任で用意すべき情報か」を考える
   • 発注側が用意すべきもの、ベンダが示すべきものを分ける。
3. 「ベンダが示すべき＝実行の方法」を重視するルールを適用する
   • ベンダ提案では「どうやってやるか（実施体制）」が最も判断材料になる。
4. 選択肢を照らし合わせて消去法で決定する
   • 発注側の責任範囲に属するものは除外する。

選択肢別の誤答解説

• ア: 現行システムの問題点
  • 現行システムの問題点は発注元が把握しておくべき情報です。ベンダが調査して提案書に書くことはありますが、発注側の要求としてまず提示するべきものではありません。発注側が自分の業務や問題意識を明確にすることが先です。
• イ: 新システム開発の実施体制
  • ベンダの能力とリスクを評価するために最も必要な情報です。誰がプロジェクトを管理するか、担当者のスキルや人数、品質保証やテスト計画、下請け利用の有無などが含まれます。発注側がベンダに求めるべき提案事項として適切です。
• ウ: 新システムの狙いと要件
  • システムの狙いや要件（要件＝requirements：何を実現すべきか）は原則として発注元が定めるものです。もちろんベンダが要件定義を支援したり改善案を出すことはありますが、発注側が「ベンダに求める提案事項」として最優先で要求する項目ではありません。
• エ: 提案内容の評価基準
  • 評価基準は発注側が決めるものです（例：価格、納期、技術力、保守体制などの重みづけ）。ベンダに「あなたの提案をどう評価するか」を決めさせるのは適切ではありません。発注側が自社基準を示して審査します。

よくある誤解

1. 「ベンダに要件まで全部考えてもらうべきだ」と思う
   • ベンダは要件策定を支援できますが、業務の目的や優先順位は発注側が明確にしておく必要があります。でないと期待と成果がずれます。
2. 「評価基準はベンダが提示してくれるもの」と誤解する
   • ベンダは自社有利に見せる資料を出します。発注側が評価の軸（価格・品質・納期・保守など）を決め、公開するのが望ましいです。
3. 「体制＝人だけ示せば良い」と考える
   • 単なる人数や役職だけでなく、責任範囲、情報共有方法、外部委託の有無、代替人員計画（人が抜けたときの対応）なども重要です。

補足コラム

• RFP（Request For Proposal：提案依頼書）
  • 発注側がベンダに何を求めるかを文書化したもの。要件や評価基準、提出形式、期限などを記載します。
• SLA（Service Level Agreement：サービスの品質や提供条件を定めた合意）
  • 保守・運用フェーズでの応答時間や稼働率などを契約で定めます。
• PM（Project Manager：プロジェクトマネージャ）／SE（System Engineer：システムエンジニア）
  • 体制を評価するときによく出てくる役割名です。

• プロジェクト責任者（PM）の氏名と経歴
• 担当チームの構成（PM、SE、QA、運用担当など）と人数
• 主な外部委託先（サブコン）と範囲
• スケジュールとマイルストーン（主要な納品日）
• 品質管理・テスト計画・レビュー体制
• コミュニケーション方法（報告頻度、ミーティングの形式）
• リスク管理と代替案（メンバー不在時の対応など）

FAQ