SaaSの非機能要件とは｜6分類・SLA・共有責任モデルと選定チェックリスト

SaaSの非機能要件とは、サービスが「何をするか」ではなく、「どの水準で、どのような条件のもとで動くか」を定めた要件のことです。可用性・性能・運用保守・移行性・セキュリティ・システム環境の6分類で整理でき、SaaSでは自社で作り込むのではなく、事業者が公開するSLAや仕様を読んで選びます。「月末に遅くなる」「障害時の連絡が来ない」「解約したらデータを取り出せない」といった問題は、機能表には載らないこの部分の確認不足から起きます。本記事では、IPA「非機能要求グレード」の6分類のSaaSへの当てはめ方、共有責任モデルとSLAの確認ポイント、稼働率や応答速度の数値の読み方、選定時のチェックリスト、よくある失敗パターンまでを、情報システム部門の担当者向けに解説します。

目次

開く

閉じる

1. 非機能要件の確認結果を利用部門に伝える｜周知と理解確認の仕組み
2. SaaSの非機能要件とは｜6分類の整理
3. 共有責任モデルとSLA確認のポイント
4. SaaS特有の数値目標例｜稼働率・応答速度
5. 非機能要件チェックリストの実務上の注意点
6. 非機能要件確認でよくある失敗パターン
7. よくある質問(FAQ)
8. まとめ
9. 参考文献

非機能要件の確認結果を利用部門に伝える｜周知と理解確認の仕組み

SaaSの非機能要件は、選ぶ段階で確認するだけでなく、自社で補うルールを利用部門に伝え、理解されているかを確かめて初めて役に立ちます。

SaaSでは、稼働率やバックアップの方式を自社の都合で変えることはできません。事業者の水準で足りない部分は、「共有リンクを社外に公開しない」「退職者のアカウントをすぐ止める」といった運用ルールで補うことになります。そのルールを実際に守るのは、情報システム部門ではなく、日々の設定や権限付与を行う利用部門の社員です。非機能要件の6分類や共有責任モデルは後半の見出しで順に説明します。ここでは先に、確認した結果を現場に伝える仕組みを整理します。

ルールを資料で配布したり、全社メールで流したりするだけでは、読まれたかどうかも理解されたかどうかも分かりません。研修コースにまとめて配信し、受講状況や確認テストの結果を管理画面で追えるeラーニングシステムは、この周知と理解確認を担う方法の1つです。役割の違う3つのサービスを、次の表で比べます。

SaaSごとに決めた運用ルールや設定手順を、そのまま自社の研修コースにしたい場合の一例が、Smart Boarding(株式会社FCE)です。自社オリジナルのコースを作成でき、学習の進捗も管理できるため、内定者・新人教育から管理職の育成まで幅広い場面で使えます。属人化を防ぎ、いつでも何度でも学べる環境をつくれる点も特徴です。一方で、電話・メール相談や教育プログラムの設計といった手厚いサポートは、「充実サポートプラン」のみで受けられます。SaaSの利用ルールそのものを扱う教材かどうかは、資料で確認してください。料金はプランによって異なるため、資料や公式サイトで確認してください。

【自社オリジナルコンテンツ】と【FCEプログラム】を活用した自社独自の学習コースを作成

Smart Boarding 導入事例(株式会社ミツハシ)の見出し 出典：導入事例ページ

SaaSの非機能要件とは｜6分類の整理

SaaSの非機能要件とは、サービスが「何をするか」ではなく「どの水準で、どのような条件のもとで動くか」を定める要件です。止まりにくさ、速さ、運用のしやすさ、データの出し入れ、守りの強さ、動作環境などが含まれます。

機能要件が「請求書を発行できる」「承認フローを組める」といった業務の中身を表すのに対し、非機能要件は「月末の締め日にも数秒で画面が開く」「障害が起きたら何時間以内に復旧する」といった品質の条件を表します。機能要件は業務部門が思いつきやすい一方、非機能要件は誰も言い出さないまま契約に進みやすいのが特徴です。

