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

by Kazuto Kusama

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

なぜこの話をするのか？仕事柄、さまざまなプラットフォームと、それを作るチームを見てきました。うまくいくチームもあれば、うまくいかないチームもありました。その違いはなんだろう？と考えてみたのです。実際にうまくいっているチームにもヒアリングした結果、『共通項』と言えるものが見えてきました。なので、今回は成功するプラットフォームの秘訣を探っていきます。

Slide 4

Slide 4 text

前提この発表にあたっては、VMware Pivotal Labsのメンバー、そしてCyberagentの青山さん、LINEの西脇さんにもご協力いただきました。ありがとうございました。

Slide 5

Slide 5 text

とあるプラットフォームチームの物語日本でも有数のエンタープライズ企業 A社 A社に勤めるプラットフォームエンジニアである((あなた)) は勤続10年の中堅社員。新入社員の頃はオンプレのデータセンターで動くシステムの運用を担当。近年はパブリッククラウドを利用することも多い。実感が沸きやすいように、主人公のことを ((あなた)) って呼んでます。

Slide 6

Slide 6 text

A社では、DXの流れで『自社のソフトウェアやサービスを強化しビジネスを変革しなければならない』との声が上がっていた。そんな中、((あなた))はこのような話を耳にする。『○○さん(偉い人)が、アプリ開発チームの生産性に不満を持っている』『生産性を上げるため、コンテナを活用しろと言っている』

Slide 7

Slide 7 text

技術に対する興味関心が強い((あなた))は、これまでも自主的にミートアップやカンファレンスに参加していた Kubernetesは世界的にも利用が広がっており、コミュニティも活発なこと、周囲を取り巻くエコシステムもどんどん発展していることを知っていた

Slide 8

Slide 8 text

これまで学んで来たことを仕事で生かすチャンスだと考えた((あなた)) は、この新しい基盤作りに名乗り出る。こうして発足した『次世代基盤構築プロジェクト』のリードエンジニアを任された((あなた))。早速以下のような構成を考えた。

Slide 9

Slide 9 text

Kubernetes (Managed) Image Registry CI/CD Monitoring Logging

Slide 10

Slide 10 text

Kubernetes (Managed) Image Registry CI/CD Monitoring Logging だいぶコンサバな構成だね。せっかく予算もついているんだし、もっと挑戦してみてもいいんじゃない？すると、上司からこういうツッコミが。

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Platform team ((あなた)) Bさん Cさん(兼務) Dさん(兼務) Eさん(派遣) Fさん(派遣) プラットフォームチームは、こういう構成になりました。

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

問題発生 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security 道半ばで大変申し訳ないのですが･･･今月末で退職します。メンバーの離脱信頼を置いていたBさんが、申し訳なさそうにこう打ち明けてきました。引き留めたかったのですが、既に次が決まっているようで・・・。

Slide 21

Slide 21 text

問題発生 - プロジェクトの大幅な遅延 - 深刻な人員不足

Slide 22

Slide 22 text

得られたサポート追加人員を連れてきたよ。追加人員？兼務です兼務です兼務ですセキュリティの専門家、Zさんインフラの専門家、Yさんネットワークの専門家、Xさん進捗が芳しくないプロジェクトに、追加人員が。全員兼務だけど、50%+50%+50%で1.5人分。辞めたBさん分以上になると上司は言います。本当かな･･･

Slide 23

Slide 23 text

10ヶ月後、なんとかリリース

Slide 24

Slide 24 text

しかし･･･ - 誰も使ってくれない

Slide 25

Slide 25 text

驚くべき実態 - Kubernetesの話は突然上から降ってきた。現場としては必要性を感じていなかった - 開発の8割は外注であり、社内では仕様の策定と納品物の検収が主 - 内製部分はCIしていない。そもそもテストコードが殆ど無い - 手順書通りにコマンドを叩いてコンテナイメージを作成出来ることは分かったが、これまでやってきた作業がコンテナに置き換わるだけで、特にメリットを感じなかった - Kubernetesの概念が複雑で、覚えるのが苦痛だった。既存の業務で手一杯なので、これ以上時間を割くのは困難あまりに使ってくれないので、開発の人たちに状況を聞きに行きました。すると、驚くべき実態が明らかになったのです。

