Arnav Mishra, Dossの共同創設者兼CTO – インタビューシリーズ

Arnav Mishra、Dossの共同創設者兼CTOは、フルスタックエンジニアであり、テクニカルリーダーとして、スタートアップから大規模なインフラシステムまで幅広いバックグラウンドを持っています。Dossを共同創設する前は、Sitelineの創設エンジニアとして、パーミッションアーキテクチャ、ERP統合、自動化フレームワークなどのコアシステムを構築しました。また、採用、収益運用、会社文化にも貢献しました。彼のキャリアの初期には、RubrikとUber、VMwareなどの企業でエンジニアとして働き、クラウドインフラストラクチャ、データシステム、自動化の分野で専門知識を身に付けました。テクニカルな仕事と並行して、Techquitable FuturesやContraryなどの組織を通じて、メンターシップや人材育成にも積極的に参加し、次世代のエンジニアをサポートするという幅広いコミットメントを示しています。

Dossは、伝統的なERPシステムを再考するために、Adaptive Resource Platform（ARP）という柔軟でAIネイティブなオペレーション・プラットフォームを提供するモダンなエンタープライズ・ソフトウェア・カンパニーです。レガシーERPソリューションの代替として構築されたこのプラットフォームは、企業が在庫、調達、財務、納品を単一のシステム内で管理できるように設計されており、実際の運用に合わせて適応するのではなく、硬直的なプロセスを強制するのではなく、ビジネス・ワークフローを統合して自動化します。プラットフォームは、集中データ・レイヤー、ノーコード・ワークフロー、リアルタイム・アナリティクスを組み合わせて、ビジネスが迅速に展開し、既存のツールと統合し、長い実装や高額なコンサルタント費用なしに運用を継続的に進化させることを可能にします。

DOSSを構築する動機は、レガシーのソフトウェアがあなたの父親の製造業を妨害したことに遡り、両者がファクトリーとハードウェア・サプライ・チェーンで働いている間にも同様の問題を目撃しました。どのようにしてその経験がDOSSを共同創設し、ERPシステムを根本から再考するという決断に影響を与えましたか?

DOSS以前は、FinTechスタートアップの創設エンジニアでした。私たちのソリューションを採用しなかった理由は、CFO、会計士など、私たちの買い手が「既存のERPの実装に忙しい」ということです。私は古いERPの実装モデルに驚かされました。

私が見たのは、同じ根本的な失敗でした。実装には数ヶ月または数年かかり、数十万から数百万ドルかかり、人間のコンサルタントによる時間単位の請求でボトルネックが生じます。ERPが配備されると、変更されません。ビジネスは進化し続けますが、システムは進化しません。那は構造的な問題であり、構成の問題ではありません。パッチでは解決できません。

ソフトウェア・ビルダーとして、私が考えることができる最も近い比較は次の通りです。重要なツール、たとえばGitHubが、第三者コンサルティング・エージェンシーによって数年かけてあなたの会社のために特別に構築された世界を想像してください。製品が完成すると、コンサルタントはメンテナンス、機能の改善、サポートなしに退場します。エンジニアは反発します。

ウィリーと私は同じ結論に達しました。問題を修正する唯一の方法は、最初から構築することです。

DOSSは、SAPやOracleのような伝統的なERPシステムを置き換えるために設計された、AIネイティブなオペレーション・プラットフォームです。10年前には実現できなかった、DOSSのようなAIネイティブなERPを可能にする根本的なアーキテクチャの違いは何ですか?

OracleとSAPは、最大の配布を達成するために、ERPの構成面をGUIベースのエディターに簡素化する必要がありました。コンサルタントが大規模に提供できるように、コア・システムの大部分をロックダウンし、エッジでのみ構成可能にしました。しかし、実際には、ビジネス・アプリケーションには最大の柔軟性が必要です。

AIネイティブな世界では、ソフトウェア・エンジニアリングがクラフトから産業化されたマシンへの変換を可能にします。ソフトウェア・アーティサンがコード・システムを手作業で作成する必要はありません。代わりに、ソフトウェアのスループットはコンピュートとトークンの要因になります。

Dossは、まさにこのことを念頭に設計されています。

