川村渇真の「知性の泉」

エラー表示を少しでもわかりやすく


まだMacに慣れていない初心者ほど、操作を誤ってしまうことが多い。しかしこの際に表示されるエラー表示についての知識も少ないため、示された内容を理解できない場合がある。今後パソコンの機能が増えるにつれて、わかりやすいメッセージの重要度は増していくだろう。


原因や対処方法などの情報を表示することも必要

 ユーザーが指示した処理が実行できないと、システムやアプリケーションはエラーを表示して知らせる。よく使われるのがアラートだ(図1)。表示面積が少ないだけに、説明文も不十分なことが多い。エラーの対象物の名前(ファイル名など)を表示するくらいはしてくれるが、わかりやすい説明があることはまれだ。

図1、多くのエラーメッセージは、短い文章で状況を簡単に説明するだけ

図1

 このようなエラー表示は、システムやアプリケーションの知識をそこそこ持っている人なら、簡単に意味を理解できる。また、どうしたら回避できるかも知っている。ところが、システムの大まかな仕組みすら知らない初心者には、エラーメッセージの意味を理解できない。例えば、同じ名前のフォルダとファイルでは、上書きを拒否される。このようなルールにしてあるのは、誤った操作で削除するのを防止するためだと思われる。どうしてできないのか、もっと詳しく説明してもらわないと、エラーの原因を理解できない。
 エラーメッセージを改良するもう1つ理由は、エラーが発生したときに意味を説明すると、知識として記憶しやすい点だ。疑問を感じたときに必要な情報を与えると、学習効果を最大限に高められる。いろいろな知識を効率よくマスターしてもらうためにも、エラーメッセージの充実は欠かせない。
 親切なエラー表示を目指すとき、まず考えるべきなのが、メッセージに含める内容だ。多くのエラーメッセージは、「こうなりました」という状況だけを説明する。しかし、それだけでは対処方法がわからない人もいる。どのようにすれば解決できるのか、できるだけ知らせたほうがよい。実際、対処方法を知らせるメッセージも存在する。ロックされたファイルがゴミ箱に入っている場合、空にする操作でのメッセージには、削除する操作方法が示される(図2)。このように教えてくれれば、その操作方法を知らない人でも、続けて削除ができるし、削除方法を覚えられる。対処方法が1つに定まらない場合には、考えられる原因をいくつか示す方法も有効となる。そのうえで、原因ごとに対処方法を示せればよい。

図2、一部のエラーメッセージでは、対処方法を親切に説明してある

図2

メッセージは箇条書きで整理して伝える

 エラーメッセージの文字数が増え、いくつもの文章がつながった状態では読みづらい。わかりやすく伝えるなら、上手に整理して表示することが求められる。
 もっとも有効なのは、項目別に分けて箇条書きでまとめる方法だ(図3)。含める項目としては、エラーの内容、エラーの重要度、推測される原因、対処方法、対象物の情報(ファイル名やサイズなど)、実行した場合の影響──などが挙げられる。エラーの内容ごとに、この中から必要な項目を選ぶ。

図3、エラー内容の説明を項目に分け、箇条書きで整えると分かりやすい

図3

 以前からMac OSは、エラーの重要度を3段階にわけて表示している(図4)。ただし、3種類のアイコンを付けるだけなので、意味を知っている人だけにしか理解できない。知らない人にとっては、何も表示していないのと同じだ。少なくとも短い言葉ぐらいは加えたほうがよい(図5)。もっと改良するなら、短い文で構わないので、重要度の内容を簡単にでも説明する(図6)。たとえば、ディスクの書き込みエラーなら、「重大なエラーで、緊急に修復が必要です」といった文を表示する。エラーの大きさだけでなく、対処の緊急性や被害の影響度など必要に応じて加える。文の形で表示する場合は、箇条書きの1項目として入れると、全体が整って見える。

図4、アラートに用いられる3つのアイコンは、エラーの重要度を表している。上から順番に、軽い警告を与える「ノート」、ユーザーに不利な結果を招く可能性がある「コーション」、すぐに対処が必要な重大エラーの「ストップ」

図4

図5、既存のアラートでも、アイコンの下に簡単な言葉を入れると、アイコンの意味が少しは伝わる

図5

図6、箇条書きの一番上に、エラーの重要度や緊急度を示す項目を追加すると、問題の重大さを伝えられる

図6

 エラーメッセージを親切にするほど、必要な文字数は増える。限られた表示面積では足りないので、スクロール機能などが必要だ。すべてのエラーメッセージを同じ形式で表示したほうがユーザーの混乱は少ないので、エラー表示用のマネージャをOS側で用意したい。それにスクロールやアウトライン表示の機能を含め、元データの形式まで標準化すればよい。アプリケーション側では、データ形式に合わせてメッセージを用意し、マネージャに渡すだけとする。決められたデータ形式でメッセージを作るツールも提供すれば、より詳しいメッセージを簡単に作れる。個々のアプリケーションが独自に作成するよりも、OS側で機能を用意したほうが、より多くのソフトで利用する。対応するソフトが増えることで、ユーザーの混乱を幅広く減らせる。
 もっと凝るなら、対処方法の実行と連動させる手もある。アシスタント機能を呼び出し、ユーザーから見てスムーズに移行する形でまとめるとよい。ただし、誤って選ぶとファイルを失うような処理は、自動化しないほうが安全だ。なお、この機能もOSがサポートすべきである。

全メッセージに出所と識別コードを付ける

 最近のOSには、いろいろな機能拡張が組み込まれ、バックグラウンドで動作する。そのような機能がエラーメッセージを出すと、どこから出されたのかユーザーにはわかりにくい。何度も出るのでオフしたいと思っても、出所が分からなければ対処できない。
 そこで、エラーメッセージを出したソフト名や機能名をメッセージに加える。箇条書きで項目を整理しているなら、先頭の項目として加えるのが最適だ。機能拡張のようにオフする可能性があるソフトでは、「機能拡張マネージャ」上で表示するパッケージ名を、エラー表示のソフト名や機能名と合わせる。まったく同じにする必要はないが、簡単に探し出せる程度には近づけたい。
 もう1つ、似た文面のエラーメッセージがあっても区別できるように、すべてのエラーメッセージに識別コードを付ける。半角の英数字を用い、重複しないコードとして割り当てる。識別コードを付けると、エラーメッセージを特定しやすいため、電話によるユーザーサポートの負荷を少しは軽減できる。まず最初に、エラーの識別コードを尋ねればよいからだ。また、エラー発生時の対処方法をマニュアルで説明する際にも、識別コードが役立つ。言葉だけのメッセージなら、対処方法のインデックスが作りづらいが、重複しないコードがあると、そのコード順で対処方法を整理できる。探しやすければ、ユーザー自身が調べて直せる。
 識別番号のフォーマットを標準化する方法もある。たとえば、前のほうの桁だけは、各桁ごとに役割を与えるとかだ。最初の1桁は重要度、2桁目はシステムの基本機能か追加機能かアプリケーションかの分類、3〜6桁目はソフトを示す略号、それ以降はソフトごとで自由に使うというように。ソフトの略号を含めることで、識別番号だけでメッセージの出所が特定できる。桁数が多くなるときは、標準化された部分とそれ以外の間に、半角のハイフンを入れるとよい。
 以上のアイデアを総合して、全部のエラーメッセージに「ソフト名、機能名、識別番号」を付ける(図7)。「機能名」の部分は、複数の言葉を入れても構わない。このルールをプラットフォーム全体で標準化すれば、どのソフトのどの機能が何のエラーを出したのか、すぐにわかる。トラブルの電話サポートでも、どの機能がエラーなのか絞れれば、他社製ソフトのトラブルで迷惑する機会が減るはずだ。ユーザー側でも、適切なサポート先に電話できて、無駄な時間を取らない。

図7、エラーメッセージの表示に、出所や識別コードを加えた状態。また、アイコンの位置を移動して、文字を表示できる面積を増やした。残念なことに、少しバランスが悪い

図7

 このような工夫は、システム全体での機能が多いほど有効となる。今後のOSは、いろいろな機能を標準で持ち、追加できる機能拡張の種類も増えるだろう。そうなる前に、ユーザーに親切な形で、エラーメッセージの標準化しておきたい。


下の飾り