インタビュー
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を使用すると、企業は在庫管理、調達、財務、納品を単一のシステム内で管理できます。このシステムは、集中データレイヤー、ノーコード・ワークフロー、リアルタイム分析を組み合わせており、ビジネスは迅速に展開し、既存のツールと統合し、長期間の実装や高額なコンサルタント費用なしに運用を継続的に進化させることができます。
伝統的なERPシステムの問題点は、実装に長期間かかり、高額な費用がかかることです。Dossの創設者であるあなたは、伝統的なERPシステムの問題点をどのように見ており、それをどのように解決しようとしていますか。
Dossを共同創設する前の私は、FinTechスタートアップの創設エンジニアでした。当時の私たちの買い手であるCFOや会計担当者たちは、私たちのソリューションを採用しなかった理由の1つは、「ERPの実装に忙しい」ということでした。私は、古代的なERPの実装モデルに驚かされました。
私が見たものは、同じ根本的な失敗でした。実装には数ヶ月または数年かかり、数十万から数百万ドルかかることが多く、人間のコンサルタントによる時間単位の請求でボトルネックになっていました。次に、ERPが配信されると、変更が止まります。ビジネスは進化し続けますが、システムは進化しません。那はアーキテクチャの問題であり、構成の問題ではありません。パッチで解決することはできません。
ソフトウェア・ビルダーとして、私が考えることができる最も近い比較は、次のようになります。最も重要なツール、たとえばGitHubが、外部のコンサルティング会社によって数年かけてあなたの会社のために特別に構築された世界を想像してください。次に、製品が完成すると、コンサルタントはメンテナンス、機能の改善、サポートなしに去ります。エンジニアは反発します。
モダンなテクノロジー会社は、そのモデルで運営することはできません。Wileyと私は同じ結論に達しました。問題を修正する唯一の方法は、最初から構築することです。
Dossは、伝統的なERPシステムの代替として、AIネイティブなオペレーション・プラットフォームを提供しています。10年前には不可能だった、DossのようなAIネイティブなERPを可能にする、基本的なアーキテクチャの違いは何ですか。
OracleやSAPは、最大限の配布を達成するために、ERPの構成プレーンを、相対的に非技術的なコンサルタントが大規模に提供できるGUIベースのエディターとして簡素化する必要がありました。ベストプラクティスを保存するために、彼らはコアシステムの広い範囲をロックダウンし、エッジでのみ構成可能にしました。しかし、実際には、ビジネスのアプリケーションは最大の柔軟性が必要です。
AIネイティブな世界は、ソフトウェアエンジニアリングを、クラフトから産業化されたマシンへの変換を可能にします。ソフトウェアシステムを手作業で構築する必要はありません。代わりに、ソフトウェアの生産量はコンピュートとトークンの要因になります。
Dossは、まさにこのことを念頭に設計されています。
私たちは、ZSLと呼ばれる宣言的なドメイン固有言語（DSL）を構築しました。これは、Dossの実装全体をコードで記述します。インフラストラクチャーとしてコード（Terraform）が行ったことと同様に、ビジネス・アプリケーション・ロジックに適用されます。低次元のプログラミング言語でERPを定義することで、ERPソリューションを配信するエージェントを大規模に展開できます。
ZSLが書かれたら、最も重要なアーキテクチャの部分は、エージェントが低品質の実装を構築できないように、プラットフォーム自体にベストプラクティスを組み込むことでした。私たちのチームは、スケーラブルな分散システムとカーネルレベルのスケジューラを提供しました。これは、バースト的なERPワークロードの負荷を処理するために設計されています。さらに、私たちは、Postgresのようなトランザクション・データベースとData Warehouseの分析機能を組み合わせたHTAPデータベース・システムを構築しました。
プラットフォームをエンタープライズグレードの強度で構築することで、システムは完全にエージェントによる配信のために設定されます。コンサルタントのチームが数ヶ月または数年かけて行っていたことは、現在は私たちの独自のクローズド・ループ・システムを使用して大規模に並列化できます。
多くの企業は、調達、在庫、注文管理のために、まだスプレッドシートや断片的なツールに依存しています。コア・ビジネス・データが単一の真実源に統一されていない場合に生じる、最も重大な運用上の盲点は何ですか。
最も重大な問題は、決定が古くなったまたは不完全な情報に基づいていることです。在庫データが一か所に、購入注文が別の場所に、販売注文が3か所に存在する場合、常に手動で、遅く、事後的に調整しています。誰かが在庫が不足していることや、サプライヤーが遅れていることを認識するまでに、すでにビジネス上の問題になっていることがあります。
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が推論するように求められているデータです。
私たちが協力しているすべてのビジネスは、運用上のワークアラウンドを蓄積してきました。データは技術的には存在しますが、従業員、ひいてはエージェントが信頼性高く行動できる場所には存在しません。
ドイツの家具メーカーは、注文生産品を制作する会社の良い例です。当社が参入したとき、彼らは、11の異なるデータ・オブジェクトと3PL同期を備えた、8つのカスタム・ファイル形式にわたる10年間の歴史的なデータを保持していました。ビジネス・ロジックは、カスタム・ディメンション、構成、支払い方法、ショールームのロケーションなど、特定のものでした。システムはドイツ語で動作する必要がありました。オフ・ザ・シェルフのスキーマはありませんでした。彼らは、購入注文のステータス・オプションなどの単純な構成オプションを変更するたびに、数千ユーロを支払わなければなりませんでした。
課題は、技術的な複雑さではありません。課題は、すべてのビジネスがこの問題の独自のバージョンを持っていることです。完全に予測することはできないでしょう。データ内に入るまでです。
現実の世界で機能するソリューションを構築するには、最大の柔軟性を持つプラットフォームが必要です。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ネイティブなスタートアップは、確立されたエンタープライズ・プラットフォームと競合する際にどのような利点がありますか。
インキューバントには、Dossとは逆の問題があります。彼らには、保護するために巨大なインストール・ベースがあります。彼らが下すすべてのアーキテクチャ上の決定は、下位互換性でなければなりません。彼らは、既存の製品にAI機能を追加できますが、根本的なシステムを再構築することはできません。そうすると、実行されているすべてのものが壊れてしまいます。那は野心の欠如ではありません。那は構造的なものです。
特にERPでは、彼らは、Dossが解決しようとしている機能、つまりプロフェッショナル・サービス・コンサルタントからの収益に基づいてビジネス上の決定を下してきました。ユーザーがソフトウェア自体に1ドルを費やすごとに、9ドルをコンサルタントに費やす場合、コンサルタントによる収入の90%を変えることは、大規模なインキューバントにとっては実行不可能です。
AIネイティブなシステムは、最初からAIがコア・アーキテクチャの一部であるように設計できます。実装モデル、データ・モデル、構成の方法はすべて、AIが最初から参加するように設計されています。那は、コンパウンドされる利点です。各展開でシステムが改善され、実装エージェントが新しい顧客ごとにより有能になります。伝統的なシステムでは、実装は人間のコンサルティング・エンゲージメントであるため、そのような改善ループは存在しません。
今後5〜10年で、特にサプライ・チェーンの可視性、リアルタイムの意思決定、自動化された運用などの分野で、AIがビジネスの「運用システム」をどのように変革するかを見据えていますか。
私たちは、エンタープライズ・システムが自分で構築できるという信念でDossを共同創設しました。3年目に入り、私たちはDossの第2フェーズ、エージェントによるセルフ・ドライビング・実装に突入しました。プラットフォームは、手動のコンサルタントの構成ではなく、顧客のシステムを生成、検証、進化させることができるようになりました。また、各展開で改善されます。
この方向に進むのは、常にビジネスと同期しているシステムです。現在、ビジネスが運営されている方法と、ソフトウェアが知っている方法の間には、数ヶ月または数年のギャップがあります。システムは、ある時点で構成され、変更されていません。システムがリアルタイムでビジネスと同期している場合に可能になるのは、異なるカテゴリの運用能力です。リアルタイムの可視性は、単に報告の高速化ではありません。サプライ・チェーンの障害を、納品の障害になる前に検出する能力です。自動化された運用は、効率だけではありません。同じチームでより複雑なビジネスを運営する能力です。那が、私たちが構築しようとしている運用ソフトウェアのバージョンです。
詳細な回答ありがとうございます。さらに詳しく知りたい読者は、Dossを訪問してください。
