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 |
プロダクトの機能開発を主業務とするポジションではありません。技術的な根拠に基づいて問題を整理し、メンバーの判断を支え、開発チームと解決に向けた議論ができることを重視します。すべての技術に最初から精通している必要はありません。

B2BのIT・SaaS領域で、技術的な問い合わせ対応やトラブルシューティングを担った実務経験
サポートチームのリード、またはサポート業務の設計・改善を主体的に推進した経験
ログ、エラーメッセージ、システム構成などをもとに、問題を切り分けられる技術的素養
開発チームと協働し、技術課題のエスカレーションや解決を推進した経験
顧客・開発者・サポートメンバーのそれぞれに合わせて、課題や対応方針を明確に伝える力
日本語で円滑に顧客対応・チーム運営ができること（ネイティブレベル）
肩書としてのマネージャー経験だけで判断しません。現場で対応をリードし、周囲を巻き込みながら、チームの仕事の進め方を改善してきた経験を重視します。

サポートチームの新規立ち上げ、または成長期の体制・プロセス整備の経験
オンコール体制の設計・運用、またはインシデント対応をリードした経験
サポートメンバーの育成、オンボーディング、対応品質のレビュー経験
エンタープライズ顧客の情報システム部門・事業部門への対応経験
API・データ連携のトラブルシューティング、SQLによる調査、コード読解の経験
ナレッジベースの整備や、生成AIを活用したサポート業務の改善経験
歓迎要件のすべてを満たす必要はありません。これまでの現場で何を変え、どのようにチームや顧客の成果につなげてきたかを、ぜひ聞かせてください。

個人の頑張りを、再現できる仕組みに変えたい方
自分が解決するだけでなく、次は誰が担当しても解決できる状態をつくりたい。属人化した知識や判断を、チームで使える手順とナレッジに変えていける方です。
顧客と開発の間に、協力の接点をつくれる方
顧客の困りごとも、開発の技術的な制約も理解し、事実と影響を整理して議論できる。責任を押し付け合うのではなく、解決に必要な連携をつくれる方を歓迎します。
数字と現場の両方から、改善を考えられる方
KPIの変化を見て、実際のケースを確かめる。件数やスピードだけに偏らず、品質、再発、チームの負荷まで見て判断できる方です。
未完成の環境を、仲間と育てることを楽しめる方
最初から完璧なルールをつくるより、試し、現場から学び、改善を重ねる。メンバーや開発チームの知見を引き出しながら、よりよいサポートのあり方をつくりたい方です。