１６
２

Ｓ・ベッカーPartⅠ「欧州レスポンスプロジェクト」

特別講演４

高度運転支援システムにおけるヒューマンファクター
ステファン・ベッカー＊        

＊＊ フォード社電気電子システム部門技術スペシャリスト

ＴｅｃｈｎｉｃａｌＳｐｅｃ
ｉａｌｉｓｔ，Ｈｕｍａ
ｎＦａ
ｃｔ
ｏｒｓ，Ｅ
ｌｅｃｔ
ｒ
ｉ
ｃａｌａｎｄＥ
ｌｅｃｔ
ｒｏｎｉ
ｃＳｙｓｔ
ｅｍｓ,
ＦｏｒｄＷｅｒｋｅＡＧ，Ｇｅｒｍａｎｙ
ケルンのＴＵ̈Ｖで約１０年間、安全運転支援装置のユーザー受容性等の研究に従事する。２００２年に欧州Ｆｏｒｄに移り、現在、電気電子システムエンジニアリング部門の技術スペシャリスト。
ＥＣのレスポンスプロジェクト２で、全体の取りまとめ責任者を務める。

欧州レスポンスプロジェクトのなかから、特にヒステムの安全性、信頼性、あるいは技術の信頼性・ューマンファクター（人間的要因）についてご紹介し安全性ということについて、あらゆる要因が影響をます。

与え合っているので、その要因をすべてコントロー

先ほど、システム及び法律の観点からＡＤＡＳの説ルしなければなりません。まずは、ユーザーとシス明がありましたが、私の話は、対象は同じですが視テムのヒューマンファクターという側面です。欠陥点が異なります。

製品か、あるいは安全な製品かということに関連しまず、ヒューマンファクターと製品の受容性につて、ユーザーと製品のシステム要件に関してのヒュいてですが、ＡＤＡＳの安全性が二つの方向に向かっーマンファクターについて紹介したいと思います。ていることを理解してください（Fig.1）。一つは機次に、第二点としては、開発プロセスにおけるヒュ能面での安全性、つまり、ドライバーがその製品をーマンファクターの側面です。重要なのは、ヒュー使って何をするのか、製品、あるいはシステムとドマンファクターという観点から見た時に、ただ単にライバーの間に、どのような相互作用があるのかと法的な側面だけではなく、いわゆる製造した側の義いうことであり、この機能の安全性は利用の安全性

務、つまり製造物責任の問題から、法的な責任をどと言う方向に向かっています。二つ目は、システムのように理解するかということを考える必要がありの安全性に向かっています。つまり技術的な分野でます。開発プロセスの要件と組織上の要件の双方にあり、ソフト／ハードの安全性に関するものです。

ついてふれてみたいと思います。どのような形でエ使用の安全性とソフト／ハードの安全性はお互いンジニアがきちんと仕事ができるようにするか、そに関連し合っています。例えば、私はエレクトロニれからもし時間があれば、製品の受容性についてもクスの開発に携わっていますが、多くの人たちと共少しふれて、つまりヒューマンファクターについて、同で作業をしています。かれらとの話はとても興味深く、しかもソフトの担当グループとシステムの安全性に取り組んでいるグループが交流している状況があり、大変に喜ばしいことです。
そこで、私はこの講演においては、ヒューマンフ
ァクターに関連して、安全なＩＴＳ製品、または安全な開発プロセスで、何が必要なのかということを論じてみたいと思います。安全なシステムは、その組織構造だけでなく、システムの開発に当たって、シ国際交通安全学会誌 Ｖｏｌ．
２８，増刊号

Fig. 1 Ｈｕｍａｎｆａｃｔｏｒｓｉｓｓｕｅｓａｎｄｐ
ｒｏｄｕ
ｃｔａｃｃｅｐ
ｔａｎｃｅ

（２６）

平成１５年８月

高度運転支援システムにおけるヒューマンファクター

１６３

メーカー、社会、そして個人のレベルでふれたいととチェックしなければなりません。それが製造者の思います。

責任でもあります。

第一に、ユーザーに関連したヒューマンファクタ

それから、直感的に使えるようなシステムでなけーの側面です。ここで、まず理解しなければならなればなりません。つまり、マニュアルをいちいち見いことは、どのような異なったレベルが関わっていなくてもすむものでなければならないということでるのかです。ユーザーは、まずシステムとのやり取す。マニュアルを完全に熟読しないと使えないようりをします。そうすると、まずユーザーのシステムなシステムは安全とは言えません。少なくとも安全