私たちは、ZSLという宣言的なドメイン・スペシフィック・言語（DSL）を構築しました。これは、顧客のDOSSの実装全体をコードで記述します。インフラストラクチャー・アズ・コード（IaC）へのTerraformの役割を想像してくださいが、ビジネス・アプリケーション・ロジックに適用されたものです。ERPを相対的に低次元のプログラミング言語で定義することで、ERPソリューションを大規模に配備するエージェントを提供できます。

ZSLが書かれた後、最も重要なアーキテクチャの部分は、エージェントが低品質の実装を構築しないように、プラットフォーム自体にベスト・プラクティスを組み込むことでした。私たちのチームは、スケーラブルな分散システムとカーネル・レベルのスケジューラーを提供しました。これはバースト的なERPワークロードの負荷を処理するために設計されています。さらに、トランザクション・データベースのようなPostgresとデータ・ウェアハウスのような分析機能を組み合わせたHTAPデータベース・システムを構築しました。

プラットフォームをエンタープライズ・グレードの強度で設計することで、システムは完全にエージェントによる配布のために設定されます。何が月または年を要するか、コンサルタントのチームによって行われるか、現在は大規模なエージェント・インフラストラクチャーを使用して並列化できます。

多くの企業は、調達、在庫、注文管理のためにスプレッドシートや断片的なツールに依存しています。コア・ビジネス・データが単一の真実源に統一されていない場合に生じる最大の運用上の盲点は何ですか?

最大の問題は、決定が古くなったまたは不完全な情報に基づいていることです。在庫データが一か所に、購入注文が別の場所に、販売注文が別の場所にある場合、常に手動で、遅く、事後的に調整しています。誰かが在庫がオフであるか、サプライヤーが遅れていることを認識するまでに、すでにビジネス上の問題になっています。

Verve Coffee Roastersは、どこでこの問題が実際に発生するかを示す良い例です。彼らは、米国と日本で、卸売、DTC、カフェを含む運用を管理していますが、実時間の在庫可視性がない状態で、断片化されたシステムでそれらを管理していました。彼らは高交通量のロケーションで自社のコーヒーが不足しており、主要な小売業者へのローンチ中に重要な在庫不足に陥り、重要な小売関係を損なっていました。データはどこかに存在しましたが、誰もが実行できるように接続されていませんでした。

より微妙な問題は、断片化が運用の実際の形を隠していることです。上流での遅延と下流での納品問題の関係が、別々のツールに存在する場合には見ることができません。症状を管理し、注文を速める、安全在庫を構築し、手動のチェックを実行することになりますが、実際に何が起こっているかを理解することはできません。統一されたシステムは、調整に費やした時間を節約するだけではありません。何を見て、どんな質問を投げかけるかが変わります。

本質的に、エンタープライズ・ビジネスを運営することなく、バージョン・コントロール・システム（Git）、可視化ツール（DataDog）、または情報を照会するための集中データベースがないことを想像してください。

伝統的なERP実装には、大規模なコンサルティング・チームと数ヶ月または数年間の展開が必要です。AIは、実運用ソフトウェアの実装における経済性と複雑さをどのように変えますか?

伝統的な実装モデルは、古いソフトウェアの慣行の結果です。私たちはもうその世界に住んでいません。

現在のERP実装には、実装が長くかかり、効果が低いほど、実装者がより多くの金銭を稼ぐという、ある種の逆インセンティブがあります。ほとんどのビルダーはこのような機会を利用しませんが、彼らはスピードと品質で動くことができません。

さらに、伝統的なERPエンゲージメントにおけるコンサルティング費用とソフトウェア費用の比率は、約9:1です。つまり、ソフトウェア自体に1ドルを費やすごとに、コンサルタントに9ドルを費やします。大企業にとっては非常に痛みですが、中規模企業にとっては禁止されます。したがって、彼らは実際に運用されるソフトウェアに合わないソフトウェアに妥協したり、プロジェクトを遅らせたり、途中で放棄したりします。

AIは、このユニットの経済性を完全に変えます。コンサルティング・エンゲージメントではなく、DOSSの実装はコードベースです。実装時間が短縮するにつれて、コンサルタントが関与するのではなく、「納品時に支払う」モデルでインセンティブを整えることができます。ビジネスが変わると、システムも変わります。コンサルタントの部屋や長いスライドの必要性はもうありません。

