情報システムの調達・評価（RFP・SLA・ROI・TCO） | 中小企業診断士1次試験経営情報システム

「ITシステムを導入したいけど、どこに何を頼めばいいかわからない」——そんな悩みを抱える中小企業は多いです。RFP・SLA・ROI・TCO、これらを体系的に理解すると、調達の全体像が一気に見えてきます。

IT調達プロセスの全体像：7つのステップ

情報システムの調達は、単に「ベンダーを選んで発注する」だけではありません。要件定義から始まり、情報収集・提案依頼・提案評価・契約・開発・検収という7段階のプロセスを経て、はじめてシステムが稼働します。このプロセスを正確に理解することが、試験においても実務においても不可欠です。

IT調達プロセス 7ステップ

①要件定義

②RFI発行

③RFP発行

④提案評価

⑤契約

⑥開発

⑦検収

ステップ	内容	主なアウトプット
①要件定義	業務課題・必要機能・制約条件を明確化する	要件定義書、業務フロー図
②RFI（情報提供依頼書）発行	市場調査。ベンダーの技術・製品情報を収集する	RFI回答書、市場調査レポート
③RFP（提案依頼書）発行	選定候補ベンダーへ具体的な提案を依頼する	RFP文書、提案書募集要項
④提案評価	提案内容を加点法・採点表で比較評価する	評価表、選定報告書
⑤契約	開発委託契約・保守契約を締結する	契約書、SLA文書
⑥開発・構築	システムを設計・開発・テスト・移行する	設計書、テスト報告書
⑦検収	要件を満たすか確認し、システムを受け入れる	検収報告書、受入テスト結果

試験のポイント：RFIとRFPの違いは頻出です。RFIは「情報収集が目的」、RFPは「特定の提案を求めることが目的」。RFIで市場調査をしてからRFPを発行する、という順序を覚えましょう。

IT調達は7つのステップで構成され、RFIで市場を調査してからRFPで提案を求めるという順序が重要です。

RFI（情報提供依頼書）とRFP（提案依頼書）の違い

RFIとRFPは名前が似ているため混同しやすいですが、目的・タイミング・対象が異なります。試験では「どちらが先か」「何を求めているか」という形で問われることが多いです。

項目	RFI（情報提供依頼書）	RFP（提案依頼書）
正式名称	Request for Information	Request for Proposal
目的	市場調査・ベンダー情報の収集	具体的な提案・見積もりの取得
タイミング	調達プロセスの初期段階	ベンダー候補を絞り込んだ後
対象	幅広いベンダー（情報収集目的）	選定候補の少数ベンダー
求める内容	製品・サービスの概要・技術情報	具体的な機能・価格・スケジュール
拘束力	なし（情報提供のみ）	提案段階（契約前）

RFPに記載すべき主な内容

調達目的・背景：なぜこのシステムを導入するのか
機能要件：必要な機能の詳細仕様（必須・推奨の区別）
非機能要件：性能・信頼性・セキュリティ・拡張性
スケジュール：提案書提出期限・評価期間・稼働開始目標
評価基準：どのような観点で提案を評価するか
予算の目安：概算予算範囲（開示する場合）
契約条件：保守・サポートの範囲・SLAの要件

実務的な視点：RFPに評価基準を明示することで、提案を客観的に比較できます。「技術力30点・価格30点・サポート20点・実績20点」のように点数配分を公開することが一般的です。

RFIは情報収集のため幅広く発行し、RFPはベンダー候補に絞った上で具体的な提案を求めるもの。この2段階の流れを整理しておきましょう。

ベンダー評価手法：加点法・採点表・デモ評価

RFPへの提案が集まったら、客観的な手法で評価します。「なんとなく好印象だったから」ではなく、定量的・定性的な評価基準を事前に設定し、複数の評価者が採点することが重要です。

評価手法	内容	特徴
加点法（重み付きスコアリング）	評価項目ごとに重みを設定し、点数を合計する	客観的・定量的。比較が容易
採点表（チェックリスト方式）	要件を満たすかどうかをYes/Noで確認する	必須要件の欠落を確認しやすい
デモ評価	実際にシステムを動かして確認する	UI・使いやすさ・実際の動作を体感
プレゼンテーション評価	提案内容をベンダーに説明させる	担当者の理解度・対応力を確認
参照先ヒアリング（リファレンスチェック）	既存顧客に利用状況を聞く	実績・信頼性を確認

