応用情報技術者 2012年 春期 午後 問04

解答の論理構成

1. RFPを作成する理由
   • 問題文には「今回、P社として初めてRFPを作成し、複数の会社から提案を受けた上で、新受発注システムの発注先を決定することにした。」とあります。
   • “複数の会社”から同条件で提案を募ることで、客観的な比較評価が可能になり、価格や品質に関する恣意的な判断を排除できます。これは解答群「ウ：発注先の決定における恣意的な要素が排除されるので、適正な価格でシステムを導入できる。」に合致します。
2. RFPがもたらす合意事項の明確化
   • R課長は「過去にユーザ受入テスト時点で仕様変更を要請されたことがあったが、いずれも要件定義における認識の相違が原因であった。」と問題点を認識しています。
   • RFPでは業務要求・品質要求・性能要求などを文書化して提示するため、発注側と受注側の認識をそろえられ、後工程での手戻りを低減できます。これは解答群「イ：P社の要求に対する合意事項や受注会社側の責任が明確になるため、認識の相違による開発手戻りリスクが減る。」に対応します。
3. 他の選択肢が不適切な理由
   • 「ア：P社と取引実績のない会社を、あらかじめ提案依頼先候補から除外できる。」
     → RFPは広く公募し比較することが目的であり、取引実績の有無による排除は趣旨と逆です。
   • 「エ：複数会社に対し、異なる条件で提案を依頼できる。」
     → 異なる条件で依頼すると公平比較ができず、RFPのメリットが失われます。
4. よって、正答は「イ、ウ」となります。

誤りやすいポイント

• 取引実績の有無で排除できると誤解する。RFPはむしろ“門戸を広げる”文書である。
• 複数ベンダーに異なる条件で依頼しても問題ないと思い込むが、比較評価を困難にする。
• 過去のトラブルの原因（「要件定義における認識の相違」）とRFP作成の関係を見逃し、選択肢「イ」を外してしまう。

FAQ

解答の論理構成

1. 現状のメンバ構成
   – 「RFP作成チームのメンバとして7名が全て情報システム部から選出された。」
   情報システム部だけでは業務側の視点が欠けています。
2. 過去のトラブル要因
   – 「過去にユーザ受入テスト時点で仕様変更を要請されたことがあったが、いずれも要件定義における認識の相違が原因であった。」
   業務部門を巻き込まないと要件の食い違いが再発します。
3. R課長の問題意識
   – 「システムの利用部門から具体的な業務要求を提示してもらう必要がある。」
   利用部門を初期段階から参画させることで、業務要求の漏れや誤解を防ぎ、RFPの実効性が高まります。
4. したがって、改善点は「利用部門からもメンバを選出する」という解答になります。

誤りやすいポイント

• 「外部コンサルティング会社」に着目し、外部メンバ追加と答えてしまう。コンサルは既に参加しているため的外れです。
• 「情報システム部内で人数を増やす」と考える。問題は人数ではなく部門の偏りです。
• 「利用部門にヒアリングを行う」と答える。ヒアリングは手段に過ぎず、求められているのはメンバ構成の改善です。

FAQ

解答の論理構成

1. 問題の主旨
   設問は「提案依頼先に業務要求を正しく伝えるために考慮すべきこと」を尋ねています。言い換えれば、ベンダに誤解なく意図を伝え、品質・コスト・スケジュール面でのリスクを下げるために有効な情報提供方法を選ぶ問題です。
2. 選択肢の検討

• ア：業務要求の実現要望度合いに関して、優先順位を付ける。
  【問題文】には「優先度の高い目標は次のとおりである。」や、「優先度の高いP社独自の機能を実現するために、カスタマイズを行うこと。」と明記されています。優先度を示せば、ベンダは必須要件と附随要件を区別しやすく、工数見積りや工程計画の精度が上がります。
• エ：現行の業務プロセス一覧、システム機能一覧を添付する。
  【問題文】には「過去にユーザ受入テスト時点で仕様変更を要請されたことがあったが、いずれも要件定義における認識の相違が原因であった。」とあります。現行の業務プロセス・機能を文書で共有すれば、現行機能の引継ぎ範囲や改修対象が明確になり、認識齟齬を防止できます。

1. 他の選択肢を除外する理由

• イ：現行業務の保証が必須の機能は、現行のプログラムソースを添付する。
  ソースコードを添付してもビジネス要求の伝達には直結せず、逆にセキュリティやライセンスの問題が生じる可能性があります。
• ウ：現行業務の保証の範囲は、提案依頼先の考えを基づいて提案してもらう。
  範囲をベンダ任せにすると認識差が拡大し、問題文で指摘された過去の失敗を繰り返す恐れがあります。
• オ：網羅性よりも詳細を優先して業務要求を記載する。
  詳細を追うあまり網羅性が欠けると、抜け漏れが発生します。RFPではまず網羅性を確保し、重要部分の詳細化を図るのが基本です。

1. 結論
   以上より、最終解答は 「ア、エ」 となります。

誤りやすいポイント

