2021年、私はシカゴ郊外の3PL倉庫を見学した。そのオーナーは、まったく見当違いのことを誇らしげに語った。「連携は全部自社で開発しましたよ」と彼は言った。「ミドルウェアのライセンス料が丸々浮きましたからね」。エンジニアは2人、そのうち1人は業務を兼任するパートタイムだった。6か月後、彼はパニック状態で電話してきた。ECプラットフォームがAPIのフィールドを変更し、パートタイムのエンジニアは辞め、新しく入った社員は古いコードを読めず、受注が2日間止まった。そのせいで大口の顧客を失った。たった2日間の損失は、数年分のミドルウェアのサブスクリプション料を上回っていた。
どの倉庫もいずれこの判断に直面する。受注はマーケットプレイスから流れ込み、送り状はキャリアから戻ってこなければならず、3PLの顧客は在庫の可視化を求め、大手の小売顧客はEDIを要求してくる——発注書の850、出荷通知の856、アルファベットスープのフルコースだ。問題は、連携するかどうかでは決してない。誰が作業を担い、本当のコストはいくらか、ということだ。
自社開発で最も安いのは「作る」部分である
多くの倉庫がこの判断を誤るのは、作るコストしか見積もらないからだ。エンジニア2人、2か月、APIはつながり、みんなで「浮いた」ライセンス料を祝う。その計算はフィクションだ。
自社開発の連携の本当のコスト構造は、おおむね開発が3割、保守が7割——そして保守は終わらない。プラットフォームはAPIを改訂する。キャリアは証明書を更新する。EDIの仕様は微調整される。午前3時にアラートが鳴っても、対応できる人間はいない。外部の変化はすべて計画外の開発スプリントになる。一度きりのエンジニアリング案件を買ったつもりが、実際に買っているのは自分の名前がついた長期の負債だ。
より鋭いリスクは人にある。自社開発の連携スタックにおける単一障害点は、サーバーではなく、そのコードを書いた人間だ。そしていつか必ず辞める。辞めれば、ドキュメントのないブラックボックスと、上流で何かが変わった日に止まる事業が残る。
ミドルウェアが実際に売っているもの
ミドルウェアも慈善事業ではない。誰もが聞いたことのあるiPaaS製品——MuleSoft、Boomi、Celigo、Workato——は3回請求してくる。契約する前に3つの金額をすべて書面で取っておくべきだ。1つ目はサブスクリプションで、接続数やデータ量に応じた段階制。料金は定期的に変わるので、ベンダーの最新の公開料金で確認し、口約束を信じてはいけない。2つ目は導入で、ベンダーのコンサルタントは日単価で請求し、中程度の複雑さの連携は見積もりの2倍の期間がかかるのが常だ。3つ目は、そして最も見落とされるのが、ロックインだ。業務ロジックが彼らのビジュアルフロー作成ツールの中に住み着いたら、移行には莫大なコストがかかる。
だから、何を買っているのかはっきりさせよう。ミドルウェアは安いのではない——リスクを外注しているのだ。プラットフォームがAPIを変更すれば、ベンダーがコネクターを適応させる。午前2時に何かが壊れれば、エスカレーションできるサポートチームがいる。午前3時の電話が自分のものにならないためにお金を払っているのだ。
契約の前に、もう1つ罠を指摘しておこう。プロセスのマッピングをベンダーのコンサルタントに外注してはいけない。自社のワークフロー——受注がどこから来て、例外は誰が処理し、在庫の正はどのシステムか——は、設定を始める前に社内で固めておかなければならない。プロセス設計を丸ごとコンサルタントに渡し、現場の実態と合わない設定で稼働させ、やり直しに2回払った倉庫を私は見てきた。コンサルタントはツールを知っている。ビジネスを知っているのはあなただけだ。
私の3つの譲れないライン
ここ数年で私が定めた3つの経験則を紹介する。どれか1つに当てはまったら、自分で連携を開発すべきではない。
1つ目：連携ポイントが5つを超える。マーケットプレイス、ERP、キャリア、EDI、顧客ポータル——追加のエンドポイントごとに、保守の複雑さは線形ではなく指数関数的に増える。人が頭の中で保持できるのはせいぜい5つまでだ。それを超えたら、プラットフォームのツールが必要になる。
2つ目：フルタイムの連携エンジニアが2人いない。「フルタイム」と「連携エンジニア」という言葉に注目してほしい。「手伝える開発者」ではない。パートタイムで保守している自社開発の連携はいずれ必ず失敗する。問題はいつか、だけだ。
3つ目：事業がまだ速く変化している。今年はShopify、来年はTikTok Shop、その翌年は大手顧客からのEDI。連携の対象自体が不安定なときに、カスタムコードのやり直しコストがあなたを溺れさせる。ミドルウェアのコネクターライブラリはまさにこのためにある——既製のコネクターを有効化するのは、ゼロから書くより一桁安い。
逆もまた真なりだ。自社開発すべきなのは3つすべてが真のときだけだ。エンドポイント数が無期限に2〜3で留まり、業務ロジックが本当にカスタムで、ミドルウェアでは表現できない方法を取っている——変わった請求ルールが典型例だ——そして、どこにも行かない安定した連携エンジニアがいること。
それでも開発するというなら、2つの譲れない条件
正当な理由があって開発する倉庫もある。いいだろう。だが私には2つの要件があり、どちらも欠かせない。
1つ目、ドキュメントと引継ぎ手順書がコードと一緒に出荷されること。作者が去る前に、他の誰かがその連携を読み、修正し、独立してデプロイできなければならない。1人しか理解できないシステムは資産ではなく、時限爆弾だ。
2つ目、すべての外部呼び出しにサーキットブレーカーとリトライを付け、すべての受注ペイロードは再実行可能でなければならない。プラットフォームのAPIはしょっちゅうつまずく。リトライがなければ、タイムアウト1回が受注1件の消失であり、ピークシーズンの受注消失は、マーケットプレイスからのペナルティや激怒した最終顧客へと連鎖しかねない。再実行可能性がなければ——「もし」ではなく「いつ」——何かが失敗したときに回復の道がない。これは最低ラインであり、天井ではない。
明日にでもできることが1つある。紙1枚に、自社が持つシステム連携ポイントをすべて書き出して数えてみよう。5つを超えたら、今週中にミドルウェアベンダー3社とデモを予約する。5つ未満だが保守が1人のパートタイムなら、それでもデモを予約する。受注が止まる日を待って、この計算を一度もしていなかったことを悟るような真似はしないことだ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
