21-1. ECサイトの構築とセキュリティ機能の実装と運用
「デジタル・ガバメント推進標準ガイドライン」に準拠した手順で情報システムを導入する方法と、セキュリティ機能を実装する方法について説明します。具体的に説明するために、ECサイトの導入を例にとって説明します。
ECサイト導入における全体概要は以下の通りです。
● サービスの利用者の種類やニーズを特定します。（ペルソナ分析など）
● 現状の業務フローを分析し、サービスの改善点を明確にします。
● 業務要件と機能要件を定義します。
● Fit&Gap分析を実施します。
● 調達仕様書を作成します。
● 適正価格で最適な業者を選定します。
● 設計・開発実施計画書を作成します。
● テストを管理し、また自社で品質を確認するために受入テストを実施します。
● ECサイト運営における業務マニュアルを作成します。
● 研修教育資料（業務マニュアルなど）を用いて、従業員に対して教育を実施します。
● 運用・保守の詳細な作業内容や実施方法などを検討します。
● 運用・保守の改善を継続的に実施していきます。
セキュリティに関する要件は、適用宣言書をもとにして行います。セキュリティに関する要件を決める流れは以下の通りです。
1. 情報システムで取扱う情報資産に対して、リスクアセスメントを実施する。
2. リスクアセスメントの結果をもとに、必要な管理策を決定する。（適用宣言書の作成）
3. 適用宣言書の内容を満たすように、非機能要件などでセキュリティ要件を決定する。
※セキュリティ要件の詳細は「21-1-2.要件定義」で説明します。
21-1-1. サービス・業務企画
本工程は、規模に関わらずすべての企業にとって重要です。顧客ニーズを理解し、現状の業務を分析した上で、新しいサービスや業務プロセスを計画することは、中小企業の成⻑と効率化に直結します。
サービスを検討するための大前提として、利用者の立場でサービスを受けることを想像し、利用者のニーズがどこにあるかを考えることが大切です。しかし、サービスを提供する側は、どうしても「提供者側の視点」に立ちがちになります。さまざまな利用者のそれぞれの立場でニーズを把握するための手法の1つとして、「ペルソナ分析」があります。
ペルソナ分析
「ペルソナ」とは、サービスの典型的な利用者の、目的、意識、行動などのパターンを構造化し、利用対象者を仮想の人物として定義するものです。例えばサービスのターゲットを「会社員」と抽象的に定義すると、検討チームのメンバーそれぞれが思い描く「会社員」の姿が異なるため、チームとして判断する際にブレが生じてしまいます。ペルソナ分析ではもっと具体的に「氏名、年齢、性別、家族構成、勤務先、仕事内容、そのほかの詳細条件」などを設定します。このような具体的な利用者像をイメージしながら検討を行うことで、利用者が抱える課題や問題を浮き彫りにし、具体性の高いアイデアを創出しやすくなります。
ペルソナの作り方
以下の企業を想定としたペルソナ作成の例を紹介します。
● 地方の特産品を扱う中小企業を想定
● 実店舗がある。
● ECサイトは現在なく、これから構築しようと検討している。
● 実店舗に加えて、販売窓口を増やしたいと考えている。
・ インタビュー・アンケート
実店舗の来店者に対して、購入動機、どのような商品をオンラインで購入したいか、どのような購入体験を期待しているかを尋ねる。実店舗での顧客に対して、購入理由、購入頻度、地域とのつながりなどをアンケートにより収集する。
・ Web検索や公開調査データ
ECサイトを利用する層（地域外の顧客や新規顧客）について、公開されている市場調査データを収集。
・ 店舗の観察・ヒアリング
店舗スタッフからのヒアリングにより、どのような顧客層が頻繁に訪れているのかを確認。
・ 地域住⺠か観光客か
地域に住んでいるリピーター、観光目的で訪れた一見の顧客。
・ 年齢層
若年層、中年層、高齢層
・ 購入動機
日常の食材としての購入、贈答品としての購入、観光の記念品としての購入。
・ 利用方法
実店舗での対面購入、電話注文、リピーターによる定期購入。
ペルソナの例:「地域住⺠のリピーター」
名前 山田 花子（45歳）
職業 地元の学校で働くパートタイムスタッフ
居住地 店舗のある地方都市
家族構成 夫と高校生の娘1人
趣味 地元のイベントや料理教室に参加すること
価値観
地元の発展に貢献することを大切にしており、地元産品の購入を積極的に行う。
安全で新鮮な食品を求めるため、実店舗で直接商品を見て購入することに安心感を得ている。
利用動機 日常の食材として地元の特産品を購入。特に週末に家族で食事を楽しむため、実店舗で定期的に訪れて新しい商品を見つけるのを楽しみにしている。
購入経路 現在は実店舗での対面購入を利用。ECサイトが構築されれば、忙しいときでもオンラインで注文し、自宅での受け取りや店舗での受け取りができることに興味を持っている。
ペルソナの案を作成後、ターゲットとなる利用者と直に接している人などに、実際の利用者像とかけ離れたところがないか、ターゲットたる利用者としてふさわしいかを確認してもらいます。実際の利用者像と作成したペルソナにかい離が見られた場合は、随時内容を修正してください。
業務を観察した結果は、多くのドキュメントとしてまとめられることがあり、分析に関わった人は内容を理解できますが、初めて読む人にはポイントを把握することが難しいことがあります。プロジェクト内部の従業員や外部の関係者、システム開発事業者など、多様な立場の人が内容を確認する必要があるため、業務の状況を誰にでもわかりやすく伝えるために、業務フローなどを用いた視覚的にわかりやすい資料を作成することが重要です。
業務フローの作成
業務フローは、現在行っている業務を「誰が（どの組織が）」「いつ」「何を」「どの順番で」実施しているか、「どの範囲が情報システム化されているか」を可視化するものです。対策の検討や企画後の業務内容の変化箇所を特定するためにも有効です。
業務フローには、現行（AsIs）と将来（ToBe）があります。はじめに作成するのは、現行の業務フローです。業務フローの書き方については、さまざまな表記方法があります。基本的に、関係者にとってわかりやすい表記であれば、どのような表記方法でも問題ないです。縦に流れるフローでも、横に流れるフローでも、どちらでも構いません。
例:お客様が実店舗で商品を購入するフロー
● 地方の特産品を扱う中小企業を想定
● 実店舗での商品購入フロー
図83. 実店舗で商品を購入するフロー例
現状把握が終わった後は、企画案を練り上げます。企画案の方向性がある程度決まったら、プロジェクト内外の関係者にわかりやすく説明し、改善点のフィードバックを受け取るために、将来（ToBe）の業務フローを活用します。現行（AsIs）の業務フローをもとに、将来どこがどのように変わるのかを明確に示し、変更点とその効果を具体的に示します。関係者と目指す姿を共有できるようにするために、業務フローに吹き出しを付けることは効果的です。
例:お客様がECサイトで商品を購入するフロー
● 地方の特産品を扱う中小企業を想定
● 実店舗での商品購入フローをもとに、ECサイトでの購入フローを作成
図84. ECサイトで商品を購入するフロー例
21-1-2. 要件定義
RFIや事業者からの情報収集といった活動を通して、市場にあるサービスや他社の事例などを把握します。その上で、情報システムを導入する際、明確な要件を定義することは中小企業にとっても非常に重要です。必要な機能を確実に実装し、パフォーマンスや信頼性などの非機能要件も満たすことができます。
セキュリティに関する要件については、適用宣言書に基づいて決定することが重要です。
要件定義の内容を記した文書は、プロジェクト管理を行うチームや担当者と事業者がサービス・業務や情報システムの目指すべき姿を共有するとともに、事業者との契約上の合意文書となる重要なものであるため、誤った定義や曖昧な定義が行われると、後続の工程に重大な影響を与えます。
そのため、要件定義の内容は次に示す点を参考に、正確で一貫性のある記載となるようにし、受託業者の解釈によりブレない内容とすることが重要です。
・ 曖昧な用語や一般的な意味と異なる使い方をしている用語などは、プロジェクト関係者間での認識の齟齬を防止するため、用語の定義および機能を定義する粒度や深さについて統一する。
・ 要件定義書の「業務要件定義」のインプットであるサービス・業務企画の内容とも整合の取れた区分、順番で機能を記載する。業務の単位ごとに記載する場合も、共通処理機能を識別できるように整理するなど、機能数を把握できるように記載する。
・ 機能の説明は、箇条書きなどにして簡潔に記載する。既存のサービス・業務や情報システムの変更を行う際の要件定義では、追加・変更となる要件が明確になるよう、変更箇所の記載ルールを定めて記載を統一する。
機能要件として定義しないといけない内容は5つです。
・ 機能
・ 画面
・ 帳票
・ データ
・ 外部インターフェース
要件定義の対象となる情報システムによっては、このうちの一部を定義しない場合もあります。例えば、他の情報システムと連携しないWebサイトであれば外部インターフェースの定義は不要となります。
機能に関する事項
「機能」とは、情報システムが外部に価値を提供する一連の動作のまとまりのことです。基本的に「入力」・「演算（処理）」・「出力」で構成されます。ボタンを押したら画面に情報が表示されるのも、夜間にバッチ処理で帳票が大量に印刷されるのも、それぞれ1つの機能です。情報システムが提供する形はさまざまですが、それらを「機能」としてリスト化して整理するために用いるものが、「情報システム機能一覧」と呼ばれるドキュメントです。
情報システム機能一覧（例）
NO 1
機能ID XXX
機能分類 新規ユーザー登録
機能名 新規ユーザー登録機能
機能概要 入力 記載事項の入力
機能概要 処理 ・・・
機能概要 出力 ・・・
処理方式 オンライン
利用者区分 新規登録申込者
現状の機能との差異 ・・・
NO 2
機能ID XXX
機能分類 新規ユーザー出力
機能名 新規ユーザー出力機能
機能概要 入力 出力方式の選択
機能概要 処理 ・・・
機能概要 出力 新規登録申込書の出力
処理方式 オンライン
利用者区分 新規登録申込者
現状の機能との差異 ・・・
画面に関する事項
情報システムの画面は、利用者が業務の流れの中で情報システムとやり取りを行う窓口となるため、画面上で取扱う情報の種類、画面を構成する要素の配置は、利用者の業務効率や満足度に大きな影響を与えます。
この画面に関する要件を取りまとめるドキュメントは、一般的に画面一覧、画面イメージ（画面モックアップ）、画面遷移図、画面設計方針書（画面設計ポリシー）と呼ばれるもので構成されています。
画面一覧（例）
NO 1
画面ID XXXX
画面分類 新規ユーザー登録画面
画面名 新規ユーザー登録作成
画面概要 新規ユーザー登録の作成画面
画面入出力要件
表示方法:...
入力操作概要:...
画面設計要件 Webブラウザで表示可能であること。
該当機能 機能ID:XXXX
利用者区分 新規ユーザー登録者
NO 2
画面ID XXXX
画面分類
画面名 新規ユーザー登録確認
画面概要 新規ユーザー登録の作成確認画面
画面入出力要件
表示方法:...
入力操作概要:...
画面設計要件 ...
該当機能 機能ID:XXXX
利用者区分 新規ユーザー登録者
帳票に関する事項
情報システムの帳票とは、サービス・業務で使用するために情報システムから出力した紙やPDF形式などの電子帳票を指します。帳票は、利用者が業務上意識して用いられるものであるため、業務の内容やきっかけと結びついた重要な情報を持ちます。帳票に関する要件を取りまとめるドキュメントは、一般的に帳票一覧、帳票イメージ、帳票設計方針書（帳票設計ポリシー）と呼ばれるもので構成されています。
帳票一覧の例
NO 1
帳票ID XX
帳票名 〇〇申込書
帳票概要 〇〇申込
入出力の区分 出力
帳票入出力要件 モノクロ印刷
帳票設計要件 用紙サイズ:A4
入出力形式 紙
該当機能 機能ID:XX
利用者区分 〇〇申込者
NO 2
帳票ID XX
帳票名 △△申込書
帳票概要 △△申込
入出力の区分 出力
帳票入出力要件 カラー印刷
帳票設計要件 用紙サイズ:A4
入出力形式 PDF
該当機能 機能ID:XX
利用者区分 △△申込者
データに関する事項
情報システムで取扱うデータに関して機密性レベル別に分類し、その管理方法を定義しておく必要があります。システム内に存在することになるデータに関して、その機密性を認識し、分類し、またその管理方法を「データ要件」として記述することにより、その後の設計・開発作業に確実につなげていくことができます。データに関する要件を取りまとめる際には、データモデル、データ一覧、データ定義などのドキュメントを整備することが重要です。
データ要件を取りまとめる際に整備するドキュメント（例）
NO 1
ドキュメント名 データモデル
説明
● 画面や帳票などに含まれる情報を抜き出して、意味のある単位（識別キー）ごとにまとめた情報の集合体である「データ」と、他のデータとの関連を1枚に表現した図で、ER（Entity Relationship）図という表記法で記述します。
● 基本的に1つのデータ項目は、必ずどこか1ヶ所のデータのみに属するようにデータを定義します（これを「正規化」といいます）。
NO 2
ドキュメント名 データ一覧
説明
● データがどのようなまとまりの単位になっているかを一覧形式で示す表で、データモデルやデータ定義の目次として利用されます。
● マスターデータとマスターデータ以外に分け、データの用途や保存期間、データ件数などを定義します。
NO 3
ドキュメント名 データ定義
説明 ● データ一覧にあるデータのまとまり単位にそれぞれに含まれるデータ項目の内容・説明を示す表です。
外部インターフェースに関する事項
情報システムの外部インターフェースとは、サービス・業務の内容を実現するために、自分の情報システムが他の情報システムと連携して情報を受け渡す仕組みです。情報連携の内容や形式・仕組みにはさまざまなものがあり、明確に定義する必要がありますが、連携先である他の情報システムの都合もあるため、双方の要件を出し合い、すり合わせることが必要となります。この外部インターフェースに関する要件を取りまとめるドキュメントは、一般的に外部インターフェース一覧と呼ばれます。
外部インターフェース一覧（例）
NO 1
外部インターフェースID XXXX
外部インターフェース名 申込者情報連携
外部インターフェース概要 申込の審査に関わる申請者の情報を○○システムから日次で取得する
相手システム 〇〇システム
送受信区分 受信
実装方式 API
送受信データ 申込者情報
送受信タイミング リアルタイム
送受信の条件 日次
NO 2
外部インターフェースID XXXX
外部インターフェース名 申込結果連携
外部インターフェース概要 承認された申込情報を○○システムに日次で提供する。
相手システム 〇〇システム
送受信区分 送信
実装方式 ファイル共有
送受信データ 承認済み申込者情報
送受信タイミング リアルタイム
送受信の条件 日次
非機能要件として定義しないといけない内容は次に挙げる17の事項です。
非機能要件は、安定的なサービスの継続に重要です。
・ 情報セキュリティに関する事項
・ ユーザビリティおよびアクセシビリティに関する事項
・ システム方式に関する事項
・ 規模に関する事項
・ 性能に関する事項
・ 信頼性に関する事項
・ 拡張性に関する事項
・ 上位互換性に関する事項
・ 中立性に関する事項
・ 継続性に関する事項
・ 情報システム稼動環境に関する事項
・ テストに関する事項
・ 移行に関する事項
・ 引継ぎに関する事項
・ 教育に関する事項
・ 運用に関する事項
・ 保守に関する事項
機能要件の場合は、内容の一部を定義せず、調達時の事業者の提案に委ねることもあります。しかし、非機能要件の場合は基本的にすべての項目を定義します。情報システムやプロジェクトの特性によって、定義すべき内容の量は異なります。
情報セキュリティに関する事項
セキュリティに関する要件の決定は、適用宣言書をもとにして行います。セキュリティ要件を決める流れは以下の通りです。
1. 情報システムで取扱う情報資産に対して、リスクアセスメントを実施する。
2. リスクアセスメントの結果をもとに、必要な管理策を決定する。（適用宣言書の作成）
3. 適用宣言書の内容を満たすように、セキュリティ要件を決定する。
※ リスクアセスメントの実施方法の詳細については、「12-2.リスクマネジメント:リスクアセスメント」を参照してください。
ECサイトにおいて、セキュリティ要件を決める例
ステップ1:情報資産の特定
ECサイトで取扱う主な情報資産は以下の通りです。
【情報資産名】顧客情報
内容 氏名、住所、電話番号、メールアドレス、クレジットカード情報など
【情報資産名】注文情報
内容 商品名、購入日、購入金額など
【情報資産名】在庫情報
内容 商品の在庫数、入荷予定など
【情報資産名】支払い情報
内容 クレジットカード情報、銀行口座情報など
ステップ2:リスク特定
各情報資産に対する脅威と脆弱性を特定します。
【情報資産名】顧客情報
【情報資産名】注文情報
【情報資産名】在庫情報
【情報資産名】支払い情報
ステップ3:リスク分析
脅威と脆弱性がもたらすリスクを評価し、リスクレベルを「高」「中」「低」に分類します。
【情報資産名】顧客情報の漏えい
リスクレベル 高
【情報資産名】注文情報の改ざん
リスクレベル 中
【情報資産名】在庫情報の誤った更新
リスクレベル 中
【情報資産名】支払い情報の盗難
リスクレベル 高
ステップ4:リスク評価
リスク分析の結果をもとに、リスクの優先順位を決定し、それに対する対応策（リスク軽減、リスク回避、リスク受容など）を検討します。
リスクアセスメントの結果に基づいて、管理策を導入する適用宣言書を作成します。
※管理策は、ISMSの管理策だけでなくCSF2.0の管理策も参考にできます。CSF2.0の管理策については、「付録:CSF2.0」を参照してください。
【情報資産】顧客情報（氏名、住所、電話番号、メールアドレス、クレジットカード情報）
リスク内容 不正アクセスによる個人情報の漏えい
リスクレベル 高
適用する管理策
情報セキュリティのための方針群（5.1）
個人情報の取扱いに関する方針を策定し、従業員に周知。
アクセス制御（5.15）
顧客情報へのアクセス権を最小限に制限。
暗号の利用（8.24）
顧客情報を保存時・転送時に暗号化。
【情報資産】注文情報（商品名、購入日、購入金額など）
リスク内容 不正なデータ改ざんや漏えい
リスクレベル 中
適用する管理策
アクセス制御（5.15）
注文情報へのアクセスを業務上必要な従業員に限定。
情報セキュリティインシデント管理の計画策定および準備（5.24）
注文情報の改ざんや漏えいが発生した場合の対応手順を整備。
【情報資産】在庫情報（商品在庫数、入荷予定など）
リスク内容 内部関係者による不正なアクセス
リスクレベル 中
適用する管理策
情報セキュリティの意識向上、教育および訓練（6.3）
従業員に対するセキュリティ教育を実施し、在庫情報の取扱いに関するリスクを軽減。
アクセス制御（5.15）
在庫情報システムへのアクセスを制限。
【情報資産】支払い情報（クレジットカード情報、銀行口座情報）
リスク内容 クレジットカード情報や銀行口座情報の盗難・不正利用
リスクレベル 高
適用する管理策
暗号の利用（8.24）
支払い情報は保存時および転送時に暗号化。
アクセス制御（5.15）
支払い情報へのアクセスを厳格に制限。
ログ取得（8.15）
支払い情報に関する操作の記録を保護し、監視を実施。
適用宣言書を満たすためのセキュリティ要件を定義します。
セキュリティに関する要件定義の例
1.セキュリティ要件
1.1 顧客情報の保護
要件 1.1.1:顧客情報（氏名、住所、電話番号、メールアドレス、クレジットカード情報）は、すべて暗号化技術を用いて保存および転送すること。
要件 1.1.2:顧客情報へのアクセスは、役割ベースで制限し、必要な従業員のみに許可すること。アクセス権は定期的にレビューし、不要な権限は削除すること。
要件 1.1.3:顧客情報の取扱いに関するセキュリティポリシーを文書化し、全従業員に周知すること。ポリシーの順守状況を定期的に監査すること。
1.2 注文情報の保護
要件 1.2.1:注文情報（商品名、購入日、購入金額）は、適切なアクセス制御により保護し、業務上必要な従業員のみがアクセスできること。
要件 1.2.2:注文情報の改ざんや漏えいが発生した場合のインシデント対応手順を整備し、インシデントの発生時には即座に対応できる体制を構築すること。
1.3 在庫情報の保護
要件
1.3.1:在庫情報（商品在庫数、入荷予定など）へのアクセスは、必要最低限の従業員のみに制限すること。アクセス制御リストは定期的に見直し、不要なアクセス権は削除すること。
要件
1.3.2:在庫情報に関するセキュリティ教育を実施し、従業員が適切に情報を取扱うようにすること。教育内容には、在庫情報の重要性とリスクについても含めること。
1.4 支払い情報の保護
要件 1.4.1:支払い情報（クレジットカード情報、銀行口座情報）は、保存時および転送時に暗号化技術を用いて保護すること。
要件 1.4.2:支払い情報へのアクセスは、業務上必要な従業員に限定し、アクセス権は厳格に管理すること。アクセスログは定期的にレビューすること。
要件 1.4.3:支払い情報に関する操作ログを記録し、改ざんや削除を防ぐための保護を施すこと。ログの保管には、セキュアなストレージを使用し、バックアップを定期的に取得すること。
2.可用性要件
2.1 システムの高可用性
要件 2.1.1:システムは24時間365日稼動し続けること。メンテナンスやアップグレード時には、事前に計画を立て、影響を最小限に抑えること。
要件 2.1.2:システム障害発生時の迅速な復旧を支援するために、定期的なバックアップを実施し、災害復旧計画を策定すること。
3.パフォーマンス要件
3.1 応答時間
要件 3.1.1:ユーザーからの要求に対する応答時間は、システムの種類に応じて以下の基準を満たすこと。
Webページの表示:3秒以内
データベースクエリの実行:2秒以内
4.コンプライアンス要件
4.1 法令順守
要件 4.1.1:個人情報保護法、クレジットカード業界の規制、電子商取引に関する規制など、関連する法令や規制を順守するためのプロセスを確立し、定期的な監査を実施すること。
ECサイトの構築時におけるセキュリティ対策要件
IPAが公開している「ECサイト構築・運用セキュリティガイドライン」では、ECサイトの構築時におけるセキュリティ対策要件を示しています。要件ごとに求められるセキュリティの水準に応じて、「必須」、「必要」、「推奨」を定め、それぞれ表中の区分に表記しています。
「必須」は、ECサイト運営事業者がECサイトのセキュリティを確保する上で早急かつ確実な対策実施が求められるものであり、実装が必須として求められる内容と定義しています。
「必要」は、事業の重要度、対策費用、対策までの期間、対策を実施しないことによる影響度など、または他の代替策を実施するなどを考慮して導入時期を検討した上で実装が求められる内容と定義しています。
「推奨」は、ECサイト運営事業者がサイバー被害を受けるリスクの低減、被害範囲の拡大防止、ECサイトを復旧する場合において、対策実施が求められるものであり、事業の重要度、影響度などを考慮した上で、ECサイト運営事業者が各自の責任において、その実装を検討すべき内容と定義しています。
「必須」の要件については必ず実装することが重要ですが、「必要」、「推奨」の要件ついては、自社の適用宣言書に基づき、実装を検討することが大切です。
要件1
セキュリティ対策要件（構築時） 「安全なウェブサイトの作り方」および「セキュリティ実装チェックリスト」に準拠して、ECサイトを構築する。
区分 必須
要件2
セキュリティ対策要件（構築時） サーバおよび管理端末などで利用しているソフトウェアをセキュリティパッチなどにより最新の状態にする。
区分 必須
要件3
要件4
セキュリティ対策要件（構築時） 管理者画面や管理用ソフトウェアへ接続する端末を制限する。
区分 必須
要件5
セキュリティ対策要件（構築時） 管理者画面や管理用ソフトウェアへ接続する端末のセキュリティ対策を実施する。
区分 必須
要件6
セキュリティ対策要件（構築時） クレジット取引セキュリティ対策協議会が作成する「クレジットカード・セキュリティガイドライン」を順守する。
区分 必須
要件7
セキュリティ対策要件（構築時） サイト利用者情報の登録時およびパスワード入力時における、不正ログイン対策を実施する。
区分 必須
要件8
セキュリティ対策要件（構築時） サイト利用者の個人情報に対して安全管理措置を講じる。
区分 必須
要件9
セキュリティ対策要件（構築時） ドメイン名の正当性証明とTLSの利用を行う。
区分 必須
要件10
セキュリティ対策要件（構築時） サイト利用者のログイン時における二要素認証を導入する。
区分 必要
要件11
セキュリティ対策要件（構築時） サイト利用者のパスワードの初期化および変更といった重要な処理を行う際、サイト利用者へ通知する機能を導入する。
区分 必要
要件12
セキュリティ対策要件（構築時） WebサーバやWebアプリケーションなどのログや、取引データなどのバックアップデータを保管する。
区分 必要
要件13
セキュリティ対策要件（構築時） 保管するログやバックアップデータを保護する。
区分 推奨
要件14
セキュリティ対策要件（構築時） サーバおよび管理端末において、セキュリティ対策を実施する。
区分 推奨
ECサイトの構築時におけるセキュリティ対策要件一覧
（出典）IPA「ECサイト構築・運用セキュリティガイドライン」をもとに作成
「詳細理解のため参考となる文献（参考文献）」に掲げた「安全なウェブサイトの作り方」および「セキュリティ実装チェックリスト」では、「ウェブアプリケーションのセキュリティ実装」として、「脆弱性関連情報の届出制度」で届出の多かったものや攻撃による影響度が大きい脆弱性である、SQLインジェクション、OSコマンド・インジェクションやクロスサイト・スクリプティングなど11種類の脆弱性を取り上げています。それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴などを解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。
また、「ウェブサイトの安全性向上のための取組」として、ウェブサーバのセキュリティ対策やフィッシング詐欺を助⻑しないための対策など7つの項目を取り上げています。主に運用面からウェブサイト全体の安全性を向上させるための方策を示していますので、IPAの「ECサイト構築・運用セキュリティガイドライン」を参考にしてECサイトを構築してください。
なお、ECサイトの構築を委託する場合は、外部委託先事業者にガイドラインを参考にして構築することを依頼してください。
ECサイトを構築する場合、次のように利用しているソフトウェアへの脆弱性対策を実施することが重要です。
・ 脆弱性情報などセキュリティに関連する情報を公表しているECサイト構築プログラムを選定してください。
・ ECサイトを構成するソフトウェア（サーバと管理端末のOS、ミドルウェアとライブラリ、または、Webアプリケーションなど）を確認の上、一覧にまとめ、それぞれのソフトウェアに関する脆弱性情報などセキュリティに関連する情報を収集して管理し、それらの情報の内容を把握してください。
・ ECサイトの構築時に利用しているサーバおよび管理端末のOS、ミドルウェアおよびライブラリ、または、WebアプリケーションやOSSなどのソフトウェアについては、その時点の最新バージョンを使用してください。
・ 利用しているソフトウェアなどについて、脆弱性情報を収集し、脆弱性の危険度が「高」の脆弱性については迅速に、危険度「中」は公開までにセキュリティパッチの適用や最新版へのバージョンアップによるアップデートを実施してください。アップデート実施後は、アップデートによりシステムへの影響がないことを確認（動作検証）してください。それ以外の脆弱性については、セキュリティパッチの適用や最新版へのバージョンアップを行うか否かを、脆弱性によるシステムへの影響などを考慮して判断してください。
ECサイトを新規に構築した際は、ECサイトを公開するまでに脆弱性対策を実施する期間を確保して、次のような第三者によるECサイトへの脆弱性診断を実施して、ECサイトに脆弱性がないかを確認し、発見された危険度「高」、「中」の脆弱性への対策を行った上で公開してください。
・ 脆弱性診断は、原則、第三者（外部委託先事業者、自社以外の第三者）による脆弱性診断を実施し、実施する脆弱性診断は、プラットフォーム診断、Webアプリケーション診断の2種類を実施してください。
・ Webアプリケーション診断の実施範囲は、最低でも以下の画面について脆弱性診断を実施してください。
▶ ログイン画面
▶ サイト利用者情報登録/変更画面
▶ 商品検索画
▶ 注文・決済画面など
・脆弱性診断を第三者に依頼する場合は、IPAが公開している「情報セキュリティサービス基準適合サービスリスト」にある「脆弱性診断サービス」に記載されている事業者を選定することを推奨します。
・脆弱性診断の診断結果として、実害に至る攻撃難易度を考慮した危険度は、一般的に「高」、「中」、「低」の3段階で分類されており、危険度「高」、「中」については、対策を行った上でECサイトを公開してください。
脆弱性診断を実施する上で参考にしていただきたいこと
【脆弱性診断の目的】
脆弱性診断は、ECサイトがサイバー攻撃を受けて被害をまねく元となる脆弱性が存在していないかを調べるために行う、とても重要で必要な工程です。もし脆弱性が見つかった場合、脆弱性によるECサイトへの影響度を確認する必要があります。見つかった脆弱性の危険度および、脆弱性によるECサイトへの影響度により、対応の要否を判断して、対応をすることが重要です。
【脆弱性診断の種類】
脆弱性診断は、診断対象、診断方法によって、以下のものがあります。
<診断対象>
● プラットフォーム診断:サーバやネットワーク機器などのOSやミドルウェアを診断します。
● Webアプリケーション診断:Webサーバ上で動作するアプリケーションを診断します。
<診断方法>
● ツールによる診断:ツールにより自動で診断します。ツールによって診断できる範囲が異なります。（ツールには無償のものと有償のものがあります。）
● 手動による診断:人手により診断します。
● ハイブリッド診断:ツールでの診断が難しい箇所（人による判断が必要な場合）を人手で行うといった両者を組み合わせて診断します。
※手動による診断は、ツールによる診断に比べて費用が高額となります。手動による診断は、ツールでは見つけられない脆弱性を発見でき、ツールによる診断と組み合わせることで結果として精度の高い診断が可能です。
【脆弱性診断の実施者】
ツールで自動的に診断できる部分があるとはいえ、ツールの使用や診断結果を判断するため、脆弱性診断を行う人はそれなりのスキルが必要になります。自社に脆弱性診断を実施する技術者がいない場合は、脆弱性診断サービスの利用を検討することが重要です。
管理者画面や管理用ソフトウェアにアクセスするためのID・パスワードが攻撃者に漏えいすると、サイト利用者の顧客情報や、注文・取引データなどが大量に漏えいすることにつながるおそれがあるため、次のように厳重に管理することが重要です。
・
管理者画面や管理用ソフトウェアにアクセスするためのID・パスワードが不正に取得された場合に備えて、アクセスできる端末を制限するためのIPアドレス接続制限や、アクセスできる利用者を制限するために、二要素認証（IDとパスワードによる認証後にSMS（ショートメッセージサービス）などでの認証を行う方法）を導入してください。
管理者画面や管理用ソフトウェアへのアクセスに用いる端末がマルウェアに感染すると、端末内部および、当該端末がアクセス可能なサーバなどに保管しているサイト利用者の顧客情報や、注文・取引データなどが外部に送信されるおそれがあります。アクセスする端末に対して、マルウェア対策ソフトウェアを導入し、リアルタイム検知の実施および、定義ファイルの更新、端末のフルスキャンなどの定期的（1回/日を推奨）な実施や、USBメモリなど外部記憶媒体の利用制限を通じて、マルウェア感染防止対策を行うことが重要です。
クレジットカード決済を提供する場合には、割賦販売法におけるセキュリティ要求事項を反映した、クレジット取引セキュリティ対策協議会が作成する「クレジットカード・セキュリティガイドライン」（カード情報の非保持化、カード決済のEMV 3Dセキュアの導入など）を順守するとともに、契約するクレジットカード会社および決済代行会社（PSP）とコミュニケーションを取り、常に最新のセキュリティ対策の実施を検討してください。
サイト利用者のパスワードが攻撃者に漏えいすると、サイト利用者の個人情報や、注文・取引データなどの漏えいにつながるおそれがあるため、次のような不正ログイン対策を実施することが重要です。
・
サイト利用者がパスワードを登録する際に10文字以上、英大文字と小文字、数字、記号を組み合わせて、推測困難なパスワードを登録するようにしてください。また、推測されやすいパスワードは登録できないようにすることが重要です。
・
ログイン用のIDとパスワードのすべてのパターンを機械的に繰り返し入力し、ECサイト利用者のIDとパスワードを盗み出すという総当たり攻撃に備えて、パスワードなどの入力間違いの回数が一定数（10回以下を推奨）を超えた場合はアカウントをロックするようにしてください。
個人情報保護法第二十三条（安全管理措置）に基づき、ECサイトの運用を通じて取扱う個人データの漏えい、滅失または毀損の防止その他の個人データの安全管理のために必要かつ適切な措置（個人データの取扱規定の整備、個人データを保存するシステム、機器および電子媒体の盗難、漏えいの防止、システム、機器へのアクセス制御、不正アクセス防止など）を講じる必要があります。
ECサイト利用者がIDとパスワードを不正に窃取するフィッシングサイトではないこと（正規のサイトであること）を確認できるようにするためには、TLS/SSL証明書などを導入し正当性証明を行うこと、およびTLS（Transport Layer Security）の利用により通信を暗号化することが重要です。
なりすましなどによる不正ログインが行われる可能性が高い（ある）と判断した場合には、IDとパスワードを用いたサイト利用者の認証に加えて、安全性を高められる二要素認証（IDとパスワードによる認証後にSMSなどでの認証を行う方法）を導入します。
正規サイトを装ったフィッシングサイトや、パスワードの変更などを行うように不正に誘導するフィッシングメールにだまされて、サイト利用者が気づかないうちにIDとパスワードを盗まれることがあります。そのため、なりすまされて登録情報を変更されたことにサイト利用者が気づくことができるようにするために、ECサイト利用者のメールアドレスの登録および変更、パスワードの初期化および変更、アカウントの登録および削除、決済処理時といった重要な処理を実行した際に、メールやSMSなどを用いて、サイト利用者への通知を行うようにします。
顧客情報の漏えい事故を発生させてしまった場合には、事故の原因究明のためにフォレンジック調査会社に依頼します。フォレンジック調査で原因究明を徹底的に行うためには、調査に必要なデータが十分に揃っていることが必要となるため、WebサーバやWebアプリケーションのログや、取引データなどのバックアップデータ（該当サーバ以外の外部ストレージサービスや、自社管理のサーバへの保管など）を過去1年間分以上保管しておくようにしましょう。
フォレンジック調査の依頼先は、IPAが公開している「情報セキュリティサービス基準適合サービスリスト」にある、「デジタルフォレンジックサービス」に記載されている事業者を参考にすると良いでしょう。
また、レンタルサーバ事業者を利用する場合は、Webサーバのアクセスログなどの保管および提供が可能な事業者を選ぶようにしましょう。
WebサーバのログおよびWebアプリケーションのログ、取引データなどのバックアップデータを過去1年間分以上保管していても、保管ログおよびデータへの不正アクセスがあれば、前述したフォレンジック調査による原因究明に支障が生じ、誤った結果が導かれるおそれがあります。このため、ログ出力機能、保管されるログ、バックアップ機能、保管されるバックアップデータに対して、不正アクセスができないような対策を実施する必要があります。
サーバおよび管理端末自体がマルウェアに感染すると、サーバや管理端末内部に保管しているサイト利用者の顧客情報や、注文・取引データなどが外部に送信されるおそれがあるため、マルウェア対策ソフトウェアを導入し、リアルタイム検知の実施および、定義ファイルの更新、ファイル・メモリのスキャンなどの定期的（1回/日を推奨）な実施や、USBメモリなど外部記憶媒体の利用制限を通じて、マルウェア感染防止対策を行うことが必要です。
ECサイトの構築時に有効なCSF2.0の管理策（例）
セキュリティ対策の要件を決める際は、CSF2.0の管理策を参考にすることも有効です。
有効な管理策の例
パッチ適用に関する管理策
・
GV.SC-09:サプライチェーンセキュリティの実践が、サイバーセキュリティと企業のリスク管理プログラムに統合され、そのパフォーマンスが技術製品とサービスのライフサイクル全体を通じて監視される。
・ ID.RA-01:資産の脆弱性を特定、検証、記録する。
・ PR.AT-01:要員は、サイバーセキュリティリスクを念頭において一般的な業務を遂行するための知識と技能を有するよう、意識向上とトレーニングを受ける。
・ PR.PS-02:ソフトウェアはリスクに見合った保守、交換、削除が行われる。など
認証に関する管理策
・ PR.AA-01:許可されたユーザー、サービス、およびハードウェアのIDとクレデンシャルが組織によって管理される。
・ PR.AA-03:ユーザー、サービス、ハードウェアを認証する。など
バックアップに関する管理策
・ PR.DS-11:データのバックアップが作成、保護、維持、およびテストされる。
・ RC.RP-03:バックアップやそのほかのリストア資産をリストアに使用する前に、その完全性を検証する。など
※各管理策の詳細は、「付録:CSF2.0」を参照してください。
ユーザビリティおよびアクセシビリティに関する事項
ユーザビリティとは、利用者がサービス・業務を利用して実施したいことを、ミスなく効率的に行うために必要となる事項であり、アクセシビリティは、目的の情報へのたどり着きやすさを指します。どちらも利用者の年齢、身体的制約、利用環境などの違いによる配慮が必要です。
ECサイト構築におけるユーザビリティの要件（例）
NO 1
ユーザビリティ分類 画面の構成（直観・シンプル）
ユーザビリティ要件
● 利用者が何をすれば良いか直感的に理解できるデザインにすること。
● 無駄な情報、凝ったデザイン、不要な機能を排したシンプルでわかりやすい画面にすること。
NO 2
ユーザビリティ分類 画面の構成（フォントおよび文字サイズ）
ユーザビリティ要件
● 十分な視認性のあるフォントおよび文字サイズを使用すること。
● 画面サイズや位置を変更できること。
● 一度に膨大な情報を提示して利用者を圧倒しないようにすること。
NO 3
ユーザビリティ分類 画面の構成（マルチデバイス対応）
ユーザビリティ要件
● スマートフォン、タブレット端末により本サービスを利用する利用者を想定し、これら端末の特性を考慮した画面にすること。
● レスポンシブWebデザインにより、PC、タブレット端末、スマートフォンなどの利用環境を問わず、同一の情報をグリッドレイアウトなどの適切なレイアウトにより表示できるようにすること。
NO 4
ユーザビリティ分類 画面遷移
ユーザビリティ要件
● 利用者が次の処理を想像しやすい画面遷移とすること。
● 無駄な画面遷移を排除し、シンプルな操作とすること。
ECサイト構築におけるアクセシビリティの要件（例）
NO 1
アクセシビリティ分類 言語対応
アクセシビリティ要件 本情報システムでは、日本語のほか、XX語で記載されたコンテンツに対応すること
システム方式に関する事項
「システム方式」では、定義された業務要件のうち、情報システムが処理・実行する範囲について、情報システムとして動作するために必要となる「道具」の具体的な実現方法を明確にします。
ECサイト構築におけるシステム方式に関する事項（例）
NO 1
全体方針の分類 システムアーキテクチャ
全体方針 本情報システムのシステムアーキテクチャは、【メインフレーム型/クライアントサーバ型/Webサーバ型/外部サービス利用型/スタンドアロン型】とする
NO 2
全体方針の分類 アプリケーションプログラムの設計方針
全体方針 情報システムを構成する各コンポーネント（ソフトウェアの機能を特定単位で分割したまとまり）間の疎結合、再利用性の確保を基本とする
NO 3
全体方針の分類 ソフトウェア製品の活用方針
全体方針
広く市場に流通し、利用実績を十分に有するソフトウェア製品を活用する
アプリケーションプログラムの動作、性能などに支障をきたさない範囲において、可能な限りオープンソースソフトウェア（OSS）製品（ソースコードが無償で公開され、改良や再配布を行うことが誰に対しても許可されているソフトウェア製品）の活用を図る。ただし、それらのOSS製品のサポートが確実に継続されていることを確認しなければならない
NO 4
全体方針の分類 システム基盤の方針
全体方針 クラウドサービス提供者が提供するサービス・機能を最大限活用した構成とする
規模に関する事項
「規模」とは、情報システムを使うユーザーの数や取扱う情報量を指します。利用者が多ければ単位時間当たりで多くのリクエストを処理できる能力が必要となりますし、情報量が多ければ、より大容量のデータベースなどが必要になります。要件定義では「利用者は最大100人、平日は常時80人、土日は基本的に休みのため10人未満」といった要件を定量的に示します。
ECサイト構築における利用者数に関する事項（例）
NO 1
ユーザー区分 想定ユーザー（アクティブユーザー）
ユーザー数 5000（人）
ECサイト構築における情報量に関する事項（例）
NO 1
項目 業務処理件数（ピーク時）
処理件数 300（件/分）
補足 1月1日から1月3日ごろまで、初売りセールのため処理が集中する
NO 2
項目 業務処理件数（通常時）
処理件数 120（件/分）
補足 平日は80（件/分）、土日祝日は100（件/分）
性能に関する事項
「性能」とは、情報システムの能力を指します。能力を測る指標には、応答性能やスループット（処理性能）などがあります。ネットショッピングで例えると、商品を検索し検索結果のリストが表示され、特定の商品を選択すると詳細情報が表示される、という一連の流れが一般的ですが、検索ボタンや選択ボタンを押してから、次の画面が表示されるまでの時間が応答性能です。スループットは、一度にどれだけの量を処理できるかという性能で、通常時でも大量に注文が発生するバーゲンセール開催中でも、定義した応答性能が担保されるということを表します
ECサイト構築における応答性能の事項（例）
NO 1
指標名 参照系処理
目標値 3秒
補足 画面の読み込み、情報の表示に関する処理
NO 2
指標名 更新系処理
目標値 5秒
補足 情報の登録、更新、削除に関する処理
ECサイト構築における処理性能に関する事項（例）
NO 1
設定対象 〇〇処理
指標名 レスポンスタイム
目標値
定常時:X秒以内
ピーク時:X秒以内
応答時間達成率 90%
NO 2
設定対象 〇〇処理
指標名 ターンアラウンドタイム
目標値
定常時:X秒以内
ピーク時:X秒以内
応答時間達成率 90%
NO 3
設定対象 〇〇処理
指標名 サーバ処理時間
目標値
定常時:X秒以内
ピーク時:X秒以内
応答時間達成率 平均値
信頼性に関する事項
「信頼性」とは、情報システムが持つ故障への耐性の度合いのことを指します。一般的には平均故障間隔（分または時間）で評価します。平均故障間隔の値が小さければ小さいほど信頼性は高いといえます。
ECサイト構築における信頼性に関する事項（例）
NO 1
指標名 運用時間
目標値
24時間
365日
補足
以下に該当する時間を除く。
● 接続回線の計画停止時間
● 大規模災害などの天災地変に起因する停止時間
● 連携するサービスまたはクラウドサービスまたはスマートフォン端末の通信キャリアの障害・計画停止・緊急メンテナンスなどに起因する停止時間
● 本サービスのメンテナンスによる計画停止時間
NO 2
指標名 稼動率
目標値 99.9%以上
補足
本サービスにおける稼動率を以下の計算式により定義する。
稼動率=年間実稼動時間/年間予定稼動時間x100
当該計算式において、年間実稼動時間は「利用者がサービスを利用可能な時間の合計」、年間予定稼動時間は「年間稼動時間（24時間365日）から計画停止時間および大規模災害による停止・縮退時間を除いた時間の合計」とする。
拡張性に関する事項
「拡張性」とは、利用率の増加、データ量の増加などにより、利用資源の規模・性能を拡張する必要が生じた場合に備え、可能な限り性能の拡張を柔軟に行えるよう、設計・開発を行うことです。また、将来の制度改正などにより機能を拡張する必要が生じた場合に備え、容易に機能追加・変更を行えるよう、設計・開発を行うことも指します。
ECサイト構築における拡張性に関する事項（例）
基本方針
本システムの利用率の増加、データ量の増加などにより、規模・性能を拡張する必要が生じた場合に備え、可能な限り性能の拡張を柔軟に行えるよう、設計・開発を行うこと。また、将来の制度改正などにより機能を拡張する必要が生じた場合に備え、容易に機能追加・変更を行えるよう、設計・開発を行うこと。
マネージドサービスなどの活用
本サービスはクラウドサービスを利用する想定としている。本サービスの構築に当たっては、当該クラウドサービスをマネージドサービスなど可能な限り活用することにより、処理能力などの動的調整を実現することにし、業務量および処理能力の拡張性については特段の拡張性要件を定義しない。
機能の追加
機能の追加や、新たな機能開発の必要が生じることが想定されることから、将来開発する機能も含めた機能間の連携が十分に図られるようにすること。
本サービスは、連携業務アプリケーションとの一層の連携など、拡張性を備えたシステム・サービスであることが求められる。連携機能などの拡張が必要になった際に拡張が容易となるような構成を取ること。
上位互換性に関する事項
「上位互換性」とは、主にソフトウェア製品において、新しいバージョンの製品で古いバージョンの製品が利用できることを指します。代表的な製品は上位互換性がありますが、バージョンアップに伴い、レイアウトが崩れたり、ブラウザの場合画面のレイアウトや特定のボタンが動作しなくなったりといった、一部の機能に限り上位互換性がないこともあります。
ECサイト構築における上位互換性に関する事項（例）
クラウドサービスのバージョンアップ
システムの構成にクラウドサービスのマネージドサービスを採用する場合、軽微なバージョンアップについては自動適用を前提とする。大規模なバージョンアップについては、アプリケーションへの影響を事前に精査し、適用を検討すること。
OSなどへの依存
原則特定バージョンへの依存は避けること。なお、やむを得ずOS、ミドルウェアなどの特定バージョンに依存する場合は、その利用を最低限とすること。
クライアント端末の更新
クライアント端末が更新され、OSやWebブラウザとして新しいバージョンのものを利用する場合も、業務運営に極力支障が生じないよう計画されたシステム構成とすること。
中立性に関する事項
「中立性」とは、情報システムを構成する要素が、特定の技術や製品に特化しないことを指します。例えば、新規に情報システムを構築する際に、ある事業者が開発・販売している製品を利用しなければ運用・保守ができない構成にしたとします。その後、運用・保守業務を一般競争入札で調達しようとしても他の事業者ではその製品を入手できないなどの理由により、その製品を導入した事業者による一者応札となってしまいます。このような状態になることを防ぐために、特定の事業者の技術に依存せず、多くの事業者が扱える製品を採用するなど、中立性への配慮が必要です。
ECサイト構築における中立性に関する事項（例）
データの可搬性の担保
データの可搬性の担保に当たっては、以下の要件を満たすこと。
・ 情報システム内のデータについては、原則としてXMLやCSVなどの標準的な形式で取り出すことができるものとすること。
・ 技術的な理由により、提供することが難しいデータ項目がある場合には、代替案を提示することが可能であること。
・ 移行用データが満たすべき制約（移行データのデータフォーマットやスキーマなどの要件も含む）を文書化すること。文書については、情報システムの業務要件を理解しているユーザーであれば理解できるように記述すること。なお、システム運用期間中に該当文書の内容に変更が生じる場合は継続して改定を行い最新化できること。
・ 移行データに関する文字コードなどは以下に従うこと。
▶ 取扱う日本語文字集合の範囲:JIS X 0213
▶ 文字コード:ISO/IEC 10646
▶ 文字の符号化形式:UTF-8
継続性に関する事項
「継続性」では、当該情報システムを構成する要素（サブシステム、サービスなど）に分解し、情報システム全体での目標復旧時間を踏まえて、各要素の継続性に係る指標や目標値を要件として示します。
クラウドサービスとオンプレミスは継続方法の確保方法が異なります。クラウドサービスを利用する場合には、オンプレミスのように別途保管する必要はなく、クラウドサービス提供者が提供するバックアップサービスを利用すれば良いと考えられます。ただし、バックアップサービスにはさまざまな種類が存在することに鑑み、選択する手法が妥当なものであることを確認しておきましょう。
ECサイト構築における継続性に関する事項（例）
データバックアップ
● バックアップ対象
データバックアップに当たっては、本サービスの稼動に必要な全データを復旧可能とすることを前提として、外部組織から再入手可能なデータの有無を含め、保全対象を精査し、復旧時に必要となるデータを過不足なく保全対象に含めることができるようにすること。なお、クラウドサービスのマネージドサービスを利用することで自動的にバックアップを取得できる部分はあるが、オペレーションミスやアプリケーションのバグなどに起因するデータ破壊に対しても破壊前の時点まで遡れるように、バックアップの実施方法について配慮すること。
● バックアップ頻度
バックアップの取得間隔は、原則日次とする。ただし、障害発生時点への復旧が必要なデータについては、復旧に用いるPITR:Point In Time Recovery/Restoreを保存するなどの対応を行うこと。
● 保存期間
万一の障害発生に備え本サービスの稼動に必要な全データを復旧可能とするとともに、過去のシステム処理に問題が発生した場合に原因分析を可能とすることを目的として、日次のバックアップについては、30日分のデータをバックアップとして保持すること。
情報システム稼動環境に関する事項
「情報システム稼動環境」とは、当該情報システムに係る、クラウドサービスの構成、ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件などを明らかにすることを指します。稼動環境には、運用、保守、研修、検証などに必要な環境も含めます。
ECサイト構築における情報システム稼動環境に関する事項（例）
動作保証対象とする利用端末
NO 1
端末：PC
OS：〜
バージョン：Ver○○
NO …
端末：…
OS：…
バージョン：…
動作保証の対象とするブラウザ
・ PCの場合：○○ブラウザの最新バージョン
・ スマートフォンの場合：□□ブラウザの最新バージョン
・ タブレット端末の場合：△△ブラウザの最新バージョン
※動作保証の対象とするOSやブラウザは、想定される利用者に合わせて決定する必要があります。動作保証対象とするOSやブラウザの種類を絞りすぎると、アクセスできない利用者から不満が出る可能性があります。想定される利用者をできるだけ広くカバーできるように動作保証対象を設定することが重要です。
テストに関する事項
情報システムのテストには、ソフトウェアの設計に基づいて事業者が行うテストと、発注者および情報システムの利用者の視点で行うテストが存在します。テストに関する要件には、実施するテストの内容や方法、環境などを示します。
ECサイト構築におけるテストに関する事項（例）
NO 1
テスト工程 単体テスト
テストの目的・内容 アプリケーションを構成する最小の単位で実施するテストであり、主に機能単位で設計通りに動作するかを事業者（プログラマ）が確認する。
テスト環境 開発環境
テストデータ テスト用に作成したデータ
テスト実施主体 事業主
NO 2
テスト工程 結合テスト
テストの目的・内容 複数の機能を連携させて動作を確認するテストであり、主にユースケース単位で設計通りに動作するかをテスト担当者が確認する。
テスト環境 検証環境
テストデータ テスト用に作成したデータ
テスト実施主体 事業主
NO 3
テスト工程 総合テスト
テストの目的・内容 システム全体が設計の通りに動作することを確認するテストであり、ユースケースを組み合わせた一連の業務が行えることを機能面や非機能面の観点からテスト担当者が確認する。
テスト環境 検証環境
テストデータ テスト用に作成したデータ、または本番データから作成した疑似データ
テスト実施主体 事業主
NO 4
テスト工程 受入テスト
テストの目的・内容 納品されるシステムが要件通りに動作することを確認するテストであり、発注者が主体となり、事業者と協力して確認する。
テスト環境 検証または本番環境
テストデータ 本番データ、または本番データから作成した疑似データ
テスト実施主体 事業主
移行に関する事項
移行には、データ移行、システム移行および業務運用移行の3つの要素があります。業務の安定的な継続が最重要課題であるため、移行の各ステップにおいて状況を評価し、最悪の場合でも既存の情報システムへ切り戻せるような計画と、プロセスの準備を要求しておくことが必要です。
移行に向けた作業手順および役割分担（例）
NO 1
作業名 移行計画の作成
主管部 承認者
工程管理支援業者 確認者
現行システム運用保守事業者 支援者
次期システム設計開発事業者 主体者
NO 2
作業名 移行データ準備・提供
主管部 主体者・承認者
工程管理支援業者 確認者
現行システム運用保守事業者 主体者
次期システム設計開発事業者 支援者
NO 3
作業名 移行データ分析
主管部 承認者
工程管理支援業者 確認者
現行システム運用保守事業者 支援者
次期システム設計開発事業者 主体者
NO 4
作業名 移行設計
主管部 承認者
工程管理支援業者 確認者
現行システム運用保守事業者 なし
次期システム設計開発事業者 主体者
NO 5
作業名 データ移行サーバ・ツール開発
主管部 承認者
工程管理支援業者 確認者
現行システム運用保守事業者 なし
次期システム設計開発事業者 主体者
NO 6
作業名 移行リハーサル
主管部 承認者
工程管理支援業者 確認者
現行システム運用保守事業者 支援者
次期システム設計開発事業者 主体者
NO 7
作業名 移行判定
主管部 主体者・承認者
工程管理支援業者 確認者
現行システム運用保守事業者 なし
次期システム設計開発事業者 主体者
NO 8
作業名 本番移行
主管部 承認者
工程管理支援業者 確認者
現行システム運用保守事業者 支援者
次期システム設計開発事業者 主体者
NO 9
作業名 稼動判定
主管部 主体者・承認者
工程管理支援業者 確認者
現行システム運用保守事業者 なし
次期システム設計開発事業者 主体者
ECサイト構築における移行対象データ（例）
NO 1
移行元 商品情報
移行対象業務 商品テーブル
件数 XX
提供方法 CSV形式での提供
NO 2
移行元 商品情報
移行対象業務 新規登録ファイル
件数 XX
提供方法 CSV形式での提供
NO 3
移行元 商品情報
移行対象業務 商品情報
件数 XX
提供方法 CSV形式での提供
引継ぎに関する事項
情報システムの構築およびテストが完了し本番運用に移行する際、または年度の節目などで事業者や要員が交代する場合、円滑な業務運営を維持するためには、あらかじめ引継ぎ項目を整理し、想定しておくことが重要です。現在その作業を担当している事業者を「引継ぎ元」と定義し、その事業者が担当している作業を「引継ぎ内容」として明らかにします。基本的には事業者ごとに作業・成果物などを定義した契約が存在しているため、その内容をもとに整理すると効率的です。引継ぎ期間は1ヶ月程度を設定することが一般的ですが、十分ではないケースが多く見られます。引継ぎ期間が十分でない場合には、他の事業者が参入できなかったり、その後の業務運営に支障が生じたりするおそれがあるため、十分な期間を確保することが重要です。
ECサイト構築における引継ぎ事項（例）
NO 1
引継ぎ期間 令和〇年〇月〇日〜令和〇年〇月〇日
引継ぎ先 運用・保守事業者（令和X年度後半に調達予定）
引継ぎ内容
・ ソースコード（テスト・構成管理・環境構築などに利用するコード含む）開発環境に必要となる各種ツール
・ 各種設計書・ドキュメント類
・ 運用課題（管理簿）
・ 仕様課題（管理簿）
・ インシデント状況（管理簿）
・ 連携業務AP対応状況（管理簿）
・ ヘルプデスク作業
・ 各種運用・保守作業
・ そのほか納品物一式
・ （クラウドサービスの管理に必要なアカウントや鍵情報、またInfrastructure as Codeに基づくシステム構築・管理に係る構成管理ファイルなど情報を漏れなく含む）
引継ぎ手順 受託者は、引継ぎ計画書の内容に基づいて、引継ぎ作業を行う。
NO 2
引継ぎ期間 令和〇年〇月〇日〜令和〇年〇月〇日
引継ぎ先 連携先システムである●●システムのアプリケーション保守事業者
引継ぎ内容 必要となる知識など
引継ぎ手順 受託者は、引継ぎ計画書の内容に基づいて、引継ぎ作業を行う。
事業者がソフトウェアライセンスを保有している場合の引継ぎ 事業者が情報システムを構成するソフトウェアのライセンスを保有している場合、事業者が交代する際にソフトウェアライセンスを引継ぎ先の事業者へ譲渡することが必要になります。ソフトウェアライセンスの契約条件によっては譲渡に制約が生じ、引継ぎ先の事業者による運用・保守作業に支障が生じる場合があります。そのため、譲渡可能なソフトウェアライセンスを調達する旨とソフトウェアライセンスの譲渡に関する制約がある場合はその情報を開示する旨を、要件定義書に記載しましょう。落札後、ソフトウェアライセンスの契約条件を発注者・事業者間で合意した上で、ソフトウェアライセンスを調達しましょう。
教育に関する事項
「教育」とは、情報システムの利用者が、その情報システムの機能を理解し、効率的に運用していくために必要となる、利用者に対する操作研修などを指します。
業務要件定義で作成した業務フロー図などを参考に、教育対象者の範囲を定めます。基本的には業務フロー図に表現されているすべてのアクター（役割）が、教育対象者の候補となりますが、対象者の役割、所属する組織、場所などを考慮し、教育効果や費用を考慮して教育内容や用いる教材などについて要件として示します。
ECサイト構築における教育対象者（例）
NO 1
教育対象者 システム部門従業員
教育内容 運用業務の全体概要、システム部門従業員の業務手順など
教育対象者数 XXX
NO 2
教育対象者 業務部門従業員
教育内容 従業員の業務に関する本システムの操作手順、画面遷移、UI表示仕様、エラー発生時の対応など
教育対象者数 XXX
NO 3
教育対象者 運用・保守事業者
教育内容 運用・保守業務の全体概要、運用・保守事業者の業務手順、運用・保守要員の業務内容など
教育対象者数 XXX
ECサイト構築における教育資料の概要（例）
NO 1
教材 システム概要資料
教材の概要 情報システムや関連業務の概要を取りまとめた資料
対象者
システム部門従業員
業務部門従業員
運用・保守事業者
補足 対象者ごとに教材を作成
NO 2
教材 操作動画
教材の概要 情報システムの操作方法について動画に取りまとめたもの
対象者 業務部門従業員
補足 XXX
NO 3
教材 FAQ
教材の概要 よくある質問や回答を取りまとめた資料
対象者
システム部門従業員
業務部門従業員
運用・保守事業者
補足 対象者ごとに教材を作成
運用に関する事項
情報システムの運用とは、稼動状態をあらかじめ定めた品質基準に基づき維持することであり、今ある環境を正常な状態に保ち続ける活動ともいえます。詳細な内容は情報システムの運用設計において検討しますが、運用要件の内容によって、情報システムの機能要件および非機能要件に求める事項が異なることもあるため、基本的な要件はここで定義しておきます。
ECサイトの運用時におけるセキュリティ対策要件
IPAの「ECサイト構築・運用セキュリティガイドライン」には、ECサイト運用時におけるセキュリティ対策要件が記載されています。「必須」、「必要」、「推奨」という区分や定義については、「21-1-2.要件定義」で前述したものと同じです。「必須」の要件については、必ず実装することが重要ですが、「必要」、「推奨」の要件ついては、自社の適用宣言書に基づいて実装するようにしましょう。
要件1
セキュリティ対策要件（運用時） サーバおよび管理端末などで利用しているソフトウェアをセキュリティパッチなどにより最新の状態にする。
区分 必須
要件2
要件3
セキュリティ対策要件（運用時） Webサイトのアプリケーションやコンテンツ、設定などの重要なファイルの定期的な差分チェックや、Webサイト改ざん検知ツールによる監視を行う。
区分 必須
要件4
セキュリティ対策要件（運用時） システムの定期的なバックアップの取得およびアクセスログの定期的な確認を行い不正アクセスなどがあればアクセスの制限などの対策を実施する。
区分 必須
要件5
セキュリティ対策要件（運用時） 重要な情報はバックアップを取得する。
区分 必須
要件6
セキュリティ対策要件（運用時） WAF（Web Application Firewall）を導入する。
区分 推奨
要件7
セキュリティ対策要件（運用時） サイバー保険に加入する。
区分 推奨
ECサイトの運用時におけるセキュリティ対策要件一覧
（出典）IPA「ECサイト構築・運用セキュリティガイドライン」をもとに作成
ソフトウェアを安全な状態で利用するためには、その前提として、脆弱性情報に関する常日頃の情報収集が大切です。すでに攻撃方法が見つかっていたり、被害の存在が広く知られていたりするなど、危険度の高い脆弱性に関しては、セキュリティパッチの適用や最新版へのバージョンアップによるアップデートを迅速に行うことが重要です。それ以外の脆弱性に関しては、セキュリティパッチの適用や最新版へのバージョンアップを行うか否かを、脆弱性によるシステムへの影響などを考慮して判断してください。
・ ECサイトの構築時に利用しているWebサーバなどのOS・ミドルウェア、プラグインおよびライブラリや、WebアプリケーションやOSSのソフトウェアについては、運用時点の最新版を使用してください。
・ 利用しているソフトウェアなどについては、ECサイト運営事業者や外部委託先において最新の脆弱性情報を収集することが大切です。セキュリティ情報サイトでの定期的な情報収集をするとともに、ソフトウェアを提供している企業から脆弱性に関する情報収集方法が用意されている場合は必ず登録するようにしてください。
・ 利用しているソフトウェアなどで脆弱性が発見された場合、脆弱性情報を収集し、脆弱性の危険度が「高」の脆弱性については迅速に、危険度「中」は、3ヶ月程度を目途にセキュリティパッチの適用や最新版へのバージョンアップによるアップデートを実施してください。アップデート実施後は、アップデートによりシステムへの影響がないことを確認（動作検証）してください。
ECサイトを構築後、新たな脆弱性が発見される・新たな脆弱性を作り込む可能性があるため、定期的およびカスタマイズを行った際に脆弱性診断を実施します。
・ 新機能の開発・追加やシステム改修などのカスタマイズを行ったときには、その都度Webアプリケーション診断を実施することが重要です。なお、診断箇所は、最低でも新機能の開発や追加やシステム改修などを行った箇所を対象とした診断を実施してください。
・ 上記のような新機能の開発・追加やシステム改修などのカスタマイズを行っていない場合でも、OSやミドルウェアなどの脆弱性は継続的に発見されているため、四半期に1回の頻度でプラットフォーム診断を実施することが望まれます。
・ 脆弱性診断の診断結果として、実害に至る攻撃難易度を考慮した危険度は、一般的に「高」、「中」、「低」の3段階で分類されており、危険度「高」の脆弱性については、迅速に対策を行うことを推奨しています。また、危険度「中」は、3ヶ月程度を目途に対策を行うことが推奨されています。
不正アクセスやマルウェア感染により、Webサーバ内部に保管しているサイト利用者の顧客情報や、注文・取引データなどを外部に送信する不正なプログラムが、Webサーバの公開ディレクトリ配下などに仕掛けられた場合でも、それを検知できるように、定期的な差分チェック（ファイル整合性監視）や、Webサイト改ざん検知ツールを利用した監視を行うようにしましょう。
不正アクセスやマルウェア感染により、システムを改ざん、破壊された場合、ECサイトでの事業の継続ができなくなる可能性があるため、システムのバックアップを最低1回/月取得するようにします。また、ECサイトへの不審なログインの試行が増えたり、システム上で対応されていない不正な注文ができたりするという不正アクセスの予兆が発生している場合もあります。このため、Webサーバのアクセスログを定期的に確認し、確認した結果、不正なアクセス（特定のIPアドレスからの大量のアクセスなど）があれば、ファイアウォールなどのネットワーク機器の設定でアクセスの制限をかけるなどの対策を実施しましょう。
Webサーバのアクセスログの定期的な確認は、IPAが提供する「ウェブサイトの攻撃兆候検出ツールiLogScanner」を利用して確認可能です。
詳細理解のため参考となる文献（参考文献）
サイト利用者の顧客情報や仕入先情報、売上情報などの重要な情報がランサムウェアによって暗号化されると、ECサイトでの事業の継続ができなくなる可能性があるため、重要な情報は1回/日にバックアップを取得（ネットワークに接続されていないオフライン環境へ保管）します。
すでに見つかっている脆弱性に対して対応するまでに期間が必要な場合や、必要となるセキュリティ対策を実装するまでに期間が必要な場合が想定されます。対策をするまでの期間内にサイバー攻撃を受けることがないよう、応急処置として、WAF（Web Application Firewall）を導入すると良いでしょう。
万が一、ECサイトまたは、自社システムがサイバー攻撃による被害を受けた場合に備えて、サイバー保険に加入しておきましょう。サイバー保険については、IPA調査でも顧客情報の漏えい事故を発生させてしまったECサイトの多くが、被害後に加入していますが、損害賠償や事故対応費用の負担、収益の減少を補う効果が認められることから、被害が発生していない場合でも被害発生に備えて加入することが推奨されます。
ECサイトの運用時に有効なCSF2.0の管理策（例）
セキュリティ対策の要件を決める際は、CSF2.0の管理策を参考にすることも有効です。
有効な管理策の例
パッチ適用に関する管理策
・ GV.SC-09:サプライチェーンセキュリティの実践が、サイバーセキュリティと企業のリスク管理プログラムに統合され、そのパフォーマンスが技術製品とサービスのライフサイクル全体を通じて監視される。
・ ID.RA-01:資産の脆弱性を特定、検証、記録する。
・ PR.AT-01:要員は、サイバーセキュリティリスクを念頭において一般的な業務を遂行するための知識と技能を有するよう、意識向上とトレーニングを受ける。
・ PR.PS-02:ソフトウェアはリスクに見合った保守、交換、削除が行われる。
など
脆弱性情報に関する管理策
・ ID.RA-08:脆弱性の開示を受領、分析、対応するためのプロセスを確立している。
など
ログに関する管理策
・ PR.PS-04:ログ記録を作成し、継続的なモニタリングに利用できるようにする。
・ DE.CM-02:潜在的に有害な事象を発見するために、物理的環境をモニターする。
・ DE.CM-03:潜在的な有害事象を発見するため、従業員の活動および技術利用を監視する。
・ DE.AE-02:潜在的有害事象を分析し、関連する活動をよりよく理解する。
・ DE.AE-03:情報は複数の情報源から関連付けられている。
・ DE.AE-06:有害事象に関する情報は、権限を与えられたスタッフおよびツールに提供される。
など
バックアップに関する管理策
・ PR.DS-11:データのバックアップが作成、保護、維持、およびテストされる。
・ RC.RP-03:バックアップやそのほかのリストア資産をリストアに使用する前に、その完全性を検証する。
など
※各管理策の詳細は、「付録:CSF2.0」を参照してください。
ECサイト構築における運用計画書の記載（例）
NO 1
項目 作業概要
補足 監視・運用・保守作業の対象範囲、管理対象、作業概要を記載する。
NO 2
項目 作業体制に関する事項
補足 運用・保守業務を実施するための体制について、管理体制図、本件受託者の要因（責任者、作業者、役割分担）、連絡手段などについて記載し、全体的な運用管理体制を明確にする。
NO 3
項目 管理対象
補足 受託者は本業務で開発するXXXシステムおよびドキュメントについて保守を行うこと。
NO 4
項目 サービスレベル
補足 運用・保守業務で達成目標とするサービスレベル項目およびサービスレベルを主管課が協議の上、決定すること。
主な運用作業例
NO 1
運用作業の分類 パッチ適用
主な運用作業の内容 保守におけるパッチ適用要否の判断結果に基づき、パッチを適用の上、適用後の稼動確認を行う。
NO 2
運用作業の分類 ログ管理業務
主な運用作業の内容
・ 操作ログやアクセスログなどのシステムログ、例外事象の発生に関するログを取得すること。
・ ログ解析機能の活用を前提として、適切なキャパシティ管理を行うこと。キャパシティの改善が必要と判断された場合、キャパシティ改善提案を行うこと。
・ 収集したログを一元的に管理し、不正侵入や不正行為の有無の点検・分析を効率的に実施すること。
NO 3
運用作業の分類 システム監視
主な運用作業の内容
・ サービスの運用状況を監視し、障害の発生またはその兆候を検知するとともに、障害を検知した際には重要性などで分類した上で、メールなどにより自動で通知する仕組みを構築すること。
監視には、例として以下のものがある。
ジョブ監視、死活監視、性能監視、リソース監視、障害監視、ログ監視（監視対象のログを監視し、特定の文字列パターンと一致した場合に障害とする方式）、セキュリティ監視、クラウドの構成監視（クラウドサービスを構成する要素を監視する方式）、外形監視（当該システムを利用するユーザーと同じ方法でアクセスし正常に動作しているか監視する方式）など
・ 各種監視結果を定期的に集計・分析し、監視方法や閾値、通知の見直しなどが必要な場合は、主管課の承認を得た上でこれに係る設計を行い、対応を実施すること。※システムサイジングについても定期的に分析を行い、主管課の承認を得た上で見直すこと。
NO 4
運用作業の分類 問題管理
主な運用作業の内容 ・ 本サービスに対し、重大な影響を与えるインシデントや将来的に重大なインシデントに発展する可能性がある問題について影響評価を行った上で、緊急度および優先度を定め、根本原因の調査および解決策の立案を行うこと。
NO 5
運用作業の分類 ヘルプデスク業務
主な運用作業の内容
・ 本サービスの利用方法に関する問い合わせの受け付けからクローズまでを一元管理するヘルプデスクを設け、本サービス利用者からの問い合わせを受け付けること。
・ 問い合わせの要件は以下に示す。
▶ 平均処理時間:6分
▶ 平均応答速度:20秒
▶ 一日の問い合わせ想定量:30件
・ ヘルプデスク担当者のスケジューリングなどの運営を適切に行うこと。
・ ヘルプデスク担当者による対応手順、サービスレベルなどを統一するため、ヘルプデスク運用マニュアルを作成し、主管課の承認を得ること。
・ ヘルプデスク運営の中でFAQは適宜追加、更新など、メンテナンスを行うこと。
・ 受け付けた問い合わせは、質問、インシデント、サービス要求、作業依頼などに分類した上で、対応日時、問い合わせ元、内容、回答状況などとともに記録すること。
なお、具体的な運用方法については、本サービスの設計開始以降に改めて検討する。
・ 問い合わせ記録は受け付け件数、問い合わせ者情報、問い合わせ内容、回率、回答に要した期間、回答内容などを適切な粒度で整理した上で、定期的に問題発生状況を分析し、必要な対応を行うこと。
運用・保守の計画および実施状況について、主管課の定める報告様式に従って取りまとめ、主管課に報告を行うこと。（原則、月次での報告）
保守に関する事項
「保守」とは機能要件に変更を加えずにプログラム修正のみを行うことです。「機能要件を変えずにプログラム修正する」という特徴があるため、現状の各種ドキュメントを正しく管理することが重要です。運用・保守計画書および運用・保守実施要領に基づき作業をします。
ECサイト構築における保守に関する事項（例）
保守業務の実施
・ 受け付けた問い合わせをインシデントとして管理し、クローズまで、対応を継続すること。
・ 障害について対応したときは、障害報告書を作成し、主管課に報告すること。
保守設計
・ 役割分担の整理
▶ 保守業務の設計に際し、受託者の責任範囲およびクラウドサービスを含めた関連事業者間の役割分担を整理すること。
▶ 新システムがクラウドサービス上で稼動することを踏まえ、各業者間の役割分担を考慮した上で、保守設計を行うこと。
アプリケーションの保守
・ インシデント管理 ▶ 運用管理・監視など作業におけるインシデント管理と適切な連携を図ること。
・ 是正保守 ▶ アプリケーションに起因した障害発生時、監査指摘事項への対応時など、アプリケーションの是正が必要な場合に、是正保守を行うこと。
・ 適応保守 ▶ OS、ブラウザ、ミドルウェアなどのバージョンアップ対応など、利用環境の変更への対応が必要な場合、アプリケーションに係る適応保守を行うこと。
・ 予防保守 ▶ アプリケーションに潜在的な問題が発見され、当該問題除去を目的とした変更が必要な場合または新たに脆弱性が報告された場合に、予防保守を行うこと。
・ 改善措置 ▶ アプリケーションに係る機能性、信頼性、使用性、効率性、保守性、移植性などの改善が必要な場合に、対処を行うこと。
・ 根本原因の分析 ▶ 是正保守および予防保守の実施に当たり、障害、監査指摘、潜在する問題などに係る根本原因の分析を行うこと。
・ 検証 ▶ 修正したアプリケーションを本番環境へ展開（デブロイ）する前に、修正が適切に実施されているか否かについて検証環境において検証すること。
・ 文章の修正 ▶ アプリケーション保守に伴い、ドキュメント（設計書、マニュアルなど）の修正を要する場合は、速やかに修正を行うこと。
ECサイトの形態の選定において、SaaS型サービスを選定した場合、以下のセキュリティ対策の実施状況について確認する必要があります。
【SaaS型サービスの選定基準】
・ 選定したサービスがクレジットカードを扱う場合にはPCI DSSに準拠していることを確認してください。（当該サービスの運営事業者のホームページやパンフレットなどに情報が公表されていない場合は、サービスの営業窓口に問い合わせて確認してください）
・ CSF2.0の管理策（ID.RA-09:ハードウェアとソフトウェアの真正性と完全性は、取得および使用前に評価される。）を参考にすることも有効です。ソフトウェアが信頼できるものであるか、セキュリティに問題がないかを導入前に確認することが大切です。
SaaS型サービスを選択した場合も、セキュリティ対策は必要です。例えば、セキュリティ対策を行わなかった場合、サービスの管理画面を乗っ取られ、ECサイトに不正ログインされる可能性があります。また、カスタマイズした部分（SaaS型サービス利用で独自の処理を追加したホームページを作成している場合）に関しては、自社構築サイトと同等レベルのセキュリティ対策を行う必要があります。ECサイト運営事業者は、上記を理解した上で以下のセキュリティ対策を必ず実施することが重要です。
【SaaS型サービス利用時に注意すべきセキュリティ対策】
・ 管理画面の乗っ取りを未然に防ぐため、SaaS型サービスの管理画面や管理用ソフトウェアへアクセスする管理端末を利用する従業員を極力最低限に限定し、管理端末からのアクセス時は二要素認証とIPアドレスや端末IDによる接続制限の導入などを必須にします。
・ 管理端末のサイバー攻撃者からの乗っ取りを防ぐために、セキュリティ対策（マルウェア対策ソフトウェアの導入、USBメモリなど外部記憶媒体の利用制限、OS、ソフトウェアの最新版へのアップデートなど）を実施します。
Fit&Gap分析は、SaaSやパッケージソフトを導入する際に非常に重要なプロセスです。Fit&Gap分析によって、RFIなどの情報収集活動によって選定したSaaSやパッケージソフトと、自社の業務要件との適合性を評価します。
Fit&Gap分析にはさまざまなやり方がありますが、一般的な実施手順の例を紹介します。
Fit&Gap分析の実施方法（例）
Fit&Gap分析の一般的な実施手順（例）
1. 現状分析
2. SaaS、パッケージソフトウェアの機能調査
3. 比較分析
4. ギャップへの対応策検討
5. 費用対効果の分析
6. 実施計画の策定
「3.比較分析」はFit&Gap分析の中核をなす重要なステップのため、手順を詳細に説明します。
比較分析の一般的な実施手順（例）
1. 比較項目の設定
2. 評価基準の設定
3. 比較表の作成
4. 詳細比較
5. ギャップの特定と分類
6. フィットの評価
7. 結果の文書化
8. 視覚化（必要があれば実施する）
9. 要件の再検討
10. ステークホルダーレビュー
上記の手順をもとに、実際にFit&Gap分析の例を紹介します。
前提条件
企業名:地方の特産品を扱う中小企業「A社」
現状:
● 実店舗は運営しているが、ECサイトはまだ存在しない。
● 主要な売上は観光客や地元の顧客による実店舗での購入。
● オンラインでの販売に関する経験がない。
● 自社にはITやセキュリティの専門家がいない。
目標:
パッケージソフトやSaaSを利用し、商品の購入から配送までを管理できるECサイトを構築する。
1.現状分析
現在のビジネスプロセスを詳細に文書化します。また、組織の要件を明確にします。
現状分析の例
● 商品仕入れと在庫管理
地元の生産者から商品を仕入れ、表計算ソフトで手動管理している。商品ごとの在庫情報は店舗ごとに管理されている。
● 店舗販売
実店舗での販売が主体で、一般的なレジを使用し、クレジットカード決済は外部の決済端末を利用している。
● 配送対応
電話やメールで受けた注文に対して手動で配送手配を行っている。オンライン販売は行っていない。
ビジネスプロセスをもとに、組織の要件を明確にします。
組織の要件を明確にする例
● ECサイトを構築し、実店舗外の顧客にもアプローチできるようにする。
● 在庫管理、注文管理、配送管理を一元化する。
● ECサイトにはクレジットカード決済機能も追加し、オンラインでも安全な決済を行えるようにする。
● セキュリティ対策を確実に実施する。（PCI-DSS準拠）
2.パッケージソフト・SaaSの機能調査
パッケージソフトやSaaSが提供する機能を詳細に調査します。また、各機能の仕様や制限を理解します。
ECサイト構築のために適したパッケージソフトやSaaSを調査する例
SaaS サービス A
・ 世界的に使用されているECサイト構築プラットフォーム。多言語対応、国際配送、複数の決済オプションをサポートしている。
・ PCI-DSSに準拠しており、セキュリティ面で強固な対策が施されている。
SaaS サービス B
・ 日本市場向けに特化したEC構築サービス。豊富なカスタマイズ機能を提供している。
・ クレジットカード決済機能が統合されており、在庫管理機能も充実している。
パッケージソフト C:
・ 中小規模のビジネス向けに使いやすいプラットフォーム。簡単にECサイトを開設でき、決済機能も搭載している。
・ セキュリティ面での拡張性は限定的で、標準機能ではPCI-DSSに準拠していない。
3.比較分析
組織の要件とパッケージソフト・SaaSの機能を比較します。また、適合する部分（フィット）と不一致の部分（ギャップ）を特定します。「比較分析」は、Fit&Gap分析の中核をなす重要なステップです。
要件定義の結果を踏まえて、業務プロセス、機能要件、非機能要件、法規制対応など、比較すべき項目を事前に定義します。これらの項目を具体的かつ測定可能な形で記述します。
比較項目の設定例
● 業務プロセス
商品の仕入れ、在庫管理、オンライン販売、決済、配送の各フローを統合して管理できること。
● 機能要件
ECサイト構築、クレジットカード決済の統合、在庫管理、顧客管理、配送管理の機能が含まれていること。
● 非機能要件
システムの稼動率が99%以上であること、セキュリティ（PCI-DSS準拠）、ユーザビリティ（初心者でも使いやすい操作画面が備わっていること。）
● 法規制対応
個人情報保護法、特定商取引法、PCI-DSS対応などの法規制に準拠していること。
各項目に対する評価基準を設定します（例:完全一致、部分一致、不一致）。必要に応じて重要度や優先度を設定します。
評価基準の設定例
● 完全一致:要件がそのまま満たされている場合に該当します。
● 部分一致:要件の大部分が満たされているが、一部の設定やカスタマイズが必要な場合に該当します。
● 不一致:要件を満たしていない場合に該当します。
候補となるパッケージソフトやSaaSが複数ある場合は、縦軸に組織の要件、横軸にパッケージソフトやSaaSの機能を配置した比較表を作成します。次に「2.評価基準の設定」で決定した評価基準をもとに、各パッケージソフト・SaaSが組織の要件を満たしているか評価します。これにより、組織の要件とパッケージソフト・SaaSの機能との対応関係を視覚化します。
比較表の例
【要件】ECサイト構築
SaaSサービスA 完全一致 SaaSサービスB 完全一致 パッケージソフトC 完全一致
【要件】クレジットカード決済の統合
SaaSサービスA 完全一致 SaaSサービスB 完全一致 パッケージソフトC 部分一致
【要件】在庫管理
SaaSサービスA 部分一致 SaaSサービスB 完全一致 パッケージソフトC 部分一致
【要件】配送管理
SaaSサービスA 完全一致 SaaSサービスB 完全一致 パッケージソフトC 部分一致
【要件】顧客管理
SaaSサービスA 完全一致 SaaSサービスB 完全一致 パッケージソフトC 部分一致
【要件】稼動率（99%以上）
SaaSサービスA 完全一致 SaaSサービスB 完全一致 パッケージソフトC 完全一致
【要件】セキュリティ（PCI-DSS 準拠）
SaaSサービスA 完全一致 SaaSサービスB 完全一致 パッケージソフトC 不一致
【要件】法規制対応
SaaSサービスA 完全一致 SaaSサービスB 完全一致 パッケージソフトC 部分一致
【要件】操作画面の使いやすさ
SaaSサービスA 完全一致 SaaSサービスB 部分一致 パッケージソフトC 完全一致
各要件に対して、パッケージソフトやSaaSが対応する機能を詳細に比較します。機能の有無だけでなく、その実現方法や操作性なども考慮します。
SaaSサービスAをもとに機能を詳細化する例を示します。他のパッケージソフトやSaaSも同様に詳細化し、比較を行います。
SaaSサービスAにおける詳細比較の例
● ECサイト構築
SaaSサービスAはECサイト構築において、豊富なテンプレートとカスタマイズ機能を提供しています。操作画面もシンプルで直感的に使えるため、初心者でも容易に利用できます。多言語対応もあり、国際展開を視野に入れている企業にとっては非常に有利です。標準機能でほぼすべての要件に対応しており、カスタマイズの必要がほとんどありません。
● クレジットカード決済の統合
SaaSサービスAは、主要な決済サービスに対応しており、クレジットカード決済の統合がシンプルに行えます。PCI-DSS準拠の決済システムが組み込まれているため、セキュリティ面も非常に強固です。操作も自動化されており、管理の手間がかかりません。
● 在庫管理
SaaSサービスAには基本的な在庫管理機能があり、在庫数の自動追跡や通知が可能です。実店舗とオンライン店舗の在庫を一元管理できますが、複雑な在庫管理には追加のカスタマイズが必要です。
● 配送管理
SaaSサービスAは主要な配送サービスと連携し、発送手続きや追跡をオンラインで一元管理できます。配送ラベルの自動生成やステータス通知により、手動管理の手間が減少します。操作画面もシンプルで使いやすいです。
● 顧客管理
SaaSサービスAには顧客の購入履歴や連絡先を自動管理する基本的な顧客管理機能があり、リピート顧客向けのプロモーションも可能です。ただし、詳細なデータ分析を行う場合は、追加のカスタマイズが必要です。
● 稼動率
SaaSサービスAはクラウドベースで、99.99%以上の稼動率を提供しており、システムが停止するリスクが非常に低いです。多くのアクセスが集中しても、安定してサイトが動作するため、安心して運用できます。
● セキュリティ（PCI-DSS準拠）
SaaSサービスAはPCI-DSSに準拠しています。クレジットカード情報が安全に取扱われ、すべての決済データが暗号化されます。また、定期的にセキュリティパッチが更新され、最新の脅威に対応できます。
● 法規制対応
SaaSサービスAは日本の法規制に対応しており、個人情報保護法や特定商取引法の要件に応じたプライバシーポリシーや利用規約の設定が可能です。
● 操作画面の使いやすさ
SaaSサービスAの操作画面は非常に直感的で、初心者でも迷うことなく利用できます。基本的な設定は数クリックで完了し、ECサイト運営の初心者にとって使いやすい設計となっています。
不一致（ギャップ）を見つけたら、その性質を分類します。（例:機能欠如、プロセスの相違、法規制への非対応など）ギャップの影響度や重要度を評価します。
ギャップの特定と分類例
SaaSサービスAのギャップ:在庫管理機能の不足
● 性質:機能欠如
SaaSサービスAは高度な在庫管理（多店舗連携や自動補充）に対応していないため、外部プラグインやカスタマイズが必要です。
● 影響度:
在庫管理はビジネス運営において重要な部分を占めます。標準機能では不足するため、プラグインやカスタマイズが必要ですが、比較的容易に対応できるため業務に大きな影響は与えないと考えられます。
SaaSサービスBのギャップ:操作画面の複雑さ
● 性質:プロセスの相違
SaaSサービスBは操作がやや複雑で、初心者にとっては学習コストが発生しますが、導入初期の対応で解決可能です。
● 影響度:
操作画面の複雑さは導入初期の学習コストを増加させますが、時間と研修によって解消できます。⻑期的には業務に大きな支障をきたさないため、影響度は低いと考えられます。
パッケージソフトCのギャップ:セキュリティ対応の不足
● 性質:法規制への非対応
パッケージソフトCはPCI-DSS準拠のセキュリティ対策が不足しており、クレジットカード決済に対する対策が別途必要です。
● 影響度:
セキュリティ対応の不足は、顧客情報の漏えいや法的な問題につながる可能性があるため、ビジネス全体に強い影響を与える可能性があると考えられます。
一致している部分（フィット）についても、適合度を評価します。単なる機能の有無だけでなく、使いやすさや効率性も考慮します。
フィットの評価例
SaaSサービスAのフィット評価
● クレジットカード決済の統合
SaaSサービスAはPCI-DSS準拠であり、セキュリティ面での信頼性が高いです。クレジットカード決済の統合もスムーズで、安全かつ使いやすいシステムを提供しています。
● 稼動率
SaaSサービスAは99%以上の稼動率を誇り、安定した運用が可能です。ビジネスが途切れることなく継続できます。
● 操作画面の使いやすさ
操作画面は非常に直感的で、初心者でも簡単に利用可能です。これにより、迅速な導入と運用が可能となります。
SaaSサービスBのフィット評価
● 在庫管理
SaaSサービスBは強力な在庫管理機能を持っており、大量の商品を扱う際に効率的な管理が可能です。この機能は、標準で十分なレベルに達しています。
● クレジットカード決済の統合
SaaSサービスBもPCI-DSSに準拠しており、決済機能が安全に統合されています。法規制対応も含め、安心して利用できる環境が整っています。
● 稼動率
99%以上の稼動率を持っており、ビジネスの安定運用が確保されています。システムの信頼性が高く、⻑期的な運用に適しています。
パッケージソフトCのフィット評価
● ECサイト構築
パッケージソフトCはシンプルで使いやすいインターフェースを提供しており、短期間でのサイト構築が可能です。特に中小企業に向いており、導入コストが低いのも魅力です。
● 稼動率
パッケージソフトCも99%以上の稼動率を誇りますが、大規模運用には適さない場合があります。小規模運用には十分な安定性があります。
● 操作画面の使いやすさ
パッケージソフトCは非常にシンプルな操作画面を提供しており、初心者でも簡単に利用できます。低コストで迅速な運用が可能です。
比較結果を詳細に文書化します。フィットとギャップの両方について、具体的な説明を記載します。
結果の文書化例
SaaSサービスAの結果
● フィット:SaaSサービスAは、重要度の高い要件であるクレジットカード決済の統合、セキュリティ（PCI-DSS準拠）、法規制対応、そして稼動率99%以上をすべて満たしています。また、操作画面の使いやすさも完全一致しており、操作に慣れていないスタッフでも扱いやすいです。
● ギャップ:在庫管理機能については一部カスタマイズが必要であり、標準機能では自社の要件を完全に満たしません。カスタマイズにより、初期導入コストやシステム設定に追加の手間がかかる可能性があります。
SaaSサービスBの結果
● フィット:SaaSサービスBは、在庫管理、顧客管理、配送管理の各プロセスにおいて高い適合度を示しており、特に中小企業の実務に即した機能が充実しています。重要度の高いセキュリティや法規制対応も完全一致しており、安心して導入できます。稼動率も高く、パフォーマンス面でも良好です。
● ギャップ:操作画面の使いやすさについては、初心者にとってはやや複雑で、導入時にトレーニングが必要となります。ただし、業務に大きな支障はないと考えられます。
パッケージソフトCの結果
● フィット:パッケージソフトCは、導入コストが非常に低く、簡単にECサイトを構築できるため、迅速にオンライン販売を開始したい企業には適しています。操作画面の使いやすさにおいても高い評価を受けており、特にITに不慣れなスタッフでも容易に操作できます。
● ギャップ:大きなギャップは、セキュリティ要件が不十分な点です。特に、PCI-DSS準拠が不足しているため、クレジットカード決済を安全に運用するためには追加のセキュリティ対策が必須となります。また、配送管理や在庫管理の一部機能が標準では不足しており、カスタマイズが必要です。初期の導入コストが低い反面、⻑期的には追加コストが発生するリスクがあります。
必要に応じて結果をグラフや図表で表現し、全体像を把握しやすくします。例えば、ヒートマップやレーダーチャートなどを使用します。
分析結果に基づき、組織の要件自体の妥当性を再検討します。場合によっては、要件の修正や優先順位の変更を行います。
要件の再検討例
要件1:ECサイトを構築し、実店舗外の顧客にもアプローチできるようにする。
分析結果の確認:SaaSサービスA、SaaSサービスB、パッケージソフトCすべてがECサイト構築要件に対して完全一致しており、特に問題がないことが確認できます。
再検討の必要性:なし
要件2:在庫管理、注文管理、配送管理を一元化する
分析結果の確認:SaaSサービスAとパッケージソフトCは在庫管理や配送管理が部分一致であり、一部カスタマイズや追加機能が必要です。SaaSサービスBは完全に一致しています。
再検討の必要性:在庫管理や配送管理の重要度は高いため、SaaSサービスAやパッケージソフトCを選ぶ場合にはカスタマイズや追加機能導入の検討が必要です。要件自体は妥当ですが、システム選定時にはこれらの要件の優先順位を高く維持するべきです。
要件3:ECサイトにはクレジットカード決済機能を追加し、オンラインでも安全な決済を行えるようにする
分析結果の確認:SaaSサービスAとSaaSサービスBはクレジットカード決済に完全一致していますが、パッケージソフトCを選択する場合には追加のセキュリティ対策が必要となります。
再検討の必要性:SaaSサービスAとSaaSサービスBは必要ありません。パッケージソフトCを選択する場合は追加のセキュリティコストを考慮する必要があります。
要件4:セキュリティ対策を確実に実施する（PCI-DSS準拠）
分析結果の確認:SaaSサービスAとSaaSサービスBはPCI-DSSに完全に準拠していますが、パッケージソフトCはこの要件に不一致であり、セキュリティ対策を強化しなければなりません。
再検討の必要性:パッケージソフトCを選択する場合には、外部セキュリティ対策を追加するコストを考慮しなければなりません。セキュリティは最も重要な要件の一つであり、特にクレジットカード決済においては必須です。
分析結果を関係者に共有し、フィードバックを得ます。必要に応じて追加の調査や分析を行います。
「1.比較項目の設定」から「10.ステークホルダーレビュー」までの詳細な比較分析により、パッケージソフト・SaaSと組織の要件との適合性を正確に評価し、導入に向けた的確な判断や計画立案が可能になります。
※比較分析の作業において業者に協力を求める場合、当該作業の内容と責任の所在を明確にする必要があります。また、複数の業者からの提案書およびFit&Gap分析の評価を求める場合は、書式の統一、用語の定義などに配慮し、誤解が生じないようにすることが信頼性の確保につながります。
4.ギャップへの対応策検討
カスタマイズ、ビジネスプロセスの変更、代替ソリューションを検討します。
（可能な限りカスタマイズは避けた方がよく、ビジネスプロセスを変更することで対応することが推奨されます。）
SaaSサービスAを例にとり、説明します。
SaaSサービスAのギャップへの対応策例
ギャップの概要 SaaSサービスAの在庫管理機能が標準では自社の要件に完全には対応していないため、カスタマイズやビジネスプロセスの調整が必要です。
対応策:
●ビジネスプロセスの変更:在庫管理の運用をシンプルにし、SaaSサービスAが標準で提供している在庫管理機能に適合するようにプロセスを調整できるか検討します。例えば、在庫の更新頻度を増やす、複雑な商品区分を簡略化するなど、システム側に合わせたプロセスの変更で対応可能な部分があるかを確認します。
●カスタマイズ:ビジネスプロセスの変更が難しい場合、在庫管理の不足部分に対して追加のプラグイン導入といったカスタマイズを行います。この際、必要最小限のカスタマイズに留めることが重要です。
5.費用対効果の分析
ギャップへの対応策実施にかかるコストと得られるメリットを評価します。SaaSサービスAを例にとり、説明します。
費用対効果の分析例
ギャップの概要 SaaSサービスAの在庫管理機能が標準では自社の要件に完全には対応していないため、カスタマイズやビジネスプロセスの調整が必要です。
対応策1:ビジネスプロセスの変更
コスト
● 初期費用:なし（社内でプロセスを調整）
● 運用費用:低コスト（社内のスタッフによる在庫管理の簡略化）
メリット
● SaaSサービスAの既存の在庫管理機能に合わせてプロセスを調整することで、カスタマイズ不要のため初期費用がかかりません。
● 社内運用のみで対応できるため、カスタマイズのコストが不要です。
● シンプルな運用による管理の効率化が見込まれます。
対応策2:カスタマイズ（プラグイン導入）
コスト
● 初期費用:中程度（プラグインの導入コストや設定費用がかかる）
● 運用費用:月額5000円〜10000円（在庫管理用のプラグイン利用料）
メリット
● カスタマイズにより、標準機能では対応できない在庫管理機能を補完できるため、自社の業務フローに完全に対応することが可能です。
● システム全体の効率性が向上し、在庫管理の自動化やリアルタイムでの在庫情報管理が可能です。
6.実施計画の策定
分析結果に基づいて、具体的な導入計画を立案します。
例ではSaaSサービスAの導入を推奨とし、その導入プロセスを具体的に示します。
導入計画の例
1.契約と初期設定（1週間）
SaaSサービスAの契約を締結し、サイトの基本レイアウトを設定します。
2.商品データと在庫管理（2〜3週間）
商品情報を登録し、在庫管理のカスタマイズを実施します。
3.クレジットカード決済とセキュリティ設定（1〜2週間）
クレジットカード決済機能を設定し、セキュリティ対策を強化します。
4.配送システムの設定（1〜2週間）
配送オプションを設定し、配送業者との連携を行います。
5.テスト運用（1〜2週間）
商品購入から配送までのプロセスをテストし、問題がないか確認します。
6.スタッフトレーニング（1週間）
SaaSサービスAの操作方法をスタッフに対してトレーニングします。
7.公開とマーケティング（1週間）
ECサイトを公開し、プロモーションを実施します。
8.運用とメンテナンス
定期的にセキュリティチェックとシステムのメンテナンスを行います。
全体の期間:約8〜10週間でECサイトを構築し、運用を開始します。
サービス・パッケージ候補とのギャップを解消するポイント
RFIにより提示した要件と提案されたサービス、パッケージ候補とのギャップを、委託候補企業の言いなりにならず、主体的に解消することが重要です。
・ 要件の変更
Gapが大きすぎる場合は、最も適合性の高いサービスに合わせて、既存の業務プロセスやシステム要件を見直すことが望ましい。
・ サービスのカスタマイズを利用
Gapが小さい場合は、サービス内のカスタマイズを利用することでGapを埋める方法があります。しかし、セキュリティの観点からから安易なカスタマイズは避け、できる限り業務プロセスをパッケージやSaaSに合わせることが望ましい。
・ 補完的なサービスを利用
特定の機能のみが不足している場合は、別のパッケージやSaaSを組み合わせることで補完する方法があります。別のシステムを利用することにより専門的な機能の利用や、迅速な導入ができるので、初期投資が低く抑えられます。
独自カスタマイズのリスクについて
GAPを埋めるために、あらかじめ用意されているパッケージソフトやSaaSサービス内のカスタマイズではなく、独自のカスタマイズを行う場合、以下のようなリスクがあります。
● コストの増加
カスタマイズには追加の開発費用がかかります。予算を超える可能性があり、コスト管理が難しくなることがあります。
● 時間の遅延
カスタマイズ作業が予想以上に時間がかかることがあり、プロジェクト全体のスケジュールに影響を与える可能性があります。
● メンテナンスの複雑化
カスタマイズされたシステムは、カスタマイズのないシステムに比べてメンテナンスが難しくなります。将来的なアップデートやバグ修正が困難になる可能性があります。
● 互換性の問題
カスタマイズにより、他のシステムやソフトウェアとの互換性が損なわれる可能性があります。これにより、システム全体のパフォーマンスや安定性に影響を与える可能性があります。
● サポートの制限
カスタマイズされた部分については、ベンダーからのサポートが受けられない場合があります。これにより、問題が発生した際の対応が遅れる可能性があります。
● 品質やセキュリティレベルの低下
カスタマイズが不十分な場合、システムのセキュリティや品質が低下するリスクがあります。
これにより、ユーザーの満足度が低下するだけでなく、セキュリティインシデントの発生可能性も高まる可能性があります。
● 将来のアップグレード問題
カスタマイズされたシステムは、将来的なバージョンアップや新機能の追加が難しくなることがあります。最新の技術や機能を利用できなくなるというリスクがあります。
カスタマイズには多くのリスクがあるため、カスタマイズの必要性は慎重に検討し、業務プロセスなどをシステムにあわせて変更することが推奨されます。
どうしても機能などを追加する場合は、本体のシステムに与える影響の少ないアドオン（外側に機能を追加する方法）で対処することが推奨されます。
21-1-3. 調達
要件定義書を含めた調達仕様書の作成方法を説明します。
調達仕様書とは、プロジェクトの目的の達成に必要な製品の入手や、必要となる役務を実施する外部事業者を選定するために示す、発注者側の条件を集めたドキュメントです。
調達仕様書には、発注者側の要望（要件）に加えて、制約となる条件を記載します。実現したいことに加えて、実現を図っていく過程で守るべき前提条件や制約条件を合わせて記載することで、調達仕様書としての完成度を高められます。
調達仕様書の全体像（例）
調達案件の概要
主要な記載内容 背景、目的、効果、業務・情報システムの概要
調達案件および関連調達案件の調達単位、調達の方式など
主要な記載内容 調達内容、関連する調達案件、方式、時期
情報システムに求める要件
主要な記載内容 要件定義の内容
作業の実施内容に求める要件
主要な記載内容 作業の内容、成果物の範囲、納品期日
作業の実施体制・方法に関する事項
主要な記載内容 作業実施体制、資格要件、管理の要領
作業の実施に当たっての順守事項
主要な記載内容 機密保持、資料の取扱い、順守する法令
成果物に関する事項
主要な記載内容 知的財産権の帰属、契約不適合責任、検収
見積り依頼をする業者の選定に関する事項
主要な記載内容 業者選定要件
再委託に関する事項
主要な記載内容 再委託の制限、条件、承認手続き
パッケージソフト、クラウドサービスの選定、利用に関するセキュリティ関連事項
（要機密情報を取扱う場合）
主要な記載内容 パッケージソフト、クラウドサービスの選定・利用に関する共通セキュリティ要件、成果物の取扱い
そのほか特記事項
主要な記載内容 機器などのセキュリティ確保、制約条件
附属文書
主要な記載内容 要件定義書など
調達仕様書を作成するときに、特に注意が必要なポイントについて説明します。項目の詳細な説明は、ひな型を参照してください。
調達の意図や目的を正しく伝える
外部業者からプロジェクトにとって有用な提案をもらうためには、以下の点をしっかり伝える必要があります。
・ プロジェクトの背景と目的
このプロジェクトがなぜ必要なのか、達成したい目標を明確に説明します。業者がプロジェクトの意図を理解しやすくなります。
・ 調達の経緯と期待する効果
なぜこの調達が必要になったのか、どんな成果や効果を期待しているのかを詳しく説明します。業者が具体的な提案を考えやすくなります。
・ プロジェクトの全体像とスケジュール
プロジェクトの全体的な流れやスケジュールを示すことで、業者がプロジェクトの全体像を把握しやすくなります。
これらの情報は、調達仕様書の「調達案件の概要」に記載し、プロジェクト全体のスケジュールも含めることで、業者がより適切で有用な提案をしやすくなります。
作業内容・納品物を関連付けて網羅的に記載する
調達仕様書では、外部事業者の作業内容、納品物をそれぞれ漏れなく定める必要があります。しかし、設計・開発などの調達では多種多様な作業や納品物があるため、漏れなく記載するのは困難です。これらを定義する際は、作業内容、納品物を関連付けて定義していくことで、効果的に抜け漏れを確認していくことができます。作業の実施内容と納品物を関連付けて一覧としてまとめておくと、工程完了時の納品物のチェックにも活用でき、検収時の確認負荷を減らせます。
外部事業者の具体的な作業内容を明確にする
外部事業者が実際に何を実施する必要があるのか理解できるように、作業内容を明確に記載することが重要です。
例えば、「支援」という言葉は人によって解釈が大きく異なります。「マニュアル作成支援」という作業項目があった際、2つの役割分担が考えられます。1つ目は、従業員がもととなる原案や素材を用意した上で事業者が体裁を整えるという役割分担です。2つ目は、事業者がマニュアルの原案自体を作成して従業員が内容を確認するという役割分担です。このような役割分担の違いによって、事業者が実施する作業範囲や必要工数は大きく変わります。実際に実施する内容が事業者に正確に伝わらない場合、上記の事態をまねくおそれがあるため、事業者に実施を求める内容は正確に記述することが重要です。
作業内容が曖昧な場合に懸念される事態
・ 必要な人員のスキルや数について、外部事業者の想定と発注者側の希望や想定がミスマッチとなる場合、契約した後に業務を完遂できない。
・ 作業を終えることができても、成果物の品質（機能性、信頼性、使用性、効率性、保守性、移植性）が著しく低下する。
・ 契約した外部事業者からの問い合わせや協議などが増加し、発注者側に想定していた以上の作業が発生する。
作業の実施体制を明確にする
調達案件を通じてプロジェクトの活動を円滑に進めていくためには、発注者側であるプロジェクト管理を行うチームや担当者や関係する従業員が、体制や役割分担、責任範囲を明確にし、外部事業者と一緒に協働していくことが大切です。調達仕様書や要件定義書をしっかり記載し、適切な外部事業者を選定することが仮にできたとしても、望んだ情報システムを必ずしも手に入れられるわけではありません。プロジェクトを進めていくと、要件の内容を設計として具体化・詳細化していく中で発注者側が決定しなければならないこと、他の関係者と調整しなければならないことは多く発生します。また、進捗上の課題や問題が発生した場合に発注者側の判断を要する場合もあります。
サービス・業務の企画や要件定義のように新しいサービス・業務や情報システムの内容を決定するような活動においては、特に注意が必要です。意思決定の責任は発注者にあることを認識した上で、プロジェクト管理を行うチームや担当者以外の関係者も含めて、適切な判断ができる体制を組成して調達仕様書に明示することが重要です。
成果物の取扱いに注意する（知的財産権）
知的財産権の取扱いについては、設計・開発した文書やアプリケーションプログラムの知的財産権が誰に帰属するかを明確にしておくことが重要です。
・ パッケージ製品
全く改変せず採用した場合、その知的財産権は提供もとに帰属します。
・ 蓄積データ
パッケージ製品を利用して蓄積されたデータの帰属については、発注者が所有することが一般的です。
・ 機能拡張やクラウド設定
発注者の要望に基づいて拡張した機能や設定の知的財産権については、契約内容により帰属先が変わります。
再委託に関する事項を定める
情報システム整備プロジェクトでは、規模が大きくなると多くの専門的役割が必要となり、特定分野の外部事業者を活用することが増えます。これらの事業者が再委託を行う場合、委託元が再委託先の作業を管理する責任がありますが、再委託に関するトラブルも少なくありません。
再委託の制限や条件、承認手続き、再委託先の契約違反に関する規定を調達仕様書に記載し、責任の所在を明確にすることが重要です。また、プロジェクト遂行中の体制変更も、発注者と協議しながら進める必要があります。再委託に関しては、情報セキュリティポリシーの規定も確認する必要があります。
納品後に不具合が発覚したときの責任を明確にする（契約不適合責任）
2020年4月に施行された改正⺠法により、「瑕疵担保責任」が廃止され、代わりに「契約不適合責任」が導入されました。これは、システム納品後の不具合に対する責任を、契約で定められた種類、品質、数量に適合しているか否かに基づいて判断するものです。この改正は、取引の実情に合わせたものであり、特に請負契約において次のような相違点が重要です。
・ 救済手段の多様化
契約不適合責任では、契約の解除、損害賠償請求に加えて、修補や代替物の引渡し、報酬減額請求など、多様な救済手段が追加されました。
・ 権利行使期間の変更
瑕疵担保責任では瑕疵を知ってから1年以内に権利行使をする必要がありましたが、契約不適合責任では不適合を知ったときから1年以内に通知すれば救済が可能になりました。
・ 「隠れた瑕疵」の要件の廃止
瑕疵担保責任では、発注者が瑕疵の存在について善意無過失であったこと（瑕疵が「隠れた瑕疵」であったこと）が要件とされていましたが、契約不適合責任ではこの要件はなくなり、「隠れた瑕疵」でなくても業者の責任を問うことができるようになりました。
中小企業が適正な価格で最適な業者を選定し、不利益を被らないような、実施可能な手続きについて説明します。
調達仕様書の明確化
中小企業にとって、調達仕様書が曖昧だと、不要な追加コストが発生するリスクが高まります。具体的な要求内容、納品スケジュール、品質基準などを明確に記載し、業者が正確な見積りを行えるようにすることが重要です。また、調達仕様書を適切に作成することで、業者の作業内容を厳密に管理し、不適切な追加請求を防げます。
透明性と公平性の維持
調達プロセス全体において透明性と公平性を確保することは、中小企業が不利益を被らないために不可欠です。提案依頼書や契約書の内容を整合性のあるものにし、期待する成果が正確に伝わるようにすることで、業者との間に不必要な誤解が生じるリスクを軽減します。
複数の見積り取得
中小企業が適正な価格を確保するためには、必ず複数の業者から見積りを取得し、比較検討することが必要です。三点見積りを活用することで、極端な価格設定による影響を排除し、より適正な予算を設定できます。また、特定の業者に依存するリスクを避けるため、依頼する業者を増やす工夫が大切です。
ECサイト構築における、3点見積りの実施例
中小企業がSaaSやパッケージソフトを用いてECサイトを構築する際、セキュリティ対策や運用・保守コストを含めた三点見積りを実施する例を説明します。
楽観値
最も良い条件が揃った場合の最低コスト。追加コストやリスクが発生せず、プロジェクトが順調に進むことを想定した見積りです。
最頻値
一般的な条件で進行した場合の予測コスト。通常のリスクや変動を含めた、最も現実的な見積りです。
悲観値
最悪の状況が発生した場合の最高コスト。予期しない問題や追加のコストが発生する場合を考慮した見積りです。
この式では最頻値に重きを置き、楽観値と悲観値を考慮してより現実的な平均を算出します。
SaaS型サービスA（標準プラン）
サービス内容:クラウドベースのECプラットフォーム。テンプレートを使って簡単にサイトを作成可能。基本的なセキュリティ機能を提供し、月額利用料で運用可能。
楽観値:60万円（基本プランと最低限のセキュリティ対策）
最頻値:75万円（追加のカスタマイズと標準的なセキュリティ対策）
悲観値:120万円（高度なカスタマイズと強化されたセキュリティ対策）
平均見積り:80万円
パッケージソフトB
サービス内容:自社サーバにインストール可能なソフトウェア。高度なカスタマイズが可能で、独自の機能を追加可能。セキュリティや保守管理が必要。
楽観値:80万円（シンプルな設定と標準的なセキュリティ対策）
最頻値:100万円（通常のカスタマイズと強化されたセキュリティ対策）
悲観値:130万円（広範なカスタマイズと最強のセキュリティ対策）
平均見積り:約102万円
SaaS型サービスC（上位プラン）
サービス内容:上位のSaaSプランで、より多くの機能や強化されたセキュリティ（WAF、不正利用検知など）を提供。追加のカスタマイズが可能。
楽観値:70万円（標準プランと基本的なセキュリティ対策）
最頻値:90万円（カスタマイズ対応と追加セキュリティ機能）
悲観値:170万円（最上位プランと強化されたセキュリティ対策）
平均見積り:100万円
三点見積りで比較した結果
SaaS型サービスA（標準プラン）が、導入コストが最も低く、基本的なセキュリティ対策も標準装備されているため、コストパフォーマンスが最も高い選択肢です。
パッケージソフトBは、カスタマイズ性が高く、独自の機能を追加したい企業に最適ですが、セキュリティや運用にかかる費用が増えるため、予算に余裕がある場合に適しています。
SaaS型サービスC（上位プラン）は、SaaSの利便性を維持しつつ、セキュリティ機能や機能拡張が必要な場合に選ぶと良いですが、標準プランに比べて費用が増します。
セキュリティやコストバランスを考慮すると、SaaS型サービスA（標準プラン）が最もバランスが良いと考えられます。
21-1-4. 設計・開発
中小企業でも、プロジェクトの計画立案とその管理は重要です。規模は小さくても、体系的なアプローチを取ることで、効率的な開発と品質の確保が可能になります。
設計・開発事業者が決まれば、最初に行うことは計画を立てることです。設計・開発は実態が見えにくい活動になるため、問題の発覚が遅れて大惨事になることがあるため、しっかりと作成することが重要です。
設計・開発実施要領
プロジェクト・業務・情報システムの概要で、実施されるに当たり知っておくべき内容を記載します。
NO 1
目次 はじめに
主要な記載内容 プロジェクト、業務、情報システムの概要
NO 2
目次 コミュニケーション管理
主要な記載内容 設計・開発事業者が参加すべき会議、開催頻度、議事録などの管理
NO 3
目次 体制管理
主要な記載内容 作業体制の管理手法
NO 4
目次 工程管理
主要な記載内容 設計、開発の作業、工程の管理手法
NO 5
目次 品質管理
主要な記載内容 品質基準、品質管理方法
NO 6
目次 リスク管理
主要な記載内容 リスクを提示する際の手順や報告様式
NO 7
目次 課題管理
主要な記載内容 課題を提示する際の手順や報告様式
NO 8
目次 システム構成管理
主要な記載内容 ハードウェアやソフトウェア製品、ネットワークなどの各資産における管理項目
NO 9
目次 変更管理
主要な記載内容 管理対象、変更手順、管理手法
NO 10
目次 情報セキュリティ管理
主要な記載内容 情報セキュリティ確保に必要な対策
設計・開発実施計画書
プロジェクト・業務・情報システムの概要や実施するに当たり手順や内容をまとめたものを記載します。
NO 1
目次 はじめに
主要な記載内容 プロジェクト、業務、情報システムの概要
NO 2
目次 作業概要
主要な記載内容 設計・開発の対象範囲、作業概要
NO 3
目次 作業体制に関する事項
主要な記載内容 作業内容および関係者間の関係性、役割分担、責務
NO 4
目次 スケジュールに関する事項
主要な記載内容 作業内容およびスケジュール、マイルストーン
NO 5
目次 成果物に関する事項
主要な記載内容 成果物、品質基準、担当者、納入期限、納入方法、納入部数、構成、内容
NO 6
目次 開発形態、開発手法、開発環境、開発ツールなど
主要な記載内容 開発形態、開発手法、開発環境、開発ツール
NO 7
目次 そのほか
主要な記載内容 設計・開発の実施の事情に応じて必要な事項
実施計画書のスケジュールに関する事項で作成するスケジュール例を紹介します。
設計・開発の大部分の作業は事業者が行いますが、発注者が適切に関わらないと品質が落ちる可能性が高くなります。テストには、「単体テスト」、「結合テスト」、「総合テスト」などがあります。
ここでは、「受入テスト」例を紹介します。受入テストは、システムの妥当性を検証（ユーザーの要件や期待に合致しているか否か、システムが正しく機能するか）、バグや不具合の検出、ユーザーの満足度向上（ユーザーがシステムを実際に操作することによって、使いやすさや機能性に関するフィードバックを得る）のために実施します。
NO 1
目次 はじめに
主要な記載内容 プロジェクト、業務、情報システムの概要
NO 2
目次 テスト体制
主要な記載内容 体制、役割、責任範囲
NO 3
目次 テスト環境
主要な記載内容 実施場所、環境、ツール、前提条件
NO 4
目次 作業内容
主要な記載内容 テスト対象、実施手順、確認・検証事項
NO 5
目次 作業スケジュール
主要な記載内容 全体スケジュール、各工程の作業スケジュール
NO 6
目次 テストシナリオ
主要な記載内容 確認・検証事項、テスト結果の予測
NO 7
目次 合否判定基準
主要な記載内容 品質基準、合否判定基準
21-1-5. サービス・業務の運営と改善
新しいシステムや業務プロセスを導入した後、それを定着させ、継続的に改善していくことは、中小企業の競争力維持に不可欠です。
情報システムの設計・開発のリリースが近づいたところで、研修教育資料（業務マニュアルなど）を用いて、実業務を担当する従業員に対して教育を実施します。
ECサイト運営における業務マニュアル作成例と、作成に当たっての注意点を解説します。
ECサイトの運営業務は、大きく「フロントエンド業務」と「バックエンド業務」の2つに分けられます。
商品の企画や仕入れ、マーケティング、ECサイトの制作など、主に「集客や商品の売上につながる業務」のことを指します。
フロントエンド業務の例
・ 商品管理
商品の情報をECサイトに登録し、在庫数と公開設定を行います。
・ 注文処理
受注管理画面で注文を確認し、出荷準備を行い、配送状況を更新します。
・ 顧客対応
顧客からの問い合わせや返品・交換リクエストに対応します。
・ プロモーション管理
割引キャンペーンや特別オファーを設定し、広告バナーを作成して配置します。
・ コンテンツ更新
ブログやニュースの投稿を行い、サイトデザインの変更を実施します。
商品情報の登録や受注管理、出荷、アフターサポートなど、「販売を支え、お客様の満足度を高める業務」のことを指します。
バックエンド業務の例
・ 受注処理
顧客からの注文内容を確認し、在庫や決済状況をチェックした上で、注文ステータスを更新します。
・ 在庫管理
在庫状況を定期的に確認し、補充や棚卸しし、新入荷商品のシステム登録を行います。
・ 出荷作業
出荷リストに基づいて商品を梱包し、発送準備を整えて集荷を依頼します。
・ 配送作業
商品の配送状況を追跡し、問題が発生した場合には配送業者と連絡を取り、顧客に対応します。
・ アフターサービス
返品や交換、顧客クレームに迅速に対応し、顧客満足度を維持します。
バックエンド業務のマニュアル例を紹介します。
バックエンド業務マニュアル（例）
1.目的
このマニュアルは、ECサイトのバックエンド業務に関する標準手順を提供し、業務の効率化と品質向上を目的とします。
2.業務の流れ
2.1受注処理
目的:顧客からの注文を迅速かつ正確に処理します。
1.注文確認:
・ 毎日午前10時と午後3時にシステム内の「注文管理」画面を確認し、すべての新しい注文をリスト化します。
・ 各注文の内容（商品名、数量、配送先）を確認し、備考欄に特記事項があればそれに従います。
2.決済確認:
・ 決済状況を確認し、「支払い済み」ステータスでない場合は、決済プロセスをチェックします。
・ 決済エラーが発生した場合、顧客に連絡し、再決済や別の支払い方法を提案します。
3.在庫確認:
・ 各注文の商品の在庫数をシステム上で確認し、在庫切れが発生していないかを確認します。
・ 在庫が不足している場合、直ちに仕入れ担当者に連絡し、在庫補充を手配します。
4.ステータス更新:
注文ステータスを「処理中」に変更し、システムに自動的に反映されるよう設定します。
2.2在庫管理
目的:適切な在庫管理を行い、欠品を防ぎます。
1.在庫確認:
・ 毎週月曜日の午前にシステムで在庫状況を確認します。特に在庫が少ない商品に対しては自動アラートを設定し、タイムリーに補充が行えるようにします。
・ 在庫が特定の数値以下になった場合は、即時に仕入れ担当に通知され、発注が行われます。
2.棚卸し:
・ 月末に物理的な在庫とシステム上の在庫を照合し、差異がないか確認します。
・ 差異が発見された場合は、原因を特定し、システム上で修正します。
3.新入荷処理:
・ 新しく入荷した商品が届いた場合、納品書と実際の在庫数を確認し、商品の状態をチェックします。
・ 問題がなければ、システムに入荷処理を行い、在庫数を更新します。
2.3出荷作業
目的:顧客に正確かつ迅速に商品を届けます。
1.出荷指示:
・ システムの「出荷準備」画面から、当日の出荷リストを取得します。
・ 各商品を倉庫から取り出し、ピッキングリストに従って確認します。
2.梱包:
・ 商品が破損しないよう、適切なサイズの梱包材を使用して商品を梱包します。
・ 伝票（納品書や配送伝票）を正しく同梱し、配送業者のステッカーを貼り付けます。
3.発送準備:
発送業者に集荷依頼を出し、翌日集荷の確認が取れたら、システムで発送ステータスを「発送済み」に更新します。
2.4配送作業
目的:配送状況を確認し、顧客に確実に商品を届けます。
1.配送確認:
・ 発送業者の追跡システムで、すべての配送中の商品のステータスを確認します。
・ 配送中に問題が発生した場合は、業者に連絡し、問題解決を図ります。
2.追跡番号連絡:
配送後、システム上で自動生成された追跡番号を、顧客にメールで通知します。
3.問題対応:
配送トラブルが発生した場合は、迅速に配送業者と連絡を取り、顧客に問題が解決する見通しを通知します。
2.5アフターサービス
目的:顧客満足度を向上させ、リピーターを増やします。
1.返品対応:
・ 顧客から返品リクエストがあった場合、商品の状態を確認し、返品の可否を決定します。
・ 返品が承認された場合、システム上で返金処理を行い、顧客に返金確認メールを送ります。
2.交換手続き:
不良品や誤配送が発生した場合、代替商品の発送手配を行い、顧客に交換手続きの詳細を案内します。
3.クレーム対応:
・ 顧客からのクレームがあった場合、可能な限り迅速に対応し、問題解決を目指します。
・ 必要に応じて、社内での対応策を共有し、再発防止策を講じます。
業務マニュアル作成時の注意点
・ 業務マニュアルは、同じ業務に携わる担当者が共通の理解を持つために有効ですが、組織や取扱う情報の種類によっては、同じ業務でも異なるルールが存在する場合があります。いわゆる、ローカルルールと呼ばれるものです。これをすべて業務マニュアルに記載しようとすると、膨大な量となり、マニュアルの更新が追いつかず、現場とのかい離が発生するおそれがあります。同じ業務内で共通化するものと、組織ごとに個別に定めるものとで分けて業務マニュアルを作成することで、その後の保守性を向上させることができます。
・ 業務マニュアルは、そのまま従業員向けの教育資料の一部とすることができます。そのことを念頭に、業務マニュアルの内容・構成を検討してください。
・ 業務マニュアルには、具体的なシステムの操作手順にとらわれず、業務の流れや手順を中心に記述してください。その流れの説明において、情報システムのどの機能を使うのか、がわかれば、使いやすいものになります。情報システムの操作手順や画面説明の詳細はシステム用のマニュアルに任せることで、マニュアルの品質を上げることができます。
・ 業務マニュアルは業務全体の業務フローを理解している従業員が作成、またはレビューすることが重要です。マニュアル上の業務説明が途中で途切れたり、内容の重要性に偏りが出たりすることが防げます。マニュアルができ上がったら、業務に初めて携わる従業員がそのマニュアルを読んで業務が行えるか、という観点でチェックすることが重要です。
サービス・業務を運営していく中で発生するさまざまな情報を集め、改善に向けた取組につなげていきます。情報システムの見直しが必要なものは「サービス・業務企画」に立ち戻り、運用保守の見直しが必要なものは「運用および保守」に立ち戻ります。これらに該当しないものは、日常的な改善として対応していく必要があります。具体的には次のようなものに該当します。
日常的に実施する改善事項の例
・ 業務の見直し
情報システムに影響を与えない範囲であれば、日常的に実施が可能です。定期的な改善を検討し、その結果は業務手順書などに反映させることが大切です。
・ 教育・訓練の見直し
具体的には教育資料の改訂やカリキュラムの改訂に相当します。現状の分析結果を踏まえて、より従業員に遡及できるような教育内容に作り替えていくことが大切です。
・ モニタリングの見直し
日常的に把握すべき指標とその仕組みの見直しに相当します。KPIで取るべき指標値は、業務の状況に応じて変更しても構いませんので、それに応じて値の取得方法や内容を見直し、現状を正確に把握できるようにすることが大切です。
そのほか、利用者からの問い合わせが多い機能や操作などについては、マニュアルの改善やFAQに情報を追加・更新することで改善が図れるため、適宜改善を検討することが大切です。
外部委託先でセキュリティ対策が確実に実施されるよう、外部委託先に委託する自社のセキュリティ対策を、選定時には実施可能かを確認するとともに、運用時においても継続的に実施状況を確認してください。確認すべきセキュリティ対策は以下の通りです。
・ セキュリティ対策要件（運用時）の要件1～5の実施状況を定期的に確認してください。
・ 確認頻度の目安としては、以下を参考にしてください。
> （要件1の確認頻度）随時
> （要件2の確認頻度）プラットフォーム診断は、少なくとも四半期に1回程度
Webアプリケーション診断は、新機能の開発や追加やシステム改修などを行ったタイミングで実施
> （要件3の確認頻度）少なくとも週に1回程度
> （要件4の確認頻度）少なくとも週に1回程度
> （要件5の確認頻度）少なくとも週に1回程度
要件1
セキュリティ対策要件（運用時） サーバおよび管理端末などで利用しているソフトウェアをセキュリティパッチなどにより最新の状態にする。
区分 必須
自社で対応可能な要件
外部委託の活用で対応すべき要件
要件2
要件3
セキュリティ対策要件（運用時） Webサイトのアプリケーションやコンテンツ、設定などの重要なファイルの定期的な差分チェックや、Webサイト改ざん検知ツールによる監視を行う。
区分 必須
自社で対応可能な要件
外部委託の活用で対応すべき要件
要件4
セキュリティ対策要件（運用時） システムの定期的なバックアップの取得およびアクセスログの定期的な確認を行い不正アクセスなどがあればアクセスの制限などの対策を実施する。
区分 必須
自社で対応可能な要件
外部委託の活用で対応すべき要件
要件5
セキュリティ対策要件（運用時） 重要な情報はバックアップを取得する。
区分 必須
自社で対応可能な要件
外部委託の活用で対応すべき要件
要件6
要件7
セキュリティ対策要件（運用時） サイバー保険に加入する。
区分 推奨
自社で対応可能な要件
外部委託の活用で対応すべき要件
21-1-6. 運用および保守
システムの安定稼動と継続的な改善は、中小企業にとっても重要です。適切な運用・保守計画を立て、定期的に見直すことで、長期的なコスト削減と効率化が図れます。
運用・保守を担当する事業者が決まったら、事業者とともに調達仕様書で示した内容から、運用・保守の詳細な作業内容や実施方法などを検討し、計画書と実施要領として明文化します。運用・保守の作業はこの計画に基づいて実施することになるため、作業が漏れたり不十分だったりすると後々問題を引き起こすこともあるため、注意が必要です。
運用計画書の作成
運用計画書には、以下のような内容を記載します。
NO 1
目次 はじめに
主要な記載内容 プロジェクト、業務、情報システムの概要
NO 2
目次 作業概要
主要な記載内容 運用作業の対象範囲、作業概要
NO 3
目次 作業体制に関する事項
主要な記載内容 定常時およびインシデント発生時の体制
NO 4
目次 スケジュールに関する事項
主要な記載内容 運用業務の年次、四半期ごと、月次、週次、日次などのスケジュール
NO 5
目次 成果物に関する事項
主要な記載内容 成果物、担当者、納入期限、納入方法、納入部数、納入場所など
NO 6
目次 運用形態、運用環境など
主要な記載内容 運用において採用する運用形態（オンサイト、リモートなど）、定常時および障害発生時における運用環境（本番環境、検証環境、研修環境などの有無）など
NO 7
目次 そのほか
主要な記載内容 運用を行う上で留意すべき前提条件、運用の時間や予算、品質などに関する制約条件
保守計画書の作成
NO 1
目次 はじめに
主要な記載内容 プロジェクト、業務、情報システムの概要
NO 2
目次 作業概要
主要な記載内容 保守作業の対象範囲、作業概要
NO 3
目次 作業体制に関する事項
主要な記載内容 定常時およびインシデント発生時の体制
NO 4
目次 スケジュールに関する事項
主要な記載内容 提案書などの内容、保守事業者からの情報提供などを踏まえた保守業務のスケジュール
NO 5
目次 成果物に関する事項
主要な記載内容 成果物、担当者、納入期限、納入方法、納入部数、納入場所など
NO 6
目次 保守形態、保守環境など
主要な記載内容 保守において採用する保守形態（オンサイト、リモートなど）、アップデートファイル（セキュリティパッチなど）の適用前テストなどを行う検証環境など
NO 7
目次 そのほか
主要な記載内容 保守を行う上で留意すべき前提条件、保守の時間や予算または品質などに関する制約条件
運用・保守の改善は、継続的に実施していきます。改善の内容には定常的な作業の範囲内で実施できるものもあれば、契約更新や事業者の交代、ライセンスの切れ目やハードウェアの交換でしか対応ができないものなど、さまざまなものがあります。これらは、対応できるタイミングが同一にはなりませんので、以下の点に留意して、確実に改善につなげるようにします。
改善を管理するポイント
・ 運用・保守の定常的な作業内で解決が難しい課題は、「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」の第8章「サービス・業務の運営と改善」内の問題管理として、どのタイミングで対応するかを明確に管理する。
・ 現行の運用・保守契約期間では対応することが難しい大規模の改善については次回の契約において対応せざるを得ないものもあるので、改善のための予算規模やスケジュールなどについて計画を立て、関係者と事前調整を行うなど、早期から準備を進めておくことが重要である。
ECサイトを運営中の場合においては、いつサイバー被害に遭ってもおかしくない状況を回避または、改善することが必要です。
取組1.過去を振り返って、これまでのセキュリティ対策が不十分ではないか自己点検する。
IPAが公開している「安全なウェブサイトの作り方」や、「ECサイト構築・運用セキュリティガイドライン」の付録にあるECサイトの構築時や運用時における講じるべきセキュリティ対策要件をまとめたチェックシートを活用して、自社のECサイトにおけるセキュリティ対策の自己点検を行ってください。
取組2.セキュリティ対策が不十分であることがわかり、対策までに時間がかかる場合、対策までのサイバー被害リスクを減らすため、応急処置を行う。
セキュリティ対策が不十分であることがわかり、対策実施には時間がかかる場合、その間の攻撃リスクを減らすため、応急処置（例：WAF実装、サイバー保険への加入）を実施してください。
なお、サイバー保険については、さまざまな種類・プランがあり、万が一の際の補償内容・金額やカバーされる脅威の範囲はもとより、事業性（売上高など）やセキュリティ対策状況、過去のインシデント被害経験などにより保険料が決まるため、詳細は保険会社にご確認ください。
取組3.セキュリティ対策の不十分な箇所を対策する。
セキュリティ対策の不十分な箇所を対策し、あわせて、長期的（ECサイトの運用を継続する期間）なトータルコストを評価し、SaaS型サービスやモール型サービスの利用も検討してください。
事業者が交代すると知識やドキュメント化されていない情報が抜け落ちてしまうことで作業効率が下がるリスクがあります。場合によっては、事業者が情報を持ち逃げするリスクもあり、持ち逃げされた情報を取り戻すために費用が発生するような場合もあります。このような事態を避けるためにも、従業員や運用・保守事業者の交代時には、以下の点に注意して、情報が抜け落ちてしまうことを防ぐことが重要です。
従業員や事業者の交代の際に気を付ける点
・ 計画時点で作業に対する成果物を明確化する。作業を実施する場合は、基本的に作業手順書を作成し提出するよう、合意する。
・ 中間成果物となるようなドキュメント・コンテンツは、維持が必要なもの、維持が必要ないものを明確にしていく。
・ 運用・保守作業に関係する事項は、従業員や事業者の特定の担当者が抱え込むことなく、必ずその作業を担当する事業者が管理するドキュメントに記載し管理する。
