シフトレフトとは、後工程で発見される問題を前工程で発見するための取り組みのことです。これにより手戻りを減らすことができます。
最近エンジニアの世界でシフトレフトは揺るぎない正しさがあると信じられていると感じます。
しかしシフトレフトが必ずしも正しいとは言えません。
1つ極端な例を上げてみると「すべてのバグを検出するコンパイラを開発しました。ただしコンパイルに100年かかります。」
これはとても価値のある発明ですが、皆さんの日常の開発では役に立たないでしょう。
このように前工程で検出したとしてもコストがリターンに見合わなければいけません。
次は、もう少し現実的な例で考えてみましょう。
「コンパイル時にある種類のバグを絶対に防ぐことがてきます。ただしコンパイル時間は3分増えます。」
「Xアーキテクチャにして頻出する実装に必ず10行のコードを追加することで、ある種類のバグを絶対に防ぐことができます。」
これらはシフトレフトの方が良いと思うかもしれません。しかし、実際に見つけられるバグが1年に1度しか発生せず、修正コストは10分で、事業への影響は軽微だとしたらどうでしょうか？
そのときはビルドを3分早くして、浮いた時間で多くの機能をリリースする or 10行のコードを減らしてコードのメンテナンス性を上げた方が良いかもしれません。もしバグが発生してもすぐに直してリリースします。またより低コストな代替手段(lintやテスト)があるなら、そちらにシフトライトして対応してもいいでしょう。
このときの問題は、バグを絶対に防ぐことに捕らわれて、現実的なコストとリターンを検証しないことです。
このような問題のあるシフトレフトが1つ2つと積み上がると、正しいことをしている気持ちのままじわじわと生産性を蝕んでいきます。100個積み上がれば生産性は半分になってもおかしくはありません。そして生産性が落ちる前の時間があれば、より重大なバグを防くことに時間を使えたことでしょう。
品質とスピードは両立しますが、コストも忘れてはいけません。