AI時代のエンタープライズソフトウェア、「自社構築」か「購入」か

エンタープライズソフトウェアの歴史の大半において、「これは自社で構築すべきか、購入すべきか」という問いへの標準的な答えは、たいてい「購入」だった。特に社内ツールではそうだった。企業が財務、採用、人事、営業、プロジェクト管理、カスタマーサポート向けのソフトウェアを必要とする場合、現実的な答えはほぼ常に、すでに存在するものを購入することだった。

しかし、最近のビジネスの多くの側面と同様に、AIはその計算を変えた。それでもなお一部の企業は、AIと現代的な開発ツールによってカスタムワークフローがはるかに実現しやすくなっているにもかかわらず、ほぼすべての社内システムは購入すべきだという古い前提で動いている。一方で、行き過ぎた反動として、本来は自社で構築すべきではないものまで社内で作ろうとする企業も見受けられる。

より難しく、より有用な答えは、その中間にある。私の実践的な枠組みはシンプルだ。差別化につながらないものは購入し、大きなレバレッジを生むものは構築し、エンジニアリング時間の機会費用については極めて率直であることだ。

購入がなお優位な場合

企業の中には、重要ではあるが独自ではない機能が数多く存在する。財務は重要だ。採用も重要だ。人事も重要だ。しかし、ほとんどの企業は、支援するためにソフトウェアをゼロから構築する必要があるほど独自の財務ワークフロー、採用プロセス、人事機能を持っているわけではない。

そうした場合、購入は依然として理にかなっている。市場には優れたソフトウェアが存在し、通常は成熟したSaaS製品を購入して設定する方が、自社で独自バージョンを構築、デバッグ、保守、セキュリティ対応、更新するよりもはるかに安価だ。

ここで、一部の企業がAIコーディングツールの台頭によって気を取られていると私は考えている。社内ソフトウェアを構築することが以前より容易になったからといって、すべてを自前で構築することが突如として良いアイデアになるわけではない。チームが「バイブコーディング」でCRMを作ることはできるが、その結果が安定し、安全で、スケーラブルで、長年にわたり磨き上げられてきた既存ツールより優れているとは限らない。

初期の開発コストが全体のコストであることは滅多にない。製品を保守し、バグに対応し、イレギュラーな事態に対応し、社内ユーザーをサポートし、ビジネスの変化に合わせて更新していく必要がある。さらに、成熟したソフトウェア企業が何年もかけて解決してきたアクセス権限、システム連携、データの質、セキュリティ、レポーティングといった細かなディテールすべてについても考えなければならない。

自社が何千もの他社と共有する機能については、購入がなお正しい答えであることが多い。

構築が意味を持ち始める場合

構築か購入かという問いは、ワークフローの差別化が進むほど興味深くなる。

たとえば、当社では顧客オンボーディング体験でこの問題に直面した。当社のオンボーディングは複雑で、クリエイティブな作業、タスク管理、プロジェクト管理、複数の社内チーム間の調整、顧客とのコミュニケーション、そして当社の価値提供の仕方に特有の一連のステップが関わっている。

サードパーティのツールも検討したが、問題はそれらが悪いということではなかった。問題は、それらが当社のプロセスを中心に設計されていないという点だった。それらを機能させるためには、あまりにも多くのカスタマイズ、回避策、手動のステップが必要となり、結果としてチームが本当に必要とするシステムを提供するのではなく、ツールに合わせてプロセスを曲げることになってしまう。そこで、その体験を自社製品に組み込むことに決めた。

これは軽い決断ではなかった。フルタイムのエンジニア1名とフルタイムのプロダクトマネージャー1名が数カ月にわたって取り組み、その投資には実質的な機会費用が伴う。彼らは別のことに取り組むこともできた。この決定が意味を持ったのは、そのワークフローが会社の運営の中核であり、改善することでチームに意味のあるレバレッジをもたらし、顧客により良い体験を提供できたからに他ならない。

これが私が用いる基準だ。構築しようとしているものが会社の差別化に深く結びついている場合、既製のツールではうまく対応できないワークフローを改善する場合、あるいは顕著に優れた顧客体験を生み出す場合、構築はしばしば理にかなう。SaaSベンダーに料金を払いたくないというのが唯一の理由であれば、その論拠はたいてい十分に強くない。

コスト削減だけでは通常不十分

社内構築の危険性は、スプレッドシート上では合理的に見える一方で、最も優秀な人材をより高価値の業務から引き離してしまうことにある。企業はソフトウェアの請求書を見て、「これは自分たちで作れる」と考えるかもしれない。特にAIがプロトタイピングと開発を加速できる今、それが真実である場合もある。しかし、より良い問いは、同じ時間でチームが他に何を構築できるかということだ。

成長モードにある場合、エンジニアリング人材の最も価値の高い活用方法は、通常、顧客価値を創出するもの、新たな収益機会を切り開くもの、製品を強化するもの、あるいは事業の中核となる領域でレバレッジを生むものを構築することだ。SaaS料金を節約することは有用かもしれないが、成長中の企業にとって、希少な技術人材の最適な活用方法ではないことが多い。

もちろん例外はある。収益性に強く注力している成熟企業であれば、効率性の観点から社内ツールの自社開発を選択することもあるだろう。大規模なエンジニアリング組織を持つ企業であれば、社内システム専用のチームを配置しているかもしれない。また、非常に特殊なワークフローであれば、その恩恵が主に運用上のものに留まるとしても、独自開発が正当化される場合もある。

しかし、ほとんどの企業は慎重になるべきだ。社内ツールは直面している課題の解決が目に見えるため生産的に感じられがちだが、機会費用の測定はより困難である。開発しなかった製品、提供を遅らせた顧客向け機能、あるいは追求しなかった新たな収益源は、回避できたソフトウェア費用よりもはるかに価値があったかもしれないのだ。

判断のためのフレームワーク

私が尋ねる問いはこうだ。これを社内で構築することで、自社に特有の優位性が生まれるか？ 答えがノーなら、購入せよ。答えがイエスなら、構築する価値があるかもしれない。

AIは多くの場合、構築をより簡単に、より速く、より安価にしたが、構築が容易になったからといって判断の必要性がなくなるわけではない。

目的は、構築すること自体を目的に、より多くを作ることではない。目的は、自社にしか生み出せない何かがある問題に、最も貴重な技術リソースを振り向けることだ。

（forbes.com 原文）