ソフトウェアテスト Advent Calendar 2022 - Qiita 19日目の記事です。
はじめに
「慣れ」の違和感に鈍感になっているな、と思うときがあります。失敗の言い訳に「慣れのせい」と思ったり、誰かがそう言うのを聞いたりすると、なんとなく釈然としない気持ちになります。こういった種類の違和感をいちいち表明するのもなんだか面倒になって……というより、仕事中はもっと具体的な問題や課題を大切にしてしまいがちで、つい「まあいいか」となってしまうのです。これはよくないよね。
慣れの違和感の正体
より良い製品をつくるために製品や開発に関する知識や失敗を含む経験は不可欠です。知っていることが増えれば増えるほど、調査や試行錯誤にかかる時間、ゴールに到達するまでの時間を減らせます。製品の細部にまで自分たちの知見（あたたかい血）を巡らせることができます。これはプログラマもテスターもみんなそうです。開発者が製品に慣れることは自分たちにとっても、最終的にはお客さまにとっても良いことです。
慣れているから朝会や夕会でスクロールされるチケットのコードからミリ秒でバグを見つけられますし、1つのテストで2つの深刻な問題をあぶり出し、加えて近い将来バグとなって現れるであろう設計や実装の危うさをも提起する、なんてことがスッとできてしまうのです。
たまに（製品に慣れてない）専門家のほうが多くのバグを出せると言われ、返答に困ることがあります。ほんとうにそうでしょうか？ もしそうだとしたら、それは単に自分たちがうまくないだけです。とことん製品を知り尽くすべきだし、圧倒的に慣れたほうがいいのです。
”言われてみれば「たしかにそうだ」とわかるのに、いつも見ているあの画面のおかしさや、使いづらさを感じなくなっていました。”
”ちょっとした応答の遅れを感じたのに「ここはハードウェアとやりとりしてるところだから、こんなものかな…」と流してしまったのです。今まさに新しい問題が起きているというのに！”
一度でもこのような体験をしたテスターならわかるでしょう。問題を見逃したことにも相当落ちこみますが、「慣れ」をコントロールできなかった事実に恐ろしさを感じたと思います。でもそれって本当に慣れたからなのでしょうか？
トッププログラマは慣れでミスをするか
日本のトッププログラマ*1のひとり @m_seki に聞いてみました。
miwa「ちょっとおかしいと思っていたコードがあったとして、見慣れるうちにおかしいって思わなくなったりする？」
咳「えー。おかしいコードは、見慣れてもおかしいよ？」
miwa「そうだよね。じゃあ、ツールや言語に慣れたらプログラミングでミスする？」
咳「そんなことありえない。慣れでミスしない。（自分の場合は）下手くそだからミスすることが多いかな。むしろ慣れが足りない。」
予想どおりの回答です。おかしいコードをずっと見ていたら、おかしくないコードに見えるでしょうか。いいえ、おかしいコードはいつ見てもやっぱりおかしいと感じるはずです。そのロジックでいくと、製品に慣れていてもおかしいものを見たら、毎回おかしいと思わないとおかしいのです。
先にも書いたように「慣れ」自体は悪いことではないので「慣れすぎて」というのは、聞こえのいい言い訳やなぐさめのようにも思えてきます。人間は認知バイアスによって思いこみや慣れや経験により間違った判断をする場合があります。だから、そうなってしまうこと自体はある程度仕方ないと、自分の感情をうやむやにして言葉をのみこんでしまう。これらの総和が違和感の正体かもしれません。
信じられないものを信じる練習をしている
「クリフォードは、定員いっぱいの乗客を乗せて出航しようとする移民船の船主を例にあげた。この船主は、船が古くて状態が悪く、そもそも造りがあまりよくないことを心配していた。もう一度無事に航海できるかどうかは疑問だと真剣に考えていた。しかし、船主はなんとか疑問を打ち消し、あと一度だけ航海したからといって、たいした危険はないと自分に思い込ませた。この船はかつて何度も嵐にさらされたが 、いつもどうにか港へ戻ってきたではないか。もう一度できない理由はあるまい。船は出航し、乗客、乗組員もろとも沈没した。」
ー『熊とワルツを リスクを愉しむプロジェクト管理』トム デマルコ, ティモシー リスター著
おかしいものを見てもおかしいと思わなくなっているとしたら、それは「慣れ」ではなく、この船主のように、
次のようなことを試してみるのもよいでしょう。
- 現象だけに注目するのではなく、なぜそうなるのかに意識を向けます。それが許容できるかどうかだけでなく、どのような仕組みでそのようなふるまいになるのか疑問を持ちましょう。
- これで良いはずだと信じるなら、信じるに至る理由や根拠をあげてみましょう。◯◯さんがそう言ったからとか仕様だからは理由や根拠になりません。「これはほんとに素晴らしい仕様だろうか？」と自分に（みんなに）問いかけてみましょう。
- 中長期にわたる製品シリーズの開発では「ずっと前からそうなっている」を免罪符にしてしまうことがあります。なぜその仕様やデザインが
今も 素晴らしいと言えるのかを自分の言葉で説明してみましょう。 - "見送り"、"暫定"、"様子見"、"とりあえず"、”次バージョン以降で対応” のような、あなたのチームで使われている特別なキーワード、方言、フレーズでチケットを検索してみましょう。信じる練習済みのイケてない仕様や設計、当時の対応に出会えるかもしれません。
- おかしさや違和感や異常を感知しなくても、自分の意識下にある前提や目の前の当たり前をひとつひとつ疑う癖をつけましょう。
おわりに
わたしがテスターとして恐れる「慣れ」について思うことを言葉にしてみました。「慣れ」ではなく「慣れのせいにする状況」を恐れるのが良さそうですね。これなら自分でコントロールできるから恐れなくてもいいのかも。
昨日よりも今日、今日よりも明日の自分の思考や言動が、まわりの人たちに良い影響を与えられるよう、日々研鑽*2を重ねていきたいと思います。
あわせて読みたい
書籍『熊とワルツを リスクを愉しむプロジェクト管理』のKindle版のサンプル（無料）をダウンロードすると引用した部分を含めた「プロローグ」全文を読むことができます。示唆に富む内容で読むたびに「ふふっ」となります。全文良すぎて今回どの部分を切り取るか悩みました。お時間のあるかたはぜひ本記事とあわせて読んでみてください。
この記事を書くにあたり、書籍『ソフトウェアテスト293の鉄則』を読み返しました。本記事と関連しそうな鉄則をあげておきます。わたしにとってバイブル的な書籍の1冊です。
- 鉄則018「認知心理学も駆使する」
- 鉄則039「思い込みから逃れられなくても、上手く付き合うことはできる」
- 鉄則040「騙されやすいと自覚することが騙されない秘訣」
- 鉄則043「慣れは見落としの素、新鮮な眼をいつも絶やさずに」
いつものやつを貼っておきます。文中の"プログラマ"をご自分のロールに置き換えて読んでみてね。
*1:書籍『プログラマが知るべき97のこと』の帯に"トッププログラマ"と書いてある
*2:とちぎRubyの勉強会で 書籍『研鑽Rubyプログラミング β版 – 技術書出版と販売のラムダノート』を読んでいて"研鑽"という言葉がマイブーム ←死語？
