バグ票も書けないのに一人前のエンジニアと思ってはいけない

on


バグ票といってもかっちりした報告書でなくてメールでフリーフォーマットで書いてもらってもいいんだけれどね。いいんだけれど、書かないといけないコンテンツって、決まりきっていますよね。え？わからないの？バグ票じゃなくてトラブル報告だっていいのだけれど。


なんでバグ票書くの
バグ票を書く時点では、そのインシデントはバグなのか、仕様なのか、パッケージなのか、自責なのか、他責なのか何も決まっていないです。そのインシデントに対する自覚というか確信があるなら別ですけど。


だから、発現したインシデントの事実を書いて、それを解決しなければならないのかどうか情報を収集するめどを付けるまで書く必要があるわけです。


そのインシデントは仕様どおりかもしれないし、ほんとに自責のバグかもしれない。それをまず切り分けるための情報を集めて、判断しましょって。で、そのインシデントは修正しないといけないならだれがどう直すのよ、って。で、また、直し方によっては、インタフェースを持つ他システムに影響するかもしれないから、こんな風にするつもりだよ、って公知する手段でもあるんですよ。


バグ票に書かれるコンテンツ

  • 誰が、
  • いつ、
  • 何をしようとして、
  • 何が起きたか、
  • このあとどうするか

それだけ書けばいいのです。書き手であるあなたの“思い”を含めてはいけません。あくまでも、事実のみ、記録するのです。

誰が、は、その操作をするロールです。利用者としての操作なのか、管理者としての操作なのか。ロールは大事なのです。


何時は実施日時です。インシデントのポイントごとに時系列に記録しておくものです。この日時を記録することの大切さを全く知らないエンジニアが多いです。トラブルになって問題になるのは初動です。初動に費やす時間とアクションを間違えるから些細なことでも顧客の地雷を踏んだりするのです。ポイント、ポイントで日時を記録するものだ、と思いましょう。


何をしようとして、は、操作のシナリオです。どんな操作をしようとして何を得ようとしていたのか。これは大事なことです。これを得る、という結果の期待があったからこそ、インシデントとの差異があってトラブルだ、と言えるわけです。その前提が、何をしようとして、です。


何が起きたか、は、インシデントそのものです。期待する結果が得られない、そのものです。計算結果、帳票、メッセージ、画面、ログにその事実は記録されます。それのどこが期待と違うのか、想定と起きた事象とを並べるのです。


このあとどうするか、は、じゃ、起きたインシデントをわかる範疇で問題解析するとか、パッケージのサポートを受けるとか、インフラに聞いてみるとか、そういったもんです。つまり、あなた次何するつもりなの？ってことです。


2-3行に要約する力を付けている？
そうした事実をテーマごとに書く冒頭に、それらの事実を概要としてのまとめる力が必要です。バグ票を掛けないエンジニアは、その事実さえ羅列できないのだけれど、そこまでたどり着いたとしても、要約する力がなくて、何が起きたか読んでもズッコケちゃうことも少なくないんですよ。


要約するところで初めて事実に基づいて書き手のバイアスを掛けられると思うのです。あまりにもインシデントとしてレベルが低いものは、あっさりと対応したいことだってあるわけで。単体試験レベルのバグが総合試験で出すわけにはいかないのですよ。でも出てしまったときに、直すんだけどサラッとやりたい。


そうしたときに要約する力を持っていれば方向にバイアスを掛けられるんです。気付かれなければ、ですが。


で、パっとまとめられますか
事実を調べるのは指示された若いエンジニアだってできるものです。だって、どこ調べてとか、どこそこのログ取ってきて、とか具体的に指示されるんだもの。


集めたものはデータだけでしかなくて、それを理解できるように整理して初めて価値のある情報になるわけで。


バグ票を書けないのは、エンジニアとして致命的です。事実を押さえられないって言っているようなものだもの。事実を並べて、仮説を描けないと言っているようなものだもの。自ら課題を設定して、課題解決できないと言っているようなものだもの。


まぁ、書かないことに越したことはないんですけどね。