クラウド導入の要件定義で決めるべき項目を整理する方法（チェックリスト）

クラウド導入の要件定義で「最初に決めるべきこと」

クラウド導入は「サーバーをクラウドに置き換えるだけ」と思われがちですが、実際は業務のやり方・セキュリティ・運用体制まで含めて設計し直すプロジェクトになりやすいです。特に、開発に詳しくない担当者が進める場合、ベンダーの提案を比較できずに「想定外の追加費用」「セキュリティ審査で差し戻し」「運用が回らない」といった失敗が起きがちです。

要件定義の役割は、クラウド移行（クラウド化、クラウド活用）で実現したい目的を、ITの仕様・運用ルール・費用見積もりに落とし込み、関係者で合意することです。ここが曖昧だと、同じ「クラウド導入」でも、A社は“最小移行”の前提、B社は“モダナイズ前提”で提案してきて、見積もりが比較不能になります。

まず押さえたいのは、クラウド導入には大きく次の2つの進め方がある点です。

• リフト（現状踏襲）：今のシステム構成をできるだけ変えずにクラウドへ移す。短期で移行しやすいが、最適化は後回しになりがち。
• モダナイズ（作り替え・最適化）：クラウドの仕組み（自動拡張、マネージドサービス等）を前提に設計を見直す。効果は大きいが設計・検証が増える。

どちらが正解というより、業務影響・期限・予算・社内スキルで選びます。この記事では、クラウド導入の要件定義で決めるべき項目を「漏れなく」「説明できる形」に整理するためのチェックリストを、非エンジニアでも扱える言葉でまとめます。

要件定義の進め方：整理の順番を間違えない

要件定義が難しく見える理由の多くは、いきなり「クラウドはAWSかAzureか」「サーバースペックは？」から入ってしまうことにあります。順番としては、目的→業務→システム→運用→費用の順に落とすと破綻しにくいです。以下の流れで整理しましょう。

1. 目的（なぜクラウド？）：コスト削減、BCP、スピード、セキュリティ、拡張性などの優先順位を決める
2. 範囲（どこまでクラウド？）：対象システム、対象業務、移行しないもの（オンプレ残し）を明確化
3. 現状把握（何が動いている？）：アプリ、サーバー、ネットワーク、連携、データ、運用手順を棚卸し
4. 将来像（どうあるべき？）：性能、可用性、セキュリティ、運用体制、監査・ログなどの要件を確定
5. 制約（できないこと）：期限、予算、社内規定、既存契約、取引先要件、審査手順
6. 移行計画（どう移す？）：段階移行、テスト、切替、リハーサル、ロールバック、教育

この順番で進めると、クラウド移行における「設計の前提」が早い段階で揃うため、ベンダーに依頼する場合も提案品質が上がり、見積もり比較もしやすくなります。逆に、目的や範囲が曖昧なままクラウド基盤の話をすると、後から「それは要件に入っていない」となりやすいので注意してください。

また、情シスが中心でも、業務部門（経理・営業・製造など）と合意しないと、移行後に「画面が遅い」「帳票が出ない」「締め処理日に止まる」といった実害が出ます。要件定義はITの文書ですが、業務の合意書でもあります。

チェックリスト：目的・範囲・現状把握（最初に固める）

ここではクラウド導入の要件定義で、最初に固めるべき“前提”をチェックリスト化します。これが揃うと、クラウド（クラウドサービス、クラウド環境）選定や設計の議論が一気に進めやすくなります。

目的・期待効果

• クラウド導入の目的は何か（例：サーバー更改をなくす、障害に強くする、拠点追加を早くする）
• 目的の優先順位は何か（コスト・スピード・セキュリティ・可用性・拡張性）
• 効果測定の指標は何か（例：リリース頻度、復旧時間、月次処理時間、運用工数）
• 「いつまでに」「何をもって成功」とするか（経営層/部門長の合意）

対象範囲（スコープ）