Slide 26

Slide 26 text

爆発する運用 - 運用においてもトラブルが多発 - 十分な引き継ぎが出来ていなかったため、ブラックボックス化している部分が多数。 - 基本的な使い方を説明するだけで1日持って行かれる

Slide 27

Slide 27 text

結局･･･ - アップデートも出来ず、Upstreamから1年以上遅れた『レガシー』なKubernetesに - 利用が広がらず、当然アプリ開発チームの生産性は変わらなかった - 結局『次世代基盤』はほとんど使われないままに、忘れ去られていく - 社員の中には『Kubernetesは使えない』という認識だけが残った

Slide 28

Slide 28 text

この物語はフィクションですたぶん

Slide 29

Slide 29 text

どこを間違ったのか？ Managedを使わず自前でいったせい？偉い人の思い込みのせい？事前の調査不足のせい？人員の配置の下手さのせい？こうなってしまった理由、いろいろ考えられると思います。上に挙げた指摘はいずれも正しい。

Slide 30

Slide 30 text

プロダクトマインドセットがなかったただ、問題の根底にあるものを一言でいうと、自分ならこう言います。

Slide 31

Slide 31 text

なぜ突然プロダクトの話に？突然『プロダクトマインドセット』と言われて面食らったかもしれません。プロダクトって製品とかサービスでしょ？今はそれを動かすためのプラットフォームの話をしているんでしょ？そう思われるのも当然なのですが、今回お話ししたいのは、まさにそこ。『プラットフォーム構築・運用においても、　　　　プロダクトのマインドセットを持つべき』

Slide 32

Slide 32 text

再掲これまで学んで来たことを仕事で生かすチャンスだと考えた((あなた))は、この新しい基盤作りに名乗り出る。こうして発足した『次世代基盤構築プロジェクト』のリードエンジニアを任された((あなた))。早速以下のような構成を考えた。さっきの物語では『次世代基盤構築プロジェクト』をやっていましたね。プロジェクトとプロダクトって何が違うんでしょう？

Slide 33

Slide 33 text

プロジェクトとは？ - 期限があるもの　終わりがあるもの - 目的や目標が明確なものマネジメントする対象 - スコープ、資源、タイム、コスト、リスク、品質、調達、コミュニケーション、ステークホルダー、統合 (ISO21500より) プロジェクトマネジメント = How, When を考える

Slide 34

Slide 34 text

プロダクトとは？プロダクト顧客価値を提供

Slide 35

Slide 35 text

プロダクトとは？プロダクト顧客価値を提供必ず顧客がいるプロダクトがある限り終わらないプロダクトマネジメント = WhatとWhyを突き詰め、プロダクトの価値を最大化するプロダクトには、必ず顧客がいます。プロダクトには、明確な終わりがありません。続けていくのが前提です。

Slide 36

Slide 36 text

プラットフォームをプロダクトとして考えるプラットフォーム (プロダクト) 開発者 (顧客) 価値を提供必ず顧客がいるプロダクトがある限り終わらないプロダクトマインドセットを持つ。つまり、プラットフォームはプロダクトであると考えるんです。プラットフォームには必ず使う人がいますよね？つまり顧客です。プラットフォームは、使う人が居る限り維持しますよね？

Slide 37

Slide 37 text

プラットフォームをプロダクトとして考えるプラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいるプロダクトがある限り終わらないプラットフォームを発展させる、安定したチームプラットフォームを安定して維持していくためには、安定したチームが必要です。

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

プラットフォームをプロダクトとして考えるプラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいるプロダクトがある限り終わらないプラットフォームを発展させる、安定したチーム進化の著しい技術に追従し顧客に新たな価値を提供する顧客のニーズに応える顧客にプラットフォームのことを知ってもらう新たな価値を理解してもらう顧客の課題に寄り添う良いものを作っても、知られなければ使ってもらうことはできません。顧客の課題を解決できなくては、使ってもらうことはできません。顧客とコミュニケーションを取っていくことも大事なのです。