DOSSでの成功は、1.86兆ドルの世界的なITサービス支出を、ZSLをビジネス・アプリケーション・ソフトウェアの言語として使用するエージェントによる実装とメンテナンスに置き換えることです。DOSSでの成功は、ビジネス・アプリケーションを大規模にコモディティ化することです。

DOSSは、製造、物流、消費財などの現実の環境で運用されている企業に展開されています。AIが汚れた運用データに出会うときに生じる、予想外の課題は何ですか?

課題は、AIではありません。それは、AIが推論するデータです。

私たちが協力するすべての企業には、運用上の回避策が蓄積されています。データは技術的には存在しますが、従業員、あるいはエージェント・システムが信頼性を持って実行できる場所にはありません。

良い例は、注文に応じて家具を制作するドイツの家具メーカーです。当社が参入したとき、彼らは10年間の歴史的なデータを8つのカスタム・ファイル・フォーマットに分散させ、11の異なるデータ・オブジェクトと3PL同期をFTPフォルダからの手動コピー・ペーストで実行していました。ビジネス・ロジックはカスタム・寸法、構成、支払い方法、ショールームのロケーションに特化しており、システム全体はドイツ語で動作する必要がありました。そこには、オフ・ザ・シェルフのスキーマはありません。彼らは、購入注文のステータス・オプションのような単純な構成オプションを変更するたびに、数千ユーロを支払わなければなりませんでした。

課題は、個々のピースの技術的な複雑さではありません。それは、すべての企業がこの問題の異なるバージョンを持っているということです。これを完全に予測することは、データの中に入るまでできません。仕事は、ビジネスが実際にどのように運営されているかを正確に把握することです。データを汎用的なテンプレートにマッピングするのではなく、ビジネスに適合するようにします。

現実の世界で機能するソリューションを構築するには、最大の柔軟性を持つプラットフォームが必要です。そうすれば、AIは、基になるデータ・モデルを理解し、各顧客に適したモデルを構築することができます。

AIコピロットやオートノマス・エージェントがビジネス・ソフトウェアでどのように機能するかについて、多くの議論があります。運用ワークフローでAIが最も価値を加えるのはどこですか? 人間の監視はどこでまだ不可欠ですか?

大規模に、AIは運用作業をすべて妨害する能力を持っています。

近い将来、Dossの独自のモデルとエージェントは、ビジネス・アプリケーションの実装におけるテクニカル・コンサルタントと、戦略的推奨の提供におけるマネジメント・コンサルタントの役割を変えることができます。Dossは、ビジネスに対するスキーマと運用情報の両方を表す構造化されたデータと運用情報の最大のリポジトリを持ちます。私たちのエージェントは、このデータを使用してスケーラブルな推奨事項を提供できます。

最も明確な価値は、より具体的です。購買注文の処理、在庫の調整、納品のルーティングの決定など、繰り返し、ルールに基づいて、現在人が行っている作業です。これらのタスクには、明確な入力と出力があり、AIはそれらを信頼性を持って大規模に処理できます。

現在、人間の監視は、間違った決定のコストが高く、システムがまだ十分なコンテキストを持っていない場所で不可欠です。今日の正しいモデルは、人間の意思決定を全面的には置き換えることではなく、エージェントが大量の、明確に定義された作業を処理できるようにすることです。そうすれば、人々は、実際に判断を必要とする決定に集中できます。

多くの企業は、既存のソフトウェア・スタックの上にAIを重ねています。レガシー・システムにAIを後から付加することと、プラットフォームの基盤にAIを組み込むことの違いは何ですか?

レガシー・システムは、AIによって推論されるように設計されていません。データ・モデル、API、情報の構造はすべて、人間がインターフェイスを通じて相互作用するように設計されています。AIを上に重ねると、AIは、設計時に想定されていなかった制約を回避するように求められます。

MCPサーバーを上に配置しようとしても、実際にはMCPサーバーは非常に特定の設計パターンを必要とします。現在のMCPサーバーは、コンテキスト・ウィンドウの膨張とパフォーマンスの低下を引き起こすことがあります。

