投稿日:

安全な製品づくりのためのユーザモデル構築

製品やシステムを開発する際には、ターゲットとなるユーザをモデル化し、ユーザが興味をもち、使いやすいシステムを設計する必要がある。たとえばペルソナと言われる手法では、製品にとって最も代表的なユーザモデルを構築する。この場合、ターゲットとなるユーザのうち、大部分を表現できるモデルを構築することが目標である。しかし、自動車など高い安全性を要求される製品では、大部分のユーザをモデル化するだけでは不十分である。製品の開発時に想定しなかったユーザの振舞いに対しては、どんなに安全性を考慮して開発されたシステムであっても危険が生じる可能性がある。ユーザがいつも取扱説明書通りに振舞うとは限らない。それが取扱説明書通りの行動では無かったとしても、明示的に禁止していなければ、製品の責任を問われるかもしれない。したがって、安全な製品を開発するためには、大部分のユーザの振舞いをモデル化するだけではなく、少数のユーザの想定しない行動もモデル化対象にする必要がある。

情報収集のタイミングとその利用方法

ユーザモデル構築のためには、多くの事例を積み重ねる必要がある。事例の情報収集を行うための方法を考えてみよう。開発時には想定できないユーザの振舞いに関する事例を収集するタイミングは、製品を市場に売り出した後になる。ユーザに危険を及ぼすようなことが判明した場合はすぐに製品をリコールし、修理することになる。大きな影響が無い場合は、次の製品開発時に、新たに判明したユーザの取りうる振舞いに対しても安全性を担保することを製品開発の要件に加えることになるだろう。さらにコンピュータ上でシミュレーション可能な程の十分な精度のユーザモデルを構築することができれば、その要件が満たされていることを確認することが容易になる。考えられる情報収集方法として、今回はユーザモニタリング、事故や苦情の情報の活用、報告報奨制度について紹介する。また、関連してユーザビリティ（使いやすさ）の評価方法については、本コラムのシステムの使い勝手を評価するふたつの方法[前編]（2007.05.08） 及び[後編]（2007.05.15）を参考にして欲しい。

ユーザモニタリング

EDR（イベント・データ・レコーダ）は、自動車が事故を起こした際の車両状況や操作状況を記録する装置である。国土交通省が国内自動車メーカ12社に対し行ったアンケート結果（2010年9月発表）によると、5社が順次導入を検討している。事故時のユーザの環境及びユーザがどのような行動を取ったかについての情報は、事故につながるユーザモデルの構築に有用な情報となる。ただし、費用や個人情報保護等の観点から難しいとの意見も出されている。この問題に対処するために、ユーザがモニタリングされることを積極的に望む環境を整備することが考えられる。そのためには、モニタリングを行うことにより、ユーザに直接的なメリットを与えられると良い。製品を対象にしているものではないが、 Microsoft Hohm やGoogle PowerMeterでは、家庭内で利用されている家電製品の利用状況をモニタリングし、ユーザに省エネのためのアドバイスを行うサービスを提供している。友人同士や地域同士で省エネ達成度を競い合う等、関心を持続するための方策も考えられている。

事故や苦情の情報の活用

JST失敗知識データベースや >ITARDA (交通事故総合分析センター) による事故データベースなど、様々な事故情報が整理され一般に公開されている。これらの情報を参考にすることにより、ユーザがどのような行動を取って事故につながったのかを解析することが可能である。

また、コールセンタでは、日々製品の苦情や問い合わせを受け付けている。この情報は製品の開発にとって貴重な情報となる可能性を持っている。実際、苦情や問い合わせの情報を利用することにより、ユーザが製品に対してどのように想定しない使い方をして事故等につながったかのモデルを構築する取り組みも行われている。

報告報奨制度

Mozilla セキュリティバグ報奨金制度やGoogle Rewarding web application security researchでは、ソフトウェアのセキュリティ調査を奨励し、セキュリティの脆弱性を発見した人に報奨金を与えるという取り組みを行っている。Mozillaでは最大500ドル、Googleは最大3,133.7ドルを与えるとしている。Googleは既に、WebブラウザChromeを開発する際にも、同様の報奨金制度を実施して成果を挙げている。ソフトウェアに限らず、取扱説明書に記載すべき、または、根本的に製品の一部を変更すべきであるような危険な要因を発見した人に対して、報奨金を与えるような制度を作ることも考えるべきであろう。

このように、少数のユーザも含め幅広く安全性を確保するための機能を実現することが必要である。しかし場合によっては、大多数のユーザの魅力ある機能と矛盾することもあるかもしれない。その場合は危険性の大きさ等を考慮し、総合的に判断する必要がある。

本文中のリンク・関連リンク：