Senior Technical Program Manager
職務内容
Description
Description
チームとチームの間に落ちている仕事を、拾い上げて着地させる。
成長する開発組織では、どのチームの担当でもない仕事が必ず生まれます。複数のチームにまたがるリリース、新規事業に向けた体制づくり、使い続けてきたツールの入れ替え、システムのコストの見直し。どれも事業にとって重要なのに、各チームのロードマップには載りにくく、気づけば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が横断プロジェクトの進行管理から手を離し、技術戦略や組織づくりに時間を使えているか
Requirements
Requirements
- ソフトウェア開発組織で、複数のチームにまたがるプロジェクト・プログラムを、計画から完了まで率いた経験（目安5年以上）
- システム構成・API・CI/CD・クラウドなどの技術的な議論にエンジニアと対等に加わり、依存関係やリスクを自分で見立てられること
- 優先順位がぶつかる場面で、選択肢と影響を整理し、経営層やチームのリーダーの合意を取りつけた経験
- 指示系統上の権限によらず、根拠と信頼で関係者を動かし、プロジェクトを前に進めた経験
- 日本語で円滑に開発チームや経営層と議論できること（ネイティブレベル）
Preferred Experiences
Preferred Experiences
- クラウドのコスト最適化や原価管理のプロジェクトの推進経験
- 既存システムやツールの移行・終息（EOL対応）の推進経験
- 新規事業や組織の立ち上げに伴う、開��体制の設計経験
- Four Keysなどの指標を使った開発プロセスの改善経験
- AIツールを使い、進捗の集約や報告などのプログラム運営を自動化した経験
- ソフトウェアエンジニア・SRE・QAなど、開発者としての実務経験
- IPO準備期や急成長期のSaaSでの勤務経験
- エンタープライズ向けSaaSの開発に関わった経験
We are looking for
We are looking for
こんな方と働きたい
誰の担当でもない問題を、拾いに行ける方
チームの間に落ちている問題に気づいたら、指示を待たずに引き取りに行ける。「担当外」を理由に手を止めず、それを誰がどう持つべきかまで考えられる方です。進捗ではなく、結果に責任を持てる方
タスクが動いていることではなく、約束したものが届いたかどうかで自分の仕事を測れる。必要なときには、立ち止まる・範囲を削るという判断も自分から提案できる方を歓迎します。調整を増やすより、減らす方法を考えられる方
会議と報告を重ねて前に進めるのではなく、繰り返す調整を仕組みとAIで減らすことを楽しめる。進め方そのものを改善の対象として見られる方です。技術と経営の両方の言葉で話せる方
エンジニアとはアーキテクチャの言葉で、経営陣とは事業への影響の言葉で話せる。相手に合わせて抽象度を変えながら、関係者の意思決定を前に進められる方です。この求人に興味がありますか？