「システムの業務コードがなんとなく読めるようになった。連携システムは多数存在することを知り、処理の流れが分かる様になった。」
そんな方が今、頭を悩ませているのは、バグの原因を突き止められないことではないでしょうか。
顧客から挙がってくるバグの報告。
『エラーメッセージは出ており、エラー箇所のプログラムを読んでみるが原因不明の状態。ログも決定打に欠ける。』
現場あるあるですが、
- 状況の整理をすること
- ここまでは分かっている、分からないの切り分けをすること
が解決の糸口です。
今回は、業務系システムの運用保守で、バグ追及と修正を2年行った筆者が、順を追ったバグの特定方法をご紹介します。
まずは想定されるルート 次に画面全体でバグを引き起こす可能性を探す
最初は難しく考えず、一度、原因が起きた処理のルートを辿ってみましょう。
例えばレコード追加を行っても、追加されないバグです。
正規のルートでは問題なさそうとなった場合でも、一度、追加処理中にクリアなどの取り消しオペレーションを挟む事で配列内の値が消失。
その後、追加処理ルートに戻る。しかし追加処理ルートに帰った際、抜け道があり追加のロジックには触れないプログラムになっていたなどの可能性があります。
大事なのは、追加処理なら追加処理の道筋を見るだけではなく、追加処理（問題箇所）の前後に行ったオペレーションが引き金で、バグ発生があり得るという視点です。
問題が見つからない場合、
追加処理（問題箇所）の前後に行ったオペレーションを可能な限り洗い出し、デバッグ。
それでも、バグが再現しない場合は
画面全体のプログラムを考慮してバグを探すという事も大事です。
追加処理（問題箇所）の前に、
- クリアを行った
- その後、挙動を確かめるために印刷ボタンを押下した
- チェックボックスのチェックを入れないまま追加処理（問題箇所）を行う
- 追加処理中、終了処理を起動したなど
無数のオペレーションを絡めての可能性も存在します。
そして、再現率をグッと上げるためには
- どの環境（本番環境 開発環境 テスト環境）
- 固定の端末（仮想端末も含む）なのか、そうではないのか
- 管理ユーザーなのか、一般ユーザーなのか
- 発生時間帯
- オペレーション手順
を顧客から共有してもらうとバグの輪郭が浮かぶことがあります。
この画面だけが原因と思い込まない
バグが発生すると、どうしても
- 『表示されているエラー箇所』
- 『エラー箇所に関連していそうな部分』
に着目しがちです。しかし、実際の業務システムでは、原因がその画面単体にあるとは限りません。
複数画面や共通処理を多く持つシステムでは、現在開いている画面とは違う画面、およびジョブで起きた影響が、後続画面にも引き継がれることがあります。
例えば、違う入力画面で設定された値をセッションや共通クラスを通じて持ち回っている場合、設定した画面の状態によっては後続画面の処理が変わる場合もあります。
見た目上は正常の遷移でも、内部では想定外の値を保持したままということも意識しましょう。
入力チェックや権限処理などが共通化されている場合、そこにも原因が潜んでいることがあります。
また、
画面遷移の前後で実行される処理の中には、遷移元の処理結果もしくはフラグの状態などが遷移先の条件分岐に関与することもあり得ます。
バグ調査では、今起きている現象だけではなく、どこから来てどこへ向かっているのか？
という流れを頭に入れておくと解決の一助になるでしょう。
連携システムの存在を意識する
画面単体や、共通処理を確認しても原因が分からない場合、意識したいことは連携システムの存在です。
業務システムでは、自画面の処理で完結するケースは少なく、外部システムや外部サーバーと連携していることがよくあります。
API連携をしていた場合、APIから取得したデータで画面表示や登録処理を行う場合があるのです。
レスポンスが正常に返ってきている場合でも、想定と異なるデータおよび空データなどで後続処理がスキップするなどのケースもあります。
バッチ処理や定期処理の影響にも注意が必要です。
夜間バッチで更新されるデータベース情報や、別システムからのデータ取り込みタイミングによって、特定の時間帯のみ不具合が発生する事があります。
- いつ発生したのか？
- 特定の時間帯に偏っていないか
といった観点は、連携処理を疑う重要な手掛かりになるでしょう。
連携の流れを整理する事で、見えていなかった原因が浮かび上がることも少なくありません。
分からない事を前提に整理する
ここまで、原因を広げて確認しても答えが見つからない事は珍しくないです。
そのような場合に大切なのは、分からない事がある前提で状況を整理すること。
原因が分からないままコードを追い続けるよりも、一度立ち止まって情報を整理すると結果的に解決が早まるケースがあります。
まずは、
- ここまで分かっていること
- ここから先は分からないこと
に対して、切り分けを行う必要があると言えるでしょう。
- エラーが発生する画面
- 再現手順
- 発生しないケース
- 環境やユーザー権限の違い
など、事実として確認できている情報を整理します。そのうえで、
- どの条件が揃うと発生するのか
- なぜこの条件でのみ起きるのか
といった、まだ仮説段階の部分を明確にします。
この整理は、自分の思考をクリアにするだけでなく、先輩や他メンバーに相談する際にも大きな助けになるのです。
- 「ここまでは確認しました」
- 「この部分がまだ分かっていません」
と説明できる状態であれば、指摘やアドバイスも的確になりやすく、無駄なやり取りを減らすことができます。
まとめ
原因が特定できないバグに直面したときは、焦ってコードを追い続けるのではなく、視点を段階的に広げて整理することが解決への近道になります。
想定ルートや画面全体、共通処理、連携システムといった観点から状況を見直し、『分かっていること』『分からないこと』を切り分けることで、バグの輪郭は徐々に明確になるのです。
バグ調査は特別な才能ではなく、整理と経験の積み重ねです。
経験1〜3年目の今だからこそ身につけたい考え方として、本記事が現場での一助になれば幸いです。
コメント