マシンルームから愛を込めて【第3回】
システム運用管理の理想形はラーメンチェーン店?
システム情報を必死にかき集め、完ぺきなドキュメントを作り上げても、それだけでは運用管理業務は回らない。ITサービスの品質を保つためには、情報の見える化に加えて「作業の平準化」が不可欠なのだ。
前回「大惨事を招く前に……システム運用の改善は『可視化』から」では、安定したシステム運用を行うためになぜ「可視化」(見える化)が必要なのかというお話をしました。そして、「可視化は安定運用のための第一歩である」と述べましたが、今回は安定した運用サービスの実現に向けてさらにもう一歩踏み出すために、「システム運用の平準化」というお話をしてみたいと思います。
ところで「平準化」という言葉、あまり普段の生活で使うことはありませんよね。ここで、あらためて平準化という言葉の意味について考えてみましょう。辞書で調べてみると、平準化とは「偏在するばらつきを、標準値にならす作業」とあります。何だかとっつきにくい言い回しですが、これをITサービスに当てはめて解釈してみると、「各個人がバラバラに行っていることを、誰でも実施可能な共通作業にならす作業」といったところでしょうか。そして、そのための「元ネタ」となるのが、前回お話しした「可視化された情報」になるのです。
可視化された情報を基に、ITサービスを提供するために必要な業務プロセスを作り、それに従えば誰でも正しく作業ができるようにすることこそが、「平準化をする」ということなのです。
ラーメンの味を均一に保つには?
ここで前回、前々回に引き続き、わたしの大好物であるラーメンの例えで説明してみましょう。わたしがよく利用する、あるおいしいラーメンチェーン店があります。どの店舗で食べても同じ味のラーメンが出てくるので、とても安心できます。
さて、このチェーン店では一体どうやって散在する複数の店舗間で同じ味を維持しているのでしょうか? 「同じ食材を使う」「調理マニュアルを統一する」といったことは当然行っていることでしょう。
しかし、ラーメンを一度も作ったことがない人間に食材と調理マニュアルだけを渡して、「さあ、ラーメンを作ってください」と言っても、到底無理でしょう。恐らく、調理マニュアルに書かれた手順や情報以外にも、ラーメンを作るためのさまざまな段取りが複数定められているに違いありません。
わたしはラーメン店の内情を知る身ではないのですが、きっとラーメン1杯をお客さんに提供するために、事前の教育や実技トレーニング、味のチェックなどといった段取りが決められていることでしょう。すなわち、マニュアルや手順などの形に可視化された「情報」だけではカバーしきれない「プロセス」を踏んでいると考えられます。
可視化された情報だけでは同じ味のラーメンは作れない、つまり品質の平準化は行えないということを何となくご理解いただけたかと思います。
平準化をないがしろにするとどうなるか……
さて、話は戻って「ITサービスの平準化」です。ここで、ITサービスにおける平準化の重要性を読者の皆さんに分かっていただくために、あえて弊社インフォリスクマネージがかつて経験した失敗談を披露してみたいと思います。
ある顧客のシステム運用に従事していた社員が、人事異動でその業務を離れなければならなくなりました。その案件に関しては非常に安定したサービスを提供しており、顧客からも厚い信頼を得ていました。そんな良好な案件を受け継いだ後任者に、思わぬ悲惨な状況が待ち構えているとは、そのとき誰が予想できたでしょうか……。
この案件に関するドキュメント類は実に豊富にそろっていました。つまり、情報は十分に可視化されていたのです。ところが、顧客との間で交わされた契約の内容があいまいで、サービス提供範囲が不明確だったのです。長い間、特定の人間に依存してサービスを提供していたため、弊社担当者と顧客との間でしか分からないような暗黙のルールや作業分担が存在していたのです。
実際に後任者が業務を引き継いでみると、ドキュメントは一通りそろっているものの、それを基に具体的にどの範囲の作業をどのタイミングで行えばいいのか、判断に迷う場面が多々発生しました。それらを作業前にいちいち顧客に確認しなければならず、そうしているうちに「前任者の○○さんなら、いちいち言わなくても分かってくれた。昔は良かった」などと嫌みを言われる始末です。日を追うごとに顧客のいら立ちは募り、とうとう「対応が遅い!」「クオリティーが下がった!」などのクレームにまで発展してしまいました。
読者の皆さんの中にも、似たようなケースを経験された方がいらっしゃるかもしれません。今回紹介したケースの場合、本来は弊社担当者と顧客との間の作業分担や作業プロセスをあらかじめ定義しておき、たとえ担当者が変わっても同じプロセスを引き続き遂行できるようにしておくべきだったのです。そうすれば、サービス品質の低下を招くこともなく、クレームを受けることもなかったでしょう。
人事異動や退職もそうですが、人間である以上、誰しも病気や事故などに遭遇して、ある日突然業務に従事できなくなる可能性があります。前回は、こうしたリスクを回避するために情報を可視化しておくことが大事だと述べましたが、それだけでは十分ではないことも理解いただけたかと思います。システムに関する静的な情報がいくらそろっていても、それらを活用して具体的にどう作業を進めればいいのか、すなわち業務プロセスが定められていないと、いざというときにITサービスの品質を維持することはできません。サービス品質の維持・向上のためには、可視化だけでなく平準化も不可欠なのです。
ITサービスの平準化に必要なこと
では、ITサービスの平準化を実現するためには、何を行う必要があるのでしょうか? 大まかに分けると、以下3つのステップを踏む必要があるかと思います。
- 可視化された情報の分析
- 分析結果を基に提供サービスのプロセスを作成
- 作成したプロセスを現場に展開
可視化された情報の分析
可視化された情報は、あくまでも安定運用のための1つのツールにすぎません。この情報を分析することによって、初めて重複作業を整理したりあいまいな業務範囲を明確にすることが可能になるのです。
この分析作業に実際取り組んでみると、意外と多くの担当者が同じような作業を重複して行っていることに気付きます。しかしだからといって、それぞれの担当者が寸分たがわず同じ内容の作業を行っているわけではありません。
例えば、サーバのログのチェック作業。どの担当者がどのサーバで作業を行ったとしても、ほぼ同じような手順を踏むことでしょう。しかし、それぞれの作業プロセスを細かくチェックしてみると、担当者によってログ内のチェック項目がわずかに異なっていたり、メールで結果を報告する際のフォーマットが異なっていたりします。このような場合、例えばチェック項目を可視化し、分析してみることで、本当にチェックすべき項目が見えてきます。そうすればおのずと、ログチェック作業の標準を設けることも可能になってくるでしょう。このようにしながら、個々の担当者がバラバラに行っていた作業を共通化していくのです。
また、可視化された情報を1つ1つ分析することにより、どの作業が顧客の分担なのか、どの作業が自分たちの分担なのかを正確に切り分けることが可能になります。逆に言うと、これをきちんと行わない限りは、顧客との間で取り交わされたあいまいな契約が原因でグレーな作業範囲が発生し、前述のようなトラブルが発生するリスクに常に付きまとわれることになります。
分析結果を基に提供サービスのプロセスを作成
次に、可視化された情報の分析結果を基に、提供するサービスの業務プロセスを構築していきます。リソースの配置や連絡体制など、実際に業務を遂行する上で必要なプロセス作りです。先ほどの例でいえば、共通化したログチェック作業のプロセス、顧客との役割分担を明確にした作業のプロセスを定めます。もちろん、構築したプロセスは業務フロー図などに落とし込み、明文化しておくことが重要です。
こうしておくことにより、有事を想定したバックアップ体制や緊急体制を築くことができるだけでなく、重複作業を複数の担当者間でローテーションさせるというようなことも可能になります。
作成したプロセスを現場に展開
最後に、構築した業務プロセスを現場に適用していきます。どんなに有用な情報やどんなに優れた業務プロセスも、実際に現場で使われなければ結局「絵に描いたもち」で終わってしまいます。現場に業務プロセスを浸透させるためには、認識合わせのミーティングを行ったり、チーム単位でプロセス導入に取り組んでいくといった方法が有効です。
またクライアント別、作業別に業務プロセス遂行の責任者を決め、情報やステータスを集約して一元管理することも有効です。プロセス全体を見渡すことができる管理者がいると、情報の錯綜(さくそう)や不整合を避けることができます。
特定の担当者が顧客の顔色やその場の雰囲気で対応を決めているようなケース、意外と多くありますよね。もし思い当たるふしがあれば、これを機にここで挙げた3つの取り組みをぜひ試してみてはいかがでしょうか?
さらに安定したシステム運用へ向けて
ITサービスの平準化が行えるようになると、ユーザーからのさまざまな要望に対して組織的な対応を行うことが可能となります。本連載の第1回「運用管理に『コーン入りしょうゆラーメン』の発想を」の内容を思い出してみてください。そこで挙げた例を引くならば、みそラーメン用のコーンをしょうゆラーメンに入れてほしいというお客さんのリクエストに対して、店員個人の判断ではなく、店全体の組織的なサービスとして対応できるようになるというわけです。
しかしながら、まだ解決していない問題が残っています。コーンの量や値段は、一体どうやって決めればいいのでしょうか……。この問いに答えるために、次回は「サービスレベルの定義」という話をしたいと思います。
<筆者紹介>
山本祥一
インフォリスクマネージ株式会社 ソリューションサポート事業部長
2000年インフォリスクマネージ株式会社入社。
システムダウン対策事業(MSP/ホスティング)のセールス、運用設計などに従事。2006年よりソリューションサポート事業部長として、50名以上のエンジニアを部下に抱え、官公庁はじめ、24時間365日止められない大型インターネットシステムの構築支援および運用設計を指揮・統括。また、情報セキュリティマネジメント(ISMS)の審査員も務める。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
5
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
6
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
7
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
10
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー