検索
カレンダー
2007年2月
« 1月   3月 »
 123
45678910
11121314151617
18192021222324
25262728  
ブログメニュー
Amazon検索
キーワード:

私が勉強をする理由

2007年2月28日

傲慢SE日記さんの「何故SEは勉強をしないのか? 」というエントリーに影響を受けて、私の考えも書いてみることにします。

仕事に対する姿勢として、社会人は大きく2つに分かれると思います。
一つが、「生活は仕事中心。お金をもらって仕事をするからには責任を果たすべき。」派で、もう一つが、「仕事はあくまでお金をもらう手段。仕事以外で人生を充実させるべき。」派です。

私の少ない経験の上での話ですが、ソフトウェア業界は後者の方のほうが多いようです。
以前私がいた職場で働いている方の過半数は、仕事は会社にいる間だけで十分で、家に帰ってから勉強するなど考えられないようでした。
人生は仕事が全てではないので家にいる間は家庭や趣味を大切にしたいのでしょうし、私はその人の考え方を否定するつもりはありません。

ですが、やっつけ仕事で建てられた家には住みたくありませんし、二日酔いの医者に掛かかりたくないのは私だけではないはずです。
同じように世の中の大半の人は、責任を持って仕事をしていない人が作ったソフトウェアにお金を払いたくないはずです。

世の中には、努力なしで仕事を完璧に遂行する天才がいるのかもしれません。
残念ながら私はこのような天才ではありませんが、凡人なりに責任を持って仕事をしているので、業務時間以外でも勉強を続けるしかないのです。

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

2007年2月15日

前回の記事 に私の考えを書きましたが、色々調べているうちに参考になるページを発見しました。

かの有名な、ヤコブ・ニールセン氏のサイトの日本語訳です。
Alertbox: エラーメッセージ・ガイドライン(2001年6月24日)

私の書くことなんかより遥かに有用ですので、参考にしてください。

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

2007年2月14日

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

2007年2月2日

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

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

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) {
		...
	}
	...
}

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

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