エラーメッセージのユーザビリティ

今までに色々なシステムを見てきましたが、私が気になる事柄の一つにエラーメッセージがあります。特に一般向けでない業務システムでは、不適切なエラーメッセージが多々見受けられるように思います。そこで、今回はエラーメッセージをどのようにすればよいか考えてみます。

例えばWebシステムで、メールアドレスを利用者に入力してもらう画面があるとします。この入力フォームに利用者が間違えて全角で入力した場合に、今まで見てきたシステムで出力されたエラーメッセージを挙げ、その問題点を考察してみたいと思います。

例1: 「内部でエラーが発生しました」というメッセージが画面に表示される

このエラーメッセージは問題です。利用者がこのメッセージを読んで、どうすればいいのでしょうか。

このようなエラーメッセージは、あまり詳細な設計がされたいないシステムや、あまりテストされていないシステムでよく見受けられます。プログラマが想定していないエラーが発生した場合のエラー処理として、このようなエラーメッセージが使われることが多いように思います。例えばJavaですと、ServletクラスでExceptionをキャッチしたら、とりえあえず上記のようなエラー画面に飛ばす等です。
個人的には、プログラマが想定していないエラーが発生したら、それはもう不具合と同じだと思っています。

例2: 「バリデーションエラー(mail)」というメッセージが画面に表示される

あまり利用者のことを考えていないプログラマがシステムを作った時に、こういうメッセージを表示していました。製作者は、利用全員が「バリデーション」の意味を分かると思ったのかもしれませんが、私はそうでないと思います。
エラーメッセージは、あくまでも利用者の言葉で書くべきです。

例3: 「メールアドレスが不正です」というメッセージが画面に表示される

よくあるエラーメッセージだと思いますが、このメッセージには解決策がありません。利用者は、「メールアドレスが間違い」だと理解することはできると思いますが、どのように直してよいか分からない場合があるはずです。例えば全角と半角の間違いの場合、プロポーショナルフォントでは違いが分かりにくいため、間違いに気づかないかもしれません。

例4: 「メールアドレスは@(アットマーク)を含む半角英数字で入力してください」というメッセージが画面に表示される

私は、このエラーメッセージが一番わかりやすいと思いました。間違いの場所と解決策が書かれています。

例5: 全角で入力した文字が半角に自動変換され、エラーが発生しない

この方法は場合によっては最良かもしれませんが、私はこの方法の使用には慎重になるべきだと考えています。例えば、将来マルチバイトのドメインが一般的に使われ始めた場合はどうするのでしょうか。
この話題は今回の記事とは少し離れてしまいますので、別の機会に考えたいと思います。


結論として、私はエラーメッセージは次のようなことに気をつけるべきだと考えています。

・エラーの発生原因を示す
・エラーの解決策を示す
・メッセージには利用者が理解できる言葉を使う

上記のポイントの他に、エラーメッセージの出し方を有名なサイトで研究するのもオススメです。例えばGoogleでキーワードに一致するサイトがない場合に、どのような画面になるでしょうか。色々なサイトでエラー画面を出して比較してみるのも面白いかもしれません。
機会があれば、このブログでやってみたいと思います。

読みやすいコードの重要性

読みやすいコードの重要性いつも巡回しているブログの中に、「整理されたコードが読みにくい理由 」という記事がありました。私はこの記事は素晴らしいと思います。プログラム初心者・初級者の方は、元記事と併せて読まれることをお勧めします。

この記事を読んで私もコードの書き方について少し書いてみることにします。仕事柄、私も色々なコードを読む事がありますが、私が気になってしょうがないのは次のようなコードです。

public void hoge(ModelList modelList) {
String name = ...
if (modelList.find(name == null ? DEFAULT_NAME : name).update()) {
...
}
...
}

上のサンプル関数「hoge」は、モデルオブジェクトのリストからname(設定されていない場合はDEFAULT_NAME)をキーにして一つを取り出し、それを更新するイメージをJavaで書いたものです。このコードの3行目は、4つの処理(findメソッド、name変数の判定、updateメソッド、if文)が書かれています。
このように処理を詰め込んだコードは一見エレガントに見えるかもしれませんが、直感的に何をしようとしているか分かりにくくなると思っています。

私は同じ処理を書くとき、コードが少し長くなっても下のような書き方をします。

public void hoge(ModelList modelList) {
String name = ...
if (name == null) {
name = DEFAULT_NAME;
}

Model model = modelList.find(name);
boolean result = model.update();
if (result == true) {
...
}

...
}

