SaaSの非機能要件｜選定前の5分類

SaaSを選ぶ際、機能の比較だけに目を向けていると、導入後に可用性やセキュリティ面で想定外の問題が起きることがあります。非機能要件を5分類で確認しておくと、こうした見落としを防げます。本記事では、SaaSの非機能要件とは何か、選定前に見る5分類とチェックリストを解説します。

目次

開く

閉じる

1. SaaSの非機能要件とは
2. 選定前に見る5分類
3. トライアル期間で確認できること
4. 可用性・性能を具体的な数値で確認する方法
5. 企業規模別の確認レベル
6. 拡張性・保守性を長期的な視点で評価する
7. 非機能要件の確認でよくある失敗パターン3つ
8. ベンダーへのヒアリングで聞くべき質問例
9. 非機能要件を軽視した場合に起こりうる影響
10. 非機能要件の確認を選定プロセスに組み込む手順
11. よくある質問(FAQ)
12. まとめ｜今日からできる3つのこと

SaaSの非機能要件とは

SaaSの非機能要件とは、機能そのものではなく、可用性・性能・セキュリティ・拡張性・保守性という観点から選定前に確認すべき条件を指します。機能比較だけでなく、契約・運用段階での継続的な見直しも重要になります。

選定前に見る5分類

可用性(障害対応・SLA・バックアップ)、性能(応答時間・同時利用対応)、セキュリティ(認証・権限管理・ログ・暗号化)、拡張性(ユーザー追加・容量・連携機能)、保守性(サポート・データ移行・更新告知)という5つの分類で確認します。

分類	確認する内容
可用性	障害対応・SLA・バックアップ
性能	応答時間・同時利用対応
セキュリティ	認証・権限管理・ログ・暗号化
拡張性	ユーザー追加・容量・連携機能
保守性	サポート・データ移行・更新告知

トライアル期間で確認できること

性能面の応答速度や、拡張性に関わる連携機能の一部は、トライアル期間中に実際に触って確認できます。可用性やセキュリティの詳細はドキュメントやSLAの記載で確認する必要がありますが、日常的な使い勝手はトライアルで検証するのが効率的です。

例えば無料プランのあるグループウェアであれば、費用をかけずにトライアル感覚で性能や拡張性を確認でき、5分類の考え方を実践しながら学ぶ機会にもなります。

可用性・性能を具体的な数値で確認する方法

可用性・性能を確認する際は、「安定して使える」といった抽象的な言葉ではなく、具体的な数値指標に落とし込んで比較することが重要です。可用性であれば、SLAに記載された稼働率保証(例えば月間稼働率99.9%等)だけでなく、その保証を下回った場合の補償内容(利用料の返金割合や上限)まで確認します。稼働率の数値だけを見て安心すると、実際に障害が発生した際の補償が想定より小さい、あるいは補償対象の条件が限定的であるといった見落としにつながります。

性能面では、通常時の応答時間だけでなく、月末・年度末・繁忙期など利用が集中するタイミングでの応答速度の変化についても、可能であれば事業者に問い合わせて確認しておくと安心です。同時アクセス数の上限が契約プランによって異なるSaaSもあるため、将来的な利用者数の増加を見込んだ場合に、プラン変更が必要になるタイミングも事前に把握しておくと、急な性能劣化に慌てずに済みます。過去の大規模障害の発生履歴や、その際の復旧までの所要時間が公開されている場合は、それも実際の運用品質を推し量る材料になります。

企業規模別の確認レベル

個人事業主は最低限の可用性とセキュリティ、中小企業は5分類全体のバランス、中堅から大企業の企業はISMAP等の制度対応を含めた詳細な確認が求められる傾向があります。自社の規模に応じて、確認の深さを調整することが実践的です。

拡張性・保守性を長期的な視点で評価する

拡張性・保守性は、導入直後の使い勝手だけでなく、数年単位での事業成長やシステム更新を見越して評価することが重要です。拡張性の観点では、契約プランごとのユーザー数上限、データ容量の追加コスト、他システムとの連携機能(API公開の有無や連携できる外部サービスの種類)を確認します。特に、事業拡大に伴って利用者数や取引データ量が増えることが見込まれる場合、上位プランへの移行がスムーズに行えるか、移行時に既存データの再設定が必要になるかを事前に確認しておくと、成長段階での運用負荷を抑えられます。