• 対象システム一覧（基幹、営業支援、会計、社内ポータル、バッチ、帳票など）
• 対象データ（顧客情報、取引情報、個人情報、機密情報）の範囲
• 移行対象外（当面オンプレ継続、SaaS利用、廃止するシステム）の整理
• 関連会社・取引先との接続があるか（EDI、API、SFTP、VPN）

現状把握（棚卸し）

• 現行の構成（サーバー台数、OS、ミドルウェア、DB、ストレージ、ネットワーク）
• ピーク負荷（締め日、セール、月末など）と処理時間の実態
• 障害履歴と、復旧にかかった時間・原因の傾向
• 運用作業（手動バッチ、バックアップ、ユーザー追加、証明書更新）の一覧
• 監視/ログの取得状況（何が見えていて、何が見えていないか）

制約条件（最初に書いておく）

• 期限（例：データセンター契約満了、オンプレ保守切れ、監査時期）
• 予算（初期費用上限、運用費上限、稟議の単位、CAPEX/OPEXの方針）
• 社内規程（セキュリティ基準、パスワード/多要素認証、ログ保管期間）
• 調達・稟議フロー（見積もり取得先、審査項目、決裁者）

チェックリスト：非機能要件（性能・可用性・バックアップ・BCP）

クラウド導入で揉めやすいのが非機能要件です。画面や帳票など“見える機能”は議論しやすい一方、性能や可用性は後回しにされがちです。しかし、ここが曖昧だとクラウド費用が青天井になったり、逆に安く作って遅くなったりします。要件定義の段階で「どの程度を狙うか」を言語化しておきましょう。

性能・キャパシティ

• 同時利用者数、想定トラフィック、バッチ処理量（件数、データサイズ）
• 許容レスポンス（例：検索は2秒以内、締め処理は60分以内）
• ピークのタイミング（いつ増えるか）と、増減の予測（事業計画）
• 性能劣化時の優先順位（全体が遅くなるのはNGか、一部機能停止でよいか）

可用性（止められない度合い）

• 稼働時間（24/365が必要か、営業時間内でよいか）
• メンテナンス停止の許容（深夜に30分ならOKなど）
• 冗長化の範囲（アプリ、DB、ネットワーク、拠点回線）
• RTO（復旧までの時間）とRPO（失ってよいデータ量）を業務目線で定義

バックアップ・アーカイブ

• バックアップ頻度（日次、時間ごと）と保管期間（例：35日、1年、7年）
• 復元手順（誰が、どの画面から、どれくらいで戻せるか）
• 監査/法令対応（電子帳簿保存法、個人情報、業界ガイドライン等に沿うか）
• ランサムウェア対策としての“改ざんされにくい保管”が必要か

BCP・災害対策

• 拠点停止（本社が使えない）時の業務継続方法
• 別リージョン/別クラウドの要否（重要システムのみでもよい）
• 年に何回、切替訓練（DR訓練）を行うか

非機能要件は「全部最高」にするとクラウド費用が膨らみます。大事なのは、業務の重要度でメリハリを付けることです。例えば、社内ポータルは営業時間内復旧でよいが、受注は短時間で復旧が必要、といった具合にレベル分けして要件定義に落とすと、クラウド設計と費用の説明が通りやすくなります。

チェックリスト：セキュリティ・ガバナンス（情シスが押さえるべき要点）

クラウド導入でのセキュリティは「クラウドだから不安」ではなく、責任分界（どこまでがクラウド事業者、どこからが自社）を前提に管理することがポイントです。特に大企業の情シスでは、監査・規程・承認プロセスとセットで要件定義しないと、導入後に運用が破綻します。

認証・権限（ID管理）

• ログイン方式（社内ID連携、SSO、多要素認証の必須化）
• 権限設計（管理者、運用者、閲覧者、委託先の権限範囲）
• 入退社・異動時の権限変更（誰がいつ反映するか）
• 特権IDの扱い（緊急時だけ使う、利用記録を残すなど）

ネットワーク・接続

