## チームとチームの間に落ちている仕事を、拾い上げて着地させる。
成長する開発組織では、どのチームの担当でもない仕事が必ず生まれます。複数のチームにまたがるリリース、新規事業に向けた体制づくり、使い続けてきたツールの入れ替え、システムのコストの見直し。どれも事業にとって重要なのに、各チームのロードマップには載りにくく、気づけばCTOの机の上に積まれていきます。
**Bring OutのSenior Technical Program Manager（TPM）は、CTO直下で、開発組織の横断プログラムを計画から着地まで率いる、デリバリーの責任者です。**
進捗表を更新して回る役割ではありません。何を、どの順番で、誰とやり、何を今はやらないのか。技術の中身を理解したうえでそれを決め、チームを動かし、約束した日に届けきる。そして同じ問題が二度と人手に頼らずに済むよう、仕組みに変えていく仕事です。
## なぜ今、このポジションなのか
Bring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上（2026年10月時点）に利用いただいています。
成長に合わせて、Bring Outは開発組織を役割ごとのチームに再編しました。ロードマップに沿って新機能をつくる新機能開発チーム、LLM・課金・対話分析の基盤を担うPlatformチーム、ロードマップの外から届く顧客要望に短いサイクルで応えるFast Track、顧客ごとの個別ソリューションを届けるSolutionチーム。今後はTechnical Supportチームも立ち上がります。チームが役割ごとに分かれたことで、それぞれの専門性は深まりました。一方で、複数のチームにまたがる仕事を最後まで運ぶ役割は、組織としてまだ置けていません。
同時に、IPOの準備と事業の成長に合わせて、システム原価の最適化、レガシーツールの整理、新規事業に向けた開発体制の設計といった、組織全体に関わるプロジェクトが並行して走っています。現在、その多くをCTOが自ら抱えており、本来向き合うべき技術戦略や組織づくりの時間を圧迫しています。
そこでBring Outは、開発組織の横断プログラムを専任で率いるSenior TPMを迎えます。完成した進め方を引き継ぐのではなく、複数のチームで約束を守るための進め方そのものを、つくっていただきます。
役割の境界も明確にしています。何をつくるか、その方向性と優先順位はProduct Managerが、顧客ごとの個別案件と外部の開発パートナーはSolution Architectが担います。TPMは、決まったことを複数のチームで確実に届けるための進め方と、CTOから引き取る横断プロジェクトに責任を持ちます。
## お任せしたいこと
まずは、いま走っている横断プロジェクトを引き取り、計画どおりに着地させることに集中していただきます。そのうえで、プログラムの進め方を仕組みに変え、開発組織全体のデリバリーを速くする領域へ広げていきます。
### CTOから横断プロジェクトを引き取り、着地させる
- システム原価の最適化、レガシーツールの整理と移行、新規事業の立ち上げに伴う開発体制の設計など、CTOが抱えている横断プロジェクトを引き取る
- 目的・スコープ・成功の条件を定義し、計画を立て、関係するチームや部門と合意する
- 実行から完了の判定まで責任を持ち、必要な判断をCTOと経営陣から引き出す
### 複数チームにまたがるリリースを率いる
- Product Managerと連携し、ロードマップを複数チームの実行計画（マイルストーン・依存関係）に落とし込む
- チーム間の依存とリスクを早い段階で見つけ、手を打つ
- 期日や範囲の見直しが必要になったら、選択肢と影響を並べて、早めに判断を仰ぐ
### 経営が判断できる形で現在地を伝える
- 横断プログラムの進捗とリスクを、CTOと経営陣がそのまま判断に使える形で定点報告する
- 優先順位がぶつかったときは、事業への影響と選択肢を整理し、CTOやチームのリーダーと調整する
### デリバリーをデータで改善する
- Four Keysなどの指標で、開発組織のデリバリーの状態を測れるようにする
- 指標から見えた詰まりを、チームと一緒に改善のサイクルに乗せる
### その先に広げていく領域
横断プロジェクトが計画どおりに着地し始めたら、次のテーマにも取り組んでいただきます。
- **プログラム運営の自動化**：繰り返し現れるプログラムの型を見つけ、AIを使って、進捗の集約・リスクの検出・報告づくりが人手に頼らずに回る状態にする
- **進め方の標準化**：計画・リリース・振り返りの進め方を、各チームが自走できる型とドキュメントにする
- **組織の変化への備え**：組織や事業の変化に合わせて、プログラム管理の置き場所や進め方の見直しを提案する
## Bring Outでこの仕事をする面白さ
### CTOの判断のすぐ隣で、会社の次の段階をつくれる
CTO直下で、横断プロジェクトの計画と判断の材料づくりを担います。IPOの準備やエンタープライズ顧客への対応など、会社の次の段階を左右するテーマに、計画の段階から関われます。決めたことを、自分の手で着地まで運べる距離にいます。
### 「回す人」ではなく、「回る仕組みをつくる人」になれる
Bring Outの開発組織には、複数のチームでプログラムを進める決まった型がまだありません。会議や報告を増やすのではなく、調整そのものを減らす。進捗の集約やリスクの検出をAIで自動化し、人が判断すべきことに時間を使える状態をつくる。その設計を、最初から任せられます。開発組織ではClaude Code等のAIツールを日常的に使っており、新しいやり方を試すことへの抵抗はありません。
### 扱う技術の幅が、そのままプログラムの幅になる
AIを中核に据えたSaaS、LLMや文字起こしを支える基盤、顧客ごとの個別ソリューション。扱うプログラムの技術領域は広く、どれも成長の途中にあります。アーキテクチャの議論に加わり、技術の中身を理解したうえで判断できる人ほど、任せられる範囲が広がっていきます。
## 大切にしたい指標
目指すのは、計画どおりに会議を回すことではありません。約束したものが約束した日に届き、問題が大きくなる前に手を打てていることを重視します。
- **横断プロジェクトの着地**：引き取ったプロジェクトが、合意した範囲と期日で完了しているか
- **期日の予見性**：計画と実績の乖離が小さく、見直しが必要なときは事前に合意できているか
- **リスクの早期発見**：問題が、リリース直前や顧客への影響が出たあとではなく、手を打てる段階で見つかっているか
- **デリバリーの状態**：Four Keysなどで見たデリバリーの指標が改善しているか
- **CTOの時間**：CTOが横断プロジェクトの進行管理から手を離し、技術戦略や組織づくりに時間を使えているか
具体的な目標は、入社後に現状を確認したうえで一緒に設定します。