スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
拍手コメントを見る

本当に明かりをつけますか?・・(U.I)友愛

みずほ、損失300億円で済みますかね。

警告メッセージだしていても、「いつもの事だから見逃した」
お粗末ですね。
耐震偽造についても「設計士の書類に間違いが無いという前提」
同じことですね。

ただ、違うのは、前者はユーザーインターフェースの作り方次第で防ぐ方法があると思ってます。

やって欲しくない操作を実行した場合に警告メッセージを出すというのはコンピューターアプリケーションの常套手段です。
「私(プログラム)は、警告を出しましたよね?『いいんですか?』って」
つまり、責任はあなたにあると言っているんですね。

では、どうしましょうか。
今回の場合、間違った数字を入れた後でシステムは「ありえないでしょ!?」と判断したわけです。だったら警告じゃなくてエラーにして続行不可でしょ!?と思うわけです。

ところが、アプリケーションを企画・設計しているときに必ず出てくるのは、「だってユーザーは本当にそうしたいのかも知れないじゃないか」という意見が出てくるんですね。人間のあいまいさを吸収するべく、YESかNOかしか基本的に判断できないコンピューターにとっては混乱の元になるわけですよ。2001年宇宙の旅の HAL ですね。

作っている立場からすると、そこまでしたいんだったら、このアプリケーションは使わないでくださいよ。と思うこともありますが、大体は「では警告メッセージを出しましょうか」というところであっさりと落ち着いてしまいます。

個人的に警告メッセージを出すユーザーインターフェースを「用意」するのは嫌いです。出すくらいなら出さないように工夫しろと。

■おもしろUI編
僕だったら「おかしい?」とシステムが判断したときに、実行者の画面上には「お疲れのようですね。コーヒーでもいかがですか?」と出して、ネットワークにつながった他のメンバーに対して「あいつ変なことしてるんやけど、様子みてくれへん?よーわからん」というメッセージを出してみるという案を、たったいま考えました。

■まっとうUI編
思いつくのは、変だなと判断されたときには実行ボタンを押せないようにしますね。使用者には「なぜこのボタンが押せないんだろう?」と学習させるのが目的です。
ただこれだと「だってユーザーが本当にしたいかもしれないじゃないか?」という壁を越えられません。

■それを踏まえての発展UI編
1) 疑問点がある場合にボタンのタイトルを「実行」から「仮実行」に変更して警告メッセージを出す。

2) 疑問点がある場合に「実行」ボタンを押せない状態にして、別の位置に「全責任を背負って実行」ボタンを表示する。

3) 疑問点がある場合に「実行」ボタンを押せない状態にして、別の位置に「2chで聞いてみる」ボタンを表示する。

ハードウェアだったら電灯のスイッチ入れたら電灯がつくのは当たり前だと認知していますが、ソフトウェアなんです。何が起こるか使い手としてはわからないんですね。

真っ暗闇のなかで電灯のスイッチを探り当ててスイッチを入れた時に「本当に明かりをつけますか?」なんてバックライトもない液晶モニターに問い合わせられても困りますよね。
「本当に明かりをつけますか?そのまえに液晶モニターのバックライトをつけますか?」
・・・・最悪です。
拍手コメントを見る

テーマ : 日記
ジャンル : 日記

コメント

面白いエントリですね

UIの事に関しては、僕もいろいろと悩みながらやっています。そして、警告というのは、やっぱり必要だとおもうのです。

ですが、世の中のアプリケーションは警告に安易に頼りすぎですね。プログラマもアーキテクチャも、どうしたら良いかわからないから、「警告」という何でも箱に、問題をして放り込んで、責任逃れをしている。そういう印象を受けます。

もっと警告は慎重に扱い、本当に大変な事が起きるときだけに表示するべきではないか、というのが僕の個人的な意見です。そんな僕のつくるアプリケーションは全く警告を表示しません、表示するのは、システムがデータを読めなかったとか、IT側が解決しなくてはならないエラーだけ。

本題からそれますが

確かに今回の件、警告UIを「いつものことだ」とオぺレーティングしてしまったことが一番の原因です。

で、誰かがクビになるのは確実でしょうが、オペレーティグミスをした人?甘い警告UIを出すことしか仕様書に書かなかったSE?それをそのまま、例外処理を施すことなくインプリメントしたプログラマー?それとも、そういう想定外の検証作業をTest Scriptに入れなかったQE?

会社の損失よりも、社内の責任問題、雰囲気も心配になってきてしまいました。

コンピュータがもし「?」と思ったときは、
コンピュータがいきなりエッチサイトに強制接続して、使用者が接続を切ろうにも次々と新しいエッチサイトにつながってしまい、止めるにはパソコンの電源をオフにするしかないような設定をしておくと、会社での大ミスは防げるのではないでしょうか。

この仕組みなら、「ユーザーは『本当はそうしたい』のかも知れないじゃないか」という批判もクリアーできるような気が。。。(笑)

はっ。
使用者が女性である場合を考えてなかった。。。

追伸。
このスレを見て、思い出しました。

中学の技術科の時間、「光を感知するとライトが点灯するキット」を組み立てろとゆうことになったのですが、先生から「この仕組みを使って何か役に立つ道具を考えて作りなさい」という課題を出され、「蛍光灯点灯確認セット」と書いて提出したのは私です。

さじ加減がね~

>らんらん
本当に大事なものしかださないのは名案ですよね。見えないところでものすごいことをやっているけど、何でもないように振る舞うヤツに憧れます。

>ヒラ社員
そりゃ責任のなすりあいでフェードアウトがこれまでの常でしょう。マンションがどうなるか目が離せませんね。

>しおさん
ブラヴォー!すごく発展性のあるアイデアだと思います。
弱点は現状案だとその結果を望む人には本来の効果がない事でしょうか。
もしくはウイルスが入り込んで想定外の甚大な被害に拡大するかもしれません。

しかし、少年時代から天然だったのね~。かなわない訳だ!

すいません、、ちょっと見栄を張りすぎました。

やっぱり、警告ダイアログはありました、、、上では大口をたたいてましたが、それはウソでした。ハハハ、、、、

今回の場合おかしいと判断する拠り所が難しかったみたいですね。
価格を1円と指定することは、なりゆき売りの時にはやることらしいので判断の基準としては難しいみたいですね。
発行株数と発注株数の差が今回のケースの1段上のエラーを出す為の拠り所みたいですが、そのためには発注の度に発行株数をデータを取得する必要があるので場合によってはパフォーマンスの問題が出るのかも。

俺はユーザーが安易に無視するほど軽い存在になるような警告の仕様を決めた人も結構悪いし、無視するようなアプリに対して警告できない業務の要件定義を行うコンサルも問題だと思います。(もし、コンサルがいたのなら)

東証のシステムにも不具合があったみたいですが、記事が本当ならなかなかマニアックな条件ではあります。
http://www.itmedia.co.jp/news/articles/0512/12/news004.html

でも、全体的に東証はシステムテストに金かけて無さ過ぎの気がします。
テストに対する投資は底の見えない穴にお金を投げ込むような投資と効果の見えなさが問題ですが、これくらいクリティカルなシステムだとおこりうる全ケースに対してテストの要件定義をして、テストを流すぐらいはやって欲しいものです。
非公開コメント
ブログ内検索
プロフィール

雷ぶ

Author:雷ぶ

最近の記事
最近のコメント
最近のトラックバック
カテゴリー
月間アーカイブ
ブロとも申請フォーム

この人とブロともになる

RSSフィード
リンク

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。