『誰の責任？』で揉めるのをやめて、エラーバジェットで判断するようにした～感情論をデータで終わらせる、PMとエンジニアの意思決定プロセス～

by coconala_engineer

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright coconala Inc. All Rights Reserved. 自己紹介 2 川崎雄太　Yuta Kawasaki @yuta_k0911 株式会社ココナラ Head of Information Dev Enablingグループ Group Manager 株式会社ココナラテック執行役員情報基盤統括本部長 SRE / 情シス / セキュリティ領域のEM AWS Community Builder（Security）

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright coconala Inc. All Rights Reserved. 責任追求が起きる「3つの欠落」その① 13 客観的に判断できる「データ」がない問題が起きてしまったことは巻き戻せないのに、原因追求の際に感情論と主観で議論が進んでしまう。結果的に「誰が悪い」という犯人探しに焦点が当たりがち。（例）またインシデントが起きたのか → エンジニア品質どうなってるんだ？💢 → いや、不具合を作り込んだ工程は…

Slide 14

Slide 14 text

Copyright coconala Inc. All Rights Reserved. 責任追求が起きる「3つの欠落」その② 14 客観的に判断できる「基準」がない施策のリリースに関するGo / No Goを決める客観的な基準がない。声の大きさと役職が上の人の意見が通る環境になってしまう。あとは過去の経験則。（例）だいたいQA通っているからリリースしていいでしょ → KPIに効くから最速でリリースするわ！ → インシデント発生…

Slide 15

Slide 15 text

Copyright coconala Inc. All Rights Reserved. 責任追求が起きる「3つの欠落」その③ 15 とにかく「心理的安全性」がない「失敗＝個人の責任」となってしまい、失敗を責めてしまう文化が醸成されてしまう。本質的な改善よりも責任逃れが優先されてしまう。「次は気をつけます」という本質的でない終わり方。（例）このコードは誰が書いたんだ？💢 → 失敗を咎められるなら開発したくない…

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Copyright coconala Inc. All Rights Reserved. SLOとプロダクト指標を統合するその① 20 ビジネスKPIを洗い出し、把握するまずは「ビジネスKPIとして何が設定されているか？」を正しく認識するところからスタートする。一般的には大上段のミッション → 事業別 / 組織別のミッションという順番で落とし込まれ、最終的にKPIが設定される。エンジニアもビジネス KPIを意識して行動することが、事業成長に必須。

Slide 21

Slide 21 text

Copyright coconala Inc. All Rights Reserved. SLOとプロダクト指標を統合するその② 21 ビジネスKPIと技術指標の関連性を明確化 PMを巻き込むためにはエンジニアが見ている技術指標をビジネス KPIに置き換えて、会話を成立しやすくする必要がある。翻訳して双方をつなげることが重要。（例）リクエスト成功率やレイテンシー → ユーザーの離脱確率や取引完了率に寄与する、と翻訳してレポートする。

Slide 22

Slide 22 text

Copyright coconala Inc. All Rights Reserved. SLOとプロダクト指標を統合するその③ 22 PMも見る共通ダッシュボードを作る PMとエンジニア同じダッシュボードを見て、会話できる状態を作る。その結果、双方の意思統一や目線合わせがしやすくなる。ダッシュボードはエンジニアの用語はなるべく排除して、ユーザー体験の状態を表現することが好ましい。また、視覚的に判断しやすいことも重要な要素の1つとなる。

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Copyright coconala Inc. All Rights Reserved. エラーバジェットとは何か？の共通認識を取る 27 許容できるリスクをマネジメントエラーバジェットを「技術的な定義」ではなく、「施策を攻めるための予算」として定義する。ユーザーの体験の良し悪しを見定めて、連続で体験悪化 → 離脱、というリスクを鑑みた意思決定を行う。（例）・予算がある＝デリバリーを重視・予算がない＝品質を重視

Slide 28

Slide 28 text

Copyright coconala Inc. All Rights Reserved. エラーバジェットをロードマップに組み込む 28 エラーバジェットをマネジメントする今のユーザー体験の状態をもとに、どれだけリスクを取れるか？＆どれだけリスクを排除できるか？を天秤にかける。 SREの領域はインシデントが起きると一撃でサイトダウンが発生する可能性がある。影響範囲・リスクを正しく認識し、次の一手の優先度設定やローンチタイミングを見定める。事業KPIもユーザー体験も両方大事。

Slide 29

Slide 29 text

Copyright coconala Inc. All Rights Reserved. ポストモーテムを普及させる 29 「失敗＝悪」という文化の脱却事業KPIを毀損すると、「失敗＝悪」となりがち。これを血肉にする文化を醸成する。「失敗はあまりひけらかしたくないもの」という認知を「次に繋げる改善のネタ」へと変換し、失敗から得られた教訓を職種問わず全体にフィードバックする。ポストモーテムのテンプレートを利活用。（原因、影響、対策、再発防止、etc）

Slide 30

Slide 30 text

