目指すは「打席に立ちまくる」企業。20億円調達生成AIスタートアップが考える事業の勝ち筋

生成AIは、ビジネスやプロダクト開発のあり方を根本から変える可能性を秘めています。この技術の登場により、テキストや画像、動画といったデジタルコンテンツをスピーディーかつ大量に作成することが可能になりました。また、生成AIに対してアプリケーションの仕様やユースケースを伝えることで、その処理を実現するソースコードも生成可能です。

この技術を活用して新規事業を生み出そうと、多くの企業が研究・開発に取り組んでいます。そうした企業のなかでもとりわけ注目を集めているのが、合同会社DMM.comからの20億円の投資を原資として立ち上がった株式会社Algomaticです。

「生成AI時代を代表する企業になる」ことを表掲する同社は、領域を問わず生成AIネイティブなプロダクトを次々と生み出すことを目指しています。今回はAlgomatic 取締役 横断CTO の南里勇気さんにインタビューしました。

スタートアップスタジオ型の組織で、複数事業を同時推進

――南里さんはもともと、受託開発を主な事業とするBison Holdingsを経営されていました。そして、2023年6月にBison HoldingsはAlgomaticの完全子会社となり、それを契機に南里さんはAlgomaticの取締役 横断CTOとなられましたが、この経緯からまずお話しください。

経営観点から見て、今後は受託開発の競争がかなり激化するだろうと感じたのが、行動を起こす起点になりました。2023年3月に、私はX（旧・Twitter）で生成AIにコードを書かせたことについての投稿をしたんですよ。

GPT4、与えたインプットに対するアウトプット凄いな。時間が相当浮く。 pic.twitter.com/IX4by6pjcZ

— Yuki Nanri/南里勇気 | Algomatic CTO (@neonankiti) March 18, 2023

私が同じ品質のコードを書くなら30〜60分ほどかかると思うんですが、これを生成AIは1分足らずで出力してきました。これほどのレベルで開発の生産性が変わったことは、これまでの人生で初めてでした。

コードの品質は人間が書くのとそれほど変わらないのに、開発スピードが劇的に速くなる。将来的に、これまで受託のプロジェクトでクライアントに「このシステムなら開発に半年かかります」と説明していたのが、ソフトウェアの品質を維持しつつ1カ月でできてしまうような世界になり得ます。

そうなると、受託開発のビジネスは品質で差をつけにくくなり、価格競争が激化することが予測できました。そこで、生成AIを使って自分たちでプロダクト開発ができる状態にしておきたいと構想していました。

そんな折に、（Algomatic CEOの）大野がSNSで「生成AIの会社をやります」とたくさん発信していたんですよ。良いタイミングだな、と思いました。私は過去にFiNCで働いていましたが、大野もFiNC初期メンバーの一人で、かつて一緒に働いていたんです。

大野はインターン生としてFiNCに入ったにもかかわらず、法人事業部のテックリードを任されるくらい優秀なメンバーでした。何より、大野はいつも明るく働いていたんですよね。私はどんな職場でも「しんどいことがあっても、楽しく笑って働く」というのを大事にしていて、大野とはその価値観が一致していました。

それに、大野は数年前に別のスタートアップを創業しプロダクトを軌道に乗せて事業売却した経験もあるので、経営者としてのスキルも高いです。大野ともう一度一緒に働けたら、絶対に面白いし良い事業が作れるだろうなと思ったのが理由のひとつ。それに、大野に出資したDMM.comの亀山さんは、DMM.comをここまで大きくした辣腕の経営者です。

この2人の存在は大きかったですね。創業間もないAlgomaticに横断CTOとして参画するのは、チャレンジングですし可能性が大きいなと思って、このキャリアを選びました。

――横断CTOとはどのような役割なのでしょうか？

Algomaticは5年で1000億円、10年で1兆円企業になることを目指しており、かつスタートアップスタジオという組織形態をとっています。これは、同時多発的に複数の事業を立ち上げるという組織の仕組みで、それぞれの事業部が独立した「1つの会社」のように立ち回っています。そのため、各事業部にそれぞれのCTOを配置していて、私はそれらの開発組織を横断的に支援する役割を担っているので、横断CTOなんです。

私たちは基本的に、スタートアップの経営はハイリスク・ハイリターンのゲームだと思っているんですよ。つまり、10回挑戦して1回成功するかどうかという戦いに、自分たちは身を置いている。そして、事業を成功させるためにありとあらゆることをやりますが、全力で努力したうえで成功するかどうかは、最終的には運の要素が大きいと思っています。つまり確率論の世界なので、事業を生み出す打席数さえ確保できれば、基本的には理論上は成功します。

