管理台帳でサービスの整理・合理化・可視化を　『運用改善の教科書』の著者が語る、運用の見直し方

サービスポートフォリオの特徴と目的

近藤誠司氏（以下、近藤）：まず、サービスポートフォリオの簡単な説明をしておきたいと思います。サービスポートフォリオには3つのプロセスがあります。“サービス・パイプライン”と呼ばれているもので、サービスやシステムを検討し始めたり、開発し始めたりという段階のもの。ここはいわゆる設計構築みたいな話です。そこを“サービス・パイプライン”と呼んでます。

そこから、いざ開発が終わって提供中になると、ここは“サービス・カタログ”と呼ばれているもの。これは「AzureやAWSだとこういうサービスが使えますよ」とか、「こういうサービスを提供予定です」みたいなところが“サービス・カタログ”になります。ここはユーザーに見せるものです。そのため、廃止する予定のものもユーザーに見せていくというところで“サービス・カタログ”が真ん中にあって、最終的に廃止になれば“廃止されるサービス”というプロセスがある。

3つのプロセスがあって、ステータスは5つあるということです。“検討中”“開発中”“提供中”“廃止予定”廃止”とあって、それぞれでやらなければいけないことがある。

けっこう大きなプロセスをまたぐところが、運用にインパクトがあります。“サービス・パイプライン”から“サービス・カタログ”に乗っかる時は運用の受け入れをしないといけません。

そこで運用受け入れ基準を決めておくこと。サービスポートフォリオでステータス管理している時に、ゲートなどの関門みたいなのを正しく作っておくことで、「きちんとしたものしか“サービス・カタログ”に載せません」とできます。また、廃止になる場合の廃止手順を定めておくことで、不要な管理から外したり、「結局データってどう保存しておけばいいんだっけ？　何年保存しておけばいいんだっけ？」みたいなところを決めておくことで、廃止にかかる工数を最適化できます。

ステータスが変わっていく時に何をやるかを決めていくところが、1つ、サービスポートフォリオの大きな目的だったりします。

サービス管理台帳のサンプル

続いて、サンプルみたいなのをいったん出していますが、もっともベーシックなサービス管理台帳が、スライドのようなかたちになります。左から説明していくと、サービス名があって、続いてサービスの概要があります。そして、サービスレベル。どれぐらいこのサービスが重要なのか。これは別途サービスレベルを規定しないといけませんが、それに従い、SとかA+とか、AとかBをつけていく。

ステータスは今説明したところで、“提供中”だとか、いろいろあります。サービス開始予定日、サービス開始日、管理している部門、責任者、あとは関連するサービスと。今回はサービスAのところで認証システムのような感じで書いているので、他のサービスは全部関連しますというところで、前提になっているサービスや、「このサービスが止まるとこっちも止まるよ」みたいなものを表せたりします。

あとは、いつ、何を廃止したかは、全体を見る観点として、今後のロードマップとしてけっこう重要なことです。そのため、廃止が決まったら“廃止予定日”と“サービス廃止日”というところで、“廃止の理由”も書いておくというようなものが、一番ベーシックなサービス管理台帳です。これに何を付加していくかによって、見えるものが変わってくるという話をしていきます。

サービス管理台帳での役割管理

まず1つ目は、サービス管理台帳に役割を付加していくとどうなんだ？　というところで、1次対応としてはサービスデスク、監視、DCオペレーター、2次対応としてはサービスの管理者と運用者。あと保守の対応としては、ソフトウェアやハードウェアの保守担当というとこで、これはメーカー保守のような話です。

これを、スライドのようなかたちで、各サービスとサービスレベルと担当者と、それが自社でやっているのか、他社にアウトソースしているのかみたいなところをマッピングしていきます。

これをじっくり見ると問題っぽいものが見えてくるので、そこをハイライトしてあります。例えばですが、サービスCのところだけは、サービスレベルがAにもかかわらず情報システム部門が見てる。これはA社の監視サービスなどに統合できないのかと考えたりできるかなと思っています。

サービスBを見てみると、管理者も運用担当者もB部署の佐藤さんとバイネームがついているので、けっこう重要なサービスなのに属人化しているとか。あとは保守の担当が、よくよく調べてみたら保守契約を結んでおらず、なにか起きても結局佐藤さんが全部なんとかしている状態でまわっている。これは、B部署の佐藤さんがいなくなったらどうなるんだという話がわかるようになります。

続いてサービスDというとこで、運用担当者がここだけC社の運用サービスを使っていて、ほかはB社の運用サービスを使っているので、ここをB社に統合したらコストメリットとかあるのかを、全体を俯瞰したかたちで確認できます。もちろん特定の開発ができるのがC社だからそうしているというような、明示的な理由があればいいです。しかし、そういったものがなければ、運用をアウトソースしている先を統合していったほうが、コミュニケーションのロスなどが減り、最終的にはよいんじゃないかといった検討もできるようになる。

