電網悠語:HTML5時代直前Web再考編[197]オスプレイ事故が人為ミスなら、核ボタンだって人為ミスの夢を見る?/三井英樹

投稿:  著者:  読了時間:9分(本文:約4,100文字)


悪いユーザーインターフェース(UI)が、何をもたらすか。少なくともWeb業界に身を置く方々にとっては、いかなる時にも頭から離れない課題の一つだろう。我々は、担当するプロジェクトのUIやユーザ体験(UX)の品質を、数値化どころか体系化さえ微妙なのに、少しでも「高品質」にするかに日々神経を尖らせる。

   ヤコブ・ニールセンの10ヒューリスティックス
   1)今、どういう状態にあるのかを常にユーザに知らせているか
   5)エラーの発生そのものを防止するような工夫がなされているか
   6)操作法や情報を覚えなくても、見れば分かるようになっているか

大御所の言葉を抜粋してみた。ニールセンの活動にネガティブなイメージを持っている人はいても、この10ヒューリスティックスに正面から異論を唱える人に出会ったことはない。

そして読む度に、都合の良いユーザ像を想定してはならないと肝に銘じる。Webの利用者に、訓練を受けた者を想定することは先ずない。イントラネットという社内に閉じた場所でしか使われないシステムだとしても、マニュアルなど読まれないとして、設計すべきというのが定説だろう。

それは緊急時にもミスをさせ難くする、というシステムができる限りの防止策を打つという姿勢でもある。






なので、下記の記事を読んだ時、あぁ米軍の捜査というのは、かなり異世界なんだと驚かされた。機体の問題点は皆無で、すべてが操作ミスだと言い切ることに、Web界にはまったくない世界感を見る。

   オスプレイ「フロリダも人為ミス」 米発表 10月普天間運用を強調
   東京新聞 < http://goo.gl/iHi86 >

   ...報告書によると事故機は別の一機と編隊を組んで飛行。先行機からの
   複雑な気流を受けるためマニュアルが危険と指摘している同機の後方の
   位置に入り、バランスを失って墜落した。さらに、操縦士らは自機が危
   険な位置にいると認識しておらず適切な対応を取れなかったと結論付け
   た。再発防止策としては、シミュレーターで別の機からの気流に対応す
   る訓練などが必要との考えを示した。...

記事曰く、米兵は、下記環境下で、ミッションを達成せねばならない:
1)気流などの情報を認識する方法が弱い(或は気がつかない状況)
2)編隊を組む場合などの危険状態へのアラートもない(或は小さい)
3)危険だとされる操作を行うことも可能(システム的にブロックされない)
そして、これは訓練を受けた者でさえ難しい(だから事故が起きた)。

私は軍事ミッションでの行動パターンを知らないが、気流は複雑なので分かり易く見せるのは難しい(詳細を見せすぎても役立たない)だろうし、軍事ミッションが故に危険な操作も逆にできなければならないかもしれないコトは理解できる。

でも、マニュアルに危険だとされている空間にあってもアラートがでない(認識できない)というのは、ちょっと違和感を感じる。

更に、人為ミスをなくすために更なる訓練をするというベクトルにも、驚かされた。センサーを増やすなり、自動でアラートを鳴らす仕掛けに工夫を増し、ミスを犯してしまう可能性のある人間(=誰でも)にすら注意を促す設計にするのが常道ではないのか。

もちろん、訓練は訓練として、精度を上げていくだろうが、人のミスによる事故を、人のケアでカバーしろというのはちょっと無理がある。しかも1秒を争うミッションであるかもしれない状況下でだ。

この記事の通りだとしたら、軍事ヘリが編隊を組む時(気流が乱れ安くなる状況)の想定がなく、そうした状況の兵士の行動パターンの読みが甘く、だからシステム的なアラートや情報提示の方法も未熟だったと、言わざるを得ない。単機でしかテストしていないのか。



オスプレイに関しては、現職大臣が乗り込んで感想を言ったりしている。私がその立場なら、何を見て安心材料とするのかも考えてみた。

気流や編隊の位置関係などのセンサーについては、どれほどの説明を受けても、私が理解するには壁がある。訓練を受けたものの熟練度は、飛行コースへの依存が大きいだろう。機体の安定飛行性は、もしかしたら感じるところはあるだろう。

一番現実的なのは、UIではないかと思う。操縦席の前に広がるパネル群、そして機体の中でも指揮官系の人が見ることのできるパネル群。そして、自動的に出される現在状況の説明やアラート。このあたりが自分の想定とズレていなかったり、凌駕して高品質である場合、このシステムは安心して使えると直感できる。

逆に、しょぼいUIや想定アラートなどが少なかったりすると、かなり不安になる。実際、エンジニアリングの世界では、全エラーメッセージを見るだけで、そのシステムの(初期)レヴューをする時もある。エラーメッセージの有無は想定しているかどうかを如実に現しているので、目利きが見れば、「これ抜けてるでしょ」と指摘が来る。

