Technical Information

トレーサビリティ管理ツールをもっと実践的に使いこなすには
~規格対応のため「だけ」から、品質・生産性向上のために~

asset_approach_column_software-quality06_hero.jpg

車載システム開発では、この10年で要求管理ツール(いわゆるトレーサビリティ管理ツール)の導入が進みました。しかし、規格への対応という当初の目的に沿った利用にとどまり、品質改善や生産性向上といった効果につなげられていないケースが少なくありません。本講演では、代表的な要求管理ツールを比較・分析した上で、より本質的な改善に導くツールの活用方法について、事例を交えて解説します。併せて、ベリサーブが提供するトレーサビリティ管理ツール「ConTrack」についてもご紹介します。

※この記事は、『ベリサーブ オートモーティブ カンファレンス 2021』の講演内容を基にした内容です。

横田 裕行

株式会社ベリサーブ
プロセスエンジニアリング
サービス開発部
プロダクトサービス開発課
課長
横田  裕行 

要求管理ツールとは

要求管理ツールとは、定義された要件がどのような工程を経て設計やソースコードへ落とし込まれているかを追跡、可視化するものをいいます。要求管理の主な目的は次の三つです。

  1. 要件と設計の整合性の確認(一貫性)
  2. 要件の全てが設計に反映されているかの確認(完全性)
  3. 設計の変更による影響の明確化(影響分析)

一般的な要求管理ツールは、これらを実現する機能を備えています。

日本での要求管理ツール普及の背景

日本で車載システム開発に要求管理ツールが利用されるようになったのは、2011年のISO 26262(自動車機能安全規格)の発行がきっかけです。それまでは表計算ソフトで要求を管理するケースが一般的でしたが、規格対応の必要に迫られ、さらにはシステムの大規模化・複雑化という事情も相まって、専門ツールの導入機運が高まりました。ただ当時はツールの大半が海外製品だったため、WordやExcelで設計書を作成する日本の開発文化にはなじまず、規格対応のエビデンスとなる成果物の“保管庫”の扱いにとどまっていました。

2010年代後半に入ると、シンプルで使い勝手の良いタグベースの要求管理ツールが登場しました。使い慣れたWordやExcelがそのまま使えることもあってそれなりに普及しましたが、導入の主目的はやはり規格への対応でした。

その規格対応もこの2~3年で一段落したようで、最近では品質や生産性の向上といった、より本質的な改善効果を期待して要求管理ツールの導入を検討するお客様が増えています。以下ではまず、代表的な要求管理ツールの種類と特徴を見ていきます。

ALM観点からの要求管理ツールの分類

要求管理ツールを分類するに当たり、今回は、要求管理より少し広い概念であるALM(Application Lifecycle Management)の観点から考えてみることにします。

ALMは、システム開発で作成されるドキュメントなどを、システムのライフサイクル全体にわたり統合的に管理していくという考え方です。図1は、ALMを実践するためのツールをイメージしたもので、要求管理の他に構成管理、変更管理、要求・仕様記述などのモジュールから成り立っていることが分かります。

ALMツールの構成イメージ

図1:ALMツールの構成イメージ

Excel

たいていのPCにインストールされているExcel(図2)は、導入や習得コストが事実上ゼロである点が最大のメリットです。要求管理ツールを提供するベンダーにとっては最強のライバルといえます。

しかし、Excelはそもそも要求管理の専門ツールではないため、できることはマトリクスや展開表の記述がせいぜいで、N対Nのような複雑な関係性の表現は困難です。構成管理や変更管理といった他のシステムとの連携も皆無なため、要求の追加や変更などの追従が全て手作業となり、大変な手間がかかります。

Excelを要求管理に用いる場合のイメージ

図2:Excelを要求管理に用いる場合のイメージ

フルALM型

Excelとは逆にALMに必要な全ての機能を含むものがフルALM型
(図3)で、きちんと使いこなせれば大きなメリットが得られます。

しかし、多機能なだけに「きちんと使いこなす」ことが非常に難しいのが実情です。開発プロセスやスタイルもある程度ツールに合わせる必要があります。特に、要求・仕様の記述にツール内の機能を使わなければならないことが、日本で普及する上で高いハードルになっているようです。

