$30 off During Our Annual Pro Sale. View Details »

「共通基盤」を超えよ! 今、Platform Engineeringに取り組むべき理由

「共通基盤」を超えよ! 今、Platform Engineeringに取り組むべき理由

OpenShift.Runで登壇した資料です。

Kazuto Kusama

April 11, 2024
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering

    Meetup Founder @Cloud Native Innovators Association この四角枠は資料公開にあたって、登壇 中に喋った内容に近くするために補足で 追加したモノです
  2. クラウドの登場とDevOps Dev Ops Configure Verify Package Plan Monitor Release Create

    Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるよ うにするアプローチ。 このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登 場した
  3. 従来の『共通基盤』の視点 コスト削減 システム統合 OSS プロセス改善 運用一元化 ガバナンス 強化 中央管理 プロセス整備

    標準化 一見合理的に見えるが・・・ 昔の共通基盤の取り組みについて事例を 見てみると、そのモチベーションはこの 2つに集約されていることが多いと気づ きました。
  4. もしあなたが開発者だったとして・・・ コスト削減のために 共通基盤を使え ガバナンスのために 共通基盤を使え うるーせ馬鹿 (渋い顔をしながら) はい、わかりました すごくいい取り組み だと思います!

    ですが今回の案件は XXXがXXXでXXXX なので独自の環境で (以下長文) ぼくたちは大人なのでホンネは胸に押し 込みつつ、仕方なく受け入れるか、ある いは理由を立てて断るかのどっちかにな ります。これじゃぁ使われないのも当然
  5. 共通基盤でコストが下がるは幻想 システムA システムB システムC システムD 共通基盤 A B C 数

    年 後 かつて共通基盤 だったもの A B C E F D G 新共通基盤 もはや 独自基盤 古い基盤に しびれを切 らして乗り 換え 新しい技術 が使いたい 新規事業 我が道を行く 中長期で見てコストは下がったのか?
  6. 共通基盤だから、投資をしつづけるべき 共通基盤 A B C D 最初は載らない ものもある 共通基盤 A

    B 共通基盤 C D 半 年 後 投資 & 進化 X 年 後 投資 & 進化 進化により 載るように A C D E F B Good bye ノウハウ蓄積が あるので新規事 業も載りやすい 事業環境の変化 にも柔軟に対応 コスト削減を大義名分にする と、投資ができなくなる。 そして進化できずに死ぬ
  7. 『正しい』とは何か 認知負荷を下げよう! アジリティを高めよう! Kubernetesでプラットフォーム組んで 実現! Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、

    クラウドはServerlessで、 特に課題感は無いんだけど? いやこれがこれからの デファクトスタンダードなんだよ つかえよ 使われるわけがない
  8. Platform as a Product • 開発者を『顧客』として考え、顧客にプラット フォームという『プロダクト』を提供していく というアプローチ • 世の中に提供されているさまざまなプロダクト

    と同じ管理手法を、プラットフォームにも取り 込んでいく 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
  9. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム

    どういう価値を提供できれば 使って貰えるか 顧客が何に困っているか どうやってサポートしていく か どうやって教育していくか どうやって安定したチームを 作るか プラットフォームによる効果 がどのくらい出ているか 何をいつまでに提供するか 世の中のトレンドはどうなっ ているか
  10. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト

    マネージャー プロダクトマネジメントの 手法がそのまま使える。 チームに専任のプロダクトマ ネージャーを置き、プロダク トとしてのプラットフォーム の方向性を決めていく
  11. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト

    マネージャー • プラットフォームが最も達成したい指標は何か ◦ North Star Metricsの策定 • 顧客は何にペインを感じているのか ◦ ユーザーヒアリング • 最も重要なものから実現し、TVP(Thinnest Viable Platform)を作る ◦ 実装する機能の優先順位付け • 社内にその存在を知ってもらう ◦ ブランディング、社内マーケティング
  12. 共通基盤だから、投資をしつづけるべき 共通基盤 A B C D 最初は載らない ものもある 共通基盤 A

    B 共通基盤 C D 半 年 後 投資 & 進化 X 年 後 投資 & 進化 進化により 載るように A C D E F B Good bye ノウハウ蓄積が あるので新規事 業も載りやすい 事業環境の変化 にも柔軟に対応 コスト削減を大義名分にする と、投資ができなくなる。 そして進化できずに死ぬ
  13. でも、ROIを考えるのは大事 • ROIを測って経営層の理解を得ることはとても大事。お金はユビキタス言語 • コスト削減では無く、どれだけ価値を生み出せたかでROIを測ろう ◦ ユーザー満足度と生産性 ▪ プラットフォームの利用者数(増加/減少) ▪

    プラットフォーム利用者のNPS(Net Promoter Score) ▪ SPACEフレームワーク ◦ 組織としての効率 ▪ サービスのリクエストから提供までの待ち時間 ▪ 新しいサービスを本番環境にデプロイするまでの時間 ▪ 新規開発者が最初のコードをコミットするまでの時間 ◦ DevOpsチームのパフォーマンス ▪ Four Keys
  14. これらの数値を金額換算 参考例: Productivity [Productivity Impact] = [Engineering hour saved] *

    [Impact per engineering hour] Stability [Stability Impact] = [Impact per minute] * [Time to restore] Efficiency [Efficiency Impact] = [Cost saving] - [Negative Impact] Risk [Risk Impact] = [RIsk in money before] - [Risk in money after]
  15. ガバナンスも大事 • 統制が取れていて、セキュアな環境を提供するという考え方自体は正しい • ただ、「統制のためにここを使いなさい」という押しつけをしても、使われない ガバナンスのために 共通基盤を使え やだ 共通基盤 •

    制限が強くやりたいことがやれない • 利用するのにいちいち申請しないといけない • 使ったところでセキュリティチェックシートは 出さないといけない
  16. ガバナンスも大事 • セキュアバイデフォルト • あるべきガードレールをプラットフォーム側で実現することによって、 開発者側はパフォーマンスを発揮できる じゃあ使 おう あるべき共通基盤 •

    開発者の業務を阻害しない形で、 きちんとセキュアに保たれている • プラットフォームチームのガードレールのも と、セルフサービスで必要な変更を行える • ここを使うことで、面倒なチェックシートは 不要になる ここを使えば、 簡単かつセキュア