ベンダー
制作会社・サービス提供業者の総称。本書では「業者」とほぼ同義で使う。狭義には IT・Web の発注先(制作会社・SI・SaaS 提供者)を指すが、広く「外注先」全般を意味することもある。「ベンダーロックイン」「ベンダー管理」「マルチベンダー」のような複合語で登場する。
本書のスタンス(Lesson 3-1)は、業者選びの 3 軸 +α は「安全性 × 規模 × コントロール」+ AI 時代の「トレンド共有力」(Lesson 9-6)。「ベンダー」と呼ぶときの距離感を、「納品先」だけでなく「学習パートナー」「同じ船に乗るメンバー」として捉え直すのが本書の方針。
マルチベンダー運用(制作 / SEO / 広告 / インフラ / 解析を別社に発注)の現実:各ベンダーの責任範囲が曖昧になり、トラブル時に責任を擦り合う。事前に役割分担表 / RACI チャート / 連絡フローを 1 枚にまとめておかないと、運用品質が落ちる。本書では役割マップ([[role-map]])と意思決定マップ([[decision-map]])の併用を推奨。
落とし穴は、ベンダー依存度を測らない(切れない関係になっていることに気付かない)、ベンダーロックインに気付かず移管不能な仕様(独自 CMS / 独自フレームワーク)で組まれる、業者の社内体制変化(担当者離職・買収・体制変更)を把握しない、複数ベンダー連携の指揮系統が曖昧で工程衝突、業者を「下請け」扱いして温度感が下がる。
言葉をよく利用する人
- Web 担当者(発注側)
- プロデューサー
- ディレクター
- 情シス
- 法務 / 契約担当
会話上での使用例
複数業者の連携体制を組む場面
-
プロデューサー
制作 + SEO + 広告で 3 社に発注、コミュニケーションどうします?
-
Web 担当者
マルチベンダーになるので、役割分担表と週次定例を設けます。窓口は私で一本化、業者間の直接やりとりは「やった内容を私に CC」のルールでお願いします。トラブル時の責任範囲も契約書に明示で
ベンダーロックインの懸念を確認する場面
-
情シス
CMS が独自フレームワークで、ベンダー変更が不可能に近い
-
Web 担当者
次のリニューアル時に WordPress 等のメジャー CMS への移行を検討します。ベンダーロックインを解消するためにあえてリニューアルを早める判断もあり得ます