役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方

by Kazuto Kusama

Slide 1

Slide 1 text

プラットフォームエンジニアが知っておくべき『プロダクト』の考え方役に立つプラットフォームを作ろう

Slide 2

Slide 2 text

KAZUTO KUSAMA @jacopen Senior Solutions Architect @VMware

Slide 3

Slide 3 text

About me ● VMware Tanzuの導入支援やプラットフォームチームづくりの支援をしています ● CloudNative Days TokyoのCo-chairを@amsy810と一緒にやっています ● Kubernetes Wakaran Tokyo #1のお手伝いをしました

Slide 4

Slide 4 text

今日話すこと ● 自分の経験を元に、k8s等のプラットフォームに関わる人たちが陥りやすい罠について話します ● より良いプラットフォームを作っていくのに役立つ、プロダクトの考え方について話します視野を広げるための、一つの考え方として知って欲しい

Slide 5

Slide 5 text

k8sに絡んでよくある話 ● 社内に新しい共通プラットフォームをつくることになった ● 『次世代基盤開発プロジェクト』『社内統合基盤開発プロジェクト』などなど ● 新しいプラットフォームだからコンテナでしょ。k8s使おう

Slide 6

Slide 6 text

k8sに絡んでよくある話 ● 社内に新しい共通プラットフォームをつくることになった ● 『次世代基盤開発プロジェクト』『社内統合基盤開発プロジェクト』などなど ● 新しいプラットフォームだからコンテナでしょ。k8s使おう明日から使える死亡フラグ図鑑  https://www.amazon.co.jp/dp/4299009878

Slide 7

Slide 7 text

社内(共通|統合|次世代)(基盤|プラットフォーム) は、高い確率で失敗する

Slide 8

Slide 8 text

ちなみに『プラットフォームを作る』とはたとえばk8sを中心とするとき ● k8sを立ち上げる

Slide 9

Slide 9 text

ちなみに『プラットフォームを作る』とはたとえばk8sを中心とするとき ● k8sを立ち上げる ● 各種リポジトリの整備 ● 認証・認可 ● ログ・メトリクスの収集 ● カスタムリソースの追加 ● CI/CD ● 既存のシステムとの繋ぎ込み他多数。利用する人たちが支障なく活用できるようにする作業=プラットフォーム開発作業割合は違えど、パブリック/プライベート、マネージド/セルフホストいずれの場合も必要

Slide 10

Slide 10 text

死亡理由その1 プラットフォームを作る理由が曖昧既存のインフラ刷新にあたって、我々も次世代基盤をアジャイルでコンテナなクラウドネイティブにすることで AIも MLもビッグデータもDevOpsでDXするぞ ⇒ 仕様を決めるだけで ○年議論した結果オワコンになって死ぬ ⇒ 手当たり次第実装してチグハグになって死ぬ

Slide 11

Slide 11 text

死亡理由その2 俺の考えた最強のプラットフォームめっちゃイケてる。クラウドネイティブっぽい ⇒　どの分野も知識が足りず『入れるだけ』になってトラブったときに死ぬ ⇒　人手が足りなくて死ぬ ⇒　運用が属人化して死ぬ Kubernetes Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security

Slide 12

Slide 12 text

死亡理由その3 プラットフォーム開発プロジェクト社運がかかったプロジェクトだ、やるぞ！プロジェクト終了後･･･みんなどこへ･･･？運用は･･･？

Slide 13

Slide 13 text

つまり目的がはっきりしないままプラットフォーム開発が始まり、次世代の御旗のもとに壮大な構想と、たくさんのリソースが投入されるも、

Slide 14

Slide 14 text

つまり目的がはっきりしないままプラットフォーム開発が始まり、次世代の御旗のもとに壮大な構想と、たくさんのリソースが投入されるも、あるべき形を議論するのにひたすら時間が使われ、スケジュールは遅延、各機能の整合性は取れないそれでもなんとか完成させたは良いが

Slide 15

Slide 15 text

つまり目的がはっきりしないままプラットフォーム開発が始まり、次世代の御旗のもとに壮大な構想と、たくさんのリソースが投入されるも、あるべき形を議論するのにひたすら時間が使われ、スケジュールは遅延、各機能の整合性は取れないそれでもなんとか完成させたは良いが開発プロジェクトは解散し、残るのは僅かな人数それでも「絶対に落とすな」と厳命され昼夜問わず対応するが

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

