株式会社ブリングアウト の全ての求人一覧

私たちは今、自社のプロダクト開発そのものを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 時代のプロダクト開発はこうあるべきだ」という型を自分で作る仕事です。

顧客の「今ほしい」を、ロードマップを待たずに届ける。Fast Trackは、プロダクトの変化を短いサイクルで何度も起こすチームです。要望の背景をつかみ、何をどこまでつくるかを自分たちで提案し、出したものが顧客の現場でどう使われたかまで見届けます。最近では、英語や中国語で商談をする顧客から、Bring Outで多言語での商談を管理したいという声が届きました。当時、文字起こしは日本語だけ。Fast Trackのエンジニアは、顧客組織ごとに文字起こしエンジンを切り替えられるようにするところから着手しました。いま、Bring Outには中国語の商談がアップロードされています。これまで使いたくても使えなかったユーザーが、使い始めています。Bring OutのBackend Engineer（Fast Track）は、ロードマップの外から届く優先度の高い顧客要望や不具合に向き合う、バックエンド中心の開発ポジションです。「なぜこの機能が必要なのか」から考え、何を、どの順番で、どこまでつくるかを決めるところに関わります。必要な検証は省かず、顧客にとって価値のある改善を、速く届けきる。それがFast Trackの仕事です。なぜ今、このポジションなのかBring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。1社が複数の部門・拠点で使うことが前提のため、導入が進むほど、現場ごとの具体的な要望が届きます。その中には、ビジネスへの影響が大きく、次のロードマップを待てないものがあります。Fast Trackは、ロードマップ開発を担うチームとは別に、こうした課題に短いサイクルで応えるチームです。届く要望が増え続けるいま、顧客に届ける改善をさらに増やしていくために、バックエンドエンジニアを迎えたいと考えています。この仕事で得られること実装の先にある、顧客の変化が見えるビジネスチームとのやり取りを通じて、顧客の困りごとやリリース後の反応を受け取れます。使えるようになったか、課題を解消できたかまで追える距離感があります。冒頭の多言語対応でも、ユースケースと必要な設定の粒度を整理したのはエンジニアです。一度にすべてをつくるのではなく、2つのフェーズに分けて届ける方針を提案しました。実装済み：顧客組織ごとに文字起こしエンジンを切り替えられるようにする今後の実装予定：投稿ごとに、日本語・多言語の言語設定を選べるようにする「やらない」も、エンジニアが提案するビジネスチームからのエスカレーションはCTO・Engineering Manager（EM）が受け、案件の優先順位や対応方針は Product Manager と EM がAIシステムも活用して検討します。そのうえで、エンジニアも影響範囲や実現方法を踏まえて、代替案や「今回は対応しない」を提案できます。2026年7〜9月の四半期では、23件の開発要望のうち6件について、エンジニアから対応しない判断を提案しました。速く応えることと、すべてを引き受けることは別。その判断を、つくる側が担えるチームです。AIで、開発と運用そのものを変えていけるObservability システムと AI を組み合わせたアラート対応の半自動化や、AI支援によるコーディング・コードレビューに取り組んでいます。ツールを使うだけでなく、繰り返す調査や対応をどう減らせるかをチームで考え、試していけます。開発の20%を、技術的負債の返済とオンコールに充てる顧客要望に応えるだけでなく、改善を安定して届け続けるための時間を、最初から確保しています。速く出した変更を、負債のまま積み残さないための仕組みです。お任せしたいこと顧客要望・機能追加の設計と実装要望の背景にある課題を、ビジネスチームと確認する案件の規模・影響範囲・必要な検証を見立て、実装方針や段階的な対応を提案するバックエンドを中心に設計・実装・検証し、リリース後の動作確認まで担う短いサイクルで扱いきれない案件は、より大きな開発として切り出すことを相談する期日や対応範囲の見直しが必要になったら、理由と代替案を添えて早めに調整するエンタープライズ顧客のセキュリティ要件に応える改修なども扱います。不具合の調査・修正と技術的負債の返済顧客から報告された不具合を調査し、修正をリリースまで届ける繰り返す不具合や問い合わせの根本原因を、コードの側から取り除く変更に伴う技術的負債を見える化し、優先順位を付けて返済するオンコール当番として、インシデント対応や調査を担うチームと働き方迷ったら、すぐ隣に相談相手がいるレポート先はEMです。仕様・設計・実装で迷ったら、まずFast Trackのメンバーに相談できます。別チームのSREやバックエンドエンジニアとの協業も日常的です。インシデントのときも、Fast Track内での相談から始め、必要に応じて別チームへと支援の輪を広げていきます。オンコールの現状と今後頻度・期間：現在は月に1回程度、1週間の当番対応時間：通常のビジネス時間のみ。夜間・休日の対応はありません当番中の業務：オンコールチケットへの対応と、技術的負債の解消今後、同じEMの下にTechnical Supportチームを立ち上げ、オンコールの主体をそちらへ移す予定です。上記は現在の体制で、チームの立ち上がりに合わせて役割分担を見直していきます。入社後に期待すること最初の半年は、プロダクトとコードベースを理解し、担当案件の調査・設計・実装・検証・リリースを自分の手で届けきることに集中していただきます。チームの進め方そのものを変えていくのは、その先の楽しみです。これまでのご経験に応じて、最初から設計レビューや開発フローの改善、AIによる自動化まで、広く担っていただくこともできます。入社半年後には、案件を進める力に加えて、次のような姿勢を期待しています。課題を問い直す：開発要望をそのまま実装するのではなく、なぜ必要なのかを確かめ、より良い顧客体験を提案する進め方を改善する：既存の開発プロセスにも、気づいた点を積極的に提案する仲間と問題解決に動く：インシデント時にも、顧客の問題を解決するために能動的に動き、仲間を支援する成果として大切にすること見るのは処理したチケットの数ではなく、顧客に必要な改善を安全に届けられているかです。着手からリリースまでの時間と、案件規模・方針の見立ての精度合意した期日を守り、見直しが必要なときに事前に調整できているかリリース後の不具合や、同じ原因の問い合わせを減らせているか具体的な目標は、入社後に現状を確認したうえで一緒に設定します。向き合う技術| 領域 | 技術 | | --- | --- | | バックエンド | Node.js / TypeScript / Python / GraphQL | | データストア | PostgreSQL / AWS S3 / DynamoDB | | インフラ | AWS / Terraform / Docker / GitHub Actions | | 可観測性 | Datadog等 | | AI処理 | LLM API、文字起こし用GPU | | 開発 | Claude Code等のAIコーディングツール |すべての技術に最初から精通している必要はありません。初めて触るコードでも、自分で読み、影響範囲を確かめてから変更できることを重視します。顧客の現場で何が変わったかを、自分の目で確かめられる開発をしたい方へ。顧客の課題を理解し、つくるものの判断から実装、その後の改善まで関わりたい方。Bring OutのFast Trackで、顧客に届く変化と、開発の仕組みを一緒につくりませんか。

