これまでわたしはいくつかのチームを転々とし、ウォーターフォール型や反復型のような開発の現場にいたり、独立したテストチームに所属し、外側から開発チームを見ていたこともあった。いまはアジャイル開発をしてるチームでテスターをしている。
そこで分かったのは、開発手法や所属するチームに違いはあれど、思ったことを何でも言えたり、起きてしまった問題を個人ではなく、全体の問題として捉えることができるチームの雰囲気が、わたし自身のアウトプットに大きな影響を与えるのだなー、ということ。
そう、開発手法なんて全然関係なかった！
わたしの日常
毎日少しずつモノができていく過程でテストしていくから、（あれ？おかしいな？）と思うことが、次のイテレーションでの開発アイテムになってる、ことはよくある。
それが明らかな場合（知っている場合）は、インシデントとしての報告はしないし、そこは実装してから改めてテストしよう、ということになる。
それが明らかでない場合は、その機能を担当しているプログラマに期待したことを話し、これから開発するアイテムなのか聞いてみる。その結果「ああ、それは考慮不足でバグでした」というのであれば安心する。
また、わたしの勘違いでその動作は正しい場合（＝仕様）もある。そのようなときは、新たな気持ちでテストをし直して、その結果をプログラマに話したりする。
そうではなくて、その仕様についてはまだ考えられていないとか、ちょっと前に話題になったけど、そういえばうやむやになっていますね、というケースもある。ほら、嫌なことが起きる前兆のような ザワザワ とした音が聞こえるでしょう。
こういった音にならない音や、いつもと違った匂いをできるだけ早く感じて、表舞台に出してあげるのもテスターの役目だと思っている。そして、わたしの日常では、そういった気づきを話すことが、推奨されているように感じる。
「誤報」になるとどうなるか
さて、わたしの報告が、実は仕様だった場合や、今後のイテレーションで開発されるアイテムだった場合に、それが気づきではなく報告のミス＝「誤報」であると認識されてしまうと、わたしのアウトプットは量も質も一気に落ちてしまう。
この時点で、嫌なことが起きる前兆のような ザワザワ とした音はもう聞こえなくなり、「誤報ではない何か」がタイムリーとは程遠いタイミングで報告される。
「ミス」には寛容に
ミスをしない人はいない。プログラマだってミスをするのだから、テスターだってミスしてもよい。ミスをしないことより、できるだけ早いうちにミスを見つけて、訂正できることが肝心である。（ミスをしなさいと言うことではありません）
何度も同じような「ミス」を繰り返してしまうような場合は、個人の問題（注意散漫なヤツだ！）と決めつけるのではなく、例えば、
- それはユーザにとっても分かりづらい仕様ではないのか？
- ミスを誘うようなテストケースの書き方になっていないか？
- 正しいテスト環境が作りづらいのではないか？
といったように、開発全体の問題として捉え、みんなで考えられるとよい。
なんで急にこんなことを書きはじまったのか分からないのだけど、そういえば今日は TPI NEXT（ビジネス主導のテストプロセス改善の本）を読んでいたんだっけ。
第4章 キーエリア
- 「利害関係者のコミットメント」
- 「関与の度合い」
- 「報告」
第7章 さまざまな状況へのBDTPIモデルの適用
- 「反復開発手法への適用」
- 「アジャイル開発手法への適用」
このあたりを読んでいて、過去に経験してきたいろんな開発やテストを思い出して、お話ししたくなったみたい。
この本は、先月開催されたソフトウェア品質シンポジウム 2015で、友人というか同僚に買ってきてもらったもので、翻訳者の湯本さんと皆川さんのサイン付きプレミアム本なのだけど、いつか薮田さんのサインももらいたいな。
