不具合対応の属人化解消 泥臭イノベーション 〜AIで人は動かせない〜

Transcript

1. 不具合対応の属人化解消 泥臭イノベーション LIGHTNING TALK 〜AIで人は動かせない〜 墨 勇汰 / @sumiVer2
2. 自己紹介 名前 墨 勇汰 所属 株式会社YOUTRUST / SRE 経歴 開発 → インフラ（オンプレ） → インフラ（クラウド）→ SRE 2年目 今日 人生初登壇です @sumiVer2 墨 勇汰 @sumiVer2 2 / 11
3. 不具合対応、 属人化していませんか？ QUESTION 弊社では、社歴の長い人やシニアなエンジニアが中心に対応し、 ジュニアなエンジニアが入れていなかった いつもありがとうございます 不具合対応は一番の成長機会。 ジュニアも入れば、ミドル・シニアが違う仕事に時間を割ける → いい循環 @sumiVer2 3 / 11
4. 前提 01 今日話す「不具合対応」 ユーザーや社内からSlackに 上がった不具合報告の解消 アプリケーション監視などは、今回は含まない @sumiVer2 02 弊社の AI の現在地 AIの一次調査に判断・責任を 持つのは、まだ人 テレメトリーデータがコストの都合で分散し、 紐付けもできていないため、AIの出力も 安定しない 4 / 11
5. 不具合に責任を持つチームをつくる APPROACH 01 Before 不具合に責任を持つチームが なかった 2 新機能開発に重きが置かれがち 1 @sumiVer2 After 1 ▶ 2 2026年4月、SRE UnitとQA Unitが合体し 品質Unit 爆誕 KPI：不具合にポイントを振り、 それを下げる 5 / 11
6. 不具合をデータベース化する APPROACH 02 不具合を管理できておらず、ステータスや対応率を追ったり、振り返りができる状態ではなかった ※ 重大なインシデントは、ポストモーテムを作成していた STEP 01 STEP 02 STEP 03 STEP 04 n8nでNotionの 不具合DBに登録 ステータスを見える 化し、対応漏れを 減らす 仕様作成・開発・ レビュー・QAの どこで防げたか PdM・エンジニアに 集める @sumiVer2 追う 振り返る 展開する 共有 6 / 11
7. 対応フローを整える APPROACH 03 Before After ユニットリーダーが一次受け 2 開発したメンバーや、手が 空いているメンバーに振る 3 振られた人が、調査・改修・ 報告まで責任を持つ 4 難しければ、自分でヘルプを出す 1 報告が上がると、全員がワーっと 群がる 2 見られる人が見る 1 @sumiVer2 ▶ 7 / 11
8. リマインドは、あえてAI・自動化しない APPROACH 04 対応漏れはゼロにならない。それは許容し、最後の責任は品質Unitで持つ 1 2 3 オオカミ少年化する 忙しさや気持ちを 加味できない 議論が生まれにくい Botのリマインドは スルーされ、優先度が下がる @sumiVer2 同じ人に集中していたら 明日にする、ができない 別の人へ移すなどの提案が できない 8 / 11
9. 最近の状況 不具合対応の担当者 不具合ポイント アプリエンジニアから、自発的に 入社1.5年未満のメンバーが対応し、 不具合チケットのクローズ率も向上 2026年4月（品質Unit発足）→ 8月 「不具合点がまたちょっと 増えちゃったから、…最近の アプリ系バグ振り返りしますか？ 防ぐ方法考えよう」 約70%が若手 39 → 20 振り返りの提案 70% もちろん、QAの体制強化やE2Eテストの充足があってこそ！ @sumiVer2 9 / 11
10. まだまだなところ まだまだ これから 明文化できていない 2 オンボーディングに 入れられていない オブザーバビリティ施策を進める 2 SRE AIエージェントで一次調査 3 一次受けやフローも自動化し、 新しく入った人でも回るように 1 @sumiVer2 1 ▶ 10 / 11
11. まとめ SUMMARY ✓ 責任を持つ場所をつくる 品質UnitとKPIで、不具合をチームの責任にする ✓ 仕組みで、誰でも入りやすくする 不具合DBと対応フローで、漏れを減らし自分事にする ✓ 人を動かすのは、まだ人 リマインドは、相手の状況を見ながら人がやる AI時代だからこそ、当たり前を当たり前に、地道に。 @sumiVer2 11 / 11