一次情報を精錬し、日本の経営モデルを刷新するこれまでの経営は、集計された数字と中継された報告をもとに判断されてきました。しかし成果を左右する分かれ目は、その奥にある一次情報の中にあります。ブリングアウトは、対話データから一次情報を抽出し構造化するAIプラットフォームと自社プロダクトを併せ持ち、そこから成果を動かすポイントを見極めて、顧客ごとのサービスや業務の型として実装し、組織に定着させます。仕事は戦略の立案にとどまりません。経営判断の質が変わる地点まで、現場の業務に手を入れて届けます。これまでも、日本を代表するエンタープライズ顧客とともに、業界のコアプロセスをAI Nativeに変える取り組みを進めてきました。経営と現場が同じ問いで動ける状態をつくり、会社の見方、判断、動き方を変える。その変化が一社の成果を生み、やがて他社から参照される新しい経営の型になる。私たちは、そうした企業を増やすことで日本企業全体の競争力を底上げしようとしています。事業は急成長のフェーズに入り、次の課題は資本戦略です。この成長を資本市場の言語に翻訳し、資金調達と事業の数字の両方から会社の成長を加速させる経営メンバーとして、CFOをお迎えします。CFOの役割当社にとって初めてのCFO招聘です。期待しているのは、事業の成長を投資家が正しく評価できるエクイティストーリーにまとめて資金調達と資本政策を主導すること、そして事業の成長を数字で捉え、予算と着地見込みをもとに経営と事業部門の意思決定を動かすことです。投資家とのコミュニケーション、M&A、事業会社との資本業務提携やアライアンスの交渉も担っていただきます。上場準備はVP of Corporateが責任者を務め、経理の実務は経理チームが担う体制です。CFOは資本市場と事業の数字に集中できます。将来的なコーポレート機能全体の統括は、ご経験と志向に応じて設計します。このポジションの面白さ① カテゴリのない事業を資本市場の言語にする対話データを経営の一次情報に変える当社の事業には、まだ確立された市場カテゴリがありません。しかもプラットフォームのリカーリング収益とプロフェッショナルサービスの収益が併存するハイブリッド型の損益構造で、これをどう指標化し、どう語るかに定石はありません。事業の面白さを投資家が正しく評価できるエクイティストーリーへ翻訳する仕事は、CFO自身の専門性が最も活きる領域になります。② 資金調達を白紙から設計できるどこから調達するか、エクイティとデットの使い分け、どの規模とタイミングで上場するか、成長投資をどこまで踏み込むか。前例のない意思決定がすべてこれから始まります。財務組織と資金調達を設計すること自体がミッションになります。③ 数字で事業を動かす料金体系や契約期間の設計ひとつで、売上とキャッシュの姿は大きく変わります。予算と着地見込みを手元に置き、事業部門や人事とタイムリーに対話しながら、成長の打ち手を数字の側から仕掛けられます。④ 経営チームと同じテーブルで意思決定する取締役会、株主との対話、経営会議に最初から参画いただきます。コンサルティングファーム、投資銀行、事業会社の出身者が集まる経営チームと、財務の専門性で対等に議論できる環境です。全社でClaude Codeを日常業務に使っており、財務の実務もAI前提で設計し直せます。このポジションで担う4つの仕事① 資金調達・資本政策・IRエクイティストーリーの構築と投資家への説明調達先の設計（VC・CVC・事業会社・金融機関など、資金以外の経営資源も含めた選定）エクイティとデットの使い分け資本政策・ストックオプション制度の設計既存株主・投資家との継続的なコミュニケーション② 事業成長の予実管理と、売上・キャッシュの最大化予算と着地見込みの管理。事業部門や人事への、タイムリーな数字のコミュニケーション利用料や契約期間など、売上とキャッシュを最大化する観点からの料金・契約条件の企画と、AX部門との調整プラットフォームのリカーリング収益（ARR・NRRなど）とプロフェッショナルサービス収益が併存するハイブリッドモデルの、KPI体系と管理会計の設計経営会議への意思決定材料の提供、採用計画・開発投資など部門横断の投資判断への財務目線の提供③ M&A・資本業務提携・アライアンス成長戦略としてのM&Aの検討と財務評価、デューデリジェンス・交渉・PMIの主導事業会社との資本業務提携の交渉アライアンスの条件面の交渉④ 上場に向けた資本戦略上場時期・市場選択に関する経営への提言上場を見据えた資本政策とエクイティストーリーの設計上場準備の実務はVP of Corporateが責任者として進め、CFOは資本戦略の観点から関与処遇について経営幹部ポジションとして、ご経験に応じて個別に設計します。本ポジションは「CFO候補」としてお迎えし、入社時の役職と権限はご経験に応じて設計します。CFO就任を前提とした採用です。ここまで読んでくださりありがとうございます。会社の次の10年を左右する資本戦略を、同じテーブルで設計してくれる方とお会いできるのを楽しみにしています。

