Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

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

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

Kazuto Kusama

May 13, 2021
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. ちなみに『プラットフォームを作る』とは たとえばk8sを中心とするとき • k8sを立ち上げる • 各種リポジトリの整備 • 認証・認可 • ログ・メトリクスの収集

    • カスタムリソースの追加 • CI/CD • 既存のシステムとの繋ぎ込み 他多数。利用する人たちが支障なく活用できるようにす る作業=プラットフォーム開発 作業割合は違えど、 パブリック/プライベート、 マ ネージド/セルフホスト いずれの場合も必要
  2. 問題点 あるべき形は変わり続ける プロジェクトには明確な目標がある ⇒ でないと終わらない プラットフォームでも目的は大事。しかし・・・ • 顧客の状況はビジネスの進捗に応じて変わる • 技術も日々進化する

    • そもそも、顧客が本当に必要としているものを最初から全て理解する のは不可能。だって人間だもの プラットフォームとして、顧客のために『あるべき姿』を日々追い求めないと いけない。そこに終着点は無い。
  3. プラットフォームをプロダクトとして考える プラットフォーム (プロダクト) 開発者 (顧客) 必ず顧客がいる 必要とされる限り 続く 進化の著しい技術に追従し 顧客に新たな価値を提供する

    顧客のニーズに応える 顧客にプラットフォームのことを知ってもらう 新たな価値を理解してもらう 顧客の課題に寄り添う プラットフォームを発展させる、 安定 したチーム
  4. プラットフォームのビジョン 自社のビジョンを成し遂げるために働く全ての開発者が、 自身のミッションに集中し、最大限の価値を発揮できるよう支えて いくプラットフォーム Why 誰をどうしたいか ペルソナ ペインポイント 割り込みが多い 仮説と検証

    コミュニケーショ ンに時間がかか る 手作業が多い ユーザーインタビュー What ユーザー体験 開発者がセルフサービスでアプリをデプロイできる 開発者のテストとデプロイに関するワークフローを自動化 プラットフォームチームに依存することなく、自由にリソースを変更できる 必要なときに必要なログ・メトリクスが得られる プロダクトのあり方を決める
  5. プロダクトマネージャー 『どうやるか』ではなく『何をすべきか』を定義する人。 フルタイムのメンバーであり、戦略の策定、機能バックログの管理、 データを元にした意思決定などで、プロダクトの方向性を決める - “Dreamer” - 古い考えやプロセスに囚われず、『何故?』を 突き詰められる人 -

    “Alchemist” - たくさんの要件をシンプルなビジョンに落とし込める人 - “Influencer” - ビジネスパートナー、開発者、ITと 強いつながりを 持っている人 - “Minimalist” - 素早くプロダクトをリリースする価値を理解している人
  6. これからは絶対に必要になるPM 物理サーバーの 時代 クラウドの時代 クラウド ネイティブの 時代 • 物理から仮想に変わった •

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

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