eSystems 社: 自動車ツールチェーンを近代化して ASPICE および ISO 26262 に対応

eSystems 社の「未来につなぐコネクティッド技術」 

eSystems MTG GmbH（KATEK SE グループの傘下）は、コネクティッド電気自動車 (EV) 充電ソリューションの自動車一次サプライヤーです。エネルギー部門と自動車部門を融合させた分野を手掛ける同社は、充電ソリューション、V2G (Vehicle-to-grid) 技術、および電気自動車の人工走行音を生成する電子制御ユニット (ECU) を開発、製造しています。

eSystems 社は bebro electronic GmbH の自動車開発部門として設立され、2019 年に独立事業体となりました。2016 年初頭のチーム結成時には、S1nn GmbH & Co. KG（現在は Samsung 社傘下 HARMAN 社の一部門）の元従業員数名がこのチームに加わりました。S1nn 社は早くから Codebeamer を使用していたため、これらのチームメンバーを通じて、統合アプリケーションライフサイクル管理 (ALM) に関する知識と、そのメリットについての詳細な情報が eSystems 社にもたらされました。  

現在、eSystems 社のソフトウェアチームは、インテグレーター、ソフトウェアツール開発者、ソフトウェアプロジェクトマネージャーなど、約 20 人で構成されています。KATEK SE グループと eSystems 社を合わせた従業員数は 2,300 人になります（2019 年 11 月時点のデータ）。  

Alexander Bourgett 氏

eSystems MTG GmbH、Leiter Software Entwicklung（ソフトウェア開発責任者）

Alexander Bourgett 氏は、自動車完成品の開発に長年の経験を持つシステム設計の専門家です。bebro 社に入社する前は、インフォテインメントシステム、接続技術、車載オーディオソリューションの革新的な開発会社である S1nn 社（後に Harman/Becker Automotive Solutions 社が買収）でシニアシステムアーキテクトを務めていました。  

Bourgett 氏は Codebeamer を早期に導入し、S1nn 社に在籍していた 2011 年からこのプラットフォームを使い始めました。多くのユーザーと同様、Bourgett 氏もこのソリューションが提供する機能の幅広さと深さを高く評価しており、中でも、当時 PTC から提供されたサポートを大変気に入っていました。偶然にも、S1nn 社と PTC は数年間、同じオフィスビルに入居していたため、PTC のオフィスがある 11 階までエレベーターで上がり、コーヒーを飲みながら問題について話す中で、サポートチケットを発行してもらうことがよくありました。  

問題点: トレーサビリティと自動車業界のコンプライアンス  

結成当初、eSystems チームはすでに自動車業界で多くの経験を積んでおり、このチームに加わる前に、移動体開発会社やサプライヤー企業で何年も働いていたメンバーもいました。それらのメンバーのほとんどは、Excel シートとオープンソースの問題追跡ツールを使用して要件管理や開発作業の追跡を行い、必要に応じてスクリプトを使用するか、あるいはデータベースを手動でリンクして、ある程度のトレーサビリティを確保していました。  

ソフトウェア開発責任者であり、この戦略に精通している Bourgett 氏は、これが決して望ましいアプローチではないことを理解していました。Excel のような汎用プログラムは、小規模な業務環境であれば役に立つかもしれません。しかし、規制された環境で 50,000 を超える要件を処理するとなると、Office ツールでは問題発生のリスクが高まり、監査時には膨大な労力が必要になる可能性もあります。

bebro 社のほかの部門では、Subversion (SVN)、Redmine、MS Office などのツールを利用して、産業用ソフトウェアやハードウェア製品を開発していました。しかし、どの関係者の目にも明らかだったのは、（Automotive Software Process Improvement and Capability Determination (ASPICE) への準拠など）自動車業界の顧客からの要件がますます厳しくなる中、それらを満たすには、eSystems 社に強力なツールチェーンを用意する必要があることでした。eSystems 社は、以下の問題を早急に解決する必要がありました。  

1. 要件やその他の成果物を部分的にしか追跡できないため、高品質な製品の開発と適切な監査が妨げられている。
2. 問題追跡ツールや Office ツールなど、「一時しのぎ」のツールチェーンにはない機能を補うため、自社開発ツールのメンテナンスに多くのコストと労力を要する。 
3. 差し迫った問題として、MS Excel 以外のテスト管理ツールがない。 
4. 「未解決のタスク」、「未解決のバグ」、「満たされていない要件」など、プロジェクトのステータスを把握するためのシンプルな手段が必要。統合ツール環境がなければ、これらを達成するのは難しい。 
5. ドキュメントに記述され、手動で実行されるワークフローは必然的にエラーが発生しやすくなる。プロセス制御を自動化することで、提供プロセスにおける高いエラー率を改善する必要がある。 
6. 顧客レビューおよび外部監査用のレポートを作成するため、チームメンバーは膨大な時間を手作業に費やしている。eSystems 社の事業拡大に伴い、この方法では対処できなくなる。 

