運用エンジニアの減点評価について考えてみた

私はユーザー企業の社内SE（情シス）としてインフラを中心に企画から設計、構築まで、たまにアプリのお手伝いに駆り出される感じのなんでも屋として働いていた。
この文章はあくまでも私の体験をベースにしたものであり、一般化できるものではないし、誰かを貶める意図はないことを予めお断りしておく。

情シスの様々な業務の中でも、インフラ担当者のよくある悩みとして、「インフラを維持する努力が会社から評価されづらい」というものがある。
インフラから見れば基幹システムなどのアプリケーション担当者はエンドユーザーと接する機会が多く、ユーザーの要望を実現する存在として重宝されるのに対し、ネットワークに代表されるインフラの維持管理はいわゆる「動いて当たり前」で、重要性は認識されているものの、意識に上らないため「何をやっているのかわからない」などと失礼なことを言われた挙句、部署間の調整で評価を下げられるなど、感謝やリスペクトを集めているとはいいがたい面があると思う。

この原因は情報システムのサポート自体が減点方式で顧客（エンドユーザー）に評価されがちであるところに構造的な問題があるのではないかと考えた。
情シスの仕事を評価することは非情シスの人間には難しすぎる。
難しいから減点方式になる。
頑張ったところや課題そのものの難しさは関係なく、問題が起きたことだけをとらえて減点される。問題が起きなかったとしても加点されない。
そのような構造があるように感じられた。

実は私は勤務していた情シスで大きな配置転換を経験している。
あるとき国内のヘルプデスク・インフラ担当から、海外拠点のヘルプデスク・インフラ担当へ業務が変わった。
サポートするべきエンドユーザーが変わったので信頼関係を一から構築する必要があった。

悪いことに私の語学力はかなり低く、英会話ではおそらく1割程度の単語しか聞き取れない。（TOEICは595点）メールはGoogle翻訳を駆使して読み書きするレベルだ。コミュニケーションがまともにとれないというハンデを負っている。

国内に勤務しながら海外のサポートをする場合、私の勤務評価は上司がするが、私の貢献を評価するのは現地法人のマネージャーになる。
現地法人のマネージャーに「あいつはよくやってくれている」という評価を上司に吹き込んでもらうことが評価の改善に必要なことだった。

それまで国内で感じていた減点方式での評価構造をなんとか変えたいと思っていた私はこの配置転換をチャンスだととらえた。

減点方式を加点方式に変えるにはどうすればよいか。
私が出した答えは「プロセスを見せる」事だった。

学生時代、数学の試験で部分点をもらうように、結果が思うようにいかなかったとしても、途中経過を評価者に納得してもらえれば部分点をもらえる可能性はある。
情シスの「評価者」はエンドユーザーだ。エンドユーザーの満足度が高ければ評価はついてくる。
エンドユーザーとの信頼関係があれば、こちらからの指導やチェックもきちんと受け止めてもらえるはずだと考えた。

目指したのは以下のことだ。
・出来るだけプロセスを見せ、関係者とのコミュニケーションを大切にする
・エビデンスを取り、社外に対して言うべきことをきちんと言う
・わからないまま放置しない。一件一件をきちんと終わらせていく

情シスのリソースはそもそも限られている。その限られたリソースを「問題解決プロセスの可視化と改善」に割り当てた。
障害を起こしたか否かでバッサリ評価される構造から解決プロセスまでを含めて評価する構造に変える。
具体的には問題の原因究明、対策立案など、情シスのオペレーション全般のスピードや妥当性、問い合わせに対するレスポンス速度等を改善して、それを評価してもらう。
これはエンドユーザーを教育することにもつながっていく。
教育とはエンドユーザーに情報システムの知識をインプットすることではない。情シスが担っている仕事のボリューム感や付随する判断基準、仕事の進め方を見せ、情シスの考えるプロセスを感じてもらうことを心掛けた。

例えば、オペレーション一つでも自分の中で仮説を立てる。機器を再起動する場合でも理由を考える。なぜ次の一手が再起動でなければならないのか。「とりあえず」という言葉はなるべく封印した。
実行コストの低さ、出ている現象、そういったものを総合的に判断し、再起動という結論に至ったことが説明できれば良い。
これは思考の訓練であり、慣れると短時間でできるようになる。
このようなオペレーションの理由付けが関係者間のコミュニケーションで効いてくる。
相手を見ながらなるべくこちらの姿勢を理解してもらえるよう情報発信を続けた。すべての行動に理由があれば説明はしやすい。「なぜ？」という質問は絶好球に変わる。必ず打ち返せるし、相手は黙る（そのうちあまり言われなくなる）
「ある現象を観測したため、○○した」という英文は書きやすい。推測や仮定が入らない。

この方法のためには、応用範囲の極めて広いデータを収集し、分析する技能が欠かせない。
OSやアプリに依存せず、それ自体エビデンスとして機能する高解像度データ、つまりパケットキャプチャだ。

余談だが、最初の頃は問題が起きたときに必要であればパケットキャプチャを取得する一般的なスタイルだったが、海外にSDNを導入したことをきっかけに常時取るやり方に変えた。
SDNで精密なデバッグが必要だったことが直接の理由だったが、そのうちこの方式がとてつもなく便利だということに気づいた。
再現を待たなくてよいため、ユーザーから受けた相談へのレスポンスが格段に速くなる。
目標として掲げた3つの項目を達成するための仕組みとして非常に強力な助けとなった。私がパケットキャプチャが満足に読みこなせるようになるまでは数年かかったが、常時取る方式であれば、異常と正常を比べれば違いが分かるようになるので、これから取り組む人も短期間で追いつけると思う。

エビデンスをもとに判断し、コミュニケーションを改善する工夫をした結果として、情シスとしての評価を減点方式から加点方式に変えることができた。

あるとき、後輩が海外法人の研修生として赴任して、現地スタッフの情シスに対する信頼感がすごいと全社にレポートしてくれたことがあった。
コミュニケーションしにくい相手との交流において、自分なりに工夫したことが評価されるのは報われたようでうれしかった。

まとめ

減点方式を加点方式に変えるには

・データをそろえ、プロセスに理由を付ける
・関係者にプロセスを見せる（ことさらに見せようとせずともにじみ出る）
・コミュニケーションは大事、工夫する

偉そうに言いますが、実現まで何年もかかりました。この記事が読者の皆さんの参考になればうれしく思います。