組み込みソフトウェア開発特有の難しさとはなにか　コンテナニーズとサーバーレスでソリューションを提供するガイオ・テクノロジー

自己紹介

藤原康弘氏：最初に自己紹介をいたします。藤原康弘と申します。役割は、エンジニアリング業務のテクニカルリードです。自動車のOEMを中心にやっています。また、本セッションでお話しする、モダン開発ネイティブな、製品開発に向けたプロジェクトのプロジェクトマネージャーを担当しています。

専門の領域は、制御開発のプロセスや検証手法です。今はDXに関わる領域も専門としています。

2つの柱でビジネスをしているガイオ・テクノロジー株式会社

あまり弊社をご存じない方もいると思うので、簡単に会社説明をいたします。弊社は、ツールビジネスとエンジニアリングサービスビジネスの2つの柱でビジネスを行っています。ソフトウェアテストに向けた主なツールは「カバレッジマスター」と「QTE」です。ほかに、デザイン設計系のツールとして「Safilia」と「Seculia」が主なツールとなっています。

エンジニアリングサービスとしては、ソフトウェアの品質の高度化支援、モデルベース開発支援、セーフティ／セキュリティ支援などを行っています。

本日のアジェンダですが、背景、弊社の取り組み、まとめ、QAというかたちで進めます。

モダンアプリケーション開発でよく言われていること

まず背景をお話しします。モダンアプリケーション開発は、一般的に手段の話が非常に多くなっています。

これは書籍や、Web上には手段の話が非常によく出ています。例えば、「AWSやAzureなどのいわゆるクラウドを使いましょう」「クラウドネイティブなアプリケーションを作ることが、モダンアプリケーション開発ですよ」という話がよく出ています。

次にアジャイル／スクラムですね。「アジャイルに小さなチームでイテレーティブに開発を進めていきましょう」「スクラムマスターを置いてスクラムをどんどん進めていきましょう」という話が非常に多いと思います。

そして、DevOpsですね。「開発・運用を一体的に行って、製品を常にデプロイしてリリースし続けるという開発をやりましょう」という話も多いと思います。

一般的には、アジャイルで小さなチームでイテレーティブに開発を進めながら、DevOpsという、開発と運用を一体にした体制で、常に小さく変更を加えて、デプロイして、リリースして、お客さま使っていただくという使い方が採用されているのかなと考えています。

モダンアプリケーション開発の目的と活動とは何か

そもそもWebアプリ/Webサービス開発におけるモダンアプリケーション開発の目的と、活動は何か？　という話をすると、目的の1つは継続的なユーザーエクスペリエンスの向上です。そのために、ユーザーフィードバックの早期化と、素早いレスポンスを得られるようにしていきましょうというところがあります。

もう1つは、可用性とコストの両立です。これを実現するために、「動的なスケールアップ」「スケールアウト」「自動復旧」があります。

例えばオンラインショッピングでセールをやって、一気にユーザー数が増えたとしても、自動的にその増加したユーザーをピークとして、システムをスケールアップしたり、反対に閑散期は、動かすバックエンドのシステムをスケールアウトして、とにかく運用コストを下げます。

ほかにも、動画視聴サービスでピークが来た時に、サーバーが止まったり、サーバーが壊れてしまったりすると損失につながってしまうので、自動復旧をさせて、ビジネスが継続するようにしましょうというところが目指されています。

最後に、停滞しない継続的なイノベーションの実現ということで、継続的に開発手法をアップデートしていきましょうというのがあります。5年、10年同じやり方をやるのではなく、継続的にどんどん良いものを取り入れて変えていく中で、新しいイノベーションが生まれるということです。

多くの企業が取り組んでいるCI/CDとクラウド利用

すでに多くの企業が、これらのものを組み込みソフトウェア開発へ適用しています。

例えばよくあるのが、CI/CDです。パイプラインですべての業務をつなげて、いかに業務をスムーズに流せるかというところです。

コーディングして、それをコミット、またはプルリクエストをして、テストして、ビルドして、ビルドが通って、パッキングが必要なものをパッキングしたら本番環境にデプロイして、そしてユーザーにリリースします。これをなるべく止めずに、一気通貫でやりましょうというのがCI/CDです。

また、クラウドも多く利用されています。自動車メーカーさんも、何年か前はクラウド利用に難色を示すことが多かったのですが、最近いろいろなツールベンダーさんとお話しすると、全社的には使えなくても、部門ごとではクラウドをけっこう使い始めているという話がよく出てきて、そのうちクラウドが主流になってくるのではないかという話をよくしています。