加点法の評価項目例（100点満点）

評価項目	配点	評価内容
機能要件の充足度	30点	必須機能・推奨機能の実装状況
価格（初期費用＋運用費）	25点	5年間TCOを比較
技術力・品質	20点	アーキテクチャ・セキュリティ対策
サポート体制	15点	サポート時間・SLA・担当者
導入実績・信頼性	10点	同業種の導入実績・企業規模

落とし穴：評価基準を事後的に変更すると、恣意的な選定につながります。評価基準・配点はRFP発行前に確定し、ステークホルダーの承認を得ておくことが重要です。

ベンダー評価は加点法・採点表・デモ評価を組み合わせて行います。評価基準は事前に確定・公開することで公平性を保ちます。

SLA（サービスレベル合意書）の構成と主要指標

SLA（Service Level Agreement）は、ITサービスの提供者と利用者の間で、サービス品質の水準を合意した文書です。「24時間365日稼働」「障害発生時は2時間以内に対応」といった具体的な数値目標を定めます。曖昧な合意では後でトラブルになるため、定量的な指標で合意することが重要です。

SLAの主要構成要素

構成要素	定義	例
可用性（Availability）	システムが稼働している時間の割合	99.9%（月当たり約43分の停止許容）
応答時間（Response Time）	リクエストへの応答速度	通常処理：3秒以内、複雑処理：10秒以内
障害復旧時間（RTO）	障害発生から復旧までの目標時間	4時間以内に復旧
目標復旧時点（RPO）	障害時にどの時点のデータまで復元できるか	最大1時間前のデータまで
サポート時間	サポート対応の時間帯	平日9:00〜18:00、障害は24時間対応
問い合わせ対応時間	問い合わせへの初期回答時間	受付後4時間以内に初期回答
定期メンテナンス	計画停止の通知期間・頻度	1週間前に通知・月1回・深夜2時〜4時
ペナルティ条項	SLAを達成できない場合の対応	月額費用の10%クレジット付与

可用性の計算方法

稼働率 = 稼働時間 ÷ （稼働時間＋停止時間） × 100

稼働率	年間許容停止時間	月間許容停止時間
99.9%（スリーナイン）	約8.7時間	約43分
99.99%（フォーナイン）	約52分	約4分
99.999%（ファイブナイン）	約5.3分	約26秒

SLAとOLAの違い：SLAは顧客と提供者の合意。OLA（Operational Level Agreement）はサービス提供者内部の部門間合意。試験でも区別が問われることがあります。

SLAは可用性・応答時間・RTO・RPO・サポート時間など定量的な指標で定義します。稼働率の計算は試験頻出です。

IT投資評価指標：ROI・TCO・NPV・IRRの使い分け

IT投資は「導入すれば何でも良い」のではなく、費用対効果を定量的に評価する必要があります。ROI・TCO・NPV・IRRはそれぞれ異なる観点からIT投資を評価する指標です。どの指標が「何を測るか」を明確に理解しましょう。

指標	正式名称	測定内容	計算式
ROI	Return on Investment（投資利益率）	投資額に対して何%のリターンを得たか	（利益 ÷ 投資額）× 100
TCO	Total Cost of Ownership（総所有コスト）	初期費用＋運用費用を含む総コスト	初期費用＋保守費用＋運用費用＋廃棄費用
NPV	Net Present Value（正味現在価値）	将来キャッシュフローを現在価値に割引した純価値	Σ（将来CF ÷ (1+割引率)^n）- 初期投資
IRR	Internal Rate of Return（内部収益率）	NPVがゼロになる割引率（投資の期待収益率）	NPV=0となるrを求める

ROIの計算例

新システム導入費用：500万円

年間削減コスト：150万円（人件費削減＋ミス削減）

5年間の利益：150万円 × 5年 = 750万円

ROI = （750万 – 500万）÷ 500万 × 100 = 50%

→5年間で投資額の50%がリターンとして得られる計算

TCOの考え方

TCOはパソコン・サーバー・クラウドサービスなど、IT資産の「見えないコスト」を可視化するものです。

コスト種別	内容
直接コスト（見えやすい）	ハードウェア購入費、ソフトウェアライセンス、初期設定費
間接コスト（見えにくい）	保守・サポート費、電気代、教育訓練費、アップグレード費用
廃棄コスト	データ移行、システム廃棄・データ消去費用

