「Startup CTO of the year 2023」獲得。世界トップクラスの最適化技術を有するALGO ARTISの開発思想

配船計画やプラントの生産計画、ロジスティクスの出荷計画・倉庫保管計画といった、私たちの社会基盤を支えているさまざまな産業の高度な運用計画。こうした業務はコンテキストの複雑さや求められるドメイン知識の高度さゆえに、限られた熟練の技術者に依存しています。その属人性の高さから、特定の人への業務の過集中や後継者不足などの課題が起きているのです。

また、立案した計画の効率がわずか1％変わるだけで、影響は業務プロセス全体に及びます。年間数百億円のコストがかかっている製造業の企業の場合、計画を1％改善することで年間数億円の削減になるのです。日本国内の製造業では年間約210兆円の原価がかかっているため、日本全体で1％の効率化をすれば、年間約2.1兆円の削減につながります。

ALGO ARTISは「社会基盤の最適化」というコーポレートミッションを掲げ、複雑で高度な運用計画策定業務の最適化を行う企業です。世界トップクラスのアルゴリズム技術を用いて、計画業務を支えるソリューションを開発しています。今回はALGO ARTISの取締役VPoEである武藤悠輔さんにインタビュー。「Startup CTO of the year 2023」の受賞者でもある武藤さんは、これまでどのような決断をして開発組織をけん引してきたのでしょうか。

事業の根幹を支えるのはアルゴリズムの力

――ALGO ARTISは、各種産業における運用計画の最適化ソリューションを提供しています。そもそも、なぜそうした業務はこれまでシステム化が進んでこなかったのでしょうか？

運用計画はとにかく複雑性が高い業務領域です。基本的に、世の中にある汎用的な業務支援システムは、どの企業でも共通していて一般化しやすい業務を効率化・自動化するものが中心です。しかし、運用計画は企業それぞれで業務フローや保有する機器・設備、業務の前提条件などが全く違います。運用計画に携わる人はそれらの情報を頭に入れたうえで、その企業の業務実態に即したプランニングをしています。

通常のシステム開発では、そうしたあらゆる条件をすべて機能に反映させることは難しいです。そのため、運用計画をDX化するプロジェクトを推進したけれど、うまくシステムを作れなかったとか、システムが完成しても使い物にならず元の状態に戻った事例が多いです。

しかし、ALGO ARTISは世界でもトップレベルのアルゴリズムの知見を持っており、従来のソリューションでは考慮しきれなかった運用上の条件を取り込んだうえで、高収益かつ低リスクの計画を自動出力するシステムを構築できます。これが、他社にはないALGO ARTISの強みになっています。

――武藤さんはスタートアップのCTOを讃えるピッチコンテスト「Startup CTO of the year 2023 powered by Amazon Web Services」で、最優秀賞である「Startup CTO of the year 2023」を受賞されましたが、感想はいかがですか？

まず、受賞できたことがとにかくうれしくて、ALGO ARTISの事業や開発組織としての取り組み全般を評価していただけたと感じています。ALGO ARTISの事業内容は人に伝えるのが本当に難しくて、これまでさまざまな場所で「どのような事業かよくわからない」と言われてきました。それを、ピッチで与えられた6分の発表時間の中で可能な限り表現して、その結果として光栄な賞を受賞できたことで、感慨深いものがありました。

知り合いの方々から「おめでとう」という連絡がありましたし、それ以外に採用にもプラスの効果がありました。驚いたのが、採用面接でエンジニアだけではなくビジネス職の方々も「Startup CTO of the year 2023」のことを知っていて、話してくれたことです。

現代のスタートアップでは、プロダクトやテクノロジーの力なしには事業を成長させられません。ほぼ確実にCTOやVPoEに相当する役割の人が必要になります。だからこそ「Startup CTO of the year」のような賞の重要性はより増してくると考えていたため、このイベントで評価していただけてうれしかったです。これをきっかけにエンジニアのコミュニティでの認知度を向上させて、会社の良さを多くの人たちに伝え、優秀なメンバーが集まる環境にしたいです。

ビジネスモデルにマッチしたシングルテナント環境を構築

――ここからは、ALGO ARTISが過去に取り組んできた技術的な意思決定の事例をお聞かせください。

まずは、創業当初に構築した共通基盤についてお話しします。ALGO ARTISはもともとDeNAからスピンオフした会社で、DeNAの時代からすでに数件の顧客を対象としたプロジェクトを進めていました。

私たちが扱うシステムの特徴として、作るべきプロダクトが顧客ごとに全く違うことが挙げられます。共通しているのは、業務要件が複雑かつセキュリティに厳しいことです。初期の段階で、システムの共通化をどのレベルでどこまで進めるか、判断が難しいという課題がありました。そのため、マルチテナントの設計を取り入れるには時期尚早であり、シングルテナントの設計にすべきだと考えました。

とはいえ、顧客ごとに全く別々のシステムを作ると、ALGO ARTISがエンタープライズ企業向けの専用SaaSを作る会社になってしまいます。そうなれば、各社のシステムごとに担当するチームを作る必要が生じますし、それぞれのチームに開発を統括するシニアエンジニアを配置することになります。その体制では、人を増やさなければ事業がスケールしなくなってしまうんです。