「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は、マッキンゼー、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は、エンタープライズ顧客の経営層・事業責任者と深く向き合い、「一次情報経営」という新しい市場の旗手としてアジェンダを切り開く役割を担います。経営層との対話から事業課題を引き出し、自社プロダクトと実装パッケージを提案・受注、顧客の事業変革のパートナーとして深く並走します。また、顧客の事業戦略の中で、ブリングアウトの価値が代替不可能な位置を占め続ける状態を作る役割です。新規アカウントでは、価値の輪郭がこれから具体化していく段階から顧客に入り込み、契約として検討できるテーマへと共に形にしていきます。既存アカウントでは、一度の成果で終わらせず、顧客の戦略実行の中で活かされる位置を共に合意し、業務の中で自然に活きる状態を作っていきます。受注は通過点であり、ブリングアウトが顧客の戦略に欠かせない存在となるまでの設計と判断を担うのが、この役割の核です。価値の輪郭をこれから形にしていく段階の対話まだ言葉になりきっていない関心を拾い、検討テーマとして立ち上げる契約として議論できる形まで価値を共に磨き、Deployment Strategist チームへ繋ぐ顧客の事業戦略における自社の位置づけの確認と、共に進める方向の合意顧客の戦略実行の中で活かされる位置を共に合意していく業務の中で自然に活きる状態への接続顧客のあるべき姿の言語化と、共有資料化拡張シナリオの合意形成顧客側キーパーソンとの長期リレーション構築価値設計プロセスの言語化・標準化Deployment Strategist チームとの密な連携次のフェーズへ進めるか・一旦立ち止まるかの判断軸を組織に蓄積

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 チームと協働し、現場実装の知見を設計原則に昇華・技術的リスクを特定し、再現性ある開発プロセスを設計・技術標準化・共通モジュール化を推進し、プロダクトのスケーラビリティを向上