ポイント：TCOを比較すると、初期費用が安いシステムが総合的に割高になるケースがあります。

NPVとIRRの使い分け

比較項目	NPV	IRR
判断基準	NPV > 0 なら投資価値あり	IRR > 資本コストなら投資価値あり
強み	絶対額で価値を把握できる	収益率(%)で直感的に理解できる
弱み	割引率の設定に依存する	複数のIRRが算出される場合がある
適した場面	複数プロジェクトの比較	ハードルレートとの比較

ROIは収益率、TCOは総コスト、NPV・IRRは将来価値の評価に使います。試験ではROIの計算式とTCOの「見えないコスト」の概念が重要です。

ITサービスマネジメント（ITSM）との関係

IT調達はシステムを「手に入れる」プロセスですが、手に入れた後はITサービスマネジメント（ITSM）によって継続的に管理・改善されます。ITSMのフレームワークとして最も広く使われているのがITIL（ITインフラストラクチャライブラリ）です。

概念	内容	調達との関係
ITSM（ITサービスマネジメント）	ITサービスの設計・提供・管理・改善の仕組み	調達したシステムの運用フレームワーク
ITIL	ITSMのベストプラクティス集（5段階ライフサイクル）	SLA策定・インシデント管理に活用
インシデント管理	障害発生時に迅速に復旧するプロセス	SLAのRTO達成に直結
変更管理	システム変更を計画的に実施するプロセス	追加開発・機能変更の管理
サービスカタログ管理	提供するITサービスの一覧・内容を管理する	SLAの基礎となるサービス定義
継続的サービス改善（CSI）	KPIを使ってサービス品質を継続的に向上させる	定期的なSLAレビューに対応

調達→運用の流れにおけるITILの位置づけ

調達プロセスでSLAを定義する → 運用開始後はITILのプロセス（インシデント管理・変更管理等）で管理する → 定期的にSLAを見直し改善する

つまり、SLAはITILの「サービスレベル管理」プロセスの中核となる文書です。

調達後のシステムはITIL等のITSMフレームワークで継続管理します。SLAはITSMのサービスレベル管理の核心となる文書です。

調達に関連する契約形態

IT調達では、どのような契約形態を選ぶかによって、責任の所在・費用構造・柔軟性が大きく変わります。請負契約・準委任契約・派遣契約の違いは試験でも問われます。

契約形態	責任の所在	報酬形態	適した場面
請負契約	成果物の完成責任はベンダー	完成報酬型（固定価格）	要件が明確なウォーターフォール開発
準委任契約	善管注意義務（完成責任なし）	時間単位（工数精算）	要件変更が多いアジャイル開発・保守
派遣契約	発注者が指揮命令権を持つ	時間単位	自社内でエンジニアを指揮する場合

偽装請負に注意：請負・準委任契約なのに発注者がベンダー要員に直接指示を出すと「偽装請負」になり、職業安定法・労働者派遣法に違反します。IT調達の現場では特に注意が必要な点です。

クラウドサービスの調達（SaaS・PaaS・IaaS）

サービス形態	内容	調達の特徴
SaaS	ソフトウェアをサービスとして利用	カスタマイズは限定的。SLAの確認が重要
PaaS	開発プラットフォームをサービスとして利用	自社開発との組み合わせ。稼働保証の確認
IaaS	インフラ（サーバー・ネットワーク）をサービスとして利用	柔軟性高い。運用管理は自社負担

IT調達では請負・準委任・派遣契約の違いを理解することが重要です。また、クラウドサービスの調達ではSLAの内容確認が不可欠です。

調達評価の落とし穴と対策

IT調達では、適切なプロセスを踏んでも失敗しやすいポイントがあります。実務・試験の両面から「よくある落とし穴」を理解しておきましょう。

落とし穴	問題点	対策
要件定義の不備	RFPが曖昧→提案が比較できない	業務フロー・As-Is/To-Beモデルで要件を可視化
TCOの軽視	初期費用だけで比較→運用費で逆転	5〜7年間のTCO比較表を作成する
SLAの形骸化	SLAはあるが定期レビューをしない	四半期ごとにSLA達成状況をレビューする
ベンダーロックイン	特定ベンダーに依存してしまう	データ移行容易性・オープンAPI対応を評価項目に加える
評価基準の恣意的変更	後付けで評価基準を変更→公平性が失われる	評価基準をRFP発行時点で確定・文書化

