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

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

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

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

Transcript

1. 世界に誇れる プラットフォームチームを作る
2. KAZUTO KUSAMA @jacopen 2 Senior Solutions Architect @VMware Tanzu VMware Tanzu(旧Pivotal)のSolutions Architectっていう仕事をしています。 SAって会社によって指す仕事が結構違うんですが、VMwareの場合はTanzu製品を導 入済みのお客さんに支援を行う、いわゆるプロフェッショナルサービスという役割を 担っています。 その前は、通信事業者でPaaS (Platform as a Service)の開発と運用をしていまし た。こういう経緯もあり、かれこれ8年くらいプラットフォームに関わっています。
3. なぜこの話をするのか？ 仕事柄、さまざまなプラットフォームと、それを作るチームを見てき ました。 うまくいくチームもあれば、うまくいかないチームもありました。そ の違いはなんだろう？と考えてみたのです。 実際にうまくいっているチームにもヒアリングした結果、『共通項』 と言えるものが見えてきました。 なので、今回は成功するプラットフォームの秘訣を 探っていきます。
4. 前提 この発表にあたっては、VMware Pivotal Labsのメンバー、 そしてCyberagentの青山さん、LINEの西脇さんにもご協力いた だきました。ありがとうございました。
5. とあるプラットフォームチームの物語 日本でも有数のエンタープライズ企業 A社 A社に勤めるプラットフォームエンジニアである((あなた)) は 勤続10年の中堅社員。 新入社員の頃はオンプレのデータセンターで動くシステムの運用を担当。 近年はパブリッククラウドを利用することも多い。 実感が沸きやすいように、主人公のことを ((あなた)) って呼んでます。
6. A社では、DXの流れで『自社のソフトウェアやサービスを強化しビジネ スを変革しなければならない』との声が上がっていた。 そんな中、((あなた))はこのような話を耳にする。 『◦◦さん(偉い人)が、アプリ開発チームの生産性に不満を持っている』 『生産性を上げるため、コンテナを活用しろと言っている』
7. 技術に対する興味関心が強い((あなた))は、これまでも自主的にミー トアップやカンファレンスに参加していた Kubernetesは世界的にも利用が広がっており、コミュニティも活発な こと、周囲を取り巻くエコシステムもどんどん発展していることを知っ ていた
8. これまで学んで来たことを仕事で生かすチャンスだと考えた((あなた)) は、この新しい基盤作りに名乗り出る。 こうして発足した『次世代基盤構築プロジェクト』のリードエンジニアを 任された((あなた))。 早速以下のような構成を考えた。
9. Kubernetes (Managed) Image Registry CI/CD Monitoring Logging
10. Kubernetes (Managed) Image Registry CI/CD Monitoring Logging だいぶコンサバな構成だね。 せっかく予算もついているんだし、もっと挑戦してみ てもいいんじゃない？ すると、上司からこういうツッコミが。
11. Kubernetes (Managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management 確かにそうかもと思ったので、こういう構成を付け加 えてみました。
12. Kubernetes (Managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management SLAが99.5%!? 年間44時間ものダウンを許容するのか。 既存のインフラは稼働率 100%を目標にやっているんだ。こ のような品質は受け入れられない すると、偉い人からこういうツッコミをうけました。 k8sは マネージドを使う予定でしたが、その SLAは99.5%とさ れていたのです。
13. Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management 悩んだ結果、k8sは自前で運用することとしました。それに よって、自分たちの目標は99.99%と主張することができ ました。
14. Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management 全てにおいてセキュリティが第一。最低限 WAFと脆弱性ス キャナと(以下社内標準のチェックリスト ) を満たさないと、インフラとして認められません。 これでなんとかなる、と思った瞬間、社内のセキュ リティ担当からツッコミが。
15. Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security こうして、社内のだれもを説き伏せられる構成が完 成しました。
16. Platform team ((あなた)) Bさん Cさん(兼務) Dさん(兼務) Eさん(派遣) Fさん(派遣) プラットフォームチームは、こういう構成になりました。
17. 役割分担 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security メンバーそれぞれが1つないしは2つの分野を受け持つ構 成を組みました。
18. 問題発生 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security コンテナ全く分かりません。触ったこと もないです 技術力不足 さて始めよう、となった瞬間、メンバーの 1人がこう打ち明けまし た。 しかたなく、((あなた))はその人の分野もカバーします。
19. 問題発生 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security 他の業務が忙しくて、こちらに手を付 けられません 兼務問題 どうも兼務の人の進捗が悪いなと思って聞いてみたら、他の業 務が忙しすぎると･･･。 しかたなく、((あなた))はその人の分野もカバーします。
20. 問題発生 Kubernetes (self-managed) Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security 道半ばで大変申し訳ないのですが･･･ 今月末で退職します。 メンバーの離 脱 信頼を置いていたBさんが、申し訳なさそうにこう打ち明けてき ました。引き留めたかったのですが、既に次が決まっているよう で・・・。
21. 問題発生 - プロジェクトの大幅な遅延 - 深刻な人員不足
22. 得られたサポート 追加人員を 連れてきたよ。 追加人員？ 兼 務 で す 兼 務 で す 兼 務 で す セキュリティの 専門家、Zさん インフラの 専門家、Yさん ネットワークの 専門家、Xさん 進捗が芳しくないプロジェクトに、追加人員が。全員兼務 だけど、50%+50%+50%で1.5人分。辞めたBさん分以上 になると上司は言います。本当かな･･･
23. 10ヶ月後、なんとかリリース
24. しかし･･･ - 誰も使ってくれない
25. 驚くべき実態 - Kubernetesの話は突然上から降ってきた。現場としては必要性を感じていなかった - 開発の8割は外注であり、社内では仕様の策定と納品物の検収が主 - 内製部分はCIしていない。そもそもテストコードが殆ど無い - 手順書通りにコマンドを叩いてコンテナイメージを作成出来ることは分かったが、こ れまでやってきた作業がコンテナに置き換わるだけで、特にメリットを感じなかった - Kubernetesの概念が複雑で、覚えるのが苦痛だった。既存の業務で手一杯なの で、これ以上時間を割くのは困難 あまりに使ってくれないので、開発の人たちに状況を聞き に行きました。すると、驚くべき実態が明らかになったので す。
26. 爆発する運用 - 運用においてもトラブルが多発 - 十分な引き継ぎが出来ていなかったため、ブラックボックス化している部分が多数。 - 基本的な使い方を説明するだけで1日持って行かれる
27. 結局･･･ - アップデートも出来ず、Upstreamから1年以上遅れた『レガシー』なKubernetesに - 利用が広がらず、当然アプリ開発チームの生産性は変わらなかった - 結局『次世代基盤』はほとんど使われないままに、忘れ去られていく - 社員の中には『Kubernetesは使えない』という認識だけが残った
28. この物語はフィクションです たぶん
29. どこを間違ったのか？ Managedを使わず自前でいったせい？ 偉い人の思い込みのせい？ 事前の調査不足のせい？ 人員の配置の下手さのせい？ こうなってしまった理由、いろいろ考えられると思います。 上に挙げた指摘はいずれも正しい。
30. プロダクト マインドセットがなかった ただ、問題の根底にあるものを一言でいうと、 自分ならこう言います。
31. なぜ突然プロダクトの話に？ 突然『プロダクト マインドセット』と言われて 面食らったかもしれません。 プロダクトって製品とかサービスでしょ？ 今はそれを動かすためのプラットフォームの話をしているんでしょ？ そう思われるのも当然なのですが、今回お話ししたいのは、まさにそこ。 『プラットフォーム構築・運用においても、 　　　　プロダクトのマインドセットを持つべき』
32. 再掲 これまで学んで来たことを仕事で生かすチャンスだと考えた((あな た))は、この新しい基盤作りに名乗り出る。 こうして発足した『次世代基盤構築プロジェクト』のリードエンジニアを 任された((あなた))。 早速以下のような構成を考えた。 さっきの物語では『次世代基盤構築 プロジェクト』をやってい ましたね。 プロジェクトとプロダクトって何が違うんでしょう？
33. プロジェクトとは？ - 期限があるもの　終わりがあるもの - 目的や目標が明確なもの マネジメントする対象 - スコープ、資源、タイム、コスト、リスク、品質、 調達、コミュニケーション、ステークホルダー、統合 (ISO21500より) プロジェクトマネジメント = How, When を考える
34. プロダクトとは？ プロダクト 顧客 価値を提供
35. プロダクトとは？ プロダクト 顧客 価値を提供 必ず顧客がいる プロダクトがある限 り終わらない プロダクトマネジメント = WhatとWhyを突き詰め、 プロダクトの価値を最大化する プロダクトには、必ず顧客がいます。 プロダクトには、明確な終わりがありません。 続けていくのが前提です。
36. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 価値を提供 必ず顧客がいる プロダクトがある限 り終わらない プロダクトマインドセットを持つ。 つまり、プラットフォームはプロダクトで あると考えるんです。 プラットフォームには必ず使う人がいま すよね？つまり顧客です。 プラットフォームは、使う人が居る限り 維持しますよね？
37. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる プロダクトがある限 り終わらない プラットフォームを発展させる、 安定 したチーム プラットフォームを安定して維持してい くためには、安定したチームが必要で す。
38. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる プロダクトがある限 り終わらない プラットフォームを発展させる、 安定 したチーム 進化の著しい技術に追従し 顧客に新たな価値を提供する 顧客のニーズに応える プロダクトは成長し続けることで顧客に 新たな価値を提供していきます プラットフォームも進化が著しいですよ ね。新しい技術に追従していくことで、 プラットフォームを成長させなければい けません。 そのためにも、やっぱり安定したチー ムが大事です。
39. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる プロダクトがある限 り終わらない プラットフォームを発展させる、 安定 したチーム 進化の著しい技術に追従し 顧客に新たな価値を提供する 顧客のニーズに応える 顧客にプラットフォームのことを知ってもらう 新たな価値を理解してもらう 顧客の課題に寄り添う 良いものを作っても、知られなければ 使ってもらうことはできません。 顧客の課題を解決できなくては、使っ てもらうことはできません。 顧客とコミュニケーションを取っていくこ とも大事なのです。
40. 何故今まではプロダクトマインドセットが 不要だったのか？ 物理サーバーの 時代 クラウドの時代 クラウド ネイティブの 時代
41. 何故今まではプロダクトマインドセットが 不要だったのか？ 物理サーバーの 時代 クラウドの時代 クラウド ネイティブの 時代 • 物理から仮想に変わった • インフラの概念はあまり変わらない • アプリケーションの作り方も変わらない • 一度作ってしまえば、その後の運用は障害対応やセ キュリティパッチの適用などが中心 『◦◦構築プロジェクト』のような進め方が可能だった
42. 何故今まではプロダクトマインドセットが 不要だったのか？ 物理サーバーの 時代 クラウドの時代 クラウド ネイティブの 時代 • より軽量なコンテナへ • タイムスケールが日・時間から秒単位に • APIが充実し、自動化前提に • アプリケーションの作り方を変えていく必要性 • プラットフォーム自体も常に進化していく 『構築して終わり』ではない時代になった
43. 成功しているプラットフォームは、 意識的・無意識的にプロダクトとして 扱われている 今回このセッションを行うにあたって、実際に成功しているプラット フォームに携わっている、LINEの西脇さん、Cyberagentの青山 さんにインタビューをしました。 その結果、こう思ったのです。
44. はじめよう、Platform as a Product プラットフォームをプロダクトとして扱うことを、我々VMwareのメン バーはPlatform as a Productと呼んでいます。
45. 価値のある プロダクト プロダクトをマネジメントしていくということは、 価値のあるプロダクトを創っていくということです。
46. 価値のある プロダクト 仮説 検証 実装 Platform Team ただ、いきなり完璧なものは作れません。チームとして仮 説・実装・検証のサイクルを繰り返して、良いものに育てて いくんです。
47. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management 世の中にはプロダクトマネジメントの知見があります。プ ラットフォームにおいても、既にある考え方を取り入れてい きたいと思います。
48. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management まずは僕らがBalanced teamと 呼んでいる考え方から。
49. Platform Teamをつくる Viability 経済性 Desirability ユーザー体験 Feasibility 実現可能性 Product 専任のPM(PdM) Platform Champion + 専任のEngineer PM Engineer チームには、専任のProduct Manager と専任のエンジニアを置くことを推奨してい ます。 エンジニアがFeasibility, PMが Desirability, Viabilityを担います。 ※ 一般のプロダクト開発においてはUXを 専任のDesignerに任せることが多いです が、プラットフォームでは一旦PMに担わせ ます
50. Product Manager 『どうやるか』ではなく『何をすべきか』を定義する人。 フルタイムのメンバーであり、戦略の策定、機能バックログの管理、データを元にした意思決定などで、プ ロダクトの方向性を決める - “Dreamer” - 古い考えやプロセスに囚われず、『何故？』を 突き詰められる人 - “Alchemist” - たくさんの要件をシンプルなビジョンに落とし込める人 - “Influencer” - ビジネスパートナー、開発者、ITと 強いつながりを 持っている人 - “Minimalist” - 素早くプロダクトをリリースする価値を理解している人
51. いかなる時であっても兼任はNG Platform TeamのエンジニアとPMは必ず専任であること。 - プロダクトを維持し、成長させるにはチームメンバーの献身が必須 - 片手間で力を貸すやり方では機能しない - 人の稼働は算数できません これは繰り返し言いたいことなのですが、 人の稼働は算数じゃないです。50%稼働の人を3 人連れてきても1.5人分の仕事が出来るなんてこと はありません。
52. Platform Champion Platform as a Productを進める際に、Platform teamを育て、 守っていくための意思と権限を持っている人。 Platform Teamとはパートタイムで関わる。 - CxOレベルの人、もしくは近い人 - 社内起業や組織変革の実績がある人 - 会話を 『◦◦が問題だ』 から 『どうすれば良くなるのか』 に 変えられる人 - プラットフォームの価値を理解し、明確にし、社内に伝えられる人
53. Q. 社内にPMが居ないんだけど･･･ PM不足はどの組織にも共通する課題。現実問題、プロダクトマネジメントを 行ってこなかった組織がいきなりベテランPMを用意するのは困難。 必要なのは肩書きとしてのPMではなく、PMの適性を持ったチームメンバー。 エンジニアの中からPMのような振る舞いをするメンバーを選定するのも手。 技術とドメイン知識を持ったPMはとても貴重なので、それはそれで良いPMに なり得るのです。
54. Q. 専任メンバーを用意できないんだけど･･･ そのためにPlatform Championがいる。 Platform Championがチームを守り、育てるための人のアサインと意思 決定を行っていく。 権限をもつ人が居ない場合、Platform as a Productの実践は困難。
55. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management
56. Platformのビジョンを定める Vision アプリケーションの変更回数が多くなっても、ワークロードが短期間に変化しても、 一貫したスピードと品質を提供できるプラットフォーム Goal / Anti-Goal Goal • 開発者がセルフサービスでアプリをデプロイできる • 開発者のテストとデプロイに関するワークフローを自動化 • プラットフォームチームに依存することなく、自由にリソースを変更できる Non-Goal • 抽象化の無いIaaS領域の自動化 目標と成果指標の計測のため、 OKR (Objectives and Key Results) の導入もあり やらないことを決めるの 超重要 達成度合いの計測 超重要
57. ユーザーインタビューをする 価値のあるプロダクトとなるには、顧客の課題を解決できるプロダクトでなけ ればいけない。 ユーザーに直接インタビューを行い、何が必要とされているのか分析していく べし。 インタビューの際には、何が欲しいか を聞くのではなく、 何に困っているか(ペ インポイント) を中心に聞くと良い
58. ユーザーストーリーで考える What (何をやるのか) 開発者がPull Requestをマージすると、自動でステージングにリリースされるようにする Why (何故やるのか) 開発者として GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージ ング環境にデプロイされるようにしたい。 なぜなら、デリバリーに関する全ての作業を開発者が意識することなく行いたいから だ (顧客価値) チケット管理システムを導入している人 は多いと思いますが、やることをそのま まチケットにしていませんか？ そうではなく『誰にとって』『どういう価値 があるか』を書いていくのです。
59. ペルソナを作る 先ほどの例だと『開発者』と書いたが、ここはペルソナを作るべき。 ペルソナを作ることで、ターゲットのブレを抑えることができる • バックエンドエンジニア歴 3年 • 入社後1年間はフロントエンジニアをやっていたので、 jQueryに 関する知識もあり • インフラはあまり詳しくない • 毎朝9時半に出社。出来るだけ定時に帰るのが目標 • キーボードにはこだわりがあり、自作キーボードを持ち込んで いる • 愛車はホンダ • いつかはインディーズゲームで一山当てたい 佐藤琢巳 バックエンド エンジニア ユーザーストーリーをより良くするには、ペル ソナを作っていきましょう。
60. ペルソナを作る What (何をやるのか) 佐藤さんがPull Requestをマージすると、自動でステージングにリリースされるようにする Why (何故やるのか) 佐藤さんとして GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージ ング環境にデプロイされるようにしたい。 なぜなら、デリバリーに関する全ての作業を 佐藤さんが意識することなく行いたいから だ (顧客価値) さっきの例に当てはめるとこうなりますね
61. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management
62. VSMを実施する Value Stream Mapping プロダクトが顧客に届くまでに必要なプロセスと時間を可視化 一カ所だけ改善しても、他にボトルネックがあ れば出力は上がりません。 こういった可視化の分析も考えましょう
63. 優先順位を決める どのストーリーがプロダクトにとって優先なのか、PMが中心となって決めてい く。 アジャイル開発の要素を取り入れ、相対見積もりをやっていくのも良い。 (ただ、 ソフトウェア開発より見積もり精度を出しづらい･･･)
64. MVPを作る MVP(Minimum Viable Product) 顧客に価値があり、実行可能なシンプルなプロダクトを作っていく。 Cloud Nativeなプラットフォームは次々と面白い仕組みが出てくるが、欲張っ てあれこれ入れるのはNG 色々詰め込んでもプラットフォームの価値は上がりま せん。本当に必要とされているものから、 小さく作っていきましょう。
65. Q. やること多くて大変そう･･･人も少ないし、時間が割けない･･･ 必要ないもの作り込む方がよっぽど時間の無駄ですよ？ このループを早く回していくことが、結果として一番の時間の節約に繋がる 計画して 小さく作って 検証して
66. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management
67. サステナブルなチーム作りのためのXP Extreme Programming アジャイル開発の一手法。チームを作る手法としても優れている。 5つの価値 Simplicity / Communication / Feedback / Respect / Courage プラクティス - イテレーション - ペアプログラミング - みんなで所有 - 継続的インテグレーション など ここではXPの例を挙げていますが、Scrumの考え方 取り入れて実践されている場合、それはそのまま続け ていいと思います。 どちらのケースも、ただ漫然とやるのではなく、『その プラクティスにどういう意味があるか』を考えながら実 践して欲しいですけどね。
68. 価値のある プロダクト 仮説 検証 実装 User Centered Design Platform Team Balanced Team Site Reliability Engineering Extreme Programming Lean Product Management 顧客 Branding Marketing Customer success
69. Platformの名前を決める もしあなたが一般向けにプロダクトをリリースするとき、 こういう名前を付けますか？ LINEみたいなサービス作って『次世代メッセージングシステム』って名 前にしますか？しないですよね。
70. Platformの名前を決める プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる 顧客にプラットフォームのことを知ってもらう 新たな価値を理解してもらう 顧客の課題に寄り添う プラットフォームに名前を付けるのは遊びではない。 マーケティング・ブランディングとして 絶対に必要 たとえ社内向けであっても、必ず顧客が居るわけで す。ならば、知ってもらうためにはプラットフォームの 名前、重要です。 チームメンバーとしても、名前のあるなしで身の入り 方が結構変わります。
71. 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という名前がついています。
72. Q. プラットフォームに名前を付けるの、気が引けるんだけど･･･ 気が引ける理由を考えてみよう - 偉い人にどう説明すればいいのか分からない - 余計な議論になってしまいそうで怖い - 社内にそういう文化が無くて浮きそう ⇒ 気にする先が内部に向きすぎかも。常に顧客のことを考えよう。 また、こういう意思決定のためにPlatform Championは重要。
73. Enablementの支援をしていく プラットフォームが出来上がっても、それを活用できなければ意味が無 い。 - ドキュメント - ワークショップ - ヘルプデスク などを整備していき、顧客がスムーズにプラットフォームを使える仕組 みを整えていく。
74. チームを分けていく おそらくEnablementに注力し始めるころから、1チームではカバーしきれな くなってくる。 しかしチームサイズを大きくするのは NG。”Two-pizza rule” 2枚のピザを 分け合えるくらいの人数)にするのが最適。 つまり、徐々にチームを責任ごとに分けていく必要性が出てくる
75. Team Topologies https://teamtopologies.com/ Platform team Complicated Subsystem Team Enabling Team Stream-aligned Team Team Topologiesっていう考え方があります。今回のセッ ションでは詳しく説明出来ませんでしたが、分け方の指標にな るかなと。
76. Team Topologies Platform team Stream-aligned team Stream-aligned team Stream-aligned team Stream-aligned team 支援する 一緒にやる サービスとして 提供する Enabling team Complicated subsystem team チーム間のコラボレーションも、いくつかのパターンがありま す。
77. まとめ • たとえ社内向けであっても、プラットフォームはプロダクトとして 扱っていくべき • 良いプロダクトとは、顧客の課題を解決できるもの • 良いプロダクトにしていくために、プロダクトマネジメントの考え方 を実践していこう
78. 『世界に誇れるプラットフォームチーム』って何だろう？ めっちゃ高度で大規模なプラットフォームを運営しているチー ム？ どれだけ最先端でも、どれだけ大規模でも、自分の顧客に価値 を提供できていなければ、良いプラットフォームとは言えない。今 回、それを学びましたね。 自分の顧客に、一番価値を提供できるプラットフォームを作れる チーム。それが、誇れるチームなんだと思います。
79. 併せて読みたい 独りよがりのプラットフォーム / 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