ソフトウェア開発特有の難しさ

しかし、組み込みソフトウェア開発特有の難しさも実はあります。組み込みソフトウェア開発特有の難しさとして、仕様確定に時間がかかるとか、会社間をまたがる製品開発プロセスとか、ハードウェアが存在するというところとか、安心／安全な品質が求められるというところがやはりあります。

例えば、WebアプリケーションやWebサービス開発のフローを見てみると、（スライドを示して）エンジニアがコーディングをして、コーディングルールをチェックして、ユニットテストをして、それをバージョンのコントロールシステムにプッシュしたりプルリクエストをしたりして、ビルドが走ります。

そうすると自動テストが行われて、そこを通れば、次はマニュアルのテストがあります。そのあと、ファイナルテストをして、デプロイして運用に持っていきます。

その流れの中では、いろいろなコンテナが使われています。テストをするためにテスト環境へデプロイして、その後、ファイナルテストでステージング用の環境へデプロイして、最後にプロダクション環境にデプロイします。

エンジニアと並行して、QAの専門のエンジニアがテストしたり、テストケースのレビューをしたり、テスト環境そのものを自動化したり、作ったりしています。Webアプリ開発/Webサービス開発の特徴としては1社でこの中が完結しているパターンです。（スライドを示して）ここの中のチームメンバーは数人で、1社で完結している、かつ非常に少ない人数で行われている場合が多いです。

一方、例えば自動車の制御ソフトの開発においては、エンジニアがいろいろと実験をしながら仕様を詰めて検討していきます。仕様ができたらコーディングやモデリングをして、ガイドラインをチェックして、ユニットテストをして、バリデーションをします。当然そこには自分たちだけではできない領域もあるので、サプライヤーのエンジニアや、同じ会社内の異なるドメインを担当する方の要求、仕様、調整が入ります。

プッシュしたあとは、インテグレーションをしないといけないのですが、実はサプライヤーさんが調査や実験などをやっている部分もあって、その中で納品されたものをインテグレーションする場合もあります。

インテグレーションをしたら、インテグレーションテストをして、モデルで解決している場合はオートコードをします。そのあとに、Back To Back Testをして、ビルドをして、Back To Back Testをまた実機でやって、最後に実機でインテグレーションテストをして、リリースをします。このように、1社だけで完結せず複数の関係者が絡んでくるという点や、使うツールや手法も何種類もあり、一概には簡単にいかないところがあります。

もう1つの例ですが、こちらはサプライヤーの場合ですね。サプライヤーがいて、顧客であるOEMがいます。サプライヤーの中にも、さらにソフトウェアやプラットフォームやBSWを提供してもらうサプライヤーがいるというかたちで、（スライドを示して）こういう場合もあります。

エンジニアがコーディング、ユニットテスト、バリデーションをします。サプライヤーからデリバリーされた納品物を含めインテグレーションして、ビルドして、インテグレーションテストを実機でやってリリースをします。そしてカスタマーにHexが展開されます。

なので、明確なスタイルは確立していません。一意にこういう手法を取ればうまくいくであろうというスタイルは、実はまだぜんぜん確立していなくて、試行錯誤されている状況かなと思っています。

開発プロセス改善と組み込みソフトウェア開発環境の2軸で支援

そこに関して、弊社はどうアプローチしているか。開発プロセスの適用という部分は、非常に複雑な会社間のつながりでやっています。サプライチェーンや、文化がさまざまあるので、すぐに適用するのは難しい。なので、ここはエンジニアリングサービスで、お客さまとともに作り上げていくことを考えています。

組み込みソフトウェア開発環境の適用に関して、モダンアプリケーション開発に対応したツールやサービスで貢献をしていきます。

既にモダンアプリケーション開発手法の適用を進めているお客さまから、テストに対する相談もあります。

例えば環境面や運用やテスト実行に絡むところだけを見ると、テスト環境のメンテナンスに工数が取れないとか。複数のツールを組み合わせるので、ツールチェーンが複雑でメンテナンスが難しいとか。テスト自動化環境の構築に専門的な知識が必要なので、なかなか人材がいないとか。

実際に運用してみると、テストケースが増加するとか、テスト対象増加によって自動で流す量を増やせば増やすほど、1回のテストに時間がかかってしまう、という相談をよく受けています。

