「テストは後回しでいいから、まず機能を出してほしい」と言われたときの話し方

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

リリース直前、事業側やPMから「テストを書く時間があるなら、その分で次の機能を作ってほしい」と言われることがあります。特に締め切りが近いときほどこの要望は強くなります。相手は怠けているわけではなく、「テストは目に見える成果を生まない作業」であり、「機能が増えること＝価値が増えること」だと素朴に信じているだけです。これはむしろ自然な感覚で、エンジニア側が説明を怠ってきた結果でもあります。

ここで「テストは大事なので書きます」とだけ返すと、相手には理由が伝わらず、次の締め切りでも同じ要求が繰り返されます。大事なのは、テストを書かないことの「見えないコスト」を、相手が普段扱っている言葉に翻訳して伝えることです。

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

これは「車検を通さずに走り続ける車」に似ています。車検を飛ばしても、その日のうちに事故が起きるわけではありません。むしろ整備工場に車を預けている時間がない分、今日も明日も予定通り走れます。問題は、ブレーキの摩耗やオイル漏れが「見えないところ」で進行していくことです。半年後、高速道路の合流で急ブレーキが利かず、事故を起こしてから初めて「整備しておけばよかった」と気づきます。しかもその事故の修理費は、毎回の車検費用よりずっと高くつきます。

テストも同じです。テストを書かずに機能を追加しても、今日・明日は何も壊れません。しかし3ヶ月後、別の機能を追加したときに過去の機能が静かに壊れ、それに誰も気づかないまま本番に出てしまう。発覚するのは大抵、顧客からのクレームやデータ不整合という形で、修正コストは最初にテストを書くコストの何倍にも膨らみます。

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

受け取り 「スケジュールを守りたいからこそ、テストより機能を優先したい」というのは合理的な発想だと思います。限られた時間をどこに使うかという判断そのものは正しいです。

たとえ ただこれは、車検を飛ばして走り続けるのに近い状態でもあります。今日は確かに早く走れますが、整備不良は目に見えないところで蓄積していって、ある日まとめて代償を払うことになります。

言い換え つまり論点は「テストをやるかやらないか」ではなく、「コストを今払うか、後で何倍にもして払うか」です。今回の判断は、将来の自分たちに借金をするかどうかの判断でもあります。

段階案 全部をテストで固める必要はありません。例えば次のような段階を提案します。

• 今回のリリースで一番壊れたら困る箇所（決済・ログイン・データ保存など）だけ最低限のテストを書く
• それ以外の画面表示や文言変更などはテストを省略してスピードを優先する
• リリース後、余裕のあるタイミングでテストを追加する「返済スプリント」を1回分あらかじめスケジュールに組み込む

これなら納期は守りつつ、重大な事故だけは防げます。

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

「今回はここだけ最低限のテストを残させてください。あとの部分はスピード優先でいいので、その代わり次のスプリントで少し返済の時間をもらえますか。」

この一文は「全部やらせてほしい」でも「全部諦める」でもなく、具体的な範囲とタイミングを提示している点がポイントです。相手は「何にどれだけ時間を使うか」を判断したいだけなので、選択肢を渡すほうが通りやすくなります。

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

このたとえを使うべきでないケースもあります。

• 本当に使い捨てのプロトタイプ：社内検証用や、1週間後には捨てる前提のデモコードにまでテストを求めるのは過剰です。この場合は相手の「テスト不要」の判断は正しいので、素直に同意してよいです。
• 影響範囲が極めて小さい変更：文言修正や色の変更など、ロジックを含まない変更にまで同じ主張をすると「テスト原理主義」に見え、信頼を失います。
• すでに手動確認の運用が機能しているチーム規模：数人規模で、変更のたびに人間がすべて目視確認できている場合は、テストの投資対効果がまだ低いこともあります。

こうした場面では「このたとえは今回は当てはまらないですね、スキップしましょう」と自分から言えると、逆に「テストが必要なときは本当に必要だから言っている」という説得力が増します。

6. まとめ表

テストと機能開発は対立概念ではなく、「コストをいつ払うか」という時間軸の選択です。相手の言葉を否定せず、同じ土俵の比喩に乗せて返すことで、議論は「正しいかどうか」から「どう配分するか」に変わります。