Project Detail
IMSDK障害分析基盤の構築
客訴対応から、再利用可能な障害分析フローへ
Key Results
CS一次判断率
33% -> 53%
Team月間工数
5.1 -> 2.0
対応品質
一次判断とSOP化を改善
Overview
IMSDKにおけるAndroidユーザーからの問い合わせ対応を、担当者依存の調査から、ログ・エラー分類・内部調査ツール・SOPを組み合わせた再利用可能な分析フローへ改善しました。
Background
ユーザーからメッセージ送受信に関する問い合わせが発生した際、CS、QA、Android、Backend、長接続、風控など複数チームの確認が必要でした。当時はエラー原因の分類が十分に統一されておらず、調査担当者によって確認手順が異なるため、同じような調査が繰り返されていました。
Problem
- Android側で取得できるログが不足していた
- エラー原因の分類が統一されていなかった
- CSやQAが一次判断できず、Androidチームへの問い合わせが集中していた
- 複数チームにまたがる確認項目が整理されておらず、問い合わせ対応の品質が担当者に依存していた
My Role
Android側の主担当として、ログ設計、エラー分類設計、SDK内の各フェーズへの埋め込み、内部調査ツールで確認しやすい情報整理、調査フローの標準化を推進しました。また、QA、CS、Backendチームと連携し、問い合わせ時に確認すべき項目をSOPとしてドキュメント化しました。
Technical Approach
メッセージ送信処理を入庫、前処理、アップロード、送信、サーバー応答、クライアント表示のフェーズに分解しました。
各フェーズで確認すべきエラー分類と診断情報を整理し、内部調査ツールから確認できるようにしました。
CS / QA が一次確認できるチェック項目を整理し、再利用可能な調査フローへ落とし込みました。
Troubleshooting Flow
User Report
-> CS / QA First Check
-> Troubleshooting Tool
-> SDK Diagnostic Signals
-> Phase-based Root Cause Classification
-> SOP-based Response
-> Android / Backend Follow-up if NeededResult
CSが一次判断できるケースが増え、Androidチームへの調査依頼が減少しました。CS一次判断率は 33% から 53% に改善し、Team月間工数は 5.1 から 2.0 に削減されました。
What I Learned
障害対応では単にバグを修正するだけでなく、原因を分類し、再現性のある調査フローを作ることが重要だと学びました。