応用情報技術者試験 過去問 2025年(令和7年) 春期 午後 問8
エラーハンドリング
Q社は、業務システムの受託開発会社である。Q社は、スーパーマーケットの複数の店舗を運営するB社から、CRM (Customer Relationship Management) システムの開発と運用保守業務を受託した。CRMシステムは各店舗で利用され、顧客からの意見やクレーム、店舗での対応の内容が登録・蓄積される。CRMシステムを運用する際の関係者の一覧を表1に示す。
関係者 | 説明 |
---|---|
顧客 | B社の店舗に来店した顧客。意見やクレームを、店舗に勤務するB社の従業員に伝える。 |
利用者 | CRMシステムへのアクセスが許可されたB社の従業員。顧客からの意見やクレームをCRMシステムに入力し、過去の類似案件の記録を参考に顧客対応を行う。顧客から聞き取った氏名と連絡先を、CRMシステムに顧客情報として登録することがある。顧客情報は、B社の従業員が顧客に連絡するためだけに利用する。 |
運用担当者 | B社に常駐しているQ社の従業員。CRMシステムの運用手順書に従って、利用者から受けた問合せに対応する。関合せ時の状況や不具合の再現手順の確認のため、運用中のCRMシステムへのアクセスが許可されている。運用手順書で対応しきれない技術的な問題については、Q社の開発担当者に対応を依頼する。 |
開発担当者 | Q社内で勤務しているQ社の開発担当者。運用担当者からの問合せの際は、調査に必要な最小限の情報として、不具合の状況、再現手順及び発生時刻近辺のログを受け取る。運用中のCRMシステムへの入力情報を、直接参照することはできない。 |
Q社は、システムのリリース後に想定される、店舗からの問合せに対する迅速な対応を可能にするために、想定される問合せのパターンと対応方法を事前に整理し、対応の際に必要な要件をシステムの設計に反映させることにした。
CRMシステムの構造
CRMシステムのクラス図(一部)を図1に示す。AbstractController、AbstractService及びAbstractDaoは、それぞれ画面遷移、ビジネスロジック及びデータベースアクセスの共通処理が実装された抽象クラスである。これらのクラスをaしたクラスを作成して、具体的な機能を実装する。ログを出力するにはLoggerクラスを利用する。ログの出力時には"DEBUG"、"ERROR"などの、ログの種別(以下、ログ種別という)が記録される。図1に示すクラスを使った処理の流れの例として、システムにログインする際のシーケンス図を、図2に示す。

利用者がログイン画面で認証に必要な情報を入力しログインを実行すると、LoginControllerのログイン実行メソッドが呼び出される。ログイン実行メソッドは、画面から入力された情報をAuthServiceに引き渡す。AuthServiceは、UserDaoに実装されている、利用者情報の検索を行う機能を用いて、認証の判定に必要な利用者情報をデータベースから取得する。AuthServiceは、取得した利用者情報を用いてログイン認証の判定を行い、結果を返す。

