システム開発の発注時には必ずSLAを明確化しよう

システム開発の発注時には必ずSLAを明確化しよう

更新日:2017年09月07日 | 公開日:2017年06月20日

SLA(Service Level Agreement)とは「サービスレベルアグリーメント」=「サービスレベルに関する合意水準」のことで、サービスを提供する事業者が契約者に対して、どの水準までのサービスを提供できるかを明示した「品質保証」のことです。

家電製品や食品などでもパッケージに品質表示があり、その表示については「品質保証」をしていますので、それと同じです。

ただし、IT系のサービスの場合にはオーダーメイドが多いので、開発側企業と発注者側との間で案件ごとにサービスや製品の内容と範囲、品質に対する達成水準を明確にして、それが達成できなかった場合のペナルティなどを含めてあらかじめ合意しておき、明文化して契約書に落とし込んでおくことが大切です。

いい加減な“SLAもどき”を作ってサインをしても、実際には履行義務がなかったり、不具合等が起きた場合でも開発会社側に有利な免責事項にしかなっていなかったりなどということでは意味がありません。

この記事では、そのような特徴を持つIT関連のSLAについて、発注者が知っておくべき事柄をまとめます。
熟読して、間違いのないSLA契約を交わして下さい。

SLA導入にあたって押さえておくべきこと

タイピング

SLAの必要性を確認しよう

IT関連のサービス、納品物は家電製品や食品などに比べて内容がわかりにくく、開発会社と発注側で製品の品質の要求水準に対して認識の相違があることが少なくありません。

また、「納品時は快適に動作していたが、使っているうちにパフォーマンスが著しく低下した」「時間帯によってネット接続が落ちてしまうケースがある」「納品後半年間は問題がなかったが徐々に不具合が頻発するようになった…」「ウイルスソフトをアップデートしたら、速度が極端に遅くなった」などの、予期せぬ不具合が出てくるのもIT関連のサービス・納品物の特徴ですので、SLAを交わす場合にはこうした点を織り込むことが必須だと言えるでしょう。

具体的には下記のような項目について文書の中ではっきりと規定することが大切です。

SLAに盛り込むべき内容
  • SLAの目的
  • SLAの範囲及び責任
  • SLAの改定方法
  • SLA対象サービス
  • サービスレベルに関する規定
  • 報告の方法、頻度と品質管理体制
  • サービスレベル未達・達成時の対応
  • 罰則規定(こちらは必要に応じて)

SLAは定量的にサービス品質を定義する

今解説したような「認識の相違」や「パフォーマンスの低下」に対処できるSLAを交わすためには、求められる品質の要求水準に対して、サービスレベルを数値によって「定量的」に定義することが不可欠です。

つまり、SLAで規定すべきサービスのレベルは「その水準で頑張ります!」という曖昧な目標基準ではなく、開発会社の責任を明確化するための数値的な基準であることが求められるわけです。

SLAを数値化することによって開発会社の責任範囲を明確化することが可能になり、同時に発注者側は納品時の品質の保証内容とともに、オプションで料金がかかってくるサービス内容についても明確に知ることができます。

システム納品後のトラブルとしてよくあるのが「そのサービスは有償となります」という開発会社の対応ですが、これは多くの場合、どこからどこまでが納品時の品質の保証範囲であり、どこから先が別のサービスメニュー(例えば「運用・保守」)であるのかを明確にしていなかったところに原因があります。

SLAを数値的に明確化することで、この線引きがはっきりして、開発会社との良好な関係をキープすることができ、さらに進んだ運用・保守契約などを納得の上で締結することも可能になります。

SLAは当初通信サービスなどのインフラ系で発達してきた品質保証ですが、最近ではASPなどのオンライン・アプリケーションサービスや、システムの運用・保守アウトソーシングなどにも広がってきています。
また、伝統的なシステム開発の納品物や、継続して納品が繰り返されるアジャイル型開発においてもSLAの導入は進んできています。

単純なインフラ環境の提供の場合には、通信速度の保証など、数値的にメニューを出しやすかったのですが、ASPなどのアプリケーションの時間貸しや、個別の運用・保守の場合、さらにシステム開発の場合にはなおさら、ケースバイケースで保証すべき品質内容が変わってきます。
当然、数値に落とし込むべき具体的なサービスレベルについても案件ごとに変わってきますので、しっかりと保証すべき数値を割り出すことがSLA締結の基本となります。

そして、SLAは単に契約時に確定した数値を確認するだけでなく、当初確認した数値が妥当であるのか、継続的なモニタリングをすることが必要です。
SLAで定めた品質保証のレベルを継続的・定期的に見直すことでSLAの保証内容を意味あるものとなります。