サポート切れか、リスクを許容できているかが見えるようになるので、まずは全体を可視化して、そこから課題や問題点を洗い出せるようになります。

これが本当に大きな企業で、サービスが50とかあったりとかすると曼荼羅みたいになっていくので。「こうしたほうがいいんじゃないか」とやっていくだけ、集約・統合するだけで、けっこういろいろと改善が見込めるところが見えてきます。

サービス管理台帳でのツール管理

続いてツール類です。同じ会社であれば、同じツールを使っておいたほうがいいものはいっぱいあります。例えばジョブの管理だったりワークフロー、バックアップ、ログ、パッチとかチケット管理。構成管理とか、ナレッジとか。もちろん自動化で使うAnsibleだったりも、できるだけ同じものを使ったほうが、利用者も運用者も学習コストがあまりかからない。

いろんなものを使える、スーパーエンジニアのほうがいいですが、ただそれは学習コストがかかってしまうので、仕事としてはある程度の種類に抑えたほうが、みんなが使い慣れていくのでいいという発想もできます。

それをまとめてみたのがこちらです。こちらもバッと入れてみたので、問題点を次のページでハイライトしてみます。

まずワークフローシステムです。いわゆるユーザーから申請をもらうところなので、エンドユーザーが一番使うところですね。ちゃんとしたワークフローツールを使っているところから、チャットで連絡すれば大丈夫だったり、メールで申請するみたいなものがいろいろ分かれていると、利用者が混乱します。

社内のサービスであったとしても、同じ申請画面からいろいろなサービスを申請できたほうがいいし、チャットでまとめるなら全部チャットにまとめて、チャットのやり方を決めるふうにしたほうがいい。

サービス利用の方法はできる限り揃えたほうが、利用者の混乱がないし、利用者も使えば使うほどツールを覚えていくので。そういった意味でも、統一したほうがいいかなと思う点です。

サービス管理台帳での運用管理

続いて右のほうにいき、運用管理のチケット管理とか、構成管理、ナレッジ管理というところ。こちらは運用の情報、運用のデータをまとめるものなので、ここを明示的にまとめていくと、実は分析がものすごくしやすくなります。

あるところではチケット管理をExcelでやってて、あるところではTeamsとかSlackでやっていて、あるところではちゃんとした運用管理ツール、インシデント管理ツールを使っているとなると、サービスを横断した分析をしようと思った時に、全部いったんデータの形式を合わせなければいけない。

何にどれぐらい時間がかかっていて、各サービスでどういう問題が起こっているのか。サービスを横断して共通した問題はなんなのかがまったく見えなくなってしまうので、できるだけチケット管理や構成管理、ナレッジ管理の方法は、合わせて1箇所にして、データの形式を合わせるというか、列というか、分類を合わせるようにしたほうがいいと思っています。

これは分析して初めて効果がわかるので、やる前に効果を説明するのはなかなか難しいんですが、絶対に合わせたほうがいいです。ワークフローも実は同じ観点で、ユーザーからの申請が何時に多いとか、実はこういう傾向があって季節性のものがあったりとか、期間性やイベント性のものがあることが、運用、ワークフローを統一することによって初めて見えてきたりするので。運用全体を改善しようと思う時は、データを揃えることが大事になってきます。

監視もそうですが、バックアップなどはそれぞれのサービス、システムの特性があるので、実はバラバラでもあまり影響がなかったりします。ログも合わせたほうがいいですが、という感じです。データを揃えたほうがいいものと、揃えなくてもいいツールがあるので、そのあたりはちょっと意識する必要があるかなと思います。

あと、「最終的には全社でこういうツールを使っていきます」という方針を決めると、スライドのサービスEの列のように、「今後入れる時には、じゃあまずはそれを使っていこう」となるので、運用設計や構築の工数も楽になります。そのため、ツール採用方針や、新しいサービス入れたり新しいシステム入れる場合の方針は、まとめておいたほうがいいと思います。

そういったことを全部まとめていくと、サービス管理台帳でいろいろと問題点が見えて、ここからようやく可視化、自動化が見えてくるかなと思います。

全自動化のためのスタートは、整理・合理化・可視化

今日のまとめです。クラウドサービスの浸透によってというところで、僕の見立てなので違ってるかも、可能性はゼロではありませんが、2006年ぐらいからAWSがEC2などを始め、そこから2011年ぐらいにITIL v3が公開されて。それが本当に浸透してきて、新しいインフラが世界中で使われはじめたという契機で、2019年ぐらいに運用にかかわるガイドラインは全部一新されてます。