「直しました」ではなく、「ここまでは安心してよい」と言える状態をつくる。脆弱性を見つけて直すだけでは、プロダクトセキュリティは前に進みません。何を今やり、何を今はやらないのか。残るリスクを誰が引き受けるのか。その判断の材料を整え、決まったことを開発組織の中で最後までやり切る。Bring OutのProduct Security Engineerは、CTOの直下で、プロダクトセキュリティの計画を立て、開発組織の中で実行を回し、経営が判断できる形で現在地を伝えるエンジニアです。診断結果をチケットにして渡す役割ではありません。自分でコードとインフラを読み、リスクを測り、優先順位を提案して、開発の計画に載せる。対応済みのリスク、未対応のリスク、その影響と対応計画を明示し、経営がリスクの受容可否を判断できる状態をつくる仕事です。セキュリティを開発のブレーキにするのではなく、安全な設計と実装を開発者が自然に選べる状態をつくります。CTOとともに優先順位を決めながら、専門性と実装力で複数チームに影響を与える、ハンズオンのシニアエンジニアのポジションです。なぜ今、このポジションなのかBring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。顧客が預けているのは、社内会議や商談という最も機密性の高いデータです。1社が複数の部門・拠点で使うことが前提のため、権限やデータの分離に求められる水準も、顧客の規模とともに上がっていきます。エンタープライズの顧客からは、導入の前にも後にも、セキュリティ審査で厳しい質問を受けます。Bring Outは現在、SOC 2 Type 2報告書の取得に向けて取り組んでいます。CIS Controls v8に沿った自己評価も行い、どこに課題があるかは見えています。一方で、見えた課題を開発の計画に載せ、完了まで追い切る専任の担い手がいませんでした。開発組織のリーダーと業務委託のメンバーが対応を進めてきましたが、何から手を付け、何を今はやらないのかを決めて回し続ける役割が、組織として空いていた状態です。そこでBring Outは、プロダクトセキュリティの予算とリソースをCTOの直下に置くことを経営として決め、その実行の中心を担う専任のProduct Security Engineerを迎えます。外部のペネトレーションテスト（Web・iOSアプリ・デスクトップアプリ）や、必要なツールの導入もあわせて進めます。完成した体制を引き継ぐのではなく、Bring Outのプロダクトセキュリティの進め方そのものをつくっていただきます。お任せしたいこと入社初期は、既知の課題とリスクを棚卸しし、対応計画と責任分担を定め、優先度の高い課題を完了まで進めることに集中していただきます。あわせて、現在地を経営に伝える仕組みと、インシデント発生時の技術対応を主導できる備えを整えます。重大な脆弱性への対応、顧客審査・監査、重要な設計レビューは、必要に応じて並行して進めます。AI固有のリスク評価、CIへの検出ツールの導入、開発者の自走を支える仕組みは、リスクに応じて順次整備し、必要であれば初期から前倒しします。残余リスクの受容と、チーム間で解消できない優先順位の衝突は、CTOが最終判断します。Product Security Engineerは、判断材料を整え、承認を得た計画の実行・進捗管理・継続的な見直しに責任を持ちます。計画と優先順位づけ既知の課題とリスクを棚卸しし、影響と対応コストをものさしにして優先順位を付ける何を今やり、何を今はやらないのかをリスクと対応コストから提案し、残余リスクの受容についてCTOの判断・承認を得る新しく見つかった脆弱性を、重大度ごとに定めた対応期限の中で処理できる流れをつくる開発組織の中での実行各開発チームのリーダーと担当・工数・期限を合意し、対応をロードマップに組み込んで、完了まで進捗を管理する開発の優先順位とぶつかったときは、リスクと事業への影響を整理してチームのリーダーと調整し、解消できない場合はCTOの判断を仰ぐ自分でコードとインフラ構成を読み、脆弱性を見つけ、修正方針を示す。必要なら自らも手を動かす「チケットは切ったが、閉じていない」を終わらせることが、最初のゴールです。設計段階からのセキュリティ新機能や重要な設計変更について、開発者とともに脅威モデリングやセキュリティ設計レビューを行い、実装前にリスクと対策を明確にする認証・認可、テナント間のデータ分離、API、機密データの取り扱いを重点的に評価し、必要に応じてコードレビューや検証を行う開発速度を不必要に落とす承認ゲートではなく、設計指針、チェックリスト、再利用可能な仕組みを整え、開発者が自ら安全性を判断できる状態をつくるAIプロダクト固有のリスクへの対応会話・文字起こしデータが、取得、保存、検索、LLMへの送信、出力までの過程で適切に保護されているかを評価するプロンプトインジェクション、機密情報の漏えい、LLMや外部ツールの不適切な呼び出しなどの脅威を、開発チームとともに検証し、現実的な対策を設計するAI機能や外部モデル・サービスを導入する際、データの送信先、権限境界、ログへの機密情報混入などのリスクを整理する経営への報告と判断材料づくり経営に対する説明責任はCTOが持ちます。Product Security Engineerは、CTOが決めるための材料をつくり、経営会議では同席して説明を担います。プロダクトセキュリティの現在地を、定点で報告できる形にする「どこまでやれば十分か」の線引きを、選択肢と残るリスクを並べて提案する非エンジニアの経営陣がそのまま判断に使える資料をつくる外部からの要求への対応顧客のセキュリティ審査の質問票に、技術的な裏付けを持って回答する外部のペネトレーションテストや診断の範囲を設計し、指摘の妥当性・重複・影響を検証して、開発チームと対応方針を整理するSOC 2などの監査に向け、プロダクトと開発プロセスに関する統制の整備・改善、運用証跡の準備、技術的な説明を主導する。全社監査の取りまとめは主担当に含めず、取りまとめを担う担当者と連携する有事の備えと技術対応CTOや関係部門とともにインシデント対応の役割分担とエスカレーション基準を整え、発生時には影響調査、封じ込め、復旧、再発防止の技術対応を主導する顧客への連絡や事業上の判断はCTO・関係部門が責任を持ち、その判断に必要な技術的事実と影響範囲を整理する対応手順や訓練を通じて、開発チームが有事に動ける状態をつくるプロダクトと開発を支える統制プロダクトと開発に関する技術的な統制の設計・改善を主導します。実装と日常運用は、開発・インフラなどの担当者と分担を合意して進めます。社内ITの運用は主担当に含めず、コーポレートセキュリティの担当と連携します。業務委託先を含め、本番環境やデータへの人のアクセスを、付与から棚卸しまで管理できる状態にする調査と説明に必要なログが、必要な期間、改ざんされずに残る状態をつくるCIS Controls等に沿った内部アセスメントを定期的に回し、結果を計画に戻すコーポレートセキュリティの担当と連携し、社内ITとプロダクトの境界で抜けが出ないようにするリスクに応じて整備・拡充する領域初期の重点課題と並行し、リスクと事業上の必要性に応じて、次のテーマにも取り組んでいただきます。既知の課題が減るまで一律に待つのではなく、必要なものは初期から前倒しします。開発の流れへの組み込み：SAST・SCA・シークレット検出などをCIに組み込み、誤検知を減らし、依存ライブラリやソフトウェアサプライチェーンのリスクも含めて、開発者が自分で対応できる状態にする認証・規格への対応判断：顧客の業界から求められる規格（金融機関向けのFISC安全対策基準など）に、どこまで、どの順で対応するかを提案する経営判断への意見：新しい機能や事業の判断に、セキュリティの立場から早い段階で意見を出す将来的には、Bring Outのセキュリティ全体を統括する役割（CISO）を置くことも考えています。この役割で経験を積んでその立場を担っていただく道も、CISOとともにプロダクトセキュリティを率いる道もあります。大切にしたい指標プロダクトセキュリティは、見つけた脆弱性の数では測れません。優先度に応じてリスクを低減できていることと、残るリスクの影響・対応計画が明示され、経営が受容可否を判断できることを重視します。優先度に応じた課題対応の進捗：優先度の高い課題から、計画どおりの対応完了、またはCTOの承認によるリスク受容まで到達しているか新規の脆弱性の期限内対応率：重大度ごとの対応期限を守れているか残るリスクの見える化：今はやらないと決めたものが、理由と合意とともに記録されているか外部要求への対応：顧客審査や監査の指摘に、根拠を持って期限内に応えられているか開発者が自走できる範囲：設計時のリスク確認から検出・修正まで、Product Security Engineerを経由せずに回る範囲が増えているか具体的な目標は、入社後に現状を確認したうえで一緒に設定します。向き合う技術| 領域 | 技術 | | プロダクト | Webアプリケーション / iOSアプリ / デスクトップアプリ | | バックエンド | Node.js / TypeScript / Python / GraphQL | | データストア | PostgreSQL / AWS S3 / DynamoDB | | インフラ | AWS / Terraform / Docker / GitHub Actions | | 可観測性 | Datadog等 | | AI処理 | LLM API、文字起こし用GPU | | セキュリティツール | SAST・SCA・シークレット検出等（選定・導入はこのポジションの担当領域） |すべての技術に最初から精通している必要はありません。自分でコードと構成を読み、リスクを根拠とともに説明できることを重視します。

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時代の新しい開発スタイルそのものを創りたい。そう考えているのであれば、ぜひ一度お話ししましょう

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