こうした活動をSLMと言いますので、次にこの内容を見ていきましょう。

SLM(Service Level Management)を同時に規定する

タイピング

SLAとは、サービスの品質の水準を明確にすることが主目的です。
したがって、サービスレベルを維持するために開発会社がどんなマネジメントを実施するかについては別途取り決めておいたほうが良いでしょう。
SLAを達成するために開発会社はどのような行動を取る義務を負うかについて明確化しておかないと、SLAが実効性のないお題目に成り下がってしまう場合もあります。

SLAを実際に回していくためには、SLMと呼ばれる、PDCAサイクルに業務を落とし込むことがセットで行われます。

【SLM(Service Level Management)】
SLAの作成(Plan)⇒サービスの実行(Do)⇒サービスのモニタリング・評価(Check)⇒SLAの見直し(Action)

通常ビジネスの現場で実施されているように、最初にプラン(P)を立てて、実際に実行(D)し、問題点がないかチェックをかけ(C)、最初のプランをバージョンアップする(A)というわけです。
SLAを実効性のあるものにしていくためには、SLAとともに、SLMの導入が不可欠です。

以前は、SLAという概念自体がまだ広く普及していなかったため、サービスレベルを規定して要求水準を明示した文書を交わしている、というだけで満足してしまうケースが多かったのですが、SLAはそれがきちんと達成できているかどうかをチェックして、サービスや納品物を改善していくためのツールとして使われて初めて意義があると言えるのです。

SLA/SLMの導入の方法

SLAを導入するためには、「だいたいこれくらいの水準を目標としてやっていきたいです!」というような、曖昧な数字を出してもらっても意味がありません。

例えば、「24時間パフォーマンスを落としません!」と宣言しても、そもそも、インターネットが回線的に混む時間にそうしたサービスが可能であるのかどうか、しっかり検証しないことには単なる目標の宣言に過ぎなくなってしまいます。

SLAをどのように作成するかを定めた国際的な基準というものは、現段階では残念ながら存在しません。
参考になりそうな品質保証の国際基準として、ISO 9126の中の「ソフトウェア製品の品質」や、ISO14598にある「ソフトウェア製品の評価」、ISO/IEC 25000 SQuaREなどがありますが、SLAそのものを意図して策定されていませんし、想定している範囲が広すぎたりします。

そのため、SLAは、下記のような手順で案件ごとに発注者と開発者が手探りで納得行く形を模索していくことが必要となります。

SLA作成の手順
  • 提供するITサービス、納品物の品質定義
    システム開発の品質とは、機能品質、操作品質、サービス品質、セキュリティ品質を網羅したものです。
  • サービス目標としてのSLAの設定
    検証を開始する前なので、過去の納品実績や同業他社の水準などから仮に決めておきます。
  • SLA対象データの収集
    実際に納品物を使ってテストを行います。
  • SLA結果のモニタリング
    発注側と開発側で同じデータを検証します。
  • 「2.サービス目標としてのSLAの設定」の数値が達成可能かどうか検証
    この5の段階で、SLMのPDCAを回します。

こうしてでき上がった実行可能な数値を、SLAに盛り込むようにしましょう。
決して、検証抜きの目標のみの数字で満足してはいけません。

データセンターなどで見られるSLAの例

SLAの設定の仕方がわかったところで、SLAの実際の例を見てみましょう。
SLAはデータセンターなどの通信サービスで結ばれることが多いので、最初にそうした例を検討してみます。

【通信サービスでのSLAの例】
■ サーバ可用性(稼働能力)  保証値 99.9以上
■ ネットワーク可用性(稼働能力)  保証値 99.9以上
■ データベース可用性(稼働能力)  保証値 99.9以上
■ 障害通知時間  15分以内
■ 障害回復時間  2時間以内
■ セキュリティアップデート  6時間以内
■ 一般お問い合わせ対応時間  平日9:00-18:00
■ 障害問い合わせ対応時間  24時間365日

システム開発におけるSLAの例

最近では、通信サービスでのSLAだけでなく、システム開発においてもSLAを結ぶケースが増えてきました。
通信インフラと違って、アプリケーションがきちんとサービスを続行できるかどうかという項目が目立っていますね。

