チームとチームの間に落ちている仕事を、拾い上げて着地させる。

成長する開発組織では、どのチームの担当でもない仕事が必ず生まれます。複数のチームにまたがるリリース、新規事業に向けた体制づくり、使い続けてきたツールの入れ替え、システムのコストの見直し。どれも事業にとって重要なのに、各チームのロードマップには載りにくく、気づけば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が横断プロジェクトの進行管理から手を離し、技術戦略や組織づくりに時間を使えているか

具体的な目標は、入社後に現状を確認したうえで一緒に設定します。

• ソフトウェア開発組織で、複数のチームにまたがるプロジェクト・プログラムを、計画から完了まで率いた経験（目安5年以上）
• システム構成・API・CI/CD・クラウドなどの技術的な議論にエンジニアと対等に加わり、依存関係やリスクを自分で見立てられること
• 優先順位がぶつかる場面で、選択肢と影響を整理し、経営層やチームのリーダーの合意を取りつけた経験
• 指示系統上の権限によらず、根拠と信頼で関係者を動かし、プロジェクトを前に進めた経験
• 日本語で円滑に開発チームや経営層と議論できること（ネイティブレベル）

経験年数そのものより、どんなプログラムを、どんな関係者と、どう判断して着地させてきたかを重視します。

• クラウドのコスト最適化や原価管理のプロジェクトの推進経験
• 既存システムやツールの移行・終息（EOL対応）の推進経験
• 新規事業や組織の立ち上げに伴う、開発体制の設計経験
• Four Keysなどの指標を使った開発プロセスの改善経験
• AIツールを使い、進捗の集約や報告などのプログラム運営を自動化した経験
• ソフトウェアエンジニア・SRE・QAなど、開発者としての実務経験
• IPO準備期や急成長期のSaaSでの勤務経験
• エンタープライズ向けSaaSの開発に関わった経験

歓迎要件のすべてを満たす必要はありません。これまでにどんなプログラムを、どう判断し、何を仕組みに変えてきたかを、ぜひ聞かせてください。

こんな方と働きたい

誰の担当でもない問題を、拾いに行ける方

チームの間に落ちている問題に気づいたら、指示を待たずに引き取りに行ける。「担当外」を理由に手を止めず、それを誰がどう持つべきかまで考えられる方です。

進捗ではなく、結果に責任を持てる方

タスクが動いていることではなく、約束したものが届いたかどうかで自分の仕事を測れる。必要なときには、立ち止まる・範囲を削るという判断も自分から提案できる方を歓迎します。

調整を増やすより、減らす方法を考えられる方

会議と報告を重ねて前に進めるのではなく、繰り返す調整を仕組みとAIで減らすことを楽しめる。進め方そのものを改善の対象として見られる方です。

技術と経営の両方の言葉で話せる方

エンジニアとはアーキテクチャの言葉で、経営陣とは事業への影響の言葉で話せる。相手に合わせて抽象度を変えながら、関係者の意思決定を前に進められる方です。