そこで、創業当初にまず実施したのは、特定顧客用のシングルテナント環境を、簡単に構築できるような共通基盤を作ることでした。そのテンプレートを使えば、エンタープライズ企業が求めるレベルのセキュリティ要件を満たす環境を、すぐに構築できるようにしました。

そして、私はAWSが得意だったのですが、最適化のシステムに向いているのがGCPだったため、使用するクラウドは共通基盤の構築時にすべてGCPで統一しました。複数のクラウドを使用すると、導入や運用の学習コストが高くなってしまうためです。また、リソース監視のためにDatadogを、外形監視のためにPrometheusを使用しており、各環境で何かのトラブルがあった際に検知するための共通監視基盤も構築しました。

誰にどのような価値を届けたいかによって最適な設計は変わる

――ALGO ARTISの扱う事業ドメインのどのような点に、システム化の難しさがあるのでしょうか？

ALGO ARTISが担っているプロダクト開発は、その事業ドメインの運用計画で扱うリソースとその状態、そして担当者の頭の中にある属人的な知識などをすべて管理するような、複雑性の高いものになります。BtoB SaaSの中でも、最難関レベルの難しさなのではないかと考えています。

また大きな特徴として、最適化のためのアルゴリズムをウォーターフォール的な流れでは作れないことが挙げられます。たとえば、顧客とミーティングをして要件などをヒアリングしたうえで、まずプロトタイプとなるシステムを作ります。それを試しに顧客に操作してもらうと、初期段階で生成される計画は多くの場合、使い物にならないんです。

なぜなら、最初のヒアリングの段階で顧客の方々が説明し忘れていたり、担当者の暗黙知になっている要素があったりと、情報を完全にキャッチアップすることが困難だからです。最適化アルゴリズムのアジャイル開発にともなって、扱うデータのスキーマは頻繁に変化していきます。

もし仮に、顧客と週に1回の定例会を開催しているならば、そのミーティングで会話をするたびにデータベースのスキーマ構造が変わることを意味します。一般的なプロダクト開発では初期段階でデータベースのスキーマを定めることが多いですが、そうした開発スタイルをとることができません。

――だからこそ、「何を共通化するか」を定義することが難しく、マルチテナントの設計にするのは困難だったということですね。

そうです。ただ、シングルテナントの設計のままではスケールしづらいのも確かです。そこで、プロダクトマーケットフィットに成功して事業拡大が見えている今では、マルチテナントの設計を各プロダクトに適用させていく作業を現在進行形で進めています。そして、先ほど述べた「スキーマ構造が頻繁に変わる」という課題を解決するために、スキーマのメタデータそのものをユーザーが変更できるような設計を取り入れています。

この施策は、ともすると行き過ぎた抽象化になってしまう可能性があり、開発工数がいたずらに増えてしまうリスクを伴います。しかし、ALGO ARTISのプロダクト開発においては、最適化アルゴリズムとそれにひも付くスキーマの更新をなるべくスムーズに行えることが、プロジェクト成功の鍵になります。そのため、こうした設計方針を選びました。

――この事例を踏まえて、読者の方々へのアドバイスはあるでしょうか？

「誰にどのような価値を届けたいか」によって、システムの最適な設計は変わってくると思っています。たとえば、「顧客ごとにシステムのカスタマイズを行わず、同じプロダクトをすべての顧客に適用していく」というビジネスモデルもあります。世の中の多くのBtoB SaaSはそうなっていますよね。

しかし、ALGO ARTISは企業ごとに内容が全く違う運用計画を最適化するためのプロダクトを提供しているので、顧客ごとにカスタマイズすることが前提となっているんです。そのカスタマイズがしやすく、かつ開発組織としてのスケールもしやすいことのバランスを取ることが常に必要でした。自社がサービスを届けたい事業領域や顧客、開発難易度の高さなどに合わせた方針策定が重要なのだと思います。

「エンジニア全員がフルスタック」を目指す

――他の取り組みについてもお聞きします。

私たちの扱うプロジェクトでは、時期ごとにエンジニアが取り組む業務に偏りがあります。たとえば、特定のプロジェクトでアルゴリズムを作るフェーズやプロダクトのユーザーインターフェースを作るフェーズなどが明確に分かれているという感じです。そのため、もし特定のメンバーしか特定のタスクをこなせない状態であれば、それぞれの顧客と調整してプロジェクトのフェーズをずらさない限り、複数プロジェクトを並走できなくなってしまいます。

「この人はフロントエンドエンジニア」とか「この人はインフラエンジニア」といった職能での役割分担が向いていません。そこで、私たちが取り組んだのは全員がフルスタックエンジニアになれる環境作りです。職能ではなくミッションで業務を分担する体制を実現することで、各プロジェクトをうまく推進したいと考えました。