確かに、私のようなコードを書いていると変数を大量に定義する必要があったり、タイプ量が増えたりするといった問題があります。（コードが幼稚に見えるということもあるかもしれません。）ですが、変数が増えるということは変数名でコードを理解しやすくなるということですし、なんといっても保守コストが増えるリスクに比べれば上記の問題など些細なことです。

どのようなコードを書くべきかは状況によって違いますので一概には言えませんが、全てのプログラマはコードを書くとき、ソフトウェアのライフサイクル全体にかかるコストを考えるべきではないでしょうか。

中国の人工衛星破壊実験と囚人のジレンマ

最近、『中国、衛星破壊のミサイル実験に成功 』というニュースがありました。この結果、スペースデブリ が大量に発生したようです。

このスペースデブリに関して、最近『使用中の人工衛星や有人衛星などに衝突する危険性が問題となっている』そうで、今回の中国の行動は、他国にかなり迷惑をかけていると言わざるを得ません。

このニュースを聞いて、私は「囚人のジレンマ 」を思い出しました。私は数学やゲーム理論に疎いので完全には理解できていませんが、国際情勢をこのゲームに当てはめてみると、今回の中国は「裏切り」を行ったということになります。無限回の囚人のジレンマゲームで、全体的に有益になるのは「しっぺ返し戦略」だと言われています。この「しっぺ返し戦略」を他の国が採るなら、次回は他の国が「裏切り」を行うのが有益ということになってしまいます。

中国は、他国が「しっぺ返し戦略」を採らないと思っているのでしょうかね。

PHPの処理を中断させない方法

PHPで標準で以下のような機能が実装されています。
  • ブラウザとの接続が切れた場合（ブラウザの「中止」ボタンが押された場合や閉じられた場合）に処理を中断する
  • ブラウザからのリクエストがあってから、30秒以上経過しても処理が終わらなければ中断する
これらの機能は、スクリプトにバグがある場合などで処理が終了できなくなった際の予防です。ですが仕事でPHPを使っている場合、どうしても処理を中断させたくない場合があります。

この場合、上記の2つの機能を無効にする必要があります。ただしタイムアウト時間を無限にした場合、本当に無限ループに入っている場合に終わらなくなってしまいますので、タイムアウト時間を十分に長いものに指定することをお勧めします。設定方法は以下のようになります。

【php.iniに設定する場合】
ignore_user_abort = On
max_execution_time = 86400

【.htaccessに設定する場合】
php_value ignore_user_abort On
php_value max_execution_time 86400

【プログラム中で設定する場合】
ignore_user_abort(1);
set_time_limit(86400);

ただし、PHPがセーフモードで動いている場合は効果がありません。また、ブラウザで処理に時間がかかるプログラムを呼び出した場合は、定期的に何かを出力していないとブラウザ側でタイムアウトしてしまう場合があります。（処理自体は最後まで実行されます）

参考：
PHP マニュアル その他の関数(Misc)
PHP マニュアル PHP オプションと情報(info)

言い伝えについての考察

明けましておめでとうございます。
皆様は正月休みをどのように過ごされたでしょうか。
私は実家に帰って両親と雑談してきました。
私の母は風水や占いといったものが大好きで、「占星術の本によると、今年の運勢は…」だとか、「風水の先生の話では、この家は風水的に…」だとか色々聞かされました。

私はいつも、こういった話に違和感を感じます。それは、占いや風水は「結果」だけを強制して、論理的な「理由」を教えてくれないからです。
例えば、風水的では鬼門にトイレを配置してはいけないようで、これは風水では有名な話のようです。（私は風水には詳しくないので本当かどうか知りませんが…。）では、なぜ鬼門にトイレを配置してはいけないのでしょうか。
私の想像ですが、この言い伝えには以下のような理由があるように思います。
昔のトイレはかなり不衛生でしたので、これが居住空間の風上にあると、細菌が繁殖しやすい環境になったのだと思います。この「風上」が鬼門や裏鬼門の位置にあたり、結果的に「鬼門にトイレを置いてはいけない」となったのではないでしょうか。
このような理由がわかって初めて、守るべき言い伝えかどうかがわかると思います。

プログラムの世界も同じようなもので、よく「GOTO文は書いてはいけない」だとか、「コードは1行80文字に収まるように書くこと」などといった、言い伝えと化しているものがあります。
これらの言い伝えを守るも守らないも自由だとは思いますが、どちらにしても理由をしっかり考えてから決めたいものです。

資格取得のための勉強法

当ブログにコメントしてくださった方の記事 を見て、私も資格試験を受けていた頃を思い出しました。
# 逆に言うと、ここ2年くらいは資格とは無縁だったりします

この際ですので、（役に立つかどうかわからないですが）私の勉強法をご紹介したいと思います。

