レコードシステムはローカルであるべき
私は、サプライチェーンにおいて多くの企業が広範なレコードシステムの購入をやめ、これをローカルで構築すべきだと考えるようになった。ここで言うソフトウェアとは、注文、受領、在庫移動、請求書、承認、そして通常の業務に伴う事務処理を記録するものを指す。これらのシステムは重要であるが、その価値は限定されている。それらはワークフローを伴う台帳に過ぎない。市場は依然として、それらに価格を付け、提示し、会社の最高の宝石であるかのように管理している。その誤りは非常に高価になってしまった。
「サプライチェーン入門」、特に第5章と第6章では、紙の記録を保持するソフトウェアと意思決定を行うソフトウェアの間に明確な区別を設けた。その区別はここで重要である。通常の演出を排したレコードシステムを見ると、その神秘性の多くは消え去る。レコードシステムは、信頼性があり、監査可能で、むしろ単調であるべきだ。考えているふりをしてはならない。事実を記憶し、いくつかのワークフローを強制し、邪魔をしないようにすべきだ。
パッケージ化された台帳の隠れた税
記録システムは商業的成熟に迅速に到達します。一度、購買、販売、在庫、請求処理、およびその他の隣接するワークフローを忠実に処理できるようになると、それを拡張する余分な価値はごく僅かです。ベンダーはこれを十分に理解しています。彼らの答えは何十年も同じでした。すなわち、別のエンティティ、別の画面、別のモジュール、別の設定ページを追加することです。既存の顧客基盤に次の増分を販売するのです。時が経つにつれて、製品は無数の顧客要求の堆積物となり、その多くは個別には理にかなっているものの、全体としては非常識なものとなります。その結果、基本的な仕事がほとんど変わらないにもかかわらず、複雑性だけが増大する機能の巨大な塊となるのです。
学術文献では、何年にもわたり同じ問題がもっと穏やかな言葉で記述されてきました。Strong と Volkoff は、パッケージ化されたエンタープライズシステムが特定の要求ではなく汎用的な要求向けに設計されているため、どの具体的な組織においても完全な適合とはならない傾向があると観察しました。ERPカスタマイゼーションに関するより最近の研究は、そのトレードオフを明示しています。カスタマイズは機能性やユーザー満足度を向上させる一方で、実装コスト、複雑性、および後のアップグレードの費用を増加させるのです。2025年のERPミスマッチに関するレビューも同様に冷静な結論に達しており、実装失敗率は高止まりし、標準化されたプロセスと現地のワークフローとの不整合が続き、これらのミスマッチを明確に解消するための広く採用された業界の実践が現れていない、と結論づけています。
この税はライセンス料に限定されるものではありません。Panoramaの2025年ERPベンチマークによると、プロジェクトの中央値は450,000米ドル、期間の中央値は9か月です。予算を超過したプロジェクトでは、最も一般的な理由は追加技術の予期せぬ必要性であり、遅延したプロジェクトでは、データの問題が主な原因でした。同じレポートは、多くのERP実装が依然として組織内のサイロを解消できていないとも指摘しています。これが私が繰り返し目にするパターンです。すなわち、スイートは複雑性を解消するのではなく、その複雑性を統合、移行、ガバナンス、および精巧な回避策へと再分配しているのです。
基盤となるデータモデルも同様の事実を物語っています。MicrosoftのDynamics向けドキュメントでは、顧客のような単純なビジネス概念が複数の正規化テーブルに散在しているため、データエンティティが非正規化された抽象として存在する理由が説明されています。OracleのJD Edwards向けドキュメントは、タイプ別およびモジュール別に長大なテーブルカタログを公開しています。サードパーティのスキーマカタログであるERPRefは、SAP Business One 9.0で1,687テーブル、JD Edwards 9.20で5,097テーブルをリストしており、同じカタログ上でSAP Business One 9.3のA/R請求書テーブルは424カラムとして示されています。特定の企業はこの広がりのほんの一部しか使用しないものの、権限、マッピング、統合、トレーニング、アップグレードにおいてこの広がりの代償を支払っているのです。
第二の税が存在し、それはしばしばより破壊的です。ウィリアム・オカシオの注意に基づく企業観は、単純な観察から始まります：企業が行うことは、意思決定者の注意がどのように向けられるかに依存します。広大な記録システムは、現金を消費するのと同様にその注意を消費します。実装、クリーンアップ、移行、再設計、追加機能、アップグレードに費やされた年は、上級管理職が事務インフラの仕組みに没頭する年です。以前、私は、記録と報告がソフトウェア予算の大部分を占めると、実際に意思決定を改善するソフトウェアに十分な余地を残さず、経営陣のリソースの大部分をも消費すると論じました。
なぜカスタム開発が難しくなくなったのか
注目すべきは、カスタム記録システムの技術的根拠がかなり前からもはや希少なものではなくなったという点です。PostgreSQLは40年近くにわたる活発な開発の実績があり、2001年以降ACID準拠となっています。ASP.NET Coreは無料でオープンソース、かつクロスプラットフォームです。Entity Framework Coreは、複数のデータベースにわたる変更追跡、アップデート、スキーマ移行をサポートします。Djangoには、一般的なウェブ攻撃に対する組み込みの保護機能が備わっています。取引型ソフトウェアの基盤がこれほど成熟していると、狭義の内部台帳を構築することはもはや勇気の行為ではなくなります。
Djangoのドキュメントには、非常に示唆に富む詳細さえあります。その自動管理インターフェースは、組織の内部管理ツール向けに推奨されており、パブリックなフロントエンド向けではありません。その小さな注意書きが、全体像を的確に捉えています。業界は、CRUDソフトウェアのバックオフィスとなる骨組みを徹底的に標準化しており、主要なフレームワークはそれを標準搭載しています。残る難点は配管工事ではなく、どのエンティティ、状態、ワークフローが自社にとって本当に重要で、どれが単にあるベンダーが20年間かけて市場セグメントの癖を集めた結果であるかを決定することです。
ここでカスタム開発が決定的に勝利を収めます。優位性は、コードの技巧ではなく、意味論的な正確さにあります。エンティティは、企業が実際に運用される仕組みに対応しうるのです：製品の階層、購買例外、受領ステータス、承認ルール、返品理由、品質保留、そして一般的なスイートでは理解されるべきでない、奇妙ではあるが有用な区別です。小規模なローカルコードベースは、理解しやすいままでいられます。さらに重要なのは、企業がそのコードに体現された運用知識の所有権を保持できるという点です。ソフトウェアはビジネスを映し出し、企業はもはやベンダーの全顧客基盤が積み重ねた妥協を引き継ぐ必要がなくなります。
コーディングエージェントがもたらした変化
2025年に変化したのは、データベースやブラウザ、ウェブスタックではなく、コード生産のコストです。2025年1月、AnthropicはアップグレードされたClaude 3.5 SonnetエージェントがSWE-bench Verifiedで49パーセントを記録したと報告しました。8月までに、Claude Opus 4.1は74.5パーセントに達しました。後にSWE-benchチームは、ミニSWEエージェントが最低限の構成で同じ検証済みサブセットで65パーセントに達したと述べました。一方、OpenAIはCodexを、並列で多数のタスクをこなせ、分離された環境でテストおよびリンターを実行し、レビュー用の変更提案を行うクラウドソフトウェアエージェントとしてリリースしました。さらに別の社内製品実験では、OpenAIはCodexが100万行のコードベース全体を、手作業でのコーディング時間の約十分の一で構築したと述べています。
これは、すべてのコードベースにおいてエージェントがすべてのエンジニアをより速くすることを意味するわけではありません。METRが経験豊富なオープンソース開発者を対象に実施したランダム化試験では、2025年前半のAIツールが、彼らが自身のリポジトリで作業する際に19パーセントの速度低下をもたらすことが判明しました。私はその結果を真剣に受け止めています。しかし、これは同じ問題を示しているわけではありません。何年にもわたる暗黙の文脈と厳格な基準を持つ成熟した公共コードベースを維持することは、受注ワークフロー、サプライヤーポータル、在庫調整バックオフィス、または内部チーム向けの返品画面を作成することとは異なります。後者の場合、要件はローカルであり、受け入れ基準は具体的で、アーキテクチャは平凡です。METRの別の時間軸に関する研究も、先端エージェントが50パーセントの確率で完了できるソフトウェアタスクの長さが約7ヶ月ごとに倍増していると報告しています。これは、作業が狭く明確に定義されている場合にまさに重要な傾向です。
このため、通常の製造業者、流通業者、小売業者であっても、以前よりはるかに多くの取引型ソフトウェアを自社で所有することが合理的になりました。そのような企業はソフトウェアベンダーになる必要はありません。ビジネスを熟知したプロセスオーナー、技術に精通したリーダー、小規模なコードベース、テストスイート、そしてスコープを狭く保つための規律が必要です。コーディングエージェントは、記録システムの大部分を占める単調な部分に必要な手作業の実装量を減少させます。その間、成熟したオープンソーススタックが残りを補います。この組み合わせは、記録システムが非常に地味であるため、まさに強力なのです。それらは主にフォーム、テーブル、バリデーション、権限、ワークフロー、統合で構成されており、そこにツールの実力が発揮されます。
依然として、ベンダーの主要な価値が法令の変更に対応することにある領域は除外すべきです。そこは実際の例外です。それ以外では、特にサプライチェーンにおいては、状況は逆転すべきです。購入フロー、受注、返品、品質保留、供給業者との連携、マスターデータ管理、その他類似の取引領域において、一般的なパッケージソフトウェアは並外れた適合性を得るための高価な手段となっています。カスタム開発の代替手段はもはや技術企業だけの専売特許ではなく、控えめな量のコードを所有し、そのコードベースを大規模なプラットフォームに変える誘惑を拒む用意があるなら、一般企業でも手の届くものになっています。
この事例はもはや感傷的でも未来的でもありません。一般的なパッケージ型台帳は、その構造上ジェネリックであり、習慣的に不適合で、コストと注意の両面でインフレーション的です。狭義の代替品を構築するためのツールは、すでに何年も前から成熟しています。コーディングエージェントは、かつて多くの企業の行動を阻んでいた、膨大なルーチンコードという最後の障壁を圧縮しました。取引型サプライチェーンシステムにおいては、証明責任が逆転しています。まず、なぜこのシステムをそもそも購入する必要があるのかを問うべきです。
