テクマトリックス株式会社の会田です。

アジャイル開発やDevOps、セキュリティ脆弱性検証などでよく「シフトレフト（Shift-Left）」という用語を目にします。恥ずかしながら、このシフトレフトという考え方が生まれた経緯をはっきりとは知りませんでした。

そこで、今回はシフトレフトがいつ・誰によって言われ始めたのかを調べてみました。※あくまでも私個人の解釈です。

シフトレフトの考え方は2001年に生まれた

1974年から2014年まで発行されていた「Dr. Dobb’s Journal」へ2001年9月1日に投稿された記事があります。Larry Smith氏が書いた”Shift-Left Testing” と題された記事がシフトレフトの始まりとされています。

By combining development and quality assurance earlier and more deeply in your project plan, you can expand your testing program and reduce manpower and equipment needs.

Larry Smith, ”Shift-Left Testing”, Dr. Dobb’s, https://www.drdobbs.com/shift-left-testing/184404768, (閲覧日: 2022-06-29)

意訳：
シフトレフトテストとは、品質保証 (QA) とソフトウェアプロジェクトの開発部分を統合するためのより良い方法を指します。これら2つの機能をより低い管理レベルでリンクすることで、テストプログラムを拡張しながら、必要な人員や機器を大幅に削減できます。

記事 ”Shift-Left Testing” の要約

Larry氏が直面した問題「QAが活用できていない」

Larry氏は、Tru64 UNIX（64ビットUNIX）の開発において直面した、開発とテストが分担されたウォーターフォール型の開発プロセスの問題点に言及し、その解決方法として実施したことをシフトレフトテストとして記載しています。

なお、記事ではウォーターフォールとは明記されていません。しかし、2001年はアジャイル・ソフトウェア開発宣言文が発表された年であり、エンタープライズな領域ではまだまだウォーターフォールが主な開発手法であったと推測します。

Larry氏がどのような問題に直面したかと言うと…

• QAの活動が回帰テストに限定されており、パフォーマンスが悪い。
• QAのテストが手動で行われており、効率が悪い。
• QAが開発の後に開始されるため、何らかの理由で開発が遅延した場合、QAが遅れる・またはスキップされる。
• QAのバグ報告は開発ではなくマネージャに対して強制され、顧客が報告したバグと開発で検出されたバグのどちらも優先される。
• 上記により、QAのテスト需要が高まり、QAがボトルネックになる。

QAのリソースを有効活用できていないことが問題の根底にあるようです。

Larry氏の解決策「QAを早期に巻き込む」

Larry氏は解決策を講じます。

Involve QA early. Well, okay, this one is motherhood and apple pie, right? Yes, in theory. But in practice it isn’t. Too often, testing issues fall by the wayside. QA is too often seen as overhead and not part of the development process. I’ve worked in shops where the relationship between the two sides was actually adversarial, as if it was part of QA’s job to keep from shipping the product. That is simply wrong.

Larry Smith, ”Shift-Left Testing”, Dr. Dobb’s, https://www.drdobbs.com/shift-left-testing/184404768, (閲覧日: 2022-06-29)

意訳：
QAを早期に巻き込む。ごもっともだとは思うけど、実際はそうではありません。テストの問題が脇に追いやられてしまうことがあまりにも多い。QAはオーバーヘッドと見なされることが多く、開発プロセスの一部であるとは認識されていません。私は、製品を出荷しないことがQAの仕事の一部であるかのように、両者の関係が実際には敵対的である場所で働いたことがあります。それは単純に間違っている。
（ちなみに、"this one is motherhood and apple pie" は、そりゃそうだよね？（ごもっともですよね）という意味の言い回しのようです。みんなが好きなものの比喩表現とのこと。日本だったら、"おばあちゃんの焼きおにぎり"とかですかね…。英語は難しいですね。）

どうすればQAが効果的かつ効率的に機能するかが記事には書かれています。粒度がまちまちですが、気になったものをピックアップします。

