シフトレフトとは

シフトレフトとは何か - テストを開発の上流に前倒しする考え方

シフトレフトとは、ソフトウェア開発ライフサイクルの左側、つまり要件定義や設計といった上流工程に、テストや品質活動を前倒しして実施する考え方です。従来の開発では、テストは実装が終わった後工程でおこなうものとされてきました。シフトレフトは、この順序を見直し、欠陥を早い段階で見つけることを狙います。

国際的なテスト技術者資格であるISTQB（International Software Testing Qualifications Board）のシラバスでは、テストの7原則の一つとして「早期テストの原則」が示されています。静的テストと動的テストの両方を開発ライフサイクルの早い段階から始めることで、欠陥の修正コストを抑えられるという考え方です。この原則が、シフトレフトという発想の土台になっています。

誤解しやすいのは、シフトレフトが「テストをやめる」ことでも「上流だけで品質を保証しきる」ことでもない点です。テストという活動全体の開始時期を早め、後工程で見つかる欠陥の絶対数を減らすことが本来の目的になります。

組み込み開発でシフトレフトが難しい理由 - ハードウェアと不可分な検証対象

IT系のシステム開発であれば、シフトレフトは比較的実行しやすい取り組みです。クラウド環境やコンテナを用意すれば、設計段階のコードでもある程度動かして検証できるからです。

組み込み開発では、事情が異なります。テスト対象のソフトウェアは、センサやモータ、通信インタフェースといったハードウェアと不可分に結びついています（「組み込みソフトと汎用ソフトの違い」参照）。ソフトウェアだけを取り出して動かしても、実際の挙動を確認したことにはなりません。

さらに、試作基板が完成するまでソフトウェアを実機で動かせないという制約があります（「組み込み開発における制約事項」参照）。ITシステムのように「環境さえ用意すれば動く」わけではなく、ハードウェアの完成というマイルストーンに検証開始が縛られます。ここが、組み込み開発でシフトレフトを語るときに最初に押さえるべき前提です。

この制約は、品質保証の進め方そのものに影響します。ITシステムであれば設計変更のたびに繰り返しテストを回せますが、組み込み開発では試作基板の台数や入手性の制約から、実機を使ったテストの回数そのものが限られます。だからこそ、実機に頼らずに前倒しできる作業を切り分ける意味が大きくなります。

試作基板の入手には、数週間から数か月かかることも珍しくありません。この期間をレビューや静的解析といった前倒し可能な作業に充てることが、組み込み開発でシフトレフトを実践する際の現実的な出発点になります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

前倒しできるもの - テスト設計・レビュー・静的解析・要求の検証

試作基板がなくても、前倒しできる作業は数多くあります。代表的な4つを整理します。

• テスト設計：要求仕様や設計書をもとに、テストケースや確認観点をあらかじめ作成する作業です。実機がなくても着手できます（「V字モデルで学ぶテスト工程と品質保証」参照）
• レビュー：要求仕様書・設計書・ソースコードを人の目で確認する作業です。レビューの手法そのものを見直すことで、精度をさらに高められます（「テスト設計レビューの基礎知識」参照）
• 静的解析：ソースコードをツールで機械的に検査し、コーディング規約違反や潜在的な欠陥を検出する手法です。MISRA Cのような規約への準拠確認にも使われ、プログラムを実行せずに欠陥を洗い出せます
• 要求の検証：要求仕様そのものに矛盾や曖昧さがないかを確認する作業です。要求段階の誤りほど後工程での修正コストが膨らむため、早期の検証効果が大きくなります

これら4つの活動は、開発の初期段階から並行して進められます。特に要求の検証とテスト設計は表裏一体の関係にあり、テストケースを作成する過程で要求の矛盾や抜けに気づくことも少なくありません。

どの機能から着手するかは、故障時の影響度や過去の不具合傾向をもとに優先順位を付けると効果的です。すべての機能を均等に前倒しする必要はありません。

これらはいずれも、実機の有無に関係なく着手できる活動です。組み込み開発でシフトレフトを進める際は、まずこの領域から手を付けるのが現実的です。

実機がないと確認できないもの - タイミング・電気的挙動・ノイズ・通信の実挙動

