進化するモビリティと、深化する品質創造。
ベリサーブ オートモーティブ カンファレンス 2021
レポート Vol.2

2 021 November Vol.24

進化するモビリティと、深化する品質創造。
ベリサーブ オートモーティブ カンファレンス 2021 レポート Vol.2

CONTENTS
特集1

06「電費」時代の自動車産業 〜クルマは仮想空間で稼ぐ
中山 淳史 氏

特集2

14

これからの車載ソフトウェア開発と品質保証
森崎 修司 氏特集3

22

車載システムの分散・分担開発におけるプロジェクトマネジメントの課題解決に向けて
冬川 健一

特集4

30

車載セキュリティテストに関するベリサーブの取り組み
長谷川 邦幸特集538

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

モビリティ産業はいま、百年に一度と言われる変革期を迎えています。MaaS／CASE といった言葉に代表されるように、
過去に例のないサービスやプロダクトが世の中に登場してはさらなる進化を続け、その開発手法もアップデートを繰り返しています。そうした時代に求められる「品質」とはどのようなものでしょうか。
本カンファレンスでは、「進化するモビリティと、深化する品質創造。」をテーマに、MaaS／CASE を前提とした世の中の動きや社会的インパクト、新時代のモビリティに求められる品質保証の考え方など、第一線の有識者・技術者がそれぞれの知見を披露しました。
前号（23 号）に続き、今号（24 号）でご紹介する講演プログラムは右ページの通りです。

Hiroyuki Yokota
Kuniyuki Hasegawa
Kenichi Fuyukawa
Shuji Morisaki
Atsushi Nakayama
Hidetoshi Suhara

Keiichi Yoneya

Kazuhiko Makimura

Hirokazu Igarashi

Vol.

24

基調講演

これからの車載ソフトウェア開発と品質保証「電費 」時代の自動車産業 ～クルマは仮想空間で稼ぐ
中山 淳史 氏森崎 修司 氏株式会社日本経済新聞社 コメンテーター

名古屋大学 大学院情報学研究科 准教授
株式会社ティアフォー 技術顧問

技術講演

車載システムの分散・分担開発におけるプロジェクトマネジメントの課題解決に向けて

車載セキュリティテストに関する
ベリサーブの取り組み

トレーサビリティ管理ツールをもっと実践的に使いこなすには

冬川 健一

長谷川 邦幸横田 浩行

株式会社ベリサーブ～規格対応のため「だけ」から、
品質・生産性向上のために～株式会社ベリサーブ

Vol.

株式会社ベリサーブ

23

自動運転社会の実現に関する取組について

MaaS が都市を変える ～移動 × 都市 DXの最前線～

五十嵐 大和 氏

牧村 和彦 氏総務省 総合通信基盤局電波部移動通信課
新世代移動通信システム推進室長 高度道路交通システム推進室長（当時）

一般財団法人 計量計画研究所 理事 兼 研究本部 企画戦略部長

車載 ECUの開発現場から見たテストと自動化の現状

車載ドメインにおけるモデルベースドテストの実践例のご紹介

米谷 恵一

須原 秀敏

株式会社ベリサーブ

株式会社ベリサーブ

「電費」時代の自動車産業～クルマは仮想空間で稼ぐ

はじめに
長い間、自動車と電機は日本経済を支える二本足と言われてきました。一部を除き凋落傾向にある電機業界と比べ、自動車産業は今も隆々とした勢いを保っていますが、昨今ではここにも大きな荒波が押し寄せてきています。これからの時代、クル
マは単に走るだけではなく、走りながら稼ぐものになっていき中山 淳史氏なかやま あつし

株式会社日本経済新聞社
コメンテーター
1989年上智大外国語学部卒、日本経済新聞社入社。編集局産業部、米州総局（ニューヨーク）、証券部などを経て2010年に産業部編集委員兼論説委員、13年から企業報道部次長兼編集委員。自動車、電機、運輸などを担当。17年2月から現職。

6 | Veriserve Navigation Vol. 24

ます。これが今後の自動車産業をどう変えていくのか、世界と日本の動向を踏まえながら考察してみたいと思います。
本講演では、● 変わる「ものさし」● 覇権をめぐるゲームチェンジという二つのポイントからお話させていただきます。

「電費」時代の自動車産業～クルマは仮想空間で稼ぐ

燃費から電費へ - 変わる「ものさし」
47万円の「ウーリン」
昨年夏、中国の中堅自動車メーカー、上汽通用五菱汽車が「ウーリン」ブランドより「宏光MINI EV」という小型電気自動車（EV）を発売しました（図1）。発売直後の瞬間風速ではあるものの、米テスラ社の Model S を抜き中国で最も売れた EV となりました。47万円という低価格ながらよくできていて、1回の充電で120km 程度は走るそうです。日本の軽自動車よりもやや小ぶりのサイズですが、若いカップルの街乗りや MaaS などのシェアリング
サービスには十分で、合理的な中国の消費者からは高く評価されています。
図1 上汽通用五菱汽車の小型 EV
引用：上汽通用五菱汽車 Web サイト

https://www.sgmw.com.cn/e50.html

Veriserve Navigation Vol. 24 | 7

脱炭素の取り組み
このクルマが登場した背景には、欧米を中心に進む「脱炭素」への動きがあります。これに関しては、以下のようなキーワー
ドがさまざまなメディアで頻出しています。

● カーボンニュートラル
● カーボンフリー● カーボンプライシング● グリーンエコノミー● ライフサイクルアセスメント

指標がよく使われますが、これは一ユーザーにつき、どれくらいの売り上げがあったかを意味します。これを自動車に置き換えて考えると、ソフトウェアのアップデートによる機能追加などによりクルマを販売した後にどれだけ稼ぐことができるか、そこが重要になってきます。

走行データの売買
実は「＋α」にはもう一つ別の考え方あります。EV が走る、
それ自体が利益を生む可能性があるということです。EV では、
それまでハードウェアが行っていた制御の多くをソフトウェアが行うようになるため、動力源である電気がいつどこで作られカーボンニュートラルとカーボンフリーは、文字通り脱炭素

たか、どこで充電したか、どこからどこまでどのように走ったのことです。カーボンプライシングは価格、つまり二酸化炭素

か、その全てをデジタルデータとして容易に追跡、蓄積するこの排出枠取引や炭素税、炭素国境調整措置などをひとくくりにとが可能です。メーカーはユーザーに同意を得た上で、このデした言葉です。グリーンエコノミーは地球温暖化を防止する経

ジタルデータを資産として活用できるかもしれません。例えば、済活動、そしてライフサイクルアセスメントは、部品作りからある区間を走行した時の道路や人通りの状況、立ち寄り先など、廃車に至るクルマの一生を通じて脱炭素を目指す取り組みでメーカー自身だけではなく他の企業も欲しがる情報は無数にあす。こうした状況の中で生まれたのが「宏光 MINI EV」というります。こうしたデータは排出権取引などと同様に売買され、わけです。

莫大な利益につながる可能性があります。

電費 =「走行距離 +α」

電費を抑える運転

本講演のタイトルにある「電費」、これは従来の自動車産業に

また、先に示した排出枠と同じ考え方で、電費を抑える運転

おける「燃費」と対比する言葉です。ご存じの通り、燃費はガという行為が経済価値を持つということです。つまり、CO 2を

ソリン1L 当たりの走行可能距離を指します。1886年にドイ排出しないクルマをさらに効率よく走らせると、その報酬としてツ・ダイムラー社のカール・ベンツ博士がガソリンで動く自動

仮想通貨が支払われる。EV を通じて、こうしたやり取りが仮想車を開発、世界で初めて商品化しました。そこから実に135年

空間上で始まる可能性があるのです。

間、メーカーの競争力を図る指針として、燃費の時代が続いてきたわけです。
では、「電費」とは何か。当然ですが、EV においても1回のデジタルツイン（電子の双子）～リアルとサイバーのマーケットプレイス

充電で何 km 走れるかは重要な要素です。先ほどのウーリンはこれを可能にするのが、デジタルツイン技術（電子の双子）

120km ですが、東京の郊外から都心までの往復ぐらいはできです。図2は伊藤忠総研の深尾三四郎氏によって作成されたもそうです。しかし、電費が内包する意味はそれだけではありまので、左に人・モノの輸送、右側にエネルギーマネジメント、せん。そこには、「走行距離 + α」の新しい価値が存在するの中心にはこれらを巡る脱炭素などの取り組みがあります。面白です。

いのは、この二つの円の上下には現実世界とサイバー空間（仮想空間）があり、同じ事象がサイバー空間上にも存在すること

この「+ α」によって、クルマを評価する「ものさし」が変わります。燃費の時代、ものさしが「1台当たりの利益」だったとすれば、電費の時代には「走行当たりの利益」というものが問われるようになります。通信や IT などの課金型ビジネスを展開する企業の業績では、ARPU（ユーザー平均単価）という

8 | Veriserve Navigation Vol. 24です。先述の電費を抑える運転で生じる取引はサイバー空間側で行われることになります。

「電費」時代の自動車産業～クルマは仮想空間で稼ぐ

これをさらに詳しく説明したのが図3です。左が現実世界、右側がサイバー空間ですが、一番下にはどちらの世界も同じクルマが存在します。道路や周囲の街並み、店舗などもサイバー空間に作れば、現実世界と同期させてクルマを走らせることができます。電費を抑える運転のより良い方法をサイバー空間でシミュレート、現実世界にフィードバックし、そこで得た報酬を再びサイバー空間に蓄積する。こうしたやり取りがリアルタイムで行われる、それが電費の時代なのです。

図2 EV・車載電池の提供価値
出所：深尾 三四郎氏より

実世界

サイバー空間「ミラーワールド」（鏡像世界）

スマートコントラクト・Ｍ２Ｍ取引
MaaS/CASEの収益化、
外部不経済（公害）
の是正

人工知能
「考える」
「学ぶ」
「決断する」
付加価値の創造
実世界にフィードバック
暗号資産「価値のインターネット」の媒体

ブロックチェーンへの記録
IoT（モノのインターネット化）
センサーによるデータ感知

現実資産

ブロックチェーン
信頼のプロトコル

ビッグデータ「憶える」

VID（デジタルID）
デジタルレプリカの複製
ブロックチェーンへの記録
デジタルツイン（デジタルの双子）
サイバーフィジカルシステム
CPS ( Cyber-Physical System )図3 車のデジタルツインと信頼のプロトコル
出典 : 深尾 三四郎・クリス・バリンジャー（2020）．モビリティ・エコノミクス ブロックチェーンが拓く新たな経済圏

日本経済新聞出版

Veriserve Navigation Vol. 24 | 9

電費の時代はいつやってくるのか？
EV はいつ爆発的に普及すると考えられるのでしょうか？ その普及にはエネルギー効率の高い電池技術が不可欠です。しかし、電池はそう簡単に性能を上げることはできません。現在、覇権を巡るゲームチェンジ
遅れが目立つ日本主流となっているリチウムイオン電池は、半導体のように1年

