Calendar for ソフトウェアテストの小ネタ | Advent Calendar 2021 - Qiita 12日目の記事です。
はじめに
アイヌ民族最後の狩人 姉崎 等（あねざき ひとし）さんを語り手として、編集、構成された書籍『クマにあったらどうするか』を、読んだことはありますか？
私は、クマを自分の師匠だと本気で思っています。なぜクマが師匠かというと、クマの足跡を見つけたときにクマを一生懸命追って歩く、そうやって追っていくうちに、山の歩き方やクマの行動などをすべて学んだからなのです。
こんな書き出しではじまり、姉崎さんの生い立ち、どうやってクマ撃ちになったのか、１２歳から６５年間、山に入ってクマを観察し続けた者にしか感じることのできないクマの生態や性質や習性、そこから導き出された知見や示唆に富んだ洞察が余すところなくインタビュー形式で収録されています。
「クマと遭遇したとき、人間は生き延びるために何をすればいいのか」
その問いに対する答えだけでなく、アイヌの教え、クマを知るということはどういうことか、人間がクマや自然と共生していくにはどうしたらよいか。それらに対する姉崎さんの考え方や向き合い方、心持ちにも触れることができます。多くのことが学べる、考えるきっかけを与えてくれる本です。
また「クマ」を「バグ」に置き換えて読むと、バグハンターとしての共通点を感じるでしょう。狩猟とソフトウェア開発。異業種ではありますが、その道のプロフェッショナルが語る言葉に耳をかたむけ、自分の仕事や日々の言動を見つめなおす ー そんな読み方、楽しみ方もできる本です。
とつぜん目の前にクマがあらわれたらどうするか。本書には姉崎さんおすすめの１０か条がまとめられていますが、この記事では製品開発中に『バグにあったらどうするか』をテーマに思うことを書いてみます。
わたしについて
医療機器（自社製品）を開発しています。eXtremeなチーム（咳チーム）*1に所属する開発者です。この記事をお読みのみなさんや、みなさんの大切な人の役に立つ製品を丁寧につくっていきたい。そんな思いで日々勤しんでおります。
バグにあったらどうするか
あなたがテスターならバグの原因を解明するための情報を集めるのではないでしょうか。バグ発生直後のスクリーンショットや各種ログファイルを収集しながら、PCの端っこに表示されているシステム時刻（バグ発生時刻）に目をやります。壁掛けの電波時計のような実世界の時刻がログ解析には役に立たないのを知っているからです。バグ発生時刻というのは、正しくは「自分がバグに気づいた時刻」です。問題はもっと前から起きていたのかもしれません。バグの現象と過去の経験からプロセッサ毎のCPU使用率やメモリ使用量といったリソース状況も確認します。
あなたは収集したものを共有フォルダに保存しながら、バグに気づく直前までに自分がやっていたことをできるだけ詳細に思い出そうとするでしょう。数秒前、数十秒前に操作していたことは短期記憶に保持されていますが、それも時間の経過とともに曖昧になっていきます。試験仕様書に記載のテストケースを忠実に実行するようなスクリプトテストではなく、テストの結果や手応えに応じて変容していくテスト（Testing、探索的テストをイメージしてください）は、どうしても手数が多くなり詳細に思い出すのがむずかしくなります。なるべく取りこぼさないように “やったこと” に加えて “なにを見たのか” “なぜその操作をしようと思ったのか” にも意識を向けて記憶しなおしていきます。
あなたは再構築した記憶を元に再現テストを試みます。すぐにバグは再現しました。ひとあんしんです。そしてこの手順（10ステップ）は冗長かもしれないと思いました。操作をすこしずつ省きながら最短手順を探します。その結果、6ステップで再現できるようになりました。最短手順を探す過程でパラメータを変えながら試したので、3ステップ目でパラメータSを選んだときだけバグが発生することもわかりました。
念のため、この現象が「そういう仕様ではない」こともドキュメントを読んで確認します。以前、報告したバグが調査の結果「そういう仕様」でプログラマーに迷惑をかけたのです。
そんなことをしていたら、すこし前の記憶がよみがえってきました。先週も似たようなところを触っていたはずなのに、このバグに気づかなかったな…。気になるので試験環境を先週の状態に戻して試します。バグは再現しませんでした。最近の変更で壊れてしまったようです。先週見つかるはずのバグを見逃したわけではなかったので、内心ほっとしました。これでバグを報告するための情報が揃いました。あなたはBTS*2のチケット登録ボタンを押しました。
チームが変われば価値観も変わる
あるテスターがバグにあってからチケットを登録するまでの様子を書いてみました。実は１０年くらい前にわたしが実際にやっていたことがベースになっています。ひとつひとつの行動に対してやる理由（やらない理由）があり、当時のわたしはこれが「良いふるまい」と思っていました。
現在の咳チームにJoinした直後、当然のようにそれまで信じて疑わなかった「良いふるまい」をしようとします。しかし１行目の「バグの原因を解明するための情報を集める」から嫌がられてしまいます。わたしは混乱しました。さらに追いうちをかけるように、これまでなら「良くないふるまい」だった行動を求めてきます。
それがバグかどうかはどうでもいいから、おかしいと思ったら何よりも先に誰かに言って！
これをやるには作業中のプログラマーたちの間にズカズカと割り込んでいかなければなりません。とても苦痛でした。
『郷に入っては郷に従え』ということわざがあります。物理的な居住地だけでなく職場やグループなど所属する組織や集団にもその考え方は当てはまり、チームが変われば開発のやり方も価値観もちがう。それはそうだろうと頭ではわかるのに気持ちが追いついていかない。身体が拒否してしまうんですね。咳チームにやっと順応できたかなと実感するまで３か月くらいかかりました。チームが大切にしていることや考え方が「ああ、こういうことなのか」と理解できたのもこの頃です。そのためには何を犠牲にするのかも明確でした。咳チームの価値観と期待される行動は見事に一致していました。
バグにあったらどうするか
咳チームのプログラマーやテスターがバグにあったらどうするか。その瞬間のふるまいやどのように考えるのか（思考の癖）を紹介します。バグの原因を調査して、設計を見直して、プログラムを修正するといった手順の話ではありません。あなたが山の中でクマにあったときのことを想像してみてください。クマにあってしまった原因を調査したり、レポートを書いたりしないでしょう。
毎日チームのみんなの言動をそばで見ていて「こうなんだよな」と感じるものを言語化しました。バグにあったときに（当たり前のことかもしれませんが）こんなふうに脊髄反射できるのが素晴らしいと思っています。*3
なお、ここで対象にするバグは明らかな不具合だけでなく、ちょっとしたおかしさや違和感のようなものも含みます。*4
あれはクマ！？
あなたはなにかに気づきました。
- 気のせいとは思わない（気配を大切にする）
- 「クマがいるような気配がするけど、気のせいかな？」(00:00.02)
- 「いやいるよ！」(00:00.21)
- 「いるつもりで！（行動しよう）」(00:00.72)
- あなたの感じたそれは気のせいではないです。なにかのメッセージです。
- 気のせいは揮発性なので忘れてしまいます。すぐに同僚に伝えましょう。
- 同僚と一緒に気のせいの正体を探りましょう。
- それともなに？ 気のせいにしたらクマはいなくなるの？
- 補足
- あなたの気のせいを真面目に受け止める同僚がいます。
- 同僚の気のせいを真面目に受け止めるあなたがいます。
- バグかどうかが完全にわかってから何かをするのではなく「バグがあったかも！バグがあるつもりで！（みんなで解こう）」
チーム（パーティ）で立ち向かう
- 何よりも先に同僚に伝える
- おかしいと思ったらすぐに同僚に伝えましょう。非同期ではなく、同期コミュニケーションで！(00.01.59)
- バグか仕様かテストの誤りかいろいろ気になるかもしれませんが、調べるのはちょっと我慢してください。
- おかしいと思った直後のシステムの状態をプログラマーに見せましょう。
- チケットを登録するのはプログラマーに見せてからにしてください。
- それを見るのに最適なプログラマーを集めましょう
- 騒ぎに気づいた同僚たちがあなたのまわりに集まってきます。
- どのような操作をしていたのか話しながら実演してみましょう。
- 深刻な問題（クラッシュするようなバグ）や、今日みんなが簡単に踏んでしまいそうな問題なら全員に知らせましょう。同じ問題を踏んでしまうのをなるべく避けるためです。システムを再起動する時間がもったいないので。
- テスターは「そこを通るテストは明日にしよう」と思うかもしれません。
- 騒ぎを知らずに同じ問題を踏んでも大丈夫です。まわりの同僚に伝えればさっきのあの問題だとすぐに教えてくれます。
- 補足
- 自分の作業より誰かからの割り込みが最優先です。
- みんなは問題（おかしさを含む）を１秒でも早く知りたがっています。
- みんなは問題（おかしさを含む）に興味があります。
- 問題が起きたのに伝わらなければ、問題が起きてないのと同じです。
最悪の事態を考えるんだ！
- 検出された意味を考える
- なぜそれが検出されたのかに興味を持ちます。(00:04.97)
- バグかどうかはどうでもいいのです。
- 同僚はなにを思ってそんなことをしたのか想像します。きっと同僚は話してくれますが、あなたはもう想像しています。
- 仕様がわかりづらいのかもしれません。だとしたら当然、お客さまもわかりづらいと思うにちがいありません。
- 前からそういう仕様だったとしても、今もそれでよいかどうかはわかりません。
- 「前からそういう仕様だった」ではなく、その仕様がどんなに素晴らしいのかについて話しましょう。
- 操作ミスはメッセージです。操作ミスを誘うような作りになっているのです。
- 勘違いもメッセージです。同僚がなぜ勘違いをしたのかを考えましょう。
- テストケースになにか問題があったのかもしれません。
- 仕様が陳腐化してテストを更新する時がきたのかもしれません。
- 一番嫌なことを想像する
- 報告した現象、報告された現象にとらわれないようにしましょう。
- 見かけの現象ではなく、その動作の原因（仕組み）から最悪なことを想像します。(00:05.64)
- お客さまの健康や生命が脅かされるくらいならクラッシュしたほうがよいときもあります。
- 起きてほしくないことは起きます。
- 嫌なことは重なります。
- 起きないことを祈るのではなく、それがなぜ起きないのかを理詰めで解きましょう。
- 「動作は問題ありません。単に表示の問題です」本当にそうかな？
- 軽微に見えるバグを軽視しがちなのを自覚しています。
- 軽微に見えるバグでも見方を変えれば重大な問題になります。
- 軽微かどうかは見かけの現象でなく、その原因とそこから想像される一番嫌なことで決まります。
- 補足
- 咳チームでは、不具合の仕組みがわかるまで調べ、そこから直すかどうかを決めます。基本的にバグはすべて直します。
繰り返しますが、ここに書いたのは「咳チームのプログラマーやテスターがバグにあったらどうするか。その瞬間のふるまいやどのように考えるのか（思考の癖）」です。こんな思考癖のあるチーム（プログラマー集団）を見たことがなかったので、えらく感動したのを覚えています。
咳チームが大切にしてることや考え方
先ほど「咳チームの価値観と期待される行動は見事に一致していました」と書きました。価値観とはチームに漂う暗黙知のようなもので、言葉にするのが非常にむずかしいのですが、咳チームが大切にしてることや考え方はこのようなものだと思っています。
- 昨日よりも良い製品にしたいから
- 問題や課題をできるだけ早く見つけたい
- 問題や課題をできるだけ早く知りたい
- 問題や課題をできるだけ早く直したい
- システム全体で結合した状態でできるだけ早く試したい
- システム全体で結合した状態でできるだけたくさん試したい
- 問題や課題はメンバーではなくチームにある
- 無理をしない
- わたしたちは間違える
とてもシンプル！
おわりに
製品開発中に『バグにあったらどうするか』をテーマに思うことを書いてみました。アドベントカレンダーに登録したとき（１か月くらい前）は、もうすこしテストっぽい話を書くつもりだったのに、気づいたらいつものように咳チーム自慢になってしまいました。プログラマーもテスターもプロの無職もみんな素晴らしいので仕方ない。
わたしが咳チームにJoinした頃の話、チームが変われば開発のやり方や価値観が変わるというのは「まあそうだよね」と思うのに、それを受け入れるには苦痛がともない、順応するまでに時間がかかったエピソードをお伝えしました。
それから、１０年くらい前に「良いふるまいである」と信じて疑わなかったものが、果たして本当にそうだったのか、いまでは疑問に思っていることもお伝えしておきます。きちんとやっている実感もあったんですよね。*5 だからなおさらこわいですし「いまだって…もしかしたら…」と思う気持ちもどこかにはあります。わたしたちは間違えるからね。*6
バグにあったらどうするか。ひとりひとりがどうふるまうのか。それはチームの価値観が反映された結果の行動でしょうし、ひとりひとりのある瞬間の些細なふるまいがチームの価値観を醸成しているとも言えます。
みなさんはバグにあったらどうしますか？
おまけ
本記事を執筆中に食べていたお菓子です。美味しい！
*1:世界一長生きのXPチーム。@m_seki がプロの無職をロールプレイしている。
*2:Bug Tracking System：障害管理システム
*3:実際の咳チームのメンバーはここに書いてある言葉から受ける「感じ」よりはもっと淡々としてます。もしかしたら @m_seki の「だって仕事でしょ？」が伝搬しているのかもしれません。この台詞について詳しく知りたい方は、書籍『プログラマが知るべき97のこと』に収録されている 関 将俊（せき まさとし）さんのエッセイ『ロールプレイングゲーム』、またはここからも読むことができます。
*4:文中の表記揺れが気になる方がいたらごめんなさい。バグ、不具合、問題など、特に区別なくわたしの気分で記載してます。
*5:要因として思い浮かぶのは「チームの中でしか物事を考えてなかった」あたりかな。あの頃は見ている世界がとても狭かったと思います。
*6:そう！間違えるからルールにしません。ルールだからやる、はよくない。ルールにすると間違いに気づけなくなります。