保守性の観点では、サポート窓口の対応時間・対応言語・問い合わせ方法(電話・チャット・メール)に加え、機能更新やシステムメンテナンスの告知が事前にどの程度の余裕を持って行われるかも確認しておくとよいでしょう。突然の仕様変更で既存の業務フローが影響を受けると、現場の混乱につながります。契約終了時のデータエクスポート形式や移行支援の有無も保守性の一部であり、将来的に他サービスへ乗り換える可能性を残しておきたい場合は、この点も選定段階で確認しておくことが望ましいといえます。

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

機能比較だけで選定を終える、SLAの記載だけで可用性を判断する、確認を一部門だけに任せるという3つが、非機能要件の確認でよく見られる失敗の典型です。

失敗パターン1:機能比較だけで選定を終える。操作画面や機能一覧だけを見て導入し、運用後に性能面の不満が出るケースです。5分類で確認することが回避策になります。

失敗パターン2:SLAの記載だけで可用性を判断する。SLAの数値だけを見て安心し、実際の障害対応の体制を確認しないケースです。SLA以外の運用実績も確認することが回避策になります。

失敗パターン3:確認を一部門だけに任せる。情報システム部門だけで確認し、実際の利用部門の要件が反映されないケースです。複数部門で確認することが回避策になります。

ベンダーへのヒアリングで聞くべき質問例

5分類それぞれについて、資料やWebサイトの記載を読むだけでなく、営業担当者やサポート窓口に直接質問することで、初めて見えてくる情報があります。ここでは分類ごとに、選定段階で確認しておきたい質問の例を整理します。

可用性については、「直近1年間で計画外の障害停止は何回発生したか」「障害発生時の一次連絡までの目標時間はどの程度か」「バックアップの取得頻度と、復旧にかかる目安の時間はどの程度か」を確認します。SLAの文面には稼働率の数値しか記載されていないことが多く、実際の障害発生履歴や復旧までのプロセスは、問い合わせて初めて分かるケースが少なくありません。

性能については、「同時アクセス数が多いプランと少ないプランで、応答速度に差があるか」「利用者数が増えた場合、プラン変更以外に性能面で調整できる余地はあるか」を確認しておくと、将来の利用拡大時に慌てずに済みます。セキュリティについては、「多要素認証に対応しているか」「操作ログはどの範囲まで記録され、保存期間はどの程度か」「データはどの国・地域のデータセンターで保管されるか」といった点を質問します。特に、取引先から特定の認証取得状況や国内データセンターでの保管を求められる業種では、この点の確認が選定の可否を左右することもあります。

拡張性については、「ユーザー数やデータ容量を追加する際の手続きと、反映までにかかる時間」「他社ツールとの連携実績があるか、連携時に別途費用が発生するか」を確認します。保守性については、「サポート窓口の対応時間と対応言語」「大きな仕様変更がある場合、事前告知はどの程度の期間を設けているか」「解約時にデータをどのような形式でエクスポートできるか」を質問しておくと、契約後のギャップを減らせます。これらの質問は、トライアル期間中の問い合わせや、商談時の議事録として残しておくと、複数サービスを比較する際の判断材料としても活用できます。

非機能要件を軽視した場合に起こりうる影響

非機能要件の確認を省略して選定を進めると、契約後・運用開始後になって初めて問題が表面化することがあります。ここでは分類ごとに、確認不足が招きやすい典型的な影響を整理します。

可用性の確認が不十分だと、繁忙期に障害が発生した際、業務が長時間止まってしまい、代替手段(紙やメールでの対応等)への切り替えに追われることがあります。特に受発注や請求処理など、止まると顧客対応に直結する業務でSaaSを使っている場合、障害発生時の影響範囲は事前の想定より大きくなりがちです。性能の確認が不十分だと、利用者数が増えた段階で動作が重くなり、日常業務のたびに待ち時間が発生し、現場から不満の声が上がることがあります。当初の少人数トライアルでは問題が見えにくく、本格導入後に初めて顕在化するケースが典型的です。

