どうも。ご無沙汰してます。ようやく地獄のリリース直前期を乗り越え、地獄の保守フェーズにそのまま突入・・・することはなく、無事追加開発側の体制に組み込まれることになった。よって、徐々に生活も通常通り、少なくとも精神崩壊するほどの労働環境からは解放された。少しずつブログエントリペースも戻していければ、と。
そんなわけで、今は追加開発をしているのだが、既に設計・製造工程は終わっていて、テストが始まっているという状況。インフラエンジニアとしては試験の中で発生した環境バグの改修とかを担当するのだけれど、どうも故障改修の依頼がなっていない人が多くて。
「◯◯処理が正常に行かないので、◯◯サーバから◯◯サーバの通信を開けて下さい。試験進捗に影響があるので至急対応をお願いいたします。」
みたいな依頼内容。自分の都合だけは押し付け、こちらの都合は何も考えていない、といった感じ。
たぶん”あるある”なのだろうと思うんですが、SI系の会社だと業務系と基盤系が体制として完全に分離していて、業務SEは基盤のことを何も把握していないケースが多く、このように雑な依頼が散見されるのだ。
で、基盤で解析をしてみると、実は基盤としての通信要件は満たせているけれど、AP基盤レイヤとか別のAPのバグに起因していたりすることもよくある話で。他にも「そんな要件依頼されてるっけ？」みたいなこともあり。インフラ屋からすれば「ふざけんなよ！」と思うわけ。
で、こういう依頼をする人って結論から言うと「1次切り分け」ができない人。特にベンダをコントロールする立場にある会社の新人とかはこうなりがちだ（私も1,2年目の頃はそうだった）。
細かい仕様まではよくわかんないし、ベンダさんが故障だって言ってるからとりあえず別Gに依頼してみよう、みたいな。でも「相手がどんな情報が必要なのか」を想像できていない、あるいは理解していないので、その依頼だと仕事が思うように進めてもらえなかったり、強気な人だとこんな指示では対応できません、みたいに突っぱねられることもあるはず。
もちろん、故障解析チームの体制が「1次切り分け」と「根本的な解析」に分かれている組織もあるけれど、そんなに多くはない。となると、基本的に人を動かす立場の人がある程度の1次切り分けができなければいけない。
1次切り分けができないと、最悪なことしかない。
１つ目は先に述べたように解析の進め方が非効率になる。本当の問題の原因とは全く関係ないところを調査する、あるいはさせてしまう可能性があるからだ。なぜかというと、全ての問題の原因は階層構造で表現できるからだ。
故障が起きる可能性はA〜Cの３つの可能性があって、もしAが起こっている場合はそれらを引き起こす原因A-1〜A-3のどれかに問題がある可能性がある、という構造に必ずなっている。もう一度言うが、全ての問題は必ず階層構造で表現ができる。これを念頭においておこう。
上記の図であれば、一次切り分けとは、「原因がAなのかBなのかCなのかを明らかにする」までを指す。実際のケースでは、AなのかBなのかCというのはチームの単位を指すことが多い。どのチームに解析を依頼すれば良いかが分からなければ、依頼ができないから。
しかし、一次切り分けができない人はいきなり、「なんとなくC-3が怪しいな・・・」みたいな感じで解析を進めようとするから他チームと衝突するし、仕事がスムーズに進みにくくなる。また、C-3ではなかった場合に、C-3が原因ではない、という情報しか得られないのも非効率だ。
2つ目は、対処が不十分になる可能性がある、ということだ。当然、故障の原因解析をするのはバグを改修するためである。ただし、正しい解析ステップを踏まなかった場合、全ての問題の原因を発見できていないリスクがある。
つまり、問題A-1だ、と決めつけて、事実そこに問題はあったけれど、実はC-2にも問題があった、と言うケースだ。当然、A,B,C全ての問題を取り除かなければ、故障という事象は解消されない。改修したけど、またやり直し、二度手間になる。
では、どうすれば一次切り分けができるようになるのか。それについてお伝えしていく。ポイントは３つ。
①MECEで原因の階層構造を想像する
②切り分けの方法を考える
③関連する処理と責任を持つチームを把握する
①について。全ての原因は階層構造で表現できる。その構造を想像する、仮説を立てる。その際にMECEは抜群に使える。故障に限らず、普段から何かを考えるときはまずMECEに分解して考える癖をつけておくと良い。
MECEというとすごく複雑な構造分解をイメージする人もいるかもしれないが、「まず２つに分けられないか」を考えると良い。例えば、故障の場合なら、自チームの問題なのか他チームの問題なのか、に分ける。さらに他チームの中で分解していく、という風に考えていくと以外と進められるし、一部分解した構造セットは経験の中で蓄積されていく。
②について。分解ができたら、それらを切り分ける方法を考える。先ほどの例では自分たちの問題ではないことを証明するにはどうするのかを考える。システム開発だとログを見たり、場合によってはデバッグログを仕込んだりする。
さらに誰の責任範囲でエラーが発生しているのかを突き止める。プログラムの構造上、処理Aから処理Bが呼び出され、処理Bから処理Cが呼び出される、みたいなことはよくあるが、処理Bの中で問題が発生していることがわかれば、処理Bか処理Cのどちらに問題があるのかは処理Bの担当者に切り分けてもらう。こうして段階的に原因を特定していくのがセオリーだ。
そして、最後の③が一番重要。ようは自分と直接的に関わる関係者や責任範囲はせめてちゃんと把握してくことだ。これがなければ、①も②も到底できない。自分たちは悪くない、でも誰に聞けばよいのかわからない、みたいな状況になると、ローラー作戦ばりに色んな人に解析依頼をすることになって非効率。
ちゃんと自分たちの作っているもの、他チームが作っているものがどのように関連して全体が作られているのかを把握しておこう。逆に言うと、ここをきっちりおさえていれば、切り分けの半分はできていると言ってもいい。
