[2026-09-30]ロックンロールは鳴り止まないっ - 信頼性かまってちゃん - 「データ駆動を投げ捨ててまで。」追いかける信頼性改善に向けた取り組みの話

小売Night 〜止められない現場を支える信頼性エンジニアリング〜
スポンサーセッション登壇
https://moneyforward.connpass.com/event/402864/

Transcript

1. ロックンロールは鳴り止まないっ - 信頼性かまってちゃん 「データ駆動を投げ捨ててまで。」追いかける 信頼性改善に向けた取り組みの話 2026年9月30日（水） 小売Night @tosite / 手島 尚人 〜止められない現場を支える信頼性エンジニアリング〜 マネーフォワード 福岡開発拠点
2. はじめまして
3. 神聖かまってちゃん 昔たまに聞いてました
4. はじめまして 株式会社マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループ リーダー 兼 エンジニアリング戦略室 エンジニアエンゲージメントグループ Fukuoka TechPR（技術広報） 手島 尚人 ／ tosite
5. はじめまして 趣味 キャンプ・登山・旅行・ ドライブ・車中泊・料理・ サウナ・温泉・かっちゃん
6. はじめまして 趣味 キャンプ・登山・旅行・ ドライブ・車中泊・料理・ サウナ・温泉・かっちゃん
7. はじめまして 副業でダイニングバーの 趣味 キャンプ・登山・旅行・ シェフ的なことも ドライブ・車中泊・料理・ サウナ・温泉・かっちゃん やったりしています
8. 閑話休題
9. はじめまして 株式会社マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループ リーダー 兼 エンジニアリング戦略室 エンジニアエンゲージメントグループ Fukuoka TechPR（技術広報） 手島 尚人 ／ tosite
10. はじめまして 株式会社マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループ リーダー 兼 エンジニアリング戦略室 エンジニアエンゲージメントグループ Fukuoka TechPR（技術広報） 手島 尚人 ／ tosite
11. って何？
12. 端的に言うと 保守運用エンジニア 今風に言うとCREです
13. Guardianグループって何？ 攻めと守りの運用の定義 🛡守りの運用 問い合わせ・インシデント対応などの 「当たり前品質」を守るための対応 ⚔攻めの運用 運用改善やプロダクトの価値向上に つながる、将来お客様や運用を楽に するための改善 最高速で守りの運用を対応し 空いた時間で機能改善を行う！ NEXT CREへ 横断組織化？ ・CREとして「正しく守る」ためには SREのマインドが必要だと気づく ・事前検知を強化して先回りして 対応したい ・そのための検知する体制を攻めの 運用で構築していきたい ・CSと連携して顧客要望を収集、 PdMと連携して改善策を議論する ・QAと連携してテスト自動化などの 品質を高める活動を推進する ・SREと連携してSWEの観点から アプリケーションの監視を行う ・開発者のコストを下げるべく CI/CDの整備を行う etc... 「守って攻める」から 「守りながら攻める」へ！ 改善と予防を広げていく 組織へと進化中！
14. Guardianグループって何？ 攻めと守りの運用の定義 🛡守りの運用 問い合わせ・インシデント対応などの 「当たり前品質」を守るための対応 ⚔攻めの運用 運用改善やプロダクトの価値向上に つながる、将来お客様や運用を楽に するための改善 最高速で守りの運用を対応し 空いた時間で機能改善を行う！ NEXT CREへ Guardianとして生まれ変わっ た俺は攻めと守りの運用で無 双する 〜守りの天才が考え る、攻めの運用術〜で登壇し ・CREとして「正しく守る」ためには ました！ SREのマインドが必要だと気づく ・事前検知を強化して先回りして 対応したい ・そのための検知する体制を攻めの 運用で構築していきたい 「守って攻める」から 「守りながら攻める」へ！ 横断組織化？ ・CSと連携して顧客要望を収集、 PdMと連携して改善策を議論する ・QAと連携してテスト自動化などの 品質を高める活動を推進する ・SREと連携してSWEの観点から アプリケーションの監視を行う ・開発者のコストを下げるべく CI/CDの整備を行う etc... 改善と予防を広げていく 組織へと進化中！
15. Guardianグループって何？ 攻めと守りの運用の定義 🛡守りの運用 問い合わせ・インシデント対応などの 「当たり前品質」を守るための対応 ⚔攻めの運用 運用改善やプロダクトの価値向上に つながる、将来お客様や運用を楽に するための改善 最高速で守りの運用を対応し 空いた時間で機能改善を行う！ NEXT CREへ ・CREとして「正しく守る」ためには SREのマインドが必要だと気づく ・事前検知を強化して先回りして 対応したい ・そのための検知する体制を攻めの 運用で構築していきたい 「守って攻める」から 「守りながら攻める」へ！ 横断組織化？ SREは誰のもの？運用エンジ ニアが始める 「SRE領域への 越境」とチームの進化の軌跡 〜Road to NEXT CREで登壇 ・CSと連携して顧客要望を収集、 PdMと連携して改善策を議論する しました！ ・QAと連携してテスト自動化などの 品質を高める活動を推進する ・SREと連携してSWEの観点から アプリケーションの監視を行う ・開発者のコストを下げるべく CI/CDの整備を行う etc... 改善と予防を広げていく 組織へと進化中！
16. Guardianグループって何？ 01 02 03 04 対応 効率化 改善 検知・監視 起きた事象に対する 対応、調査。 問い合わせや運用業務の 工数削減。 プロダクトの改善、 問い合わせ起因のバグ修正。 システムの監視や エラー検知。 例: 問い合わせ対応、 インシデント対応、 エラー対応など 例: 運用自動化、 問い合わせフロー構築、 顧客管理ツール機能開発など 例: プロダクトの改善、 バグ修正、 検知したエラーの修正、 速度改善 など 例: モニタリング ダッシュボード作成、 エラー監視ツール運用、 問い合わせ分類など
17. Guardianグループって何？ 01 02 対応 03 効率化 04 改善 ここはCRE組織にとっての「義務」であり コア機能に当たる部分です 必須の業務ではありますが、これだけだと 「保守」止まりになってしまいます 検知・監視
18. Guardianグループって何？ 01 02 対応 03 効率化 04 改善 ここはCREの手腕の見せ所です 定型作業を削減し、効率化することで 改善活動に時間を使えるようになります 検知・監視
19. Guardianグループって何？ 01 02 対応 03 効率化 04 改善 検知・監視 顧客に近い立場にいるCREだからこそできる 「お客様に価値を届けるためのプロダクト改善」に当たる部分です 例えばUI/UXの改善やアラートメッセージの修正であったり パフォーマンス改善なども手掛けています
20. Guardianグループって何？ 01 02 対応 03 効率化 04 改善 「対応が発生する前に先回りする」ために必要なものです モニタリングツールのダッシュボード画面や アラート監視ツールなどで 日々モニタリングを行っています 検知・監視
21. 最近のGuardian
22. Guardianグループって何？ 01 02 対応 03 効率化 04 改善 ②④の改善が進むことで ①に必要な時間を削減することができ 少しだけ自由な時間が増えました 検知・監視
23. Guardianグループって何？ 01 02 対応 03 効率化 04 改善 こちらについては過去の登壇資料で 色々お話ししているので 詳しくはそちらをご覧ください！ 検知・監視
24. Guardianグループって何？ 01 02 対応 03 効率化 04 改善 今日はこの部分に絞って お話をしようと思います 検知・監視
25. 【序】 信頼性を積み重ねる… その前に
26. 【序】信頼性を積み重ねる…その前に お客様の目に触れる部分の改善を 積み重ねることで信頼性も 一緒に高めていこうという話
27. とは言ったものの どうすればいいの？
28. 如何にAI時代と言えど 全てを殴りにいくのは 無謀がすぎる
29. そこでまずは
30. 【序】信頼性を積み重ねる…その前に CREのレベルについて 考えてみました
31. 引 我々にとっての「理想のCRE」とは 用 資 料 Lv4 Lv3 Lv2 大規模改善 検知・監視 小規模改善 Lv1 トイル削減・効率化 問い合わせ対応 引用: SREは誰のもの？運用エンジニアが始める「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE p31 Money Forward, Inc. 31
32. 引 我々にとっての「理想のCRE」とは 用 資 料 現在のGuardianグループは この位置にいる Lv4 Lv3 Lv2 大規模改善 検知・監視 小規模改善 Lv1 トイル削減・効率化 問い合わせ対応 引用: SREは誰のもの？運用エンジニアが始める「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE p31 Money Forward, Inc. 32
33. 引 我々にとっての「理想のCRE」とは 用 資 料 Lv4 Lv3 まずはどんなことよりも Lv2 問い合わせを捌きつつ 改善に使える時間を 確保することが最優先 大規模改善 検知・監視 小規模改善 Lv1 トイル削減・効率化 問い合わせ対応 引用: SREは誰のもの？運用エンジニアが始める「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE p31 Money Forward, Inc. 33
34. 引 我々にとっての「理想のCRE」とは 用 資 料 その後、浮いた時間で 小さな改善を 徐々に進めていくことが できるようになる Lv4 Lv3 Lv2 大規模改善 検知・監視 小規模改善 Lv1 トイル削減・効率化 問い合わせ対応 引用: SREは誰のもの？運用エンジニアが始める「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE p31 Money Forward, Inc. 34
35. 引 我々にとっての「理想のCRE」とは 用 資 料 問い合わせ起因による 不具合修正などは 優先度を上げて 取り組むのもGood Lv4 Lv3 Lv2 大規模改善 検知・監視 小規模改善 Lv1 トイル削減・効率化 問い合わせ対応 引用: SREは誰のもの？運用エンジニアが始める「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE p31 Money Forward, Inc. 35
36. 引 我々にとっての「理想のCRE」とは 用 資 料 最終段階でロードマップ的な タスクを切って長期的に 取り組んでいけるといいね Lv4 Lv3 Lv2 大規模改善 検知・監視 小規模改善 Lv1 トイル削減・効率化 問い合わせ対応 引用: SREは誰のもの？運用エンジニアが始める「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE p31 Money Forward, Inc. 36
37. その後に
38. 【序】信頼性を積み重ねる…その前に CREの業務に対して Tierという概念を導入してみました
39. 【序】信頼性を積み重ねる…その前に 守りの運用 Tier 0 障害対応 Tier 1 問い合わせ対応・Rollbarエラー・ 月初処理などの定型業務 Tier 2 問い合わせ起因の不具合対応 Tier 3 ライブラリアップデート 攻めの運用 - ビジネス優先度の高い差し込み案件 - 大規模改善・小規模改善・ 改善に向けた調査タスク・その他タスク
40. 【序】信頼性を積み重ねる…その前に 守りの運用 Tier0は何を差し置いてでも 即時対応が必要なタスク Tier 0 障害対応 Tier 1 問い合わせ対応・Rollbarエラー・ 月初処理などの定型業務 Tier 2 問い合わせ起因の不具合対応 Tier 3 ライブラリアップデート 攻めの運用 - ビジネス優先度の高い差し込み案件 - 大規模改善・小規模改善・ 改善に向けた調査タスク・その他タスク
41. 【序】信頼性を積み重ねる…その前に 守りの運用 Tier 0 Tier1はTier0よりは期限は 障害対応 Tier 1 問い合わせ対応・Rollbarエラー・ 月初処理などの定型業務 Tier 2 問い合わせ起因の不具合対応 Tier 3 ライブラリアップデート 長いがトリアージは優先して 行うべきタスク 攻めの運用 - ビジネス優先度の高い差し込み案件 - 大規模改善・小規模改善・ 改善に向けた調査タスク・その他タスク
42. 【序】信頼性を積み重ねる…その前に 守りの運用 Tier 0 障害対応 Tier 1 問い合わせ対応・Rollbarエラー・ Tier2は空いた時間で優先的に 月初処理などの定型業務 攻めの運用 - ビジネス優先度の高い差し込み案件 行うべきタスク Tier 2 問い合わせ起因の不具合対応 Tier 3 ライブラリアップデート - 大規模改善・小規模改善・ 改善に向けた調査タスク・その他タスク
43. 【序】信頼性を積み重ねる…その前に 守りの運用 Tier 0 障害対応 Tier 1 問い合わせ対応・Rollbarエラー・ 月初処理などの定型業務 Tier 2 問い合わせ起因の不具合対応 Tier3は手が空いているときに 攻めの運用 - ビジネス優先度の高い差し込み案件 - 着手するタスク Tier 3 ライブラリアップデート 大規模改善・小規模改善・ 改善に向けた調査タスク・その他タスク
44. 【序】信頼性を積み重ねる…その前に これによってタスクに対する優先度が明確になり 迷うことなくメンバー各々の裁量で 改善が進められるようになりました
45. ここまでまとめ ・GuardianグループはCREとしての 成熟度をLv1〜Lv4まで定義した ・現在のGuardianグループは Lv4のところにいる ・さらにタスクにTierという概念を 導入して着手順を定義した
46. 【破】 何を改善する？ どう改善する？
47. 【破】何を改善する？どう改善する？ これによってタスクに対する優先度が明確になり 迷うことなくメンバー各々の裁量で 改善が進められるようになりました
48. が
49. 【破】何を改善する？どう改善する？ 何を改善すればいい？ は依然よくわかっていません
50. そこで「何を」 改善するべきかを 分類したものを お見せします
51. 【破】何を改善する？どう改善する？ お客様要望 小規模改善 問い合わせ起因の 不具合修正 小規模 パフォーマンス 改善 UX改善やエラー 文言修正などの 軽微なもの リファクタリング お客様要望 大規模改善 Ruby/Railsなどの ライブラリ アップデート 既存機能の仕様 変更を伴う改善 など 大規模 パフォーマンス 改善 負債解消 脆弱性対応など
52. 【破】何を改善する？どう改善する？ これで「何を」改善すれば いいかは見えてきました
53. 【破】何を改善する？どう改善する？ 次は「どう」改善するかを考えます
54. 【破】何を改善する？どう改善する？ いきなりこれらの改善を 無通告で行うわけにはいきません どんなに素晴らしい改善であっても 段取りを踏まなければお客様や CSメンバーが混乱してしまいます
55. 【破】何を改善する？どう改善する？ そこで、各改善施策に対して以下の ようなフローを構築しました
56. 【破】何を改善する？どう改善する？ お客様要望 小規模改善 問い合わせ起因の 不具合修正 お客様要望 大規模改善 Ruby/Railsなどの ライブラリ アップデート 小規模 パフォーマンス 改善 UX改善やエラー 文言修正などの 軽微なもの リファクタリング 事前にPdMと合意形成を行い、判断を Guardianグループに一部移譲することで スピーディーに改善を行えるようにしました （もちろん修正前後で連絡はします） 既存機能の仕様 変更を伴う改善 など 大規模 パフォーマンス 改善 負債解消 脆弱性対応など
57. 【破】何を改善する？どう改善する？ 少し特殊で お客様要望 小規模改善 問い合わせ起因の 不具合修正 UX改善やエラー 文言修正などの 軽微なもの お客様要望 大規模改善 Ruby/Railsなどの ライブラリ アップデート 既存機能の仕様 変更を伴う改善 など 小規模 パフォーマンス 改善 リファクタリング ①お客様要望をストック ②CS定例で詳細ヒアリング ③PdMと協議の上やるやら判断 ④Guardian内で調査・実装 ⑤方針に迷ったら再度PdM相談 ⑥リリース 大規模 パフォーマンス 改善 負債解消 脆弱性対応など という手順を踏んでいます 時にはデザイナーが入ることも
58. 【破】何を改善する？どう改善する？ お客様要望 小規模改善 問い合わせ起因の 不具合修正 小規模 パフォーマンス 改善 UX改善やエラー 文言修正などの 軽微なもの 事前にフィルタリングを 行うことでビジネス的に 優先度の高いものだけを かいつまんでクイックに PdMに報告できます お客様要望 大規模改善 Ruby/Railsなどの ライブラリ アップデート 既存機能の仕様 変更を伴う改善 など リファクタリング 大規模 パフォーマンス 改善 負債解消 脆弱性対応など
59. 【破】何を改善する？どう改善する？ お客様要望 小規模改善 問い合わせ起因の 不具合修正 ①Guardian内でモニタリング・ 改善箇所特定 ②必要に応じてテックリード相談 ③実装・計測 ④リリース 小規模 パフォーマンス 改善 UX改善やエラー 文言修正などの 軽微なもの リファクタリング お客様要望 Ruby/Railsなどの ライブラリ アップデート という手順を踏んでいます 大規模改善 既存機能の仕様 変更を伴う改善 など 大規模 パフォーマンス 改善 負債解消 脆弱性対応など
60. 【破】何を改善する？どう改善する？ お客様要望 小規模改善 問い合わせ起因の 不具合修正 小規模 パフォーマンス 改善 UX改善やエラー 文言修正などの 軽微なもの リファクタリング 詳しい計測・分析方法については 先日登壇しましたのでこちらも 合わせてご覧ください お客様要望 大規模改善 Ruby/Railsなどの ライブラリ アップデート 既存機能の仕様 変更を伴う改善 など 大規模 パフォーマンス 改善 負債解消 脆弱性対応など
61. 【破】何を改善する？どう改善する？ 小規模改善 問い合わせ起因の 不具合修正 お客様要望 事前にEM・テックリードと協議の上 小規模 UX改善やエラー パフォーマンス 大まかな方針を策定したうえで 文言修正などの 改善 軽微なもの 期中の目標として掲げて改善しています リファクタリング お客様要望 大規模改善 Ruby/Railsなどの ライブラリ アップデート 既存機能の仕様 変更を伴う改善 など 大規模 パフォーマンス 改善 負債解消 脆弱性対応など
62. 【破】何を改善する？どう改善する？ 小規模改善 お客様要望 脆弱性対応は差し込みで入ることも多いため 小規模 問い合わせ起因の UX改善やエラー パフォーマンス リファクタリング その際は都度クイックに認識合わせを行い 不具合修正 文言修正などの 改善 軽微なもの すぐさま対応に入れるようにしています お客様要望 大規模改善 Ruby/Railsなどの ライブラリ アップデート 既存機能の仕様 変更を伴う改善 など 大規模 パフォーマンス 改善 負債解消 脆弱性対応など
63. 【破】何を改善する？どう改善する？ いずれもに共通することとして Guardianグループの強みである ステークホルダーとの連携を活かして スピーディーに合意形成しながら 改善を進めていっているということが言えます
64. 【破】何を改善する？どう改善する？ 特にお客様に近いカスタマーサポート・導入支援の メンバーからの意見を踏まえて意思決定が できることはGuardianグループならではの強みです
65. ここまでまとめ ・大規模改善、小規模改善を分類することで それぞれのタスクの特性が見えてきた ・タスク特性ごとにチェックポイントを 設けて民主的に改善を進めている ・ここ最近は特にPdM、CS、導入支援の メンバーとの連携が盛ん
66. 【急】 改善を通して 見えてきたもの
67. の前に
68. 【急】改善を通して見えてきたもの 当初、Guardianグループは SmartHRさんが掲げられている 「Customer Observability」の 概念を踏襲してお客様の価値に直結する 取り組みを行おうと考えていました
69. 【急】改善を通して見えてきたもの ですが、うまくいきませんでした チーム内で話せば話すほど 小さなものになっていって SmartHRさんが掲げているものからは 程遠いものが生まれてしまいました
70. 【急】改善を通して見えてきたもの いろんな理由があると思いますが 一番大きな理由はズバリ 「CREはドメインや組織体系を映し出す鏡」 であるからだと思っています 組織Aではうまくハマっている取り組みが 組織Bではうまくワークしない… ここがCREの難しいところですね
71. 【急】改善を通して見えてきたもの そこで我々は別のアプローチとして、前述の通り 「ステークホルダーと徹底的に対話する」 という方向に舵を切りました
72. 【急】改善を通して見えてきたもの 結果、今のところはうまくワークしているので このやり方がGuardianグループには 適していたのかなと思います とは言え定量評価をするための取り組みは できる範囲でではありますが、構築できたので Customer Observabilityについて考えられたことは 非常に有意義な時間でした
73. 例：問い合わせ傾向分析
74. 【急】改善を通して見えてきたもの
75. 【急】改善を通して見えてきたもの 今後とも隙あらばCustomer Observabilityを カスタマイズしてインストールできるよう 機会を虎視眈々と狙っていきたいと思います
76. 閑話休題
77. 【急】改善を通して見えてきたもの 当初イメージしていた要望とは とにかく新機能の追加であったり 現在の挙動の大幅な改善であったり 今をときめくトレンディな何かであったり そういった「難しいもの」の集合体でした
78. 【急】改善を通して見えてきたもの ですが、蓋を開けてみると 文言の改善であったり エラー時の挙動修正であったり ちょっとしたUIの改善であったり そういったものも少なくありませんでした （当然難易度の高い要望もありますが）
79. 【急】改善を通して見えてきたもの 我々は常日頃から新機能の開発を進めているので 新規のお客様に対してのアプローチはできています ですが、既存のお客様に対して「小さな優しさ」を もっと発揮していくことができれば 世界は優しさで溢れてみんなハッピーに なれるのではないでしょうか？
80. 【急】改善を通して見えてきたもの この辺りは投資の話にも似ているな、と最近思っていて リスクヘッジが大事だよなと思うなどしています 投資（新機能開発）だけでなく 貯蓄（機能改善・顧客要望改善）も大事 大事なのはバランスです
81. 【急】改善を通して見えてきたもの そして、最近NEXT CREとしてデータ駆動による パフォーマンス改善を行ってきた結果 皮肉にも我々はデータに頼りすぎているのでは という仮説に行き着きました
82. 【急】改善を通して見えてきたもの 何が言いたいかと言うと モニタリングツール上は性能が悪く見える機能で あっても意外とお客様は困っていなかったり その逆も然りで、一見問題がなさそうに見えても 実は満足いただけていない機能があったり いろんなパターンがあるなと思っております
83. 【急】改善を通して見えてきたもの そしてそれらを掘り起こすためには お客様やお客様に近い立場にいる人との コミュニケーションが必要不可欠です
84. そこで次のことへの コミットを決めました
85. コミット① 月に最低2日はチームで 改善だけを行う 改善デーを設ける
86. 【急】改善を通して見えてきたもの お客様からの要望というのはダイヤの原石の集合体です どんなに小さなものであってもないがしろにせず コツコツと改善し続けていくことが 信頼関係の構築にもつながっていくと思います
87. コミット② データに頼りすぎず 有機的なパフォーマンス 改善を行う
88. 【急】改善を通して見えてきたもの SRE領域で有名な言葉として 「推測するな、計測せよ」というものがあります これはNEXT CREを前に進めていくうえで 非常に心強い言葉で、今も胸に深く刻まれています ですが、CREとしてもう一歩前に踏み出すために 私たちは「推測するな、対話せよ」のマインドを インストールする必要があると考えています
89. 【急】改善を通して見えてきたもの ここで言う「有機的な」とは対話のことです お客様やお客様に近い立場にいる方から ヒアリングを行ったうえで仮説を立て 計測に基づいて事実確認を行い 改善を進めていきたいと考えています
90. 【急】改善を通して見えてきたもの これらの取り組みはまだ構想段階なので うまくいくかはわかりませんが 実った暁にはまた違うイベントで 進捗報告できればと思います！
91. 【結】まとめ ・CREに他社のベストプラクティスを そのままインストールするのは難しいが カスタマイズはできる ・お客様の要望は難しいものばかりではない！ ・計測だけではダメで、対話の重要性が 増してきている
92. 【結】まとめ デジタルとアナログの狭間を行き来するCRE デジタルとアナログを泥臭く往復し ブレずにフォーカスを絞りながら 魂と魂でぶつかり合って 確かな信頼性を紡いでいく これこそが最高にカッコよくて、ロックなCRE なんじゃないかなあと
93. 【結】まとめ Rock’n☆CRE やっていき！
94. ご清聴 ありがとう ございました