ALMに必要なすべての機能を備えたフルALM型ツール

図3:ALMに必要なすべての機能を備えたフルALM型ツール

要求管理特化型

先ほど触れたタグベースのツールは、ドキュメント内に埋め込んだIDとタグをトレース情報として可視化するもので、この要求管理特化型に分類されます(図4)。要求管理に絞り込んだシンプルさが強みで、要求・仕様はWordやExcelで記述できるため、日本の開発現場との親和性が非常に高いのも特徴です。

一方で、機能を変更・追加するとIDの情報が変更になるため、差分開発やバージョンアップ開発が進むほどにタグをメンテナンスする負担が大きくなります。また、トレースの可視化に特化しており、他のツールとはデータ連携にとどまり緩やかな結合になっています。従って、ALMを実践するには運用プロセスを工夫する必要があります。

要求管理に絞り込んだシンプルさが特徴の要求管理特化型ツール

図4:要求管理に絞り込んだシンプルさが特徴の要求管理特化型ツール

軽量ALM型

ツール自体の機能は要求管理のみですが、構成管理や変更管理はオープンソースソフトウェア(OSS)とのシームレスな連携で統合的に
ALMを実現します。要求・設計はWordやExcelから取り込み可能で、慣れ親しんだ開発プロセスをそのまま維持できるので導入も容易です(図5)。ベリサーブが提供する「ConTrack」はここに分類されます。

あえて課題を挙げるなら、派生・保守開発を行わない単発のプロジェクトでは、導入時のフォーマット検討などの負担があり費用対効果が得られにくいことです。

他システムとのシームレスな連携でALMを実現する軽量ALM型ツール

図5:他システムとのシームレスな連携でALMを実現する軽量ALM型ツール

開発における要求展開の類型

ここまで、要求管理に使われるツールを特徴ごとに分類し比較してきました。「さまざまな種類があることは分かったが、結局、自分たちのプロジェクトにはどれが適しているのか」と思う方もいらっしゃるでしょう。ツールの特徴の他に、もう一つの判断基準となるのが要求とそれを実現する機能の関係性に着目した、開発における要求展開の構造です。大きく次の二つに分類されます。

ツリー構造型

システムの要求が機能へとシンプルに分解されて1対Nの関係になる構造です。新規開発やフルスクラッチなど、これから新しいものを作る場合に多く見られます(図6)。どの要求がどの機能で実現されるかが分かりやすく、小規模なプロジェクトであればExcelでも表現できます。

ツリー構造型要求展開のイメージ

図6:ツリー構造型要求展開のイメージ

ネットワーク構造型

要求と機能がN対Nの複雑な関係になる構造で、機能改良や派生開発、カスタマイズ開発に多く見られます(図7)。追加の開発を繰り返すたびに関係性はさらに複雑になるため、可視性や視認性に優れた専用ツールでないと追跡はほぼ不可能になります。

ネットワーク構造型要求展開のイメージ

図7:ネットワーク構造型要求展開のイメージ

日本の開発事情を踏まえた要求管理ツールの適用マップ

システムのライフサイクルを縦軸、要求展開の構造を横軸とし、日本の開発事情も加味して各ツールをマッピングしたのが図8です。ツリー構造でライフサイクルの短い単発の開発であればExcelでも管理可能ですが、ライフサイクルが長くネットワーク構造になっていくと、使い勝手の面からも軽量ALM型が最適解になると考えられます。開発する製品の特徴を踏まえることが大前提となりますが、ツール選択の参考になりましたら幸いです。

要求管理ツールの適用マップ

図8:要求管理ツールの適用マップ

ConTrackの概要

ベリサーブが提供する「ConTrack」は、日本の開発現場にマッチした要求管理を実現するために開発したトレーサビリティ管理ツールです。要件管理機能と文書解析エンジンを中心に、Subversion・Redmine・Jira Softwareなどの実績あるツールと強力に連携して構成管理と変更管理を実施します(図9)。直感的で使いやすく、既存のドキュメントをそのまま活用できるなど、品質や生産性の向上に直結する要求管理ツールとして開発を進めてきました。

要求管理ツールの適用マップ

