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

組織をスケールさせるための Four Keys とチームトポロジー

組織をスケールさせるための Four Keys とチームトポロジー

Findy 開発生産性 Conference における発表です

Other Decks in Technology

Transcript

  1. 組織をスケールさせるための
    Four Keys とチームトポロジー
    Findy 開発生産性 Conference
    株式会社タイミー 執行役員 VP of Technology
    Toru Yamaguchi (@zigorou)

    View full-size slide

  2. 自己紹介
    山口 徹 | @zigorou
    執行役員 VP of Technology
    2003-2004 株式会社コンテンツ (SWE)
    2005-2007 株式会社ガイアックス (SWE, EM)
    2007-2008 サイボウズ・ラボ株式会社 (SWE)
    2009-2020 株式会社ディー・エヌ・エー (SWE, SA, 専門役員)
    2020-2023 株式会社ベルフェイス (取締役CTO兼CPO)
    2023- 株式会社タイミー (執行役員VP of Technology)
    5月にタイミーに転職したばかりです。
    ひょんな事から今月からプロダクトマネジメント組織を管掌する事になりました。
    普段はお料理系男子です。

    View full-size slide

  3. (Ad) 決意表明的なもの
    昨日、入社の経緯をインタビューして貰った記事が公開されましたので、ぜひ御覧ください
    インタビュー記事:
    https://productpr.timee.co.jp/n/n38f537cb6ff1

    View full-size slide

  4. 今日お伝えしたいこと
    チームトポロジーを実践し開発生産性を高めようとしているタイミーの取り組みと、取り組みから出てきた課題、そして打ち手につい
    てお話していきます
    タイミーの事業やプロダクトの現在地点
    前提知識として、スキマバイト No.1 のタイミーという事業とプロダクトについて知ってもらいつつ、現在の事業
    環境や将来の事業についての想定について説明していきます
    現在の開発組織のコンセプトと開発生産性への取り組み
    チームトポロジー等の考え方をベースとしたタイミーの開発組織のコンセプトと現在地について説明していきま
    す。チームトポロジーの実践例としてお聞きいただければと思います
    開発生産性や組織に関わる課題 / その打ち手としての考え方
    開発生産性や組織に関わる今抱えている課題と、その打ち手としてどのようにアプローチしているかについて、
    今時点での「個人的」な見解をお話していけたらと思います

    View full-size slide

  5. タイミーについて
    タイミーという会社や事業の現在について

    View full-size slide

  6. タイミーとは
    6
    「働きたい時間」と「働いてほしい時間」を
    マッチングするスキマバイトサービス
    従来の「求人サイト」でも「派遣」でもない

    View full-size slide

  7. タイミーの実績
    スキマ
    バイト
    No.1
    導入事業者数
    ワーカー数
    500万人
    ※2022年8月時点 ※1 [調査方法]デスクリサーチ及びヒアリング調査 [調査期間]2021年2月8日~22日 [調査概要]スキマバイトアプリ
    サービスの実態調査 [調査対象]2020年12月までにサービスを開始しているスキマバイトアプリ10サービス [調査実施]株式会社ショッ
    パーズアイ ※2 [出典]AppStoreライフスタイルカテゴリーランキング(2021年5月時点)
    7
    46,000企業

    View full-size slide

  8. 業界を超えて広がるタイミー
    タイミーは多くの業界で活用されるサービスに成長し、物流/小売/飲食の各業界TOP10社の半数以上がタイミーを導入中。
    現在導入事業者数は46,000企業 130,000拠点以上になり、様々な業界に広がっています。
    8

    View full-size slide

  9. 募集人数の推移
    9
    ※1:2022年4Qと2021年4Qの比較
    コロナ禍においても、
    過去に例を見ない程の
    加速的高成長を実現。

    View full-size slide

  10. ここまで
    会社紹介テンプレです!

    View full-size slide

  11. 既存事業はまだまだ伸びる
    しかし、プロダクトの価値提案の幅は事業拡大のスピードに追いつけていない
    スポットワークは新しい働き方
    従って、企業様や働き手であるワーカーにとっても安心して働き続けるための環境整備がまだまだ必要
    魅力品質ではなく、当たり前品質の向上がまだまだ重たい課題
    人手不足はあらゆるところで発生している
    一方で、タイミーが導入されている産業・職種はまだまだ限定的
    各産業・職種ごとでスポットワークの導入の足かせになっている課題さえクリアすれば、既存事業はまだまだ伸
    びていく
    競合環境は厳しさを増してきている
    タイミーのビジネスモデルを踏襲した競合サービス・プロダクトが台頭してきており、ファーストペンギンとし
    て MOAT を築き、他を寄せ付けない状態にすることが急務

    View full-size slide

  12. 将来を見越した先行投資
    さらなる事業成長のために必要なピースを想像して、先手を打っていく必要がある
    (想定) 強いスイッチングコストモートを築くためのパートナーシップ
    例えば顧客企業の業務プロセスに深く入り込み、手放せない連携をパートナーシップを用
    いて実現していく等の試みを検討していく可能性がある
    (想定) 事業の多角化のためのマルチプロダクト戦略やグローバル展開
    プロダクト開発だけでなく、社内の業務プロセスや組織をマルチプロダクトやグローバル
    展開に合わせてスケールアウトしていく必要がある
    開発生産性を高く保った上で、再現性のある組織拡大とプロセスのカタの構
    築が急務
    いずれも具体化したプランではないものの、近未来に起こりうる事として捉えて、開発生
    産性を高く維持するために、より良いケイパビリティを身に着け、プロセスをカタ化し、
    組織を拡大していく必要がある

    View full-size slide

  13. 現在の開発組織と
    開発生産性への取り組み
    タイミーの開発組織の文化やコンセプトと、開発生産性向上のために取り組んでいること

    View full-size slide

  14. 組織と開発生産性に関するタイミーのバイブル
    タイミーの組織文化や組織設計の根底を理解するために必読の本

    View full-size slide

  15. 学習する組織に根ざしたプロダクトマネジメント
    個人的に物凄くおすすめのプロダクトマネジメント本です

    View full-size slide

  16. タイミーが提供する顧客価値

    View full-size slide

  17. 17
    サービス開発組織の全体像

    View full-size slide

  18. チームの実例 (マッチング領域)
    領域の中に含まれるサブテーマごとにスクラムチームが内包されている
    Spotify におけるトライヴとスクアドの関係に限りなく近い
    Working Relation Marketing Enhance New Team
    PO(PdM) SM Backend
    Android iOS
    iOS Analyst Desinger
    PO(PMM) SM Backend
    Android iOS iOS
    Desinger
    (兼務)
    PO
    (兼務)
    SM
    (兼務)
    Backend
    Backend Frontend Frontend
    Desinger
    (兼務)
    Android
    Backend

    View full-size slide

  19. チームトポロジーによるチームパターン
    現在のタイミーの価値提案を目的とするチームパターン
    マッチング領域
    (Stream Aligned Team)
    開発プラットフォーム領域
    (Platform Team)
    スポットワークシステム領域
    (Stream Aligned Team)
    SAチームのストリーム
    ユーザージャーニーに基づくチームと考えられる
    SAチーム間のインタラクション
    お互いに Backend API を提供しあう
    X-as-a-Service 形式
    PFチームのObjectives
    Availability/Deploy
    Frequency/Security/Cost Reduction/Toilの
    撲滅
    SAチームとのインタラク
    ション
    SAチームの認知負荷を巻き取り
    内部サービスとして構築し
    X-as-a-Service として振る舞え
    るほどまでは成熟していないた
    め、コラボレーション型になって
    いる
    変更フロー

    View full-size slide

  20. SAチームのフロー効率を高める (1/3)
    Product Manager の多くにエンジニアリングバックボーンを推奨している理由
    PBI は顧客への価値提案以外のタスクが存在する
    顧客への価値提案以外に、例えば技術負債の解消や、品質管理、セキュリティ対応など直接的に顧客に対する価
    値提案につながらない PBI が存在し、これらは横断して開発優先度を決める必要がある。いずれの PBI もビジネ
    スインパクトや実現難易度、確度の判断にエンジニアリングの知識が求められる
    摂理面の検討や逆コンウェイの法則に基づく適切なソフトウェアアーキテクト
    スケール可能なソフトウェアとしていくために、最適な摂理面をプロダクトマネジメントの観点(顧客への価値提
    案の KPI がどのユーザージャーニーの重要 KPI に紐づくか等)を元にして、ビジネスドメインに基づくソフトウェ
    アの分割の方向性を示すには、ソフトウェアアーキテクトの知識があると良い

    View full-size slide

  21. SAチームのフロー効率を高める (2/3)
    DevOps Capabilities の向上と、ストリームアラインドチームの Best Practice の実践
    開発・プロセスのケイパビリティ
    トランクベースの開発を行い、テストカバレッジを高め、CIの実行時間が 10min を超えないようにするよう努
    め、デプロイフローを継続的に改善するなど、CI/CD の信頼性を高め、リスクの低いプロセスになるようにして
    います
    結果的に、カバレッジは95%前後を維持しており、5times/day のデプロイ頻度を実現しています
    またモニタリングやオブザーバビリティをSAチームの開発者自身で行う事でビジネスの変化をセンシングし、障
    害の徴候を捉え迅速に検知・復旧を行えるようにしています
    またチームをストリームアラインドチームとする事で、チームの検証や変更承認の効率化を実現しています
    カルチャーのケイパビリティ
    学習文化を促すために TDE10 (Timee Dev Enable) を策定。様々な形で学習するメンバーを支援しています

    View full-size slide

  22. 10の新制度を運用開始[ TDE10(Timee Dev Enable)]
    プロダクト部は、新しいプロダクトやサービスを創造するために必要な、成長支援制度を運用しメンバーのクリエイティブを支えること
    を目指しています。「DevEnable室」と「10の新制度」をご紹介します。
    22
    詳しく見る

    View full-size slide

  23. SAチームのフロー効率を高める (3/3)
    スクラムガイドの考え方をベースに、自律的なチーム運営を行うために、PM(PO)と専任SM、弱めのEMの三位一体でスクラムチーム
    の運営やピープルマネジメントを分担する
    専任のスクラムマスター(SM)を配置する
    専任のスクラムマスターを置くことで、POであるPMが強いプロダクトゴールの策定
    や PBI のメンテナンスに集中し、ふりかえりとリーンスタートアップによるダブル
    ループ学習に集中出来るようにしています
    弱めの EM が PM とニコイチになり、戦略から個人OKRへの落とし込
    み、組織の足並みを揃え、戦術遂行に必要な人材アサインをバックアップ
    EMが弱めのEMとしてPMと対になり、サーバント型のピープルマネジメントに集中す
    ることで、PMが示すプロダクトゴールを深く理解し、開発者の個人OKR策定に落とし
    込む事で、組織としての方向性がプロダクトゴールの実現に向けて前を向けるように
    しています
    出典: estherderby.com

    View full-size slide

  24. Four Keys / DevOps Capabilities の重要性
    DevOps Capabilities 向上のための取り組みに対する定量的な評価と、組織的なパフォーマンスの向上というアウトカムの実現のため
    に必要な指標
    全てはビジネスゴールとプロダクトビジョンの達成のため
    技術やプロセス、文化などのケイパビリティを向上するのは、ビジネス
    ゴールやプロダクトビジョンの達成のために実施しています
    その中間指標となる Four Keys を健全な状態に保ち、向上させて行くこ
    とは、最終的な目標であるビジネスゴールやプロダクトビジョンの達成
    のために欠かせないものと考えています
    出典: dora.dev

    View full-size slide

  25. 開発生産性と組織に関わる今の課題
    組織のケイパビリティを高め、開発生産性を維持・向上させながら、組織を大きくしていく際の課題

    View full-size slide

  26. 適切な摂理面の探索が出来ていない (1/2)
    ユーザーペルソナやバリューチェーンでソリューションが綺麗に分かれないため、自然な摂理面が見いだせていない
    バリューチェーン
    ユーザー
    ペルソナ

    View full-size slide

  27. 適切な摂理面が探索できていない (2/2)
    ユーザージャーニーをストリームとして扱っていることの難しさ
    マッチングプラットフォームゆえの両サイドのユーザーペルソナ
    ソリューションの多くがワーカー/事業者(法人・店舗など)の双方に影響を及ぼすものが多い。(求人出稿など)
    従ってユーザーペルソナを摂理面にしづらい
    バリューチェーン上の川上にあるプロセスが川下のプロセスに密接に関わる
    勤怠管理が給与計算のベースとなるなど、プロセス間の依存関係が強く存在するため、バリューチェーン上のプ
    ロセスというビジネスドメインで摂理面を設定する事が難しい
    結果としてモノリスとしている
    摂理面をうまく探索出来ていないため、結果として意図的に Ruby on Rails のモノリスのままにしている

    View full-size slide

  28. どこまでをプラットフォームとするか
    SAチームの自律性と適切な認知負荷をプラットフォームの内部サービスにする境界線
    SAチームによる自律的なDevOps
    結果として、Build/Test/Deploy/OperateといったSoftware Delivery Life
    Cycle(SDLC)を SA チームが自律的に行うことで、プラットフォームチーム
    の役務が Infrastracture (Cloud Infra や Network) を中心とした内部サービ
    スにとどまりがちになる
    結果的に SA チームが SDLC に必要なケイパビリティを強く持たなくてはな
    らない
    セキュリティや品質管理の立ち位置
    セキュリティのシフトレフトや脆弱性診断、CI/CDでのDevSecOpsの実現な
    や、品質管理におけるSET Infra の構築や、シナリオテストの計画や実装、
    ソフトウェア品質の評価など、高度な専門知識が求められる領域に対して、
    チームトポロジーにおけるパターンでどう表現するか
    Stream-aligned team
    Platform team
    Build Test Deploy Operate
    Infrastracture
    Collabora
    tion
    XaaS
    Facilita
    ting

    View full-size slide

  29. ラディカル・プロダクト・シンキング
    「リーンとアジャイルは目的地を示さない」問題に、チームトポロジーでどう立ち向かうか
    小さな自律したチームのプロダクトゴールは Fore Casting になりがち
    リーンとアジャイルという短い期間のイテレーティブな探索と実践は、目前の課題に向き
    がちで小さなプロダクトゴールを追い求め、本当に向かいたいプロダクトビジョンの実現
    を真っ直ぐに指し示さない
    Now Future
    Product
    Vision
    Back Casting
    Fore
    Casting

    View full-size slide

  30. 課題に対して
    取り組もうとしていること
    これからタイミーが向き合っていく課題に対する打ち手として VPoT として考えていること

    View full-size slide

  31. 摂理面の探索
    学びながら適切な摂理面のコンセンサスを得ていく
    初手としてのモジュラモノリス化
    適切な摂理面の探索が難しいことは変わらないので、まずはバリューチェーン
    のプロセスごとにモジュラモノリス化を実施していく
    解くべきオポチュニティ(ペインやニーズ)の探索、開発を通じてモジュラモノリ
    ス化したモジュールのどこが摂理面として適切化を学習していく
    規制やリスク、技術といった摂理面で切り離す
    お金に関わる部分や個人情報や機微情報、API Economy 実現のための Identity
    Platform (OAuth/OIDC)など、分けるべくして分ける摂理面から切り離してい

    特定の SA チームから XaaS されるシステムは Complicated Subsystem とし
    て、あらゆる SA チームから XaaS されるシステムは Platform として扱ってい

    Stream-aligned team
    Complicated
    Subsystem
    team
    Monolish
    Moduler
    Monolish
    Micro
    Services
    Secure
    Micro
    Services
    Identity
    Platform
    XaaS
    Platform team

    View full-size slide

  32. PlatformとEnablingを使い分ける (1/2)
    SAチームとPlatformチームでコラボレーションを深めながら、優先度の高い認知負荷を見出し、内部サービス化するかイネイブリング
    するかを見極めていく
    SDLC のあらゆるプロセスで仕分ける
    SAチームとPlatformチームがコラボレーションを深める中で、特定のSA
    チームが継続的に開発・運用すべき顧客に対する価値提案の根幹に関わる
    部分は Enabling する形で支援し、あらゆるSAチームの認知負荷は内部
    サービス化するようなコンセンサスを積み上げていく
    またコラボレーションの過程で必要になった専門知識は採用などでカバー
    していく
    Stream-aligned team
    Platform team
    Build Test Deploy Operate
    Infrastracture
    XaaS
    Facilita
    ting
    Enabling team

    View full-size slide

  33. Platform と Enabling を使い分ける (2/2)
    Security と品質管理のあり方を考える
    Security のあり方
    脆弱性診断はレッドチームとして検証し、DevSecOps については CI/CD プロセスに組み込むなどを行い、
    Platform チームとして振る舞う。
    一方でシフトレフトや、脆弱性対応については Enabling チームとして SA チームを支援していくスタイルを取
    る。
    品質管理のあり方
    品質分析(観点カバレッジやDDPモニタリングなど)の実施や、障害分析、SET Infra の提供、SET ライブラリの
    開発などは Platform チームとして振る舞い、SET Infra やライブラリの利用浸透、品質改善の推進は Enabling
    チームとして SA チームを支援していくスタイルを取る。

    View full-size slide

  34. ラディカルでスケールする組織設計 (1/2)
    目的や文化を明確にして Spotify モデルの組織設計を参考にしていく
    SAチームをトライブとスクアッドに分ける
    現在のチームの考え方もトライブとスクアッドのような構成になっている
    トライブとスクアッドの関係性を時間軸(中長期/短期)と粒度(俯瞰/具体)で分け
    て、トライブがトライブ内のオポチュニティの探索とソリューションの方向性や
    オプションの検討を行うなどしてプロダクト戦略の枠を決めて、各スクアッドに
    戦略の展開を行っていく。
    出典: blog.crisp.se

    View full-size slide

  35. Tribe
    ラディカルでスケールする組織設計 (2/2)
    TribeとSquadの関係性にフレームを導入して、ダブルループ学習を行う自律的で柔軟性のあるラディカル・プロダクト・シンキングを
    実現する
    Tribe/Squad間でのダブルループ学習を行う
    Squad はこれまで通りリーンとアジャイルな開発を志向し、Tribe で
    は課題の探索・検証やリフレーミングや適応課題、クリエイティブ・
    テンションなどを用いた改革を Squad にフィードバックする。
    Tribe では粒度の大きな課題の蓄積・探索を中長期スパンのイテレー
    ションで実施し、優先度を付けてプロダクトイニシアチブを策定して
    ソリューションに制約としての方向性を示す。
    経営との接続
    経営の意思として事業戦略としての戦略的意図が存在する形にした上
    で、戦略的意図に沿った解くべき課題の選定とプロダクトイニシアチ
    ブの策定、戦略的ロードマップの作成を持ってプロダクト戦略とし、
    これをすべての Tribe/Squad に浸透させて推進していく。
    Squad
    結果
    行動
    Squad
    結果
    行動
    前提・枠組み・
    メンタルモデル
    改善 改善
    改革
    改革
    Probl
    em
    Probl
    em
    Probl
    em
    Probl
    em
    プロダクトイ
    ニシアチブ
    Solu
    tion
    Solu
    tion
    Solu
    tion
    Solu
    tion

    View full-size slide

  36. まとめ
    タイミーにおける「組織をスケールさせるための Four Keys とチームトポロジー」に対する取り組み
    急成長するスポットワーク業界
    まだまだ社会課題としての人材不足や働き方の多様性をなめらかにしていくためのオポチュニティは膨大にあ
    り、事業としてもさらなる成長が期待できます
    タイミーが解決しなければならない課題は山積しています
    開発生産性に対する取り組み
    チームトポロジーや Lean と DevOps の科学などの背景知識を元に、良いプラクティスを取り入れ、技術・プロ
    セス・文化のケイパビリティを向上させるために、オペレーションを設計し実践しようとしています
    これからの課題
    チームトポロジーを軸にした組織設計と急成長していくなかで組織をスケールさせるための課題に対する取り組
    みを、継続的に取り組んでいきます

    View full-size slide

  37. (Ad) タイミーでは様々な職種で積極採用中です
    一緒に開発生産性を高めて、ラディカルにプロダクト開発をしていく仲間を募集中です
    エントランスブック :
    Timee Product Org Entrance Book
    プロダクト社員やカルチャー紹介 :
    Product note
    エンジニア向け成長支援制度 :
    TDE10
    エンジニア技術ブログ :
    Timee Product Team Blog
    オンラインイベントのアーカイブ :
    Youtube アーカイブス
    募集中の職種一覧 :
    採用情報

    View full-size slide

  38. Any Questions?

    View full-size slide