東京大学AI研究室発のスタートアップ、AlgoageとSureSide事業化の背景

宮田：Algoageは2018年に設立した、東京大学のAI研究室発のスタートアップです。2020年にDMMグループ入りし、現在は従業員数150名（パート・業務委託含む）で、AIに強みを持った事業創造会社として複数の事業を展開しています。

事業は大きく3つあります。1つ目は「DMMチャットブーストCV」というCVを最大化するチャットマーケティングのSaaS事業。2つ目は「DMMビジネスAI」という企業のAI活用を加速させるコンサルティング・研修事業。3つ目が、今日お話しする事業で、DMMグループや関連会社の業務をAIプロダクトで効率化する取り組みです。




この3つ目の取り組みから生まれたのが、5月にローンチした「SureSide」というカスタマーサポート・コールセンターの業務支援サービスです。「ひとつのAIで、支援から自動化まで。現場で育つAI Co-worker」をコンセプトとしたプロダクトで、DMMのコールセンター（CS）での2年間にわたる本番運用の中で成果を出し続けてきた実績がベースになっています。




※画像は登壇時（6月17日時点）のもの

DMMは60以上の事業を展開しており、そのCSは、石川（金沢市）と北海道（札幌）の2拠点体制で、24時間365日不休で電話・メール2チャンネルに対応しています。月約25,000件の問い合わせを処理し、35サービス以上のマルチサポートを担う規模の中で、AIでどこまで業務を効率化できるかをとことん追い求めた2年間でした。

DMMのCS現場で証明したAIの実力

成果として、問い合わせ全体で見ると1件あたりの平均対応時間を約3割削減できました。もうひとつの成果が、オペレーターのスキルアップの加速です。ベテランオペレーターの対応時間を1.0とした場合、導入初期には非ベテランのオペレーターが1.7倍の時間を要していましたが、導入後期には1.1倍にまで縮まっています。新人がベテランの速度に早く追いつけるようになったことも、大きな成果のひとつです。




こうした実績をもとに、SureSideシリーズのプロダクトを一気に立ち上げ、開発組織を急拡大していくことになりました。SureSideが提供するプロダクトはSureSideボイスアシスト、SureSideチャットインテリジェンス、SureSideボイスインテリジェンスなど、カスタマーサポートの各フェーズをAIでカバーする体系的なラインナップです。中心にあるのはSureSideナレッジハブで、FAQ・業務マニュアル・応対フローをAI VOC分析と組み合わせながら各チャンネルに展開していく設計になっています。

開発組織55名、2ヶ月で20人増員した実態

現在、この事業の開発組織は55名ほどです。4つのプロダクトチームそれぞれにメンバーが配属されており、横断的な基盤/Enablementチームとして SRE・QA・デザイン・R&Dが存在します。さらに個社への導入プロジェクトを担うチームがあり、各社にFDEが配属される形をとっています。

20人増員と聞くと一気に増えたように感じるかもしれませんが、実際には新しいチームが２つ組成され、既存チームにちょこちょこと追加される形でした。プロダクトチームに+2名、+3名、+3名、SREに+2名、QAに+4名、R&Dに+4名、個社プロジェクトにも+1名ずつという形です。全体としては大きな変化ですが、各チームの単位で見れば段階的な増加です。それでもやはり、開発速度・文化・コミュニケーションには大きな変化が生じました。




チームの運営形式もさまざまです。1人だけの小さい最強チームとして、プロダクトの要件・ビジョン・アーキテクチャから開発まで1人で担う形。スクラムで自己組織化を目指す形。計画をしっかりと立ててウォーターフォール的に進める形。それぞれ異なる課題と強みを持ちながら、各チーム単位での最適化を図り、知見を共有し合っています。AIソロプレナーに近い1人最強チームは初速が非常に速い一方、2〜3ヶ月を超えたあたりで個社への対応やバグ修正に人手が足りなくなり、増員した際の問題が複数人チームより大きく出るという特性もあります。

「作れる」は当たり前に。勝負は「届けて定着させる」

AIプロダクトを事業として成長させていく上で、最近「ラストワンマイルが大事だ」と広く言われるようになっています。その背景にあるのは、価値の源泉のシフトです。