図9:ConTrackの機能概要

ConTrack事例紹介

ConTrackの導入により課題の解決に至った2事例を紹介します。

事例1:”超上流”での品質向上~自動車業界サプライヤー

【課題】
メーカーから最初に提示される要求仕様は曖昧で未確定な部分が多く、その後のコミュニケーションによって要求を固める形を取っている。ただ、仕様書・Q&A表・会議の議事録・メールなど、変更要求の形式がバラバラで情報が散在しているため、要求の矛盾に気付かないまま開発が進んでしまい、テスト工程で手戻りが起きることもあった。

【導入後】
さまざまな形式で提示される変更要求をConTrackで一元管理し、要件定義モデルや基本設計モデルとつなげていく。
これにより、過去から現在までの変更要求の経緯が可視化でき、整合性が確保されて、後工程からの手戻りを大幅に減らすことが可能になった(図10)。

超上流での品質向上にConTrackを活用

図10:【事例1】"超上流"での品質向上にConTrackを活用

事例2:多品種開発での変更要求対応~組み込み産業機器開発

【課題】
ベースとなる汎用仕様の製品を顧客ごとにカスタマイズする業務形態で、開発は顧客別の派生ブランチで並行して進めている
(図11)。複数の顧客から類似した変更要求があった場合にも各ブランチで個別に対応していたため、無駄が生じていた。さらに、共通部分に不具合が見つかり一つのブランチで修正したものの、別のブランチにはそれが反映されず品質問題が発生したケースもあった。

多品種開発での変更要求に対応

図11:【事例2】多品種開発での変更要求に対応

【導入後】
汎用仕様の機能要件・設計・実装のドキュメントをConTrackで管理、これを各ブランチに置いて変更要求をトレースできるようにした。これにより、類似した変更要求に対応する重複作業が大幅に減少した。また、同じモジュールを流用しているブランチはどこかが即座に把握できるため、共通の不具合も迅速に解消できるようになった(図12)。

多品種開発での変更要求にConTrackを活用

図12:【事例2】多品種開発での変更要求にConTrackを活用

ConTrackの新機能「ReqIF Adapter」

2021年6月にリリースしたConTrackの最新バージョンには、欧州の自動車メーカーやメガサプライヤーと取引する日本企業を支援する新機能「ReqIF Adapter」が追加されています。

欧州ではフルALM型要求管理ツールを採用する企業が多く、日本の取引先にも同じツールでのやり取りを求めるケースが増えています。取引先が1社なら指定のツールを導入すれば良いのですが、複数の欧州企業と取引する場合にそれぞれ別のツールを用意するのはコスト面で大きな負担になります。

「ReqIF」は米国の標準化団体による規格で、異なる要求管理ツール同士で要求や設計の情報をやり取りできるフォーマットです。
ReqIF AdapterはConTrackでReqIFのインポート/エクスポートを実現する機能で、以下のようなことが可能になります(図13)。

  • ReqIFの要求をConTrackに取り込み、それに基づいてWordやExcelで設計やテストを作成しトレースする
  • ReqIFの要求が設計やテストに全て網羅されているかを確認する
  • 開発終了後、結果を取引先に納入する際にReqIF形式で出力する
  • 要求の変更や追加が発生した場合に、ReqIFの新旧バージョンを比較した差分分析をする。それにより、設計やテストの見直しに役立てることができる
多品種開発での変更要求にConTrackを活用

図13:ReqIF Adapterを活用した要求の交換イメージ

おわりに

ConTrackは、ほぼ年1回のペースでメジャーアップデートを行っており、2021年はReqIF Adapterの他にフローティングライセンスを追加、より柔軟な導入を可能にしました。フローティングライセンスとは、複数のメンバーで同一のソフトウェアを共用するための使用許諾契約(ライセンス)方式をいいます。ライセンスはサーバーで運用し、ネットワークで接続されたパソコンからライセンス数の範囲内でソフトウェアを同時に利用できます。これにより、利用するユーザ全員分のライセンスを購入する必要がなくなるメリットがあります。

日本発の製品という強みを活かし、日本の開発現場をより良くするための改良を今後も続けていきたいと考えています。


この記事をシェアする

Facebook  Twiter