Slide 40

Slide 40 text

何故今まではプロダクトマインドセットが不要だったのか？物理サーバーの時代クラウドの時代クラウドネイティブの時代

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

何故今まではプロダクトマインドセットが不要だったのか？物理サーバーの時代クラウドの時代クラウドネイティブの時代 ● より軽量なコンテナへ ● タイムスケールが日・時間から秒単位に ● APIが充実し、自動化前提に ● アプリケーションの作り方を変えていく必要性 ● プラットフォーム自体も常に進化していく『構築して終わり』ではない時代になった

Slide 43

Slide 43 text

成功しているプラットフォームは、意識的・無意識的にプロダクトとして扱われている今回このセッションを行うにあたって、実際に成功しているプラットフォームに携わっている、LINEの西脇さん、Cyberagentの青山さんにインタビューをしました。その結果、こう思ったのです。

Slide 44

Slide 44 text

はじめよう、Platform as a Product プラットフォームをプロダクトとして扱うことを、我々VMwareのメンバーはPlatform as a Productと呼んでいます。

Slide 45

Slide 45 text

価値のあるプロダクトプロダクトをマネジメントしていくということは、価値のあるプロダクトを創っていくということです。

Slide 46

Slide 46 text

価値のあるプロダクト仮説検証実装 Platform Team ただ、いきなり完璧なものは作れません。チームとして仮説・実装・検証のサイクルを繰り返して、良いものに育てていくんです。

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

価値のあるプロダクト仮説検証実装 User Centered Design Platform Team Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management まずは僕らがBalanced teamと呼んでいる考え方から。

Slide 49

Slide 49 text

Platform Teamをつくる Viability 経済性 Desirability ユーザー体験 Feasibility 実現可能性 Product 専任のPM(PdM) Platform Champion + 専任のEngineer PM Engineer チームには、専任のProduct Manager と専任のエンジニアを置くことを推奨しています。エンジニアがFeasibility, PMが Desirability, Viabilityを担います。 ※ 一般のプロダクト開発においてはUXを専任のDesignerに任せることが多いですが、プラットフォームでは一旦PMに担わせます

Slide 50

Slide 50 text

Product Manager 『どうやるか』ではなく『何をすべきか』を定義する人。フルタイムのメンバーであり、戦略の策定、機能バックログの管理、データを元にした意思決定などで、プロダクトの方向性を決める - “Dreamer” - 古い考えやプロセスに囚われず、『何故？』を突き詰められる人 - “Alchemist” - たくさんの要件をシンプルなビジョンに落とし込める人 - “Inﬂuencer” - ビジネスパートナー、開発者、ITと強いつながりを持っている人 - “Minimalist” - 素早くプロダクトをリリースする価値を理解している人

Slide 51

Slide 51 text

いかなる時であっても兼任はNG Platform TeamのエンジニアとPMは必ず専任であること。 - プロダクトを維持し、成長させるにはチームメンバーの献身が必須 - 片手間で力を貸すやり方では機能しない - 人の稼働は算数できませんこれは繰り返し言いたいことなのですが、人の稼働は算数じゃないです。50%稼働の人を3 人連れてきても1.5人分の仕事が出来るなんてことはありません。

Slide 52

Slide 52 text

Platform Champion Platform as a Productを進める際に、Platform teamを育て、守っていくための意思と権限を持っている人。 Platform Teamとはパートタイムで関わる。 - CxOレベルの人、もしくは近い人 - 社内起業や組織変革の実績がある人 - 会話を『○○が問題だ』から『どうすれば良くなるのか』に変えられる人 - プラットフォームの価値を理解し、明確にし、社内に伝えられる人

Slide 53

Slide 53 text

Q. 社内にPMが居ないんだけど･･･ PM不足はどの組織にも共通する課題。現実問題、プロダクトマネジメントを行ってこなかった組織がいきなりベテランPMを用意するのは困難。必要なのは肩書きとしてのPMではなく、PMの適性を持ったチームメンバー。エンジニアの中からPMのような振る舞いをするメンバーを選定するのも手。技術とドメイン知識を持ったPMはとても貴重なので、それはそれで良いPMになり得るのです。

