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

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

   View Slide

2. KAZUTO KUSAMA
   @jacopen
   Senior Solutions Architect @VMware
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   https://www.amazon.co.jp/dp/4299009878
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. ってならないようにね
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

29. 改めて見てみよう
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

36. プラットフォームをプロダクトとして考える
    プラットフォーム
    (プロダクト)
    開発者
    (顧客)
    必ず顧客がいる
    必要とされる限り
    続く
    進化の著しい技術に追従し
    顧客に新たな価値を提供する
    顧客のニーズに応える
    

    View Slide

37. プラットフォームをプロダクトとして考える
    プラットフォーム
    (プロダクト)
    開発者
    (顧客)
    必ず顧客がいる
    必要とされる限り
    続く
    進化の著しい技術に追従し
    顧客に新たな価値を提供する
    顧客のニーズに応える
    顧客にプラットフォームのことを知ってもらう
    新たな価値を理解してもらう
    顧客の課題に寄り添う
    

    View Slide

38. プラットフォームをプロダクトとして考える
    プラットフォーム
    (プロダクト)
    開発者
    (顧客)
    必ず顧客がいる
    必要とされる限り
    続く
    進化の著しい技術に追従し
    顧客に新たな価値を提供する
    顧客のニーズに応える
    顧客にプラットフォームのことを知ってもらう
    新たな価値を理解してもらう
    顧客の課題に寄り添う
    プラットフォームを発展させる、 安定
    したチーム
    

    View Slide

39. 成功しているプラットフォームは、
    意識的・無意識的にプロダクトとして
    扱われている
    

    View Slide

40. はじめよう、Platform as a Product
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

58. 何から始めればいい？
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

64. Thank you!
    

    View Slide