受注入力の締め切り15分前、パート社員の田中さんは最後の1件を入力し終え、確定ボタンを押した。画面が一瞬白くなり、次に現れたのはこの一文だけだった。
Error: Code 500
田中さんは何が起きたのか分からないまま、隣の同僚に声をかけた。同僚も首をかしげる。二人でボタンを何度か押し直してみるが、同じ画面が繰り返し表示される。締め切りが迫る中、田中さんは情シス担当の山本さんに内線をかけた。山本さんはちょうど別の部署からの問い合わせ対応中だったが、電話を取り、田中さんのパソコンまで歩いていった。
ログを確認し、入力画面をひとつずつ遡り、山本さんが原因にたどり着くまでに要した時間は約30分。結果は拍子抜けするほど単純だった。必須項目である「納品希望日」が未入力だったのだ。システムはそれをサーバーエラーとして処理し、開発者向けのエラーコードをそのまま画面に表示していた。田中さんは何も間違ったことをしていない。ただ、システムが「何が起きているか」を教えてくれなかっただけだ。
この30分の間、田中さんの手は完全に止まっていた。山本さんは自分の本来の業務を中断し、他の問い合わせも滞った。そして何より、田中さんの中には「またあの画面が出たらどうしよう」という不安が残った。翌週、田中さんは似たようなエラーに遭遇したとき、今度は自分で解決しようとせず、真っ先に電話を取った。原因を突き止める自信がなかったからだ。
これは特別な話ではない。全国の中小企業の現場で、毎日のように起きている光景だ。エラーメッセージという、たった一行の文字列の設計が甘いだけで、現場の手は止まり、情シス担当の時間は溶け、会社全体の生産性がじわじわと削られていく。この記事では、なぜそんな意味不明なエラーメッセージが生まれるのか、それがどれほどの実害を生んでいるのか、そしてわかりやすいエラーメッセージをどう発注時に設計依頼すればよいのかを、現場に立つすべての人のために書く。
なぜ意味不明なエラーメッセージが生まれるのか
Error: Code 500というメッセージは、実はシステムを作ったエンジニアにとってはとても分かりやすい情報だ。500番台のエラーコードはサーバー側で何らかの問題が起きたことを示す、いわばプログラムの世界の共通言語である。開発者はこのコードを見れば、どのプログラムのどの処理で問題が起きたのか、ある程度見当をつけることができる。
問題は、このエンジニア向けの言語が、そのまま現場の画面に出力されてしまうことにある。なぜそんなことが起きるのか。理由は主に三つある。
一つ目は、開発の優先順位だ。システム開発の現場では、機能が「正しく動く」ことに開発工数の大半が割かれる。エラーが起きたときにどう表示するかという設計は、後回しにされがちな部分だ。納期に追われる中で、開発者は「とりあえずエラーコードを出しておけば動作確認はできる」という状態のまま、そのメッセージを本番環境に残してしまう。
二つ目は、想定外のエラーへの対応漏れだ。開発者は「よくあるエラー」については丁寧なメッセージを用意することが多い。しかし、必須項目の未入力、通信のタイムアウト、他のユーザーとの同時編集の衝突といった、想定していなかった組み合わせのエラーが起きると、システムはあらかじめ用意されたメッセージを持たず、プログラムの内部エラーをそのまま吐き出してしまう。田中さんが遭遇したのは、まさにこのパターンだった。
三つ目は、発注側と開発側の間で「エラーメッセージの品質」が要件として明文化されてこなかったことだ。見積書や要件定義書には、画面のレイアウトや機能の一覧は細かく書かれていても、「エラーが起きたときに何と表示するか」という項目はほとんど存在しない。書かれていないものは作られない。これが最大の原因だ。
つまり、意味不明なエラーメッセージは、誰かの怠慢というよりも、発注側と開発側の間に「決めるべきこと」として意識されてこなかった、構造的な抜け漏れの結果なのだ。
わかりにくいエラーメッセージが引き起こす実害
この抜け漏れは、机上の話では終わらない。現場では具体的な損失として積み上がっていく。
まず一つ目は、問い合わせ対応にかかる工数だ。仮に一つの意味不明なエラーの解決に平均15分かかるとして、それが月に20件発生すれば、情シス担当者は月に5時間、丸一営業日近くをこの対応だけに費やしている計算になる。しかも、この時間は本来取り組むべき業務改善やシステムの安定運用の時間を確実に奪っている。情シス担当が一人しかいない中小企業では、この負担は特に重い。問い合わせが来るたびに手を止め、現場に駆けつけ、原因を探し、また自分の仕事に戻る。この往復自体が集中力を奪い、実質的な工数は表面上の時間以上に膨らむ。
二つ目は、現場の作業停止だ。田中さんのケースのように、エラーが出た瞬間、その担当者の作業は完全に止まる。締め切りが迫っている業務であればあるほど、この停止は精神的な負荷にもなる。受注処理、発注処理、勤怠入力といった日次業務がシステム化されている会社では、こうした停止が積み重なることで、月末や締め日に業務が滞留し、残業につながるケースも少なくない。
三つ目は、入力ミスの繰り返しだ。これは見落とされがちだが、実は最も深刻な問題かもしれない。わかりにくいエラーメッセージは、ユーザーに何を直せばいいのかを教えてくれない。そのため、ユーザーは「とりあえず入力し直す」「別の項目を触ってみる」といった、当てずっぽうの試行錯誤を繰り返すことになる。これは同じ種類の入力ミスが何度も発生する温床になる。本来であれば一度で解決できたはずのミスが、原因が伝わらないことによって二度、三度と繰り返される。
そして、これらすべての土台にあるのが、現場の心理的な負担だ。エラー画面を前にして「自分が何か間違えたのか、システムの問題なのか」が分からない状態は、真面目に働いている人ほど強い不安を感じさせる。田中さんが翌週のエラーで真っ先に電話を取ったように、わかりにくいエラーメッセージは、現場の自律的な問題解決能力を少しずつ奪っていく。これは単なる操作性の問題ではなく、現場で懸命に働く人たちの尊厳に関わる問題だと、私たちは考えている。
わかりやすいエラーメッセージの条件
では、わかりやすいエラーメッセージとはどういうものか。結論から言えば、次の三点が明示されていることに尽きる。
- 何が起きたか(現状の説明)
- なぜ起きたか(原因の説明)
- どうすればいいか(次に取るべき行動)
田中さんが実際に遭遇したエラーを例に、悪い例と良い例を比べてみよう。
悪い例はこうだ。「Error: Code 500」。これでは何が起きたのかすら分からない。
良い例はこうなる。「受注情報を保存できませんでした。納品希望日が入力されていません。カレンダーのアイコンから納品希望日を選択し、もう一度確定ボタンを押してください。」
この一文には、何が起きたか(保存できなかった)、なぜ起きたか(納品希望日が未入力)、どうすればいいか(カレンダーから選んで再度確定)の三つがすべて含まれている。田中さんがこのメッセージを見ていれば、電話をかける必要はなく、その場で10秒もかからずに解決できたはずだ。山本さんの30分も、田中さんの心理的な負担も、どちらも発生しなかった。
加えて、実務上とても重要なのが、未入力の項目そのものを画面上で視覚的に示すことだ。エラーメッセージの文章だけでなく、該当する入力欄を赤枠で囲んだり、欄のすぐそばに短い注意書きを添えたりすることで、ユーザーは文章を読み解く前に、目で見て「ここが問題だ」と理解できる。文章による説明と、画面上の視覚的な指示は、両輪で機能してこそ効果を発揮する。
もう一つ重要なのが、エラーメッセージのトーンだ。「入力エラーです」「不正な値です」といった突き放すような表現は、たとえ内容が正確でも、現場の人を萎縮させる。「もう少しで完了です。あと一つだけ確認をお願いします」といった、次の行動へ自然に導くトーンを選ぶことも、わかりやすさの一部だと私たちは考えている。エラーメッセージは、システムが現場の人と交わす会話の一部なのだ。
発注時にどう設計を依頼すればいいか
ここまでの内容を理解したとして、次に経営者やシステム担当者が直面する疑問は「では発注時に何をどう伝えればいいのか」だろう。エンジニアではない立場から、技術的な仕様書を書く必要はない。伝えるべきは考え方と具体例だ。
まず、要件定義の段階で次のような一文を必ず盛り込むことをお勧めする。「すべてのエラーメッセージは、何が起きたか、なぜ起きたか、どうすればいいかの三点を、専門用語を使わずに記載すること。エラーコードや技術的な例外メッセージをそのままユーザーに表示しないこと。」
この一文があるだけで、開発会社は設計段階からエラーメッセージを後回しにできなくなる。見積もりの段階でこの項目を伝えれば、開発会社側もエラーメッセージ設計に必要な工数を織り込んで提案してくる。逆にこれを伝えなければ、多くの場合、エラーメッセージは開発の最後の最後に、最小限の労力で片付けられてしまう。
次にお勧めしたいのが、具体的な文言例を一つか二つ、要件定義書やRFPに添えることだ。先ほどの受注入力の例のように、「悪い例:Error: Code 500」「良い例:受注情報を保存できませんでした。納品希望日が入力されていません。カレンダーのアイコンから納品希望日を選択し、もう一度確定ボタンを押してください。」という対比を一つ示すだけで、開発会社は求められている品質水準を具体的にイメージできる。抽象的に「わかりやすくしてほしい」と伝えるよりも、はるかに伝わる。
さらに踏み込むなら、開発工程の中に「エラー画面のレビュー工程」を明示的に含めることを提案したい。多くのプロジェクトでは、画面デザインのレビューや、正常に動作する機能のテストは丁寧に行われる一方で、エラー時の画面は納品直前に開発者が動作確認する程度で終わってしまう。要件定義の段階で「テスト工程には、代表的なエラーパターン(必須項目未入力、通信エラー、権限不足など)を実際に発生させ、そのメッセージ内容を発注者側がレビューする工程を含める」と明記しておけば、納品前に現場目線でのチェックが入る。これは決して過剰な要求ではなく、システムを実際に使う現場の人たちへの、最低限の配慮だと私たちは考えている。
もう一つ、見落とされがちだが効果が大きいのが、想定されるエラーパターンの洗い出しを、発注側と開発側が一緒に行う工程を設けることだ。「この画面でユーザーがやってしまいそうな間違いは何か」を、現場の業務を知る担当者と、システムの構造を知る開発者が一緒に洗い出す。これによって、開発者だけでは気づけない現場特有のエラーパターン(例えば、紙の伝票からの転記時に起きやすい入力ミスなど)への対応も、設計段階で組み込むことができる。
よくある失敗パターン
最後に、発注時によくある失敗パターンをいくつか挙げておきたい。同じ轍を踏まないための参考にしてほしい。
一つ目は、要件定義書に「使いやすいシステムにしてほしい」とだけ書いて満足してしまうパターンだ。この言葉は誰にとっても異論のない正論だが、具体性がないため、開発会社にとっては何をどう作ればよいかの指針にならない。結果として、エラーメッセージの品質は開発者個人の裁量やその時の余裕に左右されてしまう。
二つ目は、テスト工程を「正常に動くかどうか」だけに絞ってしまうパターンだ。発注者側の検収も、多くの場合は正常系(想定通りの操作をしたときに正しく動くか)の確認に終始しがちだ。異常系(間違った操作やイレギュラーな状況)のテストは工数がかかる割に地味で、削られやすい。しかし現場で実際に問題になるのは、まさにこの異常系の場面である。
三つ目は、リリース後にエラーメッセージの改善を先送りにし続けるパターンだ。「今はひとまず動いているから」という理由で、意味不明なエラーメッセージがそのまま放置され、気づけば数年が経っている、というケースは決して珍しくない。この間、田中さんのような現場の人たちが、見えないコストを払い続けていることを忘れてはならない。エラーメッセージの改善は、大掛かりな機能追加に比べれば小さな修正で済むことが多い。定期的な保守の中に「エラーメッセージの棚卸し」という項目を組み込むことも検討する価値がある。
四つ目は、開発会社に丸投げしてしまうパターンだ。「専門的なことは分からないので、良いようにお願いします」という姿勢は、一見謙虚なようでいて、実は現場の実情を最もよく知る発注者側の情報を、開発会社に届けないまま設計を進めさせてしまう。エラーメッセージは技術の話である以前に、現場の業務理解の話だ。発注者にしか分からない情報を伝える責任は、発注者の側にある。
まとめ
Error: Code 500という一行のメッセージの裏には、締め切り前に手を止められた田中さんと、本来の業務を中断してその原因を探した山本さんがいた。二人が失った30分は、システムのどこかに問題があったからではなく、エラーメッセージの設計という、誰も担当しなかった小さな抜け漏れが原因だった。
わかりやすいエラーメッセージには、何が起きたか、なぜ起きたか、どうすればいいかという三つの要素が必要だ。そしてこれは、開発会社に「わかりやすく」とだけ伝えても実現しない。発注する側が、具体的な文言例を示し、レビュー工程を要件に組み込み、現場で起こりうる失敗のパターンを一緒に洗い出す。この一手間が、日々現場で働く人たちの手を止めさせず、情シス担当者を電話対応から解放し、会社全体の時間を守ることにつながる。
システムを発注するということは、単に機能を作ってもらうことではない。その先で働く一人ひとりが、迷わず、萎縮せず、自分の力で前に進めるようにすることだ。エラーメッセージという小さな一文の設計にまで気を配ることは、現場で壁を越えて働く人たちへの、何よりの敬意の表し方だと私たちは考えている。