これに対する弊社としての取り組みとしては、ソリューションをどう提供していくかというところですが、簡単に使える・多くの企業で使える・いろいろなサービスと繋がる・世界のどこからでも使えるという基本コンセプトを基に新しい取り組みを進めています。

ソリューションを構成する2つのキーテクノロジー

新しい取り組みを実現するためのキーテクノロジーが3つあります。1つはコンテナです。（スライドを示して）上が従来のハイパーバイザー型の仮想化技術です。ハードの上にホストOSがいて、ハイパーバイザーがいて、さらにゲストOSがいて、その上に各種ミドルウェアやアプリケーション類があります。

対してコンテナ型の仮想化は、ハードがいて、OSがいて、その中にコンテナツールがいて、その上にアプリケーションがあります。なので、あくまでもOSのリソースの1個としてこの上のコンテナは動作します。

コンテナイメージを準備することでミドルウェアやアプリケーションのセットアップ作業を不要にしたり、環境の複製が容易になります。

もう1つが、コンテナのオーケストレーションを行う技術です。簡単に説明すると、コンテナオーケストレーションとはコンテナの管理を行うための技術です。

マスターの部分とPodと呼ばれる単位で管理します。Podの中でコンテナをデプロイをして、そのPodとコンテナを管理しています。例えば負荷が増大したとして、自動的にPodがあるCPUの閾値、ここでは例えばCPUの使用率が50パーセントを超えたら、自動的にPodを複製して負荷を分散します。

反対に、閾値以下になって、負荷分散の必要がなくなれば、自動的にPodを縮小してスケールアウトします。ほかにも、Podやコンテナがトラブルで破損したり、機能が停止したりした時は、自動的に復旧させる機能を持っています。

もう1つはサーバーレスです。従来は、どちらかというとユーザーが使う側にいて、インフラ構築側にインフラエンジニアがいてハードウェアの調達・インフラ設計からデータセンターでの環境セットアップや運用というパターンが多かったですが、サーバーレスの場合、ハードウェア部分はクラウドサービスプロバイダーが提供するリソースを利用することになります。

インフラエンジニアは、そのリソースを使いながらアプリケーションやシステムを組み、オペレーションを行います。

新しいソフトウェアテスト環境の提案

弊社は、Software Testing Platform Conceptというかたちで進めています。クラウド上のサービスとして「カバレッジマスター」や「Caseplayer2」や「PROMPT」や「QTE」など弊社のツールを提供します。利用方法の一つとしてユーザーは、目的に応じてフロントエンドツールやWebアプリケーションなどで、Software Testing Platform へリクエストを投げます。Software Testing Platform はリクエストの中から必要な処理を行い、処理結果をユーザーへ返します。

また、Software Testing Platform へリクエストをCLIで自動化する場合、自社で既に利用しているソフトウェアホスティングサービス、例えばGitHub社のGitHubやアトラシアン社のBitbucketにプルリクエストをかけることで、バージョン管理システム経由でCI/CDパイプラインが動きます。その先のテストの部分は、弊社が提供するクラウドのサービスとつなげます。

反対にオンプレミスで、クラウドではなくて自社のサーバーでバージョン管理環境を運用している場合も、ユーザーはプルリクエストを投げて、データセンターから弊社が提供するクラウドにつながって、テストに関する処理を行い結果を返すというコンセプトとなっています。

アーキテクチャの紹介

アーキテクチャを紹介します。まずユーザー側ですね。ユーザー側にバージョン管理ツールや要求管理ツール、テストマネジメントツールがあるとして、バージョン管理ツールやテストマネジメントツールからSoftware Testing Platform へ直接リクエストを投げたり、パイプラインツール経由でリクエストを投げたりします。

弊社が提供するフロントエンドツールを利用するパターンも想定します。

認証処理が通るとストレージに入力情報となるファイルを保存します。その入力情報を使ってテスト処理の管理ツールが必要な処理のコンテナをデプロイします。例えばテスト生成を行いたい場合は、テスト生成のコンテナをデプロイします。

テスト実行の場合は、テスト実行のコンテナをデプロイします。同様に、レポートだけを実行したい場合はレポート生成のコンテナをデプロイします。一気通貫で、全部の処理を流したい場合は全部のコンテナを作って流して、その処理結果を返します。

テストケースの作成は先ほどの処理とは独立したサービスとして提供することを考えています。例えばテスト設計としてテストケースだけを作りたい場合を想定します。

この環境は、弊社で管理をしていて、弊社の中のパイプラインを使ってデプロイし、常に最新の環境を提供するかたちを考えています。