タイミーを支えるプラットフォームエンジニアリング・成果指標設計から考える組織作り事例の紹介

Transcript

1. 2024/07/09　Platform Engineering Kaigi 2024 タイミーを支えるプラットフォームエン ジニアリング・成果指標設計から考える 組織作り事例の紹介 Takuya Onda
2. 登壇者情報 
 恩田 拓也
 (おんだ たくや) 
 経歴
 入社
 役割
 ※写真を挿入※ プロダクト本部
 プラットフォーム エンジニアリング部 
 部長
 2023年6月
 新卒でゲームプラットフォーム事業を展開するIT企業に入社後、バッ クエンドエンジニアとしキャリアをスタート。 
 マッチングアプリを制作・運営する企業に転職後はインフラ・SRE領域 を担当。SRE、情シス、セキュリティ部門の技術統括を経て2023年6月 にタイミーに入社。
 現在はプラットフォームエンジニアリンググループのエンジニアリング マネージャーを務めています。 

3. 今日の話 • AWS - インフラ領域のタスクを消化する所謂インフラチームから プラットフォームエンジニアリングを体現するチームへ進化するた めの1年間の取り組みの実体験です。(テクノロジーの話ほぼゼロ) • これが正解だったとは限りませんし、今でも正直わかりませんが、 これからプラットフォームエンジニアリング組織を立ち上げる方の 参考になれば幸いです。
4. タイミーについて
5. タイミーとは 5 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求人サイト」でも「派遣」でもない
6. タイミーの特徴 6
7. タイミーの使われ方 働き手と雇い手がいるBtoCプラットフォームを提供しています。外からは見えづらいですが、スポットワークを実現するための雇い手 の手続きや課題は多く、そのプロセスのほとんどをシステム化しています。 7
8. サービスの特徴 ワーカー向けのNativeアプリとクライアント企業向けのWeb 管理画面を提供している システム構成概要 • AWS x マネージドサービスを多数利用 • バックエンドアプリケーションはRuby on Rails x モノ リス構成 システムの特徴 • ワーカ向けアプリはtoCアプリ特有のWrite Heavy x スパイキーなトラフィック • クライアント向けは出退勤、労働管理、給料支払な ど、ゴールデンパスの信頼性が重要。 タイミーのシステム解説
9. タイミーのプラットフォーム エンジニアリングへの 取り組み
10. 今日の話 (再掲) • AWS - インフラ領域のタスクを消化する所謂インフラチームから プラットフォームエンジニアリングを体現するチームへ進化するた めの1年間の取り組みの実体験です。(テクノロジーの話ほぼゼロ) • これが正解とは限りませんし、今でも正直課題だらけですが、これ からプラットフォームエンジニアリング組織を立ち上げる方の参考 になれば幸いです。
11. 前提 - タイミーの開発組織 チームトポロジーでいうところの複数の Stream Aligned Team + Platform Teamで構成
12. 12 Engineering Manager 12 タイミーの標準的なストリームアラインドチーム
13. 前提 - タイミーの開発組織
14. 　　マッチングTribe
 　　（ストリームアラインドチームの集合）
 　　スポットワークシステムTribe
 　　（ストリームアラインドチームの集合）
 
 
 QA&
 Process Enabling チーム
 （イネイブリング 
 チーム）
 
 
 開発プラットフォームTribe
 （プラットフォームチーム）
 ファシリテー ション
 コラボレーション
 ファシリテー ション
 X-as-a-Service
 X-as-a-Service
 SAチーム間のインタラクション 
 
 ユーザージャーニーに基づくSAチームは機能 領域においてAPIを提供し、X-as-a-Serviceと して振る舞い、時に共通の顧客価値のために コラボレーションして開発する 
 開発プラットフォームTribe 
 
 組織の初期段階ではコラボレーション型で強く 連携し開発を進めていたが、組織の段階的な 成熟により、X-as-a-Service型に移行している 
 
 ＊人数：3人(2023/6) → 13人(2024/7) 
 イネイブリングチームの振る舞い 
 
 特定の専門領域においてCenter of Practiceと して主にファシリテーション型でSAチームと関 わるが、新しい技術や知見の導入時には意図 的にコラボレーション型を用いて深く関与し進 行する
 （SAチームへのEmbed） 
 14 チームトポロジーの切り口から見た組織構造 出典：実践チームトポロジー：プラットフォーム性とイネイブリング性の戦略 https://docs.google.com/presentation/d/1ux43ud88YQ6i-TKP_LVWowoUCb m36GP325zbSFhPQ6Y
