テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。
登場人物
プロ之 … プログラマー
テス緒 … テスター
前回、テス緒さんは現象を再現しようといろいろなテストケースを試しました。その話を聞いたプロ之さんは、テスト自動化の方法を教えつつ、テストについてもっと学びたいと伝えました。新たな手段を手に入れたテス緒さんですが、リーダーとの雑談でそれはよくないと言われてしまいました。
テストは全体のために
この会社では、チームのリーダーとメンバーは雑談のような1on1のような、気楽な会話の時間が定着しています。報告や指導というよりも、相談事だったり気になることをお互いに話したり、趣味の話やほんとうの雑談で終わることもよくあります。定期的にやっている人たちもいるし、不定期にときどき話す人もいます。
今回はテストチームのリーダーがテス緒さんに声をかけて、雑談をすることになりました。
「テス緒さん、おつかれさま。最近どう？ 忙しいですか？」
「そうでもないですよー。むしろ余裕あるんで、前に気になったイシューの件を調べてます」
それを聞いたチームリーダーはちょっと黙り、表情は柔らかいままでしたが目が少し鋭くなりました。「そうだったんですか。それはちょっとよくないですね」
テス緒さんは驚いて、あわてて口を開きました。「あ、でもアサインされた機能のテストは遅れなくできてますし、残業もほとんどしてないですよ。開発チームにも迷惑かけてないと思います」
チームリーダーはテス緒さんの話を最後まで聞いた上で、ゆっくりうなずいてから言いました。「テス緒さんはアサインはこなしています。その点は大丈夫です。ただし、29分とか58分とかに業務終了するのは、ほとんど30分余計に作業してるのと同じですからね※1。お昼休みだって作業してるでしょう」
「えっ、それもわかるんですか」
チームリーダーは声を出して笑いました。「わからないですよ、監視してたりはしません。でもそうじゃないかなと思ったんです。テス緒さん熱心ですからね」
リーダーは続けました。「テス緒さんが、自分が見つけた違和感を粘り強く調べるのは素晴らしいと思います。テスターにはそうあってほしいんです。ただ、テストチーム全体や、プロダクト全体から見たとき、いまテス緒さんがそこに集中するのがベストなのか、そういう視点も持ってほしいんですよ。アサインした機能は、最近どうですか？」
そう言われてテス緒さんは思い出しました。ひとつの機能全体をアサインされたとき、ここをよく理解するとサービスの全体が見えやすくなるから、ただテストするだけでなく機能の有り様を深く把握してほしいと言われていたのでした。
「たしかに、あんまり調べてないです」テス緒さんはだんだんしょんぼりしてきました。
ここまで、テス緒さんとテストチームリーダーの会話の様子を見てきました。チームリーダーはテス緒さんの行動に反対しているわけではないようです。いっぽうで、いまは機能とサービス全体を学ぶことに集中してほしいという期待があります。また、ここで話題には上がっていませんが、プロダクトのリリースのタイミングなどではテストを速やかに、確実に進めるため全員が集中することもあるでしょう。
そう考えると、テス緒さんはプロ之さんを通じて開発チームとの関係性を築いてきましたが、それに加えてテストチームの中にいるテスターとしてどう振るまい、どう判断するといいのか、新たに学ばないといけないようです。チーム全体にとって大事なことは何か考えたり、それをチームに伝えたりすることです。
ポイント:
- テスターは自分が感じた違和感を大事にして粘り強く探索する
- プロダクト全体のため、テストチーム全体のため、やるべきことを考える
※1 この組織ではプロジェクトの作業時間を30分単位で計算し、30分未満の端数を切り捨てています。そのため、たとえば18:29に業務終了すると、このプロジェクトの業務は18:00で終了したことになります。テストチームリーダーはこのデータに気がついて、テス緒さんが働き過ぎになっていないか心配しています。なおこの時間計算は原価計算のためのもので、勤務時間や残業時間には別の仕組みがあります。
大事なことを大事だと説明するのは大変だ
テス緒さんが大人しくなってしまったのを見て、リーダーは最後に、はげますように言いました。「言われたままにやるのがいいわけじゃないんですよ。大事なことだと思うなら、突き詰めてください。でもチームのことを考えず勝手に進めるのはよくないですね。チーム全体にとってよいことなら、チームに共有してください。どうですか、いま調べているのは、チーム全体にとって大事ですか？」
テス緒さんはこの質問に答えられず、雑談は他の話題に移っていきました。
「(大事か…大事なんだけど…チーム全体にとって大事ってなんだろう？)」テス緒さんがこう考えていると、プロ之さんから連絡がありました。
「多少、困ったことになりました」プロ之さんはこう切り出しました。聞いてみると、プロ之さんも開発チームリーダーと話をして、開発と関係ないことをやっていると叱られたそうです。テス緒さんも、リーダーと話した内容を伝えました。そして2人で、大事とはどういうことなのか話し合いました。
- サービスが停止したり、ユーザーに損害が出たりするような問題は大事だし、その対応作業は大事だ
- 新機能の追加やユーザー体験の向上は大事だから、そのための仕事も大事
- 開発でもテストでも、学習や調査を大事にしている
- 影響が小さな問題や、ユーザーにほとんど関係ない問題は、大事ではない？
- 小さな問題でも、たくさんあったり、長期間残っているとユーザーに悪影響や悪印象を与えるので、量や時間によっては大事になるのでは
- つまり大事かどうかは、他のものとの比較だ。手が空いているときなら、あまり大事ではなくても、他にやるべきことがなければ着手できる
- すぐ安全に直せる問題は、開発チームが片手間で直したりもしている。つまり、対処に必要な時間やコストが小さいなら比較的大事だということになる
テス緒さんが驚いて言いました。「えー、勝手に直されるとテストチームは困るんだよ。知らないうちに変わってると、障害なのか修正なのかわからなくて」
「そんなに大声出さなくても聞こえますよ。細かい変更点も、テストチームにはまとめて連絡しています。そう思いますけど…」プロ之さんは反論しましたが、少し自信がなさそうでした。
「そっか、ならいいけど。でも、いろいろ話したけど、これじゃあ今調べてる問題は大事だとは言えなさそうだね」
プロ之さんは少し考えて、言いました。「今の問題は、原因がわからないですよね。だからもしかしたら、実は重大な問題が隠れているのかもしれません。わからないですが、わからないのは不安です。開発チームには、不安があったらテストを書くというガイドラインがあります※2。テス緒さんがテストをたくさんしてくれましたが、まだ不安が残っています」
「不安だから、大事ということ？」
「不安な気持ちを大事にしようと開発チームでは言っています。テストチームの大事さとは、すこし違いそうですけれど」そこから2人はもう少し話し合いました。
- 不安は大事だ。なぜなら、隠れた問題を見つけるきっかけになるかもしれないから
- 隠れた問題に早く対処できれば、将来の大きな問題を未然に防げるかもしれない。これはきっと大事だ
- テストチームでは違和感を大事にしている。重大な障害につながる本当に危ない問題は、一見しただけではわからない(わかるものはすでに対応している)
- 不安や違和感は、問題があるかもしれないという、可能性の話だ。これをリスクと言い換えると伝えやすそうだ
- つまり結論として、いま調べている問題にはリスクがあるので、大事な問題だ。どんなリスクかというと…
「どんなリスクかというと…不安だから」テス緒さんが、自分でも不安そうに言いました。
「どんな不安かというと、具体的には言えず、漠然とした不安です」プロ之さんは力強く断言しました。
「説得力ないなあ」「ないですね」2人はため息をつきました。
プロ之さんが聞きました。「この問題が、実はユーザーに影響を与えているという可能性はないですか？ あくまで可能性として。仮説でもいいです」
「時間合計の表示が間違っていたら、困るユーザーもいると思う。合計を合計したら1日にならなくて、調べるとか。時間合計に合わせて、報告をしているとか。あっ！ もし勤務時間だったら、59分が1時間になったり、その逆だったりしたら大変！」テス緒さんは自分が、働き過ぎにならないよう時間ギリギリに業務終了することがあるのを思い出しました。2人はこの仮説をリーダーにぶつけてみることにしました。
「開発チームにとっては、問題はないのかな？」テス緒さんがプロ之さんに聞きました。
「最初に調べた範囲では、おかしなコードは見つかりませんでした。だからまだ見つけられていないところに潜在的なバグがある可能性があります。合計時間の計算ロジックはフロントとAPIにそれぞれありますが、どちらもテストがあるので同じ結果になるはずです。テス緒さんのテストケースを追加すれば、もっと確実になります。ということは、どこかに違う計算ロジックがあって、正しくメンテナンスされていないかもしれません。これを見つけて確認するまでは、かなり不安です」
「不安があったらなんとかするのが開発チームの鉄則なんだよね？」
「鉄則ではなくてガイドラインです。それに、なんとかするのではなくテストを書くです。ですが、この話をすれば開発チーム内でもプライオリティを上げてもらえるかもしれません」このことも2人で話し合い、開発チームのリーダーに聞いてみることにしました。
今回のお話は、ここまでになります。テス緒さんもプロ之さんも、それぞれのリーダーから指摘を受け、不安を抱えて話し合いを始めましたが、いまは自信を持って次のアクションに進めそうです。2人の情熱と作戦は、リーダーたちに通用するのでしょうか。
ポイント:
- 大事だと判断するには、ユーザーへのいい影響と悪い影響を考え、また時間の要素も考える必要がある
- また、不安やリスクという不確実な要素も、大事かどうか判断する材料になる
本連載の次回では、いよいよ2人が問題の解明に迫ります。
※2 「不安をテストで表現する」とは、テスト駆動開発で有名な和田卓人さんの言葉です。