SF映画ほどではないにしろ、様々な情報が瞬時に分かるコクピットになっているのだろうか、気になるところだ。



ユーザが操作ミスによって買い物ができない状況で、ユーザの操作が間違っていたんだから「しょうがないよね」とは間違っても我々は言わない。誤操作を起こさせた原因は開発者にあると考えるのが、正しいWeb屋の感性であり、責任感だ。

ユーザテストをしていても、設計者の想定を越える操作をされたとき、「そんなふうにしちゃ駄目だろうが」と上から目線になるよりも、「え〜、そこで、そーくるか」という驚きと、ほぼ同時に「ならばどうしよう」と考える。

すなわち、システムやデザインで何ができるのかを考える。つまりある意味、現段階のシステムにある程度の想定漏れを認め、必ず改良の余地がある、と考える。

世に新しいものを出す人々は、すべからくそういうものだと思っていたが、ちょっと違うようだ。まぁ、政府発表的なフィルターが諸々を隠している部分もあるのだろうが、ちょっと不信感を抱かせる方向の報道コンテンツに感じる。

Web流のすべてがベータ版です、という言い方では、一般の方には余りに責任放棄に聞こえるかもしれないが、開発者の心情的には、常に更なる高みはあり、常にそこに向かう様に改修しつつ進むというのは、むしろ持ってもらいたい姿勢だ。

そしてWeb屋としてヤキモキするのは、UI/UX的に改善の余地があるように見えるにも関わらず、当初のスケジュールを変えないという姿勢だ。これはよくある話だ。ユーザテストを実施して思わしくない結果が出ても、あたかもそんなネガティブ情報は存在しないかのように、スケジュールを変えずに進める。

Web業界は時間が大きな意味を持つ、スピード至上主義といっても良い。先んじてリリースすることは大きい。でも、そのツケはユーザに行く。嫌な思いをするのは必ずユーザだ。でも、結果としてネガティブ風評が立ち、そのサービスなり製品の売り上げに影響は出る。

また、スケジュールを変える気がないなら、最初からユーザテストをする意味がないとも言える(意味のないユーザテストの分だけ、スケジュールを早めても同じとも言える)。

都合の良いデータだけ利用するなら、テストとは言えない。重大な欠陥を見つけ、数日の猶予が与えられたら直せるのに、そのまま突っ走らせるプロジェクトマネージャ(PM)に苛ついている開発者の姿を想像したりする。



失敗を、操作したもののせいにするのは簡単だ。でも、そのように操作させたモノが存在しないのかを考えることが、サービスや製品を成長させる。ユーザのせいで片付けてしまったサイトは、ほぼ間違いなく廃れ消えている。そして、操作させたモノが存在するのであれば、それは(UX)デザインの中かシステムの中だ。

人がより高度な機器類に囲まれながら行きていく宿命であるなら、機器類を人間に合わせて行くしかない。人がケアレスミスをし難くする支援をしてもらうしかない。

そうでない限り、取り返しのつかないボタンを押したことも、人為ミスにされかねない。乱気流の中で、自分の置かれている状況も把握できず、やってはならないコト/判断をし、操作を誤ってしまいました...、笑えないジョークであり、見たくない悪夢だ。



Webは様々なコトガラの「露払い役」なんだろうと感じている。技術の進歩も、人の巻き込み方も、プロジェクトのマネージメントにしても、UX視点の普及にしても、社会への影響に関しても。UI/UXの理解者/専門家がもっともっと世に出て行ければ、様々なことがより良くなって行く気がしてならない。頑張ろう。

【みつい・ひでき】@mit | mit_dgcr(a)yahoo.co.jp
・< http://www.mitmix.net >
・第五世代 iPod touchが気になってしょうがない、iPhone5よりもw
 NAVER まとめ < http://matome.naver.jp/odai/2134761286428986201 >

・やはり全部載せておこう:

 ▼ヤコブ・ニールセンの10ヒューリスティックス

   1)今、どういう状態にあるのかを常にユーザに知らせているか
   2)ユーザになじみのある言葉、習慣で情報を提示しているか
   3)常にユーザが動作をコントロールできる状態にあるか
   4)操作性や用いられる用語は一貫しているか
   5)エラーの発生そのものを防止するような工夫がなされているか
   6)操作法や情報を覚えなくても、見れば分かるようになっているか
   7)上級者向けにショートカット機能/カスタマイズ機能が用意されてい
     るか
   8)情報を詰め込みすぎていないか
   9)エラーメッセージは分かり易い表現で、解決策が提示されているか
   10)分かり易く簡潔なヘルプやマニュアルが用意されているか

・書き終わってから調べたら、ニールセン博士が既に書いてました、しかも最初の戦闘機の話は、殆ど予言的です。

 医療現場のユーザビリティ:悪しきデザインがいかにして患者を死に至らし
 めるか - U-Site
 < http://www.usability.gr.jp/alertbox/20050411.html >