納品して終わり、を事業会社でやった話

SIer出身の生成AIイネーブラーが、事業会社に来て「納品して終わり」を自分でやってしまい、そこから営業の隣に座って作るやり方に変えるまでの4ヶ月の話です。

「仕様通りに作る」から「価値を生むために作る」へ。SIer出身者の転職記の登壇内容です。

最初に作ったのは、商談の文字起こしからBANTを生成AIで自動判定し、Slackに流す仕組みでした。最初の10日は好評でした。しかしその後の7週間はフィードバックが0件で、通知878件にも反応は一度も付きませんでした。会社を変えても、現場から離れて作っている限り、やっていることはSIer時代と同じでした。

そこで営業チームの隣に座り、社内システム「eco-map」を一緒に作りました。

・α版を作戦会議に持ち込んで失敗した日と、現場がNotionを使い続けていた本当の理由
・「体験はNotionと伴走で作る。コードは後」という進め方
・一覧編集を作らない／HubSpotに書き戻さない／自分が作った機能を削る、という「作らないこと」の判断
・エンジニアではない人がClaude Codeでコミットできるようにするための前提条件
・営業が自分のAIアシスタントからeco-mapを使える入り口（MCP）を作り、AI経由の週間利用者が3人から20人に増えたこと

「納品して終わり」はSIerの問題ではなく、距離の問題でした。
FDE（Forward Deployed Engineer）に必要な力の多くは、SIerの現場ですでに鍛えられています。足りなかったのは能力ではなく、成果まで追いかけられる「距離」と「立場」でした。

#SIer出身者転職記 2026.10.14
note: 生成AIを“使ってもらう”のをやめる

Transcript

