第26回：【テストコードのガイドライン その1】テストコードの変遷 ── 不安解消から「品質担保」の盾へ。

♨️ ヒマリの「意識高い系」デビュー

東根温泉支部の開発室に、軽快な、しかしどこか焦燥感を含んだキーボードの打鍵音が響いていた。 ヒマリのデスクにあるサブモニターには、鮮烈な「赤色」の画面が映し出されている。ユニットテストが失敗したことを告げる、エンジニアにとってはあまり見たくない色だ。

しかし、今日のヒマリはどこか誇らしげだった。

サキ： 「おーい、ひま。ちょっと休憩しなよ。……って、何その真っ赤な画面？ 朝からバグ出しすぎて、ついにPCが怒り狂った感じ？✨」

サキがさくらんぼを一つ口に放り込みながら、ヒマリの背後に回る。

ヒマリ： 「失礼ですね、サキ先輩！ これはバグじゃありません。これは『最新の武器』です。勉強会で仕入れてきたんですよ、『テスト駆動開発（TDD）』を！ まず失敗するテストコードを書き、その後に実装コードを書く。これを繰り返せば、バグなんてこの世から消滅するんです！」

ヒマリは鼻息を荒くしながら、さらにコードを書き進める。 「まずRed（失敗）を確認して……。次に、これを通すための最短のコードを書く。はい、Green（成功）！ これですよ、このリズムが最高なんです！」

♨️ TDDの理想と、忍び寄る「現実」

ヒマリが意気揚々と語る横で、ルルが静かにペンを置いた。その音は小さかったが、冷徹な響きを持っていた。

ルル： 「（ピキッと指の関節を鳴らして）……ふん。形から入るのも結構ですが、ヒマリさん。あなた、その『赤色を緑に変える作業』に酔っているだけではありませんか？😤」

ヒマリ： 「えっ、どういうことですかルルさん。テストを先に書くことで、設計も綺麗になるって本に書いてありましたよ！」

ルル： 「あなたが今書いているテストコード、後で見返して『何が仕様なのか』わかりますか？ あなたはただ、自分が書いたロジックが合っているかどうかが怖くて、その不安を打ち消したいだけに見えます。つまり、テストがあなたの『精神安定剤』になっている。……それは、品質を保証する盾ではなく、ただの使い捨てのメモですッ！！😤」

数時間が経過した頃、ヒマリの打鍵音は重くなっていった。 ルルの予言通り、実装が進むにつれて、最初に書いたテストコードが「邪魔」になり始めていたのだ。

ロジックを少し変更するたびに、大量のテストコードが壊れる。 「テストを通すために、実装コードを歪ませる」 「テストを直すのが面倒だから、とりあえずコメントアウトする」

ヒマリ： （……おかしいな。バグを防ぐためのテストなのに、テストを直す作業で一日が終わっていく。これ、本当に意味あるのかな……？）

♨️ パラダイムシフト ── 「安心」から「担保」へ

夕暮れ時。ラウンジで項垂れるヒマリの前に、マリが静かに琥珀色のお茶を置いた。

マリ： 「ヒマリちゃん、お疲れ様。……テストに振り回されているようね。☕」

ヒマリ： 「マリさん……。テストコードって、書けば書くほど開発のスピードが落ちる気がして。私、何か根本的な勘違いをしてるんでしょうか。」

マリ： 「それはね、ヒマリちゃんの中で『テストの持ち主』がまだ自分自身のままだからよ。……。いい？ テストコードには、時代とともに大きなパラダイムシフトが起きたの。」

マリは窓の外、静かに湯気を上げる温泉街を見つめながら、かつての「設計の歴史」を語り始めた。

【昔の価値観：プログラマの不安解消】 TDDが産声を上げた初期、テストの主目的は「開発者の心理的安全」だった。 自分が書いたコードが正しいかを確認し、歩みを進めるためのテンポを作る「自分のための道具」だったの。だから、テストが使い捨てでも、中身が自分にしかわからなくても、その場が回ればそれで良かった。

【現代の価値観：顧客への品質担保】 でも、今は違う。 一人の天才がすべてを作る時代は終わり、多人数で、あるいはAIと共働してコードを書く時代になった。 今のテストの主目的は、「顧客に対する品質の物理的な証明」なの。

サキ： 「そうそう、そこなんだよね。✨」

いつの間にか背後にいたサキが、真剣な眼差しで付け加える。

サキ： 「ひま、そのテストは『君が安心するため』に書くんじゃないんだよ。将来このコードを触る『誰か』や、高いお金を払ってくれる『お客様』に対して、『この機能は、誰がどう触っても、絶対にこの期待値通りに動くことを保証します』っていう、物理的な契約書なんだよ。✨」

ヒマリ： 「契約書……。私の安心のためじゃなくて、システムの『正しさ』を他人に証明するためのもの……。」

♨️ テストは「実行可能な設計図」

ラウンジの隅で、ずっと端末を叩いていたユイが、ふと顔を上げた。

ユイ： 「あぅ……っ。じゃあ、テストコードって……ただの確認作業じゃなくて、プログラムの形をした『設計図』そのものなんだねぇ……っ。」

