第 3 章 社会インフラサービスモデルの提案
3.3. SLA 概念を取り入れた社会インフラサービスモデルの提案…
3.3.1. SLA 概念の社会インフラサービスへの適用
66
このように、通常のサービスとは異なる環境下にある社会インフラサービスに対して、
その特徴を表す新たなサービスモデルを3.3.節で提案する。
67
ここからわかるのは、予め決められたサービス内容を市民(利用者)に対して履行すると いうことが重要と考えられていることである。また、利用者にとっては予め決められた サービスで内容であることを半ば無意識的に認識し利用しているということになる。
そこで、社会インフラサービスの提供者と利用者の間にはインタラクションではな く、過去の経緯や結果を元に予め決められた合意事項であるという考えをモデル化の再 に取り入れるため、鈴木他(2015)はSLA概念を使うことを提案した。SLAとは、
“Service Level Agreement”のことで、主にITサービス関連分野で使われているビジ ネス概念で、「サービス提供者と顧客との間で同意されたサービス内容に関する協定 書」と認知されている(打川, 2006)。ISO/IEC 20000および管理システムに関するJIS
Q 20000で規定されている規格の中で、サービス提供者が実施するサービス計画立案、
設計、移行、提供、改善の適切なマネジメントの必要性と具体的な手法が記述されてい る。ITサービスを構築するうえでは、いうまでもなく顧客の要求事項を踏まえ、できる だけ応えることが望ましいが、例えばシステムの処理能力や端末数などで、要求事項と 費用が矛盾することもある。リスク管理の面でも、例えばシステムトラブルのサポート 体制を平日日中のみとするか、全日24時間対応とするかなどは、サービス提供者の能 力およびサービスマネジメントに関わる事項となる。
日々の運用シーンで、ユーザーにとっては自分が通常使用する機能(例えばデータ入力 用端末)しか見えず、その機能がいつでも望むように利用できることが最も望ましい。し かし、IT サービスは多くのシステムがネットワークとなり構築されているため、ユーザ ーが使用する機能はその一部を構成しているため、何らかの利用制限が設けられたり、予 期せぬ不具合で利用不可となったり、データが消失したりするといったリスクも内在し ている。ユーザーの全ての要望に応えることは難しく、カスタマイズにも限界がある。
ITサービスの商品としての取引という観点では、ITサービスの黎明期は、具体的なサ ービスレベルが共有されず、必要なサービスレベルを構築するための費用や工期の妥当 性の判断も困難で、不具合が起こった時の責任の所在も不明確な部分があったが故に、IT サービスの価格が適正なのかどうか判断が難しいケースがあった。このような特徴を持 つITサービスと社会インフラサービスの類似点を表3-4に示す。
68
表3-4 社会インフラサービスとITサービスの類似点 社会インフラサービス ITサービス
提供者は、利用者個々のニーズを直接知ることが 難しい
IT サービスを日々利用するユーザーのニーズを 提供者が直接知ることが難しい
提供者は、利用者全体に同質のサービスを提供す ることしかできない
IT サービス提供者はシステムとして決められた 仕様のサービスをユーザー全体に提供する 提供者は、サービス変更に多くの手間がかかる ハードウェアの変更を伴うシステム変更には多
くの手間とコストがかかる
このようなITサービスが持つ課題に対し、JIS Q 20000が規定され、ITサービス提供 者と利用者が検討段階・開発段階・運用段階などのステージ毎にあらかじめ詳細な項目を 定め、必要なサービスレベル、サービスレベルを維持管理する主体と提供範囲、費用等を 規定することにより、提供するサービスレベルについて明文化し合意するという方法が 提案された。これがサービスレベルアグリーメント(SLA)である。JIS Q 20000では、SLA に含むべき項目は表3-5のように規定されている。
サービス理論では、提供者と利用者の直接のインタラクションにより利用者のニーズ を掴み、そのニーズに寄り添ったサービスを行うことが望ましいとされているが、IT サ ービスでは、日々の運用の中で提供者と利用者の直接のインタラクションはなく、また全 ての利用者のニーズに合わせたサービスの提供をその都度行うことは、コスト的にもシ ステム再構築の所要時間という点でも現実的ではない。SLA では、提供サービスの有効 期限を定め、SLA変更の管理方法についても明確にすることが望ましいとされている(表
3-5のb)。利用者のニーズに対し、定められた期間後に、提供するサービスを見直すタイ
ミングを設けていることになる。
この、SLA の決定、運用、変更というプロセスを管理するための活動をサービスレベ ルマネジメント(SLM: Service Level Management)と呼び、ITサービス提供者の社内の 業務マネジメントについても規定している。
このITサービスに対して適用されるSLA、SLMの概念を、類似の特徴を持つ社会イン フラサービスに適用するというのが本論文の提案の1つである。
69
表3-5 SLAに記載すべき内容(JIS Q20000より)
a) サービスの簡潔な説明 j)段階的取扱い及び通知のプロセス
b)有効期間及び/又は SLA 変更の管理の仕組み k)苦情対応手順
c)変更の承認の詳細 l)サービス目標
(例:サービス要求を実現するまでの時間,新 規利用者のためのサービスの設定時間,重大 な障害があった後にサービスを再開するま での時間) ※客観的であることが望ましい d)報告,レビューの頻度及びスケジュールを含む,
コミュニケーションの簡潔な説明
m) 合意した利用者数/作業負荷の量,シス テムスループットを支援するサービスの能 力など,作業負荷の上限及び下限
e)サービス提供時間(例えば,9 時〜17 時),例
外となる期日(例えば,週末,祝日,事業上重要な 期間),及び時間外の対応
n)課金コードなど,高レベルの財務管理の詳 細
f)通知方法及び期間当たりの頻度を含めた,予定さ れ,合意されたサービスの中断
o)インシデント及び災害を含むサービスの 中断時にとる処置は,通常は SLA から参照 される。
g) システムの正しい使い方,情報セキュリティ方 針の順守など,顧客の責任
p) 用語集
h)セキュリティなど,サービス提供者の法的責任 及び義務
q)支援サービス及び関連サービス
i)影響及び優先度の指針 r) SLAに示す条件の例外
鉄道サービスを例にして、表3-5に習いSLAを作成したのが表3-6である。
表3-6を見ると、鉄道サービスにおけるSLAは「ダイヤ」「安全」「情報提供」に関わ るものが多い。他の社会インフラサービスについてSLAを同様に考えると、電力、通信、
水道サービスにおいてはそれぞれ「24時間安定した電気、通信、水を供給する」が中心 となるし、航空サービスでは「ダイヤを維持する」「安全を確保する」が中心となるであ ろう。つまり、コアプロダクトを安定して利用できることが利用者にとっての社会インフ ラの存在価値であり、それが当たり前になって市民生活に根付いていることが提供者と 利用者の社会インフラに対する共通認識であるといえるのである。
70
表3-6 SLAの記載内容を鉄道サービスに適用した例
SLAに記載すべき内容 鉄道サービスでの記載例
a) サービスの簡潔な説明 運行路線(出発地と目的地がわかる) ダイヤ(所要時間がわかる)
b)有効期間及び/又は SLA 変更の管理の仕組み ダイヤの有効期限
c)変更の承認の詳細 毎年実施するダイヤ改正
e)サービス提供時間(例えば9 時〜17 時),例外と
なる期日(例えば,週末,祝日,事業上重要な期間),
及び時間外の対応
ダイヤ(運行時間がわかる) (曜日別ダイヤ、臨時ダイヤ)
f)通知方法及び期間当たりの頻度を含めた,予定さ れ,合意されたサービスの中断
工事等によるダイヤ変更、運休情報
g) システムの正しい使い方,情報セキュリティ方 針の順守など,顧客の責任
優先席で席を譲る、整列乗車といった利用者 のマナー啓発
鉄道営業法による、列車運行妨害への罰則 h)セキュリティなど,サービス提供者の法的責任
及び義務
鉄道営業法他の関係法令の遵守 ホームドア等、利用者の安全確保 個人情報の適切な管理
k)苦情対応手順 駅員やインターネット等による利用者から
の意見・苦情受付
l)サービス目標 ダイヤ(ダイヤ通りに運行することが目標)
安全(死傷事故が無いことが目標) m) 合意した利用者数/作業負荷の量,システムス
ループットを支援するサービスの能力など,作業 負荷の上限及び下限
ダイヤ(列車本数、定員、所要時間などがわ かる)
o)インシデント及び災害を含むサービスの中断時 にとる処置は,通常は SLA から参照される。
事故、災害、設備故障等による列車遅延・運 休に関する「情報提供」「振替輸送、払戻等 の対応」
q)支援サービス及び関連サービス 駅員やインターネット等による情報提供
71
なお、SLAによるサービスの評価は、基本的に「予め合意されたSLAからの乖離度に 応じたペナルティ」という考え方である。小山(2004)は、データの同時到着性が求められ る IT サービスにおけるペナルティを次のように定義している。「データが利用者に届く までの所要時間に関し、SLAに定められた目標時間 𝑡0と一致する場合、ペナルティ無し (penalty value=0)であり、𝑡0より遅れた場合および、目標時間から許容された一定時間早 い 𝑡𝑠 よりも更に早い場合にペナルティが最大(penalty value=1)となる(図3-5)」。
また、SLAに関する学術論文は、「定められたSLAを実現、維持するための具体的な 技術上の手法」に着目した文献がほとんどである。例を挙げれば上記の小山(2004)による
「複数の利用者に対するデータ同時到着性(複数マルチキャスト)遵守のための伝送方式 の構築」や、Linlin(2011)による「SLAで規定された応答時間の遅延を最小限に抑えるた めの、クラウドサービス上の理想的なソフトウェアリソース割り当てを実現するアルゴ リズム」といったものであり、SLAの定義や修正の手法に関する文献は見られない。