給与プロダクトの不具合調査、その戦いの始まり
こんにちは！ジンジャーの安東です。
気がつけば、前回の記事から少し時間が経ってしまいましたね。この間、私は日々プロダクトのカイゼンに奮闘していました。
今回の記事では、私が関わっているジンジャー給与というプロダクトで抱えていた
「不具合調査の非効率さ」 という課題とどのように向き合ったかについてお話します。
Slack通知に頼った不具合調査の限界
当時は、不具合が発生するとSlackに通知されたログから調査を開始していました。
「ある日の調査ではユーザーからの問い合わせを受け、Slackを遡って約1時間…ようやく原因が特定できた...さぁ対応だ！」
このような調査を不具合のたびに繰り返していました。
Slackに通知されたログからの調査にも一長一短があり、まとめてみました。
メリット
- 不具合発生時にリアルタイムで通知が届くため、迅速に一次対応ができる
- Slack上でチームメンバーとすぐに情報共有ができる
- 調査対象のログが一覧で確認できる
デメリット
- ログが流れ、遡るのが困難: 不具合が多発するとログが大量に通知され、過去のログがすぐに流れてしまいます。
- 原因究明の困難さ: 特定のユーザーや状況下で発生した不具合を調査しようとしても、関連するログが点在しており、原因を特定するためのログを辿るのに時間がかかります。
- 調査の属人化: 経験豊富なメンバーでないと、大量のログの中から必要な情報を見つけ出すのが難しい
- ログのトリアージができていない: INFOレベルからERRORレベルまですべてがSlackに流れるため、分類がしづらく、緊急なのかが分かりづらい
このように、Slack通知だけでは不具合調査の効率に限界がありました。
アプリケーションログ基盤への移行とカイゼンの決断
この課題を解決するため、私達はアプリケーションログ基盤への移行を決断しました。
※アプリケーションログ基盤とは以前、こちらの記事で書かれているjinjer社内のプロダクトから横断的にログを収集するために作成した基盤になります。
具体的なカイゼン内容は以下の通りです。
1. 給与Slack通知＋アプリケーションログ基盤利用のハイブリッド運用
Slack通知を完全にやめるのではなく、不具合発生の検知には引き続き利用し、詳細な原因究明はtraceIDを利用して、アプリケーションログ基盤で調査行うハイブリッド体制を構築しました。
下記のようなログからtraceIDを用いて、調査を進めています。
slackに通知されるログ
[API SLOW][JINJI SALARY] ENV : xxxx|| COMPANY ID: xxxx|| API method: POST,path: /api/xxx/yyy/zzz/, Response Time: 9.9999
(traceID: salary_123456789)
アプリケーションログ基盤に出力されるログ
trace_id: salary_123456789
timestamp: 2025-09-XX HH:II:SS
level: ERROR
message: ◯◯の更新処理に失敗しました。 company_id: xxxx
application: salary
stacktrace: xxxx
trace_id: salary_123456789
timestamp: 2025-09-XX HH:II:SS
level: INFO
message: ◯◯の更新処理に失敗しているため、ロールバックしました。 company_id: xxxx
application: salary
stacktrace: xxxx
アプリケーションログ基盤はAWS Athenaを用いた検索方法もあり、slackに通知されたログがわからなくても検索することが可能となっています。
これにより、「不具合が発生した」という事実は即座にキャッチしつつ、調査そのものは体系的に行えるようになりました。
2. 既存給与処理へのログ組み込み
この新しいログ運用体制を既存の給与処理に組み込むのが最大の難所でした。
複雑な処理へのログ組み込み
給与計算の処理は非常に複雑で、多くのロジックが絡み合っています。
この複雑なロジックのどこに、どのような情報をログとして出力するか、設計段階から試行錯誤を繰り返しました。
特に、給与計算のプロセスを追跡できるよう、ユーザーIDや処理IDを紐付けながらログを出力する仕組みを実装するのに苦労しました。
カイゼン結果と今後の展望
今回のカイゼンにより、不具合調査のプロセスは劇的に変化しました。
冒頭で例に出した調査で約1時間かかっていたところが、約10分で原因特定できるようになりました🙌
カイゼン結果
- 原因究明のスピードアップ: ログが時系列で整理され、ユーザーIDなどの検索キーで絞り込めるようになったため、根本原因にたどり着くまでの時間が大幅に短縮されました。
- 調査の効率化: 無関係なログに惑わされることなく、必要な情報に素早くアクセスできます。
- 調査の標準化: 誰でも同じように調査ができるようになり、属人化を解消できました。
残課題
-
アプリケーションログの組み込み: ジンジャー給与は規模がとても大きいため、重要なところから組み込みを開始しており、まだ全体をカバーできていません。
- 開発スプリントの中で、組み込みをタスク化して、組み込みを進めています。
-
Slack通知からの脱却: アプリケーションログ基盤でログレベルに応じて通知をしてくれているので、ジンジャー給与側での通知を不要にしたい
- アプリケーションログの組み込みがジンジャー給与全体に及んだタイミングで、給与側からの通知を脱却しようと思っています。
まとめ
本記事では、給与プロダクトにおける不具合調査の課題と、それを解決するためのカイゼンについてご紹介しました。
私達のチームはこれからも、より良いプロダクト開発を目指して、日々の業務のカイゼンを続けていきます。
最後に
記事を読んでくださり、ありがとうございました！
今回は開発の中でもカイゼンにフォーカスして記事にしてみました。
少しでもjinjerのプロダクト開発部がどういうことをやっているか、知ってもらえれたら嬉しいです！
また、不具合調査という地道な課題に対しても、泥臭く、しかし着実にカイゼンを進めています！
そんなカイゼンの先には開発組織が掲げている「日本一の開発」があると本気で思っていますので、ぜひ一緒に挑戦しませんか？
Discussion