認知の精神的なモデル、これには心理学的要因が関関連ということであればシンプルでなければならず、与します。ユーザーが製品（システム）の機能性に関ユーザーがマニュアルを見なくても使えるものでなしてどのような考え方を持っているか。ここでは特ければなりません。そして、最終的なチェックリスに、ユーザーの考え方が技術モデルと一致していなトの項目としては、いろいろな例が出てきます。こければなりません。ですから、システムの機能や仕れはウェブサイトで公開されていますが、システム様に関して、ユーザーがその製品を使う際に、本来機能の理解可能性の限界として、いろいろと状況が目的とされていたその技術的な仕様とは異なる考え変わる中でも理解できるようにしなければなりませ方があった場合にどうするかです。次は、心理運動ん。

的な部分です。この心理運動的なパフォーマンスと理解のしやすさの次に、予測可能性ということがしては、特にリアクションの時間がどれくらい必要あります。予測可能性とは、ユーザーの期待とシスなのかなどが関連してきます。これには、システムにテムの反応がいろいろな状況下で一致することです。

関する知識がほとんどないユーザーが、最も危険なつまり、システムが何をしているかをユーザーが理状況にある時（ｌｅａｓｔｉｎｆｏｒｍｅｄ ａｎｄ ｍｏｓｔ ｅｎｄａｎ-

解できなければなりません。それも、２秒後、３秒ｇｅｒｅｄ ｕｓｅｒ）、どのような行動を取るかということ後、４秒後どうなるかをユーザーが予測できなけれに注目しなければなりません。

ばなりません。そうでないと、ユーザーはシステム第二に、システム要件に関連したヒューマンファのコントロールができなくなり、システムへの介入クターです。私の最初の講演で申し上げましたが、もできなくなります。つまり、何か困った事態が起まずは理解のしやすさ、つまりシステム機能の理解、 きた時の緊急介入もできなくなります。その例としシステム・ハンドリングの理解とハンドリング状況ては、ＡＣＣ（Ａｄａｐｔｉｖｅ Ｃｒｕｉｓｅ Ｃｏｎｔｒｏｌ：適応型定速が、渋滞で停車した車に反応しない場合の限界について理解しやすいかどうかです。例えば、 走行装置）
交差点における自動化されたＳｔ
ｏｐ＆Ｇｏの状況におを考えてみましょう。ＡＣＣは例えば時速２０ｋｍで走いて、そのルールはどのような形で決まっているか、 行している車はターゲットとして捉えて停車します
ユーザーがシステムを理解できるかどうかが大切でが、渋滞で停車した前方の車を無視します。ここです。交差点において赤信号で止まり、信号が青に変問題となるのは、ユーザーが時速２０ｋｍ以上の渋滞わったらそこで発進する状況において、システムがを走行した経験があり、その時、速度が落ちてもＡ赤信号・青信号しか分からないのか、それとも、ヨＣＣが前の車に反応した経験から、前の車が停車しーロッパの交差点では右側から人が来たら、そちらた場合もシステムが反応してくれると期待してしま側に優先権が与えられるというルールが分かっていう場合です。システムは停車した車に反応せず、ユるかどうかが重要です。この場合のＳｔｏｐ＆Ｇｏは、ーザーの期待は誤りだったことになります。これはただ単に交差点における赤信号・青信号というよう大 変 重 要 な 問 題 で す。ユ ー ザ ー が 期 待 し て い るな単純な状況だけではありません。結論としては、ＡＣＣの機能とＡＣＣの実際の機能が一致しなければ簡単にこの種の機能をシステムの中に組み込むことなりません。ユーザーが学習のプロセスを積むことはできなくなります。つまり、もっと複雑な機能のによって、つまり、日々の経験が積まれて、段々と追加を検討しなければならないことになり、ユーザ新たな期待が生まれてきて、時としてユーザーの経ーを使っての試行も行われました。わかりやすくす験とユーザーマニュアルとの間に矛盾が出てくるかるためには、システムは技術的および精神的なモデもしれません。ユーザーが、日々の経験によって無ルの間の整合性を実現しなければならないし、また意識のうちに誤った期待を抱くのであれば、システユーザーの支持という部分もあり、実験的にきちんム設計が失敗であったということにもなります。チＩＡＴＳＳ Ｒｅｖ
ｉｅｗ Ｖｏｌ．
２８，ｓｐｅｃｉａｌｎｕｍｂｅｒ（２７）

Ａｕｇ.，
２００３

１６４

Ｓ・ベッカー