• ソースコード添付＝情報量が多いほど良いと早合点しやすい。業務要求の共有とプログラム資産の提供は目的が異なります。
• 「詳細重視」が常に正解と思い込み、網羅性を軽視してしまう。全体像を示さないとベンダはスコープを正しく把握できません。
• 現行機能の保証範囲をベンダ提案に委ねると、「保証」ではなく「再設計」扱いになりコスト増・期間延長を招く点を見落としがちです。

FAQ

解答の論理構成

1. 【問題文】には、RFPのシステム要求として
   「ASP又はソフトウェアパッケージの活用を提案する場合、優先度の高いP社独自の機能を実現するために、カスタマイズを行うこと。」
   と記載されています。
2. カスタマイズの要否を判断するには、
   ①「業務要求」や「現行システム機能」
   ②「候補となるパッケージやASPが提供する標準機能」
   を突き合わせ、両者の一致点（Fit）と不足・差異（Gap）を整理する作業が必要です。
3. この作業は一般に「フィット＆ギャップ分析（フィットギャップ分析）」と呼ばれます。
4. 設問は「業務要求や現行システム機能との差異を調査・分析・評価するための作業の名称を答えよ。」と問うているので、解答は
   フィット&ギャップ分析又はフィットギャップ分析
   となります。

誤りやすいポイント

• “差異分析”や“ギャップ分析”とだけ答えると、Fit（適合部分）の評価が抜けてしまうため減点対象となりがちです。
• “ベンチマークテスト”や“POC”など性能検証系の手法と混同するケースがありますが、本設問は機能面の適合度評価を尋ねています。
• 「カスタマイズを行うこと」という文言に注目できず、現行機能の棚卸しや要件定義そのものを答えてしまうミスが多発します。

FAQ

解答の論理構成

1. 【問題文】には「表1のうちサーバ内処理時間については、目標時間を達成すること」と明示されています。
2. 一方、同じ表1では「画面レスポンス時間 1)（努力目標）」とされており、必達ではありません。
3. 画面レスポンス時間は、顧客が使用する PC／携帯電話／スマートフォンや「インターネット」経由での通信経路に大きく左右されます。これらは P社やベンダが直接制御できない要因です。
4. したがって、P社が自社で保証できるのは「Webサーバ、業務サーバ、データベースサーバ」の処理時間のみであり、ネットワークや利用者端末を含む総合応答時間は努力目標とするのが合理的です。

誤りやすいポイント

• 「10,000時間以上」「1時間以内」など可用性指標と混同して理由を説明してしまう。
• 表1で「ピーク時」だけを根拠にし、平常時・外部要因を見落とす。
• 「サーバ内処理時間は画面レスポンス時間に含まれる」文を読み違え、両者を独立指標と誤解する。

FAQ

解答の論理構成

1. 【問題文】のキャパシティ要求には
   “・システムライフサイクルは、本番稼働後5年を想定する。”
   とあり、設計対象期間が「5年」であることが明示されています。
2. 同じ箇所には現状値として
   “取扱商品数：約50,000点” などの “現行システムにおける、現時点の取扱いデータ件数”
   しか記載されていません。
3. しかし目的・目標では
   “・5年後の法人顧客数を現時点の4倍、受注総件数を現時点の3倍と設定し”
   と、5年後を見据えた成長率が提示されています。
4. したがって、5年間で増加するデータ量を見込んだ設計が不可欠です。現状値だけでは不足しており、追記すべきは「将来（5年後）の取扱いデータ件数」です。
5. 以上より解答は【模範解答】のとおり「5年後の取扱いデータ件数」となります。

誤りやすいポイント

• 現在のデータ件数を列挙するだけで十分と考え、将来予測を忘れる。
• 増加率（4倍・3倍）そのものを解答に書いてしまい、件数という形で示さない。
• 「顧客数」や「受注総件数」を追記すべきと誤解し、「取扱いデータ件数」という設問の焦点を外す。
• キャパシティ要求を性能要求と混同し、レスポンス時間やバッチ時間を答えてしまう。

FAQ

解答の論理構成

1. 問題文は、セキュリティ要求の一つとして
   「・①なりすまし・データ改ざん・情報漏えいなどが発生するリスクの低減」
   を提案依頼事項に盛り込んでいます。
2. 「なりすまし」は、攻撃者が正規利用者を装ってシステムにログインし、不正操作を行う行為です。
3. したがって直接的対策とは、
   (1) 正規利用者を識別・認証し、本人以外のアクセスを遮断する仕組み
   (2) 認証後にセッションを乗っ取られないようにする仕組み
   (3) 認証を回避する攻撃（SQLインジェクションなど）を封じる仕組み
   など、本人確認と不正認証阻止に直結するものです。
4. 解答群を検討すると次のとおりです。

1. よって直接的に「なりすまし」を防ぐのは「イ」と「オ」です。

誤りやすいポイント

• 「暗号化＝万能」と早合点し「エ」を選ぶミス。暗号化は通信や保存データの保護であって、ログイン自体の成り立ちには直接関与しません。
• マルウェア対策としての「ウ」を選ぶミス。ウイルス感染は多岐にわたるリスクを低減しますが、本人認証の堅牢化には直結しません。
• 「USBメモリ禁止」は情報持ち出し対策であり、攻撃者がログインする経路を塞ぐわけではない点を見落としがちです。

FAQ