ってならないようにね

Slide 19

Slide 19 text

Slide 20

Slide 20 text

役に立つプラットフォーム

Slide 21

Slide 21 text

役に立つプラットフォーム誰の役に立つ？

Slide 22

Slide 22 text

誰のためのプラットフォーム？ ● プラットフォームは、顧客のためにある

Slide 23

Slide 23 text

誰のためのプラットフォーム？ ● プラットフォームは、顧客のためにある･･･ウチは社内向けなんだけど、顧客って？ ⇒ 社内向けであっても、プラットフォームを使ってくれる人は顧客です

Slide 24

Slide 24 text

顧客の役に立つプラットフォームを作る意識を持ちましょう。顧客のためのプロダクトを作るイメージを持ちましょう。

Slide 25

Slide 25 text

プロダクト？プロジェクトじゃないの？プラットフォーム構築を始める際、『プロジェクト』を発足させて取り組むケースが多い。･･･ところでプロジェクトって何？

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

問題点プロジェクトには終わりがある ⇒ プラットフォームは、作って終わりじゃない。むしろそこからが本番 SRE、Observability、Service Mesh… クラウドネイティブで語られる技術や考え方は、いずれも作った後の運用フェーズの話。プラットフォームは、顧客が居る限り続く。明確な終わりを定めづらい

Slide 28

Slide 28 text

問題点あるべき形は変わり続けるプロジェクトには明確な目標がある ⇒ でないと終わらないプラットフォームでも目的は大事。しかし･･･ ● 顧客の状況はビジネスの進捗に応じて変わる ● 技術も日々進化する ● そもそも、顧客が本当に必要としているものを最初から全て理解するのは不可能。だって人間だものプラットフォームとして、顧客のために『あるべき姿』を日々追い求めないといけない。そこに終着点は無い。

Slide 29

Slide 29 text

改めて見てみよう

Slide 30

Slide 30 text

死亡理由その1 プラットフォームを作る理由が曖昧既存のインフラ刷新にあたって、我々も次世代基盤をアジャイルでコンテナなクラウドネイティブにすることで ML もビッグデータもDevOpsでDXするぞ ⇒ 仕様を決めるだけで ○年議論した結果オワコンになって死ぬ ⇒ 手当たり次第実装してチグハグになって死ぬ

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

顧客を見ていない続ける意識が希薄

Slide 34

Slide 34 text

プロダクトとは？プロダクト（製品・サービス）顧客価値を提供

Slide 35

Slide 35 text

プラットフォームをプロダクトとして考えるプラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる必要とされる限り続く

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

はじめよう、Platform as a Product

Slide 41

Slide 41 text

先人に学ぼうプロダクトの意識を持つと、急に視野が広がる。学ぶべきプロダクトマネジメントの知見が沢山あることに気づく

Slide 42

Slide 42 text

プラットフォームのビジョン自社のビジョンを成し遂げるために働く全ての開発者が、自身のミッションに集中し、最大限の価値を発揮できるよう支えていくプラットフォームプロダクトのあり方を決める

Slide 43

Slide 43 text

プラットフォームのビジョン自社のビジョンを成し遂げるために働く全ての開発者が、自身のミッションに集中し、最大限の価値を発揮できるよう支えていくプラットフォーム Why 誰をどうしたいかペルソナペインポイント割り込みが多い仮説と検証コミュニケーションに時間がかかる手作業が多いユーザーインタビュープロダクトのあり方を決める

Slide 44

Slide 44 text

プラットフォームのビジョン自社のビジョンを成し遂げるために働く全ての開発者が、自身のミッションに集中し、最大限の価値を発揮できるよう支えていくプラットフォーム Why 誰をどうしたいかペルソナペインポイント割り込みが多い仮説と検証コミュニケーションに時間がかかる手作業が多いユーザーインタビュー What ユーザー体験開発者がセルフサービスでアプリをデプロイできる開発者のテストとデプロイに関するワークフローを自動化プラットフォームチームに依存することなく、自由にリソースを変更できる必要なときに必要なログ・メトリクスが得られるプロダクトのあり方を決める

