マシンルームから愛を込めて【第3回】

システム運用管理の理想形はラーメンチェーン店？

システム情報を必死にかき集め、完ぺきなドキュメントを作り上げても、それだけでは運用管理業務は回らない。ITサービスの品質を保つためには、情報の見える化に加えて「作業の平準化」が不可欠なのだ。

公開 2009年08月03日 08時00分

更新 2012年09月04日 17時54分

著者

山本祥一

[インフォリスクマネージ]

印刷する

　前回「大惨事を招く前に……システム運用の改善は『可視化』から」では、安定したシステム運用を行うためになぜ「可視化」（見える化）が必要なのかというお話をしました。そして、「可視化は安定運用のための第一歩である」と述べましたが、今回は安定した運用サービスの実現に向けてさらにもう一歩踏み出すために、「システム運用の平準化」というお話をしてみたいと思います。

　ところで「平準化」という言葉、あまり普段の生活で使うことはありませんよね。ここで、あらためて平準化という言葉の意味について考えてみましょう。辞書で調べてみると、平準化とは「偏在するばらつきを、標準値にならす作業」とあります。何だかとっつきにくい言い回しですが、これをITサービスに当てはめて解釈してみると、「各個人がバラバラに行っていることを、誰でも実施可能な共通作業にならす作業」といったところでしょうか。そして、そのための「元ネタ」となるのが、前回お話しした「可視化された情報」になるのです。

　可視化された情報を基に、ITサービスを提供するために必要な業務プロセスを作り、それに従えば誰でも正しく作業ができるようにすることこそが、「平準化をする」ということなのです。

ラーメンの味を均一に保つには？

　ここで前回、前々回に引き続き、わたしの大好物であるラーメンの例えで説明してみましょう。わたしがよく利用する、あるおいしいラーメンチェーン店があります。どの店舗で食べても同じ味のラーメンが出てくるので、とても安心できます。

　さて、このチェーン店では一体どうやって散在する複数の店舗間で同じ味を維持しているのでしょうか？　「同じ食材を使う」「調理マニュアルを統一する」といったことは当然行っていることでしょう。

　しかし、ラーメンを一度も作ったことがない人間に食材と調理マニュアルだけを渡して、「さあ、ラーメンを作ってください」と言っても、到底無理でしょう。恐らく、調理マニュアルに書かれた手順や情報以外にも、ラーメンを作るためのさまざまな段取りが複数定められているに違いありません。

　わたしはラーメン店の内情を知る身ではないのですが、きっとラーメン1杯をお客さんに提供するために、事前の教育や実技トレーニング、味のチェックなどといった段取りが決められていることでしょう。すなわち、マニュアルや手順などの形に可視化された「情報」だけではカバーしきれない「プロセス」を踏んでいると考えられます。

　可視化された情報だけでは同じ味のラーメンは作れない、つまり品質の平準化は行えないということを何となくご理解いただけたかと思います。

平準化をないがしろにするとどうなるか……

　さて、話は戻って「ITサービスの平準化」です。ここで、ITサービスにおける平準化の重要性を読者の皆さんに分かっていただくために、あえて弊社インフォリスクマネージがかつて経験した失敗談を披露してみたいと思います。

　ある顧客のシステム運用に従事していた社員が、人事異動でその業務を離れなければならなくなりました。その案件に関しては非常に安定したサービスを提供しており、顧客からも厚い信頼を得ていました。そんな良好な案件を受け継いだ後任者に、思わぬ悲惨な状況が待ち構えているとは、そのとき誰が予想できたでしょうか……。

　この案件に関するドキュメント類は実に豊富にそろっていました。つまり、情報は十分に可視化されていたのです。ところが、顧客との間で交わされた契約の内容があいまいで、サービス提供範囲が不明確だったのです。長い間、特定の人間に依存してサービスを提供していたため、弊社担当者と顧客との間でしか分からないような暗黙のルールや作業分担が存在していたのです。

　実際に後任者が業務を引き継いでみると、ドキュメントは一通りそろっているものの、それを基に具体的にどの範囲の作業をどのタイミングで行えばいいのか、判断に迷う場面が多々発生しました。それらを作業前にいちいち顧客に確認しなければならず、そうしているうちに「前任者の○○さんなら、いちいち言わなくても分かってくれた。昔は良かった」などと嫌みを言われる始末です。日を追うごとに顧客のいら立ちは募り、とうとう「対応が遅い！」「クオリティーが下がった！」などのクレームにまで発展してしまいました。

　読者の皆さんの中にも、似たようなケースを経験された方がいらっしゃるかもしれません。今回紹介したケースの場合、本来は弊社担当者と顧客との間の作業分担や作業プロセスをあらかじめ定義しておき、たとえ担当者が変わっても同じプロセスを引き続き遂行できるようにしておくべきだったのです。そうすれば、サービス品質の低下を招くこともなく、クレームを受けることもなかったでしょう。