ここまでお話しした通り、これからの自動車産業は全く違う

半に1回の割合で性能が倍増するようなことはまずありません。

ものにアップデートされていく可能性があります。これをにらみ、次代の主役の座を狙う国や企業がすでに活発な動きを見せ

ガソリンエンジン車を超えるエネルギー効率を得るためには、ブレークスルー（障壁を突破する革新的な電池技術の開発）がています。脱酸素化に向けた各国および主な企業の動向は図4の通りで、いろいろな思惑が読み取れます。

必要とされています。現在、メディアで取り上げられているのは「全固体電池」という技術で、これが確立されると走行可能

法制化は少し先になりますが、欧米は2030～35年にはガソな距離は何倍にもなると言われています。こうなると、EV は黙リン車を全廃する方針です。中国はマーケットが巨大なこともっていても（または「必然的に」）普及するでしょう。それがいあってそのスピードが少し緩めで、2035年に全てを省エネ車、つになるのか？というのが自動車業界最大の関心事となってい新エネルギー車にするとしています。そして日本は2030年代

ます。

半ばに HV を含めて半数を電動車にするということで、中国の目標のさらに半分となっています。ガソリン車という大きな資自動車や電池業界の予測では、期待も込めて2025年には全固体電池の量産化技術が確立されているとも言われています。

産を抱えている事情はあるにせよ、対応が遅すぎるという感はやはり否めません。

しかし、日本の関連企業の投資状況をヒアリングしてみると「リチウムイオン電池」への投資割合が多く、すぐには量産化が実

企業レベルでは、米ゼネラルモーターズ社が2035年にガソ現する時は来ないだろう、というのが私の見解です。ただ、そリン車を全廃すると発表しています。この会社は HV が弱いのれが少し先、例えば2035年頃になるとしても、のんびりとはで、EV に完全移行すると見てよいでしょう。自動車販売台数がしていられません。わずか15年足らずで電費の時代がやってく世界第1位のトヨタは2025年に半数を電動化するとしています

ると考えた方がいいでしょう。

が、同社は HV も電動車と見なしていて、これを含めての半数です。EV「リーフ」を擁する日産も現在注力しているのは
e-POWER という HV の一種となる方式で、発電専用のガソリンエンジンと蓄電池、モーターを組み合わせたものです。両社
とも EV 化という点では遅れ気味と言えるでしょう。

デファクトか、デジュールかタイムスケジュールではほぼ足並みを揃えている欧米ですが、そこに向かう戦略は分かれる可能性があります。米国が得意なのは「デファクト」、つまり企業間の自由競争によって事実上の標準を生み出すというものです。スマートフォンにおける米アップル社の iPhone が代表的な例です。
一方、EU が好むのは「デジュール」で、国家が法制度によって標準を決める戦略です。EV 関連では「バッテリー指令」、「炭
素国境調整」、「炭素税」、「排出枠取引」、こうしたものを法制化し、遵守しない相手とは取引禁止、あるいは高い関税をかける。
これを域外に広げつつ、自国企業には補助金で支援し、あわよ

10 | Veriserve Navigation Vol. 24

「電費」時代の自動車産業～クルマは仮想空間で稼ぐ

テスラの10年計画

くば EU の製品を世界に拡散しようとします。WTO（世界貿易機関）協定との整合性や補助金の高騰といった問題をはらむも

次は、企業の例として EV のリーダーと言えるテスラの状況のの、ヨーロッパの戦略はこれが昔からの基本です。

を見てみましょう、同社には「マスタープラン」と呼ばれる10
年スパンの経営計画があり、図5はその要旨です。

中国の方針はまだ定まってはいないようですが、どうやら EUと協調していく方向のようです。こうした各国の動向に日本がどう対処していくのかが、今後の大きな課題になっていくと思
われます。

国・自治体

アメリカ
カリフォルニア州

2035年にガソリン車の新車販売禁止

イギリス
・
オランダ

2030年に脱ガソリン車

中国

2035年に全て省エネ・新エネ車

日本

2030年代半ばに電動車化（ハイブリッド車：HV含む）、50年温暖化ガス0自動車各社の計画

ゼネラルモーターズ

2035年にガソリン車全廃

トヨタ

2025年に半数を電動化

日産

2030年代に新車を電動化

図4 脱酸素化に向けた各国および主な企業の動向

第1期（2006年～）

第2期（2016年～）・スポーツカーを生産する

・車や蓄電池とシームレスにつながる太陽光パネル

・その収益を元手に手ごろな価格の車を生産

・EVのラインアップを全車種に・さらにより手ごろな車を生産

・世界中のテスラ車からのデータをフィードバックし人が運転するよりも10 倍安全な自動運転技術を開発

・無公害で発電可能なシステムを提供

図5 テスラのマスタープラン

・使わない時間帯に車からカーシェアリングに向かい
持ち主に収入をもたらす技術を開発（出所）テスラ、アーサー・D・リトル・ジャパン

Veriserve Navigation Vol. 24 | 11

アップルの動向

2006年に発表した第1期、上から3番目までについては、
2008年のロードスターを皮切りに、Model S、Model 3と、もう一つの注目の企業はアップルで、おそらく自らクルマを

ほぼ計画通りに進んでいます。4番目がテスラの特徴を表すも作るのではなく、欧州などの企業に OEM で生産を依頼し、そので、これは建物の屋根に設置する太陽光パネルを指していまこに搭載する IT やサービスで稼ぐビジネスモデルを考えているす。つまり事業の根幹は持続可能エネルギーのマネジメントで、と思います。彼らはウォレットやデジタルツイン、ブロックチ

EV もその一つというわけです。

ェーンなど、いろいろな技術を持っています。クルマを売った
後に稼ぐ、そこだけに賭けようという企業がアップルなのです。

2016年からの第2期の1番目は先ほどの延長線上で、太陽光パネルの充実です。2番目が車種拡充で、小型車や SUV、トラ

図6は、株式時価総額の比較です。トヨタの時価総額は日本ックなどにも EV を広げていく。そして3番目が先ほど説明したの他の自動車メーカー全部を足しても及ばないほどなのですが、走行データに関わるもので、世界中で走るテスラ車から得たデテスラの株価は実にその3倍です。これが何を意味するかといータを元に、人間が運転するよりも10倍安全な自動運転技術をうと、仮にテスラが生産能力を増強したいと考えたなら、株式開発すると言っています。

交換を使えば日本の中堅メーカーを買収することが理論上は可能なのです。

4番目が非常に興味深いのですが、テスラ車のオーナーがマ
イカーをシェアリングサービスに登録しておくと、空き時間にいわんやアップルです。時価総額はトヨタの10倍で、この会

クルマが自動でお客さんのところへ出掛けていき、目的地に送社がどのように EV に参入してくるか。固定資産を持たないとり届け、また家に帰ってくる。要するに、自動運転技術を使っていう方針ゆえに自動車メーカーの買収はないでしょうが、時価クルマが勝手に稼いでくれるというわけです。

総額の実力を見ればさまざまな方策が考えられるでしょう。

無人運転が法律で認可されることが前提ですが、第1期の計画が全て達成されたことを考えれば、技術的には2026年までに実現する可能性が高いとみています。おそらく市場もそう判断していて、それが高い株価に反映されていると言えるでしょう。

株式時価総額の比較 （2021年5月13日現在）
0
トヨタ

フォルクスワーゲン
ゼネラル・モーターズ
テスラ
アップル
図6 株式時価総額の比較

12 | Veriserve Navigation Vol. 24

50

100

150

200

250（兆円）

「電費」時代の自動車産業～クルマは仮想空間で稼ぐ

衰退の五段階（イメージ）

迎え撃つトヨタ
2020年1月に米ラスベガスで開催された世界

第二段階

最大の家電・IT 見本市「CES 2020」におい

規律なき
拡大路線

て、トヨタは実証都市「ウーブン・シティ」のプロジェクト概要を発表しました。この計画に当たりトヨタは5000億円という大規模な社債を発行しましたが、1カ月足らずで完売した
ようです。また、事業母体としてウーブン・プ
ラネット・ホールディングスという持株会社を

第四段階

第一段階
成功から生
まれる傲慢

一発逆転
策の追求
第三段階
リスクと
問題の容認

第五段階
屈服と凡庸
な企業への
転落か消滅

作り、こちらには豊田章男社長も個人で出資をしています。
豊田社長の弁では、ここからトヨタは新旧に分かれていく。現在のトヨタを旧として、新トヨタはクルマの OS をはじめとしたソフトウェアの開発やサービスを事業として展開し、いずジェームズ・コリンズ氏「衰退の五段階」から
図7 米国の経営学者、ジェームズ・コリンズ氏が提唱する「衰退の五段階」のイメージ図

れは新トヨタが旧トヨタの時価総額を抜いて欲しいと言っています。ウーブン・シティはトヨタの新たな技術やデータ活用のショーケースであり、テスラや時代など簡単には来ない、売った後に稼ぐなどありえない、そアップルの猛攻を黙って見てはいないということでしょう。

んなふうに考えていた節があります。まさに「リスクと問題の否認」です。豊田社長は明確には述べていませんが、ウーブン・
シティや新旧トヨタの構想は、そこに気付き方針の転換を図ろおわりにうとする意志の表れであると感じます。
今のところ、日本の自動車産業は世界一の座に君臨していま

図7は、企業の衰退プロセスのイメージで、米国の経営学者

すが、このままあぐらをかいていてはテスラやアップルのようであるジェームズ・コリンズ氏が著書で提示したものです。実な企業に簡単に足をすくわれてしまう危険があります。そうなはトヨタの豊田社長は2009年に日本記者クラブの場でこれをらないためにも、燃費から電費へと戦略のマインドをすぐにで示し、今のトヨタは第二段階にいる、と発言しています。そのもシフトし、新しい経営に踏み出すことを期待しています。

時期はリーマンショックの直後で、トヨタは世界中で工場の建設ラッシュを進めていたために一気に赤字に転落していました。
「規律なき拡大路線」に走ってしまったわけです。
では今はどうなのか。想像するに、第三段階に陥りかけていたのではないでしょうか。先に述べた通り、他国と比べて日本は国もメーカーも脱炭素には消極的で遅れが目立ちます。EV の本記事の内容に関するご質問、お問い合わせは、株式会社ベリサーブ 広報・マーケティング部 Email : verinavi@veriserve.co.jp までお寄せください。

Veriserve Navigation Vol. 24 | 13

これからの車載ソフトウェア開発と品質保証

森崎 修司 氏もりさき しゅうじ
名古屋大学 大学院情報学研究科
准教授
株式会社ティアフォー 技術顧問

