ITベンダーの提案書はどう評価する？技術者でなくても確認できる7つのポイント

システム刷新やDXを進める際、ITベンダーから提案書を受け取ったものの、専門用語や構成図が多く「良い提案なのか判断できない」と感じることがあります。

特にAWS等のクラウドを利用する提案では、ネットワーク、アプリケーション実行環境、データベース、WAF、監視、冗長化など、多くの技術要素が構成図に並びます。

しかし、経営者がそれぞれの技術をエンジニアと同じ深さまで理解してから発注判断する必要はありません。

重要なのは、技術構成を「何を実現するために必要なのか」「何を前提としているのか」「導入後に誰が責任を持つのか」という経営判断に必要な情報へ変換することです。

本記事では、AWSを利用したシステム提案を受けた架空企業を例に、技術者でない経営者でもITベンダーの提案書を確認しやすくする7つの観点を整理します。

専門用語をすべて理解する必要はない

IT提案を評価するときに陥りやすいのが、「専門用語が分からないから判断できない」という状態です。

例えばAWS構成図に複数のサービスやセキュリティ機能が記載されていても、サービス名の多さ自体は提案の良し悪しを示しません。反対に、構成が単純であることだけを理由に優れた設計とも判断できません。

まず技術用語を、次のような質問へ置き換えます。

提案書を「要件・技術・責任」に分けて読む

システム構成図だけを見て評価しようとすると、専門知識の差がそのまま情報格差になります。

そこで、提案を「要件」「技術構成」「責任」の3層に分けます。

重要なのは、技術構成の各要素が上段の要件と対応しており、下段の責任範囲まで決まっているかを見ることです。

ITベンダーの提案書で確認したい7つのポイント

1. 目的・要件：何を解決する提案なのか

まず、システムを導入することで何を変えたいのかを確認します。

• 対象となる業務課題は何か
• 絶対に必要な機能は何か
• あれば便利な機能は何か
• 今回の開発・導入範囲はどこまでか
• 対象外になっているものは何か

技術構成が高度でも、解決したい業務課題と対応していなければ、投資判断はできません。

2. 前提・制約：どの条件で設計しているのか

同じシステムでも、利用人数、アクセス量、データ量、利用時間帯、必要な連携先等によって必要な構成は変わります。

「なぜこの規模の構成なのか」を確認するときは、見積もりや設計の前提になっている利用条件を確認します。

前提が実際の利用状況とかけ離れていれば、過剰な構成にも不足した構成にもなり得ます。

3. 技術構成：なぜこの方式なのか

技術構成を見るときは、サービス名ではなく採用理由を確認します。

例えばアクセスを複数の処理環境へ振り分ける構成なら、「なぜ負荷分散が必要なのか」「単純な構成では要件を満たせないのか」を確認します。

構成要素ごとに「どの要件を満たすのか」「外した場合にどのリスクが増えるのか」「別の方式も検討したのか」を質問すると、技術構成と業務要件の関係が見えやすくなります。

4. 非機能要件：止まる・遅い・漏れる場合をどう考えるか

システムでは「何ができるか」という機能だけでなく、「どの程度止まってよいか」「どの程度の速度が必要か」「障害後にどこまで復旧するか」といった非機能要件も重要です。

例えばバックアップを評価するなら、「バックアップを取っているか」だけでなく、どの時点までデータを戻せればよいか、障害発生後どの程度で業務を再開したいかを考えます。

RPO（目標復旧時点）は許容できるデータ損失の範囲、RTO（目標復旧時間）は業務を再開するまでの目標時間を整理する考え方です。これらは技術部門だけで決めるものではなく、業務への影響を理解する経営・業務側の判断も必要です。

5. 責任範囲：誰が何を担当するのか

クラウドを利用しても、クラウド事業者がシステム運用のすべてを担うわけではありません。

例えば基盤そのものの運用、アプリケーションの設定、利用者の権限管理、データ管理、監視、障害対応などについて、クラウド事業者、ITベンダー、自社のどこまでが担当するのかを確認します。

「セキュリティ対策済み」「監視あり」といった言葉だけでなく、実際にアラートが発生した場合に誰が確認し、誰が復旧判断を行うのかまで具体化すると、責任範囲を把握しやすくなります。

6. 費用・運用：作った後に何が必要か

提案書では初期構築費へ目が向きやすいですが、本番稼働後にはクラウド利用料、保守、監視、問い合わせ対応、設定変更、セキュリティ対応等が発生します。

特に確認したいのは、ベンダーへ支払う費用だけでなく、自社側に残る運用作業です。

• 利用者の追加・削除
• 権限変更
• ログ確認
• データ管理
• 障害時の社内連絡
• ベンダーへの問い合わせ
• 定期的な設定・契約見直し

まで含めて確認すると、導入後の負担を把握しやすくなります。

7. 変更・出口：将来別の選択肢へ移れるか

システムは導入時だけでなく、数年後の変更も考える必要があります。

• ベンダー変更時に設計情報を引き継げるか
• データを一般的な形式で取り出せるか
• 別のクラウドやサービスへ移行できるか
• 契約終了後にデータはどう扱われるか
• 特定の担当者しか分からない状態にならないか

を確認します。

初期構築が合理的でも、将来の変更が著しく難しい場合には、長期的な制約として経営判断に含める必要があります。

AWS構成図を見ても妥当性が分からない場合

ここでは説明用の架空ケースとして、経営者がAWSを利用したWebシステムの提案を受けたとします。

