株式会社ブリングアウト の全ての求人一覧
AI Product Manager
AI Product Manager ー AI-nativeな開発プロセスを創り出す
私たちは今、自社のプロダクト開発そのものをAI-nativeな仕組みへと再設計しようとしています。その中核を担うのが、AI Product Manager です。ブリングアウトのプロダクトを「AIが自律的に進化するプロダクト」へと変革し、そのプロセス自体を顧客が採用できる形にパッケージ化することが役割です。顧客の声、商談・CS情報、開発要望、プロダクト利用メトリクス、品質データを LLM が継続的に統合・構造化し、プロダクトの改善機会を発見し、優先順位を提案し、開発チームがすぐに動ける要件へ落とし込むワークフローを設計・運用する責任者です。単に AI 機能を企画するのではなく、PM の仕事そのもの ── 「顧客の声をどう捉え、何を作るべきかをどう判断し、どのように開発チームへ渡し、リリース後にどう学習するか」というプロダクト開発の OS を、AI で再発明する仕事です。① AI-nativeなプロダクト開発ワークフローの設計・運用
顧客の声、開発要望、プロダクト利用メトリクス、品質データをもとに、LLM がプロダクト改善の機会を発見し、優先順位付けし、要件化するワークフローを設計・運用します。VoC、商談ログ、CS情報、開発要望、利用メトリクスの統合設計LLM による分類・要約・クラスタリング・優先度スコアリングの設計バックログトリアージ、ロードマップ更新、PRD ドラフト生成のワークフロー化PdM・Engineering・CS・Sales が継続的に使える運用プロセスへの落とし込み顧客インタビューや商談・CSから得られる一次情報を、プロダクト判断と開発実行に使える形へ変換します。顧客課題の抽出、構造化、パターン化開発チームが48時間以内に動き始められる粒度の PRD・Issue ドラフト作成問題定義、ユースケース、成功指標、受け入れ条件、制約、リスク、未決事項の整理顧客の言葉と、開発チームの要件言語をつなぐドキュメント設計AI が出す提案を、組織が信頼して意思決定に使える状態にします。優先順位付けの判断軸設計事業インパクト、顧客価値、開発工数、戦略整合性、リスクを踏まえた評価フレームの設計AI が生成する提案の説明可能性・再現性・レビュー観点の設計ロードマップレビュー、スプリント計画、仕様レビュー、リリース後レビューへの組み込みLLM や AI エージェントの出力を、プロダクト開発の実務で使える品質に高めます。PRD、Issue、優先度提案、要約、分類結果の Evaluation 設計AI 出力の品質基準、レビュー基準、Human-in-the-loop 設計誤分類、過剰要約、幻覚、重要要望の見落としを防ぐガードレール設計AI ワークフローの継続改善AI が生成するインサイトや優先度提案をもとに、プロダクトロードマップと開発投資判断を継続的にアップデートします。What-if 分析を用いたロードマップシナリオ設計CTO・Engineering との投資対効果レビュープロダクト改善テーマの言語化短期の開発優先度と中長期のプロダクト進化の接続■① PMの仕事そのものをAIで再定義できる
既存プロダクトの一機能を担当するPMではありません。顧客の声をどう集め、どう解釈し、何を作るべきかをどう判断し、どのように開発へつなげるかという、プロダクト開発の中核プロセスそのものを AI で再設計する役割です。今後多くの企業で必要になる新しいテーマであり、職種としてもまだ世の中に完成形がない領域です。■② AIを実験ではなく、日々の開発プロセスに組み込める
LLM や AI エージェントを、PoC やデモで終わらせるのではなく、実際のロードマップ判断、バックログ管理、要件定義、開発プロセスに組み込んでいきます。AI を「便利ツール」ではなく、会社のプロダクト開発の中枢に据える仕事です。■③ 顧客価値と開発生産性の両方にインパクトできる
顧客の声がより早く、より正確にプロダクトへ反映されることで顧客価値を高めます。同時に、PdM・Engineering・CS・Sales の連携を滑らかにし、開発チームが迷いなく動ける状態をつくることで、開発生産性にも直接インパクトできます。顧客満足・開発スピード・売上貢献のすべてに関わる、レバレッジの高い仕事です。■④ CTO直下で、開発組織全体の進化をリードできる
所属は開発組織、CTO 直下です。プロダクト戦略、AI 活用、開発プロセス、データ基盤、組織運営が交差する領域で、経営・開発・ビジネスの意思決定に近いところから変革をリードできます。Principal IC として、組織横断の仕組みづくりに専念できる環境です。■⑤ まだ世の中に完成形がない、新しい職種を創り出せる
このポジションは、従来の PdM、Product Ops、AI 活用推進、業務設計、データ活用の要素が混ざった新しい役割です。すでに決まった型を運用する仕事ではなく、「AI 時代のプロダクト開発はこうあるべきだ」という型を自分で作る仕事です。
CFO候補(最高財務責任者)
CFO候補(最高財務責任者)
一次情報を精錬し、日本の経営モデルを刷新するこれまでの経営は、集計された数字と中継された報告をもとに判断されてきました。しかし成果を左右する分かれ目は、その奥にある一次情報の中にあります。ブリングアウトは、対話データから一次情報を抽出し構造化するAIプラットフォームと自社プロダクトを併せ持ち、そこから成果を動かすポイントを見極めて、顧客ごとのサービスや業務の型として実装し、組織に定着させます。仕事は戦略の立案にとどまりません。経営判断の質が変わる地点まで、現場の業務に手を入れて届けます。これまでも、日本を代表するエンタープライズ顧客とともに、業界のコアプロセスをAI Nativeに変える取り組みを進めてきました。経営と現場が同じ問いで動ける状態をつくり、会社の見方、判断、動き方を変える。その変化が一社の成果を生み、やがて他社から参照される新しい経営の型になる。私たちは、そうした企業を増やすことで日本企業全体の競争力を底上げしようとしています。事業は急成長のフェーズに入り、次の課題は資本戦略です。この成長を資本市場の言語に翻訳し、調達・上場・その先のガバナンスまでを設計する経営メンバーとして、CFOをお迎えします。CFOの役割当社にとって初めてのCFO招聘です。上場を見据えた財務体制の構築と、資本戦略の設計・実行に一貫して責任を持つポジションで、CEO直下で資金調達、上場準備、経営管理、M&Aの検討まで、会社のファイナンス全域を統括していただきます。日常のコーポレート業務はコーポレート責任者が率いるチームが担っており、まずは資本戦略と上場準備に集中できる分担です。将来的なコーポレート機能全体の統括は、ご経験と志向に応じて設計します。このポジションの面白さ① 資金調達を白紙から設計できる
どこから調達するか、エクイティとデットの使い分け、どの規模とタイミングで上場するか、成長投資をどこまで踏み込むか。前例のない意思決定がすべてこれから始まります。財務組織と資金調達を設計すること自体がミッションになります。② カテゴリのない事業を資本市場の言語にする
対話データを経営の一次情報に変える当社の事業には、まだ確立された市場カテゴリがありません。しかもプラットフォームのリカーリング収益とプロフェッショナルサービスの収益が併存するハイブリッド型の損益構造で、これをどう指標化し、どう語るかに定石はありません。事業の面白さを投資家が正しく評価できるエクイティストーリーへ翻訳する仕事は、CFO自身の専門性が最も活きる領域になります。③ 経営チームと同じテーブルで意思決定する
取締役会、株主との対話、経営会議に最初から参画いただきます。コンサルティングファーム、投資銀行、事業会社の出身者が集まる経営チームと、財務の専門性で対等に議論できる環境です。④ AIネイティブな管理部門をつくれる
全社でClaude Codeを日常業務に使い、コーポレート業務の自動化にも着手しています。財務・経理の実務をAI前提で設計し直せるタイミングにあり、管理部門の生産性そのものを発明できます。このポジションで担う4つの仕事① 上場準備の設計と完遂主幹事証券・監査法人の選定と折衝開示体制・内部統制・社内規程の整備上場申請書類(Ⅰの部等)の作成統括上場時期・市場選択に関する経営への提言② 資金調達・資本政策・IRエクイティストーリーの構築と投資家への説明エクイティとデットの使い分け調達先の設計(VC・CVC・事業会社・金融機関など、資金以外の経営資源も含めた選定)資本政策・ストックオプション制度の設計既存株主との継続的な対話③ 経営管理の高度化事業計画・予実管理の体制構築と運用プラットフォームのリカーリング収益(ARR・NRRなど)とプロフェッショナルサービス収益が併存するハイブリッドモデルの、KPI体系と管理会計の設計経営会議への意思決定材料の提供採用計画・開発投資など部門横断の投資判断への財務目線の提供ガバナンス体制の構築(内部統制・内部監査・役員職務分掌と相互牽制など)④ M&A・資本業務提携成長戦略としてのM&A・提携の財務評価デューデリジェンス・交渉・PMIの主導処遇について経営幹部ポジションとして、ご経験に応じて個別に設計します。本ポジションは「CFO候補」としてお迎えし、入社時の役職と権限はご経験に応じて設計します。CFO就任を前提とした採用です。ここまで読んでくださりありがとうございます。会社の次の10年を左右する資本戦略を、同じテーブルで設計してくれる方とお会いできるのを楽しみにしています。
Deployment Strategist
Deployment Strategist ー コンサル×AI実装
「Deployment Strategist」は、顧客の経営アジェンダを起点に、AI と自社プロダクトを組み合わせて業務を設計し直し、現場で経営判断が変わるところまでを一気通貫で実装する責任者です。マッキンゼー最速AP、アクセンチュア最速SMと共に、日本を代表するエンタープライズ企業の変革をお任せします。日々の業務では、最先端のデータ解析AIを活用して顧客の一次情報を自由自在に解析し、様々な業界・業種の経営課題を解くための新たなユースケースの開拓を担っていただきます。戦略提言に留まらず、見つけ出した経営示唆をプロダクトに埋め込むことで、顧客の意思決定を変革し続けます。Claude Code をはじめとする AIを使い倒し、戦略とプロダクトの両方を握って前に進める ― 経営視点 × 現場視点 × AI 実装力の三点を併せ持つ、市場で最も希少な人材を生むキャリアです。■紹介記事_コンサルファーム出身者
【戦略ファームBCGからの転職】“現場を動かす喜び”を、AIスタートアップで実装する。
生成AIは経営をどう変えるのか? _ 元マッキンゼーが語る"対話データ"の可能性
“対話データ”が生成AIを活かす。元Accenture若手シニアマネージャーが選んだ会社を育てる手触り■① コンサルタントがAI時代に求められる経験を最速で得る
ブリングアウトでは、経営戦略・現場変革・AI 実装の三領域を一人が近距離で・早期に・一気通貫で経験できる環境があります。コンサルタントがAI時代に求められる経験を、入社後すぐに束ねて回せる場所です。② トップファーム出身者の集うAIネイティブな環境で成長できる
AI の進化が日に日に早まる中で、「最先端の AI に触れる時間が確保できていない」「組織の制約で思い切り使い倒せない」と焦りを感じているなら、ブリングアウトは最高の環境です。経営陣も現場もClaude Code を日常で叩き、現場メンバーが「こう使いたい」と言えば即反映される設計。AI を片手間ではなく本業として設計し続ける環境を、入った瞬間から享受できます。③ プロダクトを所有して、事業をスケールするオーナーシップを持てる
Deployment Strategistは自らAI駆動でプロダクトを開発し、売上創出から事業化まで担います。プロジェクトで得られた知見を自社プロダクトに組み込み、次の顧客・次の業界へと広げていく挑戦が可能です。自分が手を動かした成果が自社プロダクトの進化に直結し、業界の構造変革へつながる手応えがあります。
Director of Deployment Strategist
Director of Deployment Strategist ー 執行役員/事業責任者候補
Directorは、マッキンゼー、BCG、アクセンチュアなどコンサルファーム出身者を中心に構成される Deployment Strategist 部門をリードします。当部門では、最先端のデータ解析AIを活用して顧客の一次情報を自由自在に解析し、様々な業界・業種の経営課題を解くための新たなユースケースの開拓を担っています。戦略提言に留まらず、見つけ出した経営示唆をプロダクトに埋め込むことで、顧客の意思決定を変革し続けます。また、業界ごとの変革テーマを定義し、トップマネジメントとの関係を築き、戦略から実装まで一気通貫で事業を組み立てる責任者です。若手・中堅メンバーをリードし、エンジニアを含む各領域のプロフェッショナルと組んだ総力戦チームで顧客に成果を届け、そこから事業ポートフォリオを広げていく。コンサルティング・プロダクト・事業創造を一つの組織で握る役割です。個別顧客レベルで担う「経営視点 × 現場視点 × AI 実装力」の三点を束ねる経験を、業界 Practice として束ね直す立場でもあります。対話データ × AI を活用した新規変革テーマの構想業界別 Practice の立ち上げと、勝ちパターンのユースケース化事業ポートフォリオ戦略の立案大企業トップマネジメントとの関係構築経営アジェンダに基づく提案活動と意思決定リード戦略パートナーシップの設計DS(Deployment Strategist)チームを率いた受注案件のデリバリーPrompt Expert / Adaption Success / Engineer との連携による実装品質の担保経営層レビューと成果検証各ユースケースのサブプロダクト化・アライアンス形成メンバー育成・採用への関与再現性ある成長モデルと組織体制の構築■① 業界変革を「事業」として組み立てられる
1 社の経営課題を解くだけにとどまりません。業界ごとの変革テーマを自ら定義し、勝ちパターンをユースケース化し、業界 Practice として立ち上げる責任を持ちます。SUBARU、日本 M&A センター、パソナなど、すでに各業界をリードする企業との取り組みが進んでおり、その先にある業界横展開とプロダクト化を、自らの手で形にしていけます。② 自分の冠で Practice を立ち上げ、1 社の経営判断に深く関わる
ファームの Partner トラックでは得づらい、1 社の経営判断に対する継続的・深い関与ができる環境です。「製造業向け一次情報経営」「AI ネイティブ営業組織変革」「金融機関向けリスク発見」など、自分の冠を持った Practice を Bring Out 内で立ち上げ、長く深く育てていけます。■③ チームと組織を、自ら作っていける
MBB / Big4 / 戦略コン・業務コン・AI/DX コンサル出身の DS 陣をリードしつつ、業界 Practice や機能領域の組織立ち上げを担います。DS × Prompt Expert × Adaption Success × Engineer の 4 職種総力戦のチームを設計し、再現性ある成長モデルを構築する仕事です。■④ IPO を射程に入れたフェーズで、経営の中核に立てる
事業上昇カーブそのものに自分の責任で乗れる、経済的アップサイド。給与+ストックオプションの設計で、長期のアップサイドにも参加していけます。
Enterprise Sales
Enterprise Sales ー 大手企業経営層へのトップ提案
Enterprise Salesは、エンタープライズ顧客の経営層・事業責任者と深く向き合い、「一次情報経営」という新しい市場の旗手としてアジェンダを切り開く役割を担います。経営層との対話から事業課題を引き出し、自社プロダクトと実装パッケージを提案・受注、顧客の事業変革のパートナーとして深く並走します。また、顧客の事業戦略の中で、ブリングアウトの価値が代替不可能な位置を占め続ける状態を作る役割です。新規アカウントでは、価値の輪郭がこれから具体化していく段階から顧客に入り込み、契約として検討できるテーマへと共に形にしていきます。既存アカウントでは、一度の成果で終わらせず、顧客の戦略実行の中で活かされる位置を共に合意し、業務の中で自然に活きる状態を作っていきます。受注は通過点であり、ブリングアウトが顧客の戦略に欠かせない存在となるまでの設計と判断を担うのが、この役割の核です。価値の輪郭をこれから形にしていく段階の対話まだ言葉になりきっていない関心を拾い、検討テーマとして立ち上げる契約として議論できる形まで価値を共に磨き、Deployment Strategist チームへ繋ぐ顧客の事業戦略における自社の位置づけの確認と、共に進める方向の合意顧客の戦略実行の中で活かされる位置を共に合意していく業務の中で自然に活きる状態への接続顧客のあるべき姿の言語化と、共有資料化拡張シナリオの合意形成顧客側キーパーソンとの長期リレーション構築価値設計プロセスの言語化・標準化Deployment Strategist チームとの密な連携次のフェーズへ進めるか・一旦立ち止まるかの判断軸を組織に蓄積
Forward Deployed Engineer(FDE)
Forward Deployed Engineer(FDE)ー 顧客の現場に入り込むエンジニア
AI時代のエンジニアリングを再定義する ─ Bring Out では、対話解析AI SaaS の実装を通じて、企業の意思決定と組織変革をコードで加速させるForward Deployed Engineer (FDE) を募集しています。FDE は単なる導入支援ではありません。 顧客企業の経営課題をテクノロジーで分解し、LLM・対話データ・業務フローを融合させたエンタープライズ級AIアーキテクチャを設計・実装します。 その成果を SaaS プロダクトチームに還元し、プロダクトの進化サイクルを先導します。当社のミッションは「対話をデータ化して経営を変革する」。 営業・製造・人材・IRなど対話中心の業務を変革するプロダクトを提供中です。 FDE のミッションは、生成AIを「経営変革の武器」として実装し、AI Transformation を現実に変えること。 マッキンゼー、BCG、AWS など魅力あふれるメンバーと共に、生成AI時代の産業変革を支えるエンジニアリングをリードしませんか。・Bring Out の対話解析AIを、顧客のシステム基盤(CRM / SFA / 音声解析 / ERPなど)に統合・API設計・連携、LLM・RAG・音声認識などの要素を組み合わせた新ユースケースのアーキテクチャ設計・複雑な非構造データを処理する解析パイプラインの最適化・汎化設計・クライアント課題をもとにした高速PoC〜MVP開発・OpenAI / Anthropic / Vertex AI など各種モデルを用いたLLM統合・パフォーマンス検証・新しい対話解析ユースケースの技術検証・再利用可能な仕組み化・BizDev・AI・Backend チームと協働し、現場実装の知見を設計原則に昇華・技術的リスクを特定し、再現性ある開発プロセスを設計・技術標準化・共通モジュール化を推進し、プロダクトのスケーラビリティを向上
Senior Backend Engineer
Full Cycle Engineer(FCE) ー 顧客価値を創るAI時代のエンジニアへ
Full Cycle Engineer は、顧客価値の創出を最初から最後まで担います。単に要件を実装するのではなく、顧客課題を発見し仮説を立てソリューションを設計しAIを活用して開発し本番へ届け効果を測定し継続的に改善するというプロダクト開発の全サイクルをリードします。ただし、すべてを一人で抱えるわけではありません。Product Manager や Subject Matter Expert、ビジネスチームと協働し、フェーズごとに主担当を持ちながら、成果にオーナーシップを発揮します。アイデアから顧客価値の創出まで、一つの取り組みをオーナーとして推進します。例えば、顧客課題の発見仮説検証プロダクト体験の設計AIを活用した開発本番リリースKPIの計測継続的な改善AIを前提とした新しい開発プロセスの構築などに携わります。チケットを担当するのではなく、成果に責任を持つ仕事です。顧客業務やワークフローを理解する顧客・社内メンバーへのヒアリング解くべき課題を見極める仮説を素早く検証する曖昧な課題を具体的なソリューションへ落とし込むProduct Manager や Subject Matter Expert と協働するユーザー体験を設計する短期的な成果と長期的な保守性を両立するAIを前提とした開発スタイルを実践するAIを活用した開発プロセスを改善する新しいAI技術を検証・導入する社内の生産性を高めるツールや仕組みを構築するアーキテクチャ設計本番品質の実装可用性・セキュリティ・運用性の担保本番運用と継続改善プロジェクト全体をリードする技術・プロダクト両面で意思決定するリリース後の効果を測定するデータをもとに改善を続ける技術水準を引き上げるチームメンバーを支援・育成する開発プロセスを改善する技術的な意思決定をリードする■製品紹介
対話データ解析 AI SaaS「Bring Out」を開発しています。ブラックボックス化されやすい対話データ(商談・社内会議・サービス現場で交わされる会話)を分析し、重要情報を抽出することで、導入企業や働く人々の生産性向上に貢献します。すでに IT・人材・M&A・不動産・製造・医療など様々な業界で活用され、営業・商品開発・R&D・ファイナンス・人事など幅広い職種で使われています。現在は主にエンタープライズ企業向けに提供しており、高い機密性・可用性・柔軟なデータ連携が求められます。■このポジションの特徴
■技術環境バックエンド:Node.js、TypeScript、Python、GraphQLデータストア:PostgreSQL、AWS S3、DynamoDBインフラ:AWS、Terraform、Docker、CircleCIAI 活用:AI コーディングツール(GitHub Copilot 等)、LangChain / CrewAI / AutoGen、OpenAI・Anthropic 等の LLM、RAG■評価指標
私たちは、アウトプットではなくアウトカムを評価します。例えば、顧客への価値ビジネスへのインパクトプロダクト品質デリバリースピードチーム全体へのレバレッジAI活用による改善チームへの貢献などを総合的に評価します。■入社後30日
まずはBring Outを理解する期間です。期待することプロダクトと事業を理解するシステム構成・アーキテクチャを理解するAI Firstな開発スタイルを習得する顧客やユースケースを理解する初めての本番リリースを経験する設計レビューや議論に参加する■入社後60日
少しずつオーナーシップを持ち始めます。期待すること中規模機能を主体的にリードする技術的な設計判断を行うプロダクト企画に参加する開発プロセスを一つ改善するコードレビューを通じてチームへ貢献する■入社後90日
Bring OutのFull Cycle Engineerとして自立することを期待します。期待すること顧客課題の発見からリリースまでを自ら推進できる顧客との対話を通じて課題を定義できるプロダクトの方向性について提案できるAIを活用した開発を主体的に実践できる顧客・事業へのインパクトを生み出せる開発プロセスそのものを改善できる■キャリアパス
Full Cycle Engineerはゴールではありません。経験や志向に応じて、Principal EngineerTechnical LeadProduct LeadSolution ArchitectForward Deployed EngineerEngineering Manager新規事業・新規プロダクト責任者など、多様なキャリアへ広がります。技術領域ではなく、「どれだけ大きな課題を解決できるか」がキャリアを決めます。■Bring Outで働く理由
ソフトウェア開発は、インターネットの登場以来最大の転換期を迎えています。多くの企業は、「AIでエンジニアの開発効率をどう上げるか」を考えています。一方、Bring Outが考えているのは、「AI時代において、ソフトウェア開発そのものはどうあるべきか」という問いです。もしあなたが、AIを使ってコードを書く「だけ」ではなく、AI時代の新しい開発スタイルそのものを創りたい。そう考えているのであれば、ぜひ一度お話ししましょう
Senior Technical Program Manager
Senior Technical Program Manager ー 約束を守る開発組織に
Bring Out の開発組織では、ビジネスの急伸に合わせ、AI-firstかつデータドリブンな開発モデルを構築中です。感覚や属人性に依存せず、Four Keys(デプロイ頻度・変更リードタイム・障害率・復旧時間) に代表される定量指標を基盤にPDCAを回します。TPMはその中心に立ち、「約束を守る開発組織」を実現するために、次のミッションをリードします。・プロダクトリリースの工程・リスク・進行を可視化し、確実なDeliveryを実現する・チーム・外部パートナー・海外拠点を横断して、リリースリスクを最小化する・データに基づく改善とAIツール活用を通じて、開発スピードと品質を両立させる・Product Manager と連携し、ロードマップを実行計画(マイルストーン・スプリント)へ落とし込む・ETA(Estimated Time of Arrival)・依存関係・リスクを管理し、Notion・Slack・GitHubを通じてチームと共有・開発進捗・品質・リリースリスクをモニタリングし、定例会議・レビューを運営・外部システムAPI(Salesforce・HubSpotなど)連携案件の技術窓口を担当・外部開発会社・海外拠点の生産性・品質を定量的にモニタリング・Four Keysなどを用いたPDCAサイクルの運用と改善・Slack・Notionを活用した開発プロセスの標準化・ドキュメント整備
Site Reliability Engineer(SRE)
Site Reliability Engineer(SRE)
信頼性を、運用の頑張りではなく、エンジニアリングで高める。1年でサービス規模は約3倍になりました。その先に必ず来る壊れ方に、起きる前に手を打つ。繰り返す運用作業はコードに置き換え、障害が起きても原因をすぐに説明できる状態をつくる。Bring OutのSREは、AIを活用するプロダクトと開発組織が、速くリリースしながら顧客の信頼を守れるよう、信頼性・Observability・自動化の基盤を設計し、つくるエンジニアです。アラートやチケットを処理する役割ではありません。どの信頼性指標を改善し、どの運用作業をなくし、開発者にどんな基盤を提供するのか。それを自分で決め、ソフトウェアで実現していく仕事です。なぜ今、このポジションなのかBring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。顧客が預けているのは、社内会議や商談という最も機密性の高いデータです。1社が複数の部門・拠点で使うことが前提のため、顧客が1社増えても負荷は1社分では増えません。可用性とパフォーマンスの毀損は、機能の欠陥以上に信頼を損ないます。一方で、これまで基盤レイヤーは、組織としてのオーナーシップが明確になっていませんでした。責任の所在が曖昧な領域が生まれ、その制約が機能開発のボトルネックになり、システム原価の改善にも全体を見て手を打つ人がいない状態でした。そこでBring Outは、開発組織を「アプリケーション開発」と「基盤・SRE」の2層に整理し、LLM・課金・対話分析にオーナーシップを持つPlatformチームを新設します。SREはPlatformチームの一員として、LLMを含む基盤全体の信頼性に責任を持ちます。SREは現在1名が在籍しており、今回の募集で1名を増員し、2名体制にします。すでに兆候が出ている課題もあります。データベースの瞬間的なCPU上昇と、接続数の余裕不足ストレージ容量の継続的な増加文字起こし用GPUの調達リスクLLMを含むAI処理のレイテンシとコストの増加「いずれ顕在化する」課題ではなく、すでに見えている課題です。完成した基盤を運用するのではなく、在籍するSREと役割を分担しながら、これからのBring Outの信頼性の土台を設計していただきます。お任せしたいことまずは、システムの状態を見える化し、守るべき水準を決め、LLMを含む基盤のスケールに先回りすることに集中していただきます。そのうえで、自動化と開発者体験の改善へ領域を広げていきます。Observabilityの整備「Monitoring」中心だった運用を、システムの内部状態を説明できる「Observability」へ引き上げるログ・メトリクス・トレースを統合し、障害時に原因を追える状態をつくるアラートを見直し、対応が必要なものだけが確実に届く設計にする「アラートは鳴っているが、何が起きているかは分からない」を終わらせることが、最初のゴールです。SLI/SLOの導入可用性・レイテンシ・処理の完了時間など、顧客体験に直結する指標をSLIとして定義する開発チームやビジネスチームと、運用すべき水準をSLOとして合意するSLOの状況を、リリースや改善の優先順位を決める判断材料として使える状態にする数値を決めることより、「この水準で運用する」と組織に納得してもらうプロセスの設計が難所になります。キャパシティプランニングとスケーリングデータベース、ストレージ、文字起こし用GPUの負荷を予測し、増強・調達の計画を立てる特に調達リードタイムのあるGPUについて、需要の予測と発注判断を担うデータベースのパフォーマンス改善や、接続数・負荷のボトルネック解消を進めるLLMの運用管理LLMの運用管理は、SREの担当領域です。プロダクトの中核にあるAI処理を、信頼性とコストの両面から管理します。LLM APIや文字起こし処理のレイテンシ、エラー率、レート制限、トークン消費量、コストを可視化し、管理する外部APIの遅延や障害に備えて、リトライ、フォールバック、キューイングを設計・実装するモデルやプロバイダの変更を、品質・レイテンシ・コストへの影響を確かめながら安全に進められる仕組みをつくる処理量の増加に対して、品質を保ちながらコストが線形に増えない構成をつくる基盤起因の障害の再発防止オンコール・インシデント対応のプロセスはTechnical Supportチームが持ちます。SREは、基盤が原因の障害について、技術的な原因究明と再発防止策の実装に責任を持ちます。インシデント時に、Technical Supportチームや開発チームと連携して基盤側の調査を担う振り返りで特定した基盤側の課題について、再発防止策を実装まで見届ける調査に必要なダッシュボードやランブックを整え、次の障害で原因に早くたどり着ける状態をつくるその先に広げていく領域基盤の見える化と水準が整い始めたら、次のテーマにも取り組んでいただきます。トイル削減と自動化:繰り返す運用作業を、コード、セルフサービス、自動修復に置き換える。AIによるアラート要約や調査支援、ランブックの自動化も検証する開発者体験の向上:IaC、CI/CD、デプロイの仕組みを整え、各チームが自律的に安全にリリース・運用できる基盤を提供するアクセス権限とセキュリティ:過剰な特権を見直し、一時付与や最小権限、シークレット管理の仕組みを整えるコストと非機能要件の意思決定:システム原価を可視化し、可用性・パフォーマンス・コストのどれをどの順で守るかを決め、その判断を組織に説明する大切にしたい指標信頼性は、何も起きないことでは測れません。顧客が安心して使い続けられているか、障害から学び、同じ問題を繰り返していないかを重視します。SLO達成率:定義した水準を、実際に守れているか障害の検知・復旧までの時間:顧客が気づく前に検知できているか。基盤側の原因特定にどれだけかかっているか原因が分からない障害の比率:Observabilityが機能しているかの実質的な指標基盤起因の障害の再発率:再発防止策が実装まで到達しているかシステム原価:処理量や売上の伸びに対して、インフラとAI処理のコストが線形に増えていないかトイルの量:手作業の運用が、自動化によって減っているか具体的な目標は、入社後にベースラインを計測したうえで一緒に設定します。向き合う技術| 領域 | 技術 |
| バックエンド | Node.js / TypeScript / Python / GraphQL |
| データストア | PostgreSQL / AWS S3 / DynamoDB |
| インフラ | AWS / Terraform / Docker / GitHub Actions |
| 可観測性 | Datadog等のObservabilityツール(導入・拡充はこのポジションの担当領域) |
| AI処理 | LLM API、文字起こし用GPU |すべての技術に最初から精通している必要はありません。本番環境で起きていることを根拠に基づいて説明し、ソフトウェアで改善できることを重視します。
Solutions Architect
Solutions Architect ー 顧客システムとBringOut接続の設計者
私たちは、企業に眠る非構造データ──中でも重要性の高い「対話データ」を自然言語処理技術(LLM)で解析し、企業固有の“思考データ”として生成AIに学習させることで、経営の意思決定に活かす仕組みを提供しています。企業が保有するデータの約9割を占める非構造データには、経営の判断軸や現場の知恵、顧客の声といった“数値化できない知”が眠っています。これまで扱いづらかったこれらのデータを体系的に理解し、経営に活用できる時代が到来しました。私たちはこの変化を“データ経営の新たなフロンティア”と捉え、非構造データから洞察を導き出し、トップマネジメントと共に変革シナリオを設計・実行するコンサルティング事業を展開しています。本ポジション(シニアソリューションアーキテクト)は、エンタープライズ企業向けにSaaSをカスタマイズし提供する個別ソリューション構築をリードするリーダーです。クライアント特有の要件に応じた開発を、一気通貫で設計から実装まで推進していただきます。・クライアントとの折衝における技術面での要件議論をリード・プリセールス段階での技術検討・PoC設計(営業・コンサルタントとの協働)・要件定義〜基本設計〜実装・検証〜リリースまでの技術統括・プロジェクト全体の進行管理・課題解決・リスクマネジメント・外部ベンダー/フリーランスの選定、契約、進捗・品質管理・設計・実装レビューを通じた品質担保・運用・保守体制の構築およびモニタリング設計※案件規模は数人月〜半年程度、最大5名規模のPoC/中規模開発が中心です。
Technical Support Engineer
Technical Support Engineer
技術で顧客の「困った」を解き、プロダクトの次をつくる。ログに残された小さな手がかりから、顧客の業務を止めている原因を見つける。複雑なシステムの挙動を読み解き、次に何をすればよいかをわかりやすく伝える。そして、一度の解決を、次の顧客が困らないための仕組みに変えていく。Bring OutのTechnical Support Engineerは、顧客に最も近い場所で技術的な課題の解決をリードし、その知見をプロダクトとサポートの品質に還元するエンジニアです。これまで培ってきた技術調査力と顧客対応の経験を、より複雑な課題の解決へ。自ら仮説を立て、関係者を巻き込み、解決まで進める力が、顧客の信頼にも、プロダクトの品質にもつながる仕事です。なぜ今、このポジションなのかBring Outは、エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長しています。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただき、IT・人材・M&A・不動産・製造・医療と、向き合う業界も多様です。APIの整備が進み、顧客のシステムとBring Outをつないで業務プロセスの一部として使うケースも増えました。だからこそ、必要なのは決まった回答を返すサポートではありません。顧客が実現したいことを理解し、システムを横断して課題を解き、安心して活用できるところまで伴走する技術者です。そこで、専任のTechnical Supportチームを新設します。今年はTechnical Support Lead 1名とTechnical Support Engineer 2名の3名でスタートし、事業の伸びに合わせてチームを大きくしていく計画です。チーム全体の方針や運用設計はTechnical Support Leadが担い、Technical Support Engineerには、担当案件の調査・解決を主体的に進め、現場の知見から対応手順や開発連携を改善することを期待しています。立ち上げ期のメンバーとして、これからのBring Outのサポートを形づくる機会があります。お任せしたいこと技術的な問い合わせの受付から、調査、原因の切り分け、解決、顧客への説明まで、一連の対応を主体的に担います。案件の影響度や緊急度を見極め、必要に応じてTechnical Support Leadや開発チームを巻き込みながら、解決までの進行に責任を持ちます。立ち上げ期はこうした技術対応に集中し、チームの成熟に合わせて担う領域を広げていきます。顧客の状況を理解し、解決への道筋をつくる問い合わせの背景と顧客が実現したいことを把握し、解決すべき課題を明確にする発生条件、対象データ、発生時刻、業務への影響を整理し、調査の優先順位と対応方針を判断する技術的な内容をわかりやすく説明し、制約や見通しも含めて、次のアクションを顧客と合意する技術的な手がかりから、問題の所在を明らかにするログ、エラーメッセージ、システム構成、再現結果をもとに調査方針を立て、仮説検証を進めるAPI・データ連携、プロダクトの挙動、利用環境や設定など、複数の観点から原因を切り分ける既知の問題や仕様に基づく解決策、回避策を案内し、顧客と結果を確認する開発チームと協力し、解決までつなぐ開発対応が必要な場合、再現手順、調査結果、影響範囲を整理してエスカレーションするTechnical Support Leadや開発チームと連携して対応状況を追い、顧客に見通しと進捗を伝える解決後の動作確認までフォローし、顧客が安心して利用を再開できる状態を支えるオンコール対応オンコールプロセスのオーナーはTechnical Supportチームです。実際の対応は開発チームも担い、両チームで連携してインシデントの解決にあたります。Technical Support Engineerは、オンコール当番として対応責任を担います。Technical Support Leadが主導する体制・手順に基づき、初動から技術調査、エスカレーション、顧客への状況共有、復旧・解決確認までを主体的に進めます。オンコール時に状況と顧客への影響を把握し、初動対応と技術的な切り分けを行う重大度や対応基準に応じてTechnical Support Lead・開発チームを巻き込み、必要な調査情報を揃えて連携する対応状況と判断内容を記録し、顧客への状況共有と当番間の確実な引き継ぎを行う対応後の振り返りを通じて、再発防止やオンコール手順の改善に貢献するその先に広げていく領域チームと仕組みが回り始めたら、次のテーマにも取り組んでいただきます。ナレッジとプロダクトへのフィードバック:調査で得た知見をナレッジとして残し、繰り返し発生する課題を製品改善のフィードバックにつなげるAIを活用した調査・対応:過去事例の検索や調査情報の整理、回答案の作成にAIを取り入れ、対応品質と効率を高める先回りのサポート:自社プロダクトであるBring Outを活用し、問い合わせを待つだけでなく、よりプロアクティブなサポートを実践する向き合う技術顧客の課題を調査する中で、以下の技術に触れ、プロダクト全体への理解を深めていきます。| 領域 | 技術 |
| バックエンド | Node.js / TypeScript / Python / GraphQL |
| データストア | PostgreSQL / AWS S3 / DynamoDB |
| インフラ | AWS / Terraform / Docker / GitHub Actions |プロダクトの機能開発を主業務とするポジションではありません。求めるのは、ログやシステムの挙動を読み解き、根拠に基づいて問題を説明し、解決につなげる力です。すべての技術に最初から精通している必要はありません。
Technical Support Lead
Technical Support Lead
顧客の信頼をチームで生み出す。サポートの仕組みをゼロからつくる。Bring OutのTechnical Support Leadは、新設するTechnical Supportチームを立ち上げ、開発チームとともに、顧客の課題を確実に解決できるサポートプロセスをつくるポジションです。顧客対応の現場を知り、技術的な調査に踏み込み、チームの判断を支える。個人の問題解決力を、組織として再現できる力に変えていくことが、この役割のミッションです。「もっとよいサポートのあり方があるはずだ」。これまで現場で感じてきたその思いを、プロセスとチームの形にしていきませんか。なぜ今このポジションなのかBring Outは、企業の一次情報をAIで活用し、日々の業務や意思決定に役立てるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手企業にご利用いただいています。最近ではAPIの整備が進み、顧客のシステムとBring Outをつないで業務プロセスの一部として使うケースも増えました。その分、問い合わせの背景や技術的な課題は多様になり、顧客の業務への影響を踏まえた判断が求められています。この成長を、個々の担当者の経験や頑張りだけで支えることはできません。そこで、問い合わせを受け止め、適切に調査し、必要な専門性につなぎ、解決まで伴走する専任のTechnical Supportチームを新設します。今年はLead 1名とメンバー2名の3名でスタートし、事業の伸びに合わせてチームを大きくしていく計画です。完成した組織を運営するのではなく、その最初の形をつくる立ち上げを担っていただきます。お任せしたいことまずは、チームの立ち上げ、サポートプロセスの整備、技術対応の3つに集中していただきます。そのうえで、チームの成熟に合わせて担う領域を広げていきます。Technical Supportチームの立ち上げと運営チームの役割、担当範囲、責任分担を整理し、運営体制を構築する問い合わせ量や難易度、メンバーのスキルを踏まえたアサインと優先順位づけを行うオンボーディング、技術・製品知識の共有、対応レビューを通じて、メンバーの成長を支援する対応状況や業務負荷を把握し、品質と持続可能なチーム運営を両立する開発チームと協業したサポートプロセスの構築受付、状況把握、技術調査、エスカレーション、顧客への報告、解決確認までの一連の流れを設計する開発チームと、エスカレーションの条件、必要な調査情報、優先度、進捗共有の方法を合意する再現手順、ログ、影響範囲、調査済み事項を整理するためのテンプレートや手順を整備する運用を実際のケースで検証し、現場に定着するまで見直すオンコールプロセスの設計・運営オンコールプロセスのオーナーはTechnical Supportチームです。実際の対応は開発チームも担い、両チームで連携してインシデントの解決にあたります。Technical Support Leadは、プロセスの責任者として体制の設計・運営・改善を主導するとともに、自らもオンコール対応を担います。開発チームと役割分担を合意し、当番体制、連絡経路、エスカレーション基準、引き継ぎ手順を整備するインシデント時の初動、影響範囲の把握、開発チームとの連携、顧客への状況共有を推進する対応後の振り返りを主導し、再発防止や手順の改善につなげる開発チームを含む当番担当者の負荷を把握し、持続可能な運用に見直す複雑な技術課題への対応と判断支援立ち上げ期には自ら顧客対応や技術調査に入り、現場の課題を把握するログ、システム構成、API・データ連携の挙動をもとに、問題の切り分けを支援する難易度や影響の大きいケースで、メンバーとともに対応方針を判断する開発チームと連携し、顧客への説明や回避策の案内、解決までのフォローを推進するその先に広げていく領域チームと仕組みが回り始めたら、次のテーマにも取り組んでいただきます。ナレッジとプロダクトへのフィードバック:解決事例をナレッジとして蓄積し、繰り返す問い合わせを開発チームへの改善提案につなげるAIを前提としたサポートプロセス:ナレッジ検索や回答作成、調査の支援にAIを取り入れ、人が複雑な課題の解決に集中できる状態をつくる先回りのサポート:自社プロダクトであるBring Outを活用し、問い合わせを待つだけでなく、よりプロアクティブなサポート戦略を描く大切にしたいサポート指標エンタープライズ向けの技術サポートでは、ケースごとの難易度や業務への影響が大きく異なります。処理件数を増やすことではなく、顧客が安心して利用でき、重要な課題が放置されず、確実に解決へ進んでいることを重視します。CSAT(サポート対応への顧客満足度):解決の質と説明・コミュニケーションを確認する。回答率も併せて見て、少数の回答だけで判断しない初回応答時間:受付から、次のアクションにつながる最初の実質的な回答までの時間SLA遵守率:合意した応答・更新の期限を守れているかTTR(解決までの時間):重大度や案件種別ごとに、中央値と長期化した案件を確認する。顧客からの情報待ち・開発対応待ちなどの内訳も追う未解決案件数・滞留期間:特に顧客への影響が大きい案件の放置を防ぐ再オープン率や同一課題の再問い合わせは、解決の質を確かめる補助指標として使います。FCR(初回解決率)は定型的な質問の改善に用い、複雑な技術課題にまで一律に初回解決を求めたり、必要な開発連携を抑制したりする指標にはしません。速く閉じることではなく、確実に解決し、同じ困りごとを減らすこと。具体的な目標は、立ち上げ期の実績を踏まえて一緒に設定します。向き合う技術技術調査と開発チームとの連携を通じて、以下の環境への理解を深めていきます。| 領域 | 技術 |
| バックエンド | Node.js / TypeScript / Python / GraphQL |
| データストア | PostgreSQL / AWS S3 / DynamoDB |
| インフラ | AWS / Terraform / Docker / GitHub Actions |プロダクトの機能開発を主業務とするポジションではありません。技術的な根拠に基づいて問題を整理し、メンバーの判断を支え、開発チームと解決に向けた議論ができることを重視します。すべての技術に最初から精通している必要はありません。
オープンポジション
オープンポジション
採用人事(リクルーター)
採用人事(リクルーター)
CEO直下の採用チーム立ち上げをリードするパートナーを募集Bring Outは、AIで企業の経営変革を実装まで届けるAXファームです。採用する相手は、戦略ファームやBIG4出身のコンサルタント、自社プロダクトを開発するエンジニア、経営幹部。この三つの層をどれだけ速く、どれだけ高い水準で採用できるかが、事業の成長速度を決めます。全ての採用ポジションが事業成長に不可欠であり、プロフェッショナルファーム級の採用ハードルを敷いています。日経「未来の市場をつくる100社」、東洋経済「すごいベンチャー100」に選ばれ、エンタープライズ企業への導入が広がる今、採用は経営の最重要アジェンダになっています。採用人事(リクルーター)は、開発部門またはビジネス部門の採用オーナーとして、CTO・CROと直接組み、採用計画の策定から入社までを推進する役割です。向き合う相手はパートナー・プリンシパル級のAXコンサルタント、シニアエンジニア、CxO候補。市場で最も採用難易度の高い層を経営陣と並んで口説きにいきます。最先端AIを活用しAI Nativeな採用活動をデザインする生成AIによって、採用人事の仕事の中身は入れ替わりつつあります。日程調整、情報の転記、定型連絡、レポート作成に使っていた時間は仕組みに任せられるようになり、人に残るのは誰を採るかの判断、候補者との対話、経営との議論、仕組みの設計です。Bring Outの採用チームは、この入れ替えを自分たちの手で進めています。ATSのAPIとClaude Codeをつなぎ、多くの採用業務を自動化してきました。判断は人が下し、その手前の作業をAIが受け持つ分担です。採用人事が自分でAIを扱い、自分の業務を組み替える働き方です。顧客の経営変革を実装まで届ける会社で、採用チームも同じやり方で自分たちを変えています。体制とお任せしたい範囲採用チームは現在、採用責任者1名と業務委託のオペレーション担当で動いています。年間30名規模の採用計画に対して、体制はまだ小さな規模です。そのため、入社いただく方には最初から一部門の採用をオーナーとして任せます。将来的には採用にとどまらず、オンボーディングや組織開発まで扱うPeople & Cultureのような機能へ、このチームを一緒に広げるつもりです。① 担当部門の採用戦略と計画CTOまたはCROとともに採用ポジションの要件・優先順位・時期を決めるターゲット人材像と訴求ポイントを言語化し、JD・スカウト文・エージェント向け資料に落とす歩留まり・リードタイム・チャネル別の実績を見て、計画と打ち手を更新する② 母集団形成と選考の推進重点エージェント十数社との関係構築、ブリーフィング、推薦の質の引き上げダイレクトリクルーティング、リファラル、採用広報を組み合わせたチャネル運用面接官との連携、候補者体験の設計、オファーからクロージングまでの推進③ 採用業務のAIによる組み替えClaude CodeとATS APIを使った業務の自動化採用基準・評価観点をドキュメント化し、AIが参照できる形に整備する自動化で生まれた時間を候補者と経営陣との対話に振り向ける④ 採用のその先へ内定承諾から入社、立ち上がりまでのオンボーディング設計入社後の活躍を追い、採用基準にフィードバックする仕組みづくり組織開発・ピープルサクセスを含むPeople & Culture機能の立ち上げ