ガランティ型とベストエフォート型SLAの違いとは？非機能要求を完全解説

社運をかけたシステムが、リリース当日に止まった？

想像してみてください。あなたの会社が社運をかけて、5億円の大規模な新規システムを導入しました。画面のデザインは完璧で、新しい機能も満載。経営陣も大喜びです。ところがリリース当日、社員100人が一斉にログインした瞬間に画面がフリーズし、システム全体がダウンしてしまいました。復旧までに丸3日。その間、業務は完全にストップします。動画はこんな場面から始まります。

何が起きたのでしょうか。動画の答えは、「見えないルールの交渉を怠ったから」です。目に見える機能ではなく、裏側の取り決めを詰めていなかった、ということですね。動画は、この話を次の4つの順に掘り下げます。

• 非機能要求定義：機能以外の要件を、影響度の3段階と6つの分野で決める。
• SLA：決めた品質の基準を、文書で合意する。ギャランティ型とベストエフォート型がある。
• SLM：結んだSLAが守られているかを、継続的に管理する。
• CMMI：システムを作る組織自体の成熟度を、5つのレベルで評価する。

機能だけを見ていないか？　非機能要求定義

システムを発注するユーザーは、このシステムでどんな業務ができるのかという、目に見える機能要件ばかりに目を奪われがちです。画面や新機能の話は華やかで、盛り上がりますからね。でも、システムが期待どおりに動き続けるためには、裏側の取り決めが欠かせません。それが非機能要求定義です。動画は、システムが提供する機能面以外の要件を定めること、と説明します。ここでの合意が不十分だと、あとの運用で大きな問題が生じかねません。

だから、システム開発を始める前の段階で、開発側と発注側が「どのレベルの非機能要求を満たすべきか」を合意しておくことが、非常に重要なのです。

影響度で決める、3つのレベル

• 第1段階：社会的影響がほとんどない。
• 第2段階：社会的影響は限定的。
• 第3段階：社会的影響が非常に大きい。例は、メガバンクの決済システムや交通機関の運行管理システム。一瞬でも止まると、社会経済が大混乱に陥るからです。

システムごとに、備えるべき裏側のレベルが変わってくる、というわけです。

（補足：動画にない確認です。IPAの「非機能要求グレード」には、信頼性の観点から定めた3つのモデルシステムとして、「社会的影響が殆ど無いシステム」「限定されるシステム」「極めて大きいシステム」が出てきます。動画の第3段階の「非常に大きい」は、この「極めて大きい」にあたる話だと考えられます。同資料は、費用や品質への影響が大きい重要項目92項目について、モデルごとに要求レベルを例示しています。なお、この事業は2009〜2018年度に実施されて終了しており、紹介ページは2023年8月時点の内容です。）

非機能要求の6つの分野

動画によると、非機能要求定義の内容は、具体的に6つの分野に分けられます。1つずつ見ていきましょう。

分野	動画の説明	動画のたとえ・補足
可用性	システムの稼働時間などを示す指標。止まらず動き続けられるか	―
性能・拡張性	将来、扱うデータが増えたとき、どれだけスムーズに対応できるか	テレビで紹介されてアクセスが増えても、サーバーが落ちない
運用・保守性	日々トラブルなく運用できるか、万一のときに素早く効率的に修正できるか	技術的負債を抱え込まないための取り決め
移行性	新しい環境への移行のしやすさ。特定のベンダーに依存しすぎないために重要	別のクラウドに乗り換えたいのに、データが引き出せない、を避ける
セキュリティ	不正アクセス対策など	―
システム環境・エコロジー	物理的なスペースの制限や、環境負荷への配慮	―

（補足：動画にない確認です。IPAの非機能要求グレードの6大項目名は、「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」と、中黒（・）つきで書かれます。また、基本情報技術者試験のシラバス（Ver.9.2。現行制度の版で、IPAのページに2026年1月8日掲載と記載。2027年度からの新試験制度では版が改められる予定です）には、要件定義には業務要件定義、機能要件定義、そしてパフォーマンスや信頼性、移行要件などの非機能要件定義がある、と書かれています。）

可用性を数字で考えてみよう（自作の設例）

月間稼働率	30日間の停止の上限	1日に均すと
90%	3日（4,320分）	約2.4時間
99%	7.2時間（432分）	約14分
99.9%	43.2分	約1.4分
99.99%	約4.3分（約259秒）	約8.6秒

（補足：JIS Z 8115:2019（2019年版で確認）では、アベイラビリティは「要求どおりに遂行できる状態にあるアイテムの能力」で、注記に「可用性」「可動率」「稼働率」も用いられるとあります。動画の「稼働時間などを示す指標」という説明と、方向は合っています。）

SLA：品質の約束を文書にする

要求のレベルや分野をしっかり定義しても、口約束だけでは不安です。そこで要求を定義した後は、それを誰がどう保証するのかという「約束」に変えなければなりません。登場するのがSLAです。動画は、非機能要求定義などで定めた、提供するサービスの品質基準を、事前に取り決め文書として合意することだと説明します。聞き手は、スペック表をしっかりした契約書に昇華させるイメージだと言い換えています。

