「テストは後回しでいいから、まず機能を」への向き合い方

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

リリース間際、プロダクトマネージャーやセールスから「このテスト書いてる時間、機能に回せませんか」と言われることがある。悪意はない。むしろ現場のスピード感を大事にしている発言だ。競合が先に機能を出しそうだったり、顧客への約束が迫っていたりすると、「動くものを早く出す」ことが最優先に見えてしまう。

問題は、この主張が「今」だけを見ていて、「来月の自分たち」を見ていない点にある。テストを削って得られる時間は、たいてい数日〜数週間分。しかし、そのテストが防いでいたはずのバグが本番で出たときの手戻りは、修正・検証・再デプロイ・顧客対応まで含めると、削った時間の何倍にもなることが多い。エンジニアはこの「あとで払う利子」を体感的に知っているが、非エンジニアには見えていない。だからこそ、頭ごなしに反対するのではなく、コストの構造を翻訳して見せる必要がある。

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

これは「車検を飛ばして走り続ける」話に近い。

車検は今すぐ必要な機能を何も追加しない。乗り心地も変わらないし、見た目も同じ。だから「今月は忙しいから車検は来月でいいや」と先延ばししても、その日のうちには何も起きない。でも、ブレーキパッドの摩耗や配線の劣化は、目に見えないところで進行している。そしてそれが表面化するのは、たいてい一番困るタイミング――高速道路の合流とか、納品当日の朝とか、こちらの都合とは無関係なときだ。

テストも同じ構造を持っている。テストを書く時間は「今の機能」には何も足さない。だから短期的には「テストを削った分、機能が早く出る」ように見える。しかし実際には、テストが担保していたのは「変更を加えても壊れていないという確認作業」であり、それを省くと、次に誰かがコードを触るたびに、手動で全部を目視確認するか、壊れたまま気づかず本番に出すかの二択になる。しかもその「壊れた」が発覚するのは、たいてい一番忙しい時期のリリース直後だ。

もう一つ近いたとえは「在庫管理を省いた倉庫」だ。棚卸しをサボれば、その日の作業は早く終わる。でも次に「この商品、在庫あるはずなのにない」という食い違いが起きたとき、原因を探すコストは棚卸し作業そのものより何倍も高くつく。テストは、コードベースという倉庫の棚卸し表のようなものだ。

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

受け取り まず「早く出したい」という気持ちそのものは否定しない。「そうですね、今回のリリースは特に急ぎたい理由があるんですよね」と一度受け止める。ここで「テストは大事なので削れません」と即座に反論すると、相手は「エンジニアはいつも慎重すぎる」という印象を強めるだけで、対話が終わってしまう。

たとえ そのうえで車検やブレーキパッドのたとえを使い、「今日は何も変わらないけど、来月以降に払うコストが積み上がる」という構造を共有する。数字が使えるならなお良い。「このバグ、今直せば30分ですが、本番で出たあとだと調査・再現・修正・検証・リリースで最低半日かかります」のように、具体の見積もりに落とし込む。

言い換え 「テストを書く／書かない」の二択ではなく、「どこにリスクがあるか」の話に変換する。「今回のリリース全部にテストを書くと3日かかりますが、決済まわりだけに絞れば半日で済みます。逆に決済まわりを飛ばすと、返金対応が発生したときの信用コストが一番高いです」というように、範囲を絞った提案に変える。相手が本当に求めているのは「テストゼロ」ではなく「今日中に出せること」であることが多いので、その要求自体には応えられる形を探る。

段階案 一度に全部を守ろうとせず、優先順位をつけた段階案を出す。

1. 今回は最小限（決済・認証など壊れたら致命的な箇所）だけテストを書いて出す
2. リリース後、影響範囲が広い箇所から順にテストを追加する時間を次スプリントに確保する
3. 次回以降、同じ議論を繰り返さないよう「テストを書く前提の見積もり」を最初から出す

この3段階を提示すると、相手は「今回は妥協するが、これが常態化するわけではない」と理解しやすくなる。

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

「今日テストを飛ばして得られる時間と、来月バグ対応に取られる時間、どちらが自分たちにとって高くつくか、一緒に見積もってみませんか」

この一言は「テストをやるかやらないか」の対立構造を、「コストをどちらが払うか」という共通の土台に変える。相手を説得するというより、一緒に計算する体験に持ち込むのがポイントだ。

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

すべてのケースで「テストを削るな」と主張するのは正しくない。以下のような場面では、むしろ相手の判断を支持すべきだ。

• 使い捨てのプロトタイプや検証目的の実装：数日〜数週間で役目を終える前提のコードに、本番相当のテストを書くのは過剰投資になる。ここでは「動けばOK」でいい。
• 影響範囲が極めて小さく、失敗しても被害が軽微な機能：管理画面の表示文言の修正など、壊れても即座に気づいて直せるものにまでテストを義務化する必要はない。
• すでに手動確認のフローが確立していて、そのコストが十分小さい場合：チームが小さく、リリースサイクルが速く、壊れてもすぐ気づいて直せる体制なら、テストへの投資よりも手動確認のほうが合理的なこともある。
• ビジネス上、今この瞬間を逃すと機会そのものが消える場合：契約更新の締め切りや、重要な商談前のデモなど、「多少のリスクを取ってでも今出す」ことが正しい経営判断であることもある。この場合はテストを削ることを止めるのではなく、「代わりに何を手動でチェックするか」を一緒に決める方に頭を使うべきだ。

こうした場面まで一律に車検のたとえを持ち出すと、「エンジニアはいつも石橋を叩く」という印象を強めてしまい、次に本当にリスクが高い場面で耳を貸してもらえなくなる。たとえは「使うべき場面」を見極めてこそ効く。

まとめ表