受け入れられる“やらないロジック”を作る

何のことかさっぱりわからないと思うので背景からね。

トラブルは突然やってくる
プロジェクトによっては、システム環境の順次リリースとかあるわけです。で、先にリリースしたシステム環境は手離れしてエンドユーザに開放したり、そのシステムに乗るアプリケーションシステムの改修などでバリバリ使われるんですね。
＃まぁ、使うために作っているのでうれしい限りです。

で、後続工程をちまちまとやっているときに突然「トラブルだから早く現地に行け！」とか連絡があってね。はい、行かせますけど「(事情が分からないよ。)」なんて内心思いながら最低限の情報を得ようと誰でも動きますよね。

“いつ”、“誰が”、“何して”、“どうなっている”とかとか。
現地には誰がいて、誰に断って入館すればいいのか、とか。
今は、本番環境の扱いなの？とか。
USメモリとか記憶媒体とか持込みOK？手続きは？とか。

内部では、最低限得られた情報と、いまいまのタスクを止められて、且つ、最低限の情報でフィットする技術を持っている人で、現地で言動を含めて現地の当事者の人が不安にならないふるまいをできる人は？とか、そういった条件で人選して現地に送り出すわけです。

容疑者が一次切り分け
まぁ、こうしたトラブルでお声が掛かる場合、大体、呼んだ方は呼びつけたシステムを容疑者、−容疑者は言い過ぎかな、トラブルを起こした犯人？みたいに思っているので(あまり変わらないか…)−、だと思っているので早く切り分けて直してよ、っていう感じの視線をバシバシと飛ばしてくることが多いです。

で、端末を借りて、担当するシステムを起動したり、現象を見て見たり、再現してもらったりするとき、後ろにジッと立って暗黙のプレッシャを掛けてきているのでは？と思うほど、まじまじと観察されるわけです。
＃ホントやりにくい。

現象、症状を見て、あたりを付けて、仮説を立てて。立てた仮説から疑惑を突きつけられる機能が吐くログファイルを覗いてみたり、メッセージ画面を見てみたり。で、次第に犯人に近づくんですね。そうした切り分けで確認する画面やログは後で仔細に観ることは確実なので、ちまちまと回収しつつ。

こちらは、最低限の情報からざっくりと仮説を立てて、「やべっ、これどうみてもうちが犯人！」とか「いや、絶対アクセス権限を誰かいじっただろう？」なんて想定して現地に入りますね。そうしないと闇雲な切り分けになっちゃうからね。

本来であれば、現地の人が“一次切り分け”をすることが多いですがそれにしても結局彼らがもてあませば彼らの切り分けた情報をもとに、“二次切り分け”しないといけないので、まぁ、やることの内容は同じことです。

で、今、私たちの立場は、容疑者なので、自分たちが犯人であることを確認するか、それとも自分たちの範囲でない、つまり原因でないことをログとかメッセージとか客観的な事実で証明しなければなりません。

火の粉が降りかからないようにロジックを組み立てる
“一次切り分け”の結果、自分たちが犯人であった場合、暫定対処と本格対処など、そのトラブルのインパクトに応じたスピードの対応が求められるものです。それは、もう、その事象が不具合なのであれば、それを除去して正常に動作するように対処する他ないので、シンプルと言えばシンプルですが。

まぁ、そのあと、根本原因の究明とか再発防止策とか後続するタスクが山盛りになるのは目に見えていますけれどね。

でね、自分の担当するシステムが犯人でないときも、防止策を求められることもあります。フェールセーフの考え方に近いかもしれません。トラブルに巻き込まれないように、何か予兆を監視しておこう、的な。でも、それってとっても壮大な対処になったり、ヘビーな監視になったりしがちで現実的でないこともしばしばです。

そうした場合、それをやるのはコストもやるメリットも見込めないならやらない方向で話を持って行って、それを相手に選ばせないといけないです。あくまでも最終選択権は相手に渡しておくとしても、やらない選択肢を選ばせることは、そうした意志とロジックを持っていれば難しくはないです。

ざっくり概念を単位とした括りで案のメリットデメリットを作り、どれをやってもメリットがないことや、実現するには無理難題があるとするのです。あくまでも、「全体感で考えました。でも環境の制約やシステムの制限でできることはこれだけで、それを実現するならいまのシステムにこんな影響があるみたいです。」で、どれを選んでも現実的でないし、それを実現するには他のシステムに多大に影響します。みたいに。

やらないといけないコトはやりましょう。さっさとね。でも、誰にもメリットがなくて、コストが無駄になるならやらない方向に持っていきましょう。