Slide 54

Slide 54 text

Q. 専任メンバーを用意できないんだけど･･･そのためにPlatform Championがいる。 Platform Championがチームを守り、育てるための人のアサインと意思決定を行っていく。権限をもつ人が居ない場合、Platform as a Productの実践は困難。

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Platformのビジョンを定める Vision アプリケーションの変更回数が多くなっても、ワークロードが短期間に変化しても、一貫したスピードと品質を提供できるプラットフォーム Goal / Anti-Goal Goal ● 開発者がセルフサービスでアプリをデプロイできる ● 開発者のテストとデプロイに関するワークフローを自動化 ● プラットフォームチームに依存することなく、自由にリソースを変更できる Non-Goal ● 抽象化の無いIaaS領域の自動化目標と成果指標の計測のため、 OKR (Objectives and Key Results) の導入もありやらないことを決めるの超重要達成度合いの計測超重要

Slide 57

Slide 57 text

ユーザーインタビューをする価値のあるプロダクトとなるには、顧客の課題を解決できるプロダクトでなければいけない。ユーザーに直接インタビューを行い、何が必要とされているのか分析していくべし。インタビューの際には、何が欲しいかを聞くのではなく、何に困っているか(ペインポイント) を中心に聞くと良い

Slide 58

Slide 58 text

ユーザーストーリーで考える What (何をやるのか) 開発者がPull Requestをマージすると、自動でステージングにリリースされるようにする Why (何故やるのか) 開発者として GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージング環境にデプロイされるようにしたい。なぜなら、デリバリーに関する全ての作業を開発者が意識することなく行いたいからだ (顧客価値) チケット管理システムを導入している人は多いと思いますが、やることをそのままチケットにしていませんか？そうではなく『誰にとって』『どういう価値があるか』を書いていくのです。

Slide 59

Slide 59 text

ペルソナを作る先ほどの例だと『開発者』と書いたが、ここはペルソナを作るべき。ペルソナを作ることで、ターゲットのブレを抑えることができる ● バックエンドエンジニア歴 3年 ● 入社後1年間はフロントエンジニアをやっていたので、 jQueryに関する知識もあり ● インフラはあまり詳しくない ● 毎朝9時半に出社。出来るだけ定時に帰るのが目標 ● キーボードにはこだわりがあり、自作キーボードを持ち込んでいる ● 愛車はホンダ ● いつかはインディーズゲームで一山当てたい佐藤琢巳バックエンドエンジニアユーザーストーリーをより良くするには、ペルソナを作っていきましょう。

Slide 60

Slide 60 text

ペルソナを作る What (何をやるのか) 佐藤さんがPull Requestをマージすると、自動でステージングにリリースされるようにする Why (何故やるのか) 佐藤さんとして GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージング環境にデプロイされるようにしたい。なぜなら、デリバリーに関する全ての作業を佐藤さんが意識することなく行いたいからだ (顧客価値) さっきの例に当てはめるとこうなりますね

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

VSMを実施する Value Stream Mapping プロダクトが顧客に届くまでに必要なプロセスと時間を可視化一カ所だけ改善しても、他にボトルネックがあれば出力は上がりません。こういった可視化の分析も考えましょう

Slide 63

Slide 63 text

優先順位を決めるどのストーリーがプロダクトにとって優先なのか、PMが中心となって決めていく。アジャイル開発の要素を取り入れ、相対見積もりをやっていくのも良い。 (ただ、ソフトウェア開発より見積もり精度を出しづらい･･･)

Slide 64

Slide 64 text

MVPを作る MVP(Minimum Viable Product) 顧客に価値があり、実行可能なシンプルなプロダクトを作っていく。 Cloud Nativeなプラットフォームは次々と面白い仕組みが出てくるが、欲張ってあれこれ入れるのはNG 色々詰め込んでもプラットフォームの価値は上がりません。本当に必要とされているものから、小さく作っていきましょう。