ツールチェーンの近代化  

2016 年初め、eSystems 社は、標準のソフトウェア開発管理プラットフォームがない状態で事業を開始したものの、ツールインフラストラクチャの更新が急務であることは認識していました。  

ツールチェーンをゼロから構築するメリットの 1 つは、すでに定着している従来のソフトウェアツールを回避する必要がないことです。eSystems チームは、ALM のニーズに適したツールの特定と評価を開始しました。

Siemens Polarion が候補となった主な理由は、「eSystems 社にも競合他社と同様のツールセットを導入したい」という経営陣の意向によるものでした。

PTC の Codebeamer が候補となったのは、以前の会社でこのプラットフォームを使用していたチームメンバーが高く評価したためです。

Atlassian スイート（Jira、Confluence など）も候補に挙がりました。しかし、自動車プロセスへの適用が難しいこと、「Atlassian 社のライセンスコンセプトはわかりにくい」と eSystems チームが判断したことから、技術的な評価は行われませんでした。  

eSystems 社が求めていたのは、単なる抽象的な要件や問題の管理機能ではなく、ソフトウェア開発プロセスの詳細なサポートでした。さらにチームは、将来 ISO 26262 要件も重要になる可能性が高いことから、ASPICE への準拠に関する顧客の要件に備える必要がありました。 

eSystems 社はこれらの ALM ツールを綿密に比較しました。特に重点を置いたのは、ASPICE への対応能力（および ISO 26262 のサポート）と、ソフトウェア開発プロセスを推進する機能の評価です。  

この評価で、Siemens Polarion は、ソフトウェア開発プロセスの強力なサポートが欠如していることから「望ましくない」と判断されました。また、ユーザーインターフェースについても、このプラットフォームの SVN ベースのバックエンドについても、性能が不十分と見なされました。さらに当時、シーメンスが Polarion 社を買収したことから、シーメンスのセールス/サポートチームは大企業の顧客を重視し、eSystems 社のように小規模なスタートアップのニーズは留意してもらえないのではないか、という懸念がありました。  

この評価の技術的な側面は、Bourgett 氏にいくつかの驚くべき洞察をもたらしました。  

自動車ソフトウェア開発を支援する ALM

2016 年 3 月下旬までに、eSystems 社は PTC Codebeamer の導入を決定しました。Codebeamer の全体的なパフォーマンスの高さ（競合製品より応答時間が短い）に加え、ソフトウェア開発プロセスに対する堅牢なサポートをソフトウェアチームが高く評価した結果でした。 

eSystem 社の評価により、Codebeamer は、コマンドラインサポート、自動トレーサビリティ、Git 統合を提供し、さらに Blessed リポジトリを管理するための豊富な機能を備えていることがわかりました。このシステムでは、事前コミットフックを備えたチェックイン管理機能をすぐに利用できます。これは、評価の時点でほかのソリューションになかった機能です。eSystems チームは、使いやすく、バージョン管理コンセプトがシンプルであることから、Codebeamer のドキュメント管理機能を高く評価しました。  

eSystems 社は、Codebeamer のオープンアーキテクチャと Representational State Transfer (REST) インターフェースを介した拡張性にも注目しました。これは、複雑な自動車エコシステムで、多数の関係者と連携して作業する開発者にとって重要な機能です。また、Enterprise Architect との統合についても、競合ツールより Codebeamer の方が堅牢性に優れていました。  

Codebeamer は単一のデータベース上で動作するため、eSystems 社のチームメンバーは「ありとあらゆる情報」を参照できます。このプラットフォームは完全な V モデルプロセスをサポートしており、適切と思われる方法で、チームのプロセスにアジャイル要素を取り込むことができます。 

さらに、PTC のサポートチームとの過去の経験から、eSystem チーム（および経営陣）は、自分たちのニーズを確実に満たしてもらえると確信できました（もっとも、以前のように PTC のオフィスまでエレベーターで上がり、無料のコーヒーを飲みながらサポートチケットを依頼することはできませんが）。  

展開と使用  

一部のチームメンバーはすでに Codebeamer の使用経験があったため、eSystems 社はトレーニングなしで Codebeamer を展開することにしました。新しい仮想サーバー上にこのシステムを導入し、標準のサーバー（リソース）監視プロセスとバックアッププロセスを実装しました。