プログラムの実行中にエラーが発生した際の、例外処理用のクラスとしてExceptionクラスがある。Exceptionクラスは、エラーの詳細情報として、エラーの発生箇所のソースファイル名、行番号、メソッドの呼出し履歴及び直接的な原因を示すメッセージ文字列をもつ。エラー発生時には、エラーの発生箇所でExceptionクラスのオブジェクトを作成し、呼出し元ではそれを使って例外処理を行う。
CRMシステムのエラーの種別の整理とその対応
Q社は、運用中に起き得るエラーの種別(以下、エラー種別という)を整理し、対応方法について検討した。エラー種別と運用担当者の対応を表2に、対応を行うために必要な出力機能及び出力内容と、出力内容を参照する関係者を表3に示す。
エラー種別 | 説明 | 運用担当者の対応 |
---|---|---|
システム障害 | Webサーバやデータベースサーバの停止、プログラムの異常終了、ネットワーク障害などの原因によって、システム自体の稼働が継続不能になる。 | 利用者からの報告を受けて、サーバやサービスの稼働状況を確認し、必要に応じて再起動を行う。それでも復旧できない場合は開発担当者に対応を依頼する。 |
システムエラー | 主にプログラムの欠陥によって発生する。具体的なエラー、操作の途中で画面にエラーメッセージが表示され、業務を続行できない。 | 利用者から、操作した手順を聞き取り、状況を確認する。エラー発生時の前後のログをログファイルから切り出して開発担当者に送付し、対応を依頼する。 |
業務エラー | 業務ルール上、入力値の内容が正しくないか、禁止されている操作をしたときに発生するエラー。プログラムで想定済みのエラーで、利用者が入力値の内容を修正し、操作をやり直すことによって業務を続行できる。 | 利用者から、操作した手順と、画面に表示されたエラーメッセージの内容を聞き取り、状況を確認する。運用手順書を参照し、エラーの回避方法を利用者に伝える。回避方法が不明な場合は、エラーの再現手順とエラー発生時の前後のログを開発担当者に送付し、回避方法の提示を求める。 |
入力エラー | 文字列長や文字種に関する入力値の検証時のエラー。利用者自身が入力値を修正することによって業務を続行できる。 | 対応なし。利用者自身が、画面に表示されているエラーメッセージを参照してエラーを解消する。 |
出力機能 | 出力内容 | 参照する関係者 |
---|---|---|
ログ出力 | プログラムの実行中に想定外の事態が発生した場合は処理を中断し、処理の呼出し元にエラーの内容を返す。その際、エラーの概要、詳細情報及びメソッドの呼出し履歴をLoggerクラスを使ってログファイルに出力する。 | d |
エラーメッセージ表示 | エラーの概要、Exceptionクラスがもつエラーの詳細情報及び利用者が次に行うべき操作の案内を画面に表示する。 | 利用者 |
表2、表3についてレビューを行ったところ、次の3点が指摘された。
- 表2のシステム障害及びシステムエラーは、利用者の問合せの前にシステムが自動的に検出して運用担当者が対応を開始できるようにすべきである。
- 表3の出力内容には、セキュリティの観点における潜在的なリスクがある。
- 表3について、エラーに関するログだけでは、開発担当者が原因を調査するための情報としては不足するので、追加の情報を出力する必要がある。
指摘事項の(1)に対応するために、①監視の機能を用意することにした。監視の機能は、監視対象の情報を定期的に取得し、エラー発生時の特徴を検出した場合に電子メールで運用担当者に通知する。指摘事項の(2)については、表3の②出力内容を一部変更することにした。指摘事項の(3)については、アスペクト指向プログラミングを導入して、プログラムの処理の中で、要所ごとにログを出力することにした。
アスペクト指向プログラミングの導入
レビューの指摘事項の(3)に関連して、利用者が行った操作内容を一律でログに出力することにし、これを実現するためにアスペクト指向プログラミングを導入することにした。
アスペクト指向プログラミングでは、特定のルールを定義しておくことによって、そのルールに合致する全ての箇所で同じ処理を実行させる。ルールの定義の条件にはクラス名、メソッド名に含まれる文字列のパターンが利用できる。また、特定の条件に合致する場合には実行の対象から除外するように指定することもできる。
ここでは、実装上の制約ができるだけ少なくなるようなルールの定義方法で、画面遷移に関するクラスに実装された全てのメソッドについて、クラス名、メソッド名及び全ての引数の内容をログに出力することにした。これを実現するために、eを親クラスにもつクラスのfには必ず特定の文字列のパターンを含み、それ以外のクラスのfには特定の文字列のパターンを含まないように命名規則を定義した。ただし、秘匿情報や個人情報の保護の観点から、認証に関する情報や、③顧客情報を扱う箇所はログに出力しないようにした。
Q社は、表2、表3に関する検討結果をシステムの設計に反映させ、開発を開始した。