Fig. 2 Ｈｕｍａｎｆａｃｔｏｒｓａｓｐｅｃ
ｔｓｏｆｕｓｅｒａｎｄｓｙｓｔｅｍ：Ｓａｆｅｏｒｄｅｆｅｃｔｉｖｅｐｒｏｄｕｃｔェックリストとしては、システムの反応がユーザーンファクターという視点を入れることです。では最の今までに学んだ体験と一致すること、すなわち同初のヒューマンファクターとして、どのような要件じようなシステムを使ってユーザーが学んできた経があるのでしょうか。人間は何をするのか、このシ験とシステムの反応が一致することが重要です。

ステムを理解できるのかなどのことをシステムに反次は制御性の問題です（Fig.2）。制御性とは、概映させなくてはなりませんし、システム要件の定義

念上あるいは実行、実務上、システムをユーザーがの中に入れなくてはなりません。それから、運転支オーバーライドできるか、あるいはシステムを切り援システムは技術だけで作るのではなく、人間的な離すことができるかであり、それは法的な責任とも要素を組み合わせることが大切であり、既に私たち関連しています。ユーザーの操作によってシステムはその方向でスタートしています。システムの検証が制御できないとなれば、完全にメーカーに責任がや有効性確認の過程においては、技術的な側面だけあります。メーカーは制御性を保証しなければなりに限るのではなく、起こり得るリスクを同時に想定ません。それができないのなら責任を認める必要がし、その評価を行って検証しなくてはなりません。

あります。例えば、自律的な衝突回避操作中にユーそうすることによって初めて、製品がユーザーの観ザーがシステムを切る可能性に関しては、平均的な点からみても安全となります。

ドライバーの反応時間、精神運動のパフォーマンス、そして、私の専門分野でもありますが、ソフトウさらにユーザーによる反射的なシステム切り離しなエアやハードウエアを安全に生産することです。こどが関係してきます。今まで学習してきたスキルとこでも、ヒューマンファクターが必要です。製品の使っているものが合わなくて、何かの操作で典型的開発だけではなく、生産においても特にヒューマンな失敗が起きることもあります。

ファクターへの注意が必要であり、リスクを特定す開発プロセス上の要件の一つに、ヒューマンファることが必要です。それらは条件定義の中に入らなクターがあります。メーカーやサプライヤーとしてくてはなりません。まずは要件の仕様があって、そ何をしなければならないのかを考えた時、まず、通の中でリスクを明確にすることです。リスクの明確常に理解できるようなシステムでなければなりませ

化は機能の仕様や製品の仕様の中に組み込まれる場ん。そこで、Fig.3を参照してください。システム合もあると思います。去年、私はチームのリーダーの要件があり、その定義があって、システム要件のとして、ドイツを中心にヨーロッパ全土においてリ仕様が作成されます。そして、ソフトウェアを作り、スクの特定と検証の手続きを定義付けてきましたが、システムを検証し、システムの有効性の確認が行わその過程でもヒューマンファクターが重要でした。

れて、安全な製品が製造されます。ここで重要なこでは次にタスク分析について説明しましょう（グとは、これらの全てのプロセスにおいて、ヒューマ

ラビアP.2、Fig.4）。一番目の手法はあらゆる可能

国際交通安全学会誌 Ｖｏｌ．
２８，増刊号（２８）

平成１５年８月

高度運転支援システムにおけるヒューマンファクター

１６５性を考えるということです。ユーザーがシステムをつまりどのくらいの頻度でリスクが発生するかを考使用する時に何が起こり得るかについて、あらゆるえなくてはなりません。そのリスク評価には、シスことを考えなくてはなりません。それから、状況分テムに関する知識がほとんどなく、最も危険な状況

析があり、操作が人によってどれだけ異なるか、個にあると思われるユーザーによるテストが必要です。

人差がどれだけあるかを考慮します。そして、さまいわゆる普通の平均的なユーザーではなくて、特別ざまな専門家の評価が必要です。例えば、交通事故なユーザーグループを対象に試験をする必要があるの専門家や運転指導教官などに依頼して、起こり得わけです。評価の際には、何が許容できて何が許容る事態を考えてもらうことです。ユーザーが何をしできないのかに関する明確な基準が必要です。例え得るか、またどのような事故が起こり得るかであり、 ば、典型的に使われる二つの基準があります。まず、ノックアウトクライテリアであり、これはもう受け交通事故分析の経験をベースにします。
ＦＭＥＡ（Ｆａｉｌｕｒｅ Ｍｏｄｅａｎｄ Ｅｆｆｅｃｔ Ａｎａｌｙｓｉｓ）は故入れられなくて、完全に打ち切りになる限界基準で障モード影響解析というエンジニアリングでよく使す。そしてクオリティ・オブ・ドライビング（運転われているツールですが、技術的な故障を見出す方の質）に関わる基準があり、これはシステムの使用法であり、ＤａｉｍｌｅｒＣｈｒｙｓｌｅｒをはじめ、ＢＭＷやＦｏｒｄによって運転の質の向上あるいは劣化を見る統計学などの自動車メーカーで使われています。ＦＭＥＡ的分析です。のような工学的なアプローチにもヒューマンファク