15. 過去の振り返り
16. プラットフォームチーム設立の背景 • 設立前：Stream Aligned Teamだけが存在する状態 • 経営の関心事としての 1. プロダクトの変更と拡張に対する機動 力、2. サービスの信頼性, 3. 適切なコスト運用 これを実現するチー ムとして生まれた(らしい)、
17. 1年前のプラットフォームチーム状況 - バックログ編 1. [一言でまとめると] なんかチケットいっぱいあるぞ、、！ 2. 他チームからの改善依頼が色々積まれてたり (ブロッキング含) 3. どうやって優先度つけるの状態 (声大きい人が言ったもん勝ち感) 4. 心の声 (このタスクうちのチームでやるの、、？)
18. 1年前のプラットフォームチーム状況 -コラボレーション編 1. チームのアウトカム (プラットフォームエンジニアリング..?)につい て、何をどう顧客に提供するのかが定まっていない。 2. 開発現場で起きている課題やシステム品質課題の改善に向けた一次 情報収集を行う座組やコラボレーションの場が存在しない。 3. チームの活動報告を受けた上司の心の声 (今取り組んでる事はわ かったけど、結局どこを目指してるかわからないな,,)
19. Gap分析 チームの存在意義(提供する価値)、戦略、成果指標、バックログ、およ びイテレーションサイクルがつながっておらず、インフラ/AWS関連の 散発的なタスク消化を日々続ける状態を脱する必要があると考えた。 目指す状態
20. 取り組んできた事 1. 何に取り組むチームか/どう取り組むチームかを言語化する。 2. 成果指標を定義し、バックログを作り直す。 3. 意思決定材料を収集するリズムを作る 4. コラボレーションモードの段階を定義する 5. アウトプットのインタフェースを整備する
21. 何に取り組む/どう取り組むチームか言語化する 1. 我々の顧客は誰か？ > タイミーのユーザ 2. 何を届けるべきか？ > タイミーというプロダクトのあたりまえ品質 3. どう届けるべきか？ > DevとOpsの協働による
22. SLI/SLO
 信頼性指標を観測可能(定義・収集）にしSAチームが自らリライアビリティとアジリティに対して DataDrivenな判断や議論を行えるようにSLOの定義など
 Monitoring/Alert
 ユーザー体験を損なう原因となっている項目に対するモニタリングを、SAチームがAPMなどを含め追加できる 状態
 Incident Response
 SAチームがユーザー影響、データ欠損などの事象に対する緊急対応を自律的に行え、コマンダーとし ての役割も全うすることができる状態
 Capacity Planning
 SAチームがメトリクスを元にシステム需要などを予測しコンピューティングリソースの追加を行うことがで きる状態
 Eliminating Toil
 SAチームがトイルの定義に基づいてトイルを発見することができる状態をリード
 22 何に取り組む/どう取り組むチームか言語化する Steam Aligned Teamがアプリケーション ~ インフラストラクチャまでの開発運用をソフトウェア エンジニアリングし、自律的にSRE Practiceを実践してリライアビリティとアジリティを管理でき るような状態を達成する。 信頼性エンジニアリングのイネーブルメント 

23. Release Engineering
 より素早く安全に機能をDeliveryでき、SAチームが自身で変更可能なCI/CD Pipelineを提供
 SLI/SLO Metrics
 SAチームがSLI/SLOを運用、メンテナンスできる仕組み（SLIの設定インターフェース、Dashboardなど） を提供
 IaC
 SAチームがコード(with Terraform/)で宣言的に定義するだけでインフラの開発運用をソフトウェア エンジニアリングできるIaC基盤を提供
 Monitoring/Log
 SAチームが自律的にObservability、アラート/モニタリングを向上できるようなPrimal Signal/Golden Signal収集基盤を提供
 GuardRail
 ベストプラクティスに沿ったコンポーネントの適切な設計及び実装ができる。 
 プラットフォームエンジニアリング 
 23 何に取り組む/どう取り組むチームか言語化する Stream Aligned Teamが高い開発生産性を維持しつつ、ソフトウェアの品質担保がしやすいツール や基盤を開発運用し、認知負荷及び運用負荷の低いインターフェースで提供する。
24. 取り組んできた事 1. 何に取り組むチームか/どう取り組むチームかを言語化する。 2. 成果指標を定義し、バックログを作り直す。 3. 意思決定材料を収集するリズムを作る 4. コラボレーションモードの段階を定義する 5. アウトプットのインタフェースを整備する
25. 成果指標(Key Results) を定義する • 掲げたミッションの達成度合いを数字によって計測可能にする。 • ソフトウェア品質とは何か？を定義し、その測定方法を考える 信頼性 セキュリティ システムコスト 開発生産性 可観測性 出典：ソフトウェアの品質モデル ISO/IEC 25010:2011 (JIS X 25010:2013) https://kikakurui.com/x2/X25010-2013-01.html
26. 成果指標(Key Results) を定義する マインドマップでの表現 • ソフトウェア品質とは何か？の共通認識をチームで作る 指標の一覧 (測り方 / 可観測性の成熟度)
27. バックログを作り直す。 • バックログ = 成果指標を「望む方向」に動かすために解決すべき「課題の一覧」 Key Result (成果指標) Backlog (解決すべき課題リスト)
28. バックログとKey Result(成果指標)の関係性 「何が」「いつ」リリースされる予定なのかを可視化 = ロードマップ (先行指標) Key Result(成果指標) はどのように 変化しているのかを可視化/観察する = 目標の進捗 (遅行指標) • バックログ = 成果指標を「望む方向」に動かすために解決すべき「課題の一覧」
29. [余談] 成果指標は観察するが目標にはしない • 指標は外部要因によっても容易に変動する。また、数値目標を成果や個人評 価と連動させると簡単にハックされる。 • 理想とのギャップがどこにあるか、解決対効果の高い「質の高い課題」が重 要。課題解消の完了による価値、つまり「結果として何の数字がどっちに振 れてたら私達としては勝ちだよね」の認識を揃えるための会話の道具。 • 目標へのコミットは「xxというKey Resultを向上させるために、yyというプ ロジェクトをyyyy/mm/ddまでに完了させる」という考え方をする。
30. [余談] 説明可能である事の価値 • 数字は嘘をつかないが、嘘つきは数字を使う • だが、数字で説明できない品質は品質ではない。(持論) • 経営からの信頼を得る、予算を編成する、営業組織に対する武器を与える事 (or 失注の原因を減らすこと)、様々な場面でプロダクト品質のアカウンタビ リティ(説明責任. Not Responsibility) を果たす事から逃げない。その中心的 役割を果たす。
31. 取り組んできた事 1. 何に取り組むチームか/どう取り組むチームかを言語化する。 2. 成果指標を定義し、バックログを作り直す。 3. 意思決定材料を収集するリズムを作る 4. コラボレーションモードの段階を定義する 5. アウトプットのインタフェースを整備する
32. 質の高い課題をあつめる- 一次情報の収集サイクル • システムメトリクスの観察をチームスクラムイベントに取り込む Key Result(ソフトウェア品質) に沿った システムメトリックス観測用ダッシュボード を複数用意。 毎週時間をかけチーム全員で観察、 傾向把握と課題検知 / 仮説立てを行う。 可観測性の不備、アラート設計に関する議論 も行う。 ＊その他不定期だがSteam Aligned Team所 属開発者への課題ヒアリング等も実施 チームのイテレーションサイクル
33. 取り組んできた事 1. 何に取り組むチームか/どう取り組むチームかを言語化する。 2. 成果指標を定義し、バックログを作り直す。 3. 意思決定材料を収集するリズムを作る 4. コラボレーションモードを定義する 5. アウトプットのインタフェースを整備する
34. プラットフォームとは何か？に立ち返ってみる
 A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.” デジタル・プラットフォームは、セルフサービスAPI、ツール、サービス、 ナレッジ、サポートの基盤であり、魅力的な社内製品として配置される。自 律的なデリバリー・チームは、プラットフォームを活用することで、調整を 減らしながら、より速いペースで製品機能を提供することができる。" 出典：CNCF Platforms White Paper https://tag-app-delivery.cncf.io/whitepapers/platforms/
35. 価値提供の方法を考える
 35 ストリームアラインドチーム 
 イネイブリン グチーム
 
 
 ファシリテーショ ン
 コンプリケイテッド・サブシ ステムチーム
 X-as-a-Service
 X-as-a-Service
 プラットフォームチーム 
 35 • X-as-a-Serviceは高コストな価値提供方法
36. コラボレーションモードの段階を作り、価値提供方 法を使いわける 1. X-as-a-Service - Platform Teamの提供するサービスの利用 2. 技術のEnabling / GuardRail 3. 依頼を受け付ける 4. Joint Team (有期チーム) 5. Embedded Member 参考文献：チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計
37. Platform Tribeの提供するサービスの利用 Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため に、一切のコミュニケーションを必要としない(ノンブロッキ ング)。 どんな時に有効か 定常的に発生する作業など、完全自動化による恩恵が大きい 業務フローにまつわる作業。(提供価値としては高コストな部 類なので、提供対効果の高い業務プロセスの見極めが重要) 具体例 アプリケーションのデプロイ、DDL、各種インフラのプロビ ジョニングに用いるTerraform x CI/CD Pipeline + Module提 供 / ユーザマニュアル等 ストリームアラインドチーム 
 プラットフォームチーム 
 X-as-a-Service

38. 技術のEnabling / GuardRail Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため に、Platformが技術サポートやノウハウの共有を行う。 どんな時に有効か 顧客(Stream Aligned Team)が自身で課題解決できる技術ケイ パビリティ獲得を必要とする(した方がよい) 時。 ある程度顧客ニーズのパターン化が見える場合、マニュアル を超えたX-as-a-serviceとしての提供を視野にいれる。 具体例 機密情報管理手法の相談、監視設計やモニタリングの課題相 談、etcc ストリームアラインド
 チーム
 プラットフォーム
 チーム

39. 依頼を受け付ける Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため に、その工数負担も含めPlatform Teamが依頼を受け担当す る。 どんな時に有効か 顧客(Stream Aligned Team)にとって課題内在性負荷が高い技 術課題の解決 & 顧客が自身で課題解決できるケイパビリティ獲 得を必要としない。チーム目線ではToil解消の文脈でマニュア ルによるセルフサービス化やX-as-a-serviceとしての提供へ 発展するケースあり。 具体例 新規AWSアカウントの用意。(X-as-a-Serviceとしてセルフ サービス用意の仕組みも提供も可能だが、頻度的に弊社では 依頼パターンで対応) ストリームアラインドチーム 
 プラットフォームチーム 
 Via Team Comm Interface

40. Joint Team (有期チーム) Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため に、プロジェクト単位で仮想チームを結成。定期的なミー ティングによる進捗確認や課題把握等を行いつつ、実作業も 担当する どんな時に有効か 3ヶ月 ~ かかる大型プロジェクト x 計画当初から明確に顧客 (Stream Aligned Team) の技術的ケイパビリティ(主にクラウ ドインフラ関連) が足りていない場合など。 具体例 中 ~ 大規模な新機能実装、リファクタリング、パッチアップ デート(メジャーバージョンアップ)等 ストリームアラインド
 チーム
 プラットフォーム
 チーム
 Joint Team 
 x 
 有期プロジェクト

41. Embedded Member (短期移籍) Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため に、顧客チームにPlatform Teamメンバーが一時的に異動。 異動先のスクラムイベント参加など異動先のメンバーの一員 として振る舞う。 どんな時に有効か 3ヶ月 ~ かかる大型プロジェクト x 計画当初から明確に顧客 (Stream Aligned Team) の技術的ケイパビリティ(主にクラウ ドインフラ関連) が足りていない場合など。かつ、顧客チー ムに強度を持って専門知識の伝達、自走を促したい場合など 具体例 新規サービスの立ち上げ、システムをフルスクラッチで構築 が必要な大型プロジェクト等 ストリームアラインド
 チーム
 プラットフォーム
 チーム

42. 目的や状況に合わせたインタラクションの選択 インタラクションの期待値をなる早ですり合わせる 事業戦略 / プロダクトイニシアチブの状況、プロジェクトの キックオフ、etc,,, 様々なソースから情報を取りにいく > プ ロジェクトに巻き込まれにいく姿勢。(Platform evolution via clear team interactions) プラットフォームとして提供価値の高い業務プロセ スを見極める 重厚なInternal Developer Platformを作る事を目的としな い。ユーザ価値提供のために今取れる最善の手段を選択す る。また提供対効果の高い業務プロセスの見極めのためのイ ンタラクション 顧客にとってのToil / バリューストリーム上の9つの大罪(部 分的に完了した仕事、余分な処理、余分な機能、タスクの切 り替え、待機、動作、製品不良、非標準的な作業や手作業、 超人的な作業)を取り除けるかを重視する。 参考文献：チームトポロジー・価値あるソフトウェアをすばやく届ける技術
43. 取り組んできた事 1. 何に取り組むチームか/どう取り組むチームかを言語化する。 2. 成果指標を定義し、バックログを作り直す。 3. 意思決定材料を収集するリズムを作る 4. コラボレーションモードを定義する 5. アウトプットのインタフェースを整備する
44. アウトプットのインタフェースを整備する 1. 開発者向けマニュアル 2. リリースノート 3. Design Docs 4. Architecture Docs テキストコミュニケーションのインタフェースを標準化する事で、情報の 粒度/質を均一化しアウトカムの伝達度を高めつつ、コラボレーションのコ ストを下げる (＊弊社は100%リモートワークです)
45. 開発者向けマニュアル 概要 社内開発者を顧客としたシステム利用マニュアル。顧客が自 力で業務ニーズを解決できる事を目的としている。 フォーマット • どんなニーズを解決するマニュアルなのか • 誰を想定読者としているか • 解決方法 • 関連するPRリンク・資料URL 提供のタイミング 任意。ドキュメント化されてない事で「依頼」のインタラク ションパターンが頻発している場合、提供対効果が高いと考 えられるので優先度を上げて作成するケースが多い。
46. リリースノート 概要 Platform Teamの作業やリリース等に伴い、ユーザ影響が発 生する/社内業務フローの変更(+/-どちらの変更も) が見込ま れる場合に作成する社内告知用ドキュメント フォーマット • 変更内容 • リリース日時 • ユーザへの影響 • 社内従業員への影響 • 事業インパクト 提供のタイミング チームの作業やリリース等で従業員 / 顧客の業務ワークフ ローに変更社内告知等が必要な際に、リリース前に猶予期間 をもって提供。X-as-a-Serviceの提供時も出す。
47. Design Docs 概要 プロジェクトを主語として、プロジェクトの提案/開始時およ び実行途中に作成するドキュメント。Platform Team内、も しくは顧客(Stream Aligned Team)と設計議論の叩きに用い る フォーマット • 解決したい課題 • プロジェクトの完了条件 • 解決方針(選定技術) • トレードオフ • 社内開発者/従業員へのワークフローへの影響 提供のタイミング プロジェクトの提案/開始時および実行途中に作成。設計段階 でチーム・およびステークホルダーへ共有し解決方針を意思 決定する。
48. Architecture Docs 概要 社内開発者を想定読者として、各システムについて何かを知 りたいと思ったときのファーストランディングページとなる ことを目的としたドキュメント。読者がシステムの構成 / 仕 様 の概要が把握できることをゴールとしている。 フォーマット 任意。構成図等をセットで提供する事が多い。変更背景とし てDesign Docsを添える事で、過去のアーキテクチャ選定背 景を伝える事も意図している。 提供のタイミング プロジェクト完了のタイミング。ドキュメント化されてない 場合、日々のチームインタラクションの中で提供対効果が高 いと思われる場合は優先度を上げて作成するケースもある。
49. まとめ・取り組んできた事 1. 何に取り組むチームか/どう取り組むチームかを言語化する。 2. 成果指標を定義し、バックログを作り直す。 3. 意思決定材料を収集するリズムを作る 4. コラボレーションモードの段階を定義する 5. アウトプットのインタフェースを整備する
50. 一年を振り返っての失敗 Stream Aligned Teamとのコラボレーションの量・質 コラボレーションモード、インタフェースの定義とパターニング はあくまでコラボレーションをしやすくするための装置。顧客 (Stream Aligned Team)のバーニングニーズや一次情報をチーム が分離された状況で取り続ける事は難しい。とはいえ深く入りこ まないと課題は見えてこない(アンケート等の限界) ビジョンフィットよりもサバイバル優先 Platform Engineering Teamがゲートキーパー・業 務ブロッキングは減りつつも、DevとOpsの協働というより 分業・巻取りによる品質向上への取り組みに流れ勝ち。(右上 が理想。現実は右下）。やらないといけない事 > やりたい事 のバランス
51. 検索 タイミー ご清聴ありがとうございました