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

Kubernetes Novice #10で発表した資料です。
登壇の動画はこちらからどうぞ。 https://youtu.be/uVKo28HXK2I?t=5718

資料内で紹介しているリンクはこちら
世界に誇れるプラットフォームチームをつくる https://event.cloudnativedays.jp/cndt2020/talks/29

独りよがりのプラットフォーム　https://event.cloudnativedays.jp/cndt2020/talks/30

みなさんが関わるプラットフォーム、もしかして『作っただけ』になっていませんか？ Kubernetesのような、便利ではあるが複雑なプラットフォームが増えるにつれ、単に環境を作るだけではうまく活用されない時代になってきています。
そこで大事なのは、プロダクトを作っていくという意識。そして、それを回していくチーム作りというのが必要になってきます。
この資料では、なんでプロダクトの考え方が必要なのか。そしてプロダクトマネジメントを行っていくために必要な人材について書いています。

Transcript

1. プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 役に 立つ プラットフォームを 作ろう
2. KAZUTO KUSAMA @jacopen Senior Solutions Architect @VMware
3. About me • VMware Tanzuの導入支援や プラットフォームチームづくりの支援をしています • CloudNative Days TokyoのCo-chairを@amsy810と 一緒にやっています • Kubernetes Wakaran Tokyo #1のお手伝いをしました
4. 今日話すこと • 自分の経験を元に、k8s等のプラットフォームに関わる人たちが 陥りやすい罠について話します • より良いプラットフォームを作っていくのに役立つ、 プロダクトの考え方について話します 視野を広げるための、一つの考え方として知って欲しい
5. k8sに絡んでよくある話 • 社内に新しい共通プラットフォームをつくることになった • 『次世代基盤開発プロジェクト』 『社内統合基盤開発プロジェクト』などなど • 新しいプラットフォームだからコンテナでしょ。k8s使おう
6. k8sに絡んでよくある話 • 社内に新しい共通プラットフォームをつくることになった • 『次世代基盤開発プロジェクト』 『社内統合基盤開発プロジェクト』などなど • 新しいプラットフォームだからコンテナでしょ。k8s使おう 明日から使える死亡フラグ図鑑
 https://www.amazon.co.jp/dp/4299009878