機能要件と非機能要件の違いをSaaSの例で見る

SaaSの選定では、機能要件は「何ができるか」、非機能要件は「どの水準でできるか」と見分けると整理しやすくなります。請求書を管理するSaaSを例にすると、次のように分かれます。システム開発やERPの開発側から見た解説は、お名前.comビジネスコンシェルジュの非機能要件の解説記事もあわせて参考になります。

観点	機能要件	非機能要件
定めること	業務のために、サービスができること	サービスが動く水準と条件(速さ、止まりにくさ、守り、データの出し入れなど)
請求書管理SaaSの例	請求書を発行できる、承認フローを組める	月末の締め日にも画面がすぐ開く、障害時に通知が届く、解約時にデータを取り出せる
確認の方法	機能一覧、デモ、トライアルで確認する	SLA、利用規約、セキュリティの公開資料、トライアル、ベンダーへの質問で確認する
抜けやすさ	業務部門が思いつきやすい	誰も言い出さないまま契約に進みやすい

機能要件が満たされていても、非機能要件の確認が抜けていれば、使い始めてから業務が止まったり、解約時に困ったりします。

IPA「非機能要求グレード」の6大項目

非機能要件を漏れなく洗い出す物差しとして広く参照されているのが、IPAが公開している「非機能要求グレード」です。もともとは情報システムを構築する際に、発注者と開発者が非機能要件の水準をすり合わせるためのツールで、6つの大項目に分けて整理されています。

大項目	意味	SaaS選定での確認例
可用性	サービスを継続して利用できるか	SLAの稼働率、計画メンテナンスの頻度と時間帯、障害時の復旧目標、データセンターの冗長化
性能・拡張性	速さと、利用規模の拡大への追従	画面応答やAPIの速度、データ件数や利用者数の上限、API呼び出し回数の制限
運用・保守性	日々の運用と保守のしやすさ	サポート窓口の受付時間、障害通知の方法、バックアップの取得頻度と保持期間、バージョンアップの事前告知
移行性	現行システムからの移行と、将来の乗り換え	データの一括インポート、エクスポートの形式、解約後のデータ保持期間と削除証明
セキュリティ	情報を守る仕組み	シングルサインオン(SSO)、多要素認証、IPアドレス制限、操作ログ、第三者認証の取得状況
システム環境・エコロジー	動作環境や設置環境の条件	対応ブラウザやOS、スマートフォン対応、データの保管国(リージョン)、使用言語

既存の多くの解説記事は、この6分類を「要件定義で何を決めるか」という開発者向けの視点で説明しています。しかし、SaaSを導入する利用企業の立場は少し異なります。次の項目で、その違いを整理します。

クラウド・SaaSでは「要求する」から「確認して選ぶ」に変わる

自社でシステムを構築する場合、非機能要件は「こうしてほしい」と開発者に要求し、設計に反映してもらうものです。一方、SaaSをはじめとするクラウドサービスは、多数の企業が同じ仕組みを共同で使うため、1社の要望に合わせて稼働率やバックアップの方式を変えることは基本的にできません。利用企業にできるのは、事業者が公開している水準を読み、自社の許容範囲と比べて「選ぶか、選ばないか」を判断することです。

そのため、SaaS選定における非機能要件の作業は、次の3段階で考えると進めやすくなります。

1. 自社の許容範囲を決める(どのくらい止まったら業務が回らないか、どの情報を扱うか)
2. 事業者の公開情報(SLA、利用規約、セキュリティホワイトペーパー、第三者認証)で水準を確認する
3. 公開情報で足りない部分は、トライアルやベンダーへの質問で埋め、差分は運用ルールでカバーする

とくに3番目の「運用ルールでカバーする」部分は見落とされがちです。サービス側で対応できない水準を、社内の手順や利用者への教育で補う発想を持っておくと、選定の幅が広がります。候補のSaaSを比べるときの評価軸は、SaaS比較の正しい方法｜景表法に配慮した選び方と評価軸でも整理しています。

6分類のうち、SaaSで特に重みが増す項目

6分類はどれも重要ですが、SaaSの性質上、重みが変わる項目があります。システム環境・エコロジーのうち、サーバーの設置場所や電力といった物理面は事業者の管理範囲になるため、利用企業が細かく確認する必要性は下がります。その代わり、データの保管国や対応ブラウザのように、自社の規程や利用環境に直結する部分は引き続き重要です。

逆に重みが増すのが移行性です。自社構築であればデータベースを直接扱えますが、SaaSではデータを取り出す手段が事業者の用意した機能に限られます。エクスポートできない項目があったり、添付ファイルは一括で取り出せなかったりすると、将来の乗り換えや解約時に大きな負担になります。いわゆるベンダーロックインを避けるためにも、移行性は契約前に確認しておきたい項目です。

3つのモデルシステムで「求める水準」の目安をつける

非機能要求グレードには、どのくらいの水準を求めるべきかの目安として、システムが止まったときの社会的な影響の大きさで分けた3つのモデルシステムが用意されています。いちばん近いモデルを1つ選び、それを出発点に各項目の水準を調整する使い方です。

モデルシステム	IPAが示すイメージ	SaaS選定での当てはめ例
社会的影響がほとんど無いシステム	特定部門が限られた範囲で使い、止まっても影響がその部門にとどまるもの	部署内の情報共有やタスク管理に使うツール
社会的影響が限定されるシステム	企業活動の基盤で、止まると自社に加えて取引先や顧客にも影響するもの	会計、販売管理、受発注、顧客管理など基幹業務に使うサービス
社会的影響が極めて大きいシステム	国民生活や社会経済活動の基盤で、止まると社会全体に大きな影響を与えるもの	不特定多数が使う社会インフラ向けの仕組み(一般的な企業のSaaS選定では対象になりにくい)

SaaSを導入する一般的な企業であれば、多くのツールは前の2つのどちらかに当てはまります。導入を検討しているサービスごとに「止まったら影響は部署内で収まるか、取引先や顧客にまで及ぶか」を先に決めておくと、後で説明するSLAや稼働率の数字を読むときに、自社にとって十分かどうかを判断しやすくなります。

水準は情報システム部門だけで決めない

「どのくらい止まったら業務が回らないか」「どの情報までなら載せてよいか」は、技術の問題ではなく業務への影響で決まります。たとえば経理部門が月末に使うサービスと、部署内の情報共有ツールでは、許容できる停止時間が違います。選定の早い段階で、利用部門や管理部門と次の3点を確認しておくと、後から基準が食い違うことを防げます。

1. 止まったときに困る業務と、許容できる停止時間
2. 載せる情報の種類と、社外に出てはいけない範囲
3. 水準を上げるために増える費用や運用の手間(上位プランへの切り替え、運用ルールの追加など)を、どこまで許容するか

一般に、水準を高くするほど費用や運用の手間も増えます。すべての項目を最高水準にそろえるのではなく、業務への影響が大きい項目に絞って基準を決めることが、現実的な選定につながります。

共有責任モデルとSLA確認のポイント

SaaSの非機能要件を確認するうえで欠かせないのが、共有責任モデルとSLA(サービスレベル合意)の2つです。共有責任モデルで「誰が何を守るのか」を整理し、SLAで「事業者がどの水準を約束しているのか」を読むという順番で進めます。

共有責任モデルで「自社の担当範囲」を整理する

共有責任モデルとは、クラウドサービスのセキュリティや運用について、事業者と利用者の責任範囲を分けて考える枠組みです。IaaS、PaaS、SaaSの順に事業者の担当範囲が広くなり、SaaSではアプリケーションまで事業者が管理します。ただし、SaaSであっても利用者の責任がなくなるわけではありません。