AIプロダクトは「作れる」が当たり前になりました。顧客はAIプロダクトを見て「全部よしなにAIでやってくれるんだ」と直感的に期待します。しかし実際には、顧客の業務に深く入り込み、最適化し、定着して使い続けてもらうことが非常に難しい。「顧客に届けて定着させる」ことが事業の勝負どころであり、ここにエンジニアの知見をフルで使って解いていくことが最大のレバーになっています。




この役割を担うのがFDEです。FDEは各プロダクトチームとは別に、個社への導入プロジェクトを担うチームとして組織の中に位置づけられています。顧客の業務環境に深く入り込み、AIプロダクトをどう定着させるかを実現するエンジニアリングの専門家です。
AlgoageではFDEという言葉が存在する前からこのような形での課題解決を繰り返してきました。なので、FDEという職種を作って採用を始めたというよりは、これまでやってきたFDE的業務を以下にスケールさせられるかというポイントに注力しています。

FDEの業務フローとラストワンマイルの壁

FDEの業務の出発点は「事業の成長をKGIとして最適化する」というベースラインにあります。それぞれの顧客に対して機能を最適化して届けることが目標ですが、そのステップは5段階あります。

まず「現場に入る」こと。見学やロープレを通して、決裁者と同じKPIの目線で語れるようになることが第一歩です。次に「課題特定」と「ソリューション提案」。ここで重要なのは、できることだけでなく「できないこと」も率直に伝えることです。顧客がAIに過剰な期待を持っているとき、今のAIの技術でPoC死しないための現実的なソリューションを示す。そして「作って届ける」、最終的に「事業に還元してプラットフォーム化する」という流れになります。




そして何よりも現場への敬意を忘れずにいることが大切です。急にAIの人が来て「またPoCか」という絶望感を顧客に感じさせてしまったら、本質的な価値は提供できません。「また置き換えに来ましたよ」ではなく「皆さんの痛みを取り除きに来ました」という思いで現場に入ることが大切です。

ラストワンマイルの難しさは3つあります。

1つ目は、技術的に動いていても現場では使えないケース。ヒアリングした1名が理解していた業務フローと、数十人が暗黙知として行っていた業務フローが違っていた、ということが実際に起こります。2つ目は「データを揃えればAIは動く」という幻想。数百枚のExcelの暗黙知、セルの色が例外フローを表していたり、複雑なコメントや読み取りが難しいOCRの限界。そうしたデータを整備することは非常に難しいです。3つ目は、期待値コントロールの壁です。個社対応の要望と汎用プロダクトとしての制約との間でジレンマが生じ、「AIでなんでもできる」という期待とSaaSで実際にできることのギャップを誠実に伝え続けることが求められます。



現場に深く入らないと、本当に解くべき課題は見えません。これがFDEという仕事の本質的な難しさです。

スーパーマンFDE依存からの脱却。構造化して組織で解く

こうした難しい業務をすべて1人でこなせるFDEを採用できれば理想ですが、現実はそう簡単ではありません。書類選考の通過率は2.3%で、他の求人が約20%であることを考えると際立って低い数字です。そういう人材はそもそも少なく、この時代に自分で会社を立ち上げて1人でやっているケースも多い。文化マッチ・スキルマッチの完璧さを求めるとさらに希少性が高まり、入社できたとしてもキーマンリスクが高すぎる問題に直面しました。



4プロダクトを並行開発する環境で少数精鋭に依存するのはリスクが大きすぎる。だから、構造化して組織で解くことにしました。ここからは失敗から学んだ構造設計の話です。

まず「構造化の仕方①」として、個社対応をどのレイヤーに入れ込むかを整理します。
私たちのAIプロダクトをシンプルに3つの層の構成で整理しました。各社のSaaS・業務の癖にアンビエントに浸透する「エージェント層」、業務をどう定型化してどこまでAIで解くかを担う「ワークフロー層」、顧客のナレッジデータを構造化する「コンテキスト層」です。顧客からの要望がどのレイヤーのドメインロジックに当てはまるかを整理することで、個社知見を汎用に還元する道筋が見えてきます。役割・意思決定の主権をレイヤーごとに分けることで、1人のFDEが全対応を抱え込む状況を防ぎます。



