急成長を追うインシデントマネジメントのアプローチ

6/11開催 「成長企業に学ぶ！インシデントマネジメントのノウハウ」 での発表資料

Transcript

1. 急成長を追うインシデントマネジメントのアプローチ 成長企業に学ぶ！インシデントマネジメントのノウハウ 2024.06.11 1
2. 赤川 龍之介 - @r_akgw 所属 株式会社BuySell Technologies テクノロジー戦略本部　開発２部 担当領域 CosmosプロダクトのEM 趣味 バドミントン、キャンプ、筋トレ 経験業界 • ソシャゲ • SIer • 求人紹介 • リユース
3. • 成⻑企業は組織、事業やプロダクトのフェーズによって求められる 品質が変動する • インシデントマネジメントのアプローチも各フェーズに応じて適応 することが⼤切 ◦ 理想ドリブン ◦ ユーザの声を聞く • PDCAサイクルを回した話を紹介 今⽇伝えたいこと 3
4. 事業紹介 4 総合リユース事業を展開
5. 事業紹介 5 販売 在庫管理 買取・査定 買取申込 • 紙オペレーションをデジタル化 ◦ 契約書　→　電子データ • ノウハウ化した業務プロセスを自動化・補助 顧客特定 ルーティング プライシング 買取契約書作成 ささげ(採寸・撮影・原稿) 棚卸し 出品管理 販路最適化
6. 注力プロダクト 6 リユースプラットフォームCosmosを開発中 接客時間40%減 店舗のシステム操作トレーニング期間が1ヶ月→１日
7. 背景 7
8. • 向き合いとしている事業部によってプロダクトの性質が異なる ◦ トラフィック数 ◦ 取り扱う数値の重要性 ◦ 社内向け(全般) / toB(オークション) / toC(マーケティング) • プロダクトチームの⾊が強い ◦ 開発ルールやインシデントの取り扱いが独⾃ルール 私達を取り巻く環境 8
9. 感じていた違和感 9 • これまではそれでよかったかもしれないが • なんとなく... ◦ このプロダクトインシデント多くない‧‧？ ◦ あれ、この間のインシデント報告書なくない‧‧？ ◦ 事業部に連絡しなくていいの‧‧？ ◦ 復旧まで遅くない‧‧？ ◦ あれ、また同じ⼈がインシデント対応してる‧‧？ ◦ 紙オペレーションに切り替えるから⼤丈夫って思ってない ‧‧？
10. • 違和感を解消するべくタスクフォースチームを結成 ◦ 必要であれば組織横断でルールメイクする • FY21にCTO今村⼊社以降、開発組織は急拡⼤‧急成⻑ 開発組織が急成⻑ 10 • 新卒‧中途のメンバーの急増 • 新規プロダクト及びプロダクトチームの増加
11. 理想の状態 タスクフォースチームと認識合わせを実施 Q. なぜインシデントマネジメントに注⼒するか • 開発チームとユーザとの距離が近く、信頼関係が重要 ◦ 仕様策定やスプリントプランニングで情報開⽰を求めるのに、プロダクトのバ グを放置するのは不誠実 Q. 理想の状態とは？ • 理想像を洗い出して、 現状とのギャップを測りたい • が改めて「今の状態が⾒えてなさすぎる」 ◦ PDCAサイクルを回しつつ、改善する 11
12. 取り組み ~ 第１サイクル：可視化 ~ 12
13. • 過去何件インシデントが発⽣したか、今課題管理されているインシ デントはどういう状態か(発⽣中 or 暫定対応中...?)がわからない • 報告するか否かのルールもプロダクトによってバラバラ ◦ ルールをバシッと決めて、可観測性を上げる ◦ インシデント案件はJIRA、報告書はConfluenceに集約しよう 第１サイクル：可視化 13
14. • インシデントとして取り扱う or 取り扱わないを明⽂化 インシデント重⼤度の設定 14 • 重大度S〜Dの５段階評価 • ≒影響範囲が (組織 > 個人) × (未来 > 現在)
15. • インシデント案件をJIRAに集約したい ◦ 発⽣~チケット起案までの流れを整理 インシデントマニュアルの設定 15 • 迷ったらここを見る (調査のコツまで詳細に記 載) • インシデントコマンダーを立てる
16. • マニュアルが難しすぎるので、Slackワークフローを提供 ◦ 未経験者‧⾃信がない⼈はWFを⽴ち上げてね、のスタンス Slackワークフローを作成 16 ※他社事例を参考にさせていただきました
17. インシデント集約の基盤が完成 • 「迷ったらSlackWF⽴ち上げ」が浸透してき た • WF起動(ボタンポチー)は、Slackでメンショ ン送るよりも⼼理的ハードルが低い ※前提としてWF間違えて⽴ち上げても問題な いことを周知 取り組みの結果 17
18. 取り組みの結果 18 インシデントの傾向からプロダクトの状態を推測できるように ◦ 件数は少ないが１件あたりの重⼤度が⾼い → 技術的負債が溜まっている、⼿動オペレーションが多い？..etc ◦ 件数は多いが１件あたりの重⼤度が低い → FEの更新頻度が多く、テストが網羅できてない？...etc ◦ どちらも多いし⾼い → 根本的な問題が他にある？
19. 集約した情報の利活⽤ • プロダクトのインシデントが集約 ◦ インシデントダッシュボードの提供 ▪ 発⽣傾向‧再発防⽌の滞留状況 ◦ 障害共有定例の開催 ▪ ポストモーテムの共有 19
20. 「なんとなく」が明確になってきた • インシデントの状態を可視化 ◦ 重⼤度 × 発⽣件数 ▪ 異常検知したプロダクトのロードマップ⾒直し ◦ ポストモーテムの活⽤ ▪ リバートルールの検討 取り組みの結果 20
21. 取り組み ~ 第２サイクル：改善 ~ 21
22. ルール適⽤から半年ほど経過... • 外野から⾒ていて、気になっていた部分 ◦ Slackワークフローの起動のみで完了 ◦ 再発防⽌の検討に苦戦 • マインドの変化も確認したい • ジュニアメンバーを中⼼にヒアリング 第２サイクル 22
23. ユーザヒアリング 23 品質に対する向き合い方が変わっ た。いい方向に向かっている。なぁ なぁで終わらない インシデント対応が放置されてい ることがなくなった マニュアル・テンプレート化によっ て、再発防止検討の型ができて思 考しやすくなった 技術的負債・負の遺産系の調査の 対応が辛い スピード感をもって対応できるよう になった 報告書作成が大変で業務が圧迫 される 対応順を入れ替える時、ワークフ ローが使いにくい 新卒としてはチュートリアル(防災 訓練)があると助かる アーキテクチャやドメインが異なる のでポストモーテムが活かしきれ ない
24. 理想状態とのギャップ 24 • 初期応答時間 ◦ 初速のためにもワークフローは汎⽤的でなくてはならない • 的確な再発防⽌策 ◦ ポストモーテムの利活⽤
25. Update1. マニュアル&Slackワークフローの改善 25 • プロセス&調査のコツを提⽰ → 必要最低限のステップ • チェックポイントでの⼊⼒に変更し、プロセス順不同に対応 • 更にSlackからメンションやJIRA連携 インシデント コマンダーの決定 障害対応 スレッドの作成 インシデント コマンダーの決定 障害対応 スレッドの作成 • インシデントコマンダーを選択 • 障害対応スレッドの入力 インシデントコマンダーへメンション (自動) インシデントコマン ダーへメンション before after
26. Update2. 障害共有定例細分化 26 • 異なるドメイン間の仕様説明に時間がかかっていた ◦ 「棚卸し」「ささげ」などドメイン特有のワードの意味理解、バイ セル特有ルールの説明など • 組織横断をドメインごとに変更 ◦ 買取領域 ◦ 在庫管理‧販売領域 ◦ 共通領域 • ドメインが近しいからこそ、影響範囲のイメージがつきやすくアドバ イスが出やすい
27. • プロフェッショナルな取り組みを紹介 ◦ ユーザーファーストを体現するメンバーの紹介 ▪ ⽬の前の困っている⼈のために、「なんとかしたい」 ◦ 初動を早くするために取り組んでいることを社内で共有 • 重⼤度の⾼いインシデントを紹介 ◦ 開発者全員に詳細説明 ▪ 発⽣原因‧再発防⽌ ▪ その際に協⼒してくれたメンバーの 紹介 ◦ 我々のプロダクトが社内インフラで あることを再認識 その他 ~ テックインサイト(朝礼)での共有~ 27 「初動が大事だよ」を社内で共有
28. • ダッシュボード上、インシデント件数は減少 ◦ 最⼤で６割減 ※リリースによって各⽉変動 • 啓蒙活動 ◦ 開発者にとってインシデントがより⾝近になった • まだまだやるべきことは多い ◦ モチベーション向上へ切り替えられるマインドや⽂化醸成 ◦ 新規メンバー‧プロダクトは増える ▪ インシデントマネジメントは進化し続ける 成果&今後の展望 28
29. 総括 29 • 成⻑企業は組織、事業やプロダクトのフェーズによって求められる 品質が変動する • インシデントマネジメントのアプローチも各フェーズに応じて適応 することが⼤切 ◦ 理想ドリブン ◦ ユーザの声を聞く • ルールや仕組みを⼊れて終わりではない ◦ 発信も続ける
30. 一緒に取り組みをする仲間を募集しています 30 • CTO室のEM（採用、育成、評価制度、開発生産性、DevRel、ブランディング、etc） • インシデントマネジメントに理解あるプロダクトチームのEM、PM、テックリード • 興味ある人は直接話しましょう
31. THANK YOU 31