私は資格試験を受けようと思ったとき、その分野に関する雑誌を定期購読するようにしています。
例えば「テクニカルエンジニア（ネットワーク）」なら「日経ネットワーク」、「テクニカルエンジニア（データベース）」なら「DBマガジン」といった感じです。情報セキュリティアドミニストレータを取ったときだけ、どの雑誌がよいかわからなくて結局購読せずじまいでしたが…あせる

この方法のキモなのは、雑誌の講読を必ず半年以上続けることです。
もちろん、雑誌だけでは資格取得に必要な知識を全て得ることはできませんし、試験に必要でない知識が身につくこともあります。ですが、雑誌だと「受験勉強」という意識でないので気楽ですし、読み続けると業務に近い知識を得ることができます。
これに加え、雑誌を読んでわからないことなどの基礎知識を、資格試験対策用の本から得ます。

私は半年間この方法で基礎知識と業務知識をつけ、試験対策は直前の半月～1ヶ月だけで済ませました。

この方法は私のような記憶力のない方にお勧めだと思います。皆さんはどのような勉強法をお持ちでしょうか。

レコードを他のテーブルにコピーする

履歴用テーブルとマスタ用テーブルなど、カラム構成が同じテーブル同士でレコードをコピーしたい場合があります。
このような時は下記のようなSQLを使います。

INSERT INTO table1 SELECT * FROM table2;

複数のテーブルを組み合わせたDELETE/UPDATE

他のテーブルと関連した検索条件で抽出した複数のレコードを、
DELETEしたりUPDATEしたりするには下記のようにサブクエリ（副問い合わせ）を使います。

(例)
DELETE FROM table1 WHERE column1 IN (SELECT column1 FROM table2 WHERE ...);

複数のカラムでプライマリーキーになっているテーブルがあると、複数のカラムで比較する必要がでてくると思います。
複数のカラムで比較したい場合は、下記のように複数のカラム名をカッコで囲んで書きます。

(例)
DELETE FROM table1 WHERE (column1, column2) IN (SELECT column1, column2 FROM table2 WHERE ...);

Eclipseが不安定な方へ

先日、Eclipseのバージョンを最新にし、便利そうなプラグインを片っ端から入れてみました。
その結果、Eclipseが１日に１０回以上もクラッシュして落ちるようになってしまいました汗

エラーログを漁ると、ヒープメモリ不足なような気が…。
そこで eclipse.ini を色々いじって -Xms や -Xmx を大きくしてみたりしたのですが、現象が改善せず途方にくれてしまいました。
さらにエラーログを調査すると、どうやらパーマネント領域が足りないようです。
eclipse.ini に下記のような行を追加してパーマネント領域を増やしました。
-XX:PermSize=32m
-XX:MaxPermSize=256m
この効果は絶大で、このパラメータを追加してからはクラッシュしなくなりましたニコニコ

それにしても、パーマネント領域を指定するパラメータがあるとは思いませんでした…。
原典を発見できなかったのですが、どこで定義されているのでしょうか？
sunのjavaコマンドのページ にも書かれていないようです。
もしかして安定したのは気のせいなのでしょうか？？？
どなたかお教えいただければうれしいです。

ちなみに、参考にしたページは「@IT 事例に学ぶWebシステム開発のワンポイント（9） 」です。

続・私が資格を取った理由

前回は資格の利点について考えたので、今回は問題点について考えてみました。

「私が資格を取った理由」 に『早く一人前になりたいから資格を取った』と書きましたが、これは知識を吸収したいという意味だけでなく、私が当時在籍していた会社の体質に因るところも大きいです。
私が当時在籍していた会社では、社内制度として資格の取得を奨励していました。具体的には、資格が取得できれば褒賞を、取得できなければ出世できないなどの罰則が与えられます。
私はこれを逆手にとり、資格さえ取得できれば一人前と見なされるだろうと考えたのです。

今思えば、これはかなり危険な考え方です。
たとえ資格を持っていなくても有能な方もいれば、資格をたくさん持っているからといって仕事が出来るとは限らないからです。
資格が不必要だと思われる方の多くは、自分より仕事が出来ないと思う人が資格を持っていて、その人が自分よりも重用されているのではないでしょうか。

私は、これは資格制度自体に問題があるのではなく、資格を重視する上長や会社の体質に問題があるように思います。
個人的な意見なのですが、資格は有能であるかどうかを証明するものではなく、その分野の仕事をするに最低限の知識があるかどうかを保障するためのものだと思います。
資格を持っているどうかを仕事が出来るかどうかに置き換えるのは、部下や社員の仕事の出来を見ることができない上長や会社の怠慢ではないでしょうか。