はじめに自動運転や高度運転支援への対応、より高度なセキュリティの実現など、車載ソフトウェアへの要求が多様化する中、ODD（Operational Design Domain：運行設計領域）やシナリオ
ベースの品質保証など、国内外のさまざまな取り組みが発表さ2001年 奈良先端科学技術大学院大学 情報科学研究科 博士後期課程修了。通信事業者にてオンラインストレージサービスの企画・開発に従事し、2013年10月より現職。実証的ソフトウ
ェ ア 工 学 の 研 究 に 従 事。独 立 行 政 法 人 情 報 処 理 推 進 機 構（IPA）にて、つながる世界の品質指針検討ワーキング・グルー
プ等の主査を務める。日本、ドイツの車載ソフトウェア開発に携わる社会人博士の学位取得の支援や審査に従事。

14 | Veriserve Navigation Vol. 24

れるようになりました。ソフトウェアの開発方法やその品質保証の方法もこれらの取り組みや技術に合わせて変えていかなけ
ればならない部分があります。
本講演では、そうした車載ソフトウェアを取り巻く環境の変化や背景を整理した後、これからの開発方法や品質保証に求められる要件を解説します。

これからの車載ソフトウェア開発と品質保証

図1は、環境想定の難易度を表したものです。環境想定や制御が比較的容易な左側の「車体系」から、右側の「高度運転支援」や「自動運転」に向かって環境想定の難易度が高くなっていきます。そこには「他システムとの連携」や「ドライバーへのテイクオーバー *1」「路上障害物の判断」といった複雑な状況判断が求められることを示しています。今後、必要とされる環
境想定は右側、より想定が難しい方へ向かっていくと考えています。

ODD による条件の明 確化
環境想定が難しくなる中で求められているのが、ODD による条件の明確化です。ODDとは、自動運転システムが正常に動作するための前提となる条件を定めたもので、「この前提が満たされないとこの機能は使えません」という条件をドライバーに確実に伝えるようにするためや、型式認定にも用いられます。
ODD の例として、国土交通省が公開している資料には次のよ
うな条件が示されています。
● 道路条件（自動車専用道路、一般道 など）● 地理条件（山間部、設定済みジオフェンス など）● 環境条件（天候、夜間制限 など）● その他（速度制限、信号情報等のインフラ協調の要否 など）*1:自動運転システムによる対応が難しい場合に、システムが運転をドライ
バーに要求すること

車載ソフトウェアの変化求められる環境想定の精緻化
まず車載ソフトウェアをめぐる状況として、利用環境を想定することの難しさについてお話しします。そもそも環境や利用

車体系
利用環境の想定や制御が比較的容易

状況についての想定は以前から簡単なものではありませんでした。現在、環境想定はいよいよ複雑さを増しています。場所（国）、環境、法令、走行時期（季節や時間帯）といった条件について、それまで人が行っていた判断や操作を、ソフトウェア
でも担うようになってきたためです。

環境想定易

高度運転支援自動運転

他システムとの連携
ドライバーへのテイクオーバー
路上の障害物センサーの精度
天候
環境想定難図1 環境想定の難易度

Veriserve Navigation Vol. 24 | 15

例えば、車線逸脱警告やアダプティブクルーズコントロール

将来的にはこの ODD が利便性や商品競争力につながってい（定速走行・車間距離制御装置）は、センサーがうまく稼働しな

くと思われます。無数にある条件の組み合わせから、適切にいときにメーターなどのインジケーターで「機能しない」こと

ODD を定義することは非常に難しい判断を要します。テスト技

をドライバーに示します。これと同じように、想定されていな術者や品質保証技術者が昔から取り組んできた絞り込みの技術

い条件・場所である場合にもドライバーに伝えることが求めらが、複雑化する環境想定を支える技術として重要になります。

れつつあります。

表 ODD をベースにしたシナリオ（ユースケース）の例

出典 : Tier Ⅳ Tech Blog

https://tech.tier4.jp/entry/2021/04/07/160000

図2 シナリオ（ODD ユースケース）と走行コースの対応（1～13の番号は表の番号に対応）
出典 : Tier Ⅳ Tech Blog

https://tech.tier4.jp/entry/2021/04/07/160000

16 | Veriserve Navigation Vol. 24

これからの車載ソフトウェア開発と品質保証

最初は確実に安全を確保できるような条件のみを環境想定と

図3は、シナリオを階層化し、シナリオの組み合わせによっして定義し、徐々に範囲を広げていくアプローチが一般的と言てさまざまな状況を想定できるようにするためのものです。こえるでしょう。これにはプロダクトを作る側より、品質保証すれは、自動運転を実社会で利用する際に考えなければならない

る側が積極的に ODD の設計に関与していく必要があります。

ことを整理するため、ドイツで発足した産官学共同のPEGASUS
プロジェクトが公表した資料の一部です。

シナリオベースの品質保証

変化の少ないものを1層目として、下から、道路配置（道路ODD で示された条件内で問題がないかどうかを確かめる方法の状態や道幅、車線数など）、標識・路側物、一時的な保守や事として、シナリオベースの品質保証について見ていきます。シ

象（工事や一時的な通行止めなど）、可動物体（他の車両など）、

ナリオを作成し、それを前提として開発したり、品質保証した環境条件（天候など）、V2X *2と、6つの層に分けて条件を考えりする手法が今後、主流になることが予想されます。

ます。これらの層を組み合わせながら、さまざまなパターンでクルマが期待通り動くかをテストしていきます。

表は、ティアフォー社が公開している ODD をベースにしたシナリオ（ODD ユースケース）の一部です。前方に車両がいない場所から発車する、同一車線内を走行する、路上駐車車両や障害物を回避する――といった具合に表の1行ごとにシナリオと対応する走行コースが示されています（図2）。開発も品質保証もこのシナリオとその組み合わせを前提として進めます。

*2: Vehicle to Everything：車車間通信、歩車間通信をはじめとして車両と他のあらゆるモノとの間の相互連携を総称したもの

階層化されたシナリオの組合わせによるテストと品質保証
6層 : V2X情報
5層 : 環境条件
4層 : 可動物体
3層 : 一時的な保守や事象
2層 : 標識、路側物
1層 : 道路配置
図3 シナリオの階層化
https://www.pegasusprojekt.de/files/tmpl/Pegasus-Abschlussveranstaltung/15_Scenario-Database.pdf を元に講演者が一部加筆

Veriserve Navigation Vol. 24 | 17

実車テストドライブシミュレータテスト
シナリオデータベース

シミュレーション

テスト生成

図4 シナリオの条件からテストケースを作成し、テスト実行するフロー
https://www.pegasusprojekt.de/files/tmpl/Pegasus-Abschlussveranstaltung/15_Scenario-Database.pdf を元に講演者が一部加筆

これらシナリオの条件を基にテストを生成し、テスト実行す

時のセンシングが弱点とされています。図5の右側の画像を人る流れを表したものが図4です。左から、シナリオデータベース

間の目で見ると形状などからクルマに見えるのですが、これをにさまざまな各層の条件を入れておきます。条件の組み合わせシステムにクルマだと認識させるのは難しい場合があるため、によってクルマの振る舞いが変わることがありますので、それ現状ではこの LiDAR の情報にカメラやミリ波レーダーから得らぞれのパターンについてテストを生成していきます。これにつれた情報を組み合わせて対象物を判断するセンサーフュージョ

いて実車テストやドライブシミュレータ、計算機上のシミュレンという技術を使って推測することがあります。

ーションでテストを実行します。

多岐にわたる要素技術
車載ソフトウェアの開発および品質保証の在り方が変わりつつある背景には、環境想定の複雑化のほか、自動運転や高度運
転支援を実現するために多岐にわたる要素技術が使われるようになったことが挙げられます。主にセンサー、アルゴリズム、
車外サービスとの連携などです。それぞれについて順番に説明します。

図5 センシングの結果（左：車載カメラ、右：LiDAR）
出典 : Kumar, G A.; Lee, Jin H.; Hwang, Jongrak; Park, Jaehyeong;Youn, Sung H.; Kwon, Soon. 2020.
"LiDAR and Camera Fusion Approach for
Object Distance Estimation in Self-Driving Vehicles"
Symmetry 12, no. 2: 324.

センサー
センサーについては、
LiDAR（Light Detection And Ranging:
レーザー光を用いたリモートセンシング技術）やアダプティブ
クルーズコントロールなどでよく使われるミリ波レーダー、さらにカメラ（単眼・双眼）などがあります。

アルゴリズムセンサーから得られた情報を基に物体を認識するアルゴリズ
ムを図6に示します。

このうち比較的新しいセンシング技術が LiDAR で、センシン

LiDAR の画像に見られた粒の集合（点群）から対象を推測す

グ結果は点群あるいはポイントクラウドと呼ばれる粒の集合にることをクラスタリングと言います。例えば、その形状から対よって得られます（図5右側）。遠距離にある対象物を捉えられ象物がクルマなのか歩行者なのかをクラスタリングにより推測る一方で、カメラのように色を識別できないこと、また悪天候します。そこに LiDAR よりも高い解像度と色の情報を持つカメ

18 | Veriserve Navigation Vol. 24

これからの車載ソフトウェア開発と品質保証

カメラ

LiDAR

レーダー

画像認識
アルゴリズムクラスタリング
アルゴリズム

前走車認識
アルゴリズム夜間はカメラよりも
LiDARの情報に重みを置く

センサー
フュージョン

雨天ではLiDARよりもレーダーの情報に重みを置く

認識結果
図6 センサーフュージョンの仕組み

ラを用いた画像認識アルゴリズムや、レーダーによる前走車認して期待されています。現在は ISO14296に向けて標準化が進識アルゴリズムを加え、これら複数のセンサーの結果を統合しめられています。

て判断していきます。
また、センサーごとに明るさ（時間帯）や天候などへの弱点

新しいタイプの欠陥とその対応や適性があるため（例えば、夜はカメラより LiDAR の方が正確

ここまで車載ソフトウェアをめぐる環境や要素技術についてな情報を収集でき、雨天時や雪の日には LiDAR よりレーダーの見てきました。これまでと同様に要素技術単体に対して故障モ

方が有効）、状況に応じてどの情報に重きを置いて判断するかをード影響解析（FMEA）のような分析をして、単体では問題が決めていく必要があります。こうした統合的な判断を行うのがないことを確認していても、特定の組み合わせだけで不具合がセンサーフュージョンです。実際には非常に難しいところです出たり、考慮すべき点が増えたりということが起こっています。

が、効果的なアルゴリズムが開発されれば、高い価値を生む可

ここ3、4年ほどの間で、こうした不具合や考慮すべき点をサイ能性を秘めています。

バーフィジカルギャップと呼んで、これに対する研究も進められています。