次にヒューマンファクターの分野から、開発組織ターを導入します。明日の講演でこの話題にふれるの要件を考えてみたいと思います（Fig.7）。私見でことができるかもしれません。調査を目的とした運はありますが、これは非常に重要性を増しているト転クリニックを開催する方法もあります。つまり、ピックです。製品開発組織の要件として、まず製造システム機能のプロトタイプを使って２０〜３０人ぐら部門やサプライヤーに充分なリソースが必要になりいにシステムを実際に使ってもらって、結果を見るます。リソースとは時間や人材です。開発時間は非のです。その際、ＩＳＯやＤＩＳ１２１００−１などの標準を常に重要です。ソフト開発をしたら生産ラインの最尊重します。そうすることよってリスクを明確にす終工程に持っていって、すでにタイヤなどのハードることができます。

ウエアが揃った車体に載せればよいのだという考え

次は、検証の中で行うリスクと便益の評価です

は誤りです。安全な開発のプロセスが必要であり、（グラビアP.3、Fig.5,6）。リスクの特定が一つの作

そのためには、ソフトの開発にも充分な時間をかけ業ですが、もう一つ、どれだけのリスクがあるのか、なくてはなりません。

Fig. 3 Ｈｕｍａｎｆ
ａｃｔｏｒ
ｓａｓｐｅｃｔｓｏｆｔ
ｈｅｄｅｖｅｌｏｐｍｅｎｔｐｒ
ｏｃｅｓ
ｓ： ＤｕｔｙｏｆＣａｒｅ

ＩＡＴＳＳ Ｒｅｖｉｅｗ Ｖｏｌ．
２８，ｓｐｅｃｉａｌｎｕｍｂｅｒ（２９）

Ａｕｇ.，
２００３

１６６

Ｓ・ベッカー

ムができて、故障モード分析に使うことができるようになるでしょう。それによってエンジニアが、可能性のあるリスクを理解することが可能となります。
またそれだけでなく、製造物責任の関連もありますが、企業の中で製品のモニタリングをすることが必要です。そして、ディーラーやユーザーから故障やトラブルの報告があった時に、メーカーがそれらを充分に尊重しFig. 7 Ｈｕｍａｎｆａｃｔｏｒ
ｓａｓｐｅｃｔｓｏｆｔ
ｈｅｄｅｖｅｌｏｐｍｅｎｔｐｒ
ｏｃｅｓ
ｓ： ＤｕｔｙｏｆＣａｒｅて、早急に対応を取ることが必要であり、開発プロセスにフィードバックして製品を改善しなければなりません。
明確な責任分担が必要であり、それは簡単に思えるかもしれませんが、現実には非常に困難なことなのです。明確な責任を決めることは、実際に署名をして、だれが責任者であるかを明確にすることであり、社内のこのような責任体制によって、これはFig. 8 Ｐｒｏｄｕｃｔａｃｃｅｐｔａｎｃｅ

適切な製品であると認める責任組織の要件として次に必要なのは、確かな能力を者がいなくてはなりません。さらに単独責任なのか、証明されたサプライヤーで、サプライヤーの資格認開発検証自体で分担責任とするのかの問題がありま定制度も必要です。

す。開発担当の人が同時に製品の検証をすることはまたメーカーの統合能力では、部品単位のＦＭＥＡなく、一つのチームが開発をして、別のチームがシからシステム統合のＦＭＥＡへの移行が必要になり、ステムの安全性を検証するのですから、責任を分担

システム自体が非常に複雑になります。そこで必要するシステムが必要になります。

なことは、全ての部品の複雑性を理解することです。

最後に、製品の受容の問題です。どのレベルで、またシステム安全性として、ヒューマンファクターどの要素が製品の受容に影響を与えているのでしょに関わるＯＥＭ（ＯｒｉｇｉｎａｌＥｑｕｉ
ｐｍｅｎ
ｔＭａｎｕ
ｆａｃｔｕｒｅｒ：うか。それをメーカーレベルと社会レベル、そして相手先商標で部品を供給する企業）サプライヤーのユーザーレベルで見てみたいと思います（Fig.8）。

専門家が必要になります。さらに充分な作業ができまずメーカーのレベルですが、メーカーは採算性をたかどうかを管理するために、レスポンスプロジェ確保しなくてはなりません。レーダー技術やレーザクト１で作ったチェックリストなどのツールが必要

