[JAWS Festa 2026]一番いい仕事は、請求書に現れない / jawsfesta2026

Transcript

1. 一番いい仕事は、 請求書に現れない。 〜PMから見たAWSコスト最適化と、評価されない貢献の話〜 Shintaro Fukatsu #jawsug #jawsfesta2026
2. 深津 新太郎 事業会社の情報システム子会社でPM 開発と運用の両方を見ています 2025・2026 Japan All AWS Certifications Engineers 2026 Japan AWS Top Engineers JAWS-UG 彩の国埼玉 運営 AWS Community Builder（Cloud Operations）
3. コスト削減で、 褒められたことは？
4. 最初から無駄を作らず 褒められたことは？
5. RI や Savings Plans は、推奨どおり買うだけ 環境を変えなくていいので、始めやすい 毎年、予測してコンソールで買う
6. 買えば、数字が残る
7. でも、作らなかった無駄は残らない
8. 後から直した人のほうが、評価しやすい 直した額は、数字になる 最初から作らなかった額は、数字にならない 数字で見えるほうが、評価しやすい
9. そもそも、避けたコストって成果なの？ 回避も、価値に数えられている！ “The benefits from cost optimization, however, go above and beyond cost reduction or avoidance.” コスト最適化の効果は、削減や回避にとどまらない // Well-Architected COST01-BP09 // COST01-BP09 docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management_quantify_value.html
10. …でも、AWS のスコアには出てこない Cost Efficiency は、今あるリソースを測る 作らなかった無駄は、計算式に現れない 1 −（潜在的な削減額 ÷ 最適化の対象となる支出） // Cost Optimization Hub の Cost Efficiency docs.aws.amazon.com/cost-management/latest/userguide/coh-cost-efficiency.html
11. なんで、予防は 報われないの？
12. 測れるほうに、努力は寄っていく Savings Plans の購入や後からの削減は、測りやすい仕事 予防や良い設計は測りにくい仕事 見えている頑張りと見えない頑張りがある
13. 作るときも、動いたあとも、手を入れられない 開発中は納期を優先せざるを得ない 磨き直す時間は、見積もりに入らない 運用中は、壊す責任を負えず触れない Savings Plans は買うのに、インスタンスタイプは変えない 経緯やナレッジは、異動や退職で消える 作った人も、直した人も、頑張っている
14. 誰も悪くないのに、誰も動かない FinOps は、ビジネス価値とつなげようと言う // FinOps Foundation, FinOps Principles つなげようと思う動機って何？ 予防したら、誰か褒めてくれる？ 人ではなく、測り方の問題
15. じゃあ、 どうすればいいの？
16. コストを最初から要件にする “Make Cost a Non-functional Requirement” コストを、最初から要件の一つにする // Werner Vogels, The Frugal Architect, Law I（re:Invent 2023） “Work with team members to define the balance between cost optimization and other pillars, such as performance and reliability, for this workload.” 性能や信頼性と並べて、コストとのバランスをチームで決める // AWS Well-Architected Framework COST05-BP01 // COST05-BP01 docs.aws.amazon.com/wellarchitected/latest/framework/cost_select_service_requirements.html
17. 3つの段階で考える
18. 設計 作る前に、採らなかった案と比べる 要件を満たす案同士で比べる より良い案をエージェントと探す 比べた結果を チームで見える形に残す // AWS Pricing MCP Server 等を活用 開発 運用
19. 設計 作ったら、エージェントがレビュー // 構成は一部を簡略化して記載しています 開発 運用
20. 設計 要件を満たす中で、一番安い案を推す “A fully cost-optimized workload is the solution that is most aligned to your organization’s requirements, not necessarily the lowest cost.” 最もコスト最適なのは、 要件に一番合う案で、 一番安い案とは限らない // Well-Architected COST05-BP01 // COST05-BP01 docs.aws.amazon.com/wellarchitected/latest/framework/cost_select_service_requirements.html 開発 運用
21. 設計 動き出したら、FinOps Agent に任せる 異常の原因まで調べてくれる 定期レポートにまとめてくれる 普段の言葉で頼める // AWS FinOps Agent（プレビュー） 開発 運用
22. 設計 こんな頼み方でいい 開発 運用
23. 設計 自分の仕事がいくらかを、見えるようにする “Giving visibility and creating awareness in engineering teams to understand what they do, and what they impact in terms of cost.” チームが、自分の仕事とそのコストへの影響を分かるようにする // AWS Well-Architected Framework COST01-BP08 ダッシュボードは、作り込まなくても始められる // COST01-BP08 docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management_culture.html 開発 運用
24. で、それって 評価されるの？
25. モチベーションを上げる3つの仕掛け 避けた額も、削った額も、数字で見せる 浮いたお金の使い道を語る 成果を共有し、感謝を伝える場を作る “Reward voluntary or unsolicited cost optimization accomplishments publicly or privately, and learn from mistakes to avoid repeating them in the future.” 自発的なコスト最適化の成果は、公の場でも個別にでも称え、失敗からは学んで繰り返さない // AWS Well-Architected Framework COST01-BP08
26. 仕事をどう測る？ 測るもの 測り方 間に合ったか 納期どおりに出せたか 後から下げた額 変える前と後の請求の差 作る前に避けた額 複数の案を比べ、どれだけ回避したか 誰の工夫であっても、評価する 発注先のベンダーやパートナー、派遣や委任のメンバーも
27. 全部は測れない 作業の重さは、ツールでも測れない // FinOps Agent のレポートより 指標が目標になると、良い指標でなくなる // グッドハートの法則 数字は材料 数字と人の行動を合わせて評価する
28. コストも、シフトレフト セキュリティと同じく、早い段階で手を打つ 後から直すより、最初から作らない 一番いい仕事は、請求書に現れない。
29. Share your lessons.
30. 出典 Werner Vogels, The Frugal Architect（thefrugalarchitect.com） AWS Well-Architected Framework（COST01-BP04 / BP08 / BP09、COST05-BP01） AWS Cost Optimization Hub ユーザーガイド（Cost Efficiency） FinOps Foundation, FinOps Principles（finops.org） グッドハートの法則（Strathern, 1997 による一般化） // AWS および関連する名称とロゴは、Amazon.com, Inc. またはその関連会社の商標です。 その他の会社名、製品名は、各社の商標または登録商標です。