Bourgett 氏は Codebeamer の学習曲線を「非常に急」と表現していますが、「このツールの基本的な原理を習得すれば、快適に操作できるようになる」と話しています。システムの内部ロジックにより、最初の学習フェーズの後は、習得スピードが一気に速くなります。  

現在、ソフトウェア開発者を含め、Codebeamer を頻繁に使用する上級ユーザーはこのプラットフォームに満足しています。プロジェクトマネージャーやほかのシステムに慣れている人（ハードウェア開発者など）は、最初は難しいと感じるものの、1 日トレーニングすれば基本的な原則とプロセスを理解できます。  

こうした理由から、Bourgett 氏は、管理業務を担う主要なユーザーを対象にトレーニングを実施し、ワークフローの基本的なロジックを構成したうえで、チームのほかのメンバーをトレーニングすることを勧めています。Codebeamer には多数の幅広い機能が用意されていますが、ほとんどのユーザーは、これらすべての機能が必要なわけではありません。不要な機能へのアクセスを削除すると、そのユーザーグループのユーザーエクスペリエンスが簡素化され、管理者はより多くの自動化を使用できるようになります。  

eSystems 社は、過去数年間にわたり、PTC のサポートチームと緊密に連携してきました。Bourgett 氏と彼のチームは、この協力関係を高く評価しています。  

Codebeamer で実現される価値 

導入以来、eSystems チームは Codebeamer をさまざまな目的で使用しています。同社のユースケースが拡大および深化するにつれ、このシステムのより多くの高度な機能にアクセスできるようになりました。たとえば、eSystems チームは現在、独自のレポートウィジェットを構築し、完全にカスタマイズされた非常に高度な監視およびレポートシステムを導入しています。

 ソフトウェアチームは、完全に制御され、常に規制を遵守するプロセスを実行しています。eSystems 社は、このシステムと KPI ダッシュボードにライブデータを継続的にフィードバックする方法を実装しました。そのため、監査が近づいたときにチームがやるべきことは、最近生成された新しいすべての情報が、実際に Codebeamer に保存されているかどうかを再確認するだけです。データは現実のものであり、実際のプロジェクトタスクによって継続的に更新されるため、通常、この作業は 1 日ほどで完了します。つまり、これまで eSystems チームが監査準備に費やしていた労力を大幅に削減できます。 

Bourgett 氏は、Codebeamer を使用する現実的な価値は、少人数のチームにより、最小限の労力で自動車開発プロセスを実行できることだと考えています。このプラットフォームでは、すべての監査データが 1 カ所に保存され、それらに簡単にアクセスできるため、監査時に eSystems 社の貴重な時間とコストを節約できます。  

Codebeamer の最も重要なメリットについて尋ねたところ、Bourgett 氏は以下の項目を挙げました。 

• ソフトウェア成果物からテストケースおよびテスト結果へのギャップのないトレーサビリティ 
• IBM RationalDOORS® に代わる、完全かつ優れた要件管理ツール  
• 高度に構成可能なレポートとダッシュボードウィジェットにより、プロジェクトの概要を容易に把握  
• 各ソフトウェアコミットまでドリルダウンし、関連するソフトウェアタスクにリンクされた完全なチェックイン履歴を確認
• Git ベースの Blessed リポジトリと開発者リポジトリを導入  
• REST インターフェースを介した拡張性（特に、ほかのチケットシステムに接続して問題レポートやログデータを交換する場合）  
• REST インターフェースと Codebeamer のレポートエンジンで高度に自動化されたレポート機能を使用し、顧客のリリースノートやシステムテストキャンペーンのテストレポートを生成  
• 各プロジェクトで、プロセスハンドブックを要件テンプレートとして再利用し、ベースラインを使用してバージョンを管理

全体として、eSystem 社の Codebeamer のユースケースは、このプラットフォームの柔軟性を明確に実証しています。Bourgett 氏によると、eSystems 社は、導入から 1 ～ 6 カ月でこのプラットフォームの価値を実現することができました（ユースケースによって異なります）。システム管理者チームが Codebeamer の経験を積むにつれ、このツールのカスタム構成にも熟達していき、開発チームのニーズに最適なサードパーティーソリューションと高度なワークフローを使用して Codebeamer を拡張できるようになりました。  

現在、eSystems 社は、要件管理とソフトウェア開発に加え、プロジェクト管理ハンドブックの定義と管理（新規プロジェクトで再利用）、多次元リリース計画、新しい製品バージョン用ドキュメントとリリースノートの生成で Codebeamer を使用しています。Codebeamer を導入した eSystems 社では、多大な労力を要するこれらの作業のコストを大幅に削減し、貴重な開発時間とコストを節約できるようになりました。Bourgett 氏の次の言葉は、eSystems 社における Codebeamer の使用体験を端的に伝えています。