こんにちは！タイミーでエンジニアリングマネージャーをしている恩田です。この記事は Timee Advent Calendar 2025 の10日目の記事です。

はじめに

この記事では、私が所属するプラットフォームエンジニアリング部の活動の紹介、特に課題探索を目的としてどのような活動をしているかをご紹介したいと思います。前置きとして、弊社におけるエンジニア組織およびプラットフォームエンジニアリング部の役割やメインミッションの紹介もしており、本題まで少し前置きが挟まります。また、あくまで弊社組織での実例紹介であり、ベストプラクティス等を意識したものではない点にご留意いただきつつ、どなたかのご参考になれば幸いです。

前置き・プラットフォームエンジニアリング部門の役割

タイミーのようなプロダクト主導型組織において狭義のプロダクト戦略とは、マーケティングとイノベーションに対して戦略的意図（顧客ニーズに応える新しいプロダクトやサービスをどう生み出し、どう市場に届けるか）を策定することを指します。この戦略的意図を実現するための具体的なアクションプランをタイミー社内ではプロダクトイニシアチブと表現しています。開発者目線であえて端的な表現をすれば「ユーザ価値を届けるためのプロダクト機能開発」に類する仕事です。タイミーのエンジニアの大部分は、このプロダクトイニシアチブの実行/推進を主たる業務とする組織に所属しており、職能横断的なチーム構成のもと企画から設計、開発、テスト、リリース、施策評価までを一貫して行える組織設計を意図して組成されています。

その一方、プラットフォームエンジニアリング部門ではチームのユニット単位を「職能」で定義しており、WebFront領域に専門性を持つエンジニアで構成されるチーム、バックエンド領域に専門性を持つエンジニアで構成されるチーム、クラウドインフラ領域に専門性を持つエンジニアで構成されるチーム、QAエンジニアで構成されるチーム、セキュリティ領域に専門性を持つチーム、といった具合です。

その上で、組織のミッションと存在理由を

タイミーユーザ目線のあたりまえ品質を提供する
プロダクト開発組織がプロダクトイニシアチブを爆速でデリバリできる状態を提供する

と定義しています。そのため、プロダクトイニシアチブに則った開発プロジェクトにプラットフォームエンジニアリング部が直接・間接的に参画寄与することもありますが、メイン業務は上記を達成するための技術改善/支援となります。

[NOTE] 「プラットフォームエンジニアリング」とは、安全で管理されたフレームワーク内の改善された開発者エクスペリエンスとセルフサービスを通じて各開発チームのセキュリティ、コンプライアンス、コスト、およびビジネス化までの時間に関する価値を向上させることを目的として、DevOps 原則から構築されたプラクティスである、と一般的に定義されています（定義話は長くなるのでこの記事ではこれ以上は触れません）その上で、弊社におけるプラットフォームエンジニアリング部は、上記に掲げるミッション/目標達成のために上記プラットフォームエンジニアリング（プラクティス）を「手段として必要に応じて選択、実践するもの」と捉えています。

PO/PdM不在のチームは「やるべきこと」をどうやって決めるのか？

前置きが長くなりましたが本題です。我々が上記ミッションを達成するために、どのようなアクションプランを立てるべきなのか - この意思決定の材料の1つが顧客の声です。我々にとっての顧客とは、タイミーのエンドユーザ（プロダクト品質の受益者）と社内開発者が該当します。

プラットフォームエンジニアリング組織にはいわゆる「プロダクトマネージャー」と呼ばれる役割を設置しておらず、各チームは定量軸と定性軸の一次情報、すなわちタイミーの各種システムモニタリングと社内開発者のVOC（Voice of the Customer）の継続的な収集を通じて課題仮説の言語化と打ち手仮説を立て、検証とアクションプランの実行をエンジニア全員が主体となって継続しています。これを各チームが各々定期イベントとしてチーム業務に組み込んでいます。

以下、具体的にどのような定期業務イベントでどのような定量、定性情報を日々収集し、課題仮説立てに用いているのかを紹介します。

定量情報の観測

アプリケーション定点観測会

タイミーのシステム信頼性、パフォーマンス、コスト、セキュリティ等にまつわる様々なメトリクス/指標を観測する会です。現状とトレンドの事実確認を行い課題仮説を立てアクションにつなげる / 直近の改善施策の効果を確認し、対策を継続すべきかクローズすべきか等の判断を行うことを目的としています。具体的には以下のような指標を同期ミーティングで集まり確認をしています。