「構造化の仕方②」は、AREとFDEで分業することです。
ARE（Applied Research Engineer）はデータエンジニアリングとAIに深い知見を持ち、主にコンテキスト層を担います。FDEはソフトウェア開発とプロダクト化への深い知見を持ち、主にエージェント層を担います。ワークフロー層はFDEとAREが協力して対応します。データ・ソフトウェア・AIの知見を分けて考え、適切な役割分担をすることで、1人のFDEが顧客への個別対応を全部抱え込むのではなくスケールできるようになります。

ただ、分業をすると、文化のすれ違いが発生します。探索的に課題を解決したい人、構造化して中距離を走りきれるようになりたい人。
そこで、Algoageで大事にしている事が、デュアルトラックアジャイルの思想を取り込むことです。
探索（Discovery）フェーズとデリバリー（Delivery）フェーズでは、進め方の正解がまったく異なります。「スピードが命」の探索と「品質と整合性を重視する」デリバリーを同じやり方で進めることには無理があります。今の機能がどちらのフェーズにあるかをチーム全体でロードマップ上に明示し、全体の目標として合わせることで、「探索派」と「デリバリー派」の対立が解消されてきました。

人が増えると遅くなる「人月の神話」と整合性の壁

ラストワンマイルの壁と並んで、もうひとつクリティカルな課題があります。それが「整合性の壁」です。これはAI以前から言われてきた組織論の問題ですが、AIで開発速度が上がっている分、露呈しやすくなっています。

人が増えると開発組織は逆に遅くなることがあります。コミュニケーションパスはn(n-1)/2≒n²で増えていくため、3人なら3本だったパスが7人になると21本になります。理想では人が増えれば開発量もスピードも増えるように見えますが、現実には頭打ちになり、やがて鈍化します。そのギャップが「整合・伝達のコスト」です。こうした要因がAI以前から指摘されてきたわけですが、AIで開発速度そのものが速くなった今、その問題がより鋭く露呈するようになりました。




複数プロダクトが成長していく中で、アーキテクチャ整合とプロダクトビジョン整合の2つが崩れやすくなっています。アーキテクチャ整合の問題から見ると、全体のアーキテクチャ、リポジトリ設計、データ・API設計、非機能要件のルールが定まっていないため、各チームがバラバラな判断で開発を進めてしまいます。プロダクトビジョン整合では、SDD（Spec Driven Development）で開発が高速化する一方、PMの合意なしに開発された機能や、ユーザー価値に直結しない機能、似た機能の量産といった問題が起きます。スピードが上がった分、ビジョンとのズレも一気に広がるというのが、AI時代特有の難しさです。



対策として取り組んでいるのが「AIが読んでくれるガイドラインを作り、AIで担保する」アプローチです。まず、不完全でもいいのでアーキテクチャやプロダクトビジョン等のガイドラインを作り、リポジトリで管理します。次に業務フローの中でAIにそのガイドラインを読ませ、違反・解離を検知させます。具体的には、GitHubのspec planのlintや、CodeRabbitによるコードレビューのタイミングで検出します。

どの違反を許容するか・しないかを人間が判断し、ADR（Architecture Decision Record）としてNotionに記録していく。この繰り返しでガイドラインが育ち、自分たちがやりたいプロダクトのポリシーになっていきます。

AIを意思決定ハブとして、コミュニケーションパスを削減する

増員時のもうひとつの課題が、新しく入ったメンバーのキャッチアップコストです。コンテキストを理解するまでに時間がかかる問題に対して、育てたガイドラインが有効に機能します。

取り組んでいるのは3つのステップです。まずガイドライン原本を元に、一旦AIに聞いてもらいます。NotionのAIに問いかけることで、擬似的に意思決定者と会話しながら機能を考えてもらう体験が生まれます。次にspec-kitのclarifyコマンドを打ってもらい、仕様を明確にするプロセスでガイドラインを読みながらAIと問いを立ててもらいます。SDDで速度が出る今こそ、ADR・ガイドラインの重要性が高まります。




原本とAIが対話して自分で立ち上がることでコミュニケーションパスを減らす。これが理想の形です。まだスタートしたばかりの取り組みですが、この新たな仕組みがうまく機能することを期待しています。

複数のプロダクトが立ち上がる中で、事業も組織もたくさんの課題を抱えながら前に進んでいるAlgoage。AIソロプレナーの時代にキラキラした成功事例ではなく、現場の事実と向き合い続ける姿が語られたセッションでした。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
エンジニアの役割の変化に向き合うConference

※動画の視聴にはFindyへのログインが必要です。