一方で、どれだけレビューや静的解析を尽くしても、実機でなければ確認できない項目が残ります。代表的な4つを整理します。

• タイミング：割り込み応答やタスクの実行周期は、実際のCPUクロックとプログラムの組み合わせによってはじめて数値が決まります
• 電気的挙動：電源電圧の変動やGPIO信号の波形は、回路とソフトウェアの相互作用で決まり、シミュレーション上の数値だけでは判断できません
• ノイズへの耐性：実際の通信環境で発生するノイズを模擬した状態で、ソフトウェアが誤動作しないかを確認する必要があります
• 通信の実挙動：通信相手の実機やプロトコルスタックとの組み合わせで生じるタイミングのずれや再送処理は、設計書の記述だけでは想定しきれません

これらは、机上の設計や解析だけでは再現できず、実行してはじめて表れる性質を持っています。だからこそ、実機での動的な検証が欠かせません。

ある事例では、静的解析や従来のテスト手法では検出できなかった不具合が、動的テストではじめて明らかになっています。マルチスレッド環境で生じるタイミング依存の不具合は、1000時間以上の実機テストのなかでわずか3回しか発生しない、きわめてまれな事象でした。この種の問題は、実機を使った動的な検証なしには発見できません。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

実機がなくても動的検証を始める方法 - エミュレーションという選択肢

実機がなければ、動的な検証を完全に諦めるしかないのでしょうか。そうとは限りません。試作基板そのものがなくても、接続機器やセンサ、通信相手の動作を模擬する装置やソフトウェアを使うことで、ソフトウェア側の動作を先に確認する手段があります。

このような、接続先の機器やセンサ・通信をエミュレートして代用する手法は、HILS（Hardware In the Loop Simulation）などの名称で、産業機器や医療機器、自動車などの制御開発で広く使われてきました。制御対象や通信相手を模擬環境に置き換えることで、実機の完成を待たずにコントローラ側のソフトウェアを動かし、検証を始められます（「エミュレータ/シミュレータ/実機の使い分け」参照）。

模擬の対象は、通信プロトコルスタックの応答、センサの出力波形、外部機器から返るステータスなど多岐にわたります。何を模擬すれば確認したい振る舞いを引き出せるかを見極めることが、有効に活用する鍵になります。

こうした手段を使えば、試作基板の完成前でも、通信シーケンスや異常系の応答といった動的な確認に着手できます。得られた知見をテストケースとして蓄積しておけば、実機が完成した後のテスト工程もスムーズに進められます。

ただし、模擬環境はあくまで模擬にすぎません。実機の特性を完全に再現しているわけではないため、エミュレーションで確認できた結果が、そのまま実機でも成立するとは限りません。最終確認としての実機テストは、この後の工程でも欠かせません。

シフトレフトの限界 - 後工程を不要にするものではない

ここまで見てきたシフトレフトは、あくまで前倒しできる作業を早める考え方であり、後工程のテストを不要にするものではありません。

実行環境でしか見えない問題は、必ず残ります。実際のハードウェア上で、実際の通信相手・実際のノイズ環境・実際の温度条件のもとで動かしてはじめてわかる不具合が存在するからです。シフトレフトを導入しても、実機テストの工数をゼロにできるわけではありません。

温度条件やEMC（電磁両立性）への適合を確認する試験も、実機がなければ実施できません。これらは、シフトレフトの取り組みとは別に、後工程で必ず計画しておく必要があります。

シフトレフトの正しい狙いは、前工程と後工程の両方で欠陥を見つける機会を増やし、後工程で見つかる欠陥の数そのものを減らすことです。上流での前倒しと、実機での最終確認は、どちらか一方を選ぶものではなく、両方を組み合わせてはじめて機能します。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

まとめ

シフトレフトとは、テストや品質活動を開発の上流に前倒しする考え方です。組み込み開発では、ハードウェアと不可分な検証対象という制約があるため、テスト設計・レビュー・静的解析・要求の検証から前倒しを始めるのが現実的です。実機でしか分からない挙動は必ず残るため、後工程の実機テストと組み合わせて運用することが重要です。