車外サービスとの連携
3番目の要素技術「車外サービスとの連携」
として、ここではダイナミックマップに触れます（図7）。ダイナミックマップは、静的情報である
3次元地図情報に通行規制などの準静的情報、事故情報などの準動的情報、周辺車両や歩行者といった動的情報を組み合わせたデジタル
地図であり、これをネットワークから得ることで自動運転や高度運転支援に活用しようというものです。全体が4つの階層に分かれており、階層ごとに最新情報が反映されます。ダイナミックマップは、センサーが収集する情報より多くの、より詳細な情報をもたらすこと
で、自動運転をさらに安全で精緻にするものと

図7 ダイナミックマップの概念
出典 : ダイナミックマップの概念 / 定義および、SIP-adus における取り組みに関する報告
https://www8.cao.go.jp/cstp/gaiyo/sip/iinkai/jidousoukou_30/siryo30-2-1-1.pdf

Veriserve Navigation Vol. 24 | 19

現実世界をセンシングしてコンピュータ上にモデル化し、モ「単体での妥当性確認」は既存の品質保証の方法である程度対デルの上で分析して最適な結果を導き出し、それを現実世界に応できますが、難しいのは、個々では問題なく見えるにもかか

フィードバックするシステムを「サイバーフィジカルシステム」

わらず、情報取得、物体認識、経路選択といったフィードバッ

と呼びます。この現実（フィジカル）とモデル（サイバー）のクループの中に一つ不具合が生じることによって問題がドミノ

間に「差」が生じることをサイバーフィジカルギャップと呼ん倒しのように後続のフィードバックループに悪影響を与えるケでいます。

ースです。例えば、センサーの一つが故障して自己診断機能が動き始めている間に別のセンサーの精度が落ちると、センサー

例えば、自動運転中のクルマの前方にクルマがある場合のサフュージョンの物体認識アルゴリズムがそれを想定しておらず、

イバーフィジカルギャップを次の①～③で説明します（図8）。

結果として後続の経路選択で実現されている正しい経路選択が行われなくなるようなケースです。
これらはサイバーフィジカルギャップの中でも特に手ごわい①自動運転システムはセンサーから情報を取得します（1. センサーによる情報取得）

不具合で、品質保証の現場ではこのようなコーナーケースをひたすら探して対処する必要があります。私もこうした研究に取②この情報を基に前方の物体をクルマと判断します（2. 物体認識）り組んでいます。

③対 象の位置を時系列で捉えて、前に進んでいるか、
止まっているかを判断します。前方の車両が信号待ちなどで一旦停止しているとして後ろについて停車すべ
きか、駐車しているとして追い越すべきか判断し経路を選択します（3．経路選択）

セキュリティ
セキュリティは基本的に安全性の検証と似ていますが、いくつか異なる部分もあります。
悪意ある攻撃者は次々に新たな脆弱性、新たな手口で攻撃しこの経路選択を間違うこともサイバーフィジカルギャップとてくるため、製品として出荷した後も継続的にこれらに対応し呼ばれる欠陥の一つです。サイバーフィジカルギャップを防ぐていかなければなりません。スマートフォンや PC で随時行わには、まず、センサーやアルゴリズム単体での検証が求められれているセキュリティアップデートのような頻繁なプログラム

ます。センサーが壊れたことをどのように自己診断するか、物の更新が求められます。

体認識の精度、経路選択の妥当性などを、これまでの車載ソフ

また、攻撃対象となる機能の重要性により攻撃のレベルも変わってくるため、対策をどの程度に見積もるのかも難しい問題

トウェアと同じように検証することになります。

モデル（実際には座標をはじめとした情報の集合）
2. 物体認識3. 経路選択

1. センサーによる情報取得

図8 前方にクルマがある場合の自動運転中のクルマの制御

20 | Veriserve Navigation Vol. 24センサーや他の情報からコンピュータ上に 現 実世界のモデルを作る。

これからの車載ソフトウェア開発と品質保証

で、自動運転や高度運転支援のセキュリティを考える上では重要な課題になると予想されます。

どのように開発と品質保証を変えていくべきか

これまで
プロダクト

品質保証
今後

プロダクト

ユーザ、現実世界

品質保証

図9 これからの品質保証のイメージ

より精緻な品質保証と開発プロセス
これまでお話ししたように、自動運転や高度運転支援を前提として車載ソフトウェアは大きく変化しています。品質保証やあります。ハードウェアの開発に携わる企業では、すでに検査開発についても、同時に仕組みを変えていく必要があります。

の自動化はかなり進んでいると思いますが、これからはソフトウェアでも当たり前になっていくと思われます。

まず、プロダクト開発と品質保証をこれまで以上に独立させる必要があります。品質保証は品質保証として、プロダクトはプロダクトとして社会需要やコストに応じた開発をしていくこ

継続的な開発の必要性とが重要です。図9に示した通り、今まではプロダクトに対し車載ソフトウェアの変化に伴い、継続的に開発・品質保証をてその仕様が満たされているかといった品質保証が中心でした

続け、製品（ソフトウェア）に問題がない状態を維持することが、これからはよりユーザーや現実世界の要求に対して品質保が求められるようになります。その典型例は、新たな脆弱性に証がどうあるべきかを考慮することが求められます。

対するセキュリティアップデートが必要になることです。
こうしたソフトウェアのアップデートを積極的に活用して次次にテスト（テストケース）の増加を抑えることも重要です。

のようなことが実現できます。

例えば、派生型の開発をする場合、ある車種に対してテストを行う、次の車種には今までのテストに機能追加、機能変更分を● クルマ購入後に特定の機能を追加購入できるオンデマンド機能

加えてテストを行う、といった手法でテストしていてはテスト● 交通シナリオデータベース（ダイナミックマップなど）の随時更新

が著しく増えてしまいます。従って、まずプロダクトを共通化
し、共通化されたプロダクトの使用を前提とした全体のプロダ
クト群を定義して、それに合わせてテストする「プロダクトラ

このような継続的なリリースを前提として、開発や品質保証のプロセスも変化させていかなくてはなりません。

イン」の考え方を取り入れていかなければテストが肥大化して
いきます。

おわりに

最後に開発プロセス（活動）についてですが、単体テストで検出可能なバグを、実車のテストで検出するようなことがあればここまで、自動運転や高度運転支援を支える技術や課題を大変な手戻りにつながってしまいます。開発プロセスや開発活動

通じて、開発や品質保証に対する新たな要求について俯瞰しごとに、どのような欠陥が混入される可能性があって、それらをてきました。技術の進化に応じてさまざまな工夫が求められる

どのように検出するべきかという想定をこれまで以上にしっかと同時に、継続的な開発・品質保証の重要性も浮き彫りになっりと持つ必要があります。

てきたと思います。
継続的な開発をするには、前提として V 字型開発からアジャ

先ほどシナリオベースの品質保証について説明しましたが、イルに代表されるイテレーティブな開発にシフトしていくこと

他の車両の動きや天候などさまざまな条件を組み合わせてテスが大切であり、私自身も現在ベリサーブ社と共同でこうした開トケースを作り出していきます。これを全て手作業でやるのは発に適した品質保証の在り方について研究しているところです。

現実的ではありません。つまりテストケースの自動生成機能を成果などについてはブログや SNS でも発信していますのでご参前提としたテスト実行の自動化プラットフォームを作る必要が照いただければと思います。

本記事の内容に関するご質問、お問い合わせは、株式会社ベリサーブ 広報・マーケティング部 Email : verinavi@veriserve.co.jp までお寄せください。

Veriserve Navigation Vol. 24 | 21

車載システムの分散・分担開発におけるプロジェクトマネジメントの課題解決に向けて

株式会社ベリサーブ
東日本オートモーティブ事業部 技術部長

冬川 健一

ふゆかわ けんいち

1990年代に株式会社 CSK（現 SCSK 株式会社）にて PC システムの開発や検証業
務に従事した後、2001年に株式会社ベリサーブへ移り、家電や携帯電話など組み込みシステムの検証およびプロジェクトマネジメントを担当。2010年以降は一貫
して、車載システムの開発プロセスやプロダクト検証における品質と効率の改善
提案、業務マネジメントに注力。社外活動では、IT 検証産業協会にて IT 検証標準
工法ガイドの作成などを推進している。

22 | Veriserve Navigation Vol. 24

車載システムの分散・分担開発におけるプロジェクトマネジメントの課題解決に向けてはじめに

車載システム開発プロジェクトの現状

車載システムやその機能が複雑化するに伴って、複数のシスシステム開発の多層化と複雑化

テムユニットやモジュールを組み合わせ、統合して開発される

図1は、車両・システム開発のレイヤーを図示したものです。

ケースが増えています。各ユニットやモジュールの開発は分散最上段の「車両要求」を実現するため、各種システムで役割分した組織によって役割を分担して行われますが、プロジェクト担する設計を行い、そこからユニット設計のために、各ユニッ

全体のマネジメント方法に正解はなく、手探りで開発を進めてトに要求を出します。それぞれの担当範囲として「自動車メー

いるというケースが多いのが実情ではないかと思われます。本カー」「Tier1」「Tier2」とありますが、最近は自動車メーカー

講演ではこのような開発における課題分析の進め方について、が下位のユニット設計を行ったり、Tier1サプライヤーが車体

ベリサーブの事例を基に、各現場で推進可能な取り組みをご紹開発に進出したりと、いわゆる水平分業体制になってきており、

介します。

S
A DA

制動

C AM

操舵

BRK

S

車両要求

STR

BRK

C AM

BRK

STR

C AM

BRK

Ti er1
担当範囲

A DA

自動車メーカー
担当範囲

S

S
STR

モジュール設計

A DA

制動

操舵

A DA

制動

ユニット設計

車両要求

制動

車両要求

C AM

車両要求

調整・修正

テスト実行

操舵

テスト分析～設計

操舵

システム設計

要求・設計・実装

STR

車両コンセプトシステム開発の多層化と責任分担の複雑化が進んでいます。

Ti er2
担当範囲

実装

システム開発の多層化と、責任分担の複雑化
図1 車両・システム開発における開発のレイヤー

Veriserve Navigation Vol. 24 | 23

また、現在はさまざまな部品にソフトウェアが搭載されるよ

ローチおよび手段を指します。左の V 字開発プロセスを例に見うになり、多くの部門が新たにシステムを開発するようになり

れば、自動走行要求を満たす「駆動・制動・操舵」「運転支援」

ました。そのため、システム開発に関わる組織 ・企業の複合化「高精度地図」などのシステムを組み合わせ、さらに「目的別シが顕著になっています（図2）。

ステム」「アプリ・クラウド連携」といった新たな拡張要求を積み上げています。また右の図は、システム・機能・関係組織の

図3は、自動車開発の「システムズエンジニアリング化」に増加による整合界面の増加を示しており、結果として分散組織

ついてまとめたものです。システムズエンジニアリングとは、で分担開発するプロジェクトマネジメントや検証の重要性が高システムの実現を成功させるための複数の分野にまたがるアプ

まる状況になっています。

従来

現在

自部 門

他部門

他部門

他部門

サプライヤ（系列）

他部門