• 専門的なタスクをこなすQAを尊敬し、大切にすること。そうしなければ、誰もQAのキャリアを歩もうとしない。
• 開発チームの中に”できる”QAがいることを開発者に知ってもらう。
  • QAが開発の会議に参加し、開発の人を知る。
  • 開発者が仕様を書くとき、QAは並行してテスト仕様を書く。コーディングが始まったら、テストのコーディングを始める。
• 製品コードにテストが容易になるためのコードを入れる（プログラムの実行内容や状態を示すログを仕込む）
• 開発者のその場限りのテストコードを拾い上げ、QAが継続的に利用できるコードをつくる
• 検証環境のダウンタイムを利用してテストし、開発者に直接フィードバックする

QAのリソースを有効活用するためには、「QAが開発に参加する」ことが必要だと考えたわけですね。開発者から見てもチームにすぐに相談のできるQAがいるのは大変心強いですし、QAが活躍するだけではなく、開発者が開発に集中するためにとても良いアプローチだと感じました。

記事では、テスト自動化についても書かれています。この文章だけ熱量が高いです。

And, finally — automate, automate, automate! No test should ever require any human judgment to run to completion.

Larry Smith, ”Shift-Left Testing”, Dr. Dobb’s, https://www.drdobbs.com/shift-left-testing/184404768, (閲覧日: 2022-06-29)

意訳：
そして最後に、自動化、自動化、自動化！ いかなるテストも、完了するまで人間の判断を必要としません。

Larry氏の取り組みの成果

For most base levels, therefore, I could reduce my QA hardware needs by at least 75 percent (a three-node cluster and single system down to a single system) because I had already run the tests in both single system and cluster systems 10 to 20 times

Larry Smith, ”Shift-Left Testing”, Dr. Dobb’s, https://www.drdobbs.com/shift-left-testing/184404768, (閲覧日: 2022-06-29)

意訳：
したがって、ほとんどの基本レベルでは、単一システムとクラスタシステムの両方でテストを10から20回実行しているため、QAハードウェアのニーズを少なくとも75% (3ノードクラスタと単一システムを単一システムに) 減らすことができました。
※記事中には、基本レベル（base level）という単語が多く登場します。ベースライン、リリースのために一通りの開発を終えたソフトウェア/ソースコードという意味で理解しました。

具体的な削減コストは明記されていませんが、これらの取り組みにより、QAが利用する検証用ハードウェアの利用時間（または回数）を75%ほど削減できたと記載されています。開発と並行してテストを実施しているため、本番相当の環境でのテストを大幅に減らすことができたようです。

Larry氏は、このQAが開発に参加するアプローチのことを、Shift-Left Testing と呼びました。これがシフトレフトの言葉の起源です。

”Shift-Left Testing”を読んでみて、さらにその後

シフトレフトは、QAが開発と密接に関係することで、より効果的なテストを実施できる仕組みづくりを主眼として置いていると感じました。QAリソースのパフォーマンスを最大化するためのものという理解です。

また、記事を読む限りでは、シフトレフトの概念は線形のプロセス（ウォーターフォール）を前提に語られており、反復型（スパイラル型）の場合はどうするんだろう？という疑問が湧きました。結論から言うと、アジャイルやDevOpsに適用したシフトレフトが提唱されていました。どんどん派生しますね。

この記事を読んだ後、Donald Firesmith氏が書いた "Four Types of Shift Left Testing"を見つけたので軽く読みました。詳しくは触れませんが、アジャイルやDevOps向けの4つの異なるシフトレフトが提唱されています。興味のあるかたはぜひ読んで感想をお聞かせください。

今回、”Shift-Left Testing”を詳しく読めたことで、シフトレフトが誕生した背景について知ることができました。シフトレフトは単純な「早くテストをやろう！」というスローガンなのではなく、「QAを開発に巻き込み、QAのパフォーマンスを最大化する」という効果を狙ったことがわかったことは大きな収穫でした。

当たり前ですが、良く聞く開発手法やアプローチはそれが誕生した背景をきちんと調べることが大切ですね。