パターン1：「過去の確認」で生じる4つの危険性

パターン1：「過去の確認」で生じる4つの危険性

まず、1つ目のパターンである「過去の確認」について考えてみよう。これに該当する作業は、「リソース利用状況を目視でグラフから確認する」などである。これには、何らかの基準を元に定期的に「過去」の状態を確認するものが該当する。具体的には、表2に示す内容が該当する。

このような運用を人力で行うと、

1. 運用ルールの煩雑化
2. ルール絶対主義の台頭
3. 目的の形骸化
4. 疲弊

という、4つの問題が生じる危険性がある。

運用ルールの煩雑化

「運用ルールの煩雑化」は、個人の主観が多く入ることによる問題である。

例えばリソース利用状況のグラフの確認では、グラフから何を読み取るかといった確認ポイントを、全運用担当者が100パーセント同じ感覚を共有することは難しい。その結果、確認ポイントが全員で共有されず、個人の主観が入った確認になり、分析結果の蓄積が意味をなさなくなる。

すべての運用担当者が、同一の視点で確認できるよう手順化を推し進めることもできるかもしれない。しかし、ステップごとに細かなチェックポイントや判断基準を設ければ設けるほど分析は複雑化し、運用担当者間のコンセンサスをとるのが難しくなる。その場凌ぎの場当たり的な運用ルールの追加が横行してしまう。

絶対主義の台頭

「ルール絶対主義の台頭」は、問題が発生した場合に原因を見誤る問題である。

前述の「運用ルールの煩雑化」が進むと、問題があった場合の失敗の原因を、手順に求める傾向になっていく。個人の技量や習熟の問題を先送りにしてしまうのである。それどころか、手順が神格化されるにつれて、個人の技量を考慮しない空気が形成される結果を生むことさえもあるのだ。

目的の形骸化

「目的の形骸化」は、システム運用本来の目的を見失う問題である。

「運用ルールの煩雑化」や「ルール絶対主義の台頭」が進むと、まるで伝統となった手順の継承がシステム運用の目的なのではないかと思えるような、運用体制ができあがってしまうことがある。

日々のシステム運用は、本来システムの変化を捉えるための作業であったはずなのに、手順に従うことが目的となってしまう。これは、システムの変化を捉える絶対的な基準がないからだ。こうなってしまうと、ルール管理者の顔色を伺わねばならず、職場では基準のわからない叱責が飛び交うということも発生しうる。

疲弊

「疲弊」は、運用担当者が疲弊していく問題である。

「運用ルールの煩雑化」や「ルール絶対主義の台頭」が進み、複雑化したチェックポイントの群れに立ち向かうなかで、運用担当者がルールを改善する時間は失われていく。その結果、運用担当者の視野はますます狭窄（きょうさく）していく。狭い視野はルールの先鋭化（複雑化）を推し進め、さらに運用担当者の時間と気力を奪うことになりかねない。このように疲弊したシステム運用技術者は、新たな仕事や違う環境での仕事を求めて、会社を去ってしまうかもしれない。こうなってしまうと、システム運用は、完全に負のスパイラルに陥ってしまう。

「過去の確認」に該当する業務が多い現場では、次のような会話をよく耳にする。

「…のミスは手順の…に問題があるんじゃない？」

「なんで言われたとおりに作業しないの？」

「それは手順に書いてあるの？」

「手順に書いてあったので…」

読者のみなさんの会社では、このような会話が聞かれることはないだろうか。