セキュリティの確認が不十分だと、取引先からの監査や取引条件の見直しの際に、自社が利用しているSaaSの認証・権限管理体制が要件を満たしていないことが判明し、急きょ代替サービスへの切り替えを迫られる場合があります。拡張性の確認が不十分だと、事業拡大に伴ってユーザー数やデータ容量が上限に近づいた際、上位プランへの移行に想定以上のコストや作業負荷がかかり、移行のタイミングを見誤ると一時的に業務が滞ることもあります。保守性の確認が不十分だと、サポート窓口の対応時間が自社の営業時間と合わない、あるいは大きな仕様変更が直前にしか告知されず、現場の運用フローを急遽見直す必要に迫られるといった事態が起こり得ます。こうした影響は、いずれも選定段階で5分類に沿って質問し、記録を残しておくことである程度は避けられるものです。

非機能要件の確認を選定プロセスに組み込む手順

非機能要件の確認を場当たり的に行うのではなく、選定プロセスの中に手順として組み込んでおくと、担当者が変わっても同じ水準でチェックできるようになります。ここでは、比較検討から契約締結までの流れの中で、どの段階で何を確認するかを整理します。

まず候補となるSaaSを絞り込む段階では、公開されている資料やWebサイトの記載から、5分類それぞれについて最低限の情報(SLAの有無、主要な認証方式、連携可能な外部サービスの種類等)を一覧化します。この段階で情報が極端に少ない、あるいは問い合わせても回答が得られないサービスは、比較対象から外すかどうかの判断材料になります。次にトライアル期間では、実際の操作を通じて性能面の体感や、連携機能の使い勝手を確認するとともに、前述のヒアリング項目に沿ってサポート窓口へ質問し、回答の速さや内容の具体性も評価の対象に含めます。

契約直前の段階では、確認した内容を社内で共有できる形(簡単な比較表やメモ)にまとめ、情報システム部門だけでなく実際に利用する部門の担当者にも目を通してもらいます。ここで、現場が普段の業務で重視する観点(操作のしやすさ、繁忙期の応答速度等)と、情報システム部門が重視する観点(セキュリティ、拡張性等)の両方を突き合わせておくと、契約後に「聞いていた話と違う」という食い違いを防ぎやすくなります。契約後も、非機能要件は一度確認して終わりではなく、利用者数の増加やサービス側の仕様変更に応じて、定期的に見直す機会を設けておくことが望ましいといえます。

よくある質問(FAQ)

Q1. 非機能要件の確認は誰が担当すべきですか?

A. 情報システム部門だけでなく、実際の利用部門も含めた複数部門での確認が重要です。

Q2. SLAだけでは不十分な理由は何ですか?

A. SLAの数値保証だけでなく、実際の障害対応体制や過去の運用実績も確認する必要があるためです。

Q3. 中小企業もISMAPを確認すべきですか?

A. 必須ではありませんが、取引先の要件によっては確認が求められる場合があります。

Q4. トライアル中に確認できる項目は何ですか?

A. 応答速度等の性能面や、連携機能の一部を実際に触って確認できます。

Q5. 図面管理SaaSでは何を優先すべきですか?

A. 大容量ファイルを扱うため、性能と拡張性を優先的に確認することが実践的です。

Q6. 導入後も確認は必要ですか?

A. 契約・運用段階でも継続的に見直すことが推奨されています。

Q7. 非機能要件の確認に、どの程度の時間をかけるのが目安ですか?

A. サービスの重要度によって異なりますが、基幹業務に関わるSaaSであれば、比較検討からトライアルまで含めて2週間から1か月程度を目安に、5分類の項目を一通り確認しておくと、契約後のギャップを減らしやすくなります。

まとめ｜今日からできる3つのこと

1. 5分類で確認する:機能比較だけで選定を終えません。
2. SLA以外の運用実績も確認する:数値保証だけで判断しません。
3. 複数部門で確認する:一部門だけに任せません。