株式会社ヘンリーで医療会計部のエンジニアの一條（GitHub: @rerost , X: @hazumirr）です。
これはHenryアドベントカレンダー 2025 シリーズ 1 における7日目の投稿です。昨日の記事は スタートアップで経営を執行から引き剥がした10ヶ月間 でした。
僕は今まで、
- 複雑な診療報酬をちょっとずつ理解しながらの開発
- インシデント時のコマンダー
- ロジックが複雑かつ機械学習を入れた検索システムの構築（前職）
といったことをしていました。
なので、わけのわからないバグに遭遇する機会は多い方だったと思います。
この経験の中で僕が実践していたことについて書きます。
目次
バグ自体の分類
割とここが肝だと思っていて、バグ自体が分類できたら対応の9割は終わったと言っても過言ではないと思います。
僕は、発生源・影響度の二軸で考えています。
緊急度
緊急度はバグ対応中にかなり早くに明確にしておくと対応がスムーズです。
- リリース済み機能でユーザーの行動がブロックされることがあり、即座に対応しなければいけない
- リリース済み機能でユーザーでの回避策などがあるが、早めに直さないとユーザーに手間を取らせてしまう
- 未リリースなどでユーザーに影響しない
1なら、まずは回避策を練るか一次対応するなどで根本対応より先にでること。対応へのリードタイムを減らすためにも、人を集めましょう。
2なら、落ち着いて原因を探りつつ、ユーザーへの案内などを速やかに行いましょう。
3なら、ゆっくり調べましょう。
といった具合です。
バグの発生源の種別
発生源は多くの場合、以下のどれかに分類されるかと思います。
- 実装のみからくるもの。例: 外部ライブラリの使い方やアップグレードなど
- 現状動いているものと、以下のどれかとのズレ
- 過去の仕様
- 関連するルールや法律など
2つ目の部分の説明をしていくと、まず具体例としては以下があります。
| 発生源 | 例 |
|---|---|
| 過去の仕様 | 昨日まで検索でヒットしていたものがヒットしなくなった。 先月まで自動で入力されていた部分が入力されなくなった。 |
| 関連するルールや法律など | XXを算定すると、自動でYYも算定されるはずだが、算定されない。 |
このどちらかが、実装とズレていることでバグは発生します。
更にたどると、実装者がどれとズレているか、実装者の意図しない実装になっているのか、もしくは実装者自身が過去仕様・関連するルールの理解がズレているかがあります。
これらの要因は、実装者のバグが入ったPRの文章やバグを報告してくれた方に話を聞いていくことで多くの場合は特定できるかと思います。
対応の流れ
- 再現する
- 手元環境で再現する
- 具体のバグ発生パターンをいくつか集める
- 原因を特定する
- 状況を言葉にし、まとめる
- 関連するものを図に起こす
- 発生しないという主張・発生するかもしれないという主張、を交互に繰り返し出し続ける
- 修正する
再現する
手元で環境構築などをし、報告されたスクリーンショットや報告内容から同じ状況を再現し、試しましょう。
うまく再現できない場合、弊社の開発する電子カルテ・レセコンだと、医療機関の設定や患者の状態（過去の操作）が影響するので、以下を確認するのが良いです。
- 医療機関設定
- 病棟・病床の設定
- 都道府県
- 連携する検査機関の設定
- 機能の有効無効
- etc…
- 患者の状況
- 過去算定されたもの（※ 制度上、過去の会計データに依存するロジックなどがある）
- 保険
- etc…
また、報告されたケースと類似のバグが再現するケースを集めておくと、修正時のチェックで役に立つのでおすすめです。
原因を特定する
原因の特定ですが、まずはここまで得られた情報を元に、特定していきましょう。
無論、ここまで集まった情報で原因特定が済んでいるのであれば、スキップしましょう。
コードなどを読みながら、状況を言葉や図にしてまとめていくのが肝で、わけがわからない状況のとき、言葉や図にしておくことで頭で抱え続ける情報を減らすことができます。
また、自身で
- このバグは発生しない。なぜなら〜、と主張をする
- このバグは発生する。なぜなら〜、と主張をする
を繰り返していくこともおすすめです。
例えば、昨日まで検索でヒットしていたものがヒットしなくなった場合だと、
- このバグは発生しない。なぜなら検索対象のデータは昨日と変化しておらず状況が変わらない
- このバグは発生する。なぜなら検索対象のデータは先程の調査で確認した部分以外も対象だからだ
- ….
みたいな形で進めて行くと、仮説を立てながら調査していくのがスムーズにできるし、見落としが減ります。
修正する
修正の際、考慮する必要があるのは、
- 二次被害を産まないか？
- 十分な対応か？
です。
例えば、ブログが昨日まで検索でヒットしていたものがヒットしなくなった場合には、直したが、下書き状態のブログまで検索の対象になってしまう、だと二次被害を産んでしまっています。
また、十分な対応か？で言えば、検索でヒットしないが問題なので、それ以外の要因でもヒットしなくなっていないか？は確認する必要があります。
特に、わけのわからないバグに遭遇した場合、こういったリスクがあるので注意する必要があります。
最後に
このあたりの話をもっと知りたい方や、ヘンリー全体のこと、などを知りたい方はぜひ一度カジュアル面談しましょう！
