要約

  • FastlyはIngram Microとの提携を、同社にとってシンガポール初の流通契約と位置付け、再販業者・SIerへのアクセス、研修、技術支援、販売支援を説明している。
  • その発表は、個別顧客の契約相手、実装者、最初のサポート窓口、障害対応の責任者、請求条件やSLAを公表していない。
  • 購入者は新しい商流を歓迎できるが、それを完全な運用引受と見なす前に、行為ごとの責任分担を確認する必要がある。

買える経路と、任せられる運用は同じではない

9月1日のFastlyの発表は、Ingram Microとの提携をシンガポール初の流通契約と説明する。Fastlyのエッジ・プラットフォームを、Ingram Microの再販業者とシステムインテグレーターのネットワークを通じて利用できるようにし、研修、技術イネーブルメント、Go-to-market支援も掲げる。地域の企業にとって、製品を評価し専門家に接触する入口が増えることには商業的な意味がある。

しかし、入口は責任表ではない。公開文書は、ある顧客に誰が契約上販売するか、誰が設定を導入するか、誰が本番変更を許可できるか、どこに最初のチケットを出すか、誰がベンダーへエスカレーションするかを示していない。価格、割引、マージン、独占、導入済み顧客数、特定のサービス水準も公表していない。

これは両社への批判ではない。そうした条件は顧客、流通事業者、再販業者、SIerの間で締結される個別契約に置かれることがある。ここで避けるべきなのは、流通の開始を運用責任の移管と読み替えることだ。購入先を知っていても、夜間の障害時に誰が何をするかは分からない。

「パートナー」という語は役割を一つにしない

Fastlyのチャネル・パートナー・プログラムは、紹介、再販、サービス提供を分けている。紹介パートナーには取引、実装、サービス管理が求められないとし、再販については再販売、流通、購買履行に触れる。また、特定の高度なセキュリティ製品を実装・管理するパートナー向けには技術認定を説明している。

これはシンガポール契約の条件ではなく、Ingram Microや下流の再販業者が全ての機能を担う証拠でもない。それでも、パートナーという肩書だけで運用上の問いに答えられない理由を示す。同じプラットフォームでも、商談を作る会社、注文を受ける会社、導入する会社、日常運用する会社、Fastlyが支援する層は別々でありうる。

顧客は自社に設定と承認を残し、商流と助言だけを利用できる。一度限りの導入を買うことも、継続運用を委託することもできる。Fastlyへの技術問い合わせとアプリケーション監視を異なる相手に委ねる設計もありうる。発表はこのどれかを約束していないため、読み手が補うべきでもない。

流通が増えても、サービスの層は残る

Fastlyは顧客サポートで、サポートプラン、専門家への接触、セルフサービス資料、オンボーディングやプロフェッショナルサービスの支援を別のものとして示す。Managed CDNでは、顧客の私設ネットワークに置く構成を、顧客のインフラチームと設計し、定常監視、保守、Fastlyの支援を伴う形として説明する。

これらのページは新提携における分担を決めない。ただし、プラットフォームへのアクセス、サポート、専門的な作業、私設網での管理運用が一つのサービスに自動的に溶けるわけではないことを示す。通常のCDNを使う顧客と、私設のマネージド構成を採る顧客では、必要な権限と障害時の経路が異なることがある。

したがって「ローカルサポート」は分解して確認すべきである。販売前の研修なのか、一次切り分けなのか、設定支援なのか、ベンダーケースの調整なのか、継続管理なのか。どれも価値がありうるが、発表の語から別の義務を作り出すことはできない。

発注書に添えるべき運用地図

短い責任表でよい。顧客、契約販売者、流通事業者、導入パートナー、Fastlyの直接の役割を並べ、アカウント管理、本番資格情報、設定変更、セキュリティ方針の承認、監視、一次対応、エスカレーション、障害連絡、ログへのアクセス、更新、終了を行為ごとに割り当てる。

重要なのは、実行できる権限と、結果に責任を負う立場を分けることだ。SIerが導入しても、半年後に本番を変更する権限を持つとは限らない。再販業者が注文を処理しても、サービスを運用するとは限らない。Fastlyがプラットフォームを支援しても、顧客アプリケーションの正しさを引き受けるとは限らない。日常作業を委託しながら顧客が最終承認を保持することも可能である。

確認すべき試験は実際のチケットを想定することだ。誰が受け、いつ引き渡し、誰が変更でき、誰が顧客へ説明するのか。商流についても、誰が販売・更新し、その注文にどの価格と救済が適用されるのかを問う。流通契約だけでこの答えは出ない。

現時点で推測せず、後に確認できること

共同のサービス提案、適用範囲が明記された認定、顧客事例、サポート層の明示、共有されたエスカレーション手順が出れば、役割はより読めるようになる。発表に書かれていないことは、それらが存在しない証拠ではない。ただし、既に確立した事実として書く根拠にもならない。

AI、クラウドネイティブ、APIへの言及も需要文脈として読むべきだ。それは特定のAIワークロード、容量増強、遅延改善、顧客の耐障害性向上を示すものではない。購入の根拠は、顧客が委ねる実際の作業と、手にする契約条件に戻る。