領域	主な責任者(SaaSの場合)	利用企業が確認・実施すること
データセンター・物理設備	事業者	第三者認証や監査報告書で管理状況を確認する
ネットワーク・サーバー・OS	事業者	冗長化や脆弱性対応の方針を公開情報で確認する
アプリケーション	事業者	バージョンアップの告知方法や、障害時の連絡手段を確認する
アカウント・権限・認証設定	利用企業	多要素認証の有効化、権限の最小化、退職者アカウントの停止、定期的な棚卸し
入力・保存するデータ	利用企業	どの情報を載せてよいかの社内ルール、共有範囲の設定、必要に応じた独自バックアップ
利用端末・接続環境	利用企業	端末の管理、社外ネットワークからの接続ルール、IPアドレス制限の設定

情報漏えいの原因として、共有リンクの公開範囲や権限の設定ミスが挙げられることは少なくありません。これらは事業者ではなく利用企業の担当範囲です。非機能要件のうちセキュリティを確認する際は、「サービスが何を備えているか」だけでなく、「その機能を自社が正しく設定し、使い続けられるか」までを1セットで考える必要があります。

SLAで確認したい5つの項目

SLAは、事業者が提供するサービスの品質水準を利用者と取り決めたものです。経済産業省は「SaaS向けSLAガイドライン」で、SaaSの利用者と事業者が合意すべきサービスレベルの項目例を示しています。実務では、少なくとも次の5項目を確認しておくと判断しやすくなります。

項目	確認すること	見落としやすい点
稼働率	月間または年間の目標値と、その算出方法	計画メンテナンスを停止時間に含めない定義になっていることが多い
障害時の対応	障害の検知から通知までの時間、通知手段、復旧目標	通知先が管理者1人だけで、担当者不在時に誰も気づかない
サポート	受付時間、問い合わせ手段、初回回答までの目安	上位プランでないと電話や夜間の対応を受けられない
データ保護	バックアップの頻度・保持期間、利用者の誤操作による削除からの復元可否	事業者のバックアップは障害復旧用で、個別の復元依頼には応じないことがある
未達時の扱い	目標未達時の返金やクレジット付与の有無と申請方法	利用者からの申請が必要で、期限を過ぎると受けられない

SLAは「保証値」として契約上の約束になっている場合と、「目標値」として努力目標にとどまる場合があります。同じ数字でも意味が異なるため、利用規約やSLAの文書で位置づけを確認してください。また、無料プランや下位プランにはSLAが設定されていないことも多く、業務の中核で使う場合はプランの選択自体が非機能要件の判断になります。なお、契約内容の法的な解釈について判断が必要な場合は、法務部門や専門家に相談してください。

SLA・SLO・SLIの違い

SLAと並んで、SLOやSLIという言葉が使われることがあります。GoogleのSRE(サイト信頼性エンジニアリング)の解説では、SLIはサービスの振る舞いを測る指標、SLOはその指標について定める数値目標、SLAは利用者への約束で、水準を満たせなかった場合に利用料金の一部返金などの対応を伴うものとして整理されています。

用語	意味	SaaS選定での見方
SLI	サービスの状態を測る指標(成功したリクエストの割合など)	事業者が障害情報のページなどで、どの指標を公開しているか
SLO	指標について定める数値目標(例:月間の稼働率99.9%)	努力目標なのか、契約上の保証なのかを区別する
SLA	利用者への契約上の約束。未達時の返金などを伴うことがある	稼働率の算出方法、停止に数えない範囲、未達時の申請方法

同じ解説では、SLAの数値は事業者が内部で持つSLOより緩く設定されるのが通常とされています。利用企業が契約上頼れるのはSLAの数値であり、SLOは事業者の目標にとどまる場合があります。公開されている数字がどちらにあたるのかを、文書で確認してください。

