はじめに
現在のソフトウェア開発において、開発とQAは密接な関係にあります。
それこそ、手を取り合ってプロジェクトを進めていくのが基本となりつつあります。
しかし、開発の専門性が高いようにQAも専門性が高く、用語や意図がわからない場面は多々あるでしょう。
そんな方のため、用語の解説を行っていくシリーズです。
また、本記事は私の独断と解釈によるまとめですので、一部事実と違う点があるかもしれませんが、その際はご指摘ください。
「シフトレフト」のざっくりとした解説
「シフトレフト」の概要
開発という「作る」という作業に対して、「確認する」という作業をより早い段階から実施することを指します。
この「確認する」という作業は「テスト」(Testing)だけでなく「レビュー」(Checking)なども含みます。
「シフトレフト」の主なメリット
「問題が見つかった時、修正にかかるコストの低減」がシフトレフトの主なメリットです。
「シフトレフト」のお試し方法
概要に記載している通り、レビューを今より早期に実施するだけでも効果があるので、QAを巻き込まなくとも開発チーム内で完結することができます。
チームを動かすのが難しくとも、個人単位なら、いつものレビューの実施前に「ちょっと先に確認させてください」と先輩などの詳しい人へ早めに聞くだけでも効果を発揮します。
「シフトレフト」の詳細な解説
品質関連書籍からの引用
まずは私自身の言葉で説明するよりも正確性を大事に、世に出ている公的な書籍から引用しようと思います。
今回は「シラバス2018対応JSTQBFoundation教科書＆問題集」より引用します。
ソフトウェア開発ライフサイクルのなるべく早い時期にテストすること。
早い段階でテストを実施すればするほど、欠陥の数が少ないため、1つの欠陥が多くのコンポーネントに入り込むことを未然に防ぐことができ、大きなコスト削減につながる。
私も驚いたのですが、手元には何冊かQAの参考書があるのですが、シフトレフトについての記載はこの1冊だけでした。
QAQEよりQCの面が強く、QAの参考書では詳細に語られることが少ないのかもしれません。
何に対して「左」なのか
「シフトレフト」という言葉を聞いて、まずはその字面の意味のわからなさが大きいと思います。
「左に行く」ことはわかると思いますが、何を指して左方向なのかが不明瞭かと思うので、そこから解説します。
古くはウォーターフォールという開発手法が世の代表だった時に生まれました。
ウォーターフォール開発はその名の通り、一方通行で行ったっきりの開発フローです。
図で表すと以下のような流れです。
「ウォーターフォールって言うんだから左から右じゃなくて上から下だろう」「上流工程/下流工程と言うじゃないか」というツッコミは、私も本当にそう思います。
そう思いますが、シフトレフトと言うので左から右に描き直しました。
この図で見ればわかりますが、元の「テスト」のフェーズよりも左側でもテストを実施する、ということで「シフトレフト」と呼ばれています。
「シフトレフト」の詳細なメリット
ざっくりの方で「問題が見つかった時、修正にかかるコストの低減」と書きましたが、
そうなる理由は、開発フローのより早期にバグを発見できた方が、
バグの修正にかかるコストは基本的に低くなるためです。
バグの発見タイミングによるコストのかかり方は、引用を見るのが早いでしょう。
これはIPAの出している先進的な設計・検証技術の適用事例報告書 2015 年度版PDFの画像です。
もしかしたら見たことがある方もいらっしゃるかもしれません。
要求仕様で誤りがあったことを見逃して、そのままリリースまで行ってしまった場合、一般的に修正にかかるコストは200倍になると言われています。
テストまでだったとしても20倍になります。
設計段階で気付いたら、要求仕様のミーティングの再設定と他設計の変更程度で済みますが、
遅くなるにつれて、それまでの作成にかけた工数が上乗せされて行きます。
納入で一気に跳ね上がるのは、
・不具合原因の調査
・修正までの間の一時対応の策定や実行
・修正を入れた再テスト
・修正の再リリース
と、リリースまでのコストがもう一度かかりつつ、
そもそも不具合がどこにあるのかの調査コストもさらにかかってくるからです。
そして画像に書いてある通り、200倍は修正コストに限った話です。
納入まで行ってしまった場合、修正コスト以外にも、
・お客様からの問い合わせを受けるサポートセンター等のフロント部門
・迷惑をかけたお客様への謝罪
・ものによっては会社の信用失墜
など、関わってくる人や領域、作業が莫大になりますので、
実質は200倍には留まらないでしょう。
そして、人や領域、作業が増え、通常とは違う手順を踏むということは、
それだけ別の問題や、新たなオペレーションミスを誘発することになり、
より延焼していく可能性すらあります。
ですので、同じバグであっても、見つけられるならより早期である方がよいのです。
「シフトレフト」の導入方法
別記事で他とセットで詳細を記載しようと思っていますが、
シフトレフトとは導入しようと思って導入するものではありません。
品質向上のため、不具合をより発見しやすくするため、修正コストを下げるため、
そういった問題を解決するための手段の一つだからです。
何でもかんでも「シフトレフトだ！」で解決できるわけではないということまでを、
本記事ではご理解いただければ幸いです。
「シフトレフト」に纏わる小噺
「シフトレフトテスト」とも言います。
おそらくは、この言葉が生まれた時は「テストフェーズをシフトレフトする」ということで、「シフトレフトテスト」と言われたのではないでしょうか。
ただ、こう言ってしまうと「テスト(Testing)だけをシフトレフトすればOK」と
思われてしまいそうなので個人的には使いたくないです。
先述の通り「問題を解決するため、早期に実施する」ということが真髄ですので、
「シフトレフト」すべき対象はテスト(Testing)に限りません。
その他にも「テストって付いてるから、QAや品質管理側が全部やるんでしょ」と、
誤解を生みかねないため、やはり使いたくないです。