　人事異動や退職もそうですが、人間である以上、誰しも病気や事故などに遭遇して、ある日突然業務に従事できなくなる可能性があります。前回は、こうしたリスクを回避するために情報を可視化しておくことが大事だと述べましたが、それだけでは十分ではないことも理解いただけたかと思います。システムに関する静的な情報がいくらそろっていても、それらを活用して具体的にどう作業を進めればいいのか、すなわち業務プロセスが定められていないと、いざというときにITサービスの品質を維持することはできません。サービス品質の維持・向上のためには、可視化だけでなく平準化も不可欠なのです。

ITサービスの平準化に必要なこと

　では、ITサービスの平準化を実現するためには、何を行う必要があるのでしょうか？　大まかに分けると、以下3つのステップを踏む必要があるかと思います。

可視化された情報の分析
分析結果を基に提供サービスのプロセスを作成
作成したプロセスを現場に展開

可視化された情報の分析

　可視化された情報は、あくまでも安定運用のための1つのツールにすぎません。この情報を分析することによって、初めて重複作業を整理したりあいまいな業務範囲を明確にすることが可能になるのです。

　この分析作業に実際取り組んでみると、意外と多くの担当者が同じような作業を重複して行っていることに気付きます。しかしだからといって、それぞれの担当者が寸分たがわず同じ内容の作業を行っているわけではありません。

　例えば、サーバのログのチェック作業。どの担当者がどのサーバで作業を行ったとしても、ほぼ同じような手順を踏むことでしょう。しかし、それぞれの作業プロセスを細かくチェックしてみると、担当者によってログ内のチェック項目がわずかに異なっていたり、メールで結果を報告する際のフォーマットが異なっていたりします。このような場合、例えばチェック項目を可視化し、分析してみることで、本当にチェックすべき項目が見えてきます。そうすればおのずと、ログチェック作業の標準を設けることも可能になってくるでしょう。このようにしながら、個々の担当者がバラバラに行っていた作業を共通化していくのです。

　また、可視化された情報を1つ1つ分析することにより、どの作業が顧客の分担なのか、どの作業が自分たちの分担なのかを正確に切り分けることが可能になります。逆に言うと、これをきちんと行わない限りは、顧客との間で取り交わされたあいまいな契約が原因でグレーな作業範囲が発生し、前述のようなトラブルが発生するリスクに常に付きまとわれることになります。

分析結果を基に提供サービスのプロセスを作成

　次に、可視化された情報の分析結果を基に、提供するサービスの業務プロセスを構築していきます。リソースの配置や連絡体制など、実際に業務を遂行する上で必要なプロセス作りです。先ほどの例でいえば、共通化したログチェック作業のプロセス、顧客との役割分担を明確にした作業のプロセスを定めます。もちろん、構築したプロセスは業務フロー図などに落とし込み、明文化しておくことが重要です。

　こうしておくことにより、有事を想定したバックアップ体制や緊急体制を築くことができるだけでなく、重複作業を複数の担当者間でローテーションさせるというようなことも可能になります。

作成したプロセスを現場に展開

　最後に、構築した業務プロセスを現場に適用していきます。どんなに有用な情報やどんなに優れた業務プロセスも、実際に現場で使われなければ結局「絵に描いたもち」で終わってしまいます。現場に業務プロセスを浸透させるためには、認識合わせのミーティングを行ったり、チーム単位でプロセス導入に取り組んでいくといった方法が有効です。

　またクライアント別、作業別に業務プロセス遂行の責任者を決め、情報やステータスを集約して一元管理することも有効です。プロセス全体を見渡すことができる管理者がいると、情報の錯綜（さくそう）や不整合を避けることができます。

　特定の担当者が顧客の顔色やその場の雰囲気で対応を決めているようなケース、意外と多くありますよね。もし思い当たるふしがあれば、これを機にここで挙げた3つの取り組みをぜひ試してみてはいかがでしょうか？

さらに安定したシステム運用へ向けて

　ITサービスの平準化が行えるようになると、ユーザーからのさまざまな要望に対して組織的な対応を行うことが可能となります。本連載の第1回「運用管理に『コーン入りしょうゆラーメン』の発想を」の内容を思い出してみてください。そこで挙げた例を引くならば、みそラーメン用のコーンをしょうゆラーメンに入れてほしいというお客さんのリクエストに対して、店員個人の判断ではなく、店全体の組織的なサービスとして対応できるようになるというわけです。

　しかしながら、まだ解決していない問題が残っています。コーンの量や値段は、一体どうやって決めればいいのでしょうか……。この問いに答えるために、次回は「サービスレベルの定義」という話をしたいと思います。

＜筆者紹介＞

山本祥一

インフォリスクマネージ株式会社ソリューションサポート事業部長

2000年インフォリスクマネージ株式会社入社。

システムダウン対策事業（MSP／ホスティング）のセールス、運用設計などに従事。2006年よりソリューションサポート事業部長として、50名以上のエンジニアを部下に抱え、官公庁はじめ、24時間365日止められない大型インターネットシステムの構築支援および運用設計を指揮・統括。また、情報セキュリティマネジメント（ISMS）の審査員も務める。

印刷する