第三者認証とISMAPの活用

セキュリティの水準を利用企業が1社ずつ監査するのは現実的ではありません。そこで参考になるのが、ISO/IEC 27001やISO/IEC 27017などの第三者認証、SOC2などの保証報告書です。政府機関向けには、政府情報システムのためのセキュリティ評価制度(ISMAP)があり、一定のセキュリティ基準を満たしたクラウドサービスが登録簿として公開されています。

民間企業にISMAP登録サービスの利用義務はありませんが、登録の有無は客観的な判断材料の1つになります。ただし、認証や登録はあくまで「事業者側の管理体制」を示すもので、利用企業側の設定や運用の正しさまでは保証しません。共有責任モデルの整理とあわせて使うことが大切です。

SaaS特有の数値目標例｜稼働率・応答速度

非機能要件を比べるときは、「高可用性」「高速」といった言葉ではなく、数値で比べることが基本です。ここでは、SaaSで扱われることの多い数値の読み方を整理します。

稼働率を「止まってよい時間」に換算する

稼働率は小数点以下の差が小さく見えますが、停止時間に換算すると差がはっきりします。30日の月を前提に計算すると、次のとおりです。

稼働率	1か月(30日)の許容停止時間の目安	1年の許容停止時間の目安
99.0%	約7時間12分	約3日15時間
99.5%	約3時間36分	約1日19時間
99.9%	約43分	約8時間46分
99.95%	約22分	約4時間23分
99.99%	約4分	約53分

※単純計算による目安です。実際の算出方法(計画メンテナンスの扱い、集計単位など)は各サービスのSLAで確認してください。

大切なのは、数字の高さそのものより「自社の業務がどのくらいの停止に耐えられるか」と照らし合わせることです。社内の情報共有ツールなら数十分の停止は許容できても、受注や決済に使うサービスでは同じ停止が売上に直結します。また、平日の日中に止まるのか、深夜に止まるのかでも影響は大きく変わります。計画メンテナンスの時間帯が自社の業務時間と重ならないかも、あわせて確認しましょう。

応答速度と上限値は「自社の使い方」で測る

応答速度は、稼働率ほどSLAで明示されることが多くありません。そのため、事業者の公開値だけで判断するより、トライアル期間中に自社のデータ量・利用人数に近い条件で試すほうが実態をつかめます。確認したい観点は次のとおりです。

• よく使う画面(一覧表示、検索、帳票出力)が、業務上ストレスのない時間で開くか
• 月末・期末など、処理が集中する時期を想定した件数でも速度が落ちすぎないか
• データ件数、ファイル容量、ユーザー数、API呼び出し回数に上限がないか、上限を超えたらどうなるか
• 他システムと連携する場合、APIの応答速度や同時実行数の制限が連携処理に影響しないか

性能・拡張性は「今の規模」だけでなく「3年後の規模」で考えるのがポイントです。利用者数やデータ量が増えたときに、上位プランへの切り替えで対応できるのか、それとも製品の上限に当たってしまうのかで、長期的な選択は変わります。

復旧の目標はRTOとRPOで考える

障害やデータ消失からの回復は、RTO(目標復旧時間)とRPO(目標復旧時点)の2つで考えます。RTOは「どのくらいの時間で使える状態に戻るか」、RPOは「どの時点のデータまで戻せるか」を表します。たとえばバックアップが1日1回なら、最悪の場合は直近1日分の入力が失われる可能性があります。

SaaS事業者がRTOやRPOを明示していない場合もあります。その場合は、失われると困るデータについて、定期的なエクスポートや別サービスへの自動連携など、自社側で追加のバックアップを取る運用を検討しましょう。これも共有責任モデルでいう「利用企業の担当範囲」の一部です。

非機能要件チェックリストの実務上の注意点

