KonifarPod

エンジニアは魔法使いじゃない!「なんか変です!直してください!」⇒ 「え・・・?」

      2013/03/18

Pocket

「なんか動きません!」「表示が変です!」

システムを運用していると、トラブルはつきものです。ユーザーが多いほど緊張感いっぱいで、『障害』という言葉はエンジニアにとって心臓に悪い言葉です。当然エンジニアも全力で対応するわけですが、ぶっちゃけこの伝え方どうなの?と感じる報告をしてくる人も結構います。

具体的に言うと「なんか変です!直してください!」とか言われると「え・・・?」となります。ちょっと気が短い人だと「は?」となるかもしれません。もちろんお互い言い分はあるでしょうが、僕は、ちょっとお互いのことを理解するだけでこの辺のわだかまりはぐっと改善されると思っています。僕はエンジニアなので、エンジニアから見た視点で考えをまとめてみたいと思います。

 

1.知りたいのは想定と事実

エンジニアにとって、「なんか変です!」という報告には何の情報もありません。「で、変ってどういうこと?」というのが重要です。変というからには、変じゃない状態があるはずです。それは報告者が考えるあるべき状態にすぎないかもしれません。それでもいいんです。まずは想定結果と現状の事実を知りたいのです。

少し具体例をあげましょう。僕が実際に経験したことです。1ヶ月分のある時間数の計算を行うシステムがありました。その結果がなんだか想定と違ったようで、コンサルから僕のところに報告が来ました。

コンサル「なんか計算結果が変なんです!今日中に直してください!」

・・・これはもう突っ込みどころが多すぎてまず質問を返すことしかできませんでした。

質問1)結果が変って、どの日のどの値が変なんですか?

それがわからない限り調査すらできません。どんな問題もまずは調査から始まります。最低限の情報は渡してほしいです。ここで言うと、どこがおかしいのかという情報です。もっと言えば「3日がおかしい、4日は同じ条件だけどちゃんと計算されている」みたいな切り分けがされているとなおよしです!

質問2)本当はどんな値になってほしいんですか?

変じゃない状態ってどんなんですかね?相違点がわからないと調査できません。正解のないクイズを解けと言われているようなもんです。

質問3)直すも何も、まだ問題かどうかもわからないですよね?

そもそも想定結果自体が間違っていて、実は正しいってことも往々にしてあります。何気にめちゃくちゃ多いです。「これ変です!」と言われたけど、実は設定が違うだけで仕様通りの正しい値だったりするわけです。つまりはただの勘違いってオチですね。一番萎えるパターンです。なので、最初から「直してください!」とか「解決して!」とか言われると「あーちょっと待って」ってなります。

質問4)問題だったとして、今日どういう状態になれば解決ですか?

例えばバグだったとして、今日中の解決ってどういうことなんでしょうか。バグだったら直すしかない、と思われがちですが、逆に直す方がリスクある場合もあるんですよね。そういう時には、暫定的に設定で回避したり応急処置する方がいいかもしれません。新しい機能でバグったのであれば、一時的にリリース前の状態に戻すという方法もありますよね。しかしそれだとユーザーが納得しないかもしれません。まずはどんな状態になれば解決なのかをハッキリさせた上で、色々なトレードオフを考える必要があるのです。

 

これらの質問をしてみたところ、変だと言われていた部分は実は仕様どおりでした。つまり設定のミスだったんですね。設定を一カ所変えるだけで一瞬で解決しました。「変です!直してください!」という報告は全て間違っていたわけです。ただの感想にすぎないものでした。感想はいらないので、想定結果と事実が欲しいのです。そうすれば、エンジニアもぐっと速く解決できます。

 

2.エンジニアは魔法使いじゃない!

このような食い違いが起こるのは、エンジニアがどう障害対応をしているか知られていないからだと考えています。「なんか変です!直してください!」と言ったら「ちちんぷいぷい!」って感じでぱぱっと直しているみたいに思われているのではないでしょうか。そこまで極端ではないかもしれませんが、『エンジニアは経験とか知識で問題のあたりをつけて、ピンポイントに直している』と思われているんじゃ・・・と感じることは多々あります。僕の思い違いですかね?まあ当然ですが、そんな神通力ないです。

エンジニアがやっているのは、事実に基づいた切り分けの繰り返しです。その事実の質をあげるために、ログを出したり再現を試みたり色んな工夫をしています。実はめっちゃ泥臭いことをやってる場合も多いです。例えば、スマートフォンで見たときだけ画面がおかしい、という場合は、スマートフォンとPCの実装部分の違いを見比べたりします。

医者の診察と似ているかもしれません。いつからどんな症状が出ているか、熱があるか痰があるか下痢はどうか、などなど、色んな客観情報から病気を特定して薬を処方しますよね。エンジニアも同じです。丁寧に集めた事実から検証して問題の最小範囲を切り分けて、原因を特定した上で対処方法を検討するのです。

魔法使いみたいに見えるとしたら、問題の切り分けと解決方法の検討のプロセスがめちゃくちゃ速いだけです。

 

3.お互いのことをもっと知ることが大事

とは言え、エンジニアのやってることなんてよくわかりませんよね。そりゃそうです。僕も新卒で先輩を見た時は魔法使いにしか見えませんでした。しかし自分が同じ立場に立ってみると、全然そんなことないことがよくわかりました。

非エンジニアは「なんかすげー細かいとこまで言わないとわかってくれないわー」と感じているかもしれません。一方エンジニアは「あいつら全然わかってないわー。切り分け下手だわー」みたいな感じになってるかもしれません。このすれ違いはかなり勿体ないです。エンジニアも非エンジニアも、お互いのやっていることをちょっと教えてあげるだけでだいぶ良くなるのではないでしょうか。

例えば、障害対応の時に1時間くらいエンジニアに張り付いて観察してみると、それだけでも色々わかることは多いと思います。エンジニアも「こういう風に報告してくれ」とちゃんと伝えてあげるようにするだけで次からはぐっとやりやすくなると思います。最初はめんどくさいかもしれないですが、ちょっと歩み寄るだけで今後楽になるのであればお得じゃないですかね。

 

エンジニアは魔法使いではないということ、何となく理解していただけたでしょうか。そのあたりのことを認識した上で、最速の解決を目指すために『想定結果と事実』をちゃんと伝えてみましょう!エンジニアは『想定結果と事実』をちゃんと切り分けて伝えてくれる人が好きなので、それだけで優しく協力的になってくれると思います、たぶん。きっとより強いチームワークで気持ちよく対応できるようになるはずですので、少し意識してみるといいかもしれません。

Pocket

 - Develop, 仕事