そろそろ「テスト」という言葉を使うのをやめたほうがいいのかもしれない

週末になごやのこわい人*1が東京に来てたのでいろいろ話したんだけど、そのときにちょろっと出た話について忘れないうちにまとめておく。

タイトルの件だけど、結局僕らはテストをやりたいというよりはいいプロダクトやいいサービスを作りたいのであって「テスト」という言葉を使っちゃうといろいろ誤解されることもあるなーと思った。

ソフトウェアの世界で「テスト」と言うといわゆる単体テストとか結合テストとかシステムテストとかのことを暗黙的に示してしまうわけで、それは仕様通りにソフトウェアが実装されているかどうかを確かめる行為であると認識されることが多い。実際にはさらにその先にそのソフトウェアがどの程度の価値を生み出したかという重要な指標があるんだけど、それは「マーケティング」と呼ばれたり最近だと「UXデザイン」と呼ばれたりしてソフトウェアテストとは別のものとして扱われたりする。

でも、機能上のバグだろうと、性能上のボトルネックだろうと、UI の酷さだろうと、それが結果的にユーザ体験を損ねているんだったらそれはソフトウェアとして十分な価値をデリバリーできてないわけであって、僕たちはそれらをテストしたいんだ。

ちょうど先日以下のような記事があった。

「ユーザーをちゃんと丁寧に扱うこと。これはソフトウェアの1つの機能ですよ。多くのソフトウェアは、この機能を実装していない。なんか特定の機能がないとか、ある機能が期待したように動かないとか、そういう話じゃないです。ぼくはユーザーを見放したりしない。人間というのは、ちゃんと自分に向き合ってくれる人の元を去らないもの。ソフトウェアも同じで、機能、機能、機能、技術、技術、技術……、そんな話じゃない。ソフトウェアも人の話なんです。使いやすさとか、きちんとユーザーに向かうことの大切さが過小評価されてると思います」

この記事では Amazon がロジスティックスを最適化しているという事例や Basecamp のユーザサポートの事例があげられているが、この事例のようにユーザ体験に大きな影響を与える要因がソフトウェアそのものではなくそれより外の世界であることは決して少なくない。

こういった現実世界の副作用をソフトウェアテスティングの知見を活かして測定することも可能なはずだし、副作用のない世界ででしか価値を発揮しないソフトウェアにはあまり意味がない*2

例えば自分たちが作っているプロダクトの KPI が一体何なのかというのを常に考えて、それが達成されてるか未達なのかを監視し続ける仕組みとか、未達だった場合にその原因と考えられる要素を分析して通知する仕組みとか、それをプロダクトの設計や実装にフィードバックするチームやプロセスの設計とか、きっと僕たちがやりたいことはそういうことなんだよ。

おまけ

ただ、ちょっと難しいなと思うのは(これは個人的な嗜好性なんだけど)僕はそれが再現可能なプロセスじゃないとあまり満足感を得られない人で、例えば自分が超がんばって成果を出したとか極めて特殊なチームの強みがあったからうまくいったという感じでなく、同じようなスキルを持った人たちが同じようなことに取り組めば同じことができるということのほうが興味がある。そうなるとパターンランゲージっぽい方向になると思っていたりする。

*1:https://twitter.com/kyon_mm

*2:もちろんそれすらちゃんとできてない場合もあるのでこれ自体は重要なことではある。