はじめに
システム開発では、正常に動作する機能ばかりに注目しがちです。しかし、実際の運用では「想定外」は必ず発生します。通信が切れる、ファイルが存在しない、入力値が不正、データベースへ接続できないなど、エラーが起こる場面は数え切れません。
このような状況で重要なのは、エラーをどう実装するかではなく、「どのように振る舞うシステムにするのか」を設計段階で決めておくことです。実装時にその場しのぎで例外処理を書き始めると、エラーへの対応が画面や機能ごとにばらつき、保守性や品質の低下につながります。
この記事では、なぜエラー処理は設計段階で決めるべきなのか、設計で考えるべきポイントと実装との役割分担について解説します。
エラー処理は「プログラムの書き方」ではなく「システムの振る舞い」である
例外処理という言葉を聞くと、多くの人は try-catch や throw のようなプログラミング言語の機能を思い浮かべます。しかし、それらはあくまで設計を実現するための手段です。
本来考えるべきなのは、「エラーが発生したら利用者へ何を表示するのか」「処理を継続するのか中止するのか」「ログを残すのか」「運用担当へ通知するのか」といったシステム全体の振る舞いです。これらはプログラマー個人の判断で決めるものではなく、設計として統一されている必要があります。
例えば、ある画面ではエラー画面を表示し、別の画面では何も表示されず終了するといった状態では、利用者はシステムの動作を予測できません。同じ種類のエラーであれば、同じ考え方で対応することが品質につながります。
実装段階で考え始めると対応がばらつく
設計書にエラー処理の方針が書かれていない場合、開発者はその都度判断するしかありません。
ある開発者は例外をログへ出力して再スローし、別の開発者はエラーメッセージだけ表示して終了、さらに別の開発者は例外を握りつぶして処理を続行するといった状況が起こります。
一つひとつを見ると大きな問題には見えなくても、システム全体では統一性が失われます。障害調査ではログが残っていなかったり、利用者から見ると同じような操作なのに異なるメッセージが表示されたりするため、運用や保守の負担は確実に大きくなります。
実装時に自由度を残すほど品質が向上するわけではありません。むしろ設計段階で判断基準を決めておくことで、誰が実装しても同じ品質を実現しやすくなります。
設計で決めるべきエラー処理の方針
設計では、「エラーが発生する可能性がある」ことを前提として方針を整理します。
例えば、利用者へ表示するメッセージは詳細な技術情報を表示するのか、分かりやすい文章だけにするのかを決めます。また、異常終了させるケースと処理を継続できるケースの境界も設計で整理します。
さらに、ログの出力レベルや出力内容、運用監視への通知有無、トランザクションをロールバックする条件なども設計対象です。これらはプログラムを書く人がその場で判断する内容ではありません。
設計書に明確な方針があれば、実装者は迷わずコードを書けます。一方、設計が曖昧であればあるほど、実装者ごとの解釈が入り込み、品質に差が生まれます。
例外にも優先順位がある
すべてのエラーを同じように扱う必要はありません。重要なのは、システムへの影響に応じて対応を分けることです。
例えば、一時的な通信エラーであれば再試行できる場合があります。一方、データの整合性が崩れるようなエラーでは、処理を中断してロールバックしなければなりません。また、利用者の入力ミスであれば入力画面へ戻すだけで済むこともあります。
つまり、「エラーが発生した」という事実だけでは適切な対応は決まりません。エラーの種類や影響範囲を設計段階で分類しておくことで、一貫した対応が可能になります。
ログ設計もエラー処理の一部である
障害対応では、「何が起きたのか分からない」という状況が最も困ります。そのため、エラー処理ではログ設計も非常に重要です。
ただし、何でも記録すれば良いわけではありません。ログが大量に出力されると、本当に重要な情報が埋もれてしまいます。逆に情報が少なすぎると、原因調査に時間がかかります。
設計では、「どのエラーを記録するか」「どの情報を残すか」「利用者へ表示する内容とログへ出力する内容を分けるか」といった点まで整理しておくことが重要です。
運用担当者がログだけを見て状況を把握できるかどうかは、実装技術よりも設計品質に大きく左右されます。
実装は設計を実現する工程である
設計と実装の役割を混同すると、「例外処理を書いているから設計もできている」と考えてしまいがちです。しかし実際には逆です。
設計では、「どのような振る舞いを実現するか」を決めます。実装では、その方針に従って try-catch や例外クラス、エラーコードなどの仕組みを利用して設計内容を実現します。
つまり、実装技術は手段であり目的ではありません。設計が定まっていれば、使用するプログラミング言語が変わっても考え方は大きく変わりません。
逆に、設計が曖昧なまま実装へ進むと、どれほど高度な例外処理機能を使っても、システム全体として一貫した品質を実現することは難しくなります。
まとめ
エラー処理は、単なるプログラムのテクニックではありません。利用者への通知方法、処理の継続可否、ログの出力、運用時の対応まで含めたシステム全体の設計です。
実装段階で個別に判断すると、画面ごと・機能ごとに対応がばらつき、保守性や障害対応の効率は低下します。一方で、設計段階からエラー処理の方針を統一しておけば、誰が実装しても品質を揃えやすくなります。
正常系の動作だけを設計するのではなく、「異常が起きたときにどう振る舞うか」まで設計できて初めて、運用しやすく保守性の高いシステムになります。エラー処理を実装の課題として考えるのではなく、設計品質を左右する重要な要素として捉えることが、長く使われるシステムを作る第一歩です。
コメント