　前回の記事では、IT分野のエンジニアの視点から「クラウドネイティブ」という考え方とその狙いについて整理し、組み込みソフトウェアに適用する際の端緒を提示しました。今回も引き続き、クラウドネイティブの考え方／支える技術への理解を深めていただければと思います。概念的な話にとどまらないよう“シミュレーション環境と、現実の作業環境を隔てるギャップを埋める”という、具体的な課題を解決することを通して解説を進めていきます。

⇒連載「仮想環境を使ったクラウド時代の組み込み開発のススメ」バックナンバー

シミュレーション環境と実機テスト

　システム開発において、各種テストを、早く／確実に（ミスをしないという意味で）実行することは、開発チームのみならず、顧客にとってもさまざまなメリットがあります。早く／確実なテストは、多くの場合、テスト自動化の推進によって達成可能です。テスト自動化が達成されれば、「Jenkins」などのオートメーションツールの力を借りながら、ソースコード変更の度にテストすることも無理なく繰り返し行えるようになります。

　これは、ISO 9001などの各種マネジメント国際規格で定められているような、理想的な「フィードバックサイクル」を構成できることを示しています。近年は、シミュレーション／エミュレーション環境を使った開発も普及しており、テスト自動化およびオートメーションツールとの組み合わせで、結合テスト／システムテスト（の一部）まで含む、より広範囲な自動化にも寄与しています。

　一方で、多くの開発チームからは「シミュレーション／エミュレーション環境を使ったテストは合理性や効率性を考えれば必要だ。しかし、そこから得た合格結果を盲信はできない。よって、現実の作業環境でのテストと合わせて完成に持っていくべき」という声も聞きます。筆者が属するIT分野でも、スマートフォンアプリの開発では、当たり前のようにエミュレーターを使ってデバッグやテストを行います。しかし、それと合わせて、複数のスマートフォン実機を用意してのテストも適宜実行します（図1）。要件によっては、流通しているほとんどのスマートフォン実機でのテストが求められます。その際は、テストベッド（「AWS Device Farm」など）をクラウドサービス経由で利用して、遠隔で各種テストを行う場合もあります。

図1　スマートフォン向けテストベッドのイメージ（画像は、Android端末テストベッド構築を助けるOSS、DeviceFarmer/stfのGitHubリポジトリより引用）

2つの環境を隔てる2つのギャップ

　このように、シミュレーション環境と現実の作業環境の間にギャップがあることは、経験則的にも理解されていることです。これは、筆者らが研究開発を進めるシミュレーション環境「箱庭」に限定した話ではありません。

　故に、インパクトのある変更を最小限の労力で頻繁かつ予測通りに行うためには、2つの環境で共通して動くようなテスト手法を、先に挙げたフィードバックサイクルの中へ、織り込まなければならないことが分かります。しかしながら「理想のためだけに、それぞれの環境で別々のテスト手法を実装するのは避けたい（できるだけ共通化したい）」とも考えられます。

　筆者らは、これら課題を解決するため、2つの環境を隔てるギャップ要因を整理しました。その上で、以下の2点に着目して解決に当たりました（図2）。

各環境の“可観測性”のギャップ（≒システムの動作が、内界および外界から正確に計測されて、検証に必要な情報が、適宜アウトプットできる性質についての差）
環境同士のギャップ
1. 物理的性質（機械的性質（力学的性質）、熱的性質、電気的性質、磁気的性質（磁性）、光学的性質（光物性）など）のギャップ（≒タイミング同期機構／物理演算エンジンなど、検証に“直接的”に影響を与える部分の差）
2. インフラレイヤー^※1）のギャップ（≒コンピュータ資源／ネットワーク資源など、検証に“間接的”に影響を与える部分の差）

※1）本連載では、コンピュータ資源／ネットワーク資源等の「ROSロボット／IoTシステム全体を支える情報基盤」を、「インフラレイヤー」と呼称する。