しかし、より深い問題は、実装モデルにあります。伝統的なERPでは、システムの構成はシステム自体に保存されています。コードを読んだり、テストしたり、バージョン管理したりすることはできません。エージェントがシステムが何をしているかを理解することはできず、安全に変更することもできません。ZSLは、構成が適切なコードベースであることを保証するために設計されています。読み取り、テスト、デプロイが可能です。私たちは、完全にエージェントによるソフトウェア開発ライフサイクル（SDLC）を構築しています。これが、AIがシステムを操作するための前提条件です。システムの上に単に座るのではなく。

AIがワークフローを生成し、運用システムと直接相互作用できるようになると、伝統的なエンタープライズ・ソフトウェア・インターフェイスはどのように進化するでしょうか?

インターフェイスの問題は、誰がシステムを使用する必要があるかということです。現在、ERPインターフェイスは、システムを実装中にトレーニングを受けた、小規模なパワーユーザーのグループを中心に構築されています。他の人は使用できないか、劣化したバージョンしか使用できない場合があります。

私たちが構築しているのは、インターフェイスをウェブサイト・ビルダーのように扱う、構成可能なUIです。インターフェイス自体も、閉じたZSLによってバックアップされています。CFO、倉庫マネージャー、サプライ・チェーン・アナリストなど、誰でも、実際にどのように働いているかに基づいて、ダッシュボードとデータ・ビューが構成されます。AIが基盤となるワークフローを処理するにつれて、インターフェイスはデータ入力ではなく、可視性と意思決定についてになります。誰かが何が起こっているかを把握し、理解し、判断を下す必要があります。ソフトウェアは残りを処理します。

DOSSのようなスタートアップは、数十年来の既存企業が支配する市場に参入しています。AIネイティブなスタートアップが既存のエンタープライズ・プラットフォームと競合するときの利点は何ですか?

既存の企業には、逆の問題があります。彼らは、保護するために大量のインストール・ベースを持っています。彼らが下すすべてのアーキテクチャ上の決定は、後方互換性を持たなければなりません。彼らは、既存の製品にAI機能を追加できますが、すべてが動作するようにするために、基盤となるシステムを再構築することはできません。これは、野心の欠如ではなく、構造的な問題です。

特にERPでは、彼らは、DOSSが排除しようとしている特定の機能によって推進されるビジネス上の決定を下してきました。ユーザーがソフトウェア自体に1ドルを費やすごとに、コンサルタントに9ドルを費やすため、大規模な既存企業にとって、90%の収益源を変えることは不可能です。

AIネイティブなシステムは、AIがコア・アーキテクチャの一部であるように設計できます。実装モデル、データ・モデル、構成の方法はすべて、AIが第一級の参加者として設計されています。これは、毎回のデプロイでシステムを改善する、累積的な利点です。実装エージェントは、各新しい顧客とともにより能力が高まります。このような改善ループは、実装がまだ人間のコンサルティング・エンゲージメントであるシステムでは存在しません。

先を見て、次の5〜10年で、サプライ・チェーンの可視性、リアルタイムの意思決定、自動化された運用などの分野で、AIがビジネスの「オペレーティング・システム」をどのように変えるでしょうか?

私たちは、エンタープライズ・システムが自分で構築できるという信念でDOSSを設立しました。3年目に、DOSSの第2フェーズに突入しました。プラットフォームは、顧客のシステムを生成、検証、進化させることができ、人間のコンサルタントの構成に頼るのではなく、エージェントによる実装が可能です。

この方向に向かっているのは、常にビジネスと同期しているシステムです。今日、ビジネスがどのように運営されているかと、システムがそれについて知っていることが間にあるギャップは、数ヶ月または数年です。システムはある時点で構成され、変更されていません。システムがビジネスと同期しているギャップが閉じたときに、可能になるのは、別のカテゴリの運用能力です。リアルタイムの可視性は、単に高速なレポートではありません。サプライ・チェーンの障害を、納品障害になる前に検出する能力です。自動化された運用は、効率だけではありません。同じチームでより複雑なビジネスを運営する能力です。これが、私たちが構築しようとしている、運用ソフトウェアのバージョンです。

ご質問に詳細に答えてくださり、ありがとうございます。詳しく知りたい読者は、Dossを訪けてください。