Copyright coconala Inc. All Rights Reserved. 実例：エラーバジェット運用その① 30 事業戦略を PMとエンジニアの双方で考えるリリース判断を行うために必要な要素を洗い出し、意思決定を行う。（例）・バジェットの残量は？・万が一、失敗した場合の影響範囲は？・事業KPIへの貢献度合いは？総合的に鑑みて、今リリースする or xxxのタイミングでリリースする or ペンディングを判断。

Slide 31

Slide 31 text

Copyright coconala Inc. All Rights Reserved. 実例：エラーバジェット運用その② 31 場合によってはドラスティックな意思決定が必要たとえば・リリース後のインシデントが立て続けに発生している・この四半期は予算を抑えて、利益目標を達成したい・ユーザーの離脱だけは絶対に避けたいという状態であれば、「この施策はローンチを先送りして、リリース順序を入れ替える」という意思決定が可能になる。

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright coconala Inc. All Rights Reserved. 週次レビューの変革 34 共通言語により、 MTGの生産性向上に寄与した有意義なMTGがあまりできていなかったため、以下の変更を行った。・AsIs：進捗確認と詰めがメインだった・ToBe：SLOダッシュボードも見ながら、施策の優先順位を会話できるようになった感覚的な情報ではなく、定量的なデータによる意思決定を行った。結果として、リリース後の手戻りを 25%削減することができた。

Slide 35

Slide 35 text

Copyright coconala Inc. All Rights Reserved. インシデント報告のビジネス翻訳 35 インシデント影響をビジネスインパクトで語るエンジニアとしては「原因の特定」が大事だが、まずは「ビジネスインパクトの明確化」を行うことで MTGの生産性を高めることができた。ビジネスインパクトを見据えて、施策を推進すれば自ずと「エンジニアのビジネス力」も磨かれるのではないか。エンジニアが事業視点で行動するのはとても大事。

Slide 36

Slide 36 text

Copyright coconala Inc. All Rights Reserved. SRE用語 → ビジネス用語の翻訳例 36 こうやって翻訳して比較すると、共通点が見つかるレイヤ SRE用語 PMへ翻訳メトリクス例可用性 SLO / エラーバジェットユーザー体験指標リクエスト成功率変更健全性変更失敗率施策の撤回率方向転換コストキャンセル率再見積もり比率俊敏性リードタイム / MTTR 意思決定リードタイム検知→決定の中央値合意までの回数観測ログ / トレースユーザー行動指標回遊率、LTV

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Copyright coconala Inc. All Rights Reserved. 失敗①：データ至上主義 40 データドリブンで何でもかんでも決めるわけではないデータを見ても、「コト」ではなく「ヒト」に目が向いてしまうことがある。「ヒト」に目が向いた状態だと、今までの責任を探していることとと何ら変わらない。これが最大の失敗とも言える。データはあくまで「判断材料」であり、「裁判官」ではない。最終判断は PMとエンジニアが一緒に行うことが重要。

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Copyright coconala Inc. All Rights Reserved. 明日から使えるテンプレート①： Blamelessポストモーテムテンプレート 44 免責事項を明確にし、必要情報を記録する・インシデントレベル（Sev1〜Sev3）・影響範囲（ユーザー数、損失機会の概算）・発見者・対応者（貢献者として記載）・サマリ（エンジニア用語を使わず、「ユーザーにどのような不利益があったか」を3行で記述）・タイムライン（事実のみ）・根本原因（5 Whys）・再発防止策（Action Items）

Slide 45

Slide 45 text

Copyright coconala Inc. All Rights Reserved. 明日から使えるテンプレート②：エラーバジェット判断フローチャート 45 リリース申請時に以下の観点で判断する・判定①：現在のエラーバジェットは残っているか？　→YES：リリースOK / NO：次へ・判定②：これは「特例事項（セキュリティ、法的要件、コンプライアンス対応、その他最重要案件）」か？　→YES：リリースOK / NO：次へ・判定③：信頼性向上タスクが含まれているか？　→YES：リリースOK / NO：現時点ではリリース凍結

Slide 46

Slide 46 text

Copyright coconala Inc. All Rights Reserved. 明日から使えるテンプレート③： SLOダッシュボード設計ガイド 46 今の状況がひと目でわかることを重要視・SLOとエラーバジェットの状況をひと目で判断できるエリアを設ける。・機能ごとではなく「体験」ごとのSLO達成率を表示。　→ユーザーがエラーに遭遇している確率や状況もモニタリングできるようにする　→クリティカルユーザージャーニーの状況も見れるようにする・「予算が減っていく予測」のグラフ。「このペースだと、あと10日で予算が尽きます」という予測線を表示。

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Copyright coconala Inc. All Rights Reserved. 明日から使えるテンプレート④：技術負債 ROI計算シート 48 「コードを綺麗にしたい」を「投資対効果」に変換・現状の損失コスト（Cost of Inaction）手戻りコスト / 運用トイル / 機会損失（推定） ⇒ 合計 A円 / 年・改善への投資コスト（Cost of Action）リファクタリング工数 / ツール導入費 ⇒ 合計 B円上記から投資回収期間を試算する。リファクタリングはコストではなく、将来の損失を防ぐ投資である。