情報セキュリティマネジメント 2019年 秋期 午前（科目A） 問49

要求事項の優先順位付け【情報セキュリティマネジメント解説】

正解の理由

• 評価基準が明確になり、公平な比較ができる。
• 「必須」要件を守る提案をまず選べるため、受入れテスト（受け入れ条件）も作りやすい。
• 重要度に基づくスコアリングでコスト対効果を判断できる。

解法ステップ

1. RFPとは何かを確認する（RFP＝提案依頼書。要件と評価方法を示してベンダに提案を求める文書）。
2. 各選択肢がRFP作成側（ユーザ企業）の負担・役割として妥当かを検討する。
3. 「要求の明確化」「実現可能性の確認」「要求と手段の切り分け」という観点で評価する。
4. 要件の優先度をつけることが、比較評価と調整を容易にする点で最も実務的に正しいと判断する。

選択肢別の誤答解説

• ア: RFP作成の手間を省くために要求記述を最小限にするのは誤りです。要求が曖昧だとベンダからの提案がばらつき、見積りや評価が困難になります。結局、追加確認や変更要求が増え、納期・コストの増大や責任所在の不明確化を招きます。
• イ: 実現性確認をベンダ任せにするのは危険です。ユーザ側は業務要件や規程（法令や社内ルール、外部連携要件など）を把握しており、これをベンダに伝える責任があります。実現性（技術的・業務的）や優先度、予算の範囲は発注者側である程度確認しておくべきです。
• ウ: （正答）要求ごとに重要度を設定することで、評価基準が明確になり比較可能になります。重要度は「必須（Must）」「望ましい（Should）」「任意（Nice-to-have）」など段階化すると運用しやすいです。
• エ: 製品名や実現手段を細かく指定すると、ベンダの創意工夫や最適解を阻害します。RFPは「何を実現するか（要件）」を示すのが原則で、「どの製品でどう実現するか」はベンダ提案に任せる部分です。ただし、既存システムとの互換性や特定ベンダ製品の採用が必須の理由がある場合は、その旨を明確にして例外的に指定します。

よくある誤解

• 要求を曖昧にすれば安くできる：曖昧だとベンダはリスクを見積もり保守的になり、逆に高くなるか、後で追加費用が発生します。
• ベンダに全部任せれば手間が減る：ベンダ任せにすると責任範囲が不明確になり、要件ずれ（ミスマッチ）が起きやすいです。ユーザ側は業務要件と優先順位を決める必要があります。
• 製品指定で手間が減る：一見手間が減るが、将来の拡張性・ベンダ依存（ロックイン）問題が発生しやすいので注意が必要です。

補足コラム

• レベル1：必須（Must） — これを満たさない提案は受け付けない。受入基準でテスト必須。
• レベル2：重要（Should） — 高い評価を与える項目。満たさない場合は代替案の提示義務。
• レベル3：望ましい（Nice-to-have） — プラス評価。予算や工期に余裕があれば検討。

• 必須は合否判定に使用（満たさない＝失格）。
• 重要：10点満点で重み1.5、望ましい：重み1.0など。各ベンダの得点を合算して比較。

• 機密性（暗号化の有無）、可用性（SLAで稼働率を指定）、認証・アクセス制御、ログ保存期間、脆弱性対応体制などは要件として明記する。SLA（Service Level Agreement：サービス水準合意）や受入試験の基準も忘れずに記載します。

• 関係部署（業務担当・総務・情報システム・法務）を集めたワークショップで要件を洗い出し、各要件に優先度を付けてからRFP化するのが現実的です。ベンダからの質問期間（Q&A）を設け、回答は公開して公平性を保ちます。

FAQ