• 社内ネットワークからクラウドへの接続（VPN、専用線、ゼロトラスト等）
• 拠点/在宅からのアクセス制御（IP制限、端末制御、条件付きアクセス）
• 外部公開の有無（インターネット公開する画面/ APIの範囲）

データ保護（暗号化・保管場所）

• 保存データの暗号化、通信の暗号化（TLS）
• 鍵管理（クラウド任せか、自社管理か）
• データ保管場所（国内リージョン必須か、国外可か）
• 個人情報・機密情報の取り扱い（マスキング、閲覧制御、持ち出し制御）

ログ・監査・インシデント対応

• 取得すべきログ（操作ログ、認証ログ、API、DB監査ログ）
• ログ保管期間と検索性（監査対応で“出せる”ことが重要）
• インシデント時の連絡・初動（誰が判断し、どこへ連絡するか）
• 委託先（ベンダー）が触れる範囲の明文化（作業申請、承認、証跡）

情シスが「セキュリティは任せます」としてしまうと、クラウド環境の標準設定のまま運用され、後から監査で修正が入りがちです。要件定義では、規程や監査の観点を先に洗い出し、クラウド移行後の運用が回る形（申請、承認、証跡）に落としてください。

チェックリスト：移行方式・運用設計・費用見積もり（失敗を防ぐ実務ポイント）

クラウド導入を“導入して終わり”にしないためには、移行方式と運用設計を要件定義に含めることが重要です。特に「月額はいくら？」という問いに対して、クラウド費用は使い方次第で変動します。費用がブレる前提（変動要因）を先に合意しておくと、稟議や経営説明が楽になります。

移行方式（リフト/モダナイズ/段階移行）

• 移行対象の優先順位（業務影響が小さいものから、重要なものから等）
• 段階移行の可否（システム間連携が多いと一括が必要な場合も）
• データ移行方法（停止して一気に移す/並行稼働で徐々に切替）
• 移行リハーサルの回数、切替手順、ロールバック（戻す手順）の定義

テスト・受入（非エンジニアでも決めるべき）

• 業務テストの観点（締め、請求、在庫引当、権限別の操作など）
• 性能テストの基準（ピーク時に耐えるか、処理時間の合格ライン）
• セキュリティテスト（脆弱性診断の要否、実施範囲、責任分担）
• 受入の合否判定者（業務部門・情シス・経営の誰がOKを出すか）

運用設計（運用が回るかが最重要）

• 運用体制（社内/委託先の役割分担、一次対応、二次対応）
• 監視（何を監視し、アラートが来たら誰がどう動くか）
• 変更管理（設定変更・リリース・権限変更の申請と承認）
• 定期作業（バックアップ確認、パッチ適用、証明書更新、棚卸し）
• SLA/サポート時間（夜間対応、休日対応の要否）

費用（見積もり比較のための前提条件）

• 初期費用の内訳（設計、構築、移行、テスト、教育、ドキュメント）
• 運用費の内訳（クラウド利用料、監視、保守、サポート、回線）
• 変動費の要因（アクセス増、データ増、ログ増、バックアップ増）
• コスト管理の運用（予算アラート、上限設定、月次レポートの担当）

まとめ

クラウド導入の要件定義は、クラウドサービスの選定や構成図を作る前に、目的・範囲・現状・非機能・セキュリティ・運用・費用の前提を合意する作業です。ここが揃うと、提案比較ができ、移行後も運用が回り、想定外コストや監査差し戻しを減らせます。

• 最初に「なぜクラウドか」「どこまでクラウドか」を言語化する
• 非機能要件（性能/可用性/バックアップ/BCP）は業務重要度でメリハリを付ける
• セキュリティは責任分界と運用（申請・承認・証跡）まで要件化する
• 移行方式・受入基準・コストの変動要因を前提として合意する

社内に専門家が少ない場合でも、このチェックリストを埋めていけば「何を決めないといけないか」が明確になり、クラウド移行プロジェクトの精度が上がります。要件定義の叩き台作りや、クラウド導入の進め方そのものに不安がある場合は、第三者目線で整理・伴走できる支援を入れるのも有効です。