FinOps_Enabling_LT.pdf

Transcript

1. コストオーナーシップ醸成へ 〜 FinOpsのEnablingとは？ 〜
2. 経歴 • 2010年〜2023年 SIer複数社経験 ◦ VM、OracleDB、Microsoft Azure、AWS • 2024年〜2025年 化粧品メーカー CCoE ◦ FinOps、DevSecOps推進 • 2026年1月 フリー株式会社 Join SRE本部 Platform部 CloudGovernanceチーム 北川 卓図 ◦ FinOps推進 JAWS-UG 彩の国埼玉支部運営もしてます 2
3. スモールビジネスを、世界の主役に。
4. 会計‧⼈事労務‧販売管理を核とした 統合型経営プラットフォーム 会計 ⼈事労務 販売管理 電⼦契約 ⼯数管理 固定資産 経費精算 請求管理 債権債務 管理 電⼦稟議
5. (1) スモールビジネス向けに統合型クラウド ERPを提供 その他サービス 統合型クラウド会計ソフト 2013年3⽉〜 ⽇本のクラウド 会計ソフト市場 シェアNo.1(2) 請求書 経費精算 決算書 予実管理 ワークフロー 内部統制 注: 統合型クラウド⼈事労務ソフト 統合型クラウド販売管理ソフト 2014年10⽉〜 2022年11⽉〜 スモールビジネスの ⼈事管理市場において 売上⾦額シェアNo.1(3) 【国内初】 クラウド会計ソフトと ⼀体型で使える 販売管理サービス 勤怠管理 ⼊退社管理 給与計算 年末調整 マイナンバー 管理 ⽀出管理 福利厚⽣ ⼈事労務 申告書作成 ⼯数管理‧労務費管理 ⾒積‧発注‧請求 法⼈⼿続き クレジットカード 開業⼿続き 電⼦契約 1. クラウドサービス：ソフトウェアやハードウェアを所有することなく、ユーザーがインターネットを経由して ITシステムにアクセスを行えるサービス 2. リードプラス「キーワードからひも解く業界分析シリーズ：クラウド会計ソフト編」（ 2022年8月） 3. 「freee人事労務」は ITRが今年調査発行した「 ITR MARKET VIEW：人事・給与・就業管理市場 2022」の人事管理市場において、従業員 100人未満および従業員 100~300人未満の企業で売上金額シェア No.1（2020年度）を獲得しています。 5
6. FinOps Principalsにおける Enablingって？
7. FinOps Principals Teams need to collaborate Business value drives technology decisions FinOps data should be accessible, timely, and accurate FinOps should be enabled centrally Take advantage of the variable cost model of the cloud Everyone takes ownership for their technology usage https://www.finops.org/framework/principles/ 7
8. FinOps Principals Teams need to collaborate Business value drives technology decisions FinOps data should be accessible, timely, and accurate FinOps should be enabled centrally Everyone takes ownership for their technology usage Enablingを進めるには この原則も大事 Enablingを進めるには この原則も大事 Enablingの原則はこれ Take advantage of the variable cost model of the cloud https://www.finops.org/framework/principles/ 8
9. • 全員が当事者意識を持つ • 中央部隊が土台を作る • 正確さを兼ね備えたデータの可視化 9
10. 出典：finops foundation state of finops 2022 FinOpsの実践における最⼤組織的障壁や課題 → エンジニアに⾏動を起こさせること 10
11. AWSコストを活かすまでのロードマップ FY27 「知る」フェーズ H1 プロダクトの AWSコストを 「実績をチェック」 継続 実施 H2 プロダクトの AWSコストを 「実績をチェック」 し 「予算を見直す」 FY28 「管理し始める」フェーズ FY29 「管理し活かす」 フェーズ H1/H2 H1/H2 プロダクトのAWSコストを 「予算を立てて」 「実績をチェック」 し 「予算を見直す」 プロダクトのAWSコストを 自ら「予算を立てて」 「実績をチェック」 し 「予算を見直す」 AWSコストが予算超過した場合の「AWSコスト異常調査/AWSコスト改善」 AWSコスト改善した場合の「対処方法ドキュメント化」 11
12. コストオーナー醸成のための (freeeにとっての )4本柱
13. コスト管理と言われても分からないことだらけ ①うちのプロダクトって そもそもコストどれくらい ②とはいえ、コスト管理は チームの誰かがやって かかってるの？ くれるんじゃない？ ③そもそも、うちのチーム プロダクトに予算金額って ④コストが増えそうなんだが どう運用、連絡すればいいの？ どれくらい割当たってるの？ 開発チーム エンジニア 13
14. freeeでのコストオーナー醸成4本柱 ⾒える → 担う → 判断できる → 続けられる ①コストが不透明 ②コスト管理 誰がやる？ ③予算⾦額が不透明 ④増額時の運⽤がない 可視化 コストオーナー アサイン プロダクト毎 予算伝達 増額運⽤フロー 定義 ⽇次‧⽉次 by name Projectタグ 予想内‧意図せず コスト判断の材料を いつでも確認できる チーム内に⽂化を 波及させる先導者 ⾃分たちの予算を ⽇次で判断する 増額時の運⽤と 連絡⽅法を明確にする 14
15. 可視化
16. 可視化には、⽇次と⽉次の2種類がある 変化と傾向、両⽅が判断に必要 ⽇次コスト ⽉次コスト 変化 → 違和感 → ⾦額 → 過去推移 → 早期確認 予算判断 Looker Studioで確認 スプレッドシートで確認 16
17. 日次・月次コストの可視化構成 月次：過去推移 CUR Athena Digdag Spreadsheet 日次：変化検知 Looker Studio 17
18. 日次 × 月次 コスト判断の材料を容易に得られる状態へ 当事者意識を持つ、第一歩 18
19. コストオーナーアサイン
20. 文化を波及させる先導者を、 by nameで決める 開発チーム本部長 アサイン アサイン要請 開発チーム コストオーナー CloudGovernance チーム コスト管理伴走 巻き込む 開発チーム 他メンバー 20
21. コストの判断を開発チーム側で実施できる CloudGovernanceチーム 財務チーム 開発チーム コスト増加時の連絡、許可 予算策定依頼 コスト増加承認 予算策定、予算見通し修正 実績確認 改良・改善 コスト実績 定常確認 コスト増加時の 判断材料を得る 自主的にコスト 最適化を検討 21
22. プロダクト毎の予算金額
23. 予算はProjectタグごとに算出 超過の違和感へ、早く気づける単位にする ① Projectタグごとの予算 プロダクトの意思決定単位に合わせ、⾃分たちの予算として伝える ② ⽉次ではなく、⽇次予算 ⽉次だけでは超過の違和感に気づきにくい。⽇次なら変化を早く検知できる ⾃分たちの予算を、⾃分たちで判断する 23
24. 増額運用フロー定義
25. コスト増額は、2種類に分けて考える 同じ「増額」でも、必要なアプローチは違う 事前に予想できる増額 意図せず発⽣した増額 • 実施前に予算に収まるかを判断 • 発⽣後すぐに状況を確認 • 予算内なら連絡不要 • 翌営業⽇までに共有 • 予算外なら事前連絡 • 原因‧⾒込み‧対処策を整理 • ⾃分たちの予算を把握し、⾃律して判断 • 対処後、必要なら予算を⾒直す 予想できるかどうかで、運⽤フローを分ける 25
26. 事前連絡時の予算対応フロー (1) 将来、AWSコストが増える予定 月次予算を超える 見込みか NO 特に連絡は不要 YES コストオーナー 完了 部内の予算に収まるか確認 開発チーム部長 予算修正を承認 コストオーナー → CGov Slackワークフローで CGovへ連絡 フローチャート（ 2）へ 26
27. 事前連絡時の予算対応フロー (2) フローチャート（ 1）より CGov 数営業日の間に CGovが判断 NO 判断結果 OK NG CGov 開発チームと CGovで ケース別に相談 予算修正を依頼 インスタンスタイプ・台数・ 増額スケジュール等 コストオーナー 予算を修正 両者合意 → 必要に応じて予算を修正 完了 AWSコスト予算運用フロー 27
28. 意図せず増額した場合のフロー (1) 日次予算を超過 AWS 予算超過通知を発行 AWS → Slack Slack chへ通知 翌営業日までに CGovへ報告 （月次予算見込み・原因・対処予定） 状況に応じた対応（ 2）へ 28
29. 意図せず増額した場合のフロー (2) フローチャート（ 1）より コストオーナー コスト削減対処を実施 YES 削減施策が明確で 実施可能か NO コストオーナー YES 船内の予算に収まるか確認 NO 予算見通しの修正が 必要か 開発チーム船長 予算修正を承認 予算修正は不要 コストオーナー 予算を修正 コストオーナー → CGov スプレッドシート更新を CGovへ連絡 完了 29
30. とは⾔え、苦労している点もあります 1 2 3 プロダクト数が単純に多い AWS使⽤量TOP 10から徐々に始めているが、主要プロダクトにコスト運⽤を定着しきるのはまだまだ時間がかかる プロダクト特性/フェーズも多種多様で予算初版を策定するのに時間を要する 画⼀的であればAIを駆使して予算を決めることは容易だが、たまたま料⾦が上がってた、特に増減しない or 逓増的に増 加する予定等 AIでキャッチアップできないコンテキストがある。結局⼈の判断を要する。 プロダクト毎の予算可視化からプロダクト毎のROI可視化へ 開発チームに追ってもらうのはオンデマンドコスト。決済処理は償却コストで⾏うのでそこからRI/SP適⽤後の⾦額を算 出する必要がある。ARRもプロダクト毎で出し、ROIのOKRを元にコスト管理の動機づけを⾏う。 コストオーナーシップ醸成は、ここからが本番 30
31. 可視化・主担当・予算・運用フロー 文化が育つ「土壌」は揃った 全てのチームが、自分たちのクラウドコストを管理でき る状態へ 31
32. スモールビジネスを、世界の主役に。