ここまでの内容を、SaaS選定時に使えるチェックリストにまとめます。すべての項目を最高水準で満たすサービスを探すのではなく、自社にとって「必須」「できれば」「不要」を先に仕分けてから確認するのが実務的な使い方です。導入前の確認項目をさらに広く整理したSaaSおすすめはどう選ぶ？導入前チェックリスト10項目もあわせて使えます。

分類	チェック項目	主な確認先
可用性	SLAの稼働率と算出方法、計画メンテナンスの時間帯、障害情報の公開ページの有無	SLA、ステータスページ
性能・拡張性	主要画面の応答速度、データ件数・容量・ユーザー数・APIの上限、上位プランでの拡張方法	トライアル、料金プラン表、API仕様書
運用・保守性	サポートの受付時間と手段、障害通知の宛先設定、バックアップの頻度と保持期間、仕様変更の告知期間	サポートページ、利用規約
移行性	初期データの一括取り込み、エクスポートできる項目と形式、解約後のデータ保持期間と削除方法	ヘルプページ、利用規約、ベンダーへの質問
セキュリティ	SSO・多要素認証・IPアドレス制限への対応、権限の細かさ、操作ログの取得と保存期間、第三者認証	セキュリティホワイトペーパー、認証の登録情報
システム環境	対応ブラウザ・OS・スマートフォン、データの保管国、画面や通知の対応言語	動作環境ページ、利用規約

トライアルで試しておく非機能の確認項目

公開情報だけでは分からない項目は、トライアル期間中に実際に操作して確かめます。期間が限られる場合は、エクスポート、権限、通知の設定から優先して試すと、契約後の想定外を減らせます。

• 自社の件数に近いテストデータで、一覧表示・検索・帳票出力の速さを確かめる
• 実際にエクスポートを行い、出力できる項目・形式と、添付ファイルや履歴の扱いを確かめる
• 権限の設定を試し、閲覧のみ・承認のみなど、必要な区分を作れるかを確かめる
• 多要素認証やIPアドレス制限を、契約予定のプランで設定できるかを確かめる
• 障害通知の宛先に、複数の担当者を登録できるかを確かめる

チェックリストを形骸化させない3つの工夫

チェックリストは作っただけでは機能しません。実務で使い続けるために、次の3点を意識してください。

1つ目は、確認結果に「根拠」を残すことです。「対応あり」とだけ書くのではなく、どの公開ページや回答メールで確認したかを記録しておくと、後から仕様が変わった際に比較できます。SaaSは契約後も継続的に機能や規約が更新されるため、確認した日付も残しておきましょう。

2つ目は、扱う情報の重要度で確認の深さを変えることです。個人情報や取引先の機密情報を扱うサービスと、社内の雑談用ツールでは、求める水準が違って当然です。すべてのSaaSに同じ厳しさを求めると、選定に時間がかかりすぎて現場が承認を待たずに無断でツールを使い始める、いわゆるシャドーITを招く原因にもなります。個人情報を扱う場合は、個人情報保護委員会が公開している法令やガイドラインも確認し、判断に迷う点は専門家に相談してください。

3つ目は、チェック結果を利用部門にも伝えることです。「このサービスはIPアドレス制限に対応していないため、社外からの接続は会社支給の端末に限る」のように、サービス側で満たせなかった要件は、利用者向けの運用ルールで補うことになります。情報システム部門がルールを決めても、利用者が知らなければ守られません。

とはいえ、ルールを資料で配布したり、全社メールで流したりするだけでは、読まれたかどうかも理解されたかどうかも分かりません。SaaSを入れるたびに運用ルールは増えていくため、ルールの説明と確認テストをまとめて配信し、未受講者に自動でリマインドできる仕組みがあると、情報システム部門の負担を抑えながら周知を続けられます。ルールが情報セキュリティの取り扱いに関わる場合に、その研修をeラーニングで実施できるサービスの一例が、OneCompliance(ワンコンプライアンス)(株式会社Oyster)です。法務・労務・情報領域の研修に特化したeラーニングで、情報セキュリティの研修も実施できます。ダッシュボードや自動リマインダーで、研修の実施と管理の手間を抑えられる点も特徴です。一方で、費用は受講人数に応じた課金体系のため、問い合わせでの確認が必要です。SaaSの利用ルールそのものを扱う教材かどうかは、資料で確認してください。