Slide 65

Slide 65 text

Q. やること多くて大変そう･･･人も少ないし、時間が割けない･･･必要ないもの作り込む方がよっぽど時間の無駄ですよ？このループを早く回していくことが、結果として一番の時間の節約に繋がる計画して小さく作って検証して

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

サステナブルなチーム作りのためのXP Extreme Programming アジャイル開発の一手法。チームを作る手法としても優れている。 5つの価値 Simplicity / Communication / Feedback / Respect / Courage プラクティス - イテレーション - ペアプログラミング - みんなで所有 - 継続的インテグレーションなどここではXPの例を挙げていますが、Scrumの考え方取り入れて実践されている場合、それはそのまま続けていいと思います。どちらのケースも、ただ漫然とやるのではなく、『そのプラクティスにどういう意味があるか』を考えながら実践して欲しいですけどね。

Slide 68

Slide 68 text

価値のあるプロダクト仮説検証実装 User Centered Design Platform Team Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management 顧客 Branding Marketing Customer success

Slide 69

Slide 69 text

Platformの名前を決めるもしあなたが一般向けにプロダクトをリリースするとき、こういう名前を付けますか？ LINEみたいなサービス作って『次世代メッセージングシステム』って名前にしますか？しないですよね。

Slide 70

Slide 70 text

Platformの名前を決めるプラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる顧客にプラットフォームのことを知ってもらう新たな価値を理解してもらう顧客の課題に寄り添うプラットフォームに名前を付けるのは遊びではない。マーケティング・ブランディングとして絶対に必要たとえ社内向けであっても、必ず顧客が居るわけです。ならば、知ってもらうためにはプラットフォームの名前、重要です。チームメンバーとしても、名前のあるなしで身の入り方が結構変わります。

Slide 71

Slide 71 text

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という名前がついています。

Slide 72

Slide 72 text

Q. プラットフォームに名前を付けるの、気が引けるんだけど･･･気が引ける理由を考えてみよう - 偉い人にどう説明すればいいのか分からない - 余計な議論になってしまいそうで怖い - 社内にそういう文化が無くて浮きそう ⇒ 気にする先が内部に向きすぎかも。常に顧客のことを考えよう。また、こういう意思決定のためにPlatform Championは重要。

Slide 73

Slide 73 text

Enablementの支援をしていくプラットフォームが出来上がっても、それを活用できなければ意味が無い。 - ドキュメント - ワークショップ - ヘルプデスクなどを整備していき、顧客がスムーズにプラットフォームを使える仕組みを整えていく。

Slide 74

Slide 74 text

チームを分けていくおそらくEnablementに注力し始めるころから、1チームではカバーしきれなくなってくる。しかしチームサイズを大きくするのは NG。”Two-pizza rule” 2枚のピザを分け合えるくらいの人数)にするのが最適。つまり、徐々にチームを責任ごとに分けていく必要性が出てくる

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

Team Topologies Platform team Stream-aligned team Stream-aligned team Stream-aligned team Stream-aligned team 支援する一緒にやるサービスとして提供する Enabling team Complicated subsystem team チーム間のコラボレーションも、いくつかのパターンがあります。

Slide 77

Slide 77 text

まとめ ● たとえ社内向けであっても、プラットフォームはプロダクトとして扱っていくべき ● 良いプロダクトとは、顧客の課題を解決できるもの ● 良いプロダクトにしていくために、プロダクトマネジメントの考え方を実践していこう

Slide 78

Slide 78 text

『世界に誇れるプラットフォームチーム』って何だろう？めっちゃ高度で大規模なプラットフォームを運営しているチーム？どれだけ最先端でも、どれだけ大規模でも、自分の顧客に価値を提供できていなければ、良いプラットフォームとは言えない。今回、それを学びましたね。自分の顧客に、一番価値を提供できるプラットフォームを作れるチーム。それが、誇れるチームなんだと思います。

Slide 79

Slide 79 text

併せて読みたい独りよがりのプラットフォーム / 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