IT調達の失敗の多くは「要件定義の不備」「TCO軽視」「SLA形骸化」が原因です。プロセスを標準化し、定期的なレビューを行うことが重要です。

試験頻出ポイントと過去問分析

経営情報システム頻出論点まとめ

論点	頻出度	要点
RFI vs RFP の違い	★★★	RFI=情報収集、RFP=提案依頼。RFIが先
SLAの定義・構成要素	★★★	可用性・RTO・RPO・サポート時間
稼働率（可用性）の計算	★★★	稼働率=稼働時間÷(稼働時間+停止時間)×100
TCO vs 初期費用	★★☆	TCOには運用費・廃棄費用も含む
ROIの計算	★★☆	（利益÷投資額）×100
請負 vs 準委任契約	★★☆	請負=完成責任あり、準委任=善管注意義務のみ
ベンダー評価手法	★★☆	加点法・採点表・デモ評価の組み合わせ

出題パターン：「RFPに記載すべき内容として適切でないものはどれか」「SLAの定義として最も適切なものはどれか」という択一式が多いです。定義と例を正確に覚えておきましょう。

試験では「RFI vs RFP」「SLAの構成」「稼働率計算」の3点が特に重要。定義を正確に覚えた上で、計算問題にも対応できるよう練習しておきましょう。

よくある質問（FAQ）

Q1. RFPとRFIの一番の違いは何ですか？

目的と対象が異なります。RFIは「市場にどんな製品・ベンダーがあるか調べるため」に幅広く発行するものです。RFPは候補ベンダーを絞った後に「具体的な提案・価格・スケジュールを出してほしい」と依頼するものです。RFIで情報収集→RFPで提案依頼、という順序が基本です。

Q2. SLAと契約書の違いは何ですか？

契約書はサービスの基本条件（範囲・料金・期間・免責）を定めた法的文書です。SLAは契約書の一部または別紙として、サービス品質の数値目標（稼働率・応答時間など）を定めたものです。SLAはサービス品質に特化した合意書という位置づけです。

Q3. ROIがプラスなら必ずIT投資すべきですか？

ROIがプラスであることは必要条件ですが、十分条件ではありません。他の投資機会との比較（機会費用）、リスクの大きさ、資金調達コスト（IRRが資本コストを上回るか）、組織のキャパシティ等を総合的に判断する必要があります。また、ROI計算の前提となる「コスト削減・売上向上の見積もり」が過度に楽観的でないか検証することも重要です。

Q4. TCOとROIはどのように使い分けますか？

TCOは「このシステムを持つことによる総コストはいくらか」を把握するために使います。主にベンダー比較・予算策定に役立ちます。ROIは「このシステムへの投資がどれだけ利益を生むか」を評価するために使います。TCOで総コストを把握した上で、ROIで投資効果を算出するという組み合わせが一般的です。

Q5. 中小企業はRFPを必ず作らないといけませんか？

法律上の義務ではありませんが、複数ベンダーから公平に提案を取り付けて比較するためには、RFPを作成することが強く推奨されます。RFPがないと「なんとなく知り合いのベンダーに頼む」という状況になりやすく、費用・品質の比較ができません。中小企業の場合は簡易版RFP（A4 2〜3枚程度）でも効果があります。

Q6. 請負契約と準委任契約、どちらを選ぶべきですか？

要件が明確で変更が少ない場合は「請負契約」が適しています。成果物完成の責任をベンダーに負わせることができます。一方、アジャイル開発や保守・運用など変更が多い場合は「準委任契約」が適しています。ただし準委任の場合は工数が増えると費用も増えるため、上限費用の設定などを契約に盛り込むことが重要です。

Q7. SLAの稼働率99.9%はどのくらいの停止を許容していますか？

年間約8.7時間、月間約43分の停止を許容します。ただし「計画停止（メンテナンス）」はSLAの算定対象外とすることが多いため、実際の業務影響を考えるときは計画停止も含めた稼働時間を確認する必要があります。基幹システムや金融系では99.99%（年間約52分）以上が求められることが一般的です。

情報システムの調達・評価は、RFI/RFP・ベンダー評価・SLA・投資評価指標（ROI/TCO/NPV/IRR）・契約形態という5つの柱で構成されています。各要素を体系的に理解することで、試験問題にも実務にも対応できるようになります。

Post Views: 93

よかったらシェアしてね！