信頼性/パフォーマンス観点
- タイミーのBackend API群のレイテンシ、エラーレート、コンテナの各種メトリクス、スケーリング傾向やリクエスト傾向(シーズナリティ/スパイク傾向)
- データストア層（MySQL, Redis, ElasticSearch）の各種メトリクス、クエリパフォーマンスやスロークエリ、Cache Hit Rate、etc
- Sidekiq Jobのスループット、Jobs count推移、Workerのスケーリング傾向
- バッチジョブのメトリクス、起動失敗率
- 外部SaaS類へのリクエスト数推推移やスループット、メールのバウンスレートやPUSH配信のエラーレート等
Security観点
- CSPM等によるAWS構成不備の新規逸脱検知状況のチェック
- ECRイメージ脆弱性検査状況の定点チェック
- GuardDutyの検出結果振り返り
コスト観点
- AWS、Datadog、GitHub等利用料の大きいSaaS類の利用状況トレンドの把握。
- 月次/年次予算対比での上振れリスク
- 利用内訳（group by service, product, etc）の確認と、内訳比率に大幅な変化がないかのチェック
- RI Coverageの状況
Observability観点
- メトリクスの不備、不足などについての課題提案
- アラートの過不足、およびしきい値の調整予定についての課題提案
- ダッシュボードの見直しなど、観測設計そのものを改善対象としての改善点洗い出し

内部品質定点観測会

タイミーのバックエンドアプリケーションにおける開発者体験を司る各種指標を定点観測する会です。目的はアプリケーション定点観測会と同様で、現状とトレンドの事実確認を行い課題仮説を立てアクションにつなげる / 直近の改善施策の効果を確認し、対策を継続すべきかクローズすべきか等の判断を行うことを目的としています。具体的には以下のような指標を同期ミーティングで集まり確認をしています。

CI/CDパフォーマンス観点
- CI, CD の失敗率・失敗要因の分析
- CI, CD の実行時間、実行時間変化の分析
PRのレビュープロセス観点
- レビューリードタイム推移
- マージしたPR数のトレンドと各チームの開発状況との因果関係考察
テストの健全性観点
- Flaky Test の新規発生・修正状況
- 遅いテストの抽出と高速化余地の洗い出し

定性情報の観測

組織として現在収集できているメトリクスから開発生産性の全容を捉えるのは難しい側面があります。特に開発のバリューストリーム上のボトルネックやToilはコーディング、テスト、リリースといった開発工程の外にあるケースも多いです。観測しやすいメトリクス（4keysやGitHub上で観測できるLead time to Change等）だけを追っていても改善対効果の高い課題仮説が浮かび上がらないケースもあります。ビジネス要件の把握、仕様策定、コードベースの把握、レビュー、手動/自動テスト、承認、リリース作業、etc,,。開発工程のどこにボトルネックが発生しているか課題仮説を立てる材料として、開発者からの定性情報（これがツライ、わからない、知らない、etc）は貴重な情報源となります。

ポストモーテムを眺める会

タイミーの開発組織では、障害発生後にポストモーテムを行う文化が定着しています。ポストモーテムは障害対応/収束を担当したチームが中心となって実施します。このポストモーテムの内容（議事録）に記された議論過程やNext Actionをプラットフォームエンジニアリング部門のチームでクロスレビューし、「どのような支援（技術的改善、プロセス/ガードレール整備、知識/情報の非対称性の解消等）を行うと価値がありそうか」を探索しています。

スプリントレポート報告会

プラットフォームエンジニアリング部のチームがデリバリした開発者の生産性向上、体験向上を目的とした各種施策のサマリをレポートし、顧客（社内開発者）からのFBや要望を受け取る会です。

スプリントレポートはチームの作業計画に沿ったアウトプットです。アウトプット内容を共有しつつ、同時に社内開発者から「こんなことで困っている」といった一次情報を受領する相互情報交換を目的としています。

開発者体験アンケート

「開発者が自信を持ってリリースできる状態の実現」をゴールとした、開発者体験の現状を把握し改善につなげるためのアンケートを実施しています。また、アンケート収集後に内容を精査、具体的な改善アクションにつなげるため、必要に応じて回答者へインタビュー等も実施します。SDLCの各フェーズ毎、プラットフォームエンジニアリング部門のエンジニアが独自に策定した論点を元に質問を作成しており、技術的負債、業務プロセス、知識/情報の非対称性、様々な確度から課題の種情報を収集しています。

オフィスアワー

主にクラウドインフラ領域の技術に関するオープンドア形式のQ&Aセッションです。特定時間にslackのhuddleを開き、参加者は自由に出入りできる形で場を運営しています。

クラウドインフラチームが専売特許となりがちな技術領域、例えば監視設計やデータストア選定、データマイグレーション計画のノウハウ、CI/CDパイプラインやAWS全般に関する疑問や質問、興味のあることを何でも気軽に同期で質問・相談できる場として設計しています。

この場を通じ、開発組織全体で信頼性エンジニアリングのプラクティス実践を推進するにあたり障壁となる知識/情報の非対称性や、技術/組織課題の探索の場として活用しています。

おわりに

この記事では、弊社プラットフォームエンジニアリング組織における各種課題探索の実例を紹介しました。実例の一つとして参考になれば幸いです。

We are hiring!

タイミーでは絶賛エンジニアを募集中です。興味があればぜひお話ししましょう！