多くの企業がそれをできない理由として、まず資金の問題が挙げられます。途中でショートしてしまうんですね。あとは人の問題です。そもそも人を採用できないとか、ホームランを打てる人が社内にいないとか。ですが私たちは初期投資として20億円という大きなお金がありますし、かなりエネルギーを注いで優秀な人を採用してきました。金と人を揃えたうえでスタートアップスタジオ型で事業を展開し、勝つまでやり切ることを目指しています。

成功する事業はひと握り。最初から共通化を考えても意味がない

――Webメディア「what we use」のインタビューでは「これまで取り組んできた技術的意思決定」をテーマにしているのですが、スタートアップスタジオ体制であるならば、南里さん自身はその決定をしていないということですかね。

そうですね。あえて言うならば、私自身が決めているのは「自分が技術的な意思決定に携わらないこと」です。事業部ごとに置かれているコンテキストや事業ドメインが全く違うので、それぞれに任せています。基本的には、事業ドメインに合わせた技術選定をするべきです。

――各事業部でインフラを統一するほうが、ボリュームディスカウントが効くという側面もあると思います。たとえば、クラウドはAWSだけを使うとか。そういった方針にはしないのでしょうか？

コストも重要な要素ではあるものの、横断チームでインフラをピン留めしてしまうのは、各事業部の推進力を落とすことにつながる可能性があります。各事業部の事業ドメインは全く異なるケースがあるからです。不確実な状況では、当たってぶつかりながら方向修正していくことが何より重要なので、変にピン留めして動きづらくなるような制約を置かないべきだと考えています。

――読者のなかには、採用する技術を決定する立場にある人たちもいると思うのですが、そういった方々にアドバイスはありますか？

いくつか見るべき点があります。まずは、その技術を提供している企業や組織、団体が向かっている方向性ですね。例を挙げると、私はキャリアのなかでわりと早い時期からFlutterを使い始めました。このとき、Flutterの提供元であるGoogleがこの技術にどれくらい注力するつもりなのか、動向を見ていたんですね。

すると、レンダリングエンジンライブラリのSkiaをGoogleが買収したんですよ。これはFlutterで採用されていたレンダリングエンジンで、この動きがあったので「Googleは少なくとも数年はFlutterに投資し続ける予定なんだな」と思えました。

あとは、エンジニアの採用コスト。「Flutterをやりたい」というエンジニアは多かったので、採用活動にもプラスに働きました。それから、他の技術からのスイッチングコストが低いこと。Androidアプリを開発している人がFlutterを学ぶのは簡単ですし、iOSアプリを開発している人もFlutterのDartはキャッチアップしやすい。FlutterはReactを踏襲している部分も多く、フロントエンドエンジニアにもとっつきやすいので、学習コストが低いです。

他にも、ビジネスドメインに合っているかも重視します。かつてFlutterは「UIがあまり滑らかではなく、動きがカクカクしている」と言われていたんです。でも、本当に滑らかなUIが必要かどうかは、アプリの種類によって違うじゃないですか。

たとえば、単に「何かの施設の予約をするだけ」のアプリであれば、動きがカクカクしていてもあまり影響はないですよね。その逆に、リアルタイム性が問われるライブ配信などでFlutterを採択するのは、さすがにユーザー体験が悪いのでダメだろうと過去には考えていました*。ビジネスドメインによって要求されるものは違うので、「何がエンジニアリングに求められているか」を考えることが大切ということですね。

*…南里さん曰く「Flutterの性能改善が行われてきたため、現在はライブ配信などでも使用できるかもしれないと考えている」とのこと。

真の意味での課題解決をするには、技術の多様性が必要

――南里さんが考えている、Algomatic全体としての技術的なビジョンはありますか？

大規模言語モデルの領域で起きたイノベーションというのは、技術的な正確性を無視すると「人間の脳ができた」ことに近いですよね。これは、ソフト面の飛躍的な進化が起きたという状況です。それによって、今後はハード面の適合に期待が寄せられてきています。こうした潮流のなかで、いわゆるユビキタスコンピューティング*が徐々に実現できる世界になってきたのではないかと、個人的には期待しています。

*…ユビキタスコンピューティングとは、社会や生活の至る所にコンピューターが存在しており、 ユーザーはコンピューターの使用を意識することなく、いつでもどこでも情報にアクセスできる環境のこと。

これまでIoT分野では「クラウドインフラの普及」「部品の低価格化」が起きてきましたが、それだけではユビキタスコンピューティングの実現は難しい状態でした。何かで読んだのですが、ユビキタスコンピューティングは「特定環境のなかにあるデバイスが、他のデバイスを認知し、コラボレートできること」が分散システムとの大きな違いだったと認識しています。

揺らぎのあるインプットデータを、ハードウェア側でうまく処理するためのプロセスを設計するのが、これまでは難しかったんです。しかし、LLMの登場によってその“揺らぎ”を吸収できるようになり、相互のデバイスが認知し合う状態を実現できる可能性があります。

