サービスの信頼性を高めるため、形骸化した「プロダクションミーティング」を立て直すまでの取り組み

https://phpcon.kagawa.jp/2026/ で話した際の発表資料です。
https://fortee.jp/phpconkagawa-2026/proposal/5abdcf0f-3e86-4805-8b2d-93fc80c8073a

1. サービスの信頼性を高めるため、 形骸化した「プロダクションミーティング」を 立て直すまでの取り組み 1 2026/05/09 PHPカンファレンス香川2026 すてにゃん (@stefafafan)
2. 2 SmartBank, Inc. Software Engineer すてにゃん @stefafafan @stefafafan 自己紹介
3. 今日お話すること
4. 4 今日お話すること 1. プロダクションミーティングについて 2. フェーズの変化によって合わなくなったこと 3. プロダクションミーティングの目的を再考 4. 目的に合わせて会議の形を変える 5. 仕組み化して改善サイクルを回す 6. 今後に向けて
5. 会社の状況
7. X
8. 8 会社の状況 • 家計簿アプリ「ワンバンク」 • iOS/Androidアプリ • 口座やカードと連携して家計を管理できる • プリペイドカード「ワンバンクカード」 • いくつかの手段でお金を入金し、実際に決済に使うことができる 提供しているプロダクト
9. 9 会社の状況 • 家計簿アプリが止まると • 家計の状況がわかりづらくなる • プリペイドカードが止まると • 決済に使えなくなる • お金は生活に直結するため、障害は重く扱う サービスの信頼性は大事
10. 1. プロダクションミーティングについて
11. 11 1. プロダクションミーティングについて • オライリーの「SRE サイトリライアビリティエンジニアリング」 という本に登場する • Google社のSRE事例を紹介する本 • システムの状況を確認し、チーム全体が共通認識を持った上で改善 へ導くための定期イベント プロダクションミーティングとは？
12. 12 1. プロダクションミーティングについて • 2週間に1度、30分集まって実施 • SREだけが集まって実施している会と、 サーバーサイドエンジニアが参加する会で分かれている • 私はサーバーサイドエンジニアなので、後者に参加 • 直近のリリース予定や、様々なメトリクスを確認して状況を確認し ていた スマートバンクでのプロダクションミーティング
13. 13 1. プロダクションミーティングについて プロダクションミーティングをもとに性能劣化を発見した事例 https://blog.smartbank.co.jp/entry/2024/12/26/152742
14. 14 1. プロダクションミーティングについて • 司会を持ち回りでやったり、アジェンダに沿ってやってきた • 少しずつ形骸化してきているのでは、と感じるようになった 一方で、ミーティングが合わなくなった部分も出てきている
15. 2. フェーズの変化によって合わなくなったこと
16. 16 2. フェーズの変化によって合わなくなったこと • 2021年からざっくり同じ形式で実施してきた • サーバーサイドエンジニアは5名程度から20名規模へと増加した • プロダクトも成長し、機能やユーザー規模も大きく増えた 会社の変化
17. 17 2. フェーズの変化によって合わなくなったこと • 参加者20人の30分の時間を使い続けるべきか • ※昔60分使っていたが長すぎたため30分に短縮して今に至る • 見るべき項目が増え続けて、議論する時間が限られてしまっている • 20人に対して問いかけて、お見合いになりやすい状況 以前の形が合わなくなってきた
18. 18 2. フェーズの変化によって合わなくなったこと • スマートバンクではエンジニア組織横断の課題を「委員会」という 枠組みで解消している • 今回の「プロダクションミーティング」についても、委員会で解決 を試みることに 「委員会」という形で手を入れることになった
19. 19 2. フェーズの変化によって合わなくなったこと 委員会については以下の記事を参照 https://blog.smartbank.co.jp/entry/2025/07/02/committee-system-introduction
20. 20 2. フェーズの変化によって合わなくなったこと 余談: 以前登壇したCI高速化事例も、委員会で改善を実施しました https://speakerdeck.com/stefafafan/gha-ci-performance-tuning
21. 21 3. プロダクションミーティングの目的を再考
22. 22 3. プロダクションミーティングの目的を再考 • 目的 • 参加者 • 実施頻度 • アジェンダ 参加者・頻度・アジェンダは、目的から逆算して決める 「会議」にはいろいろな構成要素がある
23. 23 3. プロダクションミーティングの目的を再考 1. 原典である “SRE本” を改めて読んでみる 2. 他社の事例を調べる・ヒアリングする 3. 自分たちの状況でどういう風に適用させるとよいかを考える 小手先の改善よりも、あるべき姿を改めて再考を試みる
24. 24 3. プロダクションミーティングの目的を再考 • Chapter 31: Communication and Collaboration in SRE • https://sre.google/sre-book/communication-and- collaboration/ • 目的を簡単にまとめると、 • ステークホルダー等全員が共通認識を持つこと • 設計・実装・監視項目に対するフィードバックループを 作ること 1. 原典である “SRE本” を改めて読んでみる 通称 “SRE本”
25. 25 3. プロダクションミーティングの目的を再考 • Appendix F: Example Production Meeting Minutes • https://sre.google/sre-book/production- meeting/ • 過去の障害や発生したアラートの共有 • 今後の本番環境向けの変更の予定 • TODOを決める 1. 原典である “SRE本” を改めて読んでみる 通称 “SRE本”
26. 26 3. プロダクションミーティングの目的を再考 • Xやはてなブックマークを活用し、他社事例を調査 • ※ 会社によって呼ばれ方が違うので検索する際に工夫が必要 • 株式会社はてな: Performance Working Group (PWG) • 他: エンジニア会、パフォミ、ふみぱお、パフォーマンス確認会 2. 他社の事例を調べる・ヒアリングする
27. 27 3. プロダクションミーティングの目的を再考 • SRE Lounge という SRE に関心のある方があつまるコミュニティ があります • https://sre-lounge.connpass.com/ • SRE Lounge Slack の #ask-anything チャンネルでざっくばらん に聞いてみることにした 2. 他社の事例を調べる・ヒアリングする
28. 28 3. プロダクションミーティングの目的を再考 2. 他社の事例を調べる・ヒアリングする
29. 29 3. プロダクションミーティングの目的を再考 • 他社事例の記事やSlackのやり取りから、以下のような目的を持っ て実施していることがわかった • SREとアプリケーションエンジニアとの接点 • 過去発生した障害やアラートの確認 • 未来に向けてダッシュボード等でリスクの共通認識を作る 2. 他社の事例を調べる・ヒアリングする
30. 30 3. プロダクションミーティングの目的を再考 • 現状の課題感については以下のようなものがありました • アジェンダに沿ってやっていくだけだと作業感が出てしまう • SREとの連携をもっと上手くやりたい • 開催頻度次第では負担が大きい 2. 他社の事例を調べる・ヒアリングする
31. 31 3. プロダクションミーティングの目的を再考 • これまでスマートバンクで設定していた目的 • アラーティングでは捉えきれない、長期的なメトリクスの変動の 種を見つける • 次の2週間で起きることに対して必要な準備がないかを確認する • 準備担当者の発表会ではなく、インタラクティブな発見の場をめ ざす 3. 自分たちの会社での目的を再考する
32. 32 3. プロダクションミーティングの目的を再考 • 長期的なトレンドを意識した目的になっていて良い • インタラクティブな場を目指しているのも良い • しかし、もう少し「プロダクト」や「会社」目線で考えてもいいの ではないか？ 3. 自分たちの会社での目的を再考する
33. 3. プロダクションミーティングの目的を再考 33 • 会社としては、 • ワンバンクをさらに成長させたい • ユーザーを増やしたい • アプリもカードも使ってほしい ということは、プロダクトを急成長させる前提に立つと良さそう 3. 自分たちの会社での目的を再考する
34. 34 3. プロダクションミーティングの目的を再考 • 新しい目的の軸となる方向性: • ワンバンクがスケールした時に耐えうるシステムに する 3. 自分たちの会社での目的を再考する
35. 35 3. プロダクションミーティングの目的を再考 • 詳細として以下のようなポイントも記載 • 長期的なトレンド(成長目標含む)や突発的なイベントに備えた対 策を議論する • これまでの障害を振り返り、全チームで同じようなことが起き ないよう対策をする • システム運用にあたって、無駄なコストを削減する 3. 自分たちの会社での目的を再考する
36. 36 3. プロダクションミーティングの目的を再考 • 結果的には大きく目的は変わっていない • 意識したポイントは会社が目指している方向と揃えること • また、会社として「急成長」が求められているので、 コストも急増してしまわないように観点に明示的に含めた 3. 自分たちの会社での目的を再考する
37. 37 3. プロダクションミーティングの目的を再考 • 大事だと認識した上で、現時点では明示的に含めていない点: • コミュニケーションを促進させる • インフラスキルの学習 • 直近やるべきことをやる、というスピード感を重視 現時点での目的に含まなかったこと
38. 38 4. 目的に合わせて会議の形を変える
39. 39 4. 目的に合わせて会議の形を変える • ADRを作って、意見を募った上で進める • アジェンダと参加者を一旦決めてまず始める • 回を重ねながら意見を受けて改善のサイクルを回す 新しい目的が決まったので、改善を進めていく
40. 40 4. 目的に合わせて会議の形を変える • Architecture Decision Records (ADR) で提案する文化があった • 今回に関しても同様に提案をした 目的と参加者の変更をADRで提案
41. 41 4. 目的に合わせて会議の形を変える • 背景、課題、提案、影響という大きく4つの項目 • 影響のある全員へ展開しつつ、インラインコメントで意見を募集 • →結果として大きな反対意見はなく、進めた 目的と参加者の変更をADRで提案
42. 42 4. 目的に合わせて会議の形を変える
43. 43 4. 目的に合わせて会議の形を変える • 各チームの代表者1名を選定して参加してもらうことにした • 少人数のほうが深い議論を進めやすいという想定 • 代表者には各チームへと話した内容を展開してもらうことを期待 目的と参加者の変更をADRで提案
44. 44 4. 目的に合わせて会議の形を変える • 一定の影響のある変更は合意をとりながら進める • 特に今回は参加者のアップデートもかねていたため • 変更内容はテキストとして残す • ADRは書くべき内容がフォーマット化されているという点以外に 必ずテキストとして決定事項が残るというのがポイント 変更の内容よりも、進め方が大事
45. 45 4. 目的に合わせて会議の形を変える • 目的や参加者はある程度考えた上で決めた • 細かいアジェンダの調整は「やりながら調整」を意識 • やらないうちに完璧に仕上げることは困難 • どちらかというと改善サイクルを回すことが大事 アジェンダは仮決めしてとにかく小さくはじめる
46. 46 5. 仕組み化して改善サイクルを回す
47. 47 5. 仕組み化して改善サイクルを回す • 長期的なトレンドや突発的なイベント確認 • 障害振り返り (with Notion AI) • メトリクス確認 (with 社内AIエージェント) • TODO項目決め • プロダクションミーティング自体の改善項目集め 現時点でのアジェンダ
48. 48 5. 仕組み化して改善サイクルを回す • 長期的なトレンドや突発的なイベント確認 • 障害振り返り (with Notion AI) • メトリクス確認 (with 社内AIエージェント) • TODO項目決め • プロダクションミーティング自体の改善項目集め 現時点でのアジェンダ
49. 49 5. 仕組み化して改善サイクルを回す • 障害報告・ポストモーテムはNotionに書いている • 障害発生時、状況のアップデートはSlackで共有している • Notionが提供している「Notion AI」をSlackに連携しつつ使うこ とで、楽に過去1ヶ月の障害などを振り返ることができる Notion AI で障害振り返り
50. 50 5. 仕組み化して改善サイクルを回す Notion AI で障害振り返り
51. 51 5. 仕組み化して改善サイクルを回す • 社内には「Askワンバン」と呼ばれているAIエージェントが開発・ 運用されている • 使われ方としてはDevinと近いが、様々なデータソースと繋がっ ている点がポイント • PMなどは数字を調べるのに気軽に利用している 社内AIエージェントの紹介
52. 52 5. 仕組み化して改善サイクルを回す 社内AIエージェントの紹介 https://blog.smartbank.co.jp/entry/ask
53. 53 5. 仕組み化して改善サイクルを回す • New Relicを現在入れているものの、ミーティングの準備のために 色々なグラフを見てアジェンダを整えるのが大変 • エージェントを様々なMCPサーバーと接続させた • New Relic MCP • Sentry MCP • プロダクションミーティング専用のプロンプトを用意して使うように メトリクス確認 with 社内AIエージェント
54. 54 5. 仕組み化して改善サイクルを回す • 実際のプロンプトの一部を抜粋: メトリクス確認 with 社内AIエージェント
55. 55 5. 仕組み化して改善サイクルを回す • 自律的にNew Relic、Sentry、ソースコードを確認し 特定期間の異常値をレポート • 注目すべき観点ややったほうが良さそうなTODO項目の提案 • AIエージェントの出力結果をほぼそのままアジェンダに使えて便利 • 準備時間が大幅短縮された エージェントがやってくれたこと
56. 56 5. 仕組み化して改善サイクルを回す • 長期的なトレンドや突発的なイベント確認 • 障害振り返り (with Notion AI) • メトリクス確認 (with 社内AIエージェント) • TODO項目決め • プロダクションミーティング自体の改善項目集め メタ的な改善もアジェンダに含める
57. 57 5. 仕組み化して改善サイクルを回す • パフォーマンスや障害に関するアクション項目を出しがち • 会議の運用そのものを振り返るセクションも追加 • テキストベースで非同期で集める形 非同期でこの会議の運用に関する改善項目を集める
58. 58 5. 仕組み化して改善サイクルを回す プロダクションミーティング参加者の声: 良い点
59. 59 5. 仕組み化して改善サイクルを回す • エージェントのおかげで準備時間を短縮できてよい • 新たな着目点を出してくれてよかった • 障害情報を改めて確認する時間があってよい • 人数を絞った結果より具体的な議論がしやすくなった プロダクションミーティング参加者の声: 良い点
60. 60 5. 仕組み化して改善サイクルを回す • AIエージェントにお任せした際に、評価の観点にブレがある • 毎回ゼロベースでエージェントに分析してもらうというよりは、 前回からの差分などを出して欲しい • TODO項目を積んだ後の運用、アサインをどうするかなどが曖昧 • ミーティングに不参加のメンバーへの伝達方法を考えたい プロダクションミーティング参加者の声: 改善項目
61. 61 5. 仕組み化して改善サイクルを回す • 改善項目が参加者から出てくることが一番の収穫 • ルーティンで作業をして、参加者からコメントがないとつらい プロダクションミーティング参加者の声について思ったこと
62. 62 余談: LLMを前提としたミーティングの未来
63. 63 余談: LLMを前提としたミーティングの未来 • 最近の Agentic Coding は人間の介在なしでループを回す方向性に なっている (と感じる) • LLMがコード書く→LLMがレビュー→LLMが修正を適用→ (以下略) • 例: Devin が Bot によるレビュー指摘を受けて自律的に修正してくれ る autofix 機能 • 例: Long-running Task をLLMに遂行させる様々な試み 最近の Agentic Coding
64. 64 余談: LLMを前提としたミーティングの未来 • 定期的なミーティングについてもLLMに置き換わっていくかも • エージェントが改善項目を自動検知・Issue化し、調査や実装の修 正提案まで出してくれるようになるなど • 人間の介入を減らす方向へ プロダクションミーティングの未来
65. 65 余談: LLMを前提としたミーティングの未来 エラーの一時調査は別のエージェントで改善がまさに進んでいる https://blog.smartbank.co.jp/entry/2026/03/18/110000
66. 66 6. 今後に向けて
67. 67 6. 今後に向けて • 目的・参加者の見直し • アジェンダを会議自体を見直せる形に調整 • 会議の準備をLLMを使って効率化 今回実施したこと
68. 68 6. 今後に向けて • 意図的に司会を委員会メンバー2名に固定して続けていて、 手離れできていない • LLMで効率化できているとはいえ、でてきたアクションアイテムを うまくハンドリングできていない まだまだ完璧な状態ではない
69. 69 6. 今後に向けて • 「ワンバンクがスケールした時に耐えうるシステムにする」という 目的を道標として進めていくのを大事に • 会議をやりながら定期的に振り返って、フィードバックループを回 すことさえできれば、人間であろうが、AIであろうが関係ない 時代の変化はどうあれ、目的は変わらず