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

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

Kazuto Kusama
September 14, 2020

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

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

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

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

Kazuto Kusama

September 14, 2020
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. 世界に誇れる
    プラットフォームチームを作る

    View full-size slide

  2. KAZUTO KUSAMA
    @jacopen
    2
    Senior Solutions Architect @VMware Tanzu
    VMware Tanzu(旧Pivotal)のSolutions Architectっていう仕事をしています。
    SAって会社によって指す仕事が結構違うんですが、VMwareの場合はTanzu製品を導
    入済みのお客さんに支援を行う、いわゆるプロフェッショナルサービスという役割を
    担っています。
    その前は、通信事業者でPaaS (Platform as a Service)の開発と運用をしていまし
    た。こういう経緯もあり、かれこれ8年くらいプラットフォームに関わっています。

    View full-size slide

  3. なぜこの話をするのか?
    仕事柄、さまざまなプラットフォームと、それを作るチームを見てき
    ました。
    うまくいくチームもあれば、うまくいかないチームもありました。そ
    の違いはなんだろう?と考えてみたのです。
    実際にうまくいっているチームにもヒアリングした結果、『共通項』
    と言えるものが見えてきました。
    なので、今回は成功するプラットフォームの秘訣を
    探っていきます。

    View full-size slide

  4. 前提
    この発表にあたっては、VMware Pivotal Labsのメンバー、
    そしてCyberagentの青山さん、LINEの西脇さんにもご協力いた
    だきました。ありがとうございました。

    View full-size slide

  5. とあるプラットフォームチームの物語
    日本でも有数のエンタープライズ企業 A社
    A社に勤めるプラットフォームエンジニアである((あなた)) は
    勤続10年の中堅社員。
    新入社員の頃はオンプレのデータセンターで動くシステムの運用を担当。
    近年はパブリッククラウドを利用することも多い。
    実感が沸きやすいように、主人公のことを
    ((あなた)) って呼んでます。

    View full-size slide

  6. A社では、DXの流れで『自社のソフトウェアやサービスを強化しビジネ
    スを変革しなければならない』との声が上がっていた。
    そんな中、((あなた))はこのような話を耳にする。
    『○○さん(偉い人)が、アプリ開発チームの生産性に不満を持っている』
    『生産性を上げるため、コンテナを活用しろと言っている』

    View full-size slide

  7. 技術に対する興味関心が強い((あなた))は、これまでも自主的にミー
    トアップやカンファレンスに参加していた
    Kubernetesは世界的にも利用が広がっており、コミュニティも活発な
    こと、周囲を取り巻くエコシステムもどんどん発展していることを知っ
    ていた

    View full-size slide

  8. これまで学んで来たことを仕事で生かすチャンスだと考えた((あなた))
    は、この新しい基盤作りに名乗り出る。
    こうして発足した『次世代基盤構築プロジェクト』のリードエンジニアを
    任された((あなた))。
    早速以下のような構成を考えた。

    View full-size slide

  9. Kubernetes
    (Managed)
    Image Registry CI/CD
    Monitoring
    Logging

    View full-size slide

  10. Kubernetes
    (Managed)
    Image Registry CI/CD
    Monitoring
    Logging
    だいぶコンサバな構成だね。
    せっかく予算もついているんだし、もっと挑戦してみ
    てもいいんじゃない?
    すると、上司からこういうツッコミが。

    View full-size slide

  11. Kubernetes
    (Managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    確かにそうかもと思ったので、こういう構成を付け加
    えてみました。

    View full-size slide

  12. Kubernetes
    (Managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    SLAが99.5%!? 年間44時間ものダウンを許容するのか。
    既存のインフラは稼働率 100%を目標にやっているんだ。こ
    のような品質は受け入れられない
    すると、偉い人からこういうツッコミをうけました。
    k8sは
    マネージドを使う予定でしたが、その
    SLAは99.5%とさ
    れていたのです。

    View full-size slide

  13. Kubernetes
    (self-managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    悩んだ結果、k8sは自前で運用することとしました。それに
    よって、自分たちの目標は99.99%と主張することができ
    ました。

    View full-size slide

  14. Kubernetes
    (self-managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    全てにおいてセキュリティが第一。最低限 WAFと脆弱性ス
    キャナと(以下社内標準のチェックリスト )
    を満たさないと、インフラとして認められません。
    これでなんとかなる、と思った瞬間、社内のセキュ
    リティ担当からツッコミが。

    View full-size slide

  15. Kubernetes
    (self-managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    Security
    こうして、社内のだれもを説き伏せられる構成が完
    成しました。

    View full-size slide

  16. Platform team
    ((あなた)) Bさん Cさん(兼務)
    Dさん(兼務) Eさん(派遣) Fさん(派遣)
    プラットフォームチームは、こういう構成になりました。

    View full-size slide

  17. 役割分担
    Kubernetes
    (self-managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    Security
    メンバーそれぞれが1つないしは2つの分野を受け持つ構
    成を組みました。

    View full-size slide

  18. 問題発生
    Kubernetes
    (self-managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    Security
    コンテナ全く分かりません。触ったこと
    もないです
    技術力不足
    さて始めよう、となった瞬間、メンバーの
    1人がこう打ち明けまし
    た。
    しかたなく、((あなた))はその人の分野もカバーします。

    View full-size slide

  19. 問題発生
    Kubernetes
    (self-managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    Security
    他の業務が忙しくて、こちらに手を付
    けられません
    兼務問題
    どうも兼務の人の進捗が悪いなと思って聞いてみたら、他の業
    務が忙しすぎると・・・。
    しかたなく、((あなた))はその人の分野もカバーします。

    View full-size slide

  20. 問題発生
    Kubernetes
    (self-managed)
    Image Registry CI/CD
    Monitoring
    Logging
    Distributed
    Tracing
    Service Mesh
    Secret
    Management
    Security
    道半ばで大変申し訳ないのですが・・・
    今月末で退職します。
    メンバーの離

    信頼を置いていたBさんが、申し訳なさそうにこう打ち明けてき
    ました。引き留めたかったのですが、既に次が決まっているよう
    で・・・。

    View full-size slide

  21. 問題発生
    - プロジェクトの大幅な遅延
    - 深刻な人員不足

    View full-size slide

  22. 得られたサポート
    追加人員を
    連れてきたよ。
    追加人員?












    セキュリティの
    専門家、Zさん
    インフラの
    専門家、Yさん
    ネットワークの
    専門家、Xさん
    進捗が芳しくないプロジェクトに、追加人員が。全員兼務
    だけど、50%+50%+50%で1.5人分。辞めたBさん分以上
    になると上司は言います。本当かな・・・

    View full-size slide

  23. 10ヶ月後、なんとかリリース

    View full-size slide

  24. しかし・・・
    - 誰も使ってくれない

    View full-size slide

  25. 驚くべき実態
    - Kubernetesの話は突然上から降ってきた。現場としては必要性を感じていなかった
    - 開発の8割は外注であり、社内では仕様の策定と納品物の検収が主
    - 内製部分はCIしていない。そもそもテストコードが殆ど無い
    - 手順書通りにコマンドを叩いてコンテナイメージを作成出来ることは分かったが、こ
    れまでやってきた作業がコンテナに置き換わるだけで、特にメリットを感じなかった
    - Kubernetesの概念が複雑で、覚えるのが苦痛だった。既存の業務で手一杯なの
    で、これ以上時間を割くのは困難
    あまりに使ってくれないので、開発の人たちに状況を聞き
    に行きました。すると、驚くべき実態が明らかになったので
    す。

    View full-size slide

  26. 爆発する運用
    - 運用においてもトラブルが多発
    - 十分な引き継ぎが出来ていなかったため、ブラックボックス化している部分が多数。
    - 基本的な使い方を説明するだけで1日持って行かれる

    View full-size slide

  27. 結局・・・
    - アップデートも出来ず、Upstreamから1年以上遅れた『レガシー』なKubernetesに
    - 利用が広がらず、当然アプリ開発チームの生産性は変わらなかった
    - 結局『次世代基盤』はほとんど使われないままに、忘れ去られていく
    - 社員の中には『Kubernetesは使えない』という認識だけが残った

    View full-size slide

  28. この物語はフィクションです
    たぶん

    View full-size slide

  29. どこを間違ったのか?
    Managedを使わず自前でいったせい?
    偉い人の思い込みのせい?
    事前の調査不足のせい?
    人員の配置の下手さのせい?
    こうなってしまった理由、いろいろ考えられると思います。
    上に挙げた指摘はいずれも正しい。

    View full-size slide

  30. プロダクト マインドセットがなかった
    ただ、問題の根底にあるものを一言でいうと、
    自分ならこう言います。

    View full-size slide

  31. なぜ突然プロダクトの話に?
    突然『プロダクト マインドセット』と言われて
    面食らったかもしれません。
    プロダクトって製品とかサービスでしょ?
    今はそれを動かすためのプラットフォームの話をしているんでしょ?
    そう思われるのも当然なのですが、今回お話ししたいのは、まさにそこ。
    『プラットフォーム構築・運用においても、
        プロダクトのマインドセットを持つべき』

    View full-size slide

  32. 再掲
    これまで学んで来たことを仕事で生かすチャンスだと考えた((あな
    た))は、この新しい基盤作りに名乗り出る。
    こうして発足した『次世代基盤構築プロジェクト』のリードエンジニアを
    任された((あなた))。
    早速以下のような構成を考えた。
    さっきの物語では『次世代基盤構築
    プロジェクト』をやってい
    ましたね。
    プロジェクトとプロダクトって何が違うんでしょう?

    View full-size slide

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

    View full-size slide

  34. プロダクトとは?
    プロダクト
    顧客
    価値を提供

    View full-size slide

  35. プロダクトとは?
    プロダクト
    顧客
    価値を提供
    必ず顧客がいる
    プロダクトがある限
    り終わらない
    プロダクトマネジメント =
    WhatとWhyを突き詰め、
    プロダクトの価値を最大化する
    プロダクトには、必ず顧客がいます。
    プロダクトには、明確な終わりがありません。
    続けていくのが前提です。

    View full-size slide

  36. プラットフォームをプロダクトとして考える
    プラットフォーム
    (プロダクト)
    開発者
    (顧客)
    価値を提供
    必ず顧客がいる
    プロダクトがある限
    り終わらない
    プロダクトマインドセットを持つ。
    つまり、プラットフォームはプロダクトで
    あると考えるんです。
    プラットフォームには必ず使う人がいま
    すよね?つまり顧客です。
    プラットフォームは、使う人が居る限り
    維持しますよね?

    View full-size slide

  37. プラットフォームをプロダクトとして考える
    プラットフォーム
    (プロダクト)
    開発者
    (顧客)
    必ず顧客がいる
    プロダクトがある限
    り終わらない プラットフォームを発展させる、 安定
    したチーム
    プラットフォームを安定して維持してい
    くためには、安定したチームが必要で
    す。

    View full-size slide

  38. プラットフォームをプロダクトとして考える
    プラットフォーム
    (プロダクト)
    開発者
    (顧客)
    必ず顧客がいる
    プロダクトがある限
    り終わらない プラットフォームを発展させる、 安定
    したチーム
    進化の著しい技術に追従し
    顧客に新たな価値を提供する
    顧客のニーズに応える
    プロダクトは成長し続けることで顧客に
    新たな価値を提供していきます
    プラットフォームも進化が著しいですよ
    ね。新しい技術に追従していくことで、
    プラットフォームを成長させなければい
    けません。
    そのためにも、やっぱり安定したチー
    ムが大事です。

    View full-size slide

  39. プラットフォームをプロダクトとして考える
    プラットフォーム
    (プロダクト)
    開発者
    (顧客)
    必ず顧客がいる
    プロダクトがある限
    り終わらない プラットフォームを発展させる、 安定
    したチーム
    進化の著しい技術に追従し
    顧客に新たな価値を提供する
    顧客のニーズに応える
    顧客にプラットフォームのことを知ってもらう
    新たな価値を理解してもらう
    顧客の課題に寄り添う 良いものを作っても、知られなければ
    使ってもらうことはできません。
    顧客の課題を解決できなくては、使っ
    てもらうことはできません。
    顧客とコミュニケーションを取っていくこ
    とも大事なのです。

    View full-size slide

  40. 何故今まではプロダクトマインドセットが
    不要だったのか?
    物理サーバーの
    時代
    クラウドの時代
    クラウド
    ネイティブの
    時代

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  43. 成功しているプラットフォームは、
    意識的・無意識的にプロダクトとして
    扱われている
    今回このセッションを行うにあたって、実際に成功しているプラット
    フォームに携わっている、LINEの西脇さん、Cyberagentの青山
    さんにインタビューをしました。
    その結果、こう思ったのです。

    View full-size slide

  44. はじめよう、Platform as a Product
    プラットフォームをプロダクトとして扱うことを、我々VMwareのメン
    バーはPlatform as a Productと呼んでいます。

    View full-size slide

  45. 価値のある
    プロダクト
    プロダクトをマネジメントしていくということは、
    価値のあるプロダクトを創っていくということです。

    View full-size slide

  46. 価値のある
    プロダクト
    仮説
    検証
    実装
    Platform Team
    ただ、いきなり完璧なものは作れません。チームとして仮
    説・実装・検証のサイクルを繰り返して、良いものに育てて
    いくんです。

    View full-size slide

  47. 価値のある
    プロダクト
    仮説
    検証
    実装
    User Centered Design
    Platform Team
    Balanced Team
    Site Reliability
    Engineering
    Extreme Programming
    Lean Product
    Management
    世の中にはプロダクトマネジメントの知見があります。プ
    ラットフォームにおいても、既にある考え方を取り入れてい
    きたいと思います。

    View full-size slide

  48. 価値のある
    プロダクト
    仮説
    検証
    実装
    User Centered Design
    Platform Team
    Balanced Team
    Site Reliability
    Engineering
    Extreme Programming
    Lean Product
    Management
    まずは僕らがBalanced teamと
    呼んでいる考え方から。

    View full-size slide

  49. Platform Teamをつくる
    Viability
    経済性
    Desirability
    ユーザー体験
    Feasibility
    実現可能性
    Product
    専任のPM(PdM)
    Platform
    Champion
    +
    専任のEngineer
    PM
    Engineer
    チームには、専任のProduct Manager
    と専任のエンジニアを置くことを推奨してい
    ます。
    エンジニアがFeasibility, PMが
    Desirability, Viabilityを担います。
    ※ 一般のプロダクト開発においてはUXを
    専任のDesignerに任せることが多いです
    が、プラットフォームでは一旦PMに担わせ
    ます

    View full-size slide

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

    View full-size slide

  51. いかなる時であっても兼任はNG
    Platform TeamのエンジニアとPMは必ず専任であること。
    - プロダクトを維持し、成長させるにはチームメンバーの献身が必須
    - 片手間で力を貸すやり方では機能しない
    - 人の稼働は算数できません
    これは繰り返し言いたいことなのですが、
    人の稼働は算数じゃないです。50%稼働の人を3
    人連れてきても1.5人分の仕事が出来るなんてこと
    はありません。

    View full-size slide

  52. Platform Champion
    Platform as a Productを進める際に、Platform teamを育て、
    守っていくための意思と権限を持っている人。
    Platform Teamとはパートタイムで関わる。
    - CxOレベルの人、もしくは近い人
    - 社内起業や組織変革の実績がある人
    - 会話を 『○○が問題だ』 から 『どうすれば良くなるのか』 に
    変えられる人
    - プラットフォームの価値を理解し、明確にし、社内に伝えられる人

    View full-size slide

  53. Q. 社内にPMが居ないんだけど・・・
    PM不足はどの組織にも共通する課題。現実問題、プロダクトマネジメントを
    行ってこなかった組織がいきなりベテランPMを用意するのは困難。
    必要なのは肩書きとしてのPMではなく、PMの適性を持ったチームメンバー。
    エンジニアの中からPMのような振る舞いをするメンバーを選定するのも手。
    技術とドメイン知識を持ったPMはとても貴重なので、それはそれで良いPMに
    なり得るのです。

    View full-size slide

  54. Q. 専任メンバーを用意できないんだけど・・・
    そのためにPlatform Championがいる。
    Platform Championがチームを守り、育てるための人のアサインと意思
    決定を行っていく。
    権限をもつ人が居ない場合、Platform as a Productの実践は困難。

    View full-size slide

  55. 価値のある
    プロダクト
    仮説
    検証
    実装
    User Centered Design
    Platform Team
    Balanced Team
    Site Reliability
    Engineering
    Extreme Programming
    Lean Product
    Management

    View full-size slide

  56. Platformのビジョンを定める
    Vision
    アプリケーションの変更回数が多くなっても、ワークロードが短期間に変化しても、
    一貫したスピードと品質を提供できるプラットフォーム
    Goal / Anti-Goal
    Goal
    ● 開発者がセルフサービスでアプリをデプロイできる
    ● 開発者のテストとデプロイに関するワークフローを自動化
    ● プラットフォームチームに依存することなく、自由にリソースを変更できる
    Non-Goal
    ● 抽象化の無いIaaS領域の自動化
    目標と成果指標の計測のため、
    OKR (Objectives and Key Results) の導入もあり
    やらないことを決めるの
    超重要
    達成度合いの計測
    超重要

    View full-size slide

  57. ユーザーインタビューをする
    価値のあるプロダクトとなるには、顧客の課題を解決できるプロダクトでなけ
    ればいけない。
    ユーザーに直接インタビューを行い、何が必要とされているのか分析していく
    べし。
    インタビューの際には、何が欲しいか を聞くのではなく、 何に困っているか(ペ
    インポイント) を中心に聞くと良い

    View full-size slide

  58. ユーザーストーリーで考える
    What (何をやるのか)
    開発者がPull Requestをマージすると、自動でステージングにリリースされるようにする
    Why (何故やるのか)
    開発者として
    GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージ
    ング環境にデプロイされるようにしたい。
    なぜなら、デリバリーに関する全ての作業を開発者が意識することなく行いたいから
    だ (顧客価値)
    チケット管理システムを導入している人
    は多いと思いますが、やることをそのま
    まチケットにしていませんか?
    そうではなく『誰にとって』『どういう価値
    があるか』を書いていくのです。

    View full-size slide

  59. ペルソナを作る
    先ほどの例だと『開発者』と書いたが、ここはペルソナを作るべき。
    ペルソナを作ることで、ターゲットのブレを抑えることができる
    ● バックエンドエンジニア歴 3年
    ● 入社後1年間はフロントエンジニアをやっていたので、 jQueryに
    関する知識もあり
    ● インフラはあまり詳しくない
    ● 毎朝9時半に出社。出来るだけ定時に帰るのが目標
    ● キーボードにはこだわりがあり、自作キーボードを持ち込んで
    いる
    ● 愛車はホンダ
    ● いつかはインディーズゲームで一山当てたい
    佐藤琢巳
    バックエンド
    エンジニア
    ユーザーストーリーをより良くするには、ペル
    ソナを作っていきましょう。

    View full-size slide

  60. ペルソナを作る
    What (何をやるのか)
    佐藤さんがPull Requestをマージすると、自動でステージングにリリースされるようにする
    Why (何故やるのか)
    佐藤さんとして
    GitHubでPull Requestがマージされると、自動でコンテナイメージをビルドし、ステージ
    ング環境にデプロイされるようにしたい。
    なぜなら、デリバリーに関する全ての作業を 佐藤さんが意識することなく行いたいから
    だ (顧客価値)
    さっきの例に当てはめるとこうなりますね

    View full-size slide

  61. 価値のある
    プロダクト
    仮説
    検証
    実装
    User Centered Design
    Platform Team
    Balanced Team
    Site Reliability
    Engineering
    Extreme Programming
    Lean Product
    Management

    View full-size slide

  62. VSMを実施する
    Value Stream Mapping
    プロダクトが顧客に届くまでに必要なプロセスと時間を可視化
    一カ所だけ改善しても、他にボトルネックがあ
    れば出力は上がりません。
    こういった可視化の分析も考えましょう

    View full-size slide

  63. 優先順位を決める
    どのストーリーがプロダクトにとって優先なのか、PMが中心となって決めてい
    く。
    アジャイル開発の要素を取り入れ、相対見積もりをやっていくのも良い。 (ただ、
    ソフトウェア開発より見積もり精度を出しづらい・・・)

    View full-size slide

  64. MVPを作る
    MVP(Minimum Viable Product)
    顧客に価値があり、実行可能なシンプルなプロダクトを作っていく。
    Cloud Nativeなプラットフォームは次々と面白い仕組みが出てくるが、欲張っ
    てあれこれ入れるのはNG
    色々詰め込んでもプラットフォームの価値は上がりま
    せん。本当に必要とされているものから、
    小さく作っていきましょう。

    View full-size slide

  65. Q. やること多くて大変そう・・・人も少ないし、時間が割けない・・・
    必要ないもの作り込む方がよっぽど時間の無駄ですよ?
    このループを早く回していくことが、結果として一番の時間の節約に繋がる
    計画して
    小さく作って
    検証して

    View full-size slide

  66. 価値のある
    プロダクト
    仮説
    検証
    実装
    User Centered Design
    Platform Team
    Balanced Team
    Site Reliability
    Engineering
    Extreme Programming
    Lean Product
    Management

    View full-size slide

  67. サステナブルなチーム作りのためのXP
    Extreme Programming
    アジャイル開発の一手法。チームを作る手法としても優れている。
    5つの価値
    Simplicity / Communication / Feedback / Respect / Courage
    プラクティス
    - イテレーション
    - ペアプログラミング
    - みんなで所有
    - 継続的インテグレーション
    など
    ここではXPの例を挙げていますが、Scrumの考え方
    取り入れて実践されている場合、それはそのまま続け
    ていいと思います。
    どちらのケースも、ただ漫然とやるのではなく、『その
    プラクティスにどういう意味があるか』を考えながら実
    践して欲しいですけどね。

    View full-size slide

  68. 価値のある
    プロダクト
    仮説
    検証
    実装
    User Centered Design
    Platform Team
    Balanced Team
    Site Reliability
    Engineering
    Extreme Programming
    Lean Product
    Management
    顧客
    Branding
    Marketing
    Customer success

    View full-size slide

  69. Platformの名前を決める
    もしあなたが一般向けにプロダクトをリリースするとき、
    こういう名前を付けますか?
    LINEみたいなサービス作って『次世代メッセージングシステム』って名
    前にしますか?しないですよね。

    View full-size slide

  70. Platformの名前を決める
    プラットフォーム
    (プロダクト)
    開発者
    (顧客)
    必ず顧客がいる
    顧客にプラットフォームのことを知ってもらう
    新たな価値を理解してもらう
    顧客の課題に寄り添う
    プラットフォームに名前を付けるのは遊びではない。
    マーケティング・ブランディングとして
    絶対に必要
    たとえ社内向けであっても、必ず顧客が居るわけで
    す。ならば、知ってもらうためにはプラットフォームの
    名前、重要です。
    チームメンバーとしても、名前のあるなしで身の入り
    方が結構変わります。

    View full-size slide

  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という名前がついています。

    View full-size slide

  72. Q. プラットフォームに名前を付けるの、気が引けるんだけど・・・
    気が引ける理由を考えてみよう
    - 偉い人にどう説明すればいいのか分からない
    - 余計な議論になってしまいそうで怖い
    - 社内にそういう文化が無くて浮きそう
    ⇒ 気にする先が内部に向きすぎかも。常に顧客のことを考えよう。
    また、こういう意思決定のためにPlatform Championは重要。

    View full-size slide

  73. Enablementの支援をしていく
    プラットフォームが出来上がっても、それを活用できなければ意味が無
    い。
    - ドキュメント
    - ワークショップ
    - ヘルプデスク
    などを整備していき、顧客がスムーズにプラットフォームを使える仕組
    みを整えていく。

    View full-size slide

  74. チームを分けていく
    おそらくEnablementに注力し始めるころから、1チームではカバーしきれな
    くなってくる。
    しかしチームサイズを大きくするのは
    NG。”Two-pizza rule” 2枚のピザを
    分け合えるくらいの人数)にするのが最適。
    つまり、徐々にチームを責任ごとに分けていく必要性が出てくる

    View full-size slide

  75. Team Topologies
    https://teamtopologies.com/
    Platform team
    Complicated
    Subsystem Team
    Enabling Team
    Stream-aligned Team
    Team Topologiesっていう考え方があります。今回のセッ
    ションでは詳しく説明出来ませんでしたが、分け方の指標にな
    るかなと。

    View full-size slide

  76. Team Topologies
    Platform team
    Stream-aligned team
    Stream-aligned team
    Stream-aligned team
    Stream-aligned team
    支援する
    一緒にやる
    サービスとして
    提供する
    Enabling team
    Complicated
    subsystem team
    チーム間のコラボレーションも、いくつかのパターンがありま
    す。

    View full-size slide

  77. まとめ
    ● たとえ社内向けであっても、プラットフォームはプロダクトとして
    扱っていくべき
    ● 良いプロダクトとは、顧客の課題を解決できるもの
    ● 良いプロダクトにしていくために、プロダクトマネジメントの考え方
    を実践していこう

    View full-size slide

  78. 『世界に誇れるプラットフォームチーム』って何だろう?
    めっちゃ高度で大規模なプラットフォームを運営しているチー
    ム?
    どれだけ最先端でも、どれだけ大規模でも、自分の顧客に価値
    を提供できていなければ、良いプラットフォームとは言えない。今
    回、それを学びましたね。
    自分の顧客に、一番価値を提供できるプラットフォームを作れる
    チーム。それが、誇れるチームなんだと思います。

    View full-size slide

  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

    View full-size slide