こんにちは、ゆーすけです。
前回は「Ｖ＆Ｖ」ということについて考えてみましたが、今回は「シフトレフト」について考えてみたいと思います。
シフトレフトとは
英語でいうと「shift-Left」となり、直訳すると
「左に動く（動け）！！」
になります
ではこの場合、『なに』を左に動かしていくかというと、品質管理の場合では
『不具合』の検出工程（ピーク）を左に移動させていく、ということになります。
不具合を左工程に移動させるのは分かっているよ！という方も多いと思いますが、ではこの移動させるのは何軸上のことになるのでしょう。
シフトレフトの工程軸とは
「システムテスト、受け入れテストにて不具合検出が多すぎるので、前工程である単体テスト、結合テスト段階で安定性確認、不具合検出を強化していく」
上記はテスト工程におけるシフトレフト例の一つになりますが、これが全てというわけではありません。
シフトレフトは、「要件定義～出荷後を一つの時間軸として、プロジェクトライフサイクル全体」を時間軸とするので、起点としては単体テストではなく要件定義～基本設計段階として考えます。
また単純に工数を前倒しして、後工程を楽にする、という活動は「フロントローディング」と言われるものになるので、使い分けは注意しましょう。
なぜシフトレフトが必要なのか
これは前述のテスト工程例でも触れていますが、プロジェクト後半では、
- 不具合の検出しきれない
- 検出コストおよび修正コストは高くなる
また修正に対する確認コストおよび影響リスクも高くなっていく。
というものが最たる理由であげることができます。
テスト界の第一人者である高橋寿一氏も著書「ソフトウェア品質を高める開発者テスト」にて
–結合テスト、システムテストでは見つからない不具合も多く存在する※検知可能率はものによっては55%程度である
–上流工程で85%以上の不具合が検知できればプロジェクト大きな遅延はなく、出荷後の致命障害はなくなるであろう
ただしこの数字はコーディング～テストだけでは達成不能で、要件定義、システム設計の段階からの取り組みが必要になってくる
と説いています。
◆Rayleighモデル
障害除去を示した品質管理では有名な曲線
不具合ピークが結合の場合、本番環境での潜在不具合も一定数残ってしまいますが、これをシフトレフト（ピークを左に動かす）ことによって本番障害の潜在件数も減らすことができます
※シフトレフトを行った図
最後に
今回シフトレフトについて考えるにあたり、初稿の段階で
- それは全くシフトレフトではない
というありがたい指摘をいただき、あらためて考えの整理を行う機会となりました。
まだまだテスト領域やプロジェクトライフサイクル、ソフトウェアエンジニアリング工程に関して思い込みや思慮不足などがあると思いますが、引き続きこの場をかりて整理・アウトプットを続けていければと思います！