他部門
他部門

自部 門

委 託

委 託

サプライヤ
（他社・海外）サプライヤ（他社・海外）他社

図2 システム開発に関わる組織の変化

他社

PMO・検証：システム組み合わせ・
サービス要求
拡張
要求

自動走行
要求

システム組み合わせ・サービス検証
拡張
検証

自動走行
検証

操舵
動・
・制
駆動
支援
運転
車
・駐
運転
自動
図
度地
高精
ム
ステ
別シ
連携
目的
ウド
クラ
リ・
アプ

複数システムの組み合わせにより実現される各種機能やサービス

業務依頼
システムC

システムZ
システムY
システムX

システムA

自部門
横通し

Tier1

Tier2

機能L

システムB

他部門

機能M

機能K

開発委託 要求仕様

委託・報告
委託
受入

Tier2

Tier1

Tier2

システム・機能増・関係組織増 による整合界面の増加➡PMOや検証ニーズ増 (水色部)

図3 左：複数システムの組み合わせにより要求を実現するプロセス 右：複数システムの組み合わせを実現するための関係組織のイメージ

24 | Veriserve Navigation Vol. 24

車載システムの分散・分担開発におけるプロジェクトマネジメントの課題解決に向けて品質確保に必要な４領域
図4は、プロダクトとプロセス、それぞれの品質を向上するための Validation（妥当性確認）と Verification（検証）をまとめたものです。図右上の「プロダクトの Verification」（仕様通りに作っているかの検証）はベリサーブが従来から取り組んできた業務ですが、最近では同左上の「プロダクトの Validation」（要求を実現できる仕様であるかなどを確認）の重要性が高まっています。
そのためには「プロセスの Validation」（同左下、目的を実現できるプロセスであるかなどを確認）や、「プロジェクトのVerification」（同右下、プロセスを手順通りに実施しているかの検証）を併せて行う必要があります。これが、ベリサーブがたどり着いた品質確保に必要な4領域で、これら全てが満たさ
れないと手戻りや不具合が生じることになります。

Verification

開発プロダクト品質

開発プロダクト品質（V字左側）
妥当性確認

要求

仕様・性能

（V 字右側）

テスト
項目

検証

・仕様通りに作っているか（テスト項目で検証）

開発プロセス品質

開発プロジェクト品質

プロセス

（標準化）

目的

妥当性確認

プロセス
・
手順

・目的を実現できるプロセスか・正確で効率的な手順か

（運営）

チェック
リスト

検証

プロジェクト・要求を実現できる仕様か・要求に応えられる性能か

プロダクト

プロダクト

Validation

・プロセス・手順通りに実施しているか（チェックリストで確認）

図4 品質確保に必要な４領域

Veriserve Navigation Vol. 24 | 25

疑があるなど、異なる課題があることが明らかになりました

プロジェクトタイプの分類（表1）。プロセスの在り方については、部門・チーム・個人によって考えが異なるため、組織や人数が大きくなるほど意見がま

プロセス状況とプロジェクトタイプ

とまらない状況が発生します。

以前、ベリサーブ主催のセミナーにおいて聴講者アンケート

組織・プロセス形態による差異を取ったところ、現状として「開発プロセスが整備されている／されていない」にかかわらず、「困っている」という回答が大組織・プロセス形態による差異もまた、プロジェクトマネジ

半を占めました。私がこれまでに見た現場の事例を分類したとメントの在り方に大きく関わります。図5の「石垣型」「レンころ、整備されているプロセスに対し「古い」「分かりづらい」

ガ・ブロック型」分類は、日本とアメリカ・シリコンバレーそといった声がある他、新たにプロセスを整備することへの懐れぞれの組織特性の違いとして、しばしば紹介されるものです。

プロセス状況

プロセス整備不十分

プロセス整備
されている

上記混合

タイプ分類

状況

分析していない

困っているのはプロセス整備が不十分なせいだと思っている
実際にはそれだけではないが、絞り込みができていないプロセスに懐疑的プロセスを整備したところでうまくいくか疑問だと考えている
複雑な事情が絡み合っている

必要だが大変何をどこまでプロセス定義すべきか難しいと思っている全部詳しい必要はなく、人によって必要なレベルも異なる

古い・合っていない

プロセスが現状の業務にマッチしていないと思っている
更新が必要だがメンテナンスされていない

分かりづらい経験の浅い人は、
プロセスガイドを見ただけでは理解できない
熟練者には理解できるが、熟練者はガイドを必要としない運用できていない

人によって実施のレベルに差異がある
皆がきちんと考えてやればいいだけであるが、それが難しい

上記複合

やるべきことが多く、切迫しているところから対応している

表1 プロセスの整備状況に応じたプロジェクトの課題

石垣型

レンガ・ブロック型

・目的に対する体制や要員数を定義
・各人の能力に応じて役割をアサイン

・目的に対するプロセスやジョブを定義
・ジョブディスクリプションに従い人をアサイン

日本的 組織構成

欧米的 組織構成

国際標準プロセスを適用しづらい

国際標準プロセスを適用しやすい

ジョブのデータ化や生産性計測が難しい

ジョブのデータ化や生産性計測がしやすい

生産性が低くなりがち

生産性を高めやすい

担当者の協力で隙間（ポテンヒット）を埋めやすい

ジョブ定義の隙間が担当者から放置されやすい

ハイコンテクスト（文脈共有前提の文書化）

ローコンテクスト（伝えることは全て文書化）

図5 組織・プロセス形態による差異

26 | Veriserve Navigation Vol. 24

車載システムの分散・分担開発におけるプロジェクトマネジメントの課題解決に向けて黄色の線で囲まれている楕円（だえん）や四角が各要員の業務

まず、プロジェクトの運営状況を理解しやすくするため、運領域を表します。石垣型では、目的に対する体制や要員数を定営のレベルを便宜的に0〜4までの5段階に分類します（図6）。

義し、各要員の能力に合わせて役割をアサインします。一方、レンガ・ブロック型では目的に対するプロセスやジョブを定義し、それらに合わせて要員をアサインするのが特徴です。
日本的な組織構成と言われる石垣型と、欧米的なレンガ・ブ
ロック型、それぞれにメリット・デメリットがあり、単純に優新規システムやプロジェクトの立ち上げ時、支援を必要とする開発現場のほとんどはレベル0、1からスタートします。以下
は、お客様から多く相談が寄せられる0～2の各レベルからのス
テップアップ事例です。

劣を語ることはできません。日本の伝統的な企業では、石垣型のまま連携を強化した組織を作り上げ、企業文化に昇華している例もあります。大切なことは、欧米で生まれた標準プロセスを適用する場合、組織の形態や現状を意識し理解した上でなけ
れば、十分な効果が発揮できないということです。組織構造と課題を見極めた上で対策を検討・適用することが重要です。
この段階では主に、リファレンスプロセス（関係者で共有さプロジェクトマネジメントの課題に対応した事例

れた標準プロセス）が整備できるよう支援します。
● 課題抽出と対策立案

ここからはベリサーブの事例を基に、プロジェクト運営レベ

課題分析は三つのステップで行います。まずは問題や課題、

ルとそのステップアップについて説明します。取り上げるの要望といった事象を洗い出し、システム開発全体をカバーするは、分担・分散開発の体制でシステム設計を行っている自動プロセスの枠組み（Automotive SPICEなど）にマッピングし車メーカーに対して、プロセスのValidationとプロジェクトのます。次に、事象の背景や経緯を確認し、原因の分析と、対策

Verification という2領域で支援した際の事例です。

を講じる領域の特定を行います。最後に、対策を実行するためのプロセスの構築や仕組み作りの計画を立案します。

レベル0 存在しない

リファレンスプロセスが標準的なプロセスの認識が関係者により異なる。
運用も管理も属人的で安定しない。

レベル

リファレンスプロセスは存在するが、標準的なプロセスの認識は共有されているが、運用の仕組みが整備されていない、または適切に運用されていない。

レベル

2 それと比較検証する運用ができている

リファレンスプロセスが存在し、標準的なプロセスはあるが、運用が属人的であるため体制規模が大きくなるとうまくいかないことがある。

レベル

プロセス運用がシステム化プロセスの運用状況が可視化され、体制規模が大きくなっても管理しやすい。

レベルプロセスとプロダクトの関係が変更点に影響するプロセス導出が可能で、業務目的も理解しやすい
理想的な形。

1 運用の仕組みが弱い

3 されて管理されている

4 紐付けされて管理されている

図6 プロジェクト運営レベルのステップアップ

Veriserve Navigation Vol. 24 | 27

● 開発プロセスフローの作成
現場へのヒアリングなどを通じて開発プロセスの現状を調査し、課題への対策を踏まえた上で、新たなフローの全体像（開発プロセス概要）を作ります。その際、主要業務間の関連や実施のタイミングが見えるようにするのがポイントです。次に、開発プロセス概要で定義した業務区分別に、作業の流れや各業
務の INPUT・OUTPUT を理解しやすい形で明記し、プロセス

この段階ではプロセス運用のシステム化を進め、適切に管理された状態を目指します。

を詳細化した詳細業務フローを作成します。
● プロジェクト状況／課題の見える化
残された課題の分類・分析や進捗状況のサマリーなどの可視化、DR（デザインレビュー）の指摘内容分析、業務負荷の分
析・管理を行います。
● プロジェクト運用効率化・業務改善
この段階ではリファレンスプロセスを運用する仕組みの整備について支援します。

計画作成や業務改善、進捗管理、管理ツールの導入、開発成
果物の管理、管理運用ルールの改善に加え、実際に開発業務を進める上で必要となる自動化ツール（比較・検証ツールなど）● 共通・汎用プロセスの運用
会議のファシリテーションや議事録作成、課題一覧の管理、情報の一元管理（各チームへの状況ヒアリング）、期日監視など、比較的一般的な業務支援を行います。これら汎用的な運用の作成などを行い、効率化を支援します。
またレベル2→3の取り組み例として、表2のようなシステム
やツールを積極的に活用します。

支援はどの運用レベルに対しても必要ですが、運用レベルが低い現場においては高い効果が得られる傾向があります。
● 作業概要／ガイドライン／手順書の作成
プロジェクトで実施する作業の一覧や目的、成果物との関連性を俯瞰できる資料、ガイドラインや詳細な作業手順書を作成します。作業領域ごとにこれらの資料を作成することで、組織標準が作られていない石垣型組織でも各領域の作業を標準化しやすくなります。
● 教育プログラム作成／教育事務局／運用・改善
リファレンスプロセスに関する資料や、テストに関連の深い「システム開発」部門などに存在する資料を基に、教育資料を作成します。その後、それらの資料を使い、教育事務局として新プロセス・プロジェクト領域の活用ツール例（当社例）

要求管理・ALM 系

Integrity, DOORS, ConTrack

構成管理

Git, SVN

タスク管理

Jira, Redmine, iQUAVIS

