テストなし？それ、あり得ません。

開発部
1月23日
読了時間: 5分

更新日：1月27日

こんにちは！株式会社雲海設計の技術部です。

いきなり強い言葉で始めます。

本番に入るコードにテストがないのは、エンジニアとしてあり得ません。

ただし誤解してほしくないのは「すべてのコードにテストを書け」と言いたいわけではないということです。現実にはテストに時間を割く合理性が薄いケースもあります。

たとえば、

一度きりのデータ移行スクリプト（実行後に捨てる前提）
技術検証のためのPoC（実現可能性の確認が目的）
本番に一切影響しない、完全に隔離された調査用コード

こうした「書き捨て」が前提のものは、テストよりも実行手順のレビューやリハーサルのほうが費用対効果が高いこともあります。

しかし、

本番環境にデプロイされるコード

事業に影響する変更

お客様のデータを扱う処理

ここにテストがないのは、やはり「あり得ない」。

理由はシンプルでこれは品質論ではなく経営判断としても損だからです。

テストがないのは「品質が低い」ではなく「損失が増える」

「テストは品質を上げるもの」と思われがちですが、本質は違います。

テストは未来に起こる損失を減らすための保険であり、投資です。

テストがない現場で増えるのは、だいたい次の4つです。

1. 手戻りコストが跳ね上がる

バグは遅く見つかるほど高くつきます。

開発中なら数分で直せる不具合でも、本番で発覚すると、

調査（ログ・再現・影響範囲の洗い出し）
原因特定と修正
レビュー、再テスト、再リリース
関係者説明、報告書、再発防止策

と、やることが一気に増えます。

「直す」より「説明する」時間が増えるのが、本番障害のコスト構造です。

2. 障害コストは連鎖し信頼コストが最後に残る

障害が起きると直接的な機会損失だけでは終わりません。

サービス停止による売上減少
SLA違反による補償
CS問い合わせの急増
SNS等での信用毀損
取引先からの追加発注見送り

特に受託ではここが致命傷になりがちです。

「直ったからOK」にならず、信用の回復に時間がかかる。

テストを削って節約したはずが最も高いコストを支払う形になります。

3. 開発スピードはテストがないほど遅くなる

「テストを書くと遅くなる」は短期だけ見た錯覚です。

テストがないと、回帰確認（既存機能が壊れていないかの確認）が人力になります。

機能が増えるほど確認項目が増え、リリース前のチェックが肥大化する。

結果として、

リリース前の確認で丸一日溶ける
不安があるから変更をまとめて出す（PRが巨大化）
さらに影響範囲が読めず、確認が増える

という形でスピードが落ちます。

テストがない現場は「変更の単価」が上がり続けるのが問題です。

4. 組織が疲弊し属人化が固定化される

テストがないとコードの安全性が人の記憶に依存します。

「あの機能は○○さんしか触れない」
「触るなら○○さんに確認して」
「ここは壊れやすいから触らないで」

こうして聖域が増え、引き継ぎや採用にダメージが出ます。

優秀なエンジニアほど「この現場は危ない」と判断して離れやすい。

結果として、さらに属人化が進む。

テスト不在は技術課題ではなく組織課題になります。

「テストを書く時間がない」を作っているのは大抵テスト不在

よくある反論がこれです。

テストを書いている時間がもったいない。機能開発に充てたい。

しかし、現場の時間が消えている原因は、だいたいここにあります。

手動回帰の確認
障害対応と恒久対策
仕様の認識ズレによるやり直し
「怖くて触れない」状態による遠回り

テストのコストは“目に見える”。

一方で、テストがないことによる損失は“日常に溶ける”。

だから削られがちですが、経営的には逆です。

何をどこまでテストするかは「優先順位」で決める

ここまで読むと「じゃあ全部テストすべき？」となりますが、答えはNOです。

大切なのは “守るべき領域”を決めて、そこに集中することです。

優先度が高い領域は、だいたいこのあたりです。

認証・認可（権限）：事故が即セキュリティ問題になる
請求・決済：金銭トラブルは致命傷
データ整合性（計算・集計）：誤データは信頼を壊す
外部連携：影響範囲が広い、契約条件に触れやすい
監査ログ・証跡：コンプラ要求が強い

逆に管理画面の軽微なレイアウトや一時キャンペーン等は、優先度を下げても成立するケースが多い。

テスト戦略は「ピラミッド」が現実的

テストには種類があり、全部を同じ比率でやるのは非効率です。

Unit（単体）：速い／壊れにくい／ロジック保証に強い
Integration（結合）：DB・API・外部連携の事故を減らす
E2E：重要フローの安心感は大きいが、遅くて壊れやすい
Static（静的解析）：型・構文・ルール違反を最速で止める

よくある失敗は「E2Eを増やせば安心」という誤解です。

E2Eは増やしすぎると実行が重くなり、変更に弱く、開発のテンポを壊します。

現実的には、

土台にUnitを厚く
Integrationで重要な連携を抑え
E2Eは最重要フローに絞る

これが最もコスパが良い戦略です。

状況別：最初に守るべき一線（現実解）

スタートアップ／高速開発フェーズ

「全部テスト」は捨てる。ただし、壊れたら致命傷な箇所だけ守る。

まずは認証・課金・データ整合性から。

受託開発／関係者が多い

認識ズレが最大コスト。受入基準を明文化し、それに沿ってテストを書く。

「完了の定義」が固まるだけで、手戻りが減る。

レガシー／負債が多い

改善より先に「回帰の柵」を作る。

現状の動作をテストで固定してから、少しずつ触れる状態にする。

まとめ - テストは「納期と利益」を守るための仕組み

テストは「品質を上げるための手段」ではなく、

損失を防ぎ、納期を守り、利益を守るための投資です。

手戻りコストを減らす
障害の連鎖を止める
開発スピードを落とさない
属人化を固定化しない

もちろん、すべてのコードにテストが必要なわけではありません。

守るべき領域を見極め、優先順位をつけて、現実的に始めること。

あなたの現場では、まずどこが“壊れたら致命傷”になりそうですか？