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

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

View Slide

自己紹介
山口徹 | @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 Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

チームトポロジーによるチームパターン
現在のタイミーの価値提案を目的とするチームパターン
マッチング領域
(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 Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

View Slide

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

View Slide

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

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 Slide

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

View Slide

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

View Slide

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 Slide

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

View Slide

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

View Slide

Any Questions?

View Slide

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

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

Toru Yamaguchi a.k.a zigorou

Other Decks in Technology

Featured

Transcript