見出し画像

NissanConnect の VPAサービスとその変遷

NISSAN NAKAME BLOG | 日産ナカメブログ

こんにちは、日産自動車のエンジニアの塩浦です。今回は、私が担当しているコネクティッドサービスの1つである「Virtual Personal Assistant (VPA)」 というサービスのご紹介と、そのサービスを数年運用する中で起きた変化やそれに対応するために行っている取り組みの一部をエンジニア目線でご紹介させていただきます。

VPAサービスについて

まずは、VPAのサービスが車（コネクティッドカー）に対して何が出来るのかをご説明いたします。

  • 自宅のスマートスピーカー に「エアコンつけて」とお願いすると、家の駐車場にある車のエアコンをつけることができる

  • 自宅のスマートスピーカー に「バッテリー残量を教えて」とお願いすると、電気自動車のバッテリー残量をスマートスピーカーが教えてくれる

その他、細かい操作方法については、こちらのリンクを参照ください。
日産リーフ向け NissanConnect サービスガイド | Amazon Alexa 
日産リーフ向け NissanConnect サービスガイド | Google アシスタント

このように、声で車を外から操作することが出来る機能を日々、開発しています。

*NissanConnect サービスは、アップルの Siri にも対応していますが、その開発担当は別の iOS エンジニアのため、今回の記事の範囲外となります。

技術構成

次に技術構成について確認していきましょう。

サービス構成

まずは、簡単なサービス構成ですが、以下の通りとなっています。

図：サービス構成図

スマートスピーカーに向けてユーザーが発話した内容が、各プラットフォームのサービス内で開発者が定義した内容（参照：AmazonとGoogleの開発者プラットフォーム）に従って解析され、我々が開発を行っているアプリケーション（上記の図の Nissan VPA Server を指します）へリクエストが飛んできます。そして、ユーザーの意図に沿うようにアライアンスインテリジェントクラウド側のAPIを実行して、車（コネクティッドカー）を操作しています。

技術スタック

次に、開発で利用している言語やフレームワークです。こちらは、上記のサービス構成図の「Nissan VPA Server」にて利用されているものです。

サービス立ち上げ時、短期間で構築する必要があり、そこで開発スピードが早いと判断された Node.js を選択した経緯があります。また、最近ではコードの保守性の向上を目的として、一部TypeScriptの導入を始めています。

AmazonとGoogleの開発者プラットフォーム

そして、AmazonとGoogleはそれぞれ Voice Assistant のサードパーティ開発者に向けて開発プラットフォームを用意しています（詳しくは、以下のリンク先を参照してください）。これらは、上記サービス構成図の「Amazon / Google Service」に該当します。
両方ともエンドユーザーが発話した内容がどういった意図なのかを定義するようになっています。しかし思想、概念や用語がプラットフォームごとに多少異なるため、開発時に多少混乱を招きやすいです。

これらに関連して、Amazonでは積極的に彼らのプロプライエタリな技術であるAPL（Application Presentation Language）のバージョンアップが頻繁に行われています。これは彼らが積極的に新型のディスプレイ搭載のデバイスを増やしていることに起因していると思われます。直近では、このAPLの進化に合わせて我々としては今まで横表示のみサポートしていましたが、次のリリースで縦表示にも対応予定です。また、Google に関しても今までNLU（Natual Language Understanding）のプラットフォームとして、Dialogflow の利用を勧めていましたが、現在彼らは、Actions console上で統一的に利用可能な Actions Builder の利用を勧めています。こちらに関しても現在、我々はActions Builder への移行を内部で始めており、開発が終わり次第リリース予定です。このようにプラットフォーム側の進化も絶えず起こっている印象です。

プロジェクトの沿革

そして、プロジェクトの大まかな沿革について確認していきたいと思います。我々のチームで現在、担当している地域は、主に２つあります。日本と欧州です。

Nissan VPA プロジェクトの沿革

  • 2017年 [日本] Proof of Conceptとして、プロジェクトがスタート

  • 2017年 [日本] Amazon Echo にて新規サービスの提供を開始

  • 2019年 [欧州] 欧州のチームにて開発されたアプリケーションを引き取り、日本の我々のチームでGoogle Assistant のサービス運用を開始

  • 2020年 [日本] Google Assistant の追加サポートを開始

  • 2020年  [欧州] Amazon Echo の追加サポートを開始

  • 2020年 開発・運用の効率化を考えて、日本 と欧州 のコードベースを統一化するプロジェクトを開始(*1)

  • 2021年 [日本] 統一化されたコードベースでサービスを開始

  • 2022年 [欧州] 統一化されたコードベースでサービスを開始

*1 日本と欧州のVPAサービスは、別々のチームで開発が行われたため、コードベースが異なっていました。日本の我々のチームで両アプリケーションの開発・運用をそのままで進めることを考えると効率が悪かったため、コードベースを統一する判断をして、設計・開発をスタートしました。

品質を確保するための活動

上記の沿革で示した通り、サービスはただ作って終わりではなく外部要因も含めて絶えず変化する必要があります。そして我々が提供しているコネクティッドサービスは10年以上ある車の寿命以上に長くサービスを保守し続ける性質のものでもあります。また、グローバルで複数の地域のサービスを展開していますと、ドラスティックに変更を加えないといけない場面もあります。そのため、我々は大きな変化に柔軟に対応しながら、品質を一定に担保することを目指しています。そのために、組織的に取り組んでいることがあります。
それはテストをコード化することによる効率化です。まず、その一つとして Unit Test です。IT業界ではスタンダードなことですが、テストコードを開発者自身が書き保守することによって、プログラムの関数レベルの品質を保ちます。現在、プロジェクト横断的にGitHub Actionsを利用しており、コミットされるたびにCIが走ってこの Unit Test が実行されます。
次に、絶えず進化するサービスをEnd to End（E2E） でユースケースを網羅的に確認して品質を担保する必要性もあります。しかし、開発者がそれらのテストを行うのは、非常に大変で非効率です。そこで、我々は解決策として Karate を導入しました。Karate は、Gherkin という文法で記述することができ、E2Eのテストを実行することが出来るフレームワークとなります。我々のチームには、Karateをメンテしてくれる専門チームがおり、開発チームとの密の連携により、テストケースの拡充や、日々テスト結果の連携などを行ってくれます。

今現在では、Karate はVPAサービスだけではなく他のサービス開発の現場にも横展開で利用され、我々の開発において品質確保の一翼を担ってくれています。

図：Slack にKarate のテスト結果が通知されている様子

この様なKarateを用いた自動化されたテストの後に、実際に車を用いたE2E テストを担当する専門部署で行われ、トータルの品質を確保しています。
そして、一連のこれらの仕組みがあったおかげで、特に日本と欧州のコードベースを統一するという大きな対応についても自信を持って開発を進めることが出来ました。

最後に

昨今スマートスピーカーの普及などによりVoice User Interface(VUI)の重要さが叫ばれてきていますが、我々中目黒は一早くこのVUIを用いたVPAサービスのPoCを実施し、さらに実際にサービス化までスピーディーに実行してきました。この様に、中目黒には、世の中のトレンドをいち早く掴み、それを実現する企画力、開発力があります。そして長期の目線で運用も行う（DevOps）など、トータルな経験ができるチャンスもあります。もしこのような環境にご興味のある方がいらっしゃいましたら、下記のURLをご確認ください。

カジュアル面談なども用意しておりますので、お気軽にボタンを押してください！！

エンジニア関連のおすすめ記事