Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 山口 徹 | @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月にタイミーに転職したばかりです。 ひょんな事から今月からプロダクトマネジメント組織を管掌する事になりました。 普段はお料理系男子です。

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

チームの実例 (マッチング領域) 領域の中に含まれるサブテーマごとにスクラムチームが内包されている 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

Slide 19

Slide 19 text

チームトポロジーによるチームパターン 現在のタイミーの価値提案を目的とするチームパターン マッチング領域 (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 として振る舞え るほどまでは成熟していないた め、コラボレーション型になって いる 変更フロー

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

どこまでをプラットフォームとするか 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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Any Questions?