開発チームに警告をするときはタイミングも大切だと思った話

テストとは，プロジェクトの行く手を照らすヘッドライトの役目なのだ。前方を明るく照らし，地図を挟んでにらみ合っているプログラマとマネージャに現在位置を示しながら，何か轢きそうな時は警告しつつ，崖に何メートルまで迫っているか教える役割なのである。

セム ケイナー,ジャームズ バック,ブレット ペティコード. ソフトウェアテスト293の鉄則 (Japanese Edition) (p.44). Kindle 版.

『ソフトウェアテスト293の鉄則』の鉄則1ではテストの役割についてこのように述べられています。こちらについて個人的には結構しっくりくるところではあるのですが、最近ここに付け加えて「警告をするタイミングが大切なのでは？」と思うことがあったので今回はそれを記事にしてみようと思います。

少しでも参考になれば幸いです。

私の体験談

基本的に私はQAの業務において色々なことを「早いに越したことはないだろう」と早め早めに動いて開発チームに警告を上げるように心がけているのですが、実際これは良かった点と良くなかった点の両方がありました。

良かった点：要件について早めに詰めることができた

私は要求が出た時点でどんな仕様になるかを想像したり、その中で考慮しなければならないユースケースを問題提起したりすることがよくあるのですが、これは結構喜ばれることが多いです。そのユースケースも込みで見積もりができるので、プロジェクトに悪い意味で響くこともありません。

良くなかった点：早すぎて内容を忘れられた

前項と同じようなことをするなかで、細かい実装の分岐について要件定義の時点で問題提起をしてみたこともありましたが、これはあまりうまくいきませんでした。問題が起こりうるということを念頭におきながら開発をしてもらえれば・・・と思っての警告ではあったのですが、実際のところこれは忘れられてしまうことが多かったです。

通知のタイミング

カーナビを例に取って考えてみると、左折右折する交差点の100m手前など「実際に何かアクションを取るタイミングの少し前」にアラートが来るものだと思います。早すぎても覚えていられないし、その道を過ぎてしまってから通知を出されても意味がありません。

似たようなことがQAからのお知らせにも言えそうな気がします。

私の体験談に立ち返ってみると、良かった点については「考慮しなければいけないユースケース」の情報がその時点の開発フェーズ（要件定義）にとって必要だったのでうまくいったのだと思います。

逆に、細かい処理の分岐の考慮点については、お知らせする最適なタイミングは「その処理を実際に書く直前」だったのでしょう。車の運転とは異なり、コードは特に書いた直後であればリカバリーは容易いので、正確には「その処理を実際に書く前後」となるでしょうか。

私のすべきだったことは、気になる点をどこかに書き留めておいて、その情報を然るべきタイミングで出すということだったのかもしれません。

終わりに

気になるところがあったらすぐお知らせしたくなってしまうこともあると思うのですが、情報をお伝えするときにはそのタイミングも考慮に入れることが大切なのではないかと思いました。

そのためには、現在開発チームが何に手をつけていて、どういう情報を求めているのかリアルタイムに把握することも必要になってきそうです。

ここまでお読みいただきありがとうございました。