なので、運用改善が今やらなければいけないところを、これに合わせてやっていったほうがいいんじゃないかというところで、考えてもらえればと思います。

続いて、OperationやRunといった運用作業は、形式を合わせて全自動化求められているし、うまく使ったり、なんとかするところに運用の比重が大きくなってきているので、スキルも変えていかなければいけないのも大きなところです。

ただ、そういったことをやるために、まずスタートは、整理、合理化、可視化なので、本当に泥くさい作業になりますが、先ほどみたいな情報を集め、1個のデータベースとして扱って合理的に整理して、可視化するところが大事です。それに必要なサービスポートフォリオだというところは、今日説明しました。

さまざまな情報を付加していくことによって、サービス導入時から運用を意識していただけるようになります。まとめていくところに運用の情報を入れていくと、社内的にも運用の価値というか、注目度がどんどん高まっていくと思うので、サービスを管理する、誰がやってるか、何を使っているかをまとめていくのは、けっこう大事じゃないかと思っています。

そういうことによって運用設計も省力化できるので、いいことしかない。けれど、最初は何の効果も生まないので、可視化という段階だと、最初のハードルがなかなか高いですが、みなさんがかかわっている案件などがあったらぜひ、今日を機にサービスをまとめてみたり、ツールをまとめてみたりをやってもらえればと思います。

それでは、ありがとうございました。私からの説明は以上となります。

質疑応答：運用の作業範囲について

永江耕治（以下、永江）：ありがとうございました。質問をけっこういただいてますので、それについて回答をいただきたいと思います。「2冊とも購入して、絶賛読書中です！」「SIerだからかもですが『運用設計の教科書』いい本。お世話になってます」というようなコメントはけっこうもらってます。あと、「これから買おうかな」という方もけっこういるようです。

質問にできる限り答えてもらえるといいなと思っているんですが、1つ目にいきましょうか。「オンプレミス時代の縁の下の力持ちからクラウド時代になって、サービスの管理やデータ分析も求められるようになっている。必要な分野が多岐にわたると、運用はどの範囲までやるのだろうか？」。悩みのような感じですね。

近藤：そうですね。基本的に運用者が扱えるデータが決まっていて、チケットのデータと、障害が起こったりとかで、いわゆるバックエンドのデータが扱えます。

要するに自分の会社、ユーザーさんの会社がビジネスとしてどういったところにアプローチしてくのかという情報だったり、ガリガリの開発の超絶スキルみたいなのには、運用からはアプローチできないので、そこは少し違います。

ただDevOpsという言葉が流行っているのは、それらが一緒になってやってったほうがいいでしょ、という話になっているからで。我々運用としては、そういうチケットデータや会社内の情報、障害がどういうところで発生しやすいかというデータを持ち寄って、開発の人たちと一緒にタッグを組んでやっていくことが求められていくことになります。

その時にデータがないとちょっと辛いので、やはりデータ分析というか、データ収集までが実は運用なんじゃないかなと思っているということです。

質疑応答：マニュアル・ドキュメントの品質と管理について

永江：ありがとうございます。残り、あと4つぐらいいけるといいなと思ってます。「完全な自動化は難しいと思いますが、そういった場合は、マニュアルやドキュメントの品質や管理なども重要だと思いますか？　この部分は簡略化したり、効率化させる方法はありますか？」という質問です。

近藤：完全自動化は、確かにNo Operationsみたいなことを求められて、僕もやったことがありますが、今のところ全部途中で頓挫しているので、完全な自動化は本当に難しいと思います。

ドキュメントやマニュアルに関しては、今後コミュニケーションツールが流行って、Wikiみたいなものに書くことが増えていくんじゃないかなと思っています。ファイルで管理すると、どうしてもデグレが起こったり、どこが最新版かがわからなくなる。

今私もやっているのは、Webベースのドキュメントが書けるもの、Confluenceとか、Backlogとかを使って、Wikiのところにマニュアルを残す。そこが最新版で、「全員ここ見ろ」と情報を集約させていく。ファイル管理をやめる。こういったことをやると、なかなか難しいところもありますが、未来はあるかなと思っています。

質疑応答：サービス管理台帳のメンテナンスについて

永江：ありがとうございます。では続いて、「サービス管理台帳。メンテナンスし続けるのが手間だし、抜け漏れが出てきそうだけど、いい手はあるのだろうか？」。

近藤：僕も友人に言われて心に刺さっている言葉があるんですが、「運用って最終的に台帳管理だよね」と言われて。「まあそうだよね」という話になりました（笑）。