ー技術などの開発投資の背景として、採算性がなけになります。将来的にはプログラミング上のヒューればなりません。もちろん利益率が低いこともありマンエラーを避けるために、ソフトウエアの自動開得るわけです。例えば、車間距離制御システムなど発プログラムを使う可能性があります。オートコー

は最初のうちはそうでした。また、ユーザーの製品

ディングは、高度な仕様から直接Ｃ言語コードを生に対する不満が高まる可能性があり、コールバック成するもので、これがうまく行けば、多くのヒューマのリスクも高まります。Ｆｏｒｄの最量販車を例にとンエラーを回避することができます。さらに、これれば、１００万台以上が今世界で走っていますが、そまでに学んだことを織り込んだエキスパートシステの電気系統システムに欠陥がありリコールすること

国際交通安全学会誌 Ｖｏｌ．
２８，増刊号（３０）

平成１５年８月

高度運転支援システムにおけるヒューマンファクター

１６７になると、企業にとって非常に大きな打撃になります。
製造物責任の賠償の問題が生じるので、リコールやコールバックが始まりますと、大きな経済的な損失になるわけです。ですから、企業としてはこのようなことが起こらないようにしなくてはなりません。次に、社会レベルにおいて、政治的な枠組みやビジョンが必要です。ヨーロッパのｅ‐Ｓａｆｅｔｙ Fig. 9 Ｐｒｏｄｕｃｔａｃｃｅｐｔａｎｃｅ
行動計画などは、何故、この製品を市場に出すのかという明確なビジョンを持を理解することは難しく、システムが適切にユーザっています。当然、製品の社会的メリットを理解しーの意図を解釈できない場合があります。数年前になくてはなりませんし、この安全システムを購入す行ったヨーロッパの衝突回避システムＡＣＳ（Ａｎｔｉ-る時の個人にとってのメリットも明確にしなくてはＣｏｌｌｉｓｉｏｎＳｙｓｔｅｍ）プロジェクトの実験で、ＡＣＳの働なりません。また、マスコミを味方に付けることがきがドライバーの意志を阻害する状況がありました。

ヨーロッパでは非常に重要ですし、おそらく日本でドライバーが前の車に接近したので追い越そうとしも同じことだと思います。また、効果的な社会教育

たところ、システムがドライバーの意図を理解できが必要であり、高度な運転の新システムを将来的にずに、その意図とは反対にブレーキをかけてしまう社会に広め、最終的には運転教習の中にも組み込まという問題がありました。この場合、ブレーキングれる可能性もあります。

がドライバーの意志でないことは明確です。このよ

さらに、個人のレベルにおける製品受容の要素をうなシステムでは当然、市場は製品を受容しません。

理解することが必要になってきます（Fig.9）。これ

システムはドライバーの意図を理解し、それに合わには四つの問題があります。まず一点目は、システせた行動を取らなければなりません。四点目は信頼ムの効果、利用価値、快適性を上げて、またこれが性であり、ユーザーは製品をどう見ているかという安全であるという認識を広める必要があります。効ことです。この問題は電子的なシステムの将来に関果とは機能的な付加価値を充分に受け入れてもらうわってきます。ここで理解しなければならないのは、ことです。クルーズコントロールとＳｔ
ｏｐ＆Ｇｏを組

実際の品質をどうユーザーが見るか、そして、どれみ合わせた製品などが例として挙げられます。二点だけ高い品質をユーザ−が期待しているかの比較で目は、それぞれの個人ニーズにどれだけ適応できるす。例えば、期待値が実際の感覚的な品質よりも高か、パーソナル化という問題です。例えば、情報シい場合には、マイナスの効果が出てしまいます。
私の二回目の講演は以上です。ご清聴ありがとう

ステム分野において、個人のニーズに合わせて情報を提供するとか、さまざまな情報提供の能力を個人ございました。に合わせて設定することです。初心者用と高度なド〈追記〉ライバー用ではインターフェースを交換できる必要

本講演の内容は、私が関わっているレスポンスプがあります。また、操作の簡便性や効率性。これはロジェクト２の見解を述べたものです。フォード社

直感的にすぐ操作できる制御性と、また学習の容易の立場で発言しているものではないことをご了承くさなども重要になります。三点目は、自動化の度合ださい。

いと機能定義です。システム側でドライバーの意図

ＩＡＴＳＳ Ｒｅｖ
ｉｅｗ Ｖｏｌ．
２８，ｓｐｅｃ
ｉａｌｎｕｍｂｅ
ｒ（３１）

Ａｕｇ.，
２００３