突発タスクの多い保守運用組織が 不確実性にどう向き合っているか

Transcript

1. 2026.02.24 どうする？どうしてる？プロジェクトマネジメントとは？ しまむー（@shimatarox） 突発タスクの多い保守運用組織が 不確実性にどう向き合っているか
2. Money Forward, Inc. 2 06 まとめ 02 背景 01 はじめに 03 変化と 成果 04 壁と葛藤 05 それは いわゆる...
3. Money Forward, Inc. 3 しまむー 株式会社マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループ Customer Reliability Engineer
4. Money Forward, Inc. 4 しまむー 株式会社マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループ Customer Reliability Engineer チームの開発プロセス改善 にも注力しています
5. 本日のお話 「保守運用組織 において どのような不確実性に どう対処して どうなったか」
6. まずは 前提の共有から
7. 我々の保守運用組織 の立ち位置 という経費精算プロダクト
8. 我々の保守運用組織 の立ち位置 Warrior ⚔ Guardian 🛡 の開発組織をとてもざっくり分けるとこんな感じ 他にも…
9. 我々の保守運用組織 の立ち位置 Warrior ⚔ Guardian 🛡 機能開発を主体 保守運用を主体（我々） の開発組織をとてもざっくり分けるとこんな感じ 他にも… QA, デザイナー, PdM などなど
10. 我々の保守運用組織 の立ち位置 Warrior ⚔ Guardian 🛡 機能開発を主体 保守運用を主体（我々） の開発組織をとてもざっくり分けると 約10年に及ぶプロダクトの成長の過程で 開発組織にWarriorとGuardianが誕生👶 そして今に至る 他にも… QA, デザイナー, PdM などなど
11. Guardianにおける２つの運用 とは 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 問題が顕在化した後の対応 問題が顕在化する前の対応 「攻め」と「守り」の2つの運用を定義しています
12. Guardianにおける２つの運用 とは 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 こちらも もっと強化したい！ 問題が顕在化した後の対応 問題が顕在化する前の対応 もっと「攻め」に転じたい
13. 不確実性
14. 僕らの抱える不確実性とは 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ いつ来るか わからない 問題が顕在化した後の対応 問題が顕在化する前の対応 「守りの運用」を取り巻く様々な不確実性
15. 僕らの抱える不確実性とは 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ いつ来るか わからない いつ終わるか わからない 問題が顕在化した後の対応 問題が顕在化する前の対応 「守りの運用」を取り巻く様々な不確実性
16. 僕らの抱える不確実性とは 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ いつ来るか わからない 難易度が わからない いつ終わるか わからない 問題が顕在化した後の対応 問題が顕在化する前の対応 「守りの運用」を取り巻く様々な不確実性
17. 僕らの抱える不確実性とは 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ いつ来るか わからない 難易度が わからない いつ終わるか わからない 問題が顕在化した後の対応 問題が顕在化する前の対応 何件来るか わからない 「守りの運用」を取り巻く様々な不確実性
18. 僕らの抱える不確実性とは 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ 何件来るか わからない いつ来るか わからない 難易度が わからない いつ終わるか わからない 「わからない」 が多すぎる！！！ という複雑性 「守りの運用」を取り巻く様々な不確実性
19. 課題
20. 我々の抱えていた課題 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ いつ来るか わからない 難易度が わからない いつ終わるか わからない 問題が顕在化した後の対応 問題が顕在化する前の対応 何件来るか わからない 「守りの運用」に気を取られすぎると
21. 我々の抱えていた課題 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ いつ来るか わからない 難易度が わからない いつ終わるか わからない ①「守り」に追われ、 「攻め」に手が回らない 問題が顕在化した後の対応 問題が顕在化する前の対応 何件来るか わからない 「守りの運用」に気を取られすぎると
22. 我々の抱えていた課題 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ いつ来るか わからない 難易度が わからない いつ終わるか わからない ①「守り」に追われ、 「攻め」に手が回らない ②「守り」ばかりでは 士気も保ちづらい 問題が顕在化した後の対応 問題が顕在化する前の対応 何件来るか わからない 「守りの運用」ばかりしていると
23. 我々の抱えていた課題 機能改善・機能開発 攻めの運用 守りの運用 お問い合わせ対応・障害対応 もっと攻めたい！！！！ いつ来るか わからない 難易度が わからない いつ終わるか わからない ①「守り」に追われ、 「攻め」に手が回らない ②「守り」ばかりでは 士気も保ちづらい 問題が顕在化した後の対応 問題が顕在化する前の対応 何件来るか わからない ③成果を実感しにくい。 水道・電気のように 「守って当たり前」の存在 「守りの運用」をこなしているのに
24. もっと「攻め」に転じたい！ 我々の抱えていた課題 「守りの運用」をこなしているのに
25. Money Forward, Inc. 25 06 まとめ 02 背景 01 はじめに 03 変化と 成果 04 壁と葛藤 05 それは いわゆる...
26. なぜそこに 「スクラム」を導入した？ ↓ 組織の目的を果たすため
27. 我々は何故ここにいるのか 弊リーダー Guardianは DevOpsの能動的な体現を目指す 組織である
28. DevOpsの能動的な体現...！ 💡
29. DevOpsの基本原則に立ち戻ると https://about.gitlab.com/ja-jp/topics/devops/#the-four-phases-of-dev-ops
30. DevOpsの基本原則に立ち戻ると https://about.gitlab.com/ja-jp/topics/devops/#the-four-phases-of-dev-ops 守りの運用 攻めの運用 まさにCRE!
31. DevOpsの基本原則に立ち戻ると https://about.gitlab.com/ja-jp/topics/devops/#the-four-phases-of-dev-ops スクラム導入したら この辺り もっと改善できそう！
32. Money Forward, Inc. 32 攻めの運用 Dev 守りの運用 Ops DevOpsを能動的に体現するために 能動的にスクラムを導入するぞ！
33. 具体的に 何を導入したの？
34. スクラムイベントを「全て」導入しました 導入前 導入後 スプリント ー（単なる週区切り） あり（１週間スプリント） デイリースクラム あり あり スプリントプランニング ー あり スプリントレビュー ー あり スプリントレトロスペクティブ あり あり（改善） （リファインメント） あり（都度） あり（定例＋都度）
35. スクラム導入前のGuardian 「デイリースクラム」「レトロスペクティブ」を実施
36. スクラム導入後のGuardian 他チームも巻き込み、スクラムイベントを全て実施 （一部省略）
37. スプリント 🙆 自然と１週間の区切りが意識できる １週間というタイムボックスを明確に設定
38. バックログリファインメント 🙆 CS要望定例で具体的な要望をCSチームから直接 聞ける 🙆 実現できるかパッとわからないものは、スパイク（技 術的調査）として切り出し、段階を分けて理解を進める ように 🙆 機能要望がPBIとしてバックログに乗るように CSチームとの定例で「攻め」の解像度を上げる
39. スプリントプランニング 🙆 スプリントバックログにタスクを可視化 🙆 「守り」のバランスを見つつ、計画的に 「攻め」ができるように 🙆 スプリントゴールを設定し、 「何かに向かって努力している」ことを意識づけ そのスプリントで何を「攻め」何を「守る」かを決める
40. スプリントレビュー 🙆 CS要望定例で生まれたPBIに関するコミュニ ケーションの場ができた 例）CSチームとGuardianだけでは判断しかねる内 容の相談 🙆 スプリントの成果物が日の目を見るように 🙆 他チームからのフィードバックを得られる PdM・Designerとの定例で成果を提示、フィードバックを活かす
41. 🙆 資料をdocs → miro にし、視覚的な ふりかえりを強化 🙆 スプリントゴールとの差分を意識できるように 🙆 KPT以外の手法も定期的に取り入れ、多角的に ふりかえり、改善に繋げられるように （ふりかえりカタログに大変お世話になっております） スプリントレトロスペクティブの改善 ふりかえりを力に
42. 他にもこんな改善をしました Guardian流のリファインメント 攻めの運用 守りの運用 事前見積もり（PBI・スパイク） 事後見積もり （お問い合わせ/インシデント） 発生時には見積もり困難。事態が落ち着いたら見積もる。 CS要望定例にて、顧客要望から実現できそうなアイテムを PBIとして起票済。 それを見積もる。 詳細が不明確な場合は、調査タスクをスパイクとして起票。設計と実装の見通しが 立ってからPBIとして起票し、それを見積もる。 スプリントプランニングの枠を活用
43. Money Forward, Inc. 43 06 まとめ 02 背景 01 はじめに 03 変化と 成果 04 壁と葛藤 05 それは いわゆる...
44. うまくいったこと
45. 先述の課題が解消してきた 大きく3つの課題がありましたが・・・
46. ①「守り」に追われ、「攻め」に手が回らない 「攻め」の成果物がデリバリーできる仕組みが整った
47. ②「守り」ばかりでは士気も保ちづらい 「スプリントゴール」で向き先を意識。最後まで「攻め」ることが、お客様への価値提供に直結 する。
48. ③成果を実感しにくい。水道・電気のように守って当たり 前。 「スプリントレビュー」で、成果が他チームの目にもとまる仕掛けを実現。 毎日軽いウィンセッションも実施。 苦労はチームで分かち合う。 成果はチケットとして形に残る。
49. 結果、お客様にさらに価値が届けられるように
50. Money Forward, Inc. 50 06 まとめ 02 背景 01 はじめに 03 変化と 成果 04 壁と葛藤 05 それは いわゆる...
51. 保守運用 × スクラム の限界
52. 「守りの運用」タスクを 「攻めの運用」と同じように管理しようとしても うまくはまらない 「攻めの運用」はだいぶ改善したけれど・・・
53. 保守運用 × スクラムはやはり相性がよくない いつ来る？ 難易度は？ 影響範囲は？ 「守った」分、「攻め」が持ち越しになる どれくらいかかる？ 積んでいた「攻め」のタスクたち・・・ さようなら
54. 保守運用 × スクラムはやはり相性がよくない 一人一人が 別のお問い合わせを対応 することもよくある 実は「スプリントゴール」が設定しにくい チーム一丸で今週は 「これ一本」に向かうぞ！！ が決めにくい 「攻め」のタスクも 一人で対応可能な粒度が多い
55. 保守運用 × スクラムはやはり相性がよくない 問い合わせ・インシデントは 多種多様のうえ 緊急度も高い やっぱり「見積もり」が大変 発生した瞬間に見積もるのは 熟練メンバーでも至難の業 どうしても事後に見積もるほかない タスクも一定ある
56. 保守運用 × スクラムはやはり相性がよくない 💡 そうか
57. スクラムイベントを守ることに 躍起になりすぎてはいないか？ あるとき気がついた
58. 別に、全部をスクラムで 救おうとしなくてもいいのでは？ 現在の運用で 誰かがめちゃめちゃ困っている というわけではないし あるとき気がついた
59. 教科書通りの運用を諦め、自分たちに合わないものは形を変えた。 • スプリントの持ち越しを許容する ◦ 守りの運用タスクの完了がスプリントを跨ぐことをよしとする • 突発タスクの事後見積もり ◦ リファインメントできないものは諦めて、対応が完了してから事後見積もりする • 意気込みから始めるスプリントゴール ◦ 無理にチームとしてのゴールに落とし込まない ◦ 一人一人が、その週の「意気込み」をシェアし、その集合をゴールとして定義 保守運用 × スクラムは相性が悪い
60. Money Forward, Inc. 60 06 まとめ 02 背景 01 はじめに 03 変化と 成果 04 壁と葛藤 05 それは いわゆる...
61. スクラムバン と呼ばれる「型」だった
62. 最初から狙っていたわけではなく、手探りで改善を続けて行ったらたまたま、 「スクラムバン」と 名前がついている ような手法に辿り着いた https://www.atlassian.com/ja/agile/project-management/scrumban こういう手法には名前がついていた
63. 最初から狙っていたわけではなく、手探りで改善を続けて行ったらたまたま、 「スクラムバン」と 名前がついている ような手法に辿り着いた https://www.atlassian.com/ja/agile/project-management/scrumban こういう手法には名前がついていた まさに我々が 辿り着いたもの 構造＝「攻め」 柔軟性＝「守り」
64. Money Forward, Inc. 64 06 まとめ 02 背景 01 はじめに 03 変化と 成果 04 壁と葛藤 05 それは いわゆる...
65. • 「DevOpsの能動的な体現を目指す」ための課題に直面した • 打開策の1つの手段として「スクラム」を導入した • 型にハマった部分は適用し、ハマらなかった部分はあえて残した • そうして辿り着いたもの自体が、実はすでに型として世にあった まとめると
66. 「どうする？どうしてる？ プロジェクトマネジメントとは？」 という本日のお題に対して思うこと
67. Money Forward, Inc. 67 どうする？どうしてる？プロジェクトマネジメントとは？ どうしてる？ 「何故を知り、型を取り入れ無理はせず、型と余白をバランスすべし 」 ・何故何かを改善したいのか（ devopsの能動的な体現を目指すため） ・「型」を取り入れる（スクラムという型） ・合わない部分は深入りせず、無理に全てを型に合わせない ・そしたらそれがまた「型」になっていた（スクラムバンという型） プロジェクト マネジメントとは？ 目指す未来に狙いを定め、辿り着くまでエネルギーを投げ続けること これは、projectの語源（前方（未来）に向かって投げかけること）通り、 実現したい未来を見据え、適度に型にはめながらそれに向かい努力し続けること だと思います
68. 皆様の知見もぜひ 後ほど教えてください
69. ご清聴 ありがとうございました！