自分はなぜテストを書かないのか

自分はなぜテストを書かないのか

僕は一人でサービスを作っているのですが、テストを書きませんし、書くのは時間の無駄だと思っています。ここでのテストっていうのは回帰テストのことね。なぜならめんどくさいから・・ではなくて、今書いたところで対して効果が期待できないからです。

いや、分かる。テストは品質を保つのに大事ですよ。バグが極力無い状態でユーザに提供できた方がいいに決まってますよ。でもね、「やったほうが良いこと」なんて他にいっくらでもある訳で、全部やってたらキリが無いんですよ。リソースは限られています。僕なんかフリーランスで受託開発しながら一人で自分のプロダクトを作ってるので、余計に。その制約の中で、どうすればアウトプットを最大化できるかを考えた時、僕はテストを書かないという選択を取っていますよという話です。

理由をもう少し詳しく説明します。

テストを書く目的ってなんでしょう？プロダクトを作る目的は利益を得ることです。だからテストを書く目的はバグを減らすことではありません。それは手段です。目的はバグによる機会損失を防ぐことと、デグレードなどのメンテコストを下げる事だと思います。

まだ始めたばかりのプロダクトや、充分に収益化できていない時点でテストを書いてもしょうがないのです。そもそも損失する機会が少ないし、気にするほどのメンテコストもかからないですから。

テストにコストをかけるよりは、デグレ上等で前のめりに変更を加えていった方が中長期的にみても機会獲得につながります。ようは守りより攻めの姿勢です。

もちろんコアな機能が動かなくなったら本末転倒です。リリース前は必ずスモークテストしたりひと通り手動で確認する事は重要です。それでもバグは出てしまうものですが、気にする必要はないと思います。だって、ユーザさんが報告してくれるから。

えっ、ユーザを当てにするなって？いやいや、この方がいいんですよ。特にユーザが少ない内は。その少ないユーザさん達と交流できるからです。その代わりバグ報告を受けたら最優先で全力で応じます。そして変更履歴にその報告者さんの名前をクレジットするのです。すると、「俺はこのアプリに貢献したぞ」と喜んでくれて愛着を持ってくれるわけです。

しっかりテストされてバグが排除されたアプリには機会損失が無いですが、機会獲得もありません。バグは図らずともユーザさんと仲良くなるきっかけをもたらしてくれるのです。オープンソースだって、最初から完璧なものより不完全なものの方がコントリビューションが盛り上がるって言うじゃないですか。

「テスターは最初のユーザ」といいますが、一人で作っている場合は自分自身が最初のユーザでもあります。他にいませんからね。チームで分担作業をするとどうしても自分の担当範囲ばかりに目がいって、全体を俯瞰して評価することをおろそかにしがちです。

「そもそもこの設計っておかしくね？」という問いを最も立てやすいのはテスターです。一人で作っているから、この全体最適化の観点は常に持つことが出来ます。そしてチームだったらその「おかしくね？」が言いやすい雰囲気かどうかって結構大事だと思うんですけど、一人なら全て自分次第です。もとい、自分との闘いです。

以上、僕がテストを書かない理由をつらつら述べてきました。あくまでこういう条件の場合はいらないよという話です。逆に当てはまらないのならテストを書くべきです。ユーザが増えて収益も上がってきて複数人体制になったら、バグによる機会損失が無視できなくなるでしょう。

テストを書く必要性があるというのは贅沢な悩みで、すごく羨ましいことだと思います。僕も早くそうなりたい。