そうなった場合に、アプリケーションのユースケースに合わせて、ハードウェア側のパフォーマンスや効率性などを変えていく必要性も出てきます。だからこそ、ソフトウェアだけではなくハードウェアへの投資も、どこかのタイミングで求められると考えています。

それに、私たちはいまアプリケーションレイヤーに特化していますが、より研究が深まると既存の大規模言語モデルだけでは実現できないことも出てくるので、自分たちで基盤モデルを作る可能性もあるはずです。

余談なんですが、以前Developers Summit 2024に登壇したときに「いまAI界隈はすべてを機械学習で解決しようとし過ぎているけれど、実際にはもっと多様なアプローチがあるはず」という旨のことを話しました。

たとえば、（テーブルにある飲み物の入ったペットボトルを手に取りながら）ふたの開け方をみんなが知っているのは、（機械学習のように）ふたを開ける動画を100万回見たからではないわけです。私たちは物理法則を理解しているので、「たぶん、こうやったら開くだろうな」という推測ができるんですよね。

この事例で何を言いたいかというと、つまり私たちは「いままで当たり前とされてきた手法」にとらわれ過ぎているんじゃないかという話があって。本当の意味で社会の課題を解決するには、いろいろな技術を複合的に扱っていかなければならないと思っています。

それを実現するために、CTO直下のプロジェクトを立ち上げています。スタートアップはマーケットの不確実性と技術の不確実性の両方に取り組むわけですが、どちらもあまりに不確実だとプロジェクトが失敗する可能性が高くなります。

そこで、このプロジェクトでは市場の不確実性には取り組まず、技術的な不確実性と徹底的に取り組むことを目的としていますね。とにかく、新しい技術を試してPoCを作りまくるという。この組織が技術的な不確実性を解消していくことで、ビジネスサイドのメンバーたちがマーケットの不確実性に取り組める状態に、なるべく早くたどり着けるようにします。

もし、その技術が使い物にならなかったとしても、世の中に出していい情報であれば、最終的に技術ブログの記事にして発信できればいいやと思っています。自分たちの事業には使えなくても、その技術が世の中の誰かの役に立って、社会の役に立てればそれでいいですからね。また、各種の技術検証やプロダクト開発などで培ったノウハウを、生成AIに特化した受託開発や壁打ち、技術顧問などを行う生成AI開発パートナー事業にも活用しています。

技術を複合的に扱うためには組織の融合も必要だと思っています。MLエンジニアとアプリケーションエンジニアが離れて働いてもしょうがないので、関係性を良好に保って一緒のプロジェクトに取り組むとか、失敗を恐れずチャレンジを尊重するような企業文化にしていきたいです。

事業成長と組織成長の好循環を生み出す

――Algomaticの開発組織における、今後のビジョンを教えてください。

Algomaticの大事な価値観として「1兆1円」という言葉をよく使っています。これは、1円たりとも無駄にしないように日々の意識を持ち、1兆円を稼ぐために視野を狭めずに限界突破していくということです。この意識を常に持っていたいのと、大変な状況であっても仕事を楽しめるような組織を作っていきたいです。

とにかく、事業で結果を出す組織にしたいですね。結局のところ、事業が人を育てると私たちは思っています。事業の規模が大きくなれば、システムの自動化・効率化を推進したり、可用性・信頼性を向上させたりといった取り組みが必要になります。こうした活動を通じて、エンジニアとしてのスキルが向上していくんですよね。

事業を爆発的に成長させていって、それに伴ってみんなが大きなチャレンジをできるようにしていく。その良い循環を生み出したいですよね。事業成長を考えず組織の理想論だけを語っても仕方がないので、まずはみんなで事業を成功させようぜという感じですかね。

――Algomaticの今後が楽しみですね。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的・組織的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

参考にできる事例が少ない状態で意思決定をするのは、すごく勇気が要ります。だからこそ、こういった事例があることはありがたいですし、可能ならばその事例を通じて当時その会社や組織が置かれていた背景や当事者たちの気持ちがわかると、より学びが大きくなると思います。

「この人たちはこういう状況に置かれていたから、この方針を選んだのか」とか「こんな優秀な人でもこのときは怖かったんだ」とわかると、すごく勉強になるし勇気づけられるじゃないですか。だから今回のこのインタビューも、誰かを勇気づけられるといいなと思っています。

人が何かを決断するときというのは、情報がすべて揃っているわけではありません。限られた情報のなかで、「自分たちはこうするべきだ」という意志と覚悟を持って方針を決めることがほとんどです。それだけに各種の事例を通じて、意思決定に携わった人の考えだけではなく“感情”も含めて、読者に伝わるといいなと思いますね。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul