NAVYA 社について
NAVYA 社は自動運転システムの開発を専門とする企業です。2014 年に設立。フランスのリヨンに本社を置き、フランスと米国の全拠点に 280 人を超える従業員(うち 140 人は設計者と技術者)を擁しています。NAVYA 社は、商業利用可能な自動運転シャトルバスを世界で初めて実用化しました。NAVYA 社初の完全自律型の無人電動式 AUTONOM® SHUTTLE は、ファーストマイルおよびラストマイルの乗客輸送手段として 2015 年 9 月に販売開始されました。
課題: アジャイルアプローチおよび ISO 26262 への準拠
2018 年初頭、NAVYA 社の一番の課題は、組織の急成長に伴って複雑化する製品開発に対応することでした。柔軟なアジャイルアプローチと厳格な V モデルのバランスを取りつつ、安全配慮義務を確実に遵守する方法が必要でした。
NAVYA 社の設立当初、開発チームには製品の仕様を管理するシステムがなく、要件が固まらないまま開発を進めていました。ソフトウェアチームはアジャイルアプローチを採用していました。ただし、チームごとに別々にバックログを管理していたため、チーム間の連携が不十分で、従うべき手順がなく、開発プロセスが可視化されていませんでした。これらはいずれも、モビリティ業界の機能的安全性を規定する厳しい規制要件に反しています。
Codebeamer に移行する前、NAVYA 社の開発チームが使用していたのは、ほかの多くの企業と同じようなツールの組み合わせです。コードのバージョン管理では Git を使用し、手動で更新するスプレッドシート、Jira、増大し続けるドキュメントリポジトリを組み合わせて開発作業を管理していました。
社内の各チームの規模が大きくなり、製品が複雑化して手に負えなくなり始めたとき、このままでは開発効率に悪影響を与えるリスクがあることがわかりました。そこで開発チームは、状況が悪化して業務に影響が及ぶ前に対策に乗り出します。方法論的な変更が必要であることは明らかでした。
自動走行車開発における安全性とコンプライアンス
NAVYA 社は、安全性が重視される複数のサブシステムを備えた自動運転製品を開発しています。自律システムの規制整備では、統轄機関が製品開発企業に後れを取っているため、現在でも、機能の安全性確保として NAVYA 社が遵守すべき最も重要な規制要件は ISO 26262 です。
開発チームは、プロセスの観点から、製品のユースケースに基づいて大局的なリスク分析を実行します。これらをもとにシステム要件が定義され、必要なサブシステムやコンポーネントに反映されます。機能正常時および機能不全時の要件を検証するため、開発チームは、機能レベルまたはシミュレーションレベルでテストを実施しています。制御された環境でソフトウェアシステムにストレスを加え、さらに、代表的な環境でシステムレベルでのストレステストを実施します。
これらすべてのテストに合格すれば、その製品は要件を満たしていると見なされ、実装することができます。しかし NAVYA 社のチームは、まず、限られた少数の顧客を対象に実装して状況を監視し、その成功を見届けた上で、その新しいソリューションをほかの車両にも実装しています。
柔軟性を念頭に置いた ALM ツールの評価
2018 年 7 月、NAVYA 社は、アプリケーションライフサイクル管理 (ALM) を選定するための調達プロセスを開始しました。開発プロセスを標準化する必要性が高まっていたため、この探索作業は極めて迅速に行われました。十分な情報に基づいて決定を下すため、同チームは、いくつかのツールの機能を分析した上で、複数のベンダーとの話し合いを開始しました。
ALM を評価するにあたり、NAVYA 社のチームが求めていた主な条件は次のとおりです。
- さまざまなタイプのオブジェクトをカスタム構成し、それらを互いにリンクして包括的に追跡できる
- 急速に成長する革新的なアジャイル環境で容易に利用できる
- コラボレーションをサポートし、そのツール内でユーザー同士が対話できる
- 継続的な改善に合わせてシステムを進化させ、適応させる柔軟性を備えている
- 構成が容易で、プロセスの改善に伴って絶えず変化するチームのニーズに対応できる
- 最適な ROI を実現できる価格モデルを提供する
ソフトウェア開発自体と同様、NAVYA 社の開発チームは、ALM 環境の構築でもアジャイルアプローチを採用しました。同チームは、アジャイル方式の基本的なパターンに従ってプロセスを段階的に進め、新しいソリューションが自社のニーズの進化に対応できるかどうかを確認したいと考えていました。同チームが目指していたのは、作業環境を継続的に改善して、効率を最大限に高めることです。そのため、NAVYA 社にとって柔軟性は重要な要件でした。完全なアジャイルの考えかたに適応し、それをサポートできるツールを選択する必要がありました。
評価プロセスを実施した NAVYA 社は、Siemens Polarion など数種類のツールにまで最終候補を絞り込み、最終的に、柔軟性が極めて重要なニーズであることから Codebeamer を選定しました。
NAVYA 社は 2018 年 8 月にいくつかのライセンスを購入し、その後、ユーザー数を徐々に増やしていきました。2019 年には社内の Codebeamer ユーザー数が 120 人になり、さらに翌年には 200 人に達する予定でした。
自律型の展開とトレーニング
NAVYA 社は、それまで開発ツールを大規模に展開した経験がありませんでした。そのため、Codebeamer によって「これほどの成果と需要増加が得られるとは想定していなかった」と NAVYA 社、製品開発責任者 氏は話します。全体として、NAVYA 社はこのツールを迅速に導入することができ、ユーザーのトレーニングでもほとんど労力を要しなかったと言います。
当初の目的は、このプラットフォームを使用してソフトウェアのバグを管理することでしたが、間もなく、ソフトウェアチームのユーザーストーリーとエピックの管理にまで拡張されました。システムについて NAVYA 社が予想外の体験をしたのは、このツールの使用をハードウェアチームが受け入れたときでした。
Codebeamer を以前から使用している製品チームにとって、このツールをハードウェア開発に拡大するのは自然なことに感じられました。しかし、ハードウェアのエンジニアは Codebeamer をソフトウェア専用ツールと認識していたため、経営陣はハードウェアチームからの抵抗に直面しました。その後まもなく、Codebeamer はハードウェア関連の問題の管理と複雑さの軽減にも役立つことが明らかになり、ハードウェアチームの賛同が得られました。
トレーニングに関してはハイブリッドアプローチを採用しました。つまり、正式なトレーニングを実施する一方で、エンジニアがこのツールを「自由に試してみる」ことがより重要だと考えました。Codebeamer の設定がいかに簡単かを知った NAVYA 社は、多数のチームに管理者権限を付与して、このツールの使用が有機的に広まるようにしました。
ただし、このアプローチは両刃の剣です。エンジニアは Codebeamer の使用と設定に熟練していく一方、NAVYA 社の開発チームは、メンテナンスされていない上に種類が異なり、互いに連携できないオブジェクトを大量に抱え込むことになりました。これを解決するため、NAVYA 社は新たなチームを立ち上げ、Codebeamer の使用、オブジェクトの整理、共有フレームワークの下での再統合を支援する体系的なアプローチの維持を任せました。
統合 ALM のメリット
Codebeamer への切り替えによって NAVYA 社が得られた一番のメリットは、社内プロセスの透明性、明確性、一貫性が向上したことです。
Codebeamer を導入する前、NAVYA 社の各チームは、サイロ化された環境で製品のさまざまな機能面に取り組んでいました。それぞれの活動が十分に可視化されず、状況をシステムレベルで把握して複雑さに対応するのは困難でした。
Codebeamer を導入した結果、要件から検証までのあらゆる成果物をリンクし、開発作業を包括的に把握できるようになりました。依存関係を簡単に追跡できる上、共通のポリシーはコーディング品質の標準化に役立ちます。進捗状況や各種の大局的な指標を監視して、注力分野を容易に測定することも可能です。これをもとに問題領域を特定し、継続的な改善に役立てることができます。
ALM を利用し、大局的な要件から、有機的なアーキテクチャを経て最終テストに至るまで、包括的に追跡できるリンクを構築することで、NAVYA 社では開発作業のコンプライアンス面にもメリットがもたらされました。これにより、NAVYA 社のチームは、必要な検証手順とコンプライアンスチェックを実施できます。Codebeamer に切り替える前は、これらのプロセスを実行するための機能がありませんでした。このプラットフォームを使用することで、チームの効率性が大幅に向上したと NAVYA 社は報告しています。
このプラットフォームの柔軟性やさまざまなメリットを考えると、現在、NAVYA 社が Codebeamer の新たな導入方法を検討しているのも驚くにあたりません。