序文
このブログもすっかり放置が過ぎて、なんと1年以上更新してませんでした。まぁ今回のように書きたいことがあったら時々書くようにします。文章書くのもそれなりにパワーがいるんですよね。
「テスト駆動開発モブ写経読書会」のご紹介
掲題の件ですが、そもそもとしてオレの意見ではなく、我々が運営・開催している「テスト駆動開発モブ写経読書会」から出た意見ですので、まずは発端となった「テスト駆動開発モブ写経読書会」から紹介させてください。
「テスト駆動開発モブ写経読書会」は「テスト駆動飲み会」から派生したIT勉強会で、ケント・ベック著 / 和田卓人(@t_wada)さん訳の名著「テスト駆動開発」(オーム社出版) を、モブプログラミングで参加者全員で読みながらコードを写経しながら理解を深めていく、という会です。活動を開始したのが2023年1月なので、1年半ほど継続しており、毎月第一・第三金曜日に開催していますので、何のかんのと40回以上開催してきておりますが、新しい参加者がいらしたりすると第一章に戻ったりと何度も同じところを読み直したりしてるので、まだ読み終わる様子はありません。初心者の方にも優しくモブプログラミングとテスト駆動開発を体験いただけるように取り組んでおりますので、ぜひ気軽にご参加ください。
本題
前回の「テスト駆動開発モブ写経読書会」では「テスト駆動開発」の中から和田卓人さんが寄稿された「付録C 訳者解説：テスト駆動開発の現在」の章を輪読していたんですが、その際に「そもそも『テスト駆動開発』の『テスト』という単語のチョイスが日本人には適切ではないのではないか？」という議論になりました。
日本人が「テスト」という単語から想起するのは、おそらく多くの人は学校の試験……中間テストや期末テストであり、その次に工業製品等の品質テストなんじゃいかなと思います。ソフトウェア開発における「テスト」が持つ語感もほぼ同じで、バグや不具合が無い、仕様通りに動作する、そんなことを確認するための工程を「テスト」と呼んでいると思います。
もっと言ってしまえば、「テスト」という言葉に対してネガティブな印象を持っている人が多いように感じています。学校のテストにせよ工業製品等の品質テストにせよ、面倒で、準備にも実施にも手間がかかって、成績が悪ければペナルティがある。テストが好きな人がいれば会って話を聞いて正気を問い正したい(※言い過ぎ)。
実際のところ「テスト駆動開発 (TDD)」に取り組むことでその過程で単体テストコードが書かれ、動作がそれらによって担保されますし、結果としてバグや不具合が少なかったり品質が安定する面はあるかと思います。ですが、「テスト駆動開発」の本質は「設計」にこそあります。実コードを書くためにそのコードのテストを先に書き、テストコードを先んじて書くためにToDoにやるべきことを洗い出す。動作する実コードが書けたらリファクタリングを行いその後の実装や変更を行いやすく整え、リファクタリングが終わったらToDoの再確認とブラッシュアップを行ってまたテストコードから書き始める。この過程はまさに「設計」の工程であり、プログラマが安心感と自信を持って開発を進めるための手法が「テスト駆動開発」です。
ところが「テスト駆動開発」の実態を鑑みると、「テスト駆動開発」をフワッと理解している人々から「TDDやってれば品質上がるんでしょ？」とか「TDDやってるんならテストは要らないよね」とかいう意見を往々にして言われがちである、ということがあるようです。前述のように「テスト」にはネガティブが印象があるので、みんな可能であればやりたくないし全力で避けたい。「テスト駆動開発」がテストを肩代わりしてくれるなら渡りに船くらいに考えるのもまぁ分からんでもないです。
確かに「テスト駆動開発」に取り組むことで結果として品質が上がる側面はありますが、設計のためにテストコードを書いている＝品質チェックを目的としてはいない ので、品質テストは品質テストでキチンと実施すべきです。TDDやってるからテストやらなくていい、なんて言われてしまうのは本意ではない訳ですよね。
じゃあなんでこんなこと言われちゃうのか、というと前述のように「テスト」という単語に対する日本人の認識が誤解を招くのではないか、という意見が我々の議論で出ました。やはり前述の「学校の試験」ですが、英語では「test」ではなく「examination」もしくは「exam」を用いるようです。そもそも用いる単語からして違うみたいですね。工業製品等の品質テストは「quallity test」なのでこちらは「test」で同じなんですが、いづれにせよ日本人が学生の頃から「テスト」という単語に持っているイメージと、ケント・ベックら欧米人が「テスト」という単語に持っているイメージに、若干なれど差異がありそうです。さらに、日本人特有の要素として「テスト」という単語にネガティブな印象を持っているのだとすれば、何か……この場合はその対象が「テスト駆動開発」になるわけですが……に押し付けたくなるのも頷けます。
であるならば、「Test Driven Development」を日本語訳するときに意図的に超約する……つまり「テスト」に別の単語を用いることで誤解をある程度防げないか、という議論になりました。
そこそこ現実的なものから荒唐無稽なものまでさまざまな案が出たのですが、一番収まりが良さそうだな、とまとまったのが掲題の「テイスティング」でした。要は「味見」という単語ですが、ワインやウイスキーの熟成具合を確かめるために樽から直接汲んで味を確認する作業も「テイスティング」と呼ぶんだそうです。酒の熟成の過程をテイスティングでチェックする、なんとなく「テスト駆動開発」の開発の過程を上手く表現できている気がしませんか？ たまたまですが「testing」と「tasting」で一字しか違いませんし、略称も「TDD」のままですし。また、自分で作ったものを自ら評価することを「ドッグフーディング」なんて呼ぶこともありますが、これも要は「味見」ですよね (ドッグフーディングは「毒見」の意味合いも強いかもですが)。そういう文脈からも乖離していないので、TDDの最初の「T」を「テイスティング」の「T」に変えるのはそれほど違和感が無いのかな、と思いました。
……あ、ちなみに、「付録C 訳者解説：テスト駆動開発の現在」では「testing」と「checking」の違いについても説明されています。本文だけでなくぜひ付録も読んでみてください。
終わりに
議論と言いつつ言葉遊びの戯れ合いなのですが、「テスト駆動開発モブ写経読書会」では「テスト駆動開発」をより深く知るための議論やモブプログラミングを行っています。常連参加者の殆どが40歳以上なのでどうしても懐古厨的な会話になりがちですが、若い人もウェルカムですので、ぜひお気軽にご参加ください。
余談ですが、今までモブプログラミングには「Replit」を使っていたのですが、先日仕様変更により人数の制約が新たに加わってしまい、今後も使い続けるのが難しくなってしまいました。新しいツールを探さなきゃなぁと頭を抱えていたんですが、そのツールの評価を勉強会の参加者の方が率先して行ってくれていて、運営としては非常に助かっています。確立出来たらきっとどこかでノウハウを公表してくれるんじゃないですかね。