（補足：現行制度の基本情報（Ver.9.2）・応用情報（Ver.7.2）技術者試験のシラバスでは、SLA（サービスレベル合意書、Service Level Agreement）を「サービス及びその合意されたパフォーマンスを特定した、組織と顧客との間の合意文書」としています。動画では非機能要求定義で定めた基準が出発点として語られますが、シラバスの表現は、そこに限らずサービス全般の合意文書です。また「契約書そのもの」ではなく「合意文書」と書かれている点も押さえておきましょう。）

ギャランティ型とベストエフォート型

動画は、SLAには大きく分けて2種類の形態がある、と整理します。

• ギャランティ型：合意したサービス水準を、確実に保証する形態。
• ベストエフォート型：合意した水準の達成を、努力目標として設定する形態。

使い分けについて、動画のやり取りでは、メガバンクの決済システムのように絶対に止まってはいけないものはギャランティ型が向きそうだ、という話が出ます。一方で、社内のちょっとしたツールなら、コストを抑えるためにベストエフォート型で十分という判断もあります。講師は「メリハリが大事です」と応じています。

（補足：「ベストエフォート」という言葉は、日本では主に電気通信の分野で、あらかじめ定めた通信速度を保証しないサービス形態を指します。1つの伝送路を複数の利用者で共用するため、料金を安く抑えられるのが利点で、速度を保証するものは「帯域保証型サービス」と呼ばれます（Wikipedia。二次資料）。なお、「ギャランティ型」という呼び名と「SLAは2種類に大別される」という整理は、今回確認したIPAのシラバス・資料などでは確認できませんでした。資料により呼び方が異なる可能性があります。）

SLM：結んだら終わりではない

ここで動画は、重要な問題を提起します。契約を結んで終わりではない、という話です。聞き手は、契約書を金庫にしまって安心してしまうパターンだと表現します。そうならないよう、締結したSLAが適切に維持されるよう管理するプロセスが必要で、動画はこれをSLMと呼びます。SLAで約束を交わし、SLMで、その約束が守られているかを継続的に管理し続ける。動画は、「システムを正しく定義し、品質の約束を交わし、それを管理する。ここまでが一連の流れ」とまとめます。

（補足：基本情報技術者試験のシラバス（Ver.9.2・現行制度の版）の「サービスレベル管理」には、顧客と提供するサービスについてSLAを合意し、あらかじめ決めた間隔で、サービスレベル目標に照らしたパフォーマンスや実績の周期的な変化を監視・レビュー・報告する、とあります。なお、略称「SLM」そのものを定義した一次資料は、今回は確認できませんでした。）

CMMI：作る組織の成熟度を測る

しかし、そもそも約束を担う組織に能力がなければ、どれだけ立派な契約も絵に描いた餅になります。聞き手は、「絶対にダウンさせません」と契約したベンダーが実は素人集団だったら、全く意味がないですよね、とたとえます。そこで重要になるのが、開発組織の評価です。

動画は、CMMIを、ソフトウェア開発における組織のプロセス成熟度を測るための指標であり、プロセス改善に向けた指針となるもの、と説明します。組織における製品やサービスの開発、調達などの能力を、5つの段階で評価します。

レベル	動画の呼び方	動画の説明
1	初期	プロセスが定まっておらず、特定の個人の職人芸に完全に依存している
2	管理された	説明は短く、聞き手が「少しチームらしくなってきた」と受け止める
3	定義された	組織全体で標準化されたプロセスが明確に定義され、マニュアル化されている
4	定量的に管理された	数値に基づいた管理が行われている
5	最適化している	プロセスを数値で把握したうえで、継続的な改善を行っている最高レベル

レベル1について、聞き手は「スーパープログラマーがいるからなんとか回っているような、危ない組織」とたとえています。レベル4については、数値に基づいた管理が行われている点で非常に重要だと、動画は強調します。感覚ではなくデータで、プロセスの品質をコントロールしているイメージです。

（補足：CMMI Institute の公式ページ（2026年10月25日確認）は、成熟度レベル1を Initial（予測できず後手に回る）、2を Managed（プロジェクトレベルで管理）、3を Defined（組織全体の標準が複数のプロジェクトを導く）、4を Quantitatively Managed（測定・統制され、データに基づく）、5を Optimizing（継続的な改善）と説明しています。動画の整理と大きく合っています。同ページには、成熟度レベル0（Incomplete）も載っているため、レベルの数え方は資料や版によって異なる可能性があります。動画の「5段階」は、レベル1〜5のことです。CMMIは基本情報・応用情報技術者試験のシラバスの用語例にも載っています。）

最後の宿題：身近なシステムに当てはめる

動画は最後に、リスナーへ呼びかけます。あなたが普段の業務で使っているシステムや、委託しているベンダーに、今日の内容を当てはめてみてください。そのシステムは、社会的影響度で言うとどのレベルに設定されているべきか。開発や運用を担っている組織は、CMMIの5段階で言うとどのレベルにあると感じるか。この視点を持つと、ITリスクの見え方が劇的に変わるはずだ、と動画は言います。システムを使う側も、ただ漫然と使うのではなく、裏側にある見えないルールや組織の成熟度を意識することが、リスク管理の第一歩になる、という締めくくりです。

まとめ