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

Developers Summit 2026 Day1の登壇資料です。
https://event.shoeisha.jp/devsumi/20260218/session/6431

Transcript

1. Copyright coconala Inc. All Rights Reserved. 『誰の責任？』で揉めるのをやめて、エラーバ ジェットで判断するようにした 〜感情論をデータで終わらせる、 PMとエンジニアの 意思決定プロセス〜 株式会社ココナラ 川崎 雄太 2026/02/18 Developers Summit 2026
2. Copyright coconala Inc. All Rights Reserved. 自己紹介 2 川崎 雄太　Yuta Kawasaki @yuta_k0911 株式会社ココナラ Head of Information Dev Enablingグループ Group Manager 株式会社ココナラテック 執行役員 情報基盤統括本部長 SRE / 情シス / セキュリティ領域のEM AWS Community Builder（Security）
3. Copyright coconala Inc. All Rights Reserved. ⚠はじめに⚠ このセッションで話すこと󰢏 • SREの領域からプロダクト開発にリーチした 取り組みや学び（失敗もあるよ） このセッションで話さないこと󰢃 • SRE以外の領域からプロダクト開発にリーチ した取り組みや学び 3
4. Copyright coconala Inc. All Rights Reserved. まずは前提のすり合わせです！ 僕はEM / グループ会社の執行役員 / 技術広報のマネージャーという ロールを担っています。 今回はEM（SRE領域）のお話です。 4
5. Copyright coconala Inc. All Rights Reserved. SREのEMが事業貢献を最大限に考えて PMと合意形成する際に試行錯誤した 事例をお話します。 このセッションが少しでもなにかの お役に立ちますように！ 😁 5
6. Copyright coconala Inc. All Rights Reserved. 6 Agenda なぜ「誰の責任？」論争が起きるのか 実践①：SLOとプロダクト指標の統合 実践②：エラーバジェットで意思決定する 実践③：共通言語で会話する仕組み 失敗から学んだ3つの教訓 2 1 5 3 4
7. Copyright coconala Inc. All Rights Reserved. なぜ「誰の責任？」論争が起きるのか Chapter 01 7
8. Copyright coconala Inc. All Rights Reserved. いきなりですが、こういうことって ありませんか？ 8
9. Copyright coconala Inc. All Rights Reserved. 再現ドラマ風シーン① 9 PM：この障害で売り上げが300万円毀損しました。誰の責任ですか？ SRE：インフラは問題ありませんでした。 開発：コードレビューは通っています。 QA：テストシナリオに含まれていませんね。 上記議論で時間が経過し、犯人探しで終了。 本質的な改善につながらず…😭
10. Copyright coconala Inc. All Rights Reserved. 再現ドラマ風シーン② 10 PM：期限が迫っています。今週リリースしましょう。 SRE：まだ負荷試験が終わっていません。 PM：でも、前回大丈夫でしたよね？ 開発：いや、前回障害でましたけど… 感情論と政治的判断が入り混じる…😭 PM：売上目標があるので、リリースしましょう。
11. Copyright coconala Inc. All Rights Reserved. 再現ドラマ風シーン③ 11 開発：この技術負債を解消しないと、いずれ大障害が起きます。 PM：でも、それって売上につながりますか？ 開発：…つながりませんね。 PM：では、優先度は低めで設定します。 数カ月後に大障害発生… 事前に対応しなかったのは誰の責任？😭
12. Copyright coconala Inc. All Rights Reserved. まずは「なぜ責任追求が起きるのか？」を 少し言語化してみます。 12
13. Copyright coconala Inc. All Rights Reserved. 責任追求が起きる「3つの欠落」その① 13 客観的に判断できる「データ」がない 問題が起きてしまったことは巻き戻せないの に、原因追求の際に感情論と主観で議 論が進んでしまう。 結果的に「誰が悪い」という犯人探しに焦点が 当たりがち。 （例） またインシデントが起きたのか → エンジニア 品質どうなってるんだ？💢 → いや、不具合を 作り込んだ工程は…
14. Copyright coconala Inc. All Rights Reserved. 責任追求が起きる「3つの欠落」その② 14 客観的に判断できる「基準」がない 施策のリリースに関するGo / No Goを決め る客観的な基準がない。 声の大きさと役職が上の人の意見が通る環境 になってしまう。あとは過去の経験則。 （例） だいたいQA通っているからリリースしていい でしょ → KPIに効くから最速でリリースする わ！ → インシデント発生…
15. Copyright coconala Inc. All Rights Reserved. 責任追求が起きる「3つの欠落」その③ 15 とにかく「心理的安全性」がない 「失敗 ＝ 個人の責任」となってしまい、失敗 を責めてしまう文化が醸成されてしまう。 本質的な改善よりも責任逃れが優先されてし まう。「次は気をつけます」という本質的でない 終わり方。 （例） このコードは誰が書いたんだ？💢 → 失敗を 咎められるなら開発したくない…
16. Copyright coconala Inc. All Rights Reserved. ここまで極端な例はそこまで 多くないかもしれません。 ただ、「ありえそうだな…」という 感覚を持つ方もいますよね？ 16
17. Copyright coconala Inc. All Rights Reserved. こういう状況では以下が起こりうります。 ・チーム間の信頼が失われる ・PMとエンジニアが対立する ・防御的な行動が増える（責任回避） ・イノベーションが生まれない ・優秀な人材が離脱する 17
18. Copyright coconala Inc. All Rights Reserved. この負の状況を断ち切るのが「SLO」と「エ ラーバジェット」 です💪 単なる監視ツールとしてではなく、 「共通言語」 として導入しました！ 18
19. Copyright coconala Inc. All Rights Reserved. 実践①：SLOとプロダクト指標の統合 Chapter 02 19
20. Copyright coconala Inc. All Rights Reserved. SLOとプロダクト指標を統合する その① 20 ビジネスKPIを洗い出し、把握する まずは「ビジネスKPIとして何が設定されてい るか？」を正しく認識するところからスタートす る。 一般的には大上段のミッション → 事業別 / 組 織別のミッションという順番で落とし込まれ、最 終的にKPIが設定される。 エンジニアもビジネス KPIを意識して行 動することが、事業成長に必須。
21. Copyright coconala Inc. All Rights Reserved. SLOとプロダクト指標を統合する その② 21 ビジネスKPIと技術指標の関連性を明確化 PMを巻き込むためにはエンジニアが見て いる技術指標をビジネス KPIに置き換え て、会話を成立しやすくする必要がある。 翻訳して双方をつなげることが重要。 （例） リクエスト成功率やレイテンシー → ユーザー の離脱確率や取引完了率に寄与する、と翻訳 してレポートする。
22. Copyright coconala Inc. All Rights Reserved. SLOとプロダクト指標を統合する その③ 22 PMも見る共通ダッシュボードを作る PMとエンジニア同じダッシュボードを見て、会 話できる状態を作る。 その結果、双方の意思統一や目線合わせが しやすくなる。 ダッシュボードはエンジニアの用語はなる べく排除して、ユーザー体験の状態を表 現することが好ましい。 また、視覚的に判断しやすいことも重要な要 素の1つとなる。
23. Copyright coconala Inc. All Rights Reserved. ダッシュボードの実例：リクエスト成功率 23
24. Copyright coconala Inc. All Rights Reserved. ダッシュボードを共通で見ることで、 ・PMのダッシュボード確認頻度： 5倍 ・プロダクト意思決定のデータ根拠率 ：+30% を実現することができました！🎉 ※導入後3ヶ月の比較値です 24
25. Copyright coconala Inc. All Rights Reserved. 実践②：エラーバジェットで意思決定する Chapter 03 25
26. Copyright coconala Inc. All Rights Reserved. 改善のステップは「対話」と 「試行錯誤」の繰り返しでした💦 「失敗 ＝ 悪と切り捨てる」 状況に 対し、どうすれば良くなるか？を 説明することで少しずつ改善しました。 26
27. Copyright coconala Inc. All Rights Reserved. エラーバジェットとは何か？の共通認識を取る 27 許容できるリスクをマネジメント エラーバジェットを「技術的な定義」ではなく、 「施策を攻めるための予算」として定義 する。 ユーザーの体験の良し悪しを見定めて、連続 で体験悪化 → 離脱、というリスクを鑑みた意 思決定を行う。 （例） ・予算がある ＝ デリバリーを重視 ・予算がない ＝ 品質を重視
28. Copyright coconala Inc. All Rights Reserved. エラーバジェットをロードマップに組み込む 28 エラーバジェットをマネジメントする 今のユーザー体験の状態をもとに、どれだけ リスクを取れるか？＆どれだけリスクを 排除できるか？を天秤にかける。 SREの領域はインシデントが起きると一撃で サイトダウンが発生する可能性がある。 影響範囲・リスクを正しく認識し、次の一手の 優先度設定やローンチタイミングを見定める。 事業KPIもユーザー体験も両方大事。
29. Copyright coconala Inc. All Rights Reserved. ポストモーテムを普及させる 29 「失敗 ＝ 悪」という文化の脱却 事業KPIを毀損すると、「失敗 ＝ 悪」とな りがち。これを血肉にする文化を醸成す る。 「失敗はあまりひけらかしたくないもの」という 認知を「次に繋げる改善のネタ」へと変換し、 失敗から得られた教訓を職種問わず全体に フィードバックする。 ポストモーテムのテンプレートを利活用。（原 因、影響、対策、再発防止、etc）
30. Copyright coconala Inc. All Rights Reserved. 実例：エラーバジェット運用 その① 30 事業戦略を PMとエンジニアの双方で考える リリース判断を行うために必要な要素を 洗い出し、意思決定を行う。 （例） ・バジェットの残量は？ ・万が一、失敗した場合の影響範囲は？ ・事業KPIへの貢献度合いは？ 総合的に鑑みて、今リリースする or xxxのタイ ミングでリリースする or ペンディングを判断。
31. Copyright coconala Inc. All Rights Reserved. 実例：エラーバジェット運用 その② 31 場合によってはドラスティックな意思決定が必要 たとえば ・リリース後のインシデントが立て続けに発生 している ・この四半期は予算を抑えて、利益目標を達 成したい ・ユーザーの離脱だけは絶対に避けたい という状態であれば、「この施策はローンチ を先送りして、リリース順序を入れ替え る」という意思決定が可能になる。
32. Copyright coconala Inc. All Rights Reserved. 実際には、愚直にPDCAサイクルを 回すだけです！ エラーバジェットの導入により、 ・「誰の責任？」という議論：ほぼ撲滅 ・PMとエンジニアの対立：データを用いて 回避 を実現することができました！🎉 ※導入後3ヶ月での比較値です 32
33. Copyright coconala Inc. All Rights Reserved. 実践③：共通言語で会話する仕組み Chapter 04 33
34. Copyright coconala Inc. All Rights Reserved. 週次レビューの変革 34 共通言語により、 MTGの生産性向上に寄与した 有意義なMTGがあまりできていなかったた め、以下の変更を行った。 ・AsIs：進捗確認と詰めがメインだった ・ToBe：SLOダッシュボードも見ながら、施策 の優先順位を会話できるようになった 感覚的な情報ではなく、定量的なデータに よる意思決定を行った。 結果として、リリース後の手戻りを 25%削 減することができた。
35. Copyright coconala Inc. All Rights Reserved. インシデント報告のビジネス翻訳 35 インシデント影響をビジネスインパクトで語る エンジニアとしては「原因の特定」が大事だ が、まずは「ビジネスインパクトの明確化」 を行うことで MTGの生産性を高めること ができた。 ビジネスインパクトを見据えて、施策を推進す れば自ずと「エンジニアのビジネス力」も 磨かれるのではないか。 エンジニアが事業視点で行動するのはとても 大事。
36. Copyright coconala Inc. All Rights Reserved. SRE用語 → ビジネス用語の翻訳例 36 こうやって翻訳して比較すると、共通点が見つかる レイヤ SRE用語 PMへ翻訳 メトリクス例 可用性 SLO / エラーバジェッ ト ユーザー体験指標 リクエスト成功率 変更健 全性 変更失敗率 施策の撤回率 方向転換コスト キャンセル率 再見積もり比率 俊敏性 リードタイム / MTTR 意思決定リードタイ ム 検知→決定の中央値 合意までの回数 観測 ログ / トレース ユーザー行動指標 回遊率、LTV
37. Copyright coconala Inc. All Rights Reserved. これらの取り組みにより、 エラーバジェットで判断する スキームの構築ができました！🎉 37
38. Copyright coconala Inc. All Rights Reserved. 失敗から学んだ 3つの教訓 Chapter 05 38
39. Copyright coconala Inc. All Rights Reserved. 大前提として、順風満帆な取り組み ではありませんでした😭 僕の失敗事例をもとに改善を目指して いる方へメッセージさせてください✉ 39
40. Copyright coconala Inc. All Rights Reserved. 失敗①：データ至上主義 40 データドリブンで何でもかんでも決めるわけではない データを見ても、「コト」ではなく「ヒト」に目が向 いてしまうことがある。 「ヒト」に目が向いた状態だと、今までの責任を 探していることとと何ら変わらない。これが最 大の失敗とも言える。 データはあくまで「判断材料」であり、「裁判官」 ではない。 最終判断は PMとエンジニアが一緒に行 うことが重要。
41. Copyright coconala Inc. All Rights Reserved. 失敗②：1人で変えようとした 41 共感者を見つけることが最優先 SREチームだけで導入しようと試行錯誤した が、ちょっと浮いていた。 最初は試行錯誤になるので、小さな成功を共 有するして仲間を増やしていく。 PMを良い意味での共犯者（仲間） にする ことが最優先。 PMと一緒に作ることで当事者意識が生まれ る。
42. Copyright coconala Inc. All Rights Reserved. 失敗③：完璧を求めすぎた 42 指標を追うことに疲弊した データドリブン ＝ 指標が多い方が好ましい、 というわけではない。 最初から見るべき指標が多いと疲弊してしま う。 マジックナンバー ＝ 3ぐらいがちょうど良 いかも。小さく始めて、あとからスケール させる方が確実に成功体験を積むことが できる。
43. Copyright coconala Inc. All Rights Reserved. 3つの失敗に共通すること、 それは「技術の問題」 ではなく、 「人と組織の問題」 でした。 43
44. Copyright coconala Inc. All Rights Reserved. 明日から使えるテンプレート①： Blamelessポストモーテムテンプレート 44 免責事項を明確にし、必要情報を記録する ・インシデントレベル（Sev1〜Sev3） ・影響範囲（ユーザー数、損失機会の概算） ・発見者・対応者（貢献者として記載） ・サマリ（エンジニア用語を使わず、「ユーザー にどのような不利益があったか」を3行で記述） ・タイムライン（事実のみ） ・根本原因（5 Whys） ・再発防止策（Action Items）
45. Copyright coconala Inc. All Rights Reserved. 明日から使えるテンプレート②：エラーバジェット判断フローチャート 45 リリース申請時に以下の観点で判断する ・判定①：現在のエラーバジェットは残っている か？ 　→YES： リリースOK / NO： 次へ ・判定②：これは「特例事項（セキュリティ、法 的要件、コンプライアンス対応、その他最重要 案件）」か？ 　→YES： リリースOK / NO： 次へ ・判定③：信頼性向上タスクが含まれている か？ 　→YES： リリースOK / NO：現時点ではリ リース凍結
46. Copyright coconala Inc. All Rights Reserved. 明日から使えるテンプレート③： SLOダッシュボード設計ガイド 46 今の状況がひと目でわかることを重要視 ・SLOとエラーバジェットの状況をひと目で判 断できるエリアを設ける。 ・機能ごとではなく「体験」ごとのSLO達成率を 表示。 　→ユーザーがエラーに遭遇している確率や 状況もモニタリングできるようにする 　→クリティカルユーザージャーニーの状況も 見れるようにする ・「予算が減っていく予測」のグラフ。「このペー スだと、あと10日で予算が尽きます」という予 測線を表示。
47. Copyright coconala Inc. All Rights Reserved. 47
48. Copyright coconala Inc. All Rights Reserved. 明日から使えるテンプレート④：技術負債 ROI計算シート 48 「コードを綺麗にしたい」を「投資対効果」に変換 ・現状の損失コスト（Cost of Inaction） 手戻りコスト / 運用トイル / 機会損失（推定） ⇒ 合計 A円 / 年 ・改善への投資コスト（Cost of Action） リファクタリング工数 / ツール導入費 ⇒ 合計 B円 上記から投資回収期間を試算する。リファクタ リングはコストではなく、将来の損失を防 ぐ投資である。
49. Copyright coconala Inc. All Rights Reserved. まとめ 49 完璧を求めすぎず、失敗しながらチューニングする 以下の3点を正しく認識し、行動を徹底するこ とが重要と気づいた。 1. 責任追求を止めて、データ（エラーバ ジェット）を共通言語にする。 2. PMとエンジニアは対立する関係では なく、同じデータを見るパートナー。 3. 上記を前提に「コト」にあたる。
50. Copyright coconala Inc. All Rights Reserved. 「誰の責任？」という言葉を できる限り、組織から無くす 取り組みを実施中です！ 類似事例がありましたら、 ぜひ情報交換させてください！😁 Change the Culture, with Data. 50
51. Fin