成果物管理

SharePoint, Conﬂuence,
Lotus Notes

不具合管理

Redmine, QualityForward

BI ツール

Qlik Sense

表2 運用レベルアップに役立つシステムやツールの一覧

規参画メンバーに対する「集合教育」を実施することで、メンバーのプロセスに対する理解の底上げを図ります。

さらに Automotive SPICE のアセッサーや TUV-SUD の機能
安全の資格保有者、PMI プロジェクトマネジメントの資格保有者などによるプロジェクト支援は、上記レベルのどの段階にあるかに限らず有効です。

28 | Veriserve Navigation Vol. 24

車載システムの分散・分担開発におけるプロジェクトマネジメントの課題解決に向けて期待される取り組み効果
このような支援により実施された対策によって得られた効果の例を挙げていきます。

1

組織・グループ別の課題が見えてくる

おわりにここまで見てきた対策は、決して全てのケースに対応するわけではありませんが、課題に対して偏りの少ない適切な分析を可能とするために、ひととおりを検討範囲とすることは重要でプロセスの標準化に取り組むこともできないような「忙しすす。また、組織の階層や役割の垣根を越えた課題に対応するにぎる」組織においては、課題が見えづらくなっています。このは、第三者による客観的・俯瞰的な課題の「見える化」が有効ような組織が抱える問題も課題分析などを通して見えやすくなです。最後に、多くの方は過去の経験の延長で今日の業務を行ります。

うため、新たに整備したプロセスがプロジェクトでの日々の経験として定着するよう業務に活かすことが重要です。以上を踏

2

課題領域を絞り込める対策の実施前は QCDの「品質」と「成果物納期」がともに良くまえながら、プロセスの妥当性とプロジェクト運営のレベルをステップアップしていくことをお勧めします。

ない状況だったのが、レビューの仕組み改善などにより品質の網羅性が高まったケースがあります。つまり課題が「期限」に絞り込まれた（課題を寄せることができた）ことになります。

3

プロセス運用支援チームによるトレーナー的活動で、開発者の負荷が軽減できる

トレーナー的活動では、主に次の工程・組織への移行断面での課題の取りまとめや対策の推進支援を行います。

4

標準規格への適合が容易になるプロセスが整備されると業務エビデンスをトレースしやすくなるため、標準規格への適合が容易になります。

5

関係する会社・組織間で、それぞれのプロセスの差異が埋めやすくなる

他社・他組織のプロセスと差異がある場合でも、相違点を可視化し、整合方法の検討・運用が可能になります。

本記事の内容に関するご質問、お問い合わせは、株式会社ベリサーブ 広報・マーケティング部 Email : verinavi@veriserve.co.jp までお寄せください。

Veriserve Navigation Vol. 24 | 29

車載セキュリティテストに関する
ベリサーブの取り組み

株式会社ベリサーブ

長谷川 邦幸はせがわ くにゆき

ソリューション事業部 サイバーセキュリティ第一ビジネスユニット
2019年 株式会社ベリサーブ入社後、企業ネットワークの脆弱性テストや I oT
機器のセキュリティテスト、リスク診断などに従事。現在は ISO /SAE 21434のプロセス構築の支援を担当している。CISSP、認定ホワイトハッカー（CEH）、情報処理安全確保支援士。

30 | Veriserve Navigation Vol. 24

車載セキュリティテストに関するベリサーブの取り組み

はじめに

自動車業界については、最近の傾向として、サイバーセキュ
リティに関する協定規則（UN-R155）への適合および ISO/SAE

自動車業界はCASE（Connected, Autonomous, Shared &21434への準拠に関するご相談を多くいただいています。

Services, Electric）の時代を迎え、クルマとその周辺システムの開発は複雑化が進み、セキュリティに対するリスクも増大し2020年6月、国際連合欧州経済委員会自動車基準調和世界ています。

フォーラム（WP29）において UN-R155が採択されました。
日本においても、UN-R155に適合するための法改正があり、ベリサーブでは2005年からセキュリティ事 業を展 開して無線によるソフトウェアアップデートに対応した新型車両につおり、車載システム関連についても日々充実を図っています。

いては2022年7月から適用されます（継続生産車は2024年7

図1は、クルマの開発を取り巻く状況と当社のサービスを図式

月から適用）。

化したものです。品質向上と効率向上というお客様のご要望にまた、車両電気電子（E/E）システムの開発に関わる OEM、

対して、プロダクト品質支援、プロセス品質支援、そして三つ

サプライヤー向けのサイバーセキュリティのガイドライン規格

目のサービスとして、セキュリティ支援を提供しています。

として、ISO/SAE 21434:2021が2021年8月31日に発行されています。

このようなサービスを提供するに当たり、経済産業省の情報
セキュリティサービス基準審査登録制度に申請し、審査登録委

本講演は、UN-R155認証取得の手段として多くの企業が適員会の審査を経て一定以上の品質を満たした脆弱性診断サービ

合を進めている自動車のサイバーセキュリティに関する ISO/スの提供ベンダーとして登録しています。またセキュリティにSAE 21434という規格の概要より、セキュリティテストの位関するサービスを提供する部門において、情報セキュリティマ

置付けを確認し、その具体的なテストの手法であるペネトレー

ネジメントシステムの認証規格である JIS Q 27001:2014

ションテストとファジングについて、当社の実践例をご紹介し（ISO/IEC27001:2013）認証（ISMS 認証）を取得しています。

たいと思います。

背景
協調動作の増加

開発の高度化・複雑化

各ECU間の協調
車車間･路車間協調

先進安全・自動運転・IoT
短期間での開発

テストに対する負荷の飛躍的増加

他部門･外部サプライヤー･ステークホルダーの増加

開発遅延･手戻り･品質リスクの増加

お客様のご要望：自動車/システム開発での

品質向上

効率向上

プロダクト品質支援

プロセス品質支援

セキュリティ・その他

要求仕様書品質向上支援

テストプロセス診断

車載サイバーセキュリティ検証

動的検証（テスト設計-実行）

テストプロセス構築支援
ASPICE準拠支援

テスト環境構築・自動化支援
データコレクション・評価サービスなど

プロジェクト推進支援PMO など

QualityForward
TESTRUCTURE
ConTrackなど

ソフトウェアテストの知見ノウハウを生かし、品質・効率向上へ貢献するサービス提供
図1 車載開発に対してベリサーブが提供するサービス

Veriserve Navigation Vol. 24 | 31ISO/SAE 21434の概要

開発のフェーズに特化した部分を少し掘り下げてみましょう（図3）。まず9章のコンセプト（Concept）には、OEM がクル*1

ISO/SAE 21434 では、クルマの企画から製品開発、運用、マを企画する際の要求が定義されています。「9.3 アイテム定廃棄に至るライフサイクル全般に及ぶサイバーセキュリティ要義」では、車両の中のアイテム、例えば自動運転などを定義し、求が定義されています。1～4章が概要、5～15章が要求事項とその機能やアーキテクチャを考えます。次の「9.4 サイバーセキュ

いう構成になっており、これを実際のライフサイクルとの関係

リティゴール（Cybersecurity goal）」では、アイテムに対して脅

性に合わせてマッピングしたのが図2です。

威分析・リスクアセスメントを実施してリスクに対する必要な

図2 ISO/SAE 21434の章立てと自動車ライフサイクルの対応

コンセプトフェーズ
9.3
アイテム定義9.4
サイバーセキュリティゴール

9.5
サイバーセキュリティ
コンセプト

脅威分析・リスクアセスメント
資産識別
脅威シナリオ特定
インパクト評価

攻撃経路分析
攻撃実現可能性の評価

リスク値の決定
リスク対応の決定

図3 ISO/SAE 21434におけるコンセプトフェーズでの要求事項*1: 本記事の ISO/SAE 21434の日本語訳については、以下の日本規格協会の訳を参考にしている。
ISO/SAE 21434:2021 自動車－サイバーセキュリティエンジニアリング https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=ISO%2FSAE+21434%3A2021

32 | Veriserve Navigation Vol. 24

車載セキュリティテストに関するベリサーブの取り組み

対策と目標を設定し、最終的に「9.5 サイバーセキュリティコン
セプト（Cybersecurity concept）」
で機能サイバーセ キュリテ
ィ要求（FCR：Functional cybersecurity requirement）
を作成します。

ペネトレーションテスト
ペネトレーションテストは攻撃者の視点からシステムを調査し、実際に侵入を試みるテスト手法です。図5は、アメリカ国
立標準技術研究所（NIST）の「SP 800-115 Technical Guide

OEM が作成した FCR が自社の開発部門もしくはサプライヤ

to Information Security Testing and Assessment」からのーに渡り、10章の製品開発フェーズに入ります（図4）。「10.4.1

引用で、テストのプロセスを示しています。最初に攻撃の計画設計」では、FCR の実装を考慮した技術サイバーセキュリティを立案、システムの弱点を探索して攻撃を行い、その結果を分要求（TCR：Technical cybersecurity requirement）を作成

析して攻撃を繰り返し、脆弱性を検証します。

しますが、この際に脆弱性分析を実施します。ここでは、攻撃の経路を検証する攻撃経路分析、攻撃実現可能性の評価などを実施し、リスクに応じて設計の見直しを行います。
設計においてサイバーセキュリティ面で問題がないと判断したら実装に移り、「10.4.2 統合及び検証」
でセキュリティテストを実施します。ここでは5種類のテストが定義されていますが、 本講演では名前だ
けではその内容が想像しづらいと思われるペネトレー
ションテストおよびファジングについて詳しく解説します。

