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

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

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

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

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を活用した開発プロセスの標準化・ドキュメント整備

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

私たちは、企業に眠る非構造データ──中でも重要性の高い「対話データ」を自然言語処理技術（LLM）で解析し、企業固有の“思考データ”として生成AIに学習させることで、経営の意思決定に活かす仕組みを提供しています。企業が保有するデータの約9割を占める非構造データには、経営の判断軸や現場の知恵、顧客の声といった“数値化できない知”が眠っています。これまで扱いづらかったこれらのデータを体系的に理解し、経営に活用できる時代が到来しました。私たちはこの変化を“データ経営の新たなフロンティア”と捉え、非構造データから洞察を導き出し、トップマネジメントと共に変革シナリオを設計・実行するコンサルティング事業を展開しています。本ポジション（シニアソリューションアーキテクト）は、エンタープライズ企業向けにSaaSをカスタマイズし提供する個別ソリューション構築をリードするリーダーです。クライアント特有の要件に応じた開発を、一気通貫で設計から実装まで推進していただきます。・クライアントとの折衝における技術面での要件議論をリード・プリセールス段階での技術検討・PoC設計（営業・コンサルタントとの協働）・要件定義〜基本設計〜実装・検証〜リリースまでの技術統括・プロジェクト全体の進行管理・課題解決・リスクマネジメント・外部ベンダー／フリーランスの選定、契約、進捗・品質管理・設計・実装レビューを通じた品質担保・運用・保守体制の構築およびモニタリング設計※案件規模は数人月〜半年程度、最大5名規模のPoC／中規模開発が中心です。

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