エラーメッセージを軽く見ると、運用・保守でかなり苦しくなる

エラーメッセージは後回しにされやすい

業務システムの開発では、まず機能を動かすことが優先される。その結果、エラー時の文言は後回しになりやすい。

開発中によく見かけるのは、こんなメッセージだ。

「〜が不正です。」

一見それっぽく見えるが、利用者からするとまったく情報がない。

• 何が悪いのか
• どの項目を見直せばよいのか
• どう直せば登録できるのか

そこが分からないと、結局は問い合わせになる。

苦しくなるのは、開発よりも運用と保守

エラーメッセージが曖昧だと、利用者は自力で解決できない。すると、運用担当や保守担当に問い合わせが集まる。

問い合わせを受けた側は、毎回ログや入力データを確認して、

• この項目が未入力です
• このコードは存在しません
• 日付の形式が違います

と調べて返すことになる。1件ずつは小さくても、利用者が多いシステムでは積み重なるとかなり重い。

本来ならシステムがその場で伝えるべきことを、人力で補っている状態だ。エラーメッセージを軽く見ると、開発時には少し楽でも、あとで運用・保守がかなり苦しくなる。

良いエラーメッセージは、利用者を止めにくい

業務システムのエラーメッセージで大事なのは、単に「エラーが起きた」と伝えることではない。それ以上に大事なのは、「次にどうすればいいか」が利用者に伝わることだ。

たとえば、こう書ければ十分に違う。

• 店舗コードが未入力です
• 商品コード 123456 は商品マスタに存在しません
• 入荷日は YYYY/MM/DD 形式で入力してください
• 賞味期限は本日以降の日付を入力してください

このレベルで具体的に出せれば、利用者は自分で直せる。問い合わせは減り、業務も止まりにくい。エラーメッセージは「補助的な飾り」ではなく、運用を支える機能の一部だ。

エラー番号に意味を持たせすぎなくてもいい

実務上そこまで重要ではないと感じるのが、エラー番号に複雑な意味を持たせる設計だ。

番号体系に細かいルールを詰め込むと、新しいエラーを追加するたびに「この番号はどの体系に当てはめるべきか」を考えなければならず、それ自体が運用の負担になる。

もちろん、ある程度の整理は必要だ。ただ、運用や保守の現場では、番号の意味よりもメッセージ本文を見て判断することのほうが圧倒的に多い。

シンプルに管理できる形のほうが現実的

エラー番号は「機能番号＋連番（3桁）」くらいのシンプルな形で十分だと考えている。

• A01-001
• A01-002
• B03-001

この形なら追加しやすく、管理もしやすい。番号そのものに多くの意味を持たせなくても、必要な情報はメッセージ本文で伝えればいい。

さらに、エラーメッセージはコードに直書きせず、テーブル化して管理しておくのがいい。

エラーメッセージは、後から直せるようにしておきたい

エラーメッセージは、実際に運用してみないと分からないことが多い。

開発時には十分だと思っていた文言でも、現場で使われると、

• 分かりにくい
• 問い合わせが減らない
• 想定した伝わり方になっていない

といったことが起こる。

だからこそ、後から文言を修正できる仕組みにしておくことが大切だ。エラーメッセージをテーブル化しておけば、プログラム本体を大きく変えなくても改善できる。運用しながら育てていける形のほうが、現実の業務システムには合っている。

おわりに

業務システム開発では、どうしても機能開発が優先される。それ自体は間違っていない。納期もあるし、まず動くものを出さなければいけない場面は多い。

ただ、その中でもエラーメッセージを軽視しすぎると、あとで運用・保守に大きく跳ね返る。

• 利用者が自力で直せるメッセージになっているか
• 問い合わせを減らせる文言になっているか
• 後から改善できる管理方法になっているか

派手ではないが、こういう部分こそ、業務システムを長く安定して回すために重要だと思っている。