信頼性を、運用の頑張りではなく、エンジニアリングで高める。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 |すべての技術に最初から精通している必要はありません。本番環境で起きていることを根拠に基づいて説明し、ソフトウェアで改善できることを重視します。

1社ごとに違う要件を、プロダクトの上で動くかたちにする。顧客ごとに違う業務フロー、システム環境、データ。その要件を、Bring Outのプロダクトの上で確かに動く実装に変える。標準機能で応えるか、個別に作るかを見極め、プロダクト本体の品質を損なわずに届ける。Bring OutのSolution Engineerは、エンタープライズ企業ごとの個別ソリューションの実装を担い、SaaSの開発チームと協業しながら、顧客の現場に合わせてBring Outを形にするエンジニアです。仕様書どおりに作るだけの役割ではありません。顧客の要望を実装の視点で具体化し、プロダクトとの整合を取りながら、1社のために正しいものをつくる仕事です。なぜ今、このポジションなのかBring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。事業は、SaaSと、顧客ごとの個別要件に応えるコンサル/SIの二層で伸ばしています。大手企業になるほど、標準機能だけでは拾いきれない固有の業務フローやシステム連携、データ形式への対応が求められ、こうしたSI案件の相談は増え続けています。一方で、社内の開発キャパシティには限りがあり、受注の機会が採用のスピードに縛られる状態になっていました。そこでBring Outは、Solutionチームの体制を強化します。要件定義・技術統括・外部パートナーの開拓と管理はSolution Architectが担い、Solution Engineerは実装の中心を担います。今年度は、Solution Engineerを最大2名採用する予定です。導入（個別の構築）はSolutionチーム、導入後の運用（問い合わせ対応）はTechnical Supportチームが担います。Solution Engineerは、構築の実装に集中できる環境で、プロダクトに深く踏み込んだ開発に取り組めます。お任せしたいことまずは、Solution Architectが主導する案件の中で、個別カスタマイズの設計・実装を確実に届けることに集中していただきます。そのうえで、案件をまたいで使える仕組みづくりへ領域を広げていきます。実装の視点から、要件を具体化するSolution Architectが主導する要件定義に実装の視点で参加し、顧客の要望を技術要件に落とし込む顧客の既存システムやデータ環境を調査し、実現可能な実装方針を示す実装上の制約やリスクを早い段階で共有し、代替案の検討に貢献する個別カスタマイズの設計と実装Bring Outのプロダクトのコードベースを理解したうえで、顧客ごとのカスタマイズを設計・実装する顧客のシステムとのAPI連携やデータ連携を設計・実装する標準機能で応える部分と個別に作る部分の境界を見極め、保守しやすい形で実装するSaaSの開発チームとの協業カスタマイズがプロダクト本体に与える影響を見極め、SaaSの開発チームと設計をすり合わせる本体に組み込むべき変更は開発チームと相談し、プロダクトとの整合を取りながら進めるコードレビューを通じて、プロダクト全体の品質水準を保つ外部パートナーとの協働外部パートナーの開拓と管理はSolution Architectが担います。Solution Engineerは、実装面でパートナーと協働します。外部パートナーが担う実装について、設計意図を伝え、技術的な質問に応える委託した実装のコードレビューを行い、品質を担保する自分の実装とパートナーの実装を結合し、全体として動く状態にする品質を担保し、リリースまで届ける案件の規模に応じたテストを設計・実施し、リリースまでの品質に責任を持つ構成や仕様をドキュメントに残し、引き継ぎに必要な情報を整えるその先に広げていく領域案件の実装が回り始めたら、次のテーマにも取り組んでいただきます。再利用できる実装づくり：繰り返し求められる要件を共通部品や構築の型にし、次の案件を速く、確実にするプロダクトへの還元：個別の要望から見えた共通のニーズを、SaaSの開発チームと連携してプロダクトの機能につなげるAIを活用した開発：生成AIを開発・テスト・調査に取り入れ、実装の品質とスピードを高めるBring Outでこの仕事をする面白さ納品で終わらず、成果まで見届けられる受託開発では、納品した時点で顧客との関係が終わることも少なくありません。Bring Outで実装するのは、顧客が日々使うBring Outとつながり、その上で動き続けるソリューションです。プロジェクトが完了したあとも、自分が実装したものが顧客の業務でどんな成果を生んでいるかを見届けられます。日々の運用はTechnical Supportチームが担いますが、顧客の活用が次のフェーズに進むときには、さらなる拡張の開発で再び関わることもあります。自分の実装が、プロダクトの機能になる個別に開発した機能のうち、多くの顧客に価値があるものはSaaS本体に還元します。1社のために書いたコードが、自社プロダクトの機能として多くの顧客に届く。SIの手応えとプロダクト開発の手応えを、同時に得られる仕事です。APIの開発では、顧客のユースケースをもとにSaaSの開発チームと議論し、仕様づくりから実装まで担う機会もあります。AIエージェント時代のインテグレーションに、いち早く向き合えるBring OutはAIを中核に据えたプロダクトです。AIエージェントが業務で当たり前に使われるようになれば、システム同士の連携は、APIをつなぐことから、エージェント同士が協調して動く形へと広がっていくはずです。顧客のシステムとBring Outをつなぐこの仕事は、そうした新しいインテグレーションを、実案件の中でいち早く手を動かして経験できる立場にあります。大切にしたい指標目指すのは、実装を速く終わらせることだけではありません。顧客の要望に正しく応え、プロダクトの品質を損なわずに届けることを重視します。納期と品質：計画どおりにリリースできているか。リリース後に重大な不具合が出ていないかプロダクトへの影響：カスタマイズによって、プロダクト本体の不具合やデグレードを起こしていないか再利用性：実装した仕組みが、次の案件でも使える形になっているか具体的な目標は、入社後に現状を確認したうえで一緒に設定します。向き合う技術| 領域 | 技術 | | バックエンド | Node.js / TypeScript / Python / GraphQL | | データストア | PostgreSQL / AWS S3 / DynamoDB | | インフラ | AWS / Terraform / Docker / GitHub Actions | | AI処理 | LLM API、文字起こし |すべての技術に最初から精通している必要はありません。プロダクトのコードベースを読み解き、顧客の要件に合わせて確かに動くものをつくれることを重視します。