もちろん、全員がすべての技術領域を担当する難易度は高いですが、それを担えるエンジニアを育成できるような環境を作りたいと思っています。先々には、ALGO ARTISでエンジニアの経験を積んだ人たちが、転職後はみんな次の会社のCTOやVPoEを担えるくらいの人材輩出企業にしたい。難易度の高い目標ですが、それを目指したいという思いがあります。

フルスタックに技術を学ぶ姿勢のあるエンジニアを採用するため、採用面談の際には「特定技術のスペシャリストのキャリアパスを歩まない限りは、ALGO ARTISでは基本的にフルスタックエンジニアのみを評価します」と前もって伝えています。ただ、その際にみなさんから「そう言ってもらえるほうがうれしい」と返答していただけることが多いです。裏を返せば、前向きに技術力を向上させたいというスタンスの方が、ALGO ARTISを選んでくれているのだと思います。

現在、フロントエンドはReact+TypeScriptでバックエンドはGo、アルゴリズムはC#を採用しています。前職でフロントエンドを担当していた人は、ALGO ARTISに参画して間もないうちはフロントエンドのタスクを主に割り振りますが、徐々に他の技術領域のタスクも担ってもらいます。

キャッチアップコストはかかりますが、みんなの様子を見ていて思うのは、エンジニアは新しいことを学ぶのが好きなのでポジティブに知識を習得してくれているということです。そういった姿勢のエンジニアが来てくれているからこそ、VPoEとしてはメンバーが確実にフルスタックを目指せるような、より良い環境を整えなければならないと感じています。メンバーたちと一緒に議論しつつ、体制作りに挑戦しているところです。

目指すは「運用計画のALGO ARTIS」が世界に認知された状態

――今後、武藤さんがALGO ARTISで実現したいことは何ですか？

ALGO ARTISの提供する運用計画という領域には、まだデファクトスタンダードのプロダクトがありません。そこで、最終的には「運用計画のALGO ARTIS」が世界に認知された状態まで持っていきたいという野望があります。

IT業界っぽい例えをすると、現代のWebアプリケーション開発では他の方々とデザインのコラボレーションをする際、Figmaなどを用いてオンラインで同期的に作業を進めることが多いですよね。でも、こうしたツールが登場する前はファイルのやりとりをして、非同期的に作業を進めるしかありませんでした。

運用計画の業務は、Figmaの登場前と近い状態にあると私は感じています。現在、それらの業務はExcelで作成した計画表やパソコンにインストールされたスタンドアローンのWindowsアプリケーションなどで遂行されています。コラボレーティブなはずの仕事を非同期かつファイルベースでやりとりしている状態です。

これをオンラインかつリアルタイムでやりとりできる状態にすることができれば、運用計画の業務そのものを次のフェーズに持っていけると考えています。そんなプロダクトを生み出せるような、大きな価値創出ができる開発組織を実現したいです。

あとは先ほど述べたこととも重複しますが、ALGO ARTISで働いていたエンジニアたちが、10年後の未来に企業を率いるCTOやVPoEになれるような道を作ることを、本気で目指したいと思います。

――壮大なビジョンで、聞いていてワクワクしますね。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。書籍やWeb記事などを通じてエンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

書籍やWeb記事が重要なことは、言うまでもないと思います。そうした媒体で発信されている成功事例からは、なんらかの事業を行っている会社が、実行したうえで価値を出しているプロダクト開発や組織作りの知見を学ぶことができます。自分が悩んでいることについて調べると、大抵の場合はそのテーマに合致した書籍やWeb記事を見つけることができます。その情報を参考にして筆者の思考や行動を追体験することで、ALGO ARTISで初めて遭遇した課題に対しても、良い意思決定につなげられているのではないかと思います。

そして、失敗事例についての情報からは、学ぶことが本当に多いと感じています。“良い”とされる技術的な取り組みや組織的な取り組みは、絶対的に正しいものではありません。事業のフェーズや対象とするマーケット、価値提案の仕方によって相対的に正否が異なってくるものだと思います。だからこそ、「こういった特徴の企業や開発組織でこの施策を推進すると、こういう失敗が起こり得る」と事前に学べること。さらに言えば、成功のバイアスがかかっていない情報を得られることは、非常に価値が高いと感じます。

スタートアップが取り組むのは蓋然性の低いビジネスです。世の中に課題が存在しており、かつ既存の企業が解決できていなかった難易度の高い領域に対して、リスクを取って挑戦することがスタートアップの本質だと思います。進むのが困難な場所や落とし穴が無数にあります。そうした困難さを、各社が悩みながら乗り越えている状況です。

そんな中で、書籍やWeb記事での情報発信を通じてお互いにGiveし合うことで、それぞれがより良い状態で挑戦できるようになります。これは究極的には、日本の将来を豊かにする一番の取り組みなのではないかと思っています。

これまで、私は他の会社の情報を受け取るばかりでしたが、私個人やALGO ARTISとして、もっと外部に情報を発信して、スタートアップ界隈の方々が良い挑戦に集中できるようにコミュニティに貢献したい。ひいては、日本・世界のより良い未来に貢献したいです。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul