状況（非エンジニアからの要望）

「まずは機能を出そう。テストは後でいい」——プロダクトマネージャーや事業側のメンバーから、こう言われた経験のあるエンジニアは多いはずです。

背景にあるのは、たいてい悪意ではなく焦りです。競合が似た機能をリリースした、来週の商談で見せたいデモがある、四半期の目標に間に合わせたい。こうした状況では「テストを書く時間」は、目に見える成果を生まない「コスト」に見えてしまいます。機能が動いている画面はデモできても、テストコードは誰にも見せられません。だからこそ、優先順位の会話で真っ先に削られる対象になります。

ここで「テストは大事なんです」とだけ主張しても、相手には響きません。相手はテストの価値を否定しているわけではなく、「今このタイミングでの投資対効果」を天秤にかけているからです。必要なのは精神論ではなく、天秤の反対側に何が乗っているかを見える化することです。

たとえ（日常・ビジネスの比喩）

こういうときによく使うのが、「引っ越しの荷造り」のたとえです。

急いで引っ越すとき、段ボールに物を適当に詰め込めば、荷造り自体はあっという間に終わります。トラックにも早く積める。でも新居に着いてから、どの箱に何が入っているか分からず、必要なものを探すのに毎回15分かかる。割れ物を緩衝材なしで詰めたせいで、いくつかは新居で割れている。結局、荷解きと片付けのトータル時間は、ちゃんとラベルを貼って詰めた場合より長くなる——というのはよくある話です。

テストのない機能開発も同じです。「今すぐ動くものを出す」スピードは確かに速い。でも半年後、その機能に手を入れようとしたエンジニアは、何がどう動いているか分からず、恐る恐るコードを触ることになります。バグを直したら別の場所が壊れる。結局、修正のたびに人力での確認作業が発生し、リリースのたびに事業側も「今回は大丈夫か」と不安になる。荷造りと同じで、「速く終わらせた分」は、後工程のどこかで必ず精算が発生します。

提案の型（受け取り→たとえ→言い換え→段階案）

こうした場面でおすすめしたいのが、次の4ステップの型です。

① 受け取る まず「今回は急ぎたい理由がある」ことを否定せずに受け止めます。「来週のデモに間に合わせたいんですね、承知しました」と一度言葉にするだけで、相手は「エンジニアはまた反対している」ではなく「エンジニアは状況を理解した上で話している」と感じます。

② たとえで翻訳する その上で、上記の引っ越しのたとえのように、相手が普段扱っている概念（在庫管理、荷造り、家の修繕など、事業側にとって身近なもの）に置き換えて説明します。ここでのコツは、「テストとは何か」を説明するのではなく、「テストを省いたときに何が起きるか」を相手の日常語で語ることです。

③ 言い換える 「テストを書くかどうか」という二択ではなく、「今回のリリースにどれだけの手戻りコストを許容できるか」という問いに言い換えます。これにより、議題が「エンジニアの作業内容」から「事業判断」に移り、相手が当事者として意思決定できるようになります。

④ 段階案を出す 最後に、全か無かではない現実的な選択肢を提示します。たとえば「今回はコア機能（決済まわり）だけテストを書き、周辺のUI調整は後回しにする」「まず出して、リリース後1週間以内にテストを追加するチケットを必ず立てる」といった折衷案です。エンジニアが選択肢を持ってくると、相手は「対立」ではなく「相談」として受け取ります。

ミーティングで使える一文

「今回、テストを省いて速く出すことはできます。ただそれは"荷造りを雑にする"のと同じで、今週の作業時間を来月以降の修正対応に前借りしている状態です。それでも今回は前借りする価値があるかどうか、一緒に判断させてください。」

この一文の良いところは、「反対」ではなく「情報提供」として聞こえる点です。判断の主導権を事業側に渡しながら、コストが消えたわけではなく先送りされているだけだと明示できます。

例外（このたとえを使わない／肯定すべきケース）

このたとえは万能ではありません。以下のような場面では、むしろ「今はテストを書かない」判断を積極的に肯定すべきです。

  • 使い捨てを前提にした検証（PoC・実験的機能）：数週間で結果を見て捨てる前提の機能に、本番品質のテストは過剰投資です。「これは荷造りせず、そのまま新居に持っていって現地で判断する引っ越し」と割り切ってよい場面です。
  • ユーザー数・影響範囲が極小な内部ツール：壊れても影響が自分たちだけに限定され、修正も即座にできる場合は、長期コストの前提自体が小さくなります。
  • 不確実性が高く、仕様が固まっていない段階：仕様がまだ大きく変わる可能性が高いなら、先にテストを固めることが逆に変更の足かせになります。この場合は「仕様が固まってからテストを厚くする」方が合理的です。

こうしたケースで無理に「テストは絶対必要です」と主張すると、エンジニアの言葉の信頼性が下がり、本当に重要な場面で聞いてもらえなくなります。原則ではなく、状況ごとの判断であることを自分自身にも言い聞かせておくことが大切です。

まとめ表

相手の言葉 たとえ 返し
「まず機能を出して、テストは後で」 荷造りを雑にして引っ越す 「速く終わりますが、荷解きで倍の時間がかかることがあります。今回はその前借りをする価値、一緒に判断しませんか」
「テストなんて誰も見ないでしょ」 家の基礎工事 「基礎は誰にも見えませんが、次に増築するときそこが効いてきます」
「今回だけ特別、次からちゃんとやる」 今日だけ夜更かし 「一度崩れた習慣は戻すのに元より時間がかかります。今回だけで済むよう、追加チケットを先に立てておきましょう」
「バグが出たらその時直せばいい」 火が出てから消火器を買う 「事後対応は、予防より高くつくことが多いです。特にどこで直すのですか、を先に決めておきましょう」

テストを「絶対にやるべき作業」として押し付けるのではなく、「今払うか、あとで利子付きで払うか」という選択として一緒に見る。これができると、テストの議論は対立ではなく、事業判断のひとつとしてテーブルに乗るようになります。