構成図には、アクセスの振り分け、アプリケーション実行環境、データベース、ファイル保存、WAF、ログ・監視、冗長構成等が記載されています。

このとき、それぞれのAWSサービスを暗記する代わりに、次のように質問を変換します。

構成要素	経営・発注側から確認したいこと
冗長構成	なぜ停止を避ける必要があるか。業務上許容できる停止時間はどの程度か。単純な構成との違いは何か。
WAF等の防御機能	どのリスクを低減するためか。導入後に設定・ログ・アラートを誰が管理するか。
監視	何を監視するのか。異常検知後に誰が確認し、夜間・休日を含め誰が対応するか。
バックアップ	どの程度のデータ損失を許容するか。どの程度で復旧する必要があるか。復旧できることをどう確認するか。
マネージドサービス	クラウド事業者へ任せられる範囲と、ベンダー・自社に残る運用作業は何か。

このようにすると、「AWS構成が正しいか」を直接判定するのではなく、自社の要求と構成の関係が説明できるかを確認できます。

複数ベンダーの提案はサービス名ではなく要件で比較する

A社とB社の構成が大きく異なる場合、そのまま構成図同士を比較しても判断しにくくなります。

そこで、両社の提案を共通の要求項目へ戻します。

例えばA社は高い可用性を重視し、B社は構成を簡素化しているかもしれません。その場合、「どちらの構成が高度か」ではなく、「自社ではどの程度の停止を許容できるか」という要求へ戻して比較します。

同様に、セキュリティ、性能、バックアップ、サポート等についても、両社が同じ要求条件を前提としているか確認します。

ベンダーへそのまま聞ける質問

• この構成要素は、どの要件を満たすために必要ですか
• この構成要素を外した場合、何ができなくなりますか
• 利用人数・アクセス量・データ量は何を前提にしていますか
• 別の構成方法は検討しましたか
• このシステムはどの程度の停止を想定していますか
• 障害時は誰が検知し、誰が復旧しますか
• バックアップからの復旧はどのように確認しますか
• セキュリティ対策のうち、導入後に継続運用が必要なものは何ですか
• クラウド事業者、御社、当社の責任範囲を整理できますか
• 初期費用以外に継続して発生する費用・作業は何ですか
• ベンダー変更時に必要となる資料・データを引き継げますか
• 契約終了時のデータ処理はどうなりますか

構成図を見て判断できない場合は、まず「どの要件を満たすために必要か」「外した場合に何が起きるか」「本番後は誰が運用するか」の3点を確認するだけでも、提案内容を整理しやすくなります。

ITベンダー提案書の発注前チェックリスト

確認領域	確認する内容
業務課題	何を改善するシステムか明確か
必須要件	なくてはならない機能・条件を分けているか
対象範囲	今回含まれるもの・含まれないものが明確か
前提条件	利用者数、データ量、アクセス量等が明確か
非機能要件	可用性、性能、セキュリティ等の要求を整理したか
バックアップ・復旧	データ損失・停止をどこまで許容するか決めているか
技術構成	主要な構成要素の採用理由を説明できるか
代替案	他の構成・サービスを検討したか
責任分界	クラウド、ベンダー、自社の役割が明確か
監視・障害対応	異常発生後に誰が何をするか決まっているか
初期費用	何が見積もりに含まれているか明確か
継続費用	クラウド、保守、監視、変更等を確認したか
自社側作業	導入後に自社へ残る作業を確認したか
SLA	サービス・サポート条件を確認したか
出口	データ移行、ベンダー変更、契約終了条件を確認したか

経営判断と技術レビューは分けて考える

「専門用語をすべて理解しなくてもよい」ということは、「技術レビューが不要」という意味ではありません。

経営者や発注者が判断すべきなのは、何を実現したいか、どの程度の停止・リスクを許容するか、どこまで費用をかけるか、誰にどの責任を持たせるか、といった部分です。

一方、実際のネットワーク設計、アクセス権限、性能見積もり、セキュリティ設定等が技術的に適切かは、詳細な技術レビューが必要になる場合があります。

経営判断と技術判断を分けることで、「全部理解できないからベンダーへ任せる」「全部自分で理解してから決める」という二択を避けやすくなります。

まとめ

ITベンダーの提案書を評価するとき、AWSやネットワークの専門用語をすべて習得することが最初の仕事ではありません。

まず提案を次の7つに分解します。

1. 目的・要件
2. 前提・制約
3. 技術構成
4. 非機能要件
5. 責任範囲
6. 費用・運用
7. 変更・出口

そのうえで、技術構成について「何の要件を満たしているのか」「なぜ必要なのか」「導入後に誰が維持するのか」を確認します。

SCI総合研究所株式会社のKAMUSHIRUBEでは、IT、DX、クラウド等のベンダー提案や技術資料について、契約・導入前の段階から論点整理を行っています。

構成図や技術用語を単に解説するのではなく、提案内容がどの業務要件・非機能要件を満たすものなのか、前提条件や責任範囲、運用負荷、費用等を整理し、次にベンダーへ確認すべき事項を明確にします。「AWS構成図を見ても妥当性が判断できない」「複数社の提案内容が違いすぎて比較できない」といった段階から相談できます。

参考文献

• Amazon Web Services. 2024. AWS Well-Architected Framework.
• Amazon Web Services. 2024. Shared responsibility – Security Pillar. AWS Well-Architected Framework.
• 独立行政法人情報処理推進機構（IPA）. 2018. 非機能要求グレード2018.