2-1サービスの計画とカタログ
11月のはじめ、こむぎ堂の朝の配達サービスは、4月に始めてから8か月目に入っていました。近所のカフェ3軒へ、前の晩に予約画面で受けた注文どおりのパンを、毎朝開店前に届けています。春から頼まれていたサンドイッチの配達は、評判を聞いた4軒目のカフェからも「届けてほしい」と言われ、1軒目のカフェからは「昼にもう1便来てほしい」と頼みが届きました。どれから始めるかを決めようと、店長とミナトは店の奥の机に書類を広げます。ところが、今あるサービスの説明書きはどこにもなく、ソフトウェアのライセンス証書は引き出しの奥から2枚だけ出てきて、配達の一部を頼んでいる運送屋さんとの約束はメールの山に埋もれていました。そこへ相棒が、去年の予約の記録を見て知らせます。「クリスマス前の1週間の予約は、今年は去年の3倍近くになりそうだよ」。店長は書類の山を見て、腕を組みました。
相棒の最初の助言は、新しい頼みを並べる前に、今あるものを書き出すことでした。新しいカフェの店主が最初に知りたいのは、こむぎ堂に何を頼めて、どう申し込めばよいかです。今のこむぎ堂には、その問いに紙1枚で答える用意がありません。
提供しているサービスについて、内容、範囲、申し込み方、問い合わせ先などをまとめた一覧をサービスカタログといいます。利用者はこれを見て、どんなサービスがあり、どう頼めばよいかを知ります。こむぎ堂なら「朝のパン配達：前の晩9時までに予約画面で注文すると、翌朝の開店前に届く。品目は食パン・バゲット・クロワッサン」といった項目が並びます。
カタログには、そのサービスで何が得られるのか（意図した成果）と、サービス同士のつながり（依存関係）も書いておきます。朝のパン配達は予約画面のサービスに頼っているので、予約画面が止まれば配達の注文も受けられません。この依存関係が書いてあれば、予約画面を止めて作業する日に、どのカフェへ前もって知らせればよいかが分かります。
ここから基本情報！提供中でないサービスも一覧にする
サービスカタログに載るのは、いま提供しているサービスです。しかし、どの頼みから始めるかを決めるには、まだ始めていないサービスや、もうやめたサービスも同じ表に並べて見たくなります。サービス提供者が扱うすべてのサービスを、提供中・提供予定・廃止済みまで含めて管理する一覧をサービスポートフォリオといいます。
ポートフォリオのうち、検討中や開発中で、まだ利用者に提供していないサービスの一覧をサービス・パイプラインと呼びます。ITILでは、サービスポートフォリオを、サービス・パイプライン、サービスカタログ（提供中）、廃止したサービスの三つに分けて考えます。新しい頼みは、まずパイプラインに入れて比べます。
一覧の各行には、そのサービスがライフサイクルのどこにいるかを書き添えます。これをサービスの状態といい、代表的なものは次の四つです。
| 状態 | 意味 | こむぎ堂の例 |
|---|---|---|
| 計画中 | まだ開発に入らず、構想や検討をしている段階 | 昼の配達（頼まれて検討している） |
| 開発中 | 計画を終え、提供に向けて作っている段階 | サンドイッチの配達（予約画面に品目を足している） |
| 稼働中 | 利用者に実際に提供し、運用している段階 | 朝のパン配達 |
| 廃止 | 提供を終え、運用も止めた段階 | 夏だけ出していた冷やしパンの配達 |
パイプラインに並べた頼みには、使える資源を考えて順番を付けます。焼き場の手と配達の車は限られているので、昼の配達とサンドイッチの配達を同じ月に始めることはできません。どちらが多くのカフェに喜ばれ、どちらが今の人手で回せるかを比べて、先に始めるものを決めます。
基本情報の範囲ここまで
2-2資産管理と構成管理
サンドイッチの品目を足すには、予約のアプリを新しい版にする必要がありました。ミナトは店のノートパソコンとレジ横のタブレット、クラウドに借りている予約のサーバを順に開いてみます。アプリの版は3台ともばらばらでした。しかも、引き出しから出てきたライセンス証書は2枚なのに、アプリは3台に入っています。
新しい版に上げるとき、まず知りたいのは「どの機器に、何が、どの状態で入っていて、どれとどれがつながっているか」です。これが分からないまま作業を始めると、タブレットだけ古いまま残り、レジの予約一覧が表示されなくなる、といったことが起きます。
サービスを形づくる要素を一つずつ見分けて記録し、その関係や状態を正しく保つ活動を構成管理といいます。記録しただけでは、いつのまにか実物とずれていきます。そのため、決めた間隔で記録と実物を照らし合わせ、正しさを確かめることも構成管理の仕事に含まれます。
構成管理で、管理の単位として一つずつ見分けて記録する要素を構成品目（構成アイテム、CI：Configuration Item）と呼びます。機器やソフトウェアだけでなく、設計書や運用の手順書、契約書のような文書も構成品目になります。こむぎ堂なら、ノートパソコン、タブレット、予約のサーバ、予約のアプリ、配達の手順書が、それぞれ一つの構成品目です。
ここから基本情報！構成の記録の中身
構成品目ごとに記録する中身を構成情報といいます。型番や置き場所、担当者といった属性、どの品目がどの品目に頼っているかという関係、そしていつ何を変えたかという履歴です。「レジ横のタブレットは、予約のサーバから予約一覧を受け取って表示している」という関係が書いてあれば、サーバの作業でタブレットに影響が出ることが前もって分かります。
構成情報を一か所にまとめて管理するデータベースを構成管理データベース（CMDB：Configuration Management Database）といいます。ITILで使われる呼び名です。ノートに手で書いた一覧でも中身は同じですが、データベースにしておけば、「このアプリが入っている機器」のような問い合わせにすぐ答えられます。
構成品目が変わるたびに、どの状態のものかを見分ける番号や名前を付けます。これを版（バージョン）といいます。予約のアプリが、ノートパソコンでは2.4、タブレットでは2.1、サーバでは2.3、と記録されていれば、どれを上げればよいかがすぐ分かります。上げた後に不具合が出たときも、記録の版を見れば、どの状態へ戻せばよいかが決まります。
基本情報の範囲ここまで
構成管理が見ているのは「何がどうつながっているか」です。店長が気にしていたのは、それとは別のことでした。2枚しかないライセンス証書で、3台にアプリを入れてよいのか。保守の契約はいつ切れるのか。こちらは、機器やソフトウェアを、お金と使う権利の面から管理する話です。
ここから基本情報！資産をお金と権利の面から管理する
サービスを提供するために使っているIT資産（ハードウェアやソフトウェアなど）を、買ってから捨てるまでのライフサイクル全体で管理する活動をITAM（IT asset management、IT資産管理）といい、資産管理とも呼びます。誰の持ち物か、いくらで買ったか、保守の契約や保証がいつまでか、いつ買い替えるかを記録しておきます。
そのうちソフトウェアに絞り、ライセンスと実際の使われ方を管理する活動をソフトウェアアセットマネジメント（SAM：Software Asset Management）といいます。持っているライセンスの数と、実際に入っている数を照らし合わせるのが基本です。足りなければ契約違反になり、余っていれば使っていない分にお金を払い続けていることになります。
ライセンスごとの使用許諾の条件や契約の中身を管理し、違反を防ぐ活動をライセンスマネジメントといいます。条件は製品によって違い、入れてよい台数、使ってよい人数、使える期間、商売に使ってよいかなどが決まっています。こむぎ堂のアプリが「1枚につき1台」の条件なら、証書2枚で3台に入れているのは1台分の違反です。ミナトは条件を確かめ、使っていないタブレットからアプリを消すか、1台分を買い足すかを店長と相談することにしました。
基本情報の範囲ここまで
2-3事業関係管理
夕方、1軒目のカフェ「ひだまり」の店主から電話がありました。「最近、クロワッサンの焼き色が薄い気がする。それと、注文の締め切りが夜9時だと、うちは閉店作業の最中で間に合わないんだよね」。電話を受けた店長は「気をつけます」と答えて切りましたが、その話はどこにも書き残されませんでした。
3軒のカフェは、こむぎ堂の配達サービスにお金を払う顧客です。注文の数が毎朝届くだけでは、カフェが何に困り、何を望んでいるかは分かりません。サービス提供者が顧客との間で築き、保っていく関係を顧客関係といいます。顧客の要求をつかみ、サービスに満足しているかを確かめることも、この関係の中に含まれます。
商品やサービスに対する顧客の期待が、実際にどの程度満たされたかを顧客満足（CS：Customer Satisfaction）といいます。満足は期待との比べ合わせで決まるので、同じクロワッサンでも、期待が高い店ほど不満が出やすくなります。ひだまりの店主が焼き色を気にし始めたのは、パンが変わったからかもしれませんし、ひだまりのお客さんの好みが変わったからかもしれません。どちらなのかは、話を聞いてみないと分かりません。
ここから基本情報！顧客との関係を仕組みにする
顧客関係を管理し、顧客満足を保ち、顧客やほかの関係者と話し合うための取り決めを作る活動を事業関係管理といいます。取り決めとは、誰が窓口になり、どれくらいの間隔で、どの場で話すかを決めておくことです。こむぎ堂なら、窓口は店長、月に1回、配達のついでに15分の打ち合わせ、と決められます。
満足しているかどうかを、印象ではなく数で見るための指標がサービス満足度です。たとえば月に1回、「味」「届く時刻」「注文のしやすさ」を5段階で答えてもらい、平均を記録します。先月の「注文のしやすさ」が3軒の平均で2.7なら、締め切りの時刻を見直す材料になります。
利用者がサービスの中身や品質について不満を申し出ることを苦情（クレーム）といいます。苦情は記録し、対応し、結果を相手に伝えるところまでを手順として決めておきます。サービスが止まった、品質が落ちたという出来事（インシデント）や、決まった手続きの依頼とは、分けて記録します。ひだまりの電話のうち「焼き色が薄い」は苦情として記録し、焼き場と原因を確かめます。「締め切りを遅くしてほしい」は、サービスの中身を変える頼みとして、次の打ち合わせで話し合うことになります。
基本情報の範囲ここまで
2-4サービスレベル管理
カフェ3軒とは、配達を始めるときに「月の配達の回数のうち95%以上は、朝7時までに届ける」とSLAを結んでいました。相棒が先月の配達の記録を集計して見せます。10月は31日あり、3軒へ毎朝届けたので、配達は93回です。そのうち7時を過ぎたのが5回ありました。ミナトは電卓をたたいて、少し青ざめます。
93回のうち7時までに届いたのは88回なので、達成率は88 ÷ 93 ≒ 94.6%です。目標の95%に届いていません。約束の紙は、結んだだけでは守られているかどうかが分からず、測って、報告して、直すところまで回して初めて役に立ちます。
サービスレベルを定め、顧客と合意してSLAに記録し、サービスレベル目標（SLO）に照らして実績を監視し、報告し、改善につなげる活動をサービスレベル管理（SLM：Service Level Management）といいます。監視は決めた間隔で行い、1回の数字だけでなく、月ごとの変化も見ます。こむぎ堂なら、毎月はじめに先月の達成率をカフェへ報告し、目標に届かなかった月は、理由とこれからの手立てを添えます。
ここから基本情報！約束を見直す、店の中でも約束する
合意したサービスレベルの達成状況を定期的に確かめ、必要なら中身そのものを見直す活動をSLAのレビューといいます。遅れた5回を調べると、4回は台風が近づいた2日の朝でした。暴風や大雨の朝は道が混むので、この4回の遅れは、配達の係が急いでも取り戻せません。カフェと話し合って「暴風や大雨の警報が出た朝は8時まで」と書き足すのも、レビューの結果としてありうる直し方です。
もう一つ分かったのは、台風の朝に限らず、焼き上がりが遅れると配達の出発も遅れることでした。カフェとの約束を守るには、こむぎ堂の中でも約束が要ります。サービス提供者の内部の部門同士で、サービスを支える仕事の役割分担と水準を取り決めた合意をOLA（Operational Level Agreement、運用レベル合意書）といいます。焼き場は朝5時半までに箱詰めを終え、配達の係は6時に出発する、と決めておけば、遅れたときにどこで詰まったかも分かります。
基本情報の範囲ここまで
2-5供給者管理
先月の遅れを調べていくと、残る1回は別の理由でした。いちばん遠い3軒目のカフェへの配達は、夏から運送屋さんに頼んでいて、その日は運送屋さんの車が30分遅れていたのです。3軒目の店主から見れば、遅れたのは運送屋さんではなく、こむぎ堂でした。
こむぎ堂の配達サービスは、こむぎ堂だけで届けているわけではありません。遠い1軒への配達は運送屋さんが、予約画面を動かすサーバはクラウドの業者が担っています。業務の一部を外の会社に任せることをアウトソーシングの利用といいます。任せた部分で起きた遅れも、顧客にとってはサービスを提供した側の遅れです。任せた相手がどれだけきちんと仕事をしているかを、任せた側が見ておく必要があります。
ここから基本情報！サービスの一部を担う相手の種類
サービスの一部を担う相手（供給者）との関係や合意を管理し、相手のパフォーマンスを監視する活動を供給者管理といいます。供給者は、どこに属し、どんな取り決めを結ぶかによって、三つに分けられます。
一つめは、サービス提供者とは別の組織に属し、取り決めに基づいてサービスの一部を提供する外部供給者です。運送屋さんとクラウドの業者がこれにあたります。外部供給者とは契約を結びます。契約は、当事者が合意し、守る法的な義務が生じる取り決めです。こむぎ堂は、運送屋さんとの契約に「7時までに届ける」と書かれているかを確かめ、遅れた回数を毎月記録することにしました。
二つめは、サービスマネジメントシステムの適用範囲の外にありながら、サービス提供者と同じ、より大きな組織に属し、サービスの一部を提供する内部供給者です。こむぎ堂なら、配達サービスを管理する仕組みの外にいて、配達サービスにパンを焼いて渡す焼き場がそれにあたります。同じ店の中なので契約は結ばず、受け渡しの時刻や量といった目標と、どこで誰に渡すかという受け渡しの決まりを、合意の文書にして取り交わします。
三つめは、サービスを受ける顧客でありながら、サービスの一部を自分で提供する供給者として行動する顧客です。ひだまりの店主が、自分の店の分を取りに来るついでに、隣のカフェの分も運んでくれることになったとします。ひだまりは配達サービスの顧客であると同時に、配達の一部を担う供給者でもあります。この場合も内部供給者と同じく、何時にどこで受け取り、何時までに隣へ渡すかを合意の文書にしておき、守られているかを見ます。
予約画面のサーバは、店に機械を置かず、クラウドの業者から借りています。サーバやストレージなどの基盤を自分で持たずに、インターネット経由で借りて使うことをクラウドサービスの利用といいます。借りる範囲によって、仮想サーバなどの基盤を借りるIaaS、OSやアプリの実行環境まで借りるPaaS、アプリそのものを借りるSaaSに分かれます。こむぎ堂は、仮想サーバを借りて、その上で知り合いの業者が作った予約のアプリを動かしているので、IaaSの利用です。機械を買わずに済む代わりに、業者の側が止まれば予約画面も止まります。業者が約束しているサービスレベルが、カフェとの約束を守れる水準かどうかを、契約の前に確かめておきます。
基本情報の範囲ここまで
2-6予算業務と会計業務
月末、店長がレシートの束を前に聞きました。「配達のサービスって、結局もうかっているの」。クラウドの利用料、運送屋さんの請求書、配達の車のガソリン代。ミナトは束をめくりながら、どれが配達のための費用で、どれが店頭のための費用なのか、自分でも分けられないことに気づきました。
サービスにかかる費用は、レシートの合計だけでは決まりません。予約のアプリを3台に入れるなら、ライセンスの代金のほかに、入れる手間、保守の契約、店の人に使い方を教える時間、古くなった機器を処分する費用もかかります。製品やシステムを手に入れてから使い終えるまでにかかる費用の総額を総所有費用（TCO：Total Cost of Ownership）といいます。買うときの値段が安くても、TCOで比べると高くつくことがあります。
ここから基本情報！サービスのお金を計画し、記録する
サービスにかかる費用を前もって見積もって計画することと、実際にかかった費用を記録して管理することを、合わせてサービスの予算業務及び会計業務と呼びます。シラバスの項目名もこの呼び名です。ITILでは、予算と会計に、利用者に料金を請求する課金を加えた活動を財務管理と呼んでいます。
前半の予算業務は、サービスの提供に要る費用を見積もり、予算として計画する仕事です。後半の会計業務は、実際にかかった費用を記録し、サービスごとに分けて管理する仕事です。決めた間隔で予算と実際の費用を比べ、ずれが出たら理由を調べて、次の見積もりを直します。
こむぎ堂の配達サービスの11月の予算と実績を並べると、次のようになりました。
| 費目 | 予算 | 実績 | 差 |
|---|---|---|---|
| クラウドの利用料（配達の分） | 6,000円 | 6,000円 | 0円 |
| 運送屋さんの代金 | 24,000円 | 25,200円 | 1,200円の超過 |
| ガソリン代 | 8,000円 | 7,500円 | 500円の余り |
| 合計 | 38,000円 | 38,700円 | 700円の超過 |
表の1行目にも、会計業務の仕事が一つ入っています。クラウドの利用料は月10,000円で、予約画面は店頭の予約にも使っているので、全額を配達の費用にするのは正しくありません。11月の予約1,000件のうち、配達の予約が600件だったので、10,000円 × 600 ÷ 1,000 = 6,000円を配達サービスの費用として配分しました。こうして分けておくと、配達サービスだけで見たときの損得が分かります。
超過の原因は運送屋さんの代金で、ここには料金の決め方が関わっています。運送屋さんの料金は、月の1〜10回目が1回1,000円、11〜20回目が1回800円、21回目からは1回600円です。利用する量が増えるほど、1回あたりの単価が段階的に下がっていく料金の決め方を逓減課金方式といいます。量と料金の関係をグラフにすると、量が増えるにつれて料金の増え方がゆるやかになります。
予算は11月の30日分、月30回の配達で見積もっていたので、1,000円 × 10 + 800円 × 10 + 600円 × 10 = 24,000円でした。実際には、3軒目のカフェが店の催しの日に昼の追加を2回頼んできたので、運送屋さんに臨時の便を2回出してもらいました。31・32回目の2回分、600円 × 2 = 1,200円が上乗せされて25,200円になりました。超過はむだづかいではなく、配達が増えた結果です。次の月からは、臨時の便の分も見込んで見積もることにしました。
基本情報の範囲ここまで
2-7需要管理と容量・能力管理
残る心配は、相棒が最初に知らせたクリスマスの予約でした。去年のクリスマス前、夜9時台に予約画面が重くなり、何人かのお客さんから「注文ボタンを押しても進まない」と電話があったことを、店長は覚えています。「今年は3倍だっていうけど、うちの予約画面はそれに耐えられるのかな」
予約画面が重くなるかどうかは、どれだけの注文が、いつ来るかで決まります。サービスに対する今の需要を把握し、将来の需要を見込み、実際の使われ方を見て報告し、その結果を機器の計画に渡す活動を需要管理といいます。需要を見込むだけでなく、早めに予約すると割り引く、受け取り日を分けてもらう、といった形で、需要の山をならすこともあります。
ここから基本情報！需要を見込み、容量を足す
サービスの利用者の側から生じる要求や仕事の量を需要といいます。こむぎ堂の予約画面なら、1時間に何件の注文が来るか、が需要です。将来の需要を見積もり、要る処理の量を前もって把握することを需要予測といいます。去年のクリスマス前の1週間は予約が1,200件で、いちばん多い時間帯（夜9時台）は1時間に120件でした。今年がその3倍なら、1週間で3,600件、夜9時台は1時間に360件と見込めます。
システムやサービスが扱える仕事の量の上限を容量・能力（キャパシティ）といいます。1時間に360件を受けられるかは、予約画面のサーバの容量・能力しだいです。将来の需要に対してSLAを満たせるように、要る容量・能力を前もって見積もり、確保しておく計画を容量・能力計画（キャパシティ計画）といいます。そして、需要や資源の使われ方を分析し、要る容量・能力を計画し、確保し、その使われ方を監視して改善する活動全体をキャパシティ管理と呼びます。キャパシティ管理はITILの呼び名で、シラバスでは容量・能力管理と呼んでいます。
使われ方は、数値で見ます。システムの稼働の状況をつかむために監視する数値を管理指標といい、代表的なものを表にまとめます。
| 管理指標 | 何に対する割合・量か | こむぎ堂の予約画面のサーバ |
|---|---|---|
| CPU使用率 | 一定の時間のうち、CPUが処理に使われていた時間の割合 | 夜9時台に30%（去年のピーク） |
| メモリ使用率 | 主記憶（メモリ）の全容量のうち、使われている割合 | ふだん40%前後 |
| ディスク使用率 | 補助記憶（ディスク）の全容量のうち、使われている割合 | 50GBのうち35GBで70% |
| ファイルの使用量 | ディスクにたまっているファイルのデータの量 | 予約の記録が月に1GBずつ増える |
| ネットワーク使用率（ネットワークの利用率） | 回線が送れる最大の量のうち、実際に流れている通信の量の割合 | 100Mbpsの回線で、ピーク時20Mbpsなら20% |
指標を眺めているだけでは、いつ手を打てばよいかが決まりません。監視している値が異常かどうか、手を打つべきかどうかを判定する基準の値をしきい値（閾値）といいます。こむぎ堂は、CPU使用率が80%を超えたら知らせが届くように決めました。
この線をもとに、クリスマスの見込みを確かめます。処理にかかるCPUの量が注文の件数にほぼ比例すると仮定すると、去年のピークの1時間120件で30%だったので、360件ではおよそ30% × 3 = 90%になります。しきい値の80%を超えるので、このままでは重くなるおそれがあります。仮想サーバのCPUを2倍にすれば、同じ仮定でおよそ45%に収まります。比例は単純化した仮定なので、ミナトは去年の記録で、件数とCPU使用率がおおむね比例しているかも確かめることにしました。
ディスクも同じように見積もれます。50GBのうち35GBを使っていて、予約の記録が月に1GBずつ増えるなら、しきい値を80%（40GB）とすると、(40 − 35) ÷ 1 = 5で、5か月後に線に届きます。クリスマスの月は予約が多いので、届くのはもう少し早いかもしれません。
基本情報の範囲ここまで
12月のはじめ、ミナトはクラウドの管理画面で、予約画面のサーバの処理能力を2倍に上げました。夜9時台の注文の山に合わせて、早めに予約したカフェとお客さんには焼き菓子を1つ付けることにして、需要の山も少しならします。机の上の書類の山は、サービスの一覧、機器とライセンスの一覧、取引先との約束、月ごとの費用の4冊のファイルになりました。店長はファイルの背表紙を指でなぞって言います。「サンドイッチの配達は、クリスマスが終わってからだね」
11月のはじめに机の上で散らばっていた紙は、どれもサービスを届け続けるために要るものでした。新しい頼みを比べるにはサービスの一覧が、アプリを新しい版にするには機器とライセンスの記録が、遅れの原因を突き止めるにはカフェや運送屋さんや焼き場との約束が、もうかっているかを答えるには費用の記録が、クリスマスに備えるには需要の見込みと容量の計画が要りました。どれも、一度書いたら終わりではなく、決めた間隔で見直していきます。
ただ、ミナトには一つ、気になっていることがありました。サーバの処理能力を上げたのは、たまたま注文の少ない火曜の昼でした。もしこれが予約の受付のまっ最中で、上げた途端に予約画面が開かなくなっていたら、どうすればよかったのでしょうか。