ちょっとひと言
エッジ ケース
前回のコラムで、誤って入力してしまった「hte」を本来入力するはずだった「the」に自動変換する Word のオートコレクト機能を賞賛しましたが、「いや、Plattski、これは実にひどい機能だよ。君が前回のコラムを執筆したとき、実際に間違いの例として「hte」と書く場面があっただろう。そんなとき、オートコレクト機能が邪魔にならないかい。ときには間違って校正してしまうんだから、Word はそんなことすべきではないよ。」というご意見を多数いただきました。
これはコンピューターの専門家の典型的な世界観です。私たちは、数学的、論理的な教育を受けていて、中学時代の数学以来、99 個のケースには当てはまっても、100 個目のケースで当てはまらなければ、その定理は誤っていると叩き込まれてきました。やっかいなものですね。このような考えを捨て、真の定理を探りましょう。
このような考え方は数学の定理では正しくても、人間のユーザーにとってはまったく正しくありません。Word のオートコレクト機能は、必ずしも文書を正しく校正するとは限りません。ですが、校正に最大限の想像力を働かせ、使用するたびに、より正しいものが推測されるようになり、結果として、多くの間違いが正され、ユーザーにとって大きな利益になります (信じていただけないのなら、試しに 1 週間ワードパッドを使ってみてください。水曜日には気が変になっていること請け合いです)。大半のユーザーは、ほとんどの場合、こうした最終結果で製品を判断します。
定理とは異なり、あなたが作ったプログラムが 100 人のうち 99 人のユーザーを幸せにするとしたら、おそらくとてもよい日を過ごせるに違いありません。次の日に、100 人目のユーザーをどうやって喜ばせるか考えるよりも、99 人のユーザーをもう一度喜ばせることを考えるほうが大切だと思いませんか。その 100 人目のユーザーの要求が、残りの 99 人を困らせるようなものだとすればなおさらです。
文書を編集する際の従来のモデルについて考えてみましょう。従来のモデルではプログラムを終了するときに、「変更を保存しますか」とたずねられます。変更をぜんぶ破棄してしまうことってどのくらいありますか。ときどきはあるとしても、頻繁にはないでしょう。1 日に 1 回、1 週間に 1 回、いや 1 か月に 1 回あるかどうかも怪しいものです。ほとんどのアプリケーションには "元に戻す" 機能があり、編集中のあらゆる時点の状態に戻すことができます。
ですが、このほとんど行わない "エッジ ケース" と、編集中の作業を保存するというほぼ必ず行うケースとが、ユーザー インターフェイス (UI) で同等に扱われています。プログラムを初めて使用するユーザーにとってわかりにくいうえに、時間を浪費してしまうユーザーも少なくありません。そればかりか、あらゆるユーザーが、基本的に保存しておきたいと考える作業を、誤って破棄してしまうおそれがあります。マウスをクリックするときにくしゃみをするユーザーもいるでしょう。私のように、飼っている猫がキーボードに飛び掛かることもあるでしょう (「やめろ、Simba、こら、やめろって言ってるだろう!」)。そして、それまでの作業が水泡に帰します。
ダイアログ ボックスに、「これまでやったことを全部消しますか」と書かれているとしたらどうでしょう。編集を終えた後に、こんなばかげた質問をする人がどこにいますか。ですが、ユーザーの視点から言えば、先ほどとまったく同じ質問です。
このアンチパターンは従わなくてもかまいません。また、ときどき従っていないプログラムもあります。Microsoft Office OneNote は、ドキュメントを自動的に保存し、必要なときには、元に戻すキーで変更を元に戻すことができますが、そのことについていちいちメッセージを表示したりしません。Intuit 社の家計簿ソフト Quicken も同じように機能します。Quicken では、家計簿を保存するかどうかはたずねられません。家計簿を入力するということは、それを保存するつもりであることを意味します。気が変わったら、その日の家計簿を削除するでしょう。このアプリケーションを正しく使用するにあたって、変更の保存について考える必要はありません。調査結果によると、ユーザーは、このソフトウェアが従来のソフトウェアと違っていることにすぐに気付き、この機能を好んでいるそうです。
最初にすべてのケースを正しく処理できなければ失敗するプログラムでは、明らかにこのデザイン アプローチを当てはめることはできません。たとえば、航空管制のプログラムや、癌化学療法のプログラムなどです。ですが、このような命にかかわるアプリケーションには、UI に関して特別な注意を要するさまざまな問題点が独自に存在します。
UI で "エッジ ケース" もで同等に扱う必要があるという状況そのものが、あまりない "エッジ ケース" です。あなたのプログラムがそのようなケースを扱わなければならないとしたら、どうぞ片付けてしまってください。ですが、ほとんどのビジネス向けプログラムや消費者向けプログラムでは、すべての "エッジ ケース" を扱ってユーザーを困らせるよりも、必ず扱うべき主なケースをシームレスに処理し、発生したときにだけ "エッジ ケース" を解決するほうが、よりすばらしい世界になるでしょう。
David S. Platt は、ハーバード大学の公開講座や世界中の会社で .NET のプログラミングの講師をしています。『Why Software Sucks...and What You Can Do About It』(Addison-Wesley Professional、2006 年) や『Microsoft .NET テクノロジガイド』(日経BPソフトプレス、2001 年) などの、11 冊のプログラミング関連の書籍の著者でもあります。2002 年には、マイクロソフトから Software Legend に指名されました。David は、8 進法で数える方法を学べるように、娘の 2 本の指をテープで留めるかどうか悩んでいるところです。連絡先は rollthunder.com (英語) です。