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、文字起こし |

実装を主業務とするポジションではありません。求めるのは、これらの技術を前提に実現方式を判断し、設計と実装をレビューして、品質に責任を持てる力です。

• SI・受託開発・SaaSの導入などで、要件定義からリリースまでの技術面を主導した経験（目安5年以上）
• Webアプリケーションやクラウド（AWS/GCPなど）を前提としたシステムのアーキテクチャ設計・レビューの経験
• 外部の開発パートナー（ベンダー・業務委託）の開拓・選定と、委託した開発の品質・進行管理の経験
• 顧客の課題を技術的に解釈し、実現方式や代替案を提案した経験
• スコープ・スケジュール・リスクを管理し、プロジェクトを完了まで導いた経験
• 日本語で円滑に顧客折衝ができること（ネイティブレベル）

自分で書いたコードの量より、どんな要件に、どんな設計と体制で応え、最後まで届けきってきたかを重視します。

• Node.js / TypeScript / Pythonなどを用いた、ハンズオンでの開発経験
• AWS / Terraform / Dockerを用いたインフラ構築の経験
• SaaS製品のカスタマイズ開発、またはマルチテナント構成の設計経験
• 顧客の既存システムとのAPI連携・データ連携の設計経験
• LLM・自然言語処理・音声認識などAI関連技術のPoCや導入の経験
• エンタープライズ企業の情報システム部門・事業部門との折衝経験
• スタートアップや急成長期のSaaSでの勤務経験

歓迎要件のすべてを満たす必要はありません。これまでにどんな案件を、どんな体制で届けてきたかを、ぜひ聞かせてください。

こんな方と働きたい

標準化されていない問題を、面白がれる方

顧客ごとに違う業務フローやシステム環境を、面倒ではなく設計の腕の見せどころと捉えられる。顧客の業務を理解しようとする姿勢を、技術の判断に活かせる方です。

要望をそのまま受けず、現実的な答えを出せる方

実現が難しい要望を鵜呑みにせず、技術的な制約と実装コストを見極めたうえで、顧客が納得できる代替案を示せる。「できます」ではなく「こうすれば実現できます」と言える方を歓迎します。

抱え込まず、体制で解ける方

実装を一人で抱え込むのではなく、社内のエンジニアと外部パートナーを組み合わせて体制をつくれる。仕事を渡すときも丸投げにせず、レビューと品質の責任を自分で持ち続けられる方です。

相手に合わせて、技術を語れる方

経営層から現場の担当者、社内のエンジニア、外部パートナーまで、相手に応じて説明の抽象度を変えられる。信頼関係を築きながら、関係者の意思決定を前に進められる方です。