Shift-Leftとは?
shift-leftとは、テスト、品質チェック、フィードバックといった活動を、開発プロセスのより早い段階 (より左) - 問題がより安く、より簡単に修正できる場所 - に移す実践です。
デリバリーのプロセスが、アイデアから本番へと左から右へ流れていくと想像してください。歴史的に、テストやその他のチェックは終盤近く、ずっと右の方で行われていました。shift-leftはそれらを前倒しし、欠陥を高くつく遅い段階ではなく、それが持ち込まれた場所の近くで捕捉します。
中核となる考え方
shift-leftとは、品質の作業を先送りするのではなく、できるだけ早く行うことを意味します。開発が終わってからテストするのではなく、最初から継続的にテストする。最終ゲートで品質をチェックするのではなく、全工程を通じて品質を作り込む。その比喩が、これらの活動をタイムラインの左に動かすということです。
なぜ早い方が安上がりなのか
欠陥を修正するコストは、それが見つかるのが遅いほど急激に上昇します。コードを書いているときに捕捉されたバグは些細なものですが、同じバグが本番で見つかると高くつき、損害をもたらしかねません。フィードバックを前倒しすることでこの曲線を活用し、問題が最も安く簡単に対処できるうちに捕捉します。
何が左に移るのか
- 開発と並行して書かれ、実行されるテスト。
- あらゆる変更に対するcode reviewと静的解析。
- CIでのパフォーマンスチェックと統合チェック。
- pipelineの早い段階でのセキュリティスキャン。
素早いフィードバックが不可欠
shift-leftは、早期のフィードバックが素早い場合にのみ機能します。変更に対してテストやスキャンを実行するのに延々と時間がかかると、開発者は頻繁に実行しなくなり、恩恵は消え去ります。だからこそ、素早く信頼できるCIがこれほど重要なのです。それは頻繁で早期のチェックを、開発者が避ける面倒事ではなく実用的なものにします。
文化の変化でもある
shift-leftは単なるツールではなく、誰が品質の責任を持つかを変えます。コードを壁越しに別のQAフェーズへ投げ渡すのではなく、開発者は構築しながら品質の責任を負います。チーム全体が、問題を早期に捕捉することを最後に誰か他の人がやる仕事ではなく、仕事の一部として扱います。
重要なポイント
- shift-leftは、テストと品質の作業をプロセスのより早い段階に移します。
- 欠陥は、早く捕捉されるほど修正がはるかに安上がりです。
- これは素早いフィードバックに依存し、品質の責任を開発者へと移します。