トラブルシュートの真髄はトラブルシュートそれを作業に変えてしまうこと

いやはや、緩募に間に合わなくて結果的に迷惑を掛けなくてよかった……。
トラブルになるなんておもんわなかったんだもの。それはそれでしょうがないというか、いろいろと、ふりかえりネタになるというか。
いやホント、ビックリしたと言うか。

経験していることでも時間が経つと忘れる
某プロジェクトは今どきで言えばそれなりに長い部類になるかもしれないんだけど、所謂、プロジェクトの中にいくつかのサブプロジェクトが並んで走る並行線表なんですね。で、これまでやってきた作業を別の線表で作業をするんですけど、ある作業がちょっと“間”が空いたんですね。

同じ作業でも線表が違うから、その“対象”となる環境下においては“ハ・ジ・メ・テ”な作業のわけです。はい。

で、間が空く前の作業でいろいろと勉強をしてきたんですよ。時間も体力も使って。それ、すっかり忘れてしまっていましたねぇ。はい。すっかり。もう、ワロタって感じ。

作業計画とか作業手順書とか、間が空く前に用意していたこともソレ＝忘れてしまっていたということに輪をかけたかもしれませんねぇ。事前に準備することは先々の予定が見通しが立っているときはいいことなんですけど、忘れちゃったんですねぇ。

“準備したときと実際に作業するときの差異があるかを確認することを”

というわけで、トラブルです！(かもしれない)
エンジニアにはトラブルになると俄然張り切る人もいますが、「え？お前だろうって？またまたご冗談を。おほほ。」、ここはプロジェクトマネージャやSEリーダの頑張りどころですね。

トラブルの時点では、まだそれが不具合なのか仕様どおりの動きなのかそれは誰も断言できませんね。類似のインシデントがあって、顕在している事象に一致しているものがあるなら別ですけど。

エンジニアの特性として、特に現場に近い、開発や構築を手掛ける担当のエンジニアに多いのが、何か、この場合はトラブルが発生するとそのまま前のめりに頭からダイブしてしまって、当てもなく解析やあてずっぽでシステムのパラメータをいじってしまうことです。

これ、ダメです。そのシステムが本番のサービスをしているシステムならとんでもないことです。なぜって、わかりますよね。トラブルが起きたたら初めに何をしないといけないか。

“まずは、現場を保存せよ。”

です。事実のまま、今起きている事象を確保するんですよ。何時、誰が、何をして、どうなっているか、を。その“何をして”起きたのか、そのシチュエーション、画面のスクショ、ログの収集を最初に確保するんです。これは、

“トラブルのエビデンスを確保する”

ということです。起きたことを何を持って正確に再現できるかという観点でエビデンスを確保します。このエビデンスがなければあとでそのトラブルがトラブルなのか、そうでないか、切り分けも解析もできなくなってしまわないように。

トラブルシュートは作業に落とすの真意
現場を確保できるということは、それを別の環境に移して再現できるという可能性を確保することです。それを確保することにより、それこそ、自由に思うがままに、解析も試行錯誤もできるのです。

でも、それだけではトラブルシュートとしては進まないですね。トラブルシュート、それ全体を進められるように誰かが旗を振らないといけない。それはそのトラブルのインパクトによってプロジェクトマネージャかもしれないし、SEリーダかもしれないし、担当エンジニアかもしれない。何れにしても、誰がが率先して問題を切り分けていかないといけないんですよ。

じゃあ、どうするかってことですけど、それこそ、プロジェクト自体が同じものがこの世にないと定義されているのと同じように、トラブルの方がもっと千差万別ですよね。そんなこと言われなくてもわかりますと速攻でツッコまれそうですけど。

でも、そのトラブルシュートの、問題解決の手法ってないんじゃないんですか。こうやればいいっていうのが。それこそ、一人一人のエンジニアがトラブルにあって、当事者にならないと経験できないんですから。エンジニア個人のノウハウでしかない。

ワタシ自身、これなんとかしたいと思うけれど、それを共有できる形式知に落とせるのかどうかなんて、実は考えてもみなかったんですね。で、このケースでたまたま

「そういう形式知にできる“ところ”もあるんじゃないか？」

って思ったんです。漠然と。で、トラブルシュートに手をつけて、ホワイトボードにがーっとToDoを書いて、作業指示やしていいこと、ダメなことをブリーフィングして作業が進んだときにホワイトボードを見て、

「あ、これだ。」

と。そう、ホワイトボードに書いた様々な情報の中で普遍的なことがあるんじゃないか。それは、パタンになるんじゃないか。パタンにできるなら、それをテンプレにしておけばいいんじゃないか。そう思ったんです。

トラブルシュートの真髄なんていいましたけど、それは、パタンを作って、それを使うことでその領域に長けているエンジニア以外でもそのパタンに情報を埋め込んでいけば、トラブルシュートも作業レベル“に”ランクダウンするんじゃないか、と。

作業になれば誰もどうしてよいか“悩む”必要がなくなりますね。悩んでしまうから悩んでいるうちにトラブルシュートの目的を忘れてやっていはいけないことをやったりしてしまうということ、それを作業にすることで防止できるんじゃないか、と。

勿論、それほど簡単に、都合よくはいかないと思うんですが、パタンはないよりあった方がいいでしょう。結局はそのパタンを作れる人がノウハウを握ったままであることは変わらないですけれど、そういうパタンがあることで一つステップを飛び越えて作業として経験できるので、そのパタンのノウハウを理解することに早く到達できるのではないかな、って思ったんです。