Slide 45

Slide 45 text

ユーザーストーリーで考える What (何をやるのか) 開発者がPull Requestをマージすると、自動でステージングにリリースされるようにする Why (何故やるのか) 開発者として GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージング環境にデプロイされるようにしたい。なぜなら、デリバリーに関する全ての作業を開発者が意識することなく行いたいからだ (顧客価値)

Slide 46

Slide 46 text

バックログを作るユーザーストーリー

Slide 47

Slide 47 text

MVPを作る MVP(Minimum Viable Product) 顧客に価値があり、実行可能なシンプルなプロダクトを作っていく。最初からてんこ盛りにはしない。本当に顧客が必要なものは、すぐには分からない。

Slide 48

Slide 48 text

ステークホルダーと調整するプロダクトチーム顧客

Slide 49

Slide 49 text

ステークホルダーと調整するプロダクトチーム顧客担当役員法務セキュリティ担当インフラエンジニア UX デザイナー部門長

Slide 50

Slide 50 text

めっちゃやることあるやん･･･これ、俺ら(プラットフォームエンジニア)がやるの？

Slide 51

Slide 51 text

プロダクトマネージャーが成功の鍵これまで挙げたようなプロダクトマネジメントを行うために、専任の PM(PdM)を置きましょう。プラットフォームの成功には、PMが不可欠です。エンジニアとPMで、一体となったPlatform Teamを作ります。 Viability 経済性 Desirability ユーザー体験 Feasibility 実現可能性 Product PM Engineer

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

● プラットフォームは顧客のためにある。 ● プラットフォームは作って終わりじゃない。育てるもの。 ● 何故なら、人も技術も組織も世の中も、日々変わり続けるから。

Slide 56

Slide 56 text

● プラットフォームは顧客のためにある。 ● プラットフォームは作って終わりじゃない。育てるもの。 ● 何故なら、人も技術も組織も世の中も、日々変わり続けるから。 ● 役に立つプラットフォームのためには、プロダクトの意識が有用。 ● プラットフォームを成功に導く、プロダクトマネージャーが必要。

Slide 57

Slide 57 text

● プラットフォームは顧客のためにある。 ● プラットフォームは作って終わりじゃない。育てるもの。 ● 何故なら、人も技術も組織も世の中も、日々変わり続けるから。 ● 役に立つプラットフォームのためには、プロダクトの意識が有用。 ● プラットフォームを成功に導く、プロダクトマネージャーが必要。 ● Kubernetesというドメイン知識を得た皆さんの次の選択肢に、PMを加えてみるのはいかが？ ● Kubernetesに関わらず、今後ありとあらゆる場面で必要にされると思う

Slide 58

Slide 58 text

何から始めればいい？

Slide 59

Slide 59 text

CNDT2020のセッションを見ましょう世界に誇れるプラットフォームチームを作る https://event.cloudnativedays.jp/cndt2020/talks/29 今日のセッションと被るところも多いですが、 Platform as a Productを実践していくためのチーム作りについて語っています。

Slide 60

Slide 60 text

CNDT2020のセッションを見ましょう独りよがりのプラットフォーム https://event.cloudnativedays.jp/cndt2020/talks/30 Toriclsさんのセッション。プロダクトという表現はありませんが、全く同じ問題意識で発表されています。AWSにおける考え方は必見

Slide 61

Slide 61 text

いい書籍も揃ってきましたプロダクトマネジメントのすべて事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

Slide 62

Slide 62 text

いい書籍も揃ってきましたデザインリサーチの教科書正しいものを正しくつくるプロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

Slide 63

Slide 63 text

あ、一つ補足 ● 説明順の都合上、プロジェクト的な進め方はNGという表現に捉えられたと思いますが、正確には違います。 ● プロダクトの考えは第一に持ちつつ、そのライフサイクルの中で都度プロジェクトを走らせるのは正しいアプローチです ● 1回こっきりの構築プロジェクトで終わっちゃうのがNG プロダクトのライフサイクル ○○機能開発プロジェクト △△ プロジェクト ××計画プロジェクト ○×開発プロジェクト △×x プロジェクト

Slide 64

Slide 64 text

Thank you!