この資料について

トリビューのプロダクト組織がどんな体制で、どんな流れで開発しているかを紹介する資料です。面接の前に全体感を掴んでいただくためにお渡ししています。ここに書いている体制と流れは2026年9月時点でのものです。気になる点は面接でぜひ聞いてください。

プロダクト本部の構成

プロダクトを"作る"組織と"届ける"組織を1つの本部にまとめています。企画・開発だけでなく、「ユーザーとクリニックにどう届けるか」までを同じ組織で持ち、それをAIを前提としたプロセスで最短最速で提供することを狙いとしています。この背景から、現在は本部長をCTOが兼務しています。

flowchart LR
  HQ["プロダクト本部<br>本部長：CTO 兼務"]
  HQ --> PM["プロダクトマネジメント部"]
  HQ --> DEV["開発部"]
  HQ --> MKT["マーケティング部"]
  HQ --> ED["トリビュー編集部"]
  PM --> PM1["プロダクトマネージャー"]
  PM --> PM3["プロダクトデザイン"]
  PM --> PM4["ユーザーサポート"]
  PM --> PM2["QA"]
  DEV --> D1["エンジニアリング<br>iOS / Android / Web / バックエンド / 基盤"]
  DEV --> D2["データ分析"]
  MKT --> M1["CRM"]
  MKT --> M2["プロモーション"]
  ED --> E1["編集企画"]
  ED --> E2["コンテンツ制作"]
  ED --> E3["コミュニケーションデザイン<br>クリエイティブ制作"]

開発の流れ

開発の大きな流れは以下の通りです。原則すべての施策が同じフローで進みます。担い手となるチームの構成は、次のパートで説明します。

課題 →［取捨選択］→ ディスカバリー →［採択］→ デリバリー →［判定・ふりかえり］→ …

flowchart LR
  Z["課題・アイデア"] -.-> P0{"⓪ 取捨選択<br>どの課題に時間を使うか"}
  P0 --> D1["① ディスカバリー<br>作るべきか・何を作るべきか"]
  M1{"② 採択<br>何にどれだけ投資するか"}
  D2["③ デリバリー<br>実装・リリース"]
  G["④ GTM・検証<br>届けて測る"]
  M2{"⑤ 判定・ふりかえり<br>継続・拡大・撤退"}
  D1 --> M1
  M1 --> D2
  D2 --> G
  G --> M2
  M2 -->|継続・拡大| M1
  M2 -->|学び| D1
  style Z stroke-dasharray: 5 5

実際にはポッドとデリバリーチームが複数の施策を並行で回しています。取捨選択・採択・判定の意思決定は、週次の「やるやら会」で一括して行います。

フェーズ	主体	何をする
⓪ 取捨選択	プロダクト責任者 + α	起票された課題・アイデア（誰でも起票できます）から、どれに探索の時間を使うかを決める
① ディスカバリー	ポッド	ユーザーインタビュー・小さなリサーチ・プロトタイプで「作るべきか・何を作るべきか」を確かめ、企画にまとめる。期間は1〜2週間の区切り（タイムボックス）で宣言して始める
② 採択	プロダクト責任者 + α	企画を並べ、何にどれだけ投資するかを一括で決める
③ デリバリー	デリバリーチーム	Spec / Design Doc を揃えてから実装し、リリースする。ポッドのエンジニアが実装できるものはポッド内で実装することもある
④ 届けて測る（GTM・検証）	ポッド＋マーケティング	届け方（GTM）を実行し、成功条件と照らして測る
⑤ 判定・ふりかえり	プロダクト責任者 + α	検証結果をもとに継続・拡大・撤退を決める

ディスカバリーでは「作るべきか・何を作るべきか」を、価値（使われるか）・ユーザビリティ（使いこなせるか）・実現可能性（作れるか）・事業成立性（ビジネスとして成立するか）の4つの観点で確かめます。デリバリーは、採択された企画をユーザーとクリニックの手元に届き、結果を判定できる状態まで持っていくことです。速さは「リリースまで」ではなく「判定できる状態まで」で測ります。

採択された枠（期間・人・スコープ）の中では、仕様もリリースも実行するチーム自身が判断します。戻せない変更や大きな投資など例外に当たるものだけ、作る前に事前承認を通します。

リリース

Web は日次で複数回、アプリ（iOS・Android）は定期（週次）でリリースします。

プロダクト開発組織の構成

プロダクト開発に関わるメンバーは、「ポッド」と呼ぶ3〜4名の小さなユニット3組と、開発チーム3つ、QAチームで構成されます。ポッドが「何を作るべきか」を探索し、デリバリーチームが「作って届ける」を担う分担です（ポッドもリリースまでの全プロセスに関わります）。

単位	構成の目安	役割
ポッド（3組）	各3〜4名（PdM・デザイナー・エンジニア）	担当する目標（アウトカム）を持ち、課題の探索から企画・検証までのオーナー。小さな検証は実装まで完結できる
プロダクトデリバリーチーム	8名（iOS・Android・バックエンド・Web）	採択された企画の本番実装・リリースの運行・保守。本番品質の最終責任を持つ
プラットフォームチーム	3名	検証基盤（Feature Flag・AB計測・E2E）・CI/CD・開発標準の整備
AI / R&Dチーム	3名＋兼務1名	R&D・AI活用・インフラ/SRE。ポッドやデリバリーに人と技能を送り込む横断支援
QAチーム	リーダー1名＋9名	内製の QA。テスト計画・リリース前の品質保証。自動 E2E と人のテストを組み合わせる

どのチームも、AI エージェントとの協働を前提としており、人は検証と判断に時間を使う前提で、ポッドは3〜4名を1ユニットにしています。オンライン診療のプロダクトは、この体制とは別の専任チームが担当しています。

flowchart LR
  subgraph DISC["ディスカバリー：作るべきかを確かめる"]
    direction TB
    T1["ポッド 1<br>PdM・デザイナー・エンジニア"]
    T2["ポッド 2<br>PdM・デザイナー・エンジニア"]
    T3["ポッド 3<br>PdM・デザイナー・エンジニア"]
  end
  REV{"やるやら会<br>採択・アサイン"}
  subgraph DELIV["デリバリー：作って届ける"]
    direction TB
    PD["プロダクトデリバリー<br>iOS / Android / BE / Web<br>実装・リリース・保守"]
    QA["QA<br>テスト計画・品質保証"]
  end
  subgraph BASE["基盤・横断支援"]
    direction LR
    PF["プラットフォーム<br>検証基盤・CI/CD・開発標準"]
    AI["AI / R&D<br>AI活用・インフラ / SRE・技能移転"]
  end
  DISC -->|企画| REV
  REV -->|採択された企画| DELIV
  DELIV -.検証結果・学び.-> DISC
  BASE -.基盤・人と技能.-> DISC
  BASE -.基盤・人と技能.-> DELIV