社内に法務専任担当や教育専任担当がおらず、社内のみでの実施が困難

OneCompliance 導入事例(株式会社プリメディカ。導入の背景・課題感として掲載) 出典：導入事例ページ

非機能要件確認でよくある失敗パターン

非機能要件の確認不足は、導入直後ではなく、利用が定着した数か月後や解約のタイミングで表面化することが多いのが厄介な点です。よくある失敗パターンと、事前にできた対策を整理します。

失敗パターン	起きたこと	事前にできた対策
稼働率の数字だけで判断した	SLAは満たしていたが、計画メンテナンスが業務時間中に入り、繁忙期に作業が止まった	稼働率の算出方法と、メンテナンスの時間帯・告知時期をセットで確認する
解約時のデータ取り出しを確認しなかった	乗り換えの際、添付ファイルや履歴がエクスポートできず、手作業で移し替えることになった	契約前にエクスポートの対象項目と形式を試し、解約後の保持期間を確認する
バックアップは事業者任せだと思っていた	利用者の誤操作で削除したデータについて、個別の復元には対応していなかった	誤削除時の復元可否を確認し、重要データは自社でも定期的にエクスポートする
上位プランの機能を前提にしていた	SSOやIPアドレス制限が上位プラン限定で、契約したプランでは使えなかった	必須の非機能要件が、契約予定のプランで提供されるかをプラン表で確認する
設定と運用ルールを現場に伝えなかった	共有リンクの公開範囲の設定ミスで、社外から閲覧できる状態が続いていた	共有責任モデルで自社の担当範囲を整理し、利用者向けのルールとして周知・確認する

5つのパターンに共通するのは、「サービスの性能」ではなく「確認の範囲」の問題だという点です。非機能要件は、公開情報を読むだけで済む部分と、トライアルで試さなければ分からない部分、社内の運用で補う部分の3つに分けて考えると、抜け漏れを減らせます。

ベンダーへの質問で確認したいこと

公開情報で分からない点は、ベンダーに質問して確認します。回答は後から参照できるよう、メールなど記録に残る形で受け取るのがおすすめです。

• 過去1年間で大きな障害はあったか、その際の通知と復旧までの流れはどうだったか
• 利用者の誤操作で削除したデータは、いつの時点まで、どのような手続きで復元できるか
• 解約後、データはいつまで保持され、削除されたことをどのように確認できるか
• データはどの国・地域で保管され、保管場所が変わる場合は事前に通知されるか
• 仕様変更や機能の廃止は、どのくらい前に、どの手段で告知されるか

最後の失敗パターン「設定と運用ルールを現場に伝えなかった」は、ルールを配っただけで、理解を確かめていないことから起きがちです。研修のあとに確認テストで理解度を確かめたい場合の一例が、SAKU-SAKU Testing(株式会社イー・コミュニケーションズ)です。確認テストやドリルの機能があり、ユーザー管理機能で受講者をカテゴリーやグループごとに紐づけられるため、部署ごとに確認の対象を分けられます。コンテンツは作成・登録しやすい機能を備えています。一方で、事務局運営やカスタマーデスクを利用する場合はオプション扱いです。SaaSの利用ルールそのものを扱う教材かどうかは、資料で確認してください。料金はプランによって異なるため、資料や公式サイトで確認してください。

確認テストの前に、運用ルールそのものを自社の研修コースとして整えておきたい場合は、先に紹介したSmart Boardingのように、自社オリジナルのコースを作成できるサービスも選択肢になります。

よくある質問(FAQ)

Q. SaaSの非機能要件とは何ですか？