手順などを自動化していったりといろいろやれるけれど、結局台帳の管理はどうしても最後まで残るという話があって。僕もけっこうそのタイプですが、1人本当に口うるさいお局さんみたいな人、「絶対やれよ」って言い続ける人がいると続けられるんですが、そういう人が抜けちゃうと、確かに陳腐化していったりすところはあります。

良い方法としては、承認プロセスや、誰かの承認する時に合わせてメンテナンスを要求するようなプロセスに変える。それもある意味では人力でしかいですが。

質疑応答：クラウド運用と相性のいいものについて

永江：なるほど、ありがとうございます。まだまだたくさんきていますが、「クラウド運用にはコンテナ化やサーバーレスの選択肢がありますが、アジャイルやDevOps、DevSecOpsと相性がよさそうなのはどちらでしょうか？」という質問です。

近藤：用途もありますが、バックエンド社内で使っているものに関しては、仮想マシーンや今までのOSをいろいろとちゃんとチューニングして、穴も塞いでとしたほうが、セキュアなものができる気がしています。

ただ、ユーザーに使ってもらうもので、アクセス数が増えたり、イベントなどでなにか変わるものは、コンテナやサーバーレスのでリソースのオートスケールなどができるものがあって、それらはアジャイルやDevOpsに向いています。というとこなので、システムの用途によってそのあたりは変えていく必要があるかなというのが、僕が今のところで感じていることです。

質疑応答：CS部門とインフラ・運用・保守部門との連携について

永江：ありがとうございます。続いてこちらいきます。「サービス重視ということで、最近はカスタマーサクセスなども注目されていますが、CS部門とインフラ・運用・保守部門はどのように連携すればいいかなどのアドバイスありますか？　問い合わせツールも、CSとトラブルでは合わせたほうがよいのでしょうか？」という質問です。

近藤：ツールは合わせたほうがいいですが、私が見ている中でも、合っていないところがほとんどで。カスタマーサクセス部門とインフラ・保守部門が、性質的にあまり融合しないところはあります。

このあたりがたぶんDevOpsなどの考え方にも近いんですが、情報やデータに注目して、CS部門が持っているデータと、インフラ・保守部門が持っているデータをどう合わせるとうまくいくのかを考えないと。役職で見ると、インフラ・保守部門は絶対エラーをさせない、変なリリースさせないとなるんですが。

カスタマーサクセス部門は「いや、お客さん求めているから」となって、役職で見ると絶対に対立しちゃうので（笑）。持っているデータや、目的、目標みたいなところから合わせていくしかないです。あと、ヒューマンスキルで、誰か飲み会番長みたいな人がいると、意外とうまくいくところはあります（笑）。

質疑応答：新しいサービス構築で意識すること

永江：なるほど。ありがとうございます。「新しいサービス構築の段階から運用について、ここまでは意識しておいたほうがいい、というのはあるのでしょうか？」。

近藤：今日説明した体制とツールは、早めに意識しておいたほうがいいです。どこの部門とか、どういう体制でサービスを運用するのか。中で整理が済んでいれば済んでいるほど、始まるという段階である程度提示できるはずです。なので、今日説明した2点に関しては、早めに連携しておいたほうがいいかなというところです。

質疑応答：部署をまたいだドキュメントの管理について

永江：うんうん。もう1個だけいっちゃいます。「Confluenceを使っているのですが、開発・保守・企画がそれぞれ乱立で部署も異なり、何が信頼できるドキュメントなのか、最新なのか、何を定期的にメンテナンスするべきかわからなくなっています。基準作りはどうやったらできるのでしょうか？」。リアルな質問ですね（笑）。

近藤：そうですね（笑）。これは放っておくと絶対的にこうなりますね。でも、放っておくとこうなるのは、実はそれはそれでいいという考え方もあって。

ドキュメントをどこかの段階で塩漬けすると決めてしまうという考え方もあります。リリース時に塩漬けして、それ以降は全部変更管理で追えるから更新しない、という考え方でうまくいっているところもあります。

なので、完全に新規リリースしたらドキュメントも更新していくというルールにするのか、それとも、ある時点でドキュメントは塩漬けして、それ以降は変更管理などをしっかりする、実機から情報を見やすくするを見やすくするような対応にしていくのか。これは文化として決めなければいけないので。

「どうやったら基準作りができるのでしょうか？」というところの問いには、あまり答えていないんですが（笑）。会社の中の文化が堅い、金融とか官公庁みたいなところは完全にやっていかなければいけませんが、もうちょっと緩いような、生産業などの場合は、変更を必要な時に追えればいいというところで諦めるというのも1個手かなと思います。

永江：はい、ありがとうございます。いったんここまでとしたいと思います。近藤さん、ありがとうございました。

近藤：はい、ありがとうございました。