トリビューのプロダクト組織がどんな体制で、どんな流れで開発しているかを紹介する資料です。面接の前に全体感を掴んでいただくためにお渡ししています。ここに書いている体制と流れは2026年9月時点でのものです。気になる点は面接でぜひ聞いてください。
プロダクトを"作る"組織と"届ける"組織を1つの本部にまとめています。企画・開発だけでなく、「ユーザーとクリニックにどう届けるか」までを同じ組織で持ち、それをAIを前提としたプロセスで最短最速で提供することを狙いとしています。この背景から、現在は本部長をCTOが兼務しています。
開発の大きな流れは以下の通りです。原則すべての施策が同じフローで進みます。各チームの構成は、次のパートで説明します。
実際にはポッドとデリバリーチームが複数の施策を並行で回しています。取捨選択・採択・判定の意思決定は、週次の「やるやら会」で一括して行います。
| フェーズ | 主体 | 何をする |
|---|---|---|
| ⓪ 取捨選択 | プロダクト責任者 + α | 起票された課題・アイデア（誰でも起票できます）から、どれに探索の時間を使うかを決める |
| ① ディスカバリー | ポッド | ユーザーインタビュー・小さなリサーチ・プロトタイプで「作るべきか・何を作るべきか」を確かめ、企画にまとめる。期間は1〜2週間の区切り（タイムボックス）で宣言して始める |
| ② 採択 | プロダクト責任者 + α | 企画を並べ、何にどれだけ投資するかを一括で決める |
| ③ デリバリー | デリバリーチーム | Spec / Design Doc を揃えてから実装し、リリースする。ポッドのエンジニアが実装できるものはポッド内で実装することもある |
| ④ 届けて測る（GTM・検証） | ポッド＋マーケティング | 届け方（GTM）を実行し、成功条件と照らして測る |
| ⑤ 判定・ふりかえり | プロダクト責任者 + α | 検証結果をもとに継続・拡大・撤退を決める |
ディスカバリーでは「作るべきか・何を作るべきか」を、価値（使われるか）・ユーザビリティ（使いこなせるか）・実現可能性（作れるか）・事業成立性（ビジネスとして成立するか）の4つの観点で確かめます。
チームでインサイトを扱うために。トリビューでの、インサイト駆動な組織へのアップデートの全体像｜Cocoda
プロダクト開発に関わるメンバーは、「ポッド」と呼ぶ3〜4名の小さなユニット3組と、開発チーム3つ、QAチームで構成されます。ポッドが「何を作るべきか」を探索し、デリバリーチームが「作って届ける」を担う分担です（ポッドもリリースまでの全プロセスに関わります）。
| 単位 | 構成の目安 | 役割 |
|---|---|---|
| ポッド | 各3〜4名（PdM・デザイナー・エンジニア）✕ 3 | 担当する目標（アウトカム）を持ち、課題の探索から企画・検証までのオーナー。小さな検証は実装まで完結できる |
| プロダクトデリバリーチーム | 8名（iOS・Android・バックエンド・Web） | 採択された企画の本番実装・リリースの運行・保守。本番品質の最終責任を持つ |
| プラットフォームチーム | 3名 | 開発基盤・検証基盤・CI/CD・開発標準の整備 |
| AI / R&Dチーム | 3名＋兼務1名 | R&D・AI活用・インフラ/SRE。ポッドやデリバリーの横断支援 |
| QAチーム | リーダー1名＋9名 | 内製のQAチーム。テスト計画・リリース前の品質保証。自動E2Eと手動テストを組み合わせて実施 |
どのチームも、AI エージェントとの協働を前提としており、ポッドは3〜4名を1ユニットにしています。
どのチームもAIエージェントとの協働を前提にし、人は検証と判断に時間を使う。