A. サービスが「何をするか」ではなく、「どの水準で、どのような条件のもとで動くか」を定める要件です。止まりにくさ、速さ、運用のしやすさ、データの出し入れ、セキュリティ、動作環境などが含まれ、IPAの非機能要求グレードでは6つの大項目に整理されています。

Q. 機能要件と非機能要件の違いは何ですか？

A. 機能要件は「何ができるか」、非機能要件は「どの水準で、どのような条件のもとで動くか」を定めるものです。請求書の発行や承認フローは機能要件、月末でも画面がすぐ開くこと、障害時の復旧、解約時のデータの取り出しやすさは非機能要件にあたります。非機能要件は、IPAの非機能要求グレードで可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つに整理されています。

Q. SaaSでも非機能要件を定義する必要はありますか？

A. 必要です。ただし自社構築のように事業者へ要求するのではなく、自社の許容範囲を先に決め、事業者が公開しているSLAや仕様と比べて選ぶという使い方になります。満たせない部分は、社内の運用ルールで補うことを検討します。

Q. 稼働率99.9%とはどのくらい止まる可能性がありますか？

A. 30日の月で単純計算すると、約43分の停止が許容される水準です。ただし計画メンテナンスを停止時間に含めない定義も多いため、SLAの算出方法とメンテナンスの時間帯をあわせて確認してください。

Q. 共有責任モデルでは、SaaS利用者は何に責任を持ちますか？

A. 一般的に、アカウントや権限、認証の設定、入力・保存するデータの管理、利用端末や接続環境の管理は利用者の担当範囲とされます。多要素認証の有効化や退職者アカウントの停止、共有範囲の設定などは、利用企業が自ら行う必要があります。

Q. 非機能要件で決めたルールを社内に定着させるにはどうすればよいですか？

A. サービス側で満たせなかった要件を利用者向けの運用ルールとして文書化し、説明と確認テストをセットで周知する方法があります。eラーニングシステムを使えば、受講状況の管理や未受講者へのリマインドを仕組み化でき、ルールが増えても周知を続けやすくなります。

まとめ

SaaSの非機能要件は、機能比較の陰で見落とされやすい一方、導入後の業務の安定や解約時の負担を大きく左右します。確認を進めるうえで押さえておきたいポイントは次の6つです。

1. IPAの非機能要求グレードの6分類を、SaaSでは「要求」ではなく「確認して選ぶ」物差しとして使う
2. 共有責任モデルで、事業者の担当範囲と自社の担当範囲を先に分けておく
3. SLAは稼働率の数字だけでなく、算出方法・メンテナンス・未達時の扱いまで読む
4. 移行性は契約前に、エクスポートの対象項目と解約後のデータの扱いを確認する
5. サービス側で満たせない要件は運用ルールで補い、利用部門まで周知して定着させる
6. 周知と理解確認を仕組みにする方法として、eラーニングシステムの資料を取り寄せて比べる

非機能要件の確認は、選定して終わりではありません。確認結果とその根拠を残し、利用者に必要なルールを伝え続けることが、SaaSを安全に使い続けるための土台になります。

参考文献

• 独立行政法人情報処理推進機構「非機能要求グレード」https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/index.html
• 独立行政法人情報処理推進機構「システム構築の上流工程強化(非機能要求グレード)紹介ページ」https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
• 経済産業省「SaaS向けSLAガイドライン」https://www.meti.go.jp/policy/netsecurity/secdoc/contents/downloadfils/080121saasgl.pdf
• 独立行政法人情報処理推進機構「IPAセミナー＠東京(2019年3月4日)講演資料」https://www.ipa.go.jp/archive/files/000072715.pdf
• ISMAPポータル「政府情報システムのためのセキュリティ評価制度(ISMAP)」https://www.ismap.go.jp/csm
• Google Cloud「SRE fundamentals: SLIs, SLAs and SLOs」https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-slis-slas-and-slos