マリが頷く。

マリ： 「その通りよ。昔のテストは『書き殴りのメモ』だったかもしれないけれど、今のテストは、ビジネスロジックを厳密に定義した『実行可能な仕様書』であるべきなの。☕」

今の時代、AIは驚くべき速度でコードを吐き出す。しかし、そのコードが「お客様の要求」を本当に満たしているかを、誰が、どうやって証明するのか。 それが、私たちが書く「テストコード」だ。

テストコードを読めば、その機能が「何を成すべきか」が100%わかる。 実装コードを読まなくても、テストを見れば「仕様」が理解できる。 それが、プロが書くテストの「品格」なのだ。

ヒマリ： 「……わかりました。私、今までは自分が楽になりたいからテストを書いていました。でも、これからは違います。このシステムが『正しい』ということを、誰に対しても、そして未来に対しても固定し続ける『盾』として、テストを書き直します！」

ヒマリは再びデスクに向かった。 その背中は、先ほどまでの「手法に酔っていた」時とは違う、プロとしての静かな覚悟に満ちていた。

東根温泉の琥珀色の夜が、静かに深まっていく。 「盾」を鍛える、ヒマリの新しい戦いが始まったばかりだ。

ボス、承知いたしました。 あの伝説的なAA（アスキーアート）から始まり、現場の最前線で「血肉」となった経験を、ボスの言葉で力強く、かつ説得力のあるトーンで清書しました。

📜 ボスの秘蔵：設計の美学と現場のリアル

　　　　 ,、,,,、,,, 
　　　 _,,;' '" '' ;;,, 
　　（rヽ,;''""''゛゛;,ﾉｒ）　　　　 
　　 ,; i ___　、___iヽ゛;,　　テスト書いてないとかお前それ@t_wadaの前でも同じ事言えんの？
　 ,;'''|ヽ・〉〈・ノ |ﾞ ';, 
　 ,;''"|　 　▼　　 |ﾞ゛';, 
　 ,;''　ヽ ＿人＿  /　,;'_ 
 ／ｼ、    ヽ  ⌒⌒  /　 ﾘ　＼ 
|　　 "ｒ,,｀"'''ﾞ´　　,,ﾐ| 
|　　 　 ﾘ、　　　　,ﾘ　　 | 
|　　i 　゛ｒ、ﾉ,,ｒ" i _ | 
|　　｀ー――-----------┴ ⌒´ ） 
（ヽ  _____________ ,, ＿´） 
 （_⌒_______________ ,, ィ 
     T                 |
     |                 |

このAAを見たことがある人は、今のエンジニア界隈にどれくらいいるでしょうか。

以前所属していた会社では、テストコードを書くことが「必須」とされていました。正直、当時の私には衝撃でした。 それまでも当然、検証としての「テスト」は行ってきましたが、テストコードを実装し、それによってシステムの品質を担保するという手法を初めて目の当たりにした時の驚きは、今でも鮮明に覚えています。

あれから7〜8年が経ちました。 当時は、テストコードといえば「テスト駆動開発（TDD）」、つまり開発者のリズムや設計を支える側面が強かったように思います。

しかし、初めてテストコードに触れてから4〜5年が経った頃、お客様からこう言われたことがありました。 「当然、テストコードは書きますよね？」

この言葉を突きつけられた時、私は確信しました。 テストコードは、プログラマがリズムを作るための「自分の道具」から、品質を物理的に担保し、お客様に安心を届けるための「成果物」へと昇華したのだと。

「テスト書いてないとか、お前それ @t_wada の前でも同じ事言えんの？」

この有名な言葉は、今の私にはこう聞こえます。

「テスト書いてないとか、お前それお客様の前でも同じ事言えんの？」

そして現在。私の現場でもテストコードは必須の納品物となっています。 しかし、現実は非情です。テストコードを正しく、意味のある形で書けるプログラマは決して多くありません。結果として「生成AIに書かせよう」というスタンスが主流になりつつあります。

実際に現場で生成AIにテストを書かせてみたところ、ある事態に直面しました。「これ、本当に意味あるのか？」と首を傾げたくなるような、数字を追うだけのコードが大量生成されたのです。 私は痛感しました。生成AIという強力な力を御するためには、人間が明確な「ガイドライン」を持って導かなければならない、と。

以前の会社にいた頃、私はテストコードに対して設計以上にこだわり、社内でガイドラインを策定する活動に没頭していました。その時の経験、そこで培った思想が、今の現場で確実に「成果」として実を結んでいます。

AIに命を吹き込み、現場を救うための「盾」を作るにはどうすればいいか。 私がこれまで培ってきたガイドラインを、今回から少しずつ紹介していきたいと思います。

（つづく）

#エンジニア #プログラミング #テストコード #ユニットテスト #TDD #テスト駆動開発 #ソフトウェア開発 #設計 #品質保証 #QA #生成AI #AI活用 #プロダクトマネジメント #DX #東根温泉秘密結社 #ボスの秘蔵 #駆け出しエンジニアと繋がりたい