エラーメッセージ

　エラーメッセージの文言について考えてみる。

　メッセージには、事象と対応の２種類のパターンがあると思います。
　たとえば、
　　「○○○の項目が未入力です。」
　と言うか、
　　「○○○の項目に入力してください。」
　と言うかです。前者が事象で、後者が対応です。
　メッセージの親切さからすれば、後者のほうが次に何をするべきかわかるので、ユーザービリティ的に良いです。

　ですが、現実的にはきちんとした指針もないまま、現場で各々の開発者が決めたりすることが多いので、バラバラだったり、事象のパターンが多かったりします。
　事象のパターンが多いのは、開発者やプログラマーには不親切な人が多いから・・・・というのは、嘘です。

　理由のひとつには、エラー判定処理が、「もし○○○の項目が未入力ならば〜」という意味になりますので、判定内容をそのままメッセージにしてしまうのが、楽というのがあります。
　開発者として、仕組みのわかっている人から見れば、事象のパターンだけで、次に何をすればよいかわかりますから、この文言に違和感を感じない場合が多いです。

　理由の二つとして、エラーケースの中でも、対応方法が複数あり、メッセージとして対応方法を決められない場合もあります。
　たとえば、生年月日と年齢が一致しないときに、生年月日が間違っているのか、年齢が間違っているのかは入力した本人しかわかりません。
　そうなると、対応パターンのメッセージは勝手に決められません。
　開発が忙しくユーザー視点で考える余裕がなければ、ユーザーがエラー時に対応としてどうしたいのか、わからないなんて開発者もいるかもしれません。

　どんなケースでもチェック処理があれば確実に決められる文言は事象パターンです。
　しかし、使い慣れていないシステムを使う人ならば、原因がわかっても対処方法がわからないこともあります。
　この辺をどこまで対応メッセージでフォローするのか？
　業務システムなら使用者に一定の教育を実施できるかなども含め、確認を取ってから文言の方針を決めないと、いけないのかなと。
　メッセージを細かく分けると、エラーチェック処理も細かくなったりすることもありますので、エラーメッセージは設計のどの段階で決めておくものなのでしょう？
　メッセージは仮決めのまま、テスト段階になってから、ユーザー指示で一斉修正なんてこともあるので、意外に手間の掛かる小事として、エラーメッセージの文言があります。

　あと、「〜できません。」という否定的な文言をあまり使わないという、意見もありますね。