Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

takuya542
July 12, 2024
3.3k

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

takuya542

July 12, 2024
Tweet

More Decks by takuya542

Transcript

  1. 登壇者情報 
 恩田 拓也
 (おんだ たくや) 
 経歴
 入社
 役割


    ※写真を挿入※ プロダクト本部
 プラットフォーム エンジニアリング部 
 部長
 2023年6月
 新卒でゲームプラットフォーム事業を展開するIT企業に入社後、バッ クエンドエンジニアとしキャリアをスタート。 
 マッチングアプリを制作・運営する企業に転職後はインフラ・SRE領域 を担当。SRE、情シス、セキュリティ部門の技術統括を経て2023年6月 にタイミーに入社。
 現在はプラットフォームエンジニアリンググループのエンジニアリング マネージャーを務めています。 

  2. サービスの特徴 ワーカー向けのNativeアプリとクライアント企業向けのWeb 管理画面を提供している システム構成概要 • AWS x マネージドサービスを多数利用 • バックエンドアプリケーションはRuby

    on Rails x モノ リス構成 システムの特徴 • ワーカ向けアプリはtoCアプリ特有のWrite Heavy x スパイキーなトラフィック • クライアント向けは出退勤、労働管理、給料支払な ど、ゴールデンパスの信頼性が重要。 タイミーのシステム解説
  3.   マッチング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
  4. SLI/SLO
 信頼性指標を観測可能(定義・収集)にしSAチームが自らリライアビリティとアジリティに対して DataDrivenな判断や議論を行えるようにSLOの定義など
 Monitoring/Alert
 ユーザー体験を損なう原因となっている項目に対するモニタリングを、SAチームがAPMなどを含め追加できる 状態
 Incident Response
 SAチームがユーザー影響、データ欠損などの事象に対する緊急対応を自律的に行え、コマンダーとし ての役割も全うすることができる状態


    Capacity Planning
 SAチームがメトリクスを元にシステム需要などを予測しコンピューティングリソースの追加を行うことがで きる状態
 Eliminating Toil
 SAチームがトイルの定義に基づいてトイルを発見することができる状態をリード
 22 何に取り組む/どう取り組むチームか言語化する Steam Aligned Teamがアプリケーション ~ インフラストラクチャまでの開発運用をソフトウェア エンジニアリングし、自律的にSRE Practiceを実践してリライアビリティとアジリティを管理でき るような状態を達成する。 信頼性エンジニアリングのイネーブルメント 

  5. 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が高い開発生産性を維持しつつ、ソフトウェアの品質担保がしやすいツール や基盤を開発運用し、認知負荷及び運用負荷の低いインターフェースで提供する。
  6. 質の高い課題をあつめる- 一次情報の収集サイクル • システムメトリクスの観察をチームスクラムイベントに取り込む Key Result(ソフトウェア品質) に沿った システムメトリックス観測用ダッシュボード を複数用意。 毎週時間をかけチーム全員で観察、

    傾向把握と課題検知 / 仮説立てを行う。 可観測性の不備、アラート設計に関する議論 も行う。 *その他不定期だがSteam Aligned Team所 属開発者への課題ヒアリング等も実施 チームのイテレーションサイクル
  7. プラットフォームとは何か?に立ち返ってみる
 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/
  8. 価値提供の方法を考える
 35 ストリームアラインドチーム 
 イネイブリン グチーム
 
 
 ファシリテーショ ン


    コンプリケイテッド・サブシ ステムチーム
 X-as-a-Service
 X-as-a-Service
 プラットフォームチーム 
 35 • X-as-a-Serviceは高コストな価値提供方法
  9. コラボレーションモードの段階を作り、価値提供方 法を使いわける 1. X-as-a-Service - Platform Teamの提供するサービスの利用 2. 技術のEnabling /

    GuardRail 3. 依頼を受け付ける 4. Joint Team (有期チーム) 5. Embedded Member 参考文献:チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
  10. Platform Tribeの提供するサービスの利用 Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため に、一切のコミュニケーションを必要としない(ノンブロッキ

    ング)。 どんな時に有効か 定常的に発生する作業など、完全自動化による恩恵が大きい 業務フローにまつわる作業。(提供価値としては高コストな部 類なので、提供対効果の高い業務プロセスの見極めが重要) 具体例 アプリケーションのデプロイ、DDL、各種インフラのプロビ ジョニングに用いるTerraform x CI/CD Pipeline + Module提 供 / ユーザマニュアル等 ストリームアラインドチーム 
 プラットフォームチーム 
 X-as-a-Service

  11. 技術のEnabling / GuardRail Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため

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

  12. 依頼を受け付ける 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

  13. Joint Team (有期チーム) Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため

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

  14. Embedded Member (短期移籍) Stream Aligned Teamとのコラボレーション 顧客(Stream Aligned Team) がやりたい事を実現するため

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

  15. 目的や状況に合わせたインタラクションの選択 インタラクションの期待値をなる早ですり合わせる 事業戦略 / プロダクトイニシアチブの状況、プロジェクトの キックオフ、etc,,, 様々なソースから情報を取りにいく > プ ロジェクトに巻き込まれにいく姿勢。(Platform

    evolution via clear team interactions) プラットフォームとして提供価値の高い業務プロセ スを見極める 重厚なInternal Developer Platformを作る事を目的としな い。ユーザ価値提供のために今取れる最善の手段を選択す る。また提供対効果の高い業務プロセスの見極めのためのイ ンタラクション 顧客にとってのToil / バリューストリーム上の9つの大罪(部 分的に完了した仕事、余分な処理、余分な機能、タスクの切 り替え、待機、動作、製品不良、非標準的な作業や手作業、 超人的な作業)を取り除けるかを重視する。 参考文献:チームトポロジー・価値あるソフトウェアをすばやく届ける技術
  16. アウトプットのインタフェースを整備する 1. 開発者向けマニュアル 2. リリースノート 3. Design Docs 4. Architecture

    Docs テキストコミュニケーションのインタフェースを標準化する事で、情報の 粒度/質を均一化しアウトカムの伝達度を高めつつ、コラボレーションのコ ストを下げる (*弊社は100%リモートワークです)
  17. 開発者向けマニュアル 概要 社内開発者を顧客としたシステム利用マニュアル。顧客が自 力で業務ニーズを解決できる事を目的としている。 フォーマット • どんなニーズを解決するマニュアルなのか • 誰を想定読者としているか •

    解決方法 • 関連するPRリンク・資料URL 提供のタイミング 任意。ドキュメント化されてない事で「依頼」のインタラク ションパターンが頻発している場合、提供対効果が高いと考 えられるので優先度を上げて作成するケースが多い。
  18. リリースノート 概要 Platform Teamの作業やリリース等に伴い、ユーザ影響が発 生する/社内業務フローの変更(+/-どちらの変更も) が見込ま れる場合に作成する社内告知用ドキュメント フォーマット • 変更内容

    • リリース日時 • ユーザへの影響 • 社内従業員への影響 • 事業インパクト 提供のタイミング チームの作業やリリース等で従業員 / 顧客の業務ワークフ ローに変更社内告知等が必要な際に、リリース前に猶予期間 をもって提供。X-as-a-Serviceの提供時も出す。
  19. Design Docs 概要 プロジェクトを主語として、プロジェクトの提案/開始時およ び実行途中に作成するドキュメント。Platform Team内、も しくは顧客(Stream Aligned Team)と設計議論の叩きに用い る

    フォーマット • 解決したい課題 • プロジェクトの完了条件 • 解決方針(選定技術) • トレードオフ • 社内開発者/従業員へのワークフローへの影響 提供のタイミング プロジェクトの提案/開始時および実行途中に作成。設計段階 でチーム・およびステークホルダーへ共有し解決方針を意思 決定する。
  20. Architecture Docs 概要 社内開発者を想定読者として、各システムについて何かを知 りたいと思ったときのファーストランディングページとなる ことを目的としたドキュメント。読者がシステムの構成 / 仕 様 の概要が把握できることをゴールとしている。

    フォーマット 任意。構成図等をセットで提供する事が多い。変更背景とし てDesign Docsを添える事で、過去のアーキテクチャ選定背 景を伝える事も意図している。 提供のタイミング プロジェクト完了のタイミング。ドキュメント化されてない 場合、日々のチームインタラクションの中で提供対効果が高 いと思われる場合は優先度を上げて作成するケースもある。
  21. 一年を振り返っての失敗 Stream Aligned Teamとのコラボレーションの量・質 コラボレーションモード、インタフェースの定義とパターニング はあくまでコラボレーションをしやすくするための装置。顧客 (Stream Aligned Team)のバーニングニーズや一次情報をチーム が分離された状況で取り続ける事は難しい。とはいえ深く入りこ

    まないと課題は見えてこない(アンケート等の限界) ビジョンフィットよりもサバイバル優先 Platform Engineering Teamがゲートキーパー・業 務ブロッキングは減りつつも、DevとOpsの協働というより 分業・巻取りによる品質向上への取り組みに流れ勝ち。(右上 が理想。現実は右下)。やらないといけない事 > やりたい事 のバランス