1社のための正解を、技術と体制で形にする。顧客ごとに違う業務フロー、システム環境、データ。その中から本当に解くべき課題を見極め、実現できる設計に落とし込む。社内のエンジニアと外部パートナーを組み合わせて、約束した品質と納期で届けきる。Bring OutのSolution Architectは、エンタープライズ企業ごとの個別ソリューションを、プリセールスから構築、Technical Supportチームへの引き継ぎまで技術面で率いる、Solutionチームの技術責任者です。自分ですべてを実装する役割ではありません。どの要望に、どんな設計で、誰と応えるのか。それを決め、案件を最後まで導き、技術でSI事業の成長速度そのものをつくっていく仕事です。なぜ今、このポジションなのかBring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。事業は、SaaSと、顧客ごとの個別要件に応えるコンサル/SIの二層で伸ばしています。大手企業になるほど、標準機能だけでは拾いきれない固有の業務フローやシステム連携、データ形式への対応が求められ、こうしたSI案件の相談は増え続けています。一方で、社内の開発キャパシティには限りがあり、受注の機会が採用のスピードに縛られる状態になっていました。そこでBring Outは、SI案件に外部の開発パートナーを活用する方針を決めました。Solutionチームに、要件定義から技術統括、外部パートナーの開拓・管理までを担うSolution Architect 1名を迎えます。役割の境界も明確にしています。導入（個別の構築）はSolutionチーム、導入後の運用（問い合わせ対応）はTechnical Supportチームが担います。Solution Architectは、構築を終えた案件を、運用できる状態でTechnical Supportチームへ引き継ぐところまでに責任を持ちます。お任せしたいことまずは、プリセールスから構築、引き継ぎまでの一連の案件を確実に届けきること、そして外部パートナーと協働できる体制をつくることに集中していただきます。そのうえで、案件で得た知見をプロダクトとチームに還元する領域へ広げていきます。プリセールスと技術提案商談や要件ヒアリングに技術側の当事者として参加し、顧客が実現したいことと解くべき課題を見極める実現可能性と現実的な実装コストを見極め、技術提案・見積もり・PoCを設計する実現が難しい要望には、制約と理由を示したうえで代替案を提示する要件定義とアーキテクチャ設計顧客の言葉で語られる要望を、実装可能な要件と仕様に落とし込む顧客の既存システムやデータ環境を踏まえ、クラウド・データベース・API・フロントエンドを含む全体の設計を担う標準機能で応える部分と個別に構築する部分の境界を決め、SaaSプロダクトとの整合を取るプロジェクト管理スコープ、スケジュール、体制、リスクを管理し、案件の進行に責任を持つ顧客、Solution Engineer、外部パートナー、SaaSの開発チームなど、関係者をまとめて意思決定を進める設計・実装のレビューを通じて、個別の構築であってもBring Out全体の品質水準を保つ外部パートナーの開拓と管理委託先となる外部開発パートナーやフリーランスを開拓・選定する要件と設計意図を明文化し、パートナーが迷わず実装できる状態で引き渡す委託した実装のレビュー、品質担保、進行管理を担うSolution Engineerと外部パートナーを組み合わせ、案件ごとに最適な体制を設計する構築の完了とTechnical Supportへの引き継ぎリリースまでの検証を主導し、顧客と完了を合意する構成、仕様、既知の制約を整理し、Technical Supportチームが運用を担える状態で引き継ぐその先に広げていく領域案件と体制が回り始めたら、次のテーマにも取り組んでいただきます。個別対応の再利用と標準化：繰り返し求められる要件を見つけ、再利用できる実装や構築の型にするプロダクトへの還元：顧客ごとの要望から見えた共通のニーズを、SaaSの開発チームと連携してプロダクトの改善につなげるパートナーネットワークの拡大：信頼できる外部パートナーとの関係を広げ、より多くの案件に応えられる体制をつくるBring Outでこの仕事をする面白さ納品で終わらず、成果まで見届けられる受託開発では、納品した時点で顧客との関係が終わることも少なくありません。Bring Outで構築するのは、顧客が日々使うBring Outとつながり、その上で動き続けるソリューションです。プロジェクトが完了したあとも、自分が設計したものが顧客の業務でどんな成果を生んでいるかを見届けられます。日々の運用はTechnical Supportチームが担いますが、顧客の活用が次のフェーズに進むときには、さらなる拡張の構想から再び関わることもあります。1社のための開発が、プロダクトの成長につながる個別に開発した機能のうち、多くの顧客に価値があるものはSaaS本体に還元します。1社の課題から生まれた機能が、自社プロダクトの一部として多くの顧客に届く。SIの手応えとプロダクト開発の手応えを、同時に得られる仕事です。APIの開発では、顧客のユースケースをもとにSaaSの開発チームと議論し、仕様づくりから関わる機会もあります。顧客の現場を最もよく知る立場から、プロダクトの方向性に影響を与えられます。AIエージェント時代のインテグレーションに、いち早く向き合えるBring OutはAIを中核に据えたプロダクトです。AIエージェントが業務で当たり前に使われるようになれば、システム同士の連携は、APIをつなぐことから、エージェント同士が協調して動く形へと広がっていくはずです。顧客のシステムとBring Outをつなぐこの仕事は、そうした新しいインテグレーションの設計に、実案件の中でいち早く向き合える立場にあります。大切にしたい指標目指すのは、案件を数多くこなすことだけではありません。約束したものを、約束した品質で届け、顧客が次も任せたいと思えることを重視します。納期と品質：計画どおりにリリースできているか。リリース後に重大な不具合が出ていないか見積もりの精度：計画と実績の乖離が小さく、事業として成り立つ案件になっているか引き継ぎの質：Technical Supportチームが、追加の説明なしに運用を担える状態で引き継げているか対応できる案件の量：外部パートナーとの協働によって、社内のキャパシティを超えて案件に応えられているか顧客からの信頼：追加の相談や次の案件につながっているか具体的な目標は、入社後に現状を確認したうえで一緒に設定します。向き合う技術| 領域 | 技術 | |---|---| | バックエンド | Node.js / TypeScript / Python / GraphQL | | データストア | PostgreSQL / AWS S3 / DynamoDB | | インフラ | AWS / Terraform / Docker / GitHub Actions | | AI処理 | LLM API、文字起こし |実装を主業務とするポジションではありません。求めるのは、これらの技術を前提に実現方式を判断し、設計と実装をレビューして、品質に責任を持てる力です。

技術で顧客の「困った」を解き、プロダクトの次をつくる。ログに残された小さな手がかりから、顧客の業務を止めている原因を見つける。複雑なシステムの挙動を読み解き、次に何をすればよいかをわかりやすく伝える。そして、一度の解決を、次の顧客が困らないための仕組みに変えていく。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 |プロダクトの機能開発を主業務とするポジションではありません。求めるのは、ログやシステムの挙動を読み解き、根拠に基づいて問題を説明し、解決につなげる力です。すべての技術に最初から精通している必要はありません。

顧客の信頼をチームで生み出す。サポートの仕組みをゼロからつくる。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機能の立ち上げ