Upgrade to Pro — share decks privately, control downloads, hide ads and more …

世界に誇れるプラットフォームチームをつくる

Kazuto Kusama
September 14, 2020

 世界に誇れるプラットフォームチームをつくる

#CNDT2020 で発表した資料+αです。動画アーカイブは以下のページからどうぞ。
http://event.cloudnativedays.jp/cndt2020/talks/29

プラットフォームは、プロダクトとして考えましょうという話をしています。

Toriさんの発表『独りよがりのプラットフォーム』
https://speakerdeck.com/toricls/for-whom-that-platform-runs
も、同じメッセージを違う表現で伝えてくれているので、併せて読むことをお勧めします。

Kazuto Kusama

September 14, 2020
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. KAZUTO KUSAMA @jacopen 2 Senior Solutions Architect @VMware Tanzu VMware

    Tanzu(旧Pivotal)のSolutions Architectっていう仕事をしています。 SAって会社によって指す仕事が結構違うんですが、VMwareの場合はTanzu製品を導 入済みのお客さんに支援を行う、いわゆるプロフェッショナルサービスという役割を 担っています。 その前は、通信事業者でPaaS (Platform as a Service)の開発と運用をしていまし た。こういう経緯もあり、かれこれ8年くらいプラットフォームに関わっています。
  2. Kubernetes (Managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service

    Mesh Secret Management 確かにそうかもと思ったので、こういう構成を付け加 えてみました。
  3. Kubernetes (Managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service

    Mesh Secret Management SLAが99.5%!? 年間44時間ものダウンを許容するのか。 既存のインフラは稼働率 100%を目標にやっているんだ。こ のような品質は受け入れられない すると、偉い人からこういうツッコミをうけました。 k8sは マネージドを使う予定でしたが、その SLAは99.5%とさ れていたのです。
  4. Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service

    Mesh Secret Management 悩んだ結果、k8sは自前で運用することとしました。それに よって、自分たちの目標は99.99%と主張することができ ました。
  5. Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service

    Mesh Secret Management 全てにおいてセキュリティが第一。最低限 WAFと脆弱性ス キャナと(以下社内標準のチェックリスト ) を満たさないと、インフラとして認められません。 これでなんとかなる、と思った瞬間、社内のセキュ リティ担当からツッコミが。
  6. Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service

    Mesh Secret Management Security こうして、社内のだれもを説き伏せられる構成が完 成しました。
  7. 役割分担 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing

    Service Mesh Secret Management Security メンバーそれぞれが1つないしは2つの分野を受け持つ構 成を組みました。
  8. 問題発生 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing

    Service Mesh Secret Management Security コンテナ全く分かりません。触ったこと もないです 技術力不足 さて始めよう、となった瞬間、メンバーの 1人がこう打ち明けまし た。 しかたなく、((あなた))はその人の分野もカバーします。
  9. 問題発生 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing

    Service Mesh Secret Management Security 他の業務が忙しくて、こちらに手を付 けられません 兼務問題 どうも兼務の人の進捗が悪いなと思って聞いてみたら、他の業 務が忙しすぎると・・・。 しかたなく、((あなた))はその人の分野もカバーします。
  10. 問題発生 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing

    Service Mesh Secret Management Security 道半ばで大変申し訳ないのですが・・・ 今月末で退職します。 メンバーの離 脱 信頼を置いていたBさんが、申し訳なさそうにこう打ち明けてき ました。引き留めたかったのですが、既に次が決まっているよう で・・・。
  11. 得られたサポート 追加人員を 連れてきたよ。 追加人員? 兼 務 で す 兼 務

    で す 兼 務 で す セキュリティの 専門家、Zさん インフラの 専門家、Yさん ネットワークの 専門家、Xさん 進捗が芳しくないプロジェクトに、追加人員が。全員兼務 だけど、50%+50%+50%で1.5人分。辞めたBさん分以上 になると上司は言います。本当かな・・・
  12. プロダクトとは? プロダクト 顧客 価値を提供 必ず顧客がいる プロダクトがある限 り終わらない プロダクトマネジメント = WhatとWhyを突き詰め、

    プロダクトの価値を最大化する プロダクトには、必ず顧客がいます。 プロダクトには、明確な終わりがありません。 続けていくのが前提です。
  13. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 価値を提供 必ず顧客がいる プロダクトがある限 り終わらない プロダクトマインドセットを持つ。

    つまり、プラットフォームはプロダクトで あると考えるんです。 プラットフォームには必ず使う人がいま すよね?つまり顧客です。 プラットフォームは、使う人が居る限り 維持しますよね?
  14. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる プロダクトがある限 り終わらない プラットフォームを発展させる、 安定

    したチーム 進化の著しい技術に追従し 顧客に新たな価値を提供する 顧客のニーズに応える プロダクトは成長し続けることで顧客に 新たな価値を提供していきます プラットフォームも進化が著しいですよ ね。新しい技術に追従していくことで、 プラットフォームを成長させなければい けません。 そのためにも、やっぱり安定したチー ムが大事です。
  15. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる プロダクトがある限 り終わらない プラットフォームを発展させる、 安定

    したチーム 進化の著しい技術に追従し 顧客に新たな価値を提供する 顧客のニーズに応える 顧客にプラットフォームのことを知ってもらう 新たな価値を理解してもらう 顧客の課題に寄り添う 良いものを作っても、知られなければ 使ってもらうことはできません。 顧客の課題を解決できなくては、使っ てもらうことはできません。 顧客とコミュニケーションを取っていくこ とも大事なのです。
  16. 何故今まではプロダクトマインドセットが 不要だったのか? 物理サーバーの 時代 クラウドの時代 クラウド ネイティブの 時代 • 物理から仮想に変わった

    • インフラの概念はあまり変わらない • アプリケーションの作り方も変わらない • 一度作ってしまえば、その後の運用は障害対応やセ キュリティパッチの適用などが中心 『◦◦構築プロジェクト』のような進め方が可能だった
  17. 何故今まではプロダクトマインドセットが 不要だったのか? 物理サーバーの 時代 クラウドの時代 クラウド ネイティブの 時代 • より軽量なコンテナへ

    • タイムスケールが日・時間から秒単位に • APIが充実し、自動化前提に • アプリケーションの作り方を変えていく必要性 • プラットフォーム自体も常に進化していく 『構築して終わり』ではない時代になった
  18. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team

    Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management 世の中にはプロダクトマネジメントの知見があります。プ ラットフォームにおいても、既にある考え方を取り入れてい きたいと思います。
  19. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team

    Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management まずは僕らがBalanced teamと 呼んでいる考え方から。
  20. Platform Teamをつくる Viability 経済性 Desirability ユーザー体験 Feasibility 実現可能性 Product 専任のPM(PdM)

    Platform Champion + 専任のEngineer PM Engineer チームには、専任のProduct Manager と専任のエンジニアを置くことを推奨してい ます。 エンジニアがFeasibility, PMが Desirability, Viabilityを担います。 ※ 一般のプロダクト開発においてはUXを 専任のDesignerに任せることが多いです が、プラットフォームでは一旦PMに担わせ ます
  21. Product Manager 『どうやるか』ではなく『何をすべきか』を定義する人。 フルタイムのメンバーであり、戦略の策定、機能バックログの管理、データを元にした意思決定などで、プ ロダクトの方向性を決める - “Dreamer” - 古い考えやプロセスに囚われず、『何故?』を 突き詰められる人

    - “Alchemist” - たくさんの要件をシンプルなビジョンに落とし込める人 - “Influencer” - ビジネスパートナー、開発者、ITと 強いつながりを 持っている人 - “Minimalist” - 素早くプロダクトをリリースする価値を理解している人
  22. Platform Champion Platform as a Productを進める際に、Platform teamを育て、 守っていくための意思と権限を持っている人。 Platform Teamとはパートタイムで関わる。

    - CxOレベルの人、もしくは近い人 - 社内起業や組織変革の実績がある人 - 会話を 『◦◦が問題だ』 から 『どうすれば良くなるのか』 に 変えられる人 - プラットフォームの価値を理解し、明確にし、社内に伝えられる人
  23. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team

    Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management
  24. Platformのビジョンを定める Vision アプリケーションの変更回数が多くなっても、ワークロードが短期間に変化しても、 一貫したスピードと品質を提供できるプラットフォーム Goal / Anti-Goal Goal • 開発者がセルフサービスでアプリをデプロイできる

    • 開発者のテストとデプロイに関するワークフローを自動化 • プラットフォームチームに依存することなく、自由にリソースを変更できる Non-Goal • 抽象化の無いIaaS領域の自動化 目標と成果指標の計測のため、 OKR (Objectives and Key Results) の導入もあり やらないことを決めるの 超重要 達成度合いの計測 超重要
  25. ユーザーストーリーで考える What (何をやるのか) 開発者がPull Requestをマージすると、自動でステージングにリリースされるようにする Why (何故やるのか) 開発者として GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージ

    ング環境にデプロイされるようにしたい。 なぜなら、デリバリーに関する全ての作業を開発者が意識することなく行いたいから だ (顧客価値) チケット管理システムを導入している人 は多いと思いますが、やることをそのま まチケットにしていませんか? そうではなく『誰にとって』『どういう価値 があるか』を書いていくのです。
  26. ペルソナを作る 先ほどの例だと『開発者』と書いたが、ここはペルソナを作るべき。 ペルソナを作ることで、ターゲットのブレを抑えることができる • バックエンドエンジニア歴 3年 • 入社後1年間はフロントエンジニアをやっていたので、 jQueryに 関する知識もあり

    • インフラはあまり詳しくない • 毎朝9時半に出社。出来るだけ定時に帰るのが目標 • キーボードにはこだわりがあり、自作キーボードを持ち込んで いる • 愛車はホンダ • いつかはインディーズゲームで一山当てたい 佐藤琢巳 バックエンド エンジニア ユーザーストーリーをより良くするには、ペル ソナを作っていきましょう。
  27. ペルソナを作る What (何をやるのか) 佐藤さんがPull Requestをマージすると、自動でステージングにリリースされるようにする Why (何故やるのか) 佐藤さんとして GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージ

    ング環境にデプロイされるようにしたい。 なぜなら、デリバリーに関する全ての作業を 佐藤さんが意識することなく行いたいから だ (顧客価値) さっきの例に当てはめるとこうなりますね
  28. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team

    Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management
  29. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team

    Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management
  30. サステナブルなチーム作りのためのXP Extreme Programming アジャイル開発の一手法。チームを作る手法としても優れている。 5つの価値 Simplicity / Communication / Feedback

    / Respect / Courage プラクティス - イテレーション - ペアプログラミング - みんなで所有 - 継続的インテグレーション など ここではXPの例を挙げていますが、Scrumの考え方 取り入れて実践されている場合、それはそのまま続け ていいと思います。 どちらのケースも、ただ漫然とやるのではなく、『その プラクティスにどういう意味があるか』を考えながら実 践して欲しいですけどね。
  31. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team

    Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management 顧客 Branding Marketing Customer success
  32. Platformの名前を決める プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる 顧客にプラットフォームのことを知ってもらう 新たな価値を理解してもらう 顧客の課題に寄り添う プラットフォームに名前を付けるのは遊びではない。

    マーケティング・ブランディングとして 絶対に必要 たとえ社内向けであっても、必ず顧客が居るわけで す。ならば、知ってもらうためにはプラットフォームの 名前、重要です。 チームメンバーとしても、名前のあるなしで身の入り 方が結構変わります。
  33. GKE 互換のオンプレコンテナ基盤 AKE (Adtech Container Engine) 誕生秘話とアーキテクチャ完全公開! https://developers.cyberagent.co.jp/blog/archives/12058/ 【Team &

    Project】OpenStackとKubernetesを用いたVerda Platformを開発しているチームを紹介します https://engineering.linecorp.com/ja/blog/verda-platform-team/ Cyberagentの青山さんのところではAKE、LINE西脇さん のところではVerdaという名前がついています。
  34. Team Topologies https://teamtopologies.com/ Platform team Complicated Subsystem Team Enabling Team

    Stream-aligned Team Team Topologiesっていう考え方があります。今回のセッ ションでは詳しく説明出来ませんでしたが、分け方の指標にな るかなと。
  35. Team Topologies Platform team Stream-aligned team Stream-aligned team Stream-aligned team

    Stream-aligned team 支援する 一緒にやる サービスとして 提供する Enabling team Complicated subsystem team チーム間のコラボレーションも、いくつかのパターンがありま す。
  36. 併せて読みたい 独りよがりのプラットフォーム / For Whom that Platform Runs https://speakerdeck.com/toricls/for-whom-that-platform-runs Team

    Topologiesにみるモダンな組織編成の理論と実際 https://speakerdeck.com/toricls/for-whom-that-platform-runs 効果を出すためのクラウドネイティブ DevOpsの道のり https://www.slideshare.net/mosuke5/devops-238358794