1. SIer出身者転職記 ／ Ubie 納品して終わり、を 事業会社でやった話 ── 現場の隣に座るまでの4ヶ月 盛田崇弘（tamosan）／ Ubie株式会社 生成AIイネーブラー 2026.10.14 @tamosan_01
2. 自己紹介 盛田崇弘 / tamosan Ubie株式会社 生成AIイネーブラー 製薬企業向け事業で、営業プロセスに生成AIを組み込む仕事 キャリアのスタートはSIerで金融システムの運用保守担当 ソフトウェアエンジニアではありません
3. 先に結論 「納品して終わり」は、 SIerの問題ではありませんでした。 距離の問題でした。 事業会社に来ても、ユーザーと離れて作れば同じことが起きます。実際に、私がやりました。
4. 前職SIer 私のいたSIerは、納品して終わりではありませんでした 前職 一気通貫で運用まで持つ会社だった。SIerの中では特 殊だったと思う 整地 ただ 顧客がその先の顧客に届ける価値との距離は、やはり 遠かった カオスな現場 フローが無い業務 属人化したタスク 身についたもの 増殖したExcel コードではなく、「整地」 出典: note②「私のトンガリは、コードではなく『整地』でした」 ／ note.com/tamosan_01/n/n892ba831e9ce 誰でも回る運用 → 重くない道具で 誰でも回せる形にして 運用に乗せきる
5. トライと失敗 事業会社に来て作ったもの 商談の文字起こしから、BANT（商談フレームワーク）を生成AIが自動判定して、Slackに流す 営業が 商談する 人がやる → 文字起こしが 取れる → AIワークフローが 処理 → BANTを 自動判定 ここから先は自動 営業がやることは「お客様と喋る」だけ、を目指した 出典: note① → Slackに 通知
6. トライと失敗 反応は良かった。そして、止まりました。 最初の10日 社内Slackで「BANT」に触れた投稿数（月） 「頭の中でぼんやり考えていることが、先 にクリアに言語化される」 112 フィードバックの回答 9件 ── すべて稼 106 105 100 働から10日以内 66 50 36 35 26 9 8月 9月 その後 次の7週間、フィードバックの回答は 0件 そして通知 878件 には、リアクションも返 0 2月 稼働開始 3月 4月 信も一度も付かなかった 作った後の打ち手を出せていなかった。 追いかける数字を決めていなかったので、「良かったね」で止めてしまった 出典: 社内Slack公開チャンネルの投稿（自動投稿を除く）2026年2月〜9月 5月 6月 7月
7. トライと失敗 これ、やっていることは SIer と同じでした SIer時代 事業会社に来てから 誰の要望か 顧客 社内の営業 どこで作るか 自席 自席 渡し方 納品 Slackに通知 その後 運用に入る 「良かったね」で終わる 会社を変えても、現場から離れて作っている限り、構造は変わりませんでした
8. さらにトライ だから次は、営業チームの隣に座りました eco-map ── 製薬業界の「誰が誰に影響を与えるか」を これまで 可視化して、案件と次のアクションを回す社内システム 仕様をヒアリングして自席に帰る、をやめた。 営業の現場 距離 自席で作る 商談に一緒に出て、その場で画面を直す この働き方に近いイメージです FDE（Forward Deployed Engineer） 顧客の現場に入り込み、課題を見つけ、その場で作って運 用に乗せるエンジニア 出典: note② ／ note.com/tamosan_01/n/n892ba831e9ce eco-map 営業の現場 隣で作る
9. さらにトライ 生成AIがあれば1営業日で作れます。だから、一度止まりました。 私が作ったのは「入力フォームと一覧画面」。 営業が持っていたのは「顧客との関係性」でした 自分でスキーマを描いてみて、「面識あり」をどこに 置けばいいか分からなくなった 医師 A 自分 面識あり 人物カードにもタグ欄にも収まらない。 それは人の属性でもタグでもなく、「その人と自分の 2人のあいだの線の上にしか置けない 関係」だったから 本人に聞かずにスキーマを切ると、いちばん価値のある暗黙知だけがきれいに抜け落ちたシステムが できあがる
10. さらにトライ 2026年6月25日、営業チーム全員が集まる1日 がかりの作戦会議に、 版を持ち込みました α 11:26 会社検索に失敗しました 11:29 ブラウザ読み込みしたらエラー真っ白 13:47 間に合ったー！！！！ 14:00 オフサイト開始 20名超 が同時ログイン 8アカウント超 のマップをその場で編集 8本 のPRをその日のうちにマージ それでも、この日は失敗でした。 その日の本題は、顧客の意思決定構造をチームで書いて揃えること。 全員が「この画面どう動かすのですか」でつまずいて終わった
11. さらにトライ 現場がNotionを使い続けていた理由が、この日はじめて分かりました 思っていたこと 実際 Notionは構造化されていないから、ちゃんとした 彼らは正規化を諦めてNotionにしたのではない。 DBにすべきだ 入力と閲覧の体験でNotionを選んでいた データの正規化も大事ながら入力・閲覧の体験がよくないとNG。その体験が CRMよりも NotionDB が優れていたからこそ Notion を使っていることが理解できた ── 当日から5日後の自分のメモ 自分の作ったものを持ち込んで、それが本題の邪魔をするところまで見ないと分からなかった
12. さらにさらにトライ 体験は Notion と伴走で作る。コードは後。 1 まず eco-map を触ってもらう。どこでつまずくかを、自分の 目で見る ここを飛ばしたくなる 2 3 体験そのものは Notion で掘る。私が営業に伴走しながら 手で埋める 生成AIがあると、実装が速す ぎて 2と3を飛ばしたくなる。 でも体験が固まっていないも のを実装しても、作り直しに なるだけでした 「良い体験」が人力で成立するところまで持っていく 伴走しているあいだ、私は仕様書を書いてい 4 固まったものを eco-map に実装する ません。営業と一緒にNotionを埋めているう ちに、仕様が勝手に決まっていきました 出典: note②「体験は Notion と伴走で作った。コードは後だった」 ／ note.com/tamosan_01/n/n892ba831e9ce
13. さらにさらにトライ この4ヶ月で決めたのは、作ることより「作らないこと」でした × × × 一覧編集（営業向けCRUD）を 作らない 自動でやりすぎない 自分が実装した機能を削る HubSpotのコンタクト情報を最初から タスク種別ラベルを実装したら、営業 「入力させる道具」は営業にとって eco-mapに全て同期させて取引情報に レビューで「期日があれば優先度はい “報告の作業”になる。作りたかった 紐付けても、情報が過多になって何を らない。分類もなくていい」。社内を のは報告先ではなく、開いた瞬間に したいのかがわからなくなる。最初は 横断して調べたら、欲しがっていたの 「次に誰に会うか」「何を話すか」が 手動でも大事な人とお会いした記録を は私一人だった 分かる画面 つけていく業務プロセスから 「あえて削る」は、その画面を毎日見ている人の隣に座らないと出てこない発想でした
14. さらにさらにトライ 7月1日に本番に出した日、pi-chan の最初のコミットが入りました pi-chan は生成AIイネーブラーで、エンジニアではありませ ん。Claude Codeを渡して、リポジトリを触れるようにしただ け リポジトリのコード（著者別） 55% 45% 非エンジニア2人 エンジニア 4.4倍 494件 本番に出した月の 非エンジニア2人の コミット総量 4ヶ月合計（43.9%） それでも、このリポジトリのコードの55%はエ ンジニアが書いています ここを飛ばして「AIがあれば誰でも作れる」と言うのは嘘 だと思っています 私は3人のなかで、いちばん書いていません 成立条件 1 「開発のやり方」を全部文章にした （Markdown 232ファイル・4万3千行） 2 稼働日あたり6回リリースできる状態に した 3 私やエンジニアがレビューしつつ、機能 を確認した
15. さらにさらにトライ ★時間調整で省略可 いちばん効いたAIの使い方は、コード生成ではありませんでした 38件 「複数の担当者を付けたい」は、6月に一度出て「まだ早い」で保留になっていた SlackとNotionの議事録を 「案件→親タスク→子タスクの階層にしたい」は、8月に別々の二人が独立に、別のチャ 全部横断。「誰が、いつ、 ンネルで言っていた。一方にはスタンプだけが付いて、文章の返信はゼロ 何を求めたか」を出典URL 付きで収集 コードを見たら、JOINの書き方のせいで、ある種類のタスクは一度も通知されていなかっ た AIに横断して読ませると、声の大きさではなく、要望の分布が見える
16. さらにさらにトライ 隣に座り続けたら、「もっと便利に」がAIから使える入り口になりました 「もっと楽に入力したい」「会議の前にま 画面で使う → もっと楽にしたい → AIから使う とめて確認したい」に応えて、営業が自分 のAIアシスタントから eco-map を読み書 きできる入り口（MCP）を作った AI経由の週間利用者（人） 20 13 3 4 営業がSlackでAIに頼む eco-map に議事録が紐づく 使い方は営業が自分で見つけていく 9/14週 9/21週 9/28週 10/5週 呼び出し 165 → 308 → 687 → 約2,600 回 ・商談のSlackスレッドを渡すだけで、新規案件を登録 ・毎朝、その日の予定から「更新すべき項目」を洗い出し、確認してから更新 ・会議の前に、入力漏れのある案件を担当者別に一覧にする 「今までの人生で使ったシステムで、圧倒的No.1」 ── 営業の声 出典: eco-map 利用ログ（2026年9月14日の週〜10月5日の週。最終週は週途中の集計）
17. 結論 FDEに要る力の多くは、SIerの現場で鍛えられていました FDEに要るもの SIerで鍛えたもの 事業会社で足したもの 現場に入り込み、言葉になっていない要件 を掘る 客先での要件定義・調整 ─ その場で作って直す （以前は重かった） 生成AIで、実装の下限が下がった 運用に乗せきる 保守・運用・「整地」 ─ 使われたかどうかに責任を持つ 契約の外にあった ここだけは、事業会社で手に入れた 足りなかったのは能力ではなく、成果まで追いかけられる「距離」と「立場」でした
18. 結論 いま足りないのは、仕様を聞いて作れる人ではありません 生成AIで実装の下限は下がりました。作れる人は増えて います いま足りない人 現場に座って「その矢印はどういう意味ですか」 希少になったのは、「どの課題を解くべきか」を見極め と聞ける人 る力と、「運用に乗せきる」執念 自分が作った機能を削る判断ができる人 整地 ← 時代が、こちら側に寄ってきた 「使われていない」という事実から目を逸らさな い人 それは今、FDEと呼ばれ始めている役割です 出典: note②「私のトンガリは、コードではなく『整地』でした」 ／ note.com/tamosan_01/n/n892ba831e9ce
19. まとめ 最初にやるべきは、人と話すことでした 課題を持っている人と、解く力を持っている人がタッグを組んだ時に、 いちばん速く、いちばん遠くまで行けます 私が本当にやりたいのは、「作る仕組みを作る」こと 「これできたー！」って言い合える人と作りたい 盛田崇弘（tamosan）／ Ubie株式会社 生成AIイネーブラー @tamosan_01 ／ #SIer出身者転職記 note: 生成AIを“使ってもらう”のをやめる