図5 ペネトレーションテストのプロセス
出典：アメリカ国立標準技術研究所 情報セキュリティテスト、アセスメントの技術的ガイド(https://csrc.nist.gov/publications/detail/sp/800-115/final)を元に一部加筆

製品開発フェーズ
10.4.1
設計

10.4.2
統合及び検証脆弱性分析

セキュリティテスト

攻撃経路分析
攻撃実現可能性の評価

セキュリティ機能テスト
セキュアコーディング
脆弱性スキャン

ファジング
ペネトレーションテスト

図4 ISO/SAE 21434における製品開発フェーズでの要求事項

Veriserve Navigation Vol. 24 | 33

ペネトレーションテストは、必ずしもブラックボックスで行う必要はありません。
「 ISO/SAE 21434 Annex E サイバーセキュリ
ティ保証レベル」では、攻撃者はターゲットに対してある程度の知識を持っていると想定しています。また、攻撃者側にはある意
味無限に時間がある一方、お客様やベリサーブのようなベンダ
ーはテストの時間が限られています。そのため、攻撃者が時間をかければ見つけられるレベルの情報は事前に開示し、その上で攻撃を実施するグレーボックステストというのが、一番費用対効果が高いと私たちは考えています。

ファームウェアの抽出
チップを外すための道具としてヒートガン、はんだごて、ペンチ、ピンセットを用意します。まずヒートガンで基板に熱を加えてハンダを溶かし、チップを分離します。チップの接合面に汚れが付いていると読み取りに支障が出るため、なるべくキレイにしておくのも一つのポイントです（図6）。
チップをアダプターにセットし読み取り装置に取り付け、USB
で PCと接続し、ツールを利用してファームウェアを抽出します（図7）。

ペネトレーションテストの実践例
ここからは、車両の ECU を対象としたペネトレーションテストの一例をご紹介します。クルマから ECU を抜き取り、さらに中の基板からチップを外してファームウェアを抽出し、ファーム
ウェアから得た情報をもとに攻撃を行うことを想定しています。

図6 ECU の基板よりチップを取り出す様子⑤②

ソフトウェアでチップからファームウェアを抽出するアダプターを本体にセットし、 USBで本体とP Cを接続④①

アダプターにチップをセット

このボタンの押下で読み込み開始③

ファームウェアの抽出を行う
図7 取り出したチップよりファームウェアを抽出する様子

34 | Veriserve Navigation Vol. 24

車載セキュリティテストに関するベリサーブの取り組み

ファームウェアの解析
図8は、セキュリティテストによく使われる「Kali Linux」の画面で、ここに含まれる「binwalk」というツールでファーム*2

ウェアのイメージファイル を解凍しファイル・ディレクトリ
の一覧として表示しています。この図では重要な設定ファイルの「IDA Pro」というツールを使ってアセンブリコードから脆弱性を探したり、バイナリファイルに含まれる OSS（Opensource software）を Synopsys 社の「Black Duck」などのツールで特定し、既知の脆弱性について検索したりして、見つかった脆弱性を利用した攻撃を行います。

などが配置されることの多い”/etc”というディレクトリの内部を表示しています。当該ディレクトリに存在するテキストフ
ァイルに機微な情報が含まれていればこの時点で読めてしまい
ますし、また、バイナリファイルを入手して中身を解析することも可能です。

ファジング
既知の脆弱性というのは氷山の一角に過ぎず、実際にはそれをはるかに上回る数の未知の脆弱性が存在します。ファジング
は、こうした未知の脆弱性、潜在的な脆弱性を発見するためのテスト手法です。

*2 : 外部記憶装置に保存されているすべての内容を、ディレクトリ構造を保ったまま一つのファイルとしてまとめて保存したもの。

具体的には、ファズ（予測不能な入力データ）をシステムに与えて意図的に例外処理を発生させ、その挙動を確認します。
ファズの例としては、プロトコル上の標準や製品の仕様を満た

脆弱性調査とエクスプロイトコード
ファームウェア内のファイルが入手できたら、脆弱性を見つさない、あるいは違反するデータで、極端に長い文字列や上限を超えた数値、許可されていない特殊文字などが挙げられます。

けてエクスプロイト（攻撃）コードを作成し、実際に攻撃を試みます。システムの脆弱性調査の場合、スクリプトファイルをファジングの種類と検出できる問題

解析して得られた暗号化アルゴリズムから復号用のスクリプトの作成や、パスワードを暗号化して記述しているシャドウファ

ファジングで代表的なのはプロトコルファジング・ファイル

イルが見つかればブルートフォース（総当たり）攻撃を実行す

ファジング・API ファジング・UI ファジングの四つで、いずれるなどして、パスワードの解析を試みます。

も要求された仕様を逸脱するデータを投入するものです。このうちプロトコルファジングについては、業界ごとにさまざまなバイナリファイルに対しては、同じアーキテクチャ上で動作させデバッガで解析することもできます。また、Hex-Rays 社

通信プロトコルが使われているため、製品でどのようなものが使われているのかを把握しておくことが大事です。

図8 ファームウェア内のファイル・ディレクトリの一覧

Veriserve Navigation Vol. 24 | 35

図9は、Ari 他 (2018) の「Fuzzing for Software Security
Testing and Quality Assurance, Second Edition」p.29 のFigure1.10に記載されたファジングで検出できる問題の一覧です。実際のテストでは crashes（クラッシュ）や Denial ofService（DoS、サービス拒否）、つまりプログラムやシステム
が異常終了もしくは無反応になる、といったものが多くを占めます。

ファジングを実施する前に検討すべき事項

監視方法
どのような問題を検出するのかを事前に決めておくことが重要です。監視にもツールを利用できますが、自動での判定には限界があるため、やはり人による確認が必要になります。一般
的には三つの方法があります。検出する問題について最適なものを組み合わせることをお勧めします。

● システムモニタリング（システム内プロセス、ログの監視）➡検出する問題：クラッシュ

ファジングについては、対象とするインターフェース、送信するファズの内容、結果の判定方法が重要なポイントとなります。

● リモートモニタリング（ネットワーク応答の監視）➡ 検出する問題：サービス拒否、性能低下、応答遅延、機密情報の漏えい対象インターフェース & プロトコル
機器の持つインターフェースを列挙し、検討漏れがないよう● アプリケーションモニタリング（デバッガなどによるアプリ動作の監視）にします。また、そのインターフェースで使われるプロトコル➡ 検出する問題：改ざん、破棄、異常に違反し例外を出す必要があるため、プロトコルの仕様も確認します。

脆弱性スキャンとの違い
ファズデータの種類

脆弱性スキャンは既知の脆弱性を発見するのが目的で、入力

ファズデータはツールでの生成も可能で、車載関連では

インターフェースやコンソール内でのスキャンを実行します。

Synopsys 社の「Defensics」などが多く使われています。適一方、ファジングは未知の脆弱性の発見を目的に、入力インタ

切なデータを生成するために、ツールに任せるだけではなく、ーフェースに対して例外データを送って反応を確認します。こ人の観点での補足も大事です。

の点が二つのテスト手法の違いです。

カテゴリ※

問題の概要

crashes[クラッシュ]

ファジング対象のプログラム、システムが異常終了する

denial of service(DoS)[サービス拒否]

ファジング対象のプログラム、システムの一部機能が無反応となる

security exposures[機密情報の漏えい]

ファジング対象のプログラム、システムのファズに対するレスポンスに、機微な情報が含まれる

performance degradation[性能低下]

ファジング対象のプログラム、システムの処理能力が低下する

slow responses[応答遅延]

ファジング対象のプログラム、システムのレスポンスが遅くなる

trashing[改ざん、破棄]

ファジング対象のプログラム、システムの設定が意図せず変更、削除される

anomalous[異常]ファジング対象のプログラム、システムで、上記以外の異常な振る舞いが発生する（例えば、スタックオーバーフロー）

図9 ファジングで検出できる問題※参考：書籍「Fuzzing for Software Security Testing and Quality Assurance, Second Edition」p.29

36 | Veriserve Navigation Vol. 24

車載セキュリティテストに関するベリサーブの取り組み

おわりにファジングテストの実践例
図10は、実際のファジングテストの様子です。「Defensics」が動作する PC をターゲット機器とアダプター経由で接続し、ファズを送信して反応を確認します。アダプターを交換することで、さまざまな機器のファジングが可能です。

図11は、ISO/SAE 21434の要求とベリサーブが提供するサービスの対応表です。全体的なコンサルティングから PSIRT 支援、個別の脅威分析・脆弱性分析やテスト支援まで幅広く対応
していますので、ご興味がございましたら、ぜひお声がけいた
だければ幸いです。当社の35年以上に及ぶ検証分野での実績と技術を生かし、今後も品質・安全・セキュリティの三つの要素を守るため、より良いサービスを継続的に開発・提供していきます。

ターゲット機器

Synopsys 社
Defensics

図10 ファジングテストの様子

No.

1

サービス名

システム提供実務支援

ISO/SAE 21434コンサルティング△〇

規格全体をカバー（規程策定・運用）

ISO / SAE 21434 要件

2

PSIRT支援〇〇8.3 サイバーセキュリティ監視
8.4 サイバーセキュリティイベントの評価
8.6 脆弱性管理
13.3 サイバーセキュリティインシデント対応

3

脅威分析／脆弱性分析

×〇

8.5 脆弱性分析
15. 脅威分析及びリスク評価手法

4

セキュリティテスト

△〇[RQ-10-09] 実装・統合のサイバーセキュリティ仕様充足を検証

5

脆弱性スキャン

△〇[RC-10-12] 未確認のウィークネス（弱点）・脆弱性の確認[RQ-11-01] 妥当性確認活動

6

ファズテスト（ファジング）〇〇[RC-10-12] 未確認のウィークネス（弱点）・脆弱性の確認[RQ-11-01] 妥当性確認活動

7

ペネトレーションテスト

×〇[RC-10-12] 未確認のウィークネス（弱点）・脆弱性の確認[RQ-11-01] 妥当性確認活動

8

セキュアコーディング準拠支援〇〇[RQ-10-05] 設計・コーディングルール

図11 ISO/SAE 21434の要求・推奨とベリサーブの提供する支援サービスとの対応

本記事の内容に関するご質問、お問い合わせは、株式会社ベリサーブ 広報・マーケティング部 Email : verinavi@veriserve.co.jp までお寄せください。

Veriserve Navigation Vol. 24 | 37

トレーサビリティ管理ツールをもっと実践的に使いこなすには～ 規格対応のため「だけ」から、
品質・生産性向上のために～株式会社ベリサーブ
プロセスエンジニアリングサービス開発部 プロダクトサービス開発課 課長

横田 浩行

よこた ひろゆき2009年 株式会社ベリサーブ入社。大手電機メーカーのプロジェクトなどで QA エン
ジニアを務めた後、新規事業の企画・推進に従事。その後はトレーサビリティ管理
ツール「ConTrack」の企画・開発を主導するなど、システム開発全体の QCD 向上のためのソリューションの開発に注力。この間、
ソフトウェア開発に関する独立行政法人
情報処理推進機構（IPA）の標準化・制度検討部会にも参画している。

38 | Veriserve Navigation Vol. 24

トレーサビリティ管理ツールをもっと実践的に使いこなすには～規格対応のため「だけ」から、品質・生産性向上のために～はじめに車載システム開発では、この10年で要求管理ツール（いわゆるトレーサビリティ管理ツール）の導入が進みました。しかし、2010年代後半に入ると、シンプルで使い勝手の良いタグベースの要求管理ツールが登場しました。使い慣れた Word や
Excel がそのまま使えることもあってそれなりに普及しました
が、導入の主目的はやはり規格への対応でした。

規格への対応という当初の目的に沿った利用にとどまり、品質改善や生産性向上といった効果につなげられていないケースがその規格対応もこの2～3年で一段落したようで、最近では少なくありません。本講演では、代表的な要求管理ツールを比

品質や生産性の向上といった、より本質的な改善効果を期待較・分析した上で、より本質的な改善に導くツールの活用方法

して要求管理ツールの導入を検討するお客様が増えています。

について、事例を交えて解説します。併せて、ベリサーブが提以下ではまず、代表的な要求管理ツールの種類と特徴を見て供するトレーサビリティ管理ツール「ConTrack」についてもいきます。

ご紹介します。

要求管理ツールとは
要求管理ツールとは、定義された要件がどのような工程を経て設計やソースコードへ落とし込まれているかを追跡、可視化するものをいいます。要求管理の主な目的は次の三つです。①
要件と設計の整合性の確認（一貫性）、②要件の全てが設計に反映されているかの確認（完全性）、③設計の変更による影響の明
確化（影響分析）。一般的な要求管理ツールは、これらを実現する機能を備えています。

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

日本での要求管理ツール普及の背景かります。

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

構成管理

変更管理
ALMツール
要求・仕様記述

の“保管庫”の扱いにとどまっていました。

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

Veriserve Navigation Vol. 24 | 39

Excel

しかし、多機能なだけに「きちんと使いこなす」ことが非常

たいていの PC にインストールされている Excel（図２）は、導入や習得コストが事実上ゼロである点が最大のメリットです。
要求管理ツールを提供するベンダーにとっては最強のライバルといえます。
しかし、 Excel はそもそも要求管理の専門ツールではないた
め、できることはマトリクスや展開表の記述がせいぜいで、N 対
N のような複雑な関係性の表現は困難です。構成管理や変更管理といった他のシステムとの連携も皆無なため、要求の追加や変更などの追従が全て手作業となり、 大変な手間がかかります。

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

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

要求管理

一方で、機能を変更・追加すると ID の情報が変更になるため、差分開発やバージョンアップ開発が進むほどにタグをメン
構成管理

変更管理

テナンスする負担が大きくなります。また、トレースの可視化に特化しており、他のツールとはデータ連携にとどまり緩やかな結合になっています。従って、ALM を実践するには運用プロ

要求・
仕様記述

セスを工夫する必要があります。

図2 Excel を要求管理に用いる場合のイメージ
デフル ALM 型
Excel とは逆に ALM に必要な全ての機能を含むものがフルALM 型（図３）で、きちんと使いこなせれば大きなメリットが

連
タ
ー

構成管理

携

要求管理

デ

ー
タ
連

変更管理

密結合

要求・仕様記述得られます。
など

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

要求管理

構成管理

変更管理

要求・
仕様記述

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

40 | Veriserve Navigation Vol. 24

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

軽量 ALM 型

ツリー構造型

ツール自体の機能は要求管理のみですが、構成管理や変更管システムの要求が機能へとシンプルに分解されて1対 N の関理はオープンソースソフトウェア（OSS）とのシームレスな連係になる構造です。新規開発やフルスクラッチなど、これから携で統合的に ALM を実現します。要求・設計は Word や Excel

新しいものを作る場合に多く見られます（図6）。どの要求がどから取り込み可能で、慣れ親しんだ開発プロセスをそのまま維の機能で実現されるかが分かりやすく、小規模なプロジェクト持できるので導入も容易です（図５）。ベリサーブが提供するであれば Excel でも表現できます。

「ConTrack」はここに分類されます。
要求2

要求1

あえて課題を挙げるなら、派生・保守開発を行わない単発の要求3

プロジェクトでは、導入時のフォーマット検討などの負担があり費用対効果が得られにくいことです。

設計

設計

機能G

設計

設計

設計

機能 F

設計

機能 E

設計

機能D

設計

設計

変更管理

設計

合

設計

密結合

結

設計

構成管理

密

機能C

設計

結

要求管理

機能B

設計

密

合

機能A

図6 ツリー構造型要求展開のイメージ要求・仕様記述
ネットワーク構造型など

要求と機能が N 対 N の複雑な関係になる構造で、機能改良や
図5 他システムとのシームレスな連携で ALM を実現する
軽量 ALM 型ツール

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

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

要求2

要求1

要求3

ここまで、要求管理に使われるツールを特徴ごとに分類し比較してきました。「さまざまな種類があることは分かったが、結
機能D

設計

設計

設計

機能 E

機能 F

機能G

設計

機能C

設計

機能B

設計

機能A

設計

局、自分たちのプロジェクトにはどれが適しているのか」と思う方もいらっしゃるでしょう。ツールの特徴の他に、もう一つの判断基準となるのが要求とそれを実現する機能の関係性に着

設計

設計

設計

設計

設計

設計

設計

目した、開発における要求展開の構造です。大きく次の二つに分類されます。

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

Veriserve Navigation Vol. 24 | 41

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

システムライフサイクル：長いフル AL M 型

軽量 AL M 型
要求管理

要求管理
構成管理

構成管理

変更管理

ツリー構造

要求・
仕様記述

ネットワーク構造

など

要求管理

構成管理

変更管理

要求・仕様記述

要求管理
構成管理

変更管理

変更管理

要求・仕様記述

要求・
仕様記述

など

Excel
要求管理特化型

Excel

システムライフサイクル：短い
図8 要求管理ツールの適用マップ

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

要求管理

構成管理

● 直感的に簡単に文書を関連付け● システム開発検 討 経 緯の可視化

ReqIF
Adapter● 文書のバージョン・変 更 履 歴を詳細に管 理● ブランチ、ベースライン管 理により文書の探索・流 用・作成を支 援

変更管理

構成管理

Subversion

変更管理

文書解析エンジン

Redmine● 多種多様なファイルフォーマットに対応● 既存の開発成果 物をそのまま登録・管 理

Outlook

Text

PDF

MATLAB ／Simulink

ReqIFEnterprise Architect

図9 ConTrack の機能概要

42 | Veriserve Navigation Vol. 24

なぜ？どうやって？
正しいのか？
“変更”に関わる全ての活動履歴を一元管理
Jira Software

文書解析
エンジン

ロール管理

変更
要求
変更の
変更の
V&V 変更管理 検討

プロセス

変更の
実装

ロール管理
ユーザ 特 性ごとに利用可能な機能・範囲・編集 権限を設 定可能

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

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

事例1”超上流 ”での品質向上 ～自動車業界サプライヤー＜課題＞
メーカーから最初に提示される要求仕様は曖昧で未確定な部分が多く、その後のコミュニケーションによって要求を固める形を取っている。ただ、仕様書・Q ＆ A 表・会議の議事録・メールなど、変更要求の形式がバラバラで情報が散在しているため、要求の矛盾に気付かないまま開発が進んでしまい、テスト工程で手戻りが起きることもあった。
＜導入後＞さまざまな形式で提示される変更要求を ConTrack で一元管理し、要件定義モデルや基本設計モデルとつなげていく。これにより、
過去から現在までの変更要求の経緯が可視化でき、 整合性が確保されて、後工程からの手戻りを大幅に減らすことが可能になった（図10）。

変更要求の形式がバラバラ
要求仕様書

メール

Q&A

超上流の
「なぜ」
「なに」を
追跡可能
でのトレーサビリティ管理イメージ

会議議事録

システム要求Q&A

要求仕様書

システム要求

メール
会議議事録

変更要求

要件定義

要求モデル

要件定義

USDM

基本設計

仕様モデル

“超上流” 起因の手戻り・・
・

基本設計

詳細設計

実装

超上流からの品質不具合作り込み防止へ

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

Veriserve Navigation Vol. 24 | 43

事例2

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

汎用仕様

機能
要件

設計

更

実装

機能
要件

更
設計

更
実装

変更要求
仕様

派生 A

一定期間ごとにまとめてマージ

変更要求
仕様

派生B

変更要求
仕様

派生C

変更要求
仕様

派生D

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

汎用仕様

機能
要件

設計

派生 A

更
更
変更要求 機能
設計
仕様
要件

更

実装

実装

派生B

更
更
変更要求 機能
設計
仕様
要件

変更要求
仕様

実装

派生C

設計

関数 A
関数 B
関数 C
関数 D
関数 E

関数 A
関数 B
関数 C
関数 D
関数 E

更
更
機能
設計
要件

更

実装

派生D
変更要求
仕様

実装

更
更
機能
設計
要件

更

実装

・変更要求仕様と機能要件をひも付けることであらかじめ変更箇所を特定しておく
・都度、汎用仕様や別の派生ラインへのマージを行う➡メンテナンスコストの爆発的増大を防ぐ➡ 各ラインで別々に同じ検討をしないようにする

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

44 | Veriserve Navigation Vol. 24

更実装

共通部分の変更は関連ブランチを探索してマージ

更

変更要求
仕様

機能 A
機能 B
機能 C
機能 D

更
設計

その都度、マージ

更

機能要件

機能
要件

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

ConTrackの新機能「ReqIF Adapter」
2021年6月にリリースしたConTrackの最新バージョンには、欧州の自動車メーカーやメガサプライヤーと取引する日本企業を支援する新機能「ReqIF Adapter」が追加されています。
欧州ではフルALM型要求管理ツールを採用する企業が多く、日本の取引先にも同じツールでのやり取りを求めるケースが増えています。取引先が1社なら指定のツールを導入すれば良いのですが、複数の欧州企業と取引する場合にそれぞれ別のツールを用意するのはコスト面で大きな負担になります。
「ReqIF」は米国の標準化団体による規格で、異なる要求管理
ツール同士で要求や設計の情報をやり取りできるフォーマット
です。ReqIF AdapterはConTrackでReqIFのインポート／エクスポートを実現する機能で、以下のようなことが可能になります（図13）。

おわりに
ConTrackは、ほぼ年1回のペースでメジャーアップデートを行っており、2021年はReqIF Adapterの他にフローティング
ライセンスを追加、より柔軟な導入を可能にしました。フローティングライセンスとは、複数のメンバーで同一のソフトウェ
アを共用するための使用許諾契約（ライセンス）方式をいいます。ライセンスはサーバーで運用し、ネットワークで接続されたパソコンからライセンス数の範囲内でソフトウェアを同時に利用できます。これにより、利用するユーザ全員分のライセン
スを購入する必要がなくなるメリットがあります。
日本発の製品という強みを活かし、日本の開発現場をより良くするための改良を今後も続けていきたいと考えています。
※ConTrackの詳細については、https://www.veriserve.co.jp/
service/detail/contrack.htmlをご参照ください。

● ReqIFの 要求を ConTrack に 取り込 み、それ に 基 づ いて

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

OEM ／メガサプライヤー（欧米）

サプライヤー（日本）

ReqIF
サプライヤーへの要求情報のみ他社要求管理ツール

ReqIF
設計・テスト結果の情報
設計・テスト結果と要求のトレース

ReqIF
Adapter

設計書（Word／Excel など）① 読み込みReqIF② 設計書などの
読み込み

ReqIF

③ 要求をトレース④ 出力

設計・テスト結果とテスト
結果（Word／Excel など）

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

本記事の内容に関するご質問、お問い合わせは、株式会社ベリサーブ 広報・マーケティング部 Email: verinavi@veriserve.co.jp までお寄せください。

Veriserve Navigation Vol. 24 | 45

2021 年 11 月号