シフトレフトとは？本番環境で発生するバグを1/3に減らす方法

---

IBMの調査によると、本番環境でバグが見つかった場合、その修正コストは設計段階で発見した時の6倍にもなるそうです。

さらに、問題はそれだけではありません。

多くの開発チームが、作業時間の20〜40%を本番環境でのバグ対応に費やしているのが現状です。本来なら、その時間を新機能の開発や改善に使いたいところですよね。

もしあなたが「ソフトウェア開発ってそういうものだよね」と思った方は、おそらくシフトレフト（Shift Left）をまだ取り入れていないのではないでしょうか。

---

シフトレフト（Shift Left）とは？

シフトレフトとは、システム開発の工程（企画→要件定義→設計→実装→テスト→リリース）において、より上流の段階からセキュリティ対策やテストを組み込むという考え方です。
テストといえば、通常は下流工程で行うイメージがありますが、それを「もっと左＝早い段階」にシフトさせることから、「シフトレフト」と呼ばれています。
早い段階で問題を洗い出せば、修正にかかる時間もコストも大幅に削減できます。そして、より多くのリソースを新機能開発に使えるようになります。

シフトレフトの実例

例えば、ECアプリに認証機能を追加するケースを考えてみましょう。

従来のプロセスでは、開発が終わったあとにQA（品質保証）チームがテストを行い、本番環境にリリースされます。
しかし、QAチームだけですべてのバグを見つけるのは不可能に近いのが現実です。

そこで、シフトレフトの考え方では、要件定義の段階からQAチームがプロジェクトに参画し、この時点で、次のような質問が飛び交うかもしれません。

• OTPを送信するメールは、ちゃんと届くのか？
• 登録時には、どんなバリデーションが必要か？
• ブルートフォース攻撃にはどう対応するか？

こうした問いかけを通じて、開発者は初期段階からセキュリティやバリデーションを意識しながらコードを書くようになります。

その結果、バグの多くが早期に発見され、本番環境で発生する問題は大幅に減少します。

「要件が生まれたその瞬間からテストは始まっている」
それこそが、シフトレフトの本質です。

シフトレフトとテスト駆動開発(TDD)の違い

「それってTDDと同じじゃないの？」
そう感じた方もいるかもしれません。

確かにどちらも「開発前にテストを考える」という点では共通しています。
しかし、スコープ（適用範囲）が大きく異なります。

テスト駆動開発は主に開発者が主導し、ユニットテストに特化したアプローチです。一方、シフトレフトは、要件定義からリリースまで、開発ライフサイクル全体を対象とした考え方です。言い換えれば、テスト駆動開発はシフトレフトの一部に過ぎません。

シフトレフトでは、設計書や要件レビュー、統合テストの問題点などを、コードを書く前に洗い出します。そのため、プログラミングスキルがなくても、参加できることが特徴です。

つまり、テスト駆動開発が「開発者向けのアプローチ」であるのに対し、シフトレフトは「チーム全体で取り組む戦略」です。また、テスト駆動開発が「ユニットテスト」に焦点を当てるのに対し、シフトレフトは「プロジェクト全体をスコープ対象」とします。

---

---

テスト駆動開発はあくまで、シフトレフト戦略の一部として捉えるのがよいでしょう。

シフトレフトのメリット

シフトレフトを導入することで得られるメリットは、コスト削減だけにとどまりません。

1. 開発スピードの向上

QAエンジニアが実装完了を待たずに動き出せるため、開発・QA・DevOpsが並行して作業できるようになります。その結果、リリース直前に起きがちな障害も減り、リリースまでのスピードが大きく向上します。

2. コード品質の向上

要件定義の段階からテストを見据えることで、テストしやすい設計・実装が自然とできるようになります。バリデーションやセキュリティも後回しにせず、品質への意識が最初から組み込まれるのです。

3. 安定したリリース

バグが早期に発見されることで、本番環境での障害が激減します。
「金曜の夕方に緊急リリース対応」といった悪夢のような状況も、避けやすくなるでしょう。

ただし、「シフトレフトを徹底してすべてに適用しよう」と思い立ち、過剰なテスト自動化に走るのは逆効果です。
不安定なテストが増えれば、むしろ開発を妨げる結果になりかねません。

そこで大切なのが、まずは小さく始めることです。

小さな自動化からスタートしよう

もしコードに慣れているのであれば、シンプルな機能テストから始めるのがおすすめです。
例えば、Seleniumでのログインテストや、Postmanを使ったAPIのヘルスチェックなど、単純なテストでも十分な効果が得られます。
これらはJenkinsやGitLab CIに組み込むことで、継続的に実行可能です。

一方で、コードが書けなくても問題ありません。
MagicPodのようなノーコード自動化ツールを使うことで、プログラミングなどの特別なスキルがなくても直感的にテストを作成することが可能です。そのためエンジニアでなくても、安定したテスト自動化が実現できます。

大切なのは、自動化そのものが目的ではないということ。
本当の目的は、「できるだけ早い段階で問題を見つけること」です。

そのためにも、まずは重要な機能(クリティカルパス)から着手し、自動化の幅を少しずつ広げていきましょう。

Original article: https://blog.magicpod.com/shift-left-testing-stop-bugs-from-reaching-production

参考文献

• IBM System Science Institute Relative Cost of Fixing Defects
• DevOps Shift Left Testing: A Detailed Guide
• Shift Left Testing Approach and its Benefits | Ultimate Guide
• Best Practices For QA Testing

---