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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Kubernetes
(Managed)
Image Registry CI/CD
Monitoring
Logging

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

Kazuto Kusama

More Decks by Kazuto Kusama

Other Decks in Technology

Featured

Transcript