品質特性とバグの聞こえる化

午前中に見つかったクリティカルな問題が、お昼休み前には原因が分かり一安心。

会話(問題が起きる前にどんなことをしていたか)とログでだいたいのことは分かるんだなあ。これって品質特性で言うところの「保守性(解析性)が高い」ということだよね?すばらしいなあ。

午後になって、対応してくれたプログラマSさんに「もう原因が分かっちゃったんですねー。早くてびっくりした。すごーい!」と言ったらSさん、

隣でmiwaさんがテストしながら「あ…」て言ったでしょう。気になって(コーディングする手を止めて)miwaさんの画面を見たらあれ(深刻な状態)ですからねー。その場でログとらせてもらってすぐに見れたからですよ!

なんだかわたしまでほめられた気分。うれしいな。

 

今回のケースは”テスターが問題を検出してからプログラマに伝わるまでの時間”がゼロでした。世の中にはこんなメトリクスがあるのかどうかわからないけど、とにかくコードは日々変化してしまうので、この時間は短ければ短いほどいい。多分みんなそう思ってるはずです。

 

ところで、わたしはほぼ毎日プログラマの隣でテストしているのだけど、あれ?おかしいな?と思った時、真剣にコードをかいてるプログラマに話しかけるのは、少々気が引けてしまうのですよね。

朝会で今日対応してるチケットがどれとかだいたい把握してるので、今まさに重要で繊細なところを直してるのかもしれない、ここで声をかけたら思考を妨げちゃうかも…と思うわけ。

 

さっき検出した問題がプログラマに伝わるまでの時間は短ければ短いほどいいと書いたけど、そうなの。アタマでは良いと分かってはいても、なかなか行動に移せないことって、ある。(それはわたし自身の内面的な問題で他人にはどうでもいいような些細なことだったりするのだけど…)

そんなこと、ありませんか?

 

だからそんな時は問題の大きさによって「ん?」とか「あれ?」とか「あわわわ」とか声に出してみようと思います。これなら気が引けないね。だって独り言だもん。

うまくいけば周りのプログラマたちがシグナルを受信して、わたしのモニタを覗きこんでくれるはずだ。

誰も気がついてくれないときは、いつも通りチケットを発行しますね。