7. 社内(共通|統合|次世代)(基盤|プラットフォーム) は、高い確率で失敗する
8. ちなみに『プラットフォームを作る』とは たとえばk8sを中心とするとき • k8sを立ち上げる
9. ちなみに『プラットフォームを作る』とは たとえばk8sを中心とするとき • k8sを立ち上げる • 各種リポジトリの整備 • 認証・認可 • ログ・メトリクスの収集 • カスタムリソースの追加 • CI/CD • 既存のシステムとの繋ぎ込み 他多数。利用する人たちが支障なく活用できるようにす る作業=プラットフォーム開発 作業割合は違えど、 パブリック/プライベート、 マ ネージド/セルフホスト いずれの場合も必要
10. 死亡理由その1 プラットフォームを作る理由が曖昧 既存のインフラ刷新にあたって、我々も次世代基盤をア ジャイルでコンテナなクラウドネイティブにすることで AIも MLもビッグデータもDevOpsでDXするぞ ⇒ 仕様を決めるだけで ◦年議論した結果 オワコンになって死ぬ ⇒ 手当たり次第実装してチグハグになって死ぬ
11. 死亡理由その2 俺の考えた最強のプラットフォーム めっちゃイケてる。 クラウドネイティブ っぽい ⇒　どの分野も知識が足りず『入れるだけ』になっ てトラブったときに死ぬ ⇒　人手が足りなくて死ぬ ⇒　運用が属人化して死ぬ Kubernetes Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security
12. 死亡理由その3 プラットフォーム開発プロジェクト 社運がかかった プロジェクトだ、やる ぞ！ プロジェクト終了後･･･ みんなどこへ･･･？ 運用は･･･？
13. つまり 目的がはっきりしないままプラットフォーム開発が始まり、 次世代の御旗のもとに壮大な構想と、 たくさんのリソースが投入されるも、
14. つまり 目的がはっきりしないままプラットフォーム開発が始まり、 次世代の御旗のもとに壮大な構想と、 たくさんのリソースが投入されるも、 あるべき形を議論するのにひたすら時間が使われ、 スケジュールは遅延、 各機能の整合性は取れない それでもなんとか完成させたは良いが
15. つまり 目的がはっきりしないままプラットフォーム開発が始まり、 次世代の御旗のもとに壮大な構想と、 たくさんのリソースが投入されるも、 あるべき形を議論するのにひたすら時間が使われ、 スケジュールは遅延、 各機能の整合性は取れない それでもなんとか完成させたは良いが 開発プロジェクトは解散し、残るのは僅かな人数 それでも「絶対に落とすな」と厳命され 昼夜問わず対応するが
16. つまり 目的がはっきりしないままプラットフォーム開発が始まり、 次世代の御旗のもとに壮大な構想と、 たくさんのリソースが投入されるも、 あるべき形を議論するのにひたすら時間が使われ、 スケジュールは遅延、 各機能の整合性は取れない それでもなんとか完成させたは良いが 開発プロジェクトは解散し、残るのは僅かな人数 それでも「絶対に落とすな」と厳命され 昼夜問わず対応するが 結局あんまり使われない
17. つまり 目的がはっきりしないままプラットフォーム開発が始まり、 次世代の御旗のもとに壮大な構想と、 たくさんのリソースが投入されるも、 あるべき形を議論するのにひたすら時間が使われ、 スケジュールは遅延、 各機能の整合性は取れない それでもなんとか完成させたは良いが 開発プロジェクトは解散し、残るのは僅かな人数 それでも「絶対に落とすな」と厳命され 昼夜問わず対応するが 結局あんまり使われない Kubernetesを学んだ結果がこれだよ!
18. ってならないようにね
19. つまり 目的がはっきりしないままプラットフォーム開発が始まり、 次世代の御旗のもとに壮大な構想と、 たくさんのリソースが投入されるも、 あるべき形を議論するのにひたすら時間が使われ、 スケジュールは遅延、 各機能の整合性は取れない それでもなんとか完成させたは良いが 開発プロジェクトは解散し、残るのは僅かな人数 それでも「絶対に落とすな」と厳命され 昼夜問わず対応するが 結局あんまり使われない 役に 立たない プラットフォーム
20. 役に立つ プラットフォーム
21. 役に立つ プラットフォーム 誰の 役に立つ？
22. 誰のためのプラットフォーム？ • プラットフォームは、顧客のためにある
23. 誰のためのプラットフォーム？ • プラットフォームは、顧客のためにある ･･･ウチは社内向けなんだけど、顧客って？ ⇒ 社内向けであっても、 プラットフォームを使ってくれる人は顧客です
24. 顧客の役に立つプラットフォームを作る意識を持ちましょう。 顧客のためのプロダクトを作るイメージを持ちましょう。
25. プロダクト？プロジェクトじゃないの？ プラットフォーム構築を始める際、 『プロジェクト』を発足させて取り組むケースが多い。 ･･･ところでプロジェクトって何？
26. プロジェクトとは？ - 目的や目標が明確なもの - 期限があるもの　終わりがあるもの マネジメントする対象 - スコープ、資源、タイム、コスト、リスク、品質、 調達、コミュニケーション、ステークホルダー、統合 (ISO21500より) プロジェクトマネジメント = How, When を考える
27. 問題点 プロジェクトには終わりがある ⇒ プラットフォームは、作って終わりじゃない。 むしろそこからが本番 SRE、Observability、Service Mesh… クラウドネイティブで語られる技術や 考え方は、いずれも作った後の運用フェーズの話。 プラットフォームは、顧客が居る限り続く。明確な終わりを 定めづらい
28. 問題点 あるべき形は変わり続ける プロジェクトには明確な目標がある ⇒ でないと終わらない プラットフォームでも目的は大事。しかし･･･ • 顧客の状況はビジネスの進捗に応じて変わる • 技術も日々進化する • そもそも、顧客が本当に必要としているものを最初から全て理解する のは不可能。だって人間だもの プラットフォームとして、顧客のために『あるべき姿』を日々追い求めないと いけない。そこに終着点は無い。
29. 改めて見てみよう
30. 死亡理由その1 プラットフォームを作る理由が曖昧 既存のインフラ刷新にあたって、我々も次世代基盤をア ジャイルでコンテナなクラウドネイティブにすることで ML もビッグデータもDevOpsでDXするぞ ⇒ 仕様を決めるだけで ◦年議論した結果オワコン になって死ぬ ⇒ 手当たり次第実装してチグハグになって死ぬ
31. 死亡理由その2 俺の考えた最強のプラットフォーム めっちゃイケてる。 クラウドネイティブ っぽい ⇒　どの分野も知識が足りず『入れるだけ』になっ てトラブったときに死ぬ ⇒　人手が足りなくて死ぬ ⇒　運用が属人化して死ぬ Kubernetes Image Registry CI/CD Monitoring Logging Distributed Tracing Service Mesh Secret Management Security
32. 死亡理由その3 プラットフォーム開発プロジェクト 社運がかかった プロジェクトだ、やる ぞ！ プロジェクト終了後･･･ みんなどこへ･･･？ 運用は･･･？
33. 顧客を 見ていない 続ける 意識が希薄
34. プロダクトとは？ プロダクト （製品・サービス） 顧客 価値を提供
35. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる 必要とされる限り 続く
36. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる 必要とされる限り 続く 進化の著しい技術に追従し 顧客に新たな価値を提供する 顧客のニーズに応える
37. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる 必要とされる限り 続く 進化の著しい技術に追従し 顧客に新たな価値を提供する 顧客のニーズに応える 顧客にプラットフォームのことを知ってもらう 新たな価値を理解してもらう 顧客の課題に寄り添う
38. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる 必要とされる限り 続く 進化の著しい技術に追従し 顧客に新たな価値を提供する 顧客のニーズに応える 顧客にプラットフォームのことを知ってもらう 新たな価値を理解してもらう 顧客の課題に寄り添う プラットフォームを発展させる、 安定 したチーム
39. 成功しているプラットフォームは、 意識的・無意識的にプロダクトとして 扱われている
40. はじめよう、Platform as a Product
41. 先人に学ぼう プロダクトの意識を持つと、急に視野が広がる。 学ぶべきプロダクトマネジメントの知見が沢山あることに気づく
42. プラットフォームのビジョン 自社のビジョンを成し遂げるために働く全ての開発者が、 自身のミッションに集中し、最大限の価値を発揮できるよう支えて いくプラットフォーム プロダクトのあり方を決める
43. プラットフォームのビジョン 自社のビジョンを成し遂げるために働く全ての開発者が、 自身のミッションに集中し、最大限の価値を発揮できるよう支えて いくプラットフォーム Why 誰をどうしたいか ペルソナ ペインポイント 割り込みが多い 仮説と検証 コミュニケーショ ンに時間がかか る 手作業が多い ユーザーインタビュー プロダクトのあり方を決める
44. プラットフォームのビジョン 自社のビジョンを成し遂げるために働く全ての開発者が、 自身のミッションに集中し、最大限の価値を発揮できるよう支えて いくプラットフォーム Why 誰をどうしたいか ペルソナ ペインポイント 割り込みが多い 仮説と検証 コミュニケーショ ンに時間がかか る 手作業が多い ユーザーインタビュー What ユーザー体験 開発者がセルフサービスでアプリをデプロイできる 開発者のテストとデプロイに関するワークフローを自動化 プラットフォームチームに依存することなく、自由にリソースを変更できる 必要なときに必要なログ・メトリクスが得られる プロダクトのあり方を決める
45. ユーザーストーリーで考える What (何をやるのか) 開発者がPull Requestをマージすると、自動でステージングにリリースされるようにする Why (何故やるのか) 開発者として GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージ ング環境にデプロイされるようにしたい。 なぜなら、デリバリーに関する全ての作業を開発者が意識することなく行いたいから だ (顧客価値)
46. バックログを作る ユーザーストーリー
47. MVPを作る MVP(Minimum Viable Product) 顧客に価値があり、実行可能なシンプルなプロダクトを作っていく。 最初からてんこ盛りにはしない。 本当に顧客が必要なものは、すぐには分からない。
48. ステークホルダーと調整する プロダクトチー ム 顧客
49. ステークホルダーと調整する プロダクトチー ム 顧客 担当役員 法務 セキュリティ担 当 インフラ エンジニア UX デザイナー 部門長
50. めっちゃやることあるやん･･･ これ、俺ら(プラット フォームエンジニア)が やるの？
51. プロダクトマネージャーが成功の鍵 これまで挙げたようなプロダクトマネジメントを行うために、専任の PM(PdM)を置きましょう。プラットフォームの成功には、PMが不可欠で す。 エンジニアとPMで、一体となったPlatform Teamを作ります。 Viability 経済性 Desirability ユーザー体験 Feasibility 実現可能性 Product PM Engineer
52. プロダクトマネージャー 『どうやるか』ではなく『何をすべきか』を定義する人。 フルタイムのメンバーであり、戦略の策定、機能バックログの管理、 データを元にした意思決定などで、プロダクトの方向性を決める - “Dreamer” - 古い考えやプロセスに囚われず、『何故？』を 突き詰められる人 - “Alchemist” - たくさんの要件をシンプルなビジョンに落とし込める人 - “Influencer” - ビジネスパートナー、開発者、ITと 強いつながりを 持っている人 - “Minimalist” - 素早くプロダクトをリリースする価値を理解している人
53. これからは絶対に必要になるPM 物理サーバーの 時代 クラウドの時代 クラウド ネイティブの 時代 • 物理から仮想に変わった • インフラの概念はあまり変わらない • アプリケーションの作り方も変わらない • 一度作ってしまえば、その後の運用は障害対応やセ キュリティパッチの適用などが中心 『◦◦構築プロジェクト』のような進め方が可能だった
54. これからは絶対に必要になるPM 物理サーバーの 時代 クラウドの時代 クラウド ネイティブの 時代 • より軽量なコンテナへ • タイムスケールが日・時間から秒単位に • APIが充実し、自動化前提に • アプリケーションの作り方を変えていく必要性 • プラットフォーム自体も常に進化していく 『構築して終わり』ではない時代になった
55. • プラットフォームは顧客のためにある。 • プラットフォームは作って終わりじゃない。育てるもの。 • 何故なら、人も技術も組織も世の中も、日々変わり続けるから。
56. • プラットフォームは顧客のためにある。 • プラットフォームは作って終わりじゃない。育てるもの。 • 何故なら、人も技術も組織も世の中も、日々変わり続けるから。 • 役に立つプラットフォームのためには、プロダクトの意識が有用。 • プラットフォームを成功に導く、プロダクトマネージャーが必要。
57. • プラットフォームは顧客のためにある。 • プラットフォームは作って終わりじゃない。育てるもの。 • 何故なら、人も技術も組織も世の中も、日々変わり続けるから。 • 役に立つプラットフォームのためには、プロダクトの意識が有用。 • プラットフォームを成功に導く、プロダクトマネージャーが必要。 • Kubernetesというドメイン知識を得た皆さんの次の選択肢に、PMを加え てみるのはいかが？ • Kubernetesに関わらず、今後ありとあらゆる場面で必要にされると思う
58. 何から始めればいい？
59. CNDT2020のセッションを見ましょう 世界に誇れるプラットフォームチームを作る https://event.cloudnativedays.jp/cndt2020/talks/29 今日のセッションと被るところも多いですが、 Platform as a Productを実践していく ためのチーム作りについて語っています。
60. CNDT2020のセッションを見ましょう 独りよがりのプラットフォーム https://event.cloudnativedays.jp/cndt2020/talks/30 Toriclsさんのセッション。プロダクトという表現はありませんが、 全く同じ問題意識で発表されています。AWSにおける考え方は必見
61. いい書籍も揃ってきました プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム ・組織運営まで INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
62. いい書籍も揃ってきました デザインリサーチの教科書 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャ イルのその先について
63. あ、一つ補足 • 説明順の都合上、プロジェクト的な進め方はNGという表現に捉え られたと思いますが、正確には違います。 • プロダクトの考えは第一に持ちつつ、そのライフサイクルの中で 都度プロジェクトを走らせるのは正しいアプローチです • 1回こっきりの構築プロジェクトで終わっちゃうのがNG プロダクトのライフサイクル ◦◦機能開発 プロジェクト △△ プロジェクト ××計画 プロジェクト ◦×開発 プロジェクト △×x プロジェクト
64. Thank you!