シフトレフトとシフトライトは、アジャイルDevOps手法の中核となるテストの概念です。この手法では、コードの進化に合わせて小規模なビルドを頻繁にリリースすることで、アプリケーション開発を加速させます。継続的な段階的デリバリーのサイクルの一環として、DevOpsチームは、こうしたダイナミックな環境においてソフトウェアの品質を確保するために、シフトレフトとシフトライトの原則も採用しています。
こうした「シフト」という言葉は抽象的に聞こえるかもしれませんが、このソフトウェア検証アプローチがDevOpsの手法や成果にどのようなメリットをもたらし、ソフトウェアの信頼性を高めるのかについて解説します。
DevOpsにおいて、「シフトレフト」とは何でしょうか？また、「シフトライト」とは何でしょうか？
シフトレフトとシフトライトを理解するには、ソフトウェア開発サイクルを、左から右へと続く連続体、あるいは無限ループとして捉えてみてください。
ループの左側では、チームは本番環境導入前の段階でソフトウェアの計画、開発、テストを行います。ループの左側にある本番環境導入前の段階における主な関心事は、設計基準を満たすソフトウェアを構築することです。
ループの右側でチームがソフトウェアを本番環境にリリースすると、ユーザーに提供されることになります。本番環境における関心事は、ビジネス目標と信頼性基準を満たすソフトウェアを維持することです。
DevOpsにおける「シフトレフト」とは何を意味するのでしょうか？
シフトレフトとは、テスト、品質、およびパフォーマンス評価を、開発プロセスの早い段階、多くの場合コードが記述される前に実施する手法です。
シフトレフトテストは、開発プロセス中に発生するパフォーマンスやその他のデリバリープロセスに影響を与える変更を、チームが予測するのに役立ちます。シフトレフトテストにより、チームはAPI、コンテナ構成、マイクロサービス間の相互作用などを検証します。
なぜシフトレフトが重要なのでしょうか？
機能テストに加え、シフトレフトテストでは、ソフトウェアが顧客要件を満たしているかどうかも確認します。これにより、開発者やステークホルダーは、顧客体験や機能を向上させる可能性のある改善点を特定できるようになります。開発プロセスの早い段階でこれらの変更を行うことで、コードリリース後の変更にかかるコストを削減できます。
その結果、チームがより高品質なソフトウェアをより迅速かつ頻繁に提供するというプレッシャーに直面する中、シフトレフトテストの重要性はますます高まっています。シフトレフトは、ソフトウェアの欠陥が本番環境に到達する前に、開発サイクルの早い段階で検出・対処することで、開発効率を向上させ、コストを削減します。
シフトレフトのメリット
シフトレフトの概念は、ソフトウェア開発およびテストの世界で注目を集めています。開発ライフサイクルの早い段階でテストと品質保証を導入するこのアプローチには、いくつかの大きなメリットがあります。
- 早期のバグ検出：開発プロセスの早い段階でテストを行うことで、チームはバグを特定し、修正が容易でコストもかからない段階で対処することができます。これにより、最終製品の品質が向上するだけでなく、デバッグや手直しに費やす時間とリソースも削減できます。
- 市場投入までの期間の短縮: 「シフトレフト」により、テストは開発のあらゆる段階に組み込まれます。この継続的なテストにより、フィードバックの迅速化と反復サイクルの短縮が可能となり、市場投入までの全体的な期間を大幅に短縮できます。
- 顧客満足度の向上: 開発の初期段階から品質を最優先事項とすることで、「シフトレフト」は、顧客の期待に応える、あるいはそれを上回る製品を提供するのに役立ちます。これにより、顧客満足度とロイヤルティの向上につながります。
- コスト削減: シフトレフトの導入には初期投資が必要となる場合がありますが、手戻りの削減や市場投入までの期間短縮によるコスト削減効果により、その投資はすぐに回収できます。さらに、問題を早期に発見・修正することで、開発の終盤やリリース後の修正に伴う高額なコストを回避することができます。
- 連携の強化: シフトレフトは、プロジェクトの初期段階からテスター、開発者、その他のステークホルダー間の協働を促進します。この協働的なアプローチにより、コミュニケーションの改善、製品に対する共通認識の醸成、そしてより良い最終成果につながります。
DevOpsにおける「シフトライト」とは？
シフトライトとは、本番環境において実環境下でテスト、品質、およびパフォーマンス評価を行う手法です。シフトライトの手法により、本番環境で稼働するアプリケーションが実際のユーザー負荷に耐えつつ、高い品質水準を維持できるようになります。
シフトライトでは、DevOpsチームはビルドされたアプリケーションをテストし、パフォーマンス、回復力、およびソフトウェアの信頼性を確保します。その目的は、開発環境では予測が困難な問題を検出し、是正することにあります。
なぜシフトライトは重要なのでしょうか？
シフトライトにより、チームは開発環境では再現できない実稼働環境を模した環境でコードをテストできます。この手法により、チームは顧客に問題が発生する前にランタイム不具合を捕捉することが可能になります。プロセスの一部を自動化するために、チームはアプリケーション・プログラミング・インターフェース（API）呼び出しを利用できます。また、組織は現場で設定または監視されているコードに対してもシフトライトテストを適用できます。その結果、ユーザー体験に関する懸念により適切に対処できる、より包括的なテストカバレッジが実現します。
シフトレフト・テストと同様に、シフトライト・テストの目的は、「小さな段階で、かつ迅速に失敗を特定すること」です。デプロイ前の環境で早期に問題を特定した方が、本番環境で顧客によって発見された問題よりも解決が容易であるという前提に基づいています。
シフトライトテストは、予期せぬ問題の影響を最小限に抑えるために、開発者が新しいソフトウェア機能を段階的にリリースする「プログレッシブデリバリー」を実践している組織にとって特に有用です。本番環境に近い環境でのテストは、機能を本番運用に投入する準備が整ったと宣言する前の、極めて重要な最終段階となります。
シフトライトのメリット
シフトライトとは、テストを本番環境にまで拡張する概念です。本番環境におけるシステムの監視とテストを通じてインサイトを得て品質を向上させるものであり、いくつかの重要な利点をもたらします。
- 現実的なユーザーテスト: シフトライトのテストでは、実際のユーザーを交えたテストが行われます。ユーザーをプロセスに組み込むことで、ソフトウェア開発者は、ユーザーがソフトウェアとどのようにやり取りするかについて貴重なフィードバックを得ることができます。これにより、将来の改善に向けた情報に基づいた意思決定が可能になります。
- 継続的なフィードバックループ: シフトライト・テストは、開発の全フェーズにわたる継続的な監視と改善を促進します。この反復的なフィードバックループにより、問題が迅速に対処され、製品品質の向上につながります。
- テストカバレッジ: テストを実際の使用シナリオにまで拡大することで、シフトライトテストはより広範なテストカバレッジを実現します。これにより、開発の初期段階では現れない可能性のある問題を特定することができ、より包括的なテストが可能になります。
- 監視機能の強化: 本番環境におけるソフトウェアの挙動を監視することで、そのパフォーマンス、安定性、およびユーザー体験をより明確に把握できます。これにより、チームは異常やパフォーマンスのボトルネックに先手を打って対処できるようになります。
- 顧客中心のアプローチ: シフトライトテストは、ユーザーのニーズと体験を最優先します。実際のユーザーを巻き込むことで、ソフトウェアチームは顧客満足度向上につながるインサイトを得ることができます。
DevOpsについてもっと知りたいですか？
オブザーバビリティとAIOpsを活用して、IT運用の効率化と企業の成長を促進しましょう。当社のDevOps ebook『DevOpsの基礎入門ガイド』をご覧ください。
マイクロサービスアーキテクチャにおいてシフトライトとシフトレフトが重要な理由
ソフトウェアがますますマイクロサービスで構築されるようになるにつれ、シフトレフトとシフトライトの両方のテストの重要性が高まっています。アプリケーションがモノリシックな形で構築・実行されるのではなく、マイクロサービスはランタイムに呼び出される疎結合な機能です。マイクロサービスベースのアプリケーションのパフォーマンスは個々のサービスの応答性に依存するため、シミュレートされた環境でのテストは複雑になります。
シフトレフト・テストにより、チームはシミュレーション環境においてサービス間の相互作用を観察し、コードをデプロイする前に潜在的なパフォーマンスへの影響を検出することができます。
デプロイ時点またはその直前の「シフトライト」テストにより、チームは実環境での負荷を観察し、その影響を測定できます。シフトライトのテストでは通常、機能性、パフォーマンス、耐障害性、およびユーザーエクスペリエンスが対象となります。チームはこうした本番環境でのテストを自動化し、フィードバックを開発者向けの技術仕様に反映させることがよくあります。
シフトレフトおよびシフトライトのテストにより、テスターは問題を特定できるため、チームは修正と改善を並行して進めることができます。アプリケーションの安定性が高まるにつれ、チームはパフォーマンスのテストと最適化を開始できます。特に、シフトレフトとシフトライトは、アジャイルソフトウェア開発において重要な実践となっています。これらは一体となって、DevOpsを特徴づける継続的なフィードバックループの一部を構成しています。
シフトライトテストの種類
シフトライトのアプローチでは、さまざまな種類のテストスイートが活用されることがあります。以下は、チームにとって有用と思われるテストの例です：
- A/Bテスト。Webデザイナーは一般的にこの手法を用います。ユーザーには2つのバージョンのページが表示され、テスターはどちらがより大きな反応を生むかを測定します。チームは実環境でのフィードバックを収集するため、この種のテストを本番環境で行うことがよくあります。
- 合成モニタリング。合成モニタリングは、ソフトウェアツールを使用して、ユーザーがアプリケーションを利用する際にたどる可能性のある経路をエミュレートする、シフトライト・テストの一種です。合成モニタリングを利用すれば、アプリケーションの稼働時間や、一般的なユーザー行動に対するアプリケーションの反応を自動的に追跡できます。スクリプトを使用して、さまざまなシナリオ、地理的な場所、デバイスの種類、その他の変数に対するシミュレートされたユーザー行動を生成します。
- カオスエンジニアリング。カオステストとも呼ばれるカオスエンジニアリングでは、開発者が意図的にエラーを発生させてアプリケーションを「破壊」し、障害からの回復能力を評価します。DevOpsチームやITチームは、アプリケーションがさまざまな種類の負荷にどのように反応するかを正確に把握するために、監視ツールを設定します。チームは、ミッションクリティカルなシステムへの影響を最小限に抑えるため、管理された本番環境でこれらのテストを実施します。
- カナリアリリース。この戦略は、炭鉱夫が有毒ガスを検知するために炭鉱に下ろしたカナリアにちなんで名付けられました。幸いなことに、技術の進歩により、この非人道的な手法は廃れてしまいました。しかし、この用語は、チームが変更をインフラ全体に適用する前に、テストのために少数のインスタンスに対して変更を徐々に展開することを表す言葉として残っています。
- ブルー・グリーン・デプロイメント。ブルー・グリーン・デプロイメントでは、組織は2つのほぼ同一の本番環境を運用し、一方または他方に小さな変更を加える際に、（実ユーザーまたは 合成ユーザーを）その2つの環境間で切り替えます。この手法はダウンタイムを最小限に抑えることができるため、シフトライト手法において重要です。また、最新バージョンに問題が発生した場合に、迅速にロールバックするための仕組みも提供します。
シフトライトツール
シフトライトツールは、コードが本番環境にデプロイされた後の品質検証に重点を置いています。このようなツールは、実環境におけるソフトウェアの挙動を特定・分析し、チームに実際のパフォーマンスに関するインサイトを提供する上で重要です。シフトライトツールの例としては、以下のようなものがあります：
- アプリケーションパフォーマンス監視（APM）ツール：APMツールは、アプリケーションのパフォーマンスに関するメトリクス、ログ、トレースを提供し、チームが問題をより迅速に解決し、アプリケーションをさらに最適化する方法に関するインサイトを得られるようにします
- デジタルエクスペリエンスモニタリング（DEM）ツール：DEMツールは、アプリケーションのユーザーエクスペリエンス（UX）に関するインサイトを提供します。これらのツールには、以下のような機能があります：
- 実ユーザーモニタリング（RUM）：実際のユーザーの行動や体験を分析するための機能です。
- 人工的にシミュレートされたユーザージャーニーを実行し、UX上のボトルネックや不具合をテストするシンセティックモニタリング
- 実際のユーザージャーニーを動画のようにドキュメント化するセッションリプレイ
- セキュリティ監視およびインシデント対応ツール：これらのツールは、セキュリティインシデントの検出、管理、および伝達を支援し、対応プロセスを円滑にします。また、チームが優先順位付けを行う際にも役立ち、ビジネスへの影響が最も大きい脆弱性を最優先に対処できるようにします。
- カオスエンジニアリングツール：これらのツールは、シミュレートされた障害を発生させることで、コードの回復力や、そのような障害に対する対応プロセスの有効性をテストします。これにより、チームはコードの欠陥を把握し、改善の余地を見出すことができます
- 機能フラグ設定ツール：これらのツールは、追加のコードをデプロイすることなく、デプロイメントの特定の機能をオンまたはオフに切り替える機能を提供します。このようなツールは、ユーザー体験の実験や微調整をより多く可能にするため、開発者により高いレベルの制御を提供します。機能フラグ設定は、機能のロールアウトにおける信頼性を高め、デプロイメントが可能な限り最高のユーザー体験を提供することを保証するのに役立ちます。
シフトレフトテストの種類
シフトレフトテストの4つの基本的な種類は以下の通りです：
- 従来のシフトレフトテスト。従来のアプローチは、ユニットテストや統合テストに重点を置いており、通常はAPIやクロスブラウザ互換性が含まれます。このアプローチは、システムレベルの運用テストや受入テストよりも、小さなコード単位のユニットテストに重点を置き、情報を早期かつ頻繁に提供することを重視しています。
- 段階的なシフトレフトテスト。これは、ウォーターフォール型開発アプローチから、複雑なプロジェクトを小さな単位に分割するアプローチへ移行するチームに広く採用されている手法です。このシナリオでは、チームはより小規模で段階的なスケールで、システムレベルの運用テストや受入テストを実施します。段階的なテストは、大規模で複雑なシステムの検証に広く活用されています。
- アジャイル／DevOpsテスト。これは、開発段階における一連の短期間かつ継続的なスプリントです。このアプローチは、運用パフォーマンスに対処することを意図したものではなく、基本的な要件やアーキテクチャへの準拠を検証することを目的としています。
- モデルベースのシフトレフト。モデルベースのテストは、要件定義、アーキテクチャ、設計の各フェーズで生じるエラーを削減することを目的としています。実行可能な要件、アーキテクチャ、設計に対してテストを行います。モデルベースのテストの利点は、他のすべてのテストサイクルを完了した後ではなく、ほぼ即座に開始できる点にあります。
シフトレフト・ツール
-
セキュリティスキャンツール：
これらのツールは、開発サイクルの早い段階で脆弱性を特定することで、セキュリティとDevOpsプロセスの統合を効率化します。これにより、テスト段階まで待つのではなく、開発の過程でコードの安全性を確保できるようになります。
セキュリティスキャンツールの例としては、次のようなものがあります：
- 静的アプリケーションセキュリティテスト（SAST）： SASTツールは、ソースコードを実行せずに分析します。これらは、潜在的なセキュリティ上の問題、コーディング標準への違反、および脆弱性を特定します。リンター（例：JavaScript用のESLint、Python用のpylint）はこのカテゴリに分類されます。
- 動的アプリケーションセキュリティテスト（DAST）： DASTツールは、攻撃をシミュレートすることで、ランタイムアプリケーションをテストします。これらは、攻撃者に悪用される可能性のある脆弱性を特定します。例としては、OWASP ZAPやBurp Suiteなどが挙げられます。
- 依存関係スキャン： これらのツールは、アプリケーションで使用されているサードパーティ製ライブラリや依存関係に脆弱性がないかを確認します。
- シークレット検出： GitGuardianなどのツールは、コードリポジトリをスキャンして、漏洩しているシークレット（APIキーやパスワードなど）を検出し、不注意による漏洩を防ぎます。
- 統合アプリケーションセキュリティテスト（IAST）： IASTツールは、静的解析と動的解析を組み合わせて、包括的なセキュリティカバレッジを提供します。
-
品質管理ツール
これらのツールは、DevOpsパイプライン内のコードが安全であるだけでなく、機能的かつ効果的であることを保証し、検証するのに役立ちます。開発プロセスの早い段階でこうしたツールを導入することで、本番環境に到達する前にエラーや不備を検出し、修正することを確実にすることができます。
- 静的コード解析ツール：SASTツールと同様に、静的コード解析ツールはソースコードを実行せずに評価を行い、コードが準拠しているか、バグがないか、そして全体的に品質が良好であるかを判断します。
- コードレビューツール：コードレビューツールは、コードの変更点を整理して表示し、変更に関する開発者間のコミュニケーションを促進し、コードレビュープロセスの有効性を検証することで、コードレビュープロセスの自動化を支援します。
- 継続的インテグレーション（CI）ツール：CIツールは、GitHub、GitLab、Bitbucketなどの単一のリポジトリに、複数の開発者からのコードを自動的に統合することで、開発者間のコラボレーションを可能にします。
シフトライトとシフトレフトがもたらすアプリケーションセキュリティの恩恵
シフトライトの重要な利点の一つは、アプリケーションセキュリティの向上です。「リポジトリ内や開発環境にある静的なイメージをスキャンするだけでは、本番環境で動作しているアプリケーションを観察した場合に得られるような豊富なインサイトを得ることはできません」と、クラウドにおけるセキュリティの進化に関するDynatraceのレポートは指摘しています。 「例えば、実際にどのライブラリが呼び出されているか、それらがどのように使用されているか、プロセスがインターネットに公開されているか、あるいはプロセスが機密性の高い企業データとやり取りしているかといったことは、把握できません。」
ソフトウェアコンテナの利用拡大は、サイバーセキュリティの側面を複雑化させています。コンテナは内部で実行されているプロセスを隠蔽する可能性があり、攻撃者はエクスプロイト自体をコンテナ化することさえあります。本番環境でのテストは、たとえコンテナの内容が隠蔽されていても、コンテナベースのソフトウェアの挙動を明らかにします。また、組織はシフトライトテストを活用して、Log4Shellのような新たなゼロデイエクスプロイトの存在を検査することも可能です。
シフトレフトの観点からは、開発段階でのセキュリティテストは、脆弱性をライフサイクルの可能な限り早い段階で特定するのに役立ちます。この時期であれば、修正が最も容易だからです。
シフトレフト、シフトライト、それとも両方でしょうか？
組織がマイクロサービスやコンテナといったクラウドネイティブな構成要素を中心にアプリケーションスタックを近代化する中で、ベストプラクティスとして「シフトレフト」と「シフトライト」の両方の戦略を採用することが挙げられます。 シフトレフトのテストは、ソフトウェアの欠陥を減らし、市場投入までの時間を短縮します。シフトライトは、実環境下でのテストを通じて、ソフトウェアが最も重要な場面、つまりユーザーへのサービス提供において確実に機能していることを確認することで、本番環境での信頼性をより確実に保証します。この2つを組み合わせることで、組織は自動化と部門横断的なコミュニケーションを活用した継続的インテグレーション（CI）および継続的デリバリー（CD）という究極の目標に近づくことができます。その結果、より迅速でアジャイルな組織が実現します。
包括的なシフトレフトおよびシフトライトのテストに不可欠な機能は、自動化されたフルスタックのオブザーバビリティとモニタリングです。開発の全フェーズにおいてエンドツーエンドの分析が可能になることで、DevOpsチームはすべてのリクエストとプロセスを監視できます。単一のインターフェースから、広範で複雑なマルチクラウドアプリケーション全体にわたるすべてのサービスを自動的に分析できるため、チームは自動化を実現できます。テスターはスクリプトを使用してデプロイ情報やメタデータをモニタリング環境にプッシュし、ビルド、リビジョン、および構成の変更を追跡することができます。
自動化されたDevOpsプラットフォームが問題の全体像をより深く理解すればするほど、根本原因の特定、関係部署への適切な通知、さらには自己修復措置の実施もより的確に行えるようになります。
組織がテストを「シフトレフト（開発フェーズへの早期導入）」や「シフトライト（本番環境での実施）」に移行している場合でも、あるいは単に本番環境でのパフォーマンスを監視したい場合でも、AIを活用したフルスタック・オブザーバビリティ・ソリューションは、ソフトウェア開発を次のレベルへと引き上げることができます。
シフトレフト（Shift-Left）アプローチには多大なメリットがありますが、業界ではその対極となる興味深いアプローチ、「シフトライト（Shift-Right）」が台頭しています。詳細については、引き続きお読みください。
ご質問がありますか？
Q&Aフォーラムで新しいディスカッションを開始するか、助けを求めてください。
フォーラムへ