■ サーバ可用性(稼働能力)   保証値 99.9以上
■ ネットワーク可用性(稼働能力)  保証値 99.9以上
■ データベース可用性(稼働能力)  保証値 99.9以上
■ 納品アプリケーション/システム可用性(稼働能力) 保証値 99.9以上
■ 年間納品アプリケーション/システム障害件数 2回まで
■ 納品アプリケーション/システム回復時間  6時間以内
■ 納品アプリケーション/システム障害通知時間 1時間以内
■ 納品アプリケーション/システムオンラインレスポンス 5秒以内
■ 納品アプリケーション/システムバッチ処理レスポンス 1時間以内
■ 一般お問い合わせ対応時間  平日9:00-18:00
■ 障害問い合わせ対応時間  24時間365日

SLA導入の注意点について

キーボードとマウス

ここまで、SLAとは何か、策定時の注意点や方法、具体的な例などを検討してきました。
実際にSLAを策定するときには、これまで解説してきたことをしっかりと実践していただきたいのですが、一番重視して欲しいのは、SLA締結が後手に回らないということです。

SLA締結が後手に回ってしまうのはひとえにSLAの検討開始のタイミングが遅いからです。
実際に納品直前や実際に納品してから品質保証についてあれこれ項目を洗い出したり、各項目を遵守できるかをSLMで慌てて検証したりすることになりがちです。
そして検証している間に、肝心のシステムは本稼働をスタートさせているので「まあ、動いているから慌ててSLAを締結しなくてもいいか…」という雰囲気も出てきます。
そして、何か障害が起きてしまったときに「SLAを結んでいなかった…」という事態に直面するわけです。

ひとくちにSLAと言っても、案件ごとにその内容はさまざまです。
機能品質、操作品質、サービス品質、セキュリティ品質のそれぞれについて求められるものもバラバラですので、開発会社では過去に他の案件で検討したSLAをそのまま使いまわすということもできません。

一番理想的なのは、システム開発の仕様を詰める段階で、SLAについても設計をしてしまうことです。
案件ごとに仕様は千差万別なわけですから、その千差万別の案件の詳細を詰めている仕様作成の時期に、稼働した後のSLAについての設計も行ってしまうのが一番合理的だと言えるでしょう。

例えば、サービス稼働率に関してのSLAを明確化するためには、設計段階でどのような障害を想定してシステムを組むことにしたかが重要になってきます。
2重化やクラスタリングなどの高可用性を考慮した設計を行った場合と、最低限の手動でのオンラインバックアップを運用時に行うとした場合では、「納品アプリケーション/システム回復時間」もまるで変わってきます。

設計通りにシステムが稼働している場合に、どのくらいの時間で「納品アプリケーション/システム回復時間」が達成できるのかも詰めておき、その検証だけをシステムが稼働する直前に行って、納品と同じタイミングでSLAを完成させれば理想的だと言えます。

【まとめ】サービスレベルの維持について先手を打つことが重要です!

握手をする男性

以上、SLAを交わすことの重要性についてお伝えしてきました。
SLAは運用が始まってから検討する、というケースもまだまだ多いのです。
しかし、運用するそのサービスは、設計段階で検討され構築段階で作り込まれたシステムであることを忘れてはいけません。

早い話が、設計段階でまったくセキュリティについて考慮せずに開発、運用とフェーズが推移してきシステムに対して、いきなりセキュリティーについてのサービス水準の話をすることそれ自体に無理があるのです。

まったくセキュリティについて話が出なかったというのは極端な例だとしても、SLA締結の段階で高い水準のサービスレベルの維持を求めたいのであれば、それが可能な設計になっていることが欠かせません。
セキュリティ的にずさんな設計のままに実装されたシステムを、いくらSLA締結の段階できめ細かくフォローしようとしても限界があります。

つまり、高水準のSLAを無理なく締結するには「サービスレベルの維持について先手を打つことが重要」なのです。
しかし現実問題として、開発会社の側でも、「SLAについては運用が見え始めてからぼちぼち検討しましょう…」といった雰囲気があります。
本来は開発会社が率先して、設計・開発フェーズからSLA、SLMについて話をすべきですが、どの開発会社もSLAを早い段階で検討してくれるわけではありません。

こうした中、SLAの重要性についてきちんと認識をして、早い段階でSLA、SLMについての重要性を発注者と共有してくれる良心的な開発会社は貴重な存在と言えるでしょう。
「アイミツ」にご相談いただければ、こうしたシステム構築会社を複数ピックアップすることが可能ですので、ぜひご相談いただければと思います。

いま知りたいこと
コンシェルジュが解決します!

コンシェルジュサービスは
3万社以上が利用している無料の相談サービスです。

コンシェルジュ

発注は時間も手間もかかりますよね?

コンシェルジュが解決します!

コンシェルジュに相談、あなたにあった業者を提案、発注の手間を削減!

完全無料

まずはお気軽にご相談ください