ベンダーとは?意味と語源、メーカー・サプライヤーとの違い、ITベンダーの7分類を発注者目線で解説

「その件はベンダーに確認します」——会議でこの一言が飛び交うが、ベンダーが何を指しているのか、実のところよく分からない。そう感じている方は少なくありません。辞書を引くと「売り手」と出てきます。ところが社内で「ベンダー」と呼ばれているのは、システムを作って納めてくる会社です。売り手なのか、作り手なのか。この食い違いが、この言葉を分かりにくくしている正体です。

先に結論を書きます。ベンダーとは、製品やサービスを販売・提供する事業者を指す言葉です。英語の vendor が語源で、vend は「売る」という意味の動詞。自動販売機を vending machine と言うのと同じ語です。そしてIT業界では、この語が広がって、自社で開発している会社も含め、発注先の会社全般を指すようになりました。だから「作る会社」もベンダーと呼ばれます。

この記事では、まず語義と業界ごとの用法を押さえ、次にメーカー・サプライヤー・ディストリビューター・SIerといった紛らわしい言葉との位置関係を整理します。そのうえで、ITベンダーを出自と提供の形の2軸で分類し、最後に発注する側として最初に確認したい3つのことを書きます。用語を覚えて終わりではなく、見積もりを読むときに使える形にするのが狙いです。

私はTALENTBASE VIETNAMでCOOを務めています。人材業界の出身で、同じ言葉が業界ごとに違うものを指す現象は、転職市場の用語でも何度も見てきました。2018年からホーチミンに拠点を置き、約100社の開発体制づくりをお手伝いしてきましたが、商談の場で「御社はベンダーですか」と聞かれることがあります。当社は2,000名以上のIT人財データベースから直接アサインしているので、売り手であり作り手でもある。この二重性こそ、ベンダーという語が抱える性質そのものです。

読み終えたら、手元の提案書や見積書を1枚だけ開いてみてください。確認するのは「この会社は作っているのか、売っているだけなのか」の一点です。ここが分かると、価格の根拠も、不具合が出たときの窓口も、契約が終わったあとに何が残るのかも、読み方が変わります。

ベンダーとは——製品やサービスを売る側を指す言葉。IT業界では発注先そのものを指す

ベンダーとは、製品やサービスを販売・提供する事業者を指す言葉です。自社で製造しているかどうかは問いません。売る側に立っている事業者であれば、ベンダーと呼ばれます。そしてIT業界では、この語がさらに広がり、システムやソフトウェアを提供する取引先の会社全般を指す言い方として定着しました。まずは語源から順に見ていきます。

語源は英語の vendor——「売る」の名詞形

ベンダーは英語の vendor をそのままカタカナにした語です。vendor は「売る」という意味の動詞 vend と同じ語根をもつ語で、Merriam-Webster によれば、アングロフランス語の vendour(vendre「売る」)を経て、ラテン語の vēndere(売る)にさかのぼります。直訳すれば「売る人」で、古くは行商人や露天商を指す語でした。そこから問屋や供給会社にも使われるようになり、現在の「販売業者」という意味に落ち着いています。

身近なところでは、自動販売機を vending machine と言います。vend に -ing が付いた形で、「売っている機械」という成り立ちです。日本では、この自動販売機を設置・運営する会社を単に「ベンダー」と呼ぶ慣習があり、飲料業界の求人票などでいまも使われています。同じ語根から出た言葉だと分かると、業界ごとの用法の広がりも納得がいきます。

表記については、「ベンダー」と「ベンダ」の両方を見かけます。これは同じ語の表記ゆれです。工業規格や技術文書では語尾の長音を省く慣習があり、そちらでは「ベンダ」と書かれます。一般のビジネス文書やWeb記事では「ベンダー」が多数派です。どちらを使っても間違いではありませんが、1つの文書の中では統一しておくと読み手が迷いません。英語で書く場合は vendor です。vender という綴りも Merriam-Webster に vendor の異綴りとして掲載されていますが、ビジネス文書では vendor が一般的です。

業界によって指すものが変わる

ベンダーがややこしいのは、業界によって「どの位置にいる会社」を指すかが変わる点です。語義そのものは「売る側」で一貫していますが、その業界で売られているものが違うため、結果として指す相手が変わります。

飲料業界では、先ほどの自動販売機の設置・運営会社を指します。食品業界では、小売店や飲食店へ商品を納入する会社です。自動車業界では部品やアクセサリーを供給する会社、建設業界では資材や建設機械を納める会社、医療業界では医療機器や医薬品を提供する会社を指します。そしてIT業界では、ハードウェア、ソフトウェア、クラウドサービス、システム開発といったIT関連の製品・サービスを提供する会社を指します。

私は人材業界の出身です。転職市場でも、同じ言葉が業界ごとに違うものを指す現象は何度も見てきました。言葉の意味を1つに固定しようとすると、かえって使えなくなります。「売る側を指す語である」という軸だけ覚えておいて、あとは業界ごとに何が売られているかで読み替える。この読み方のほうが実用的です。

IT業界では「作る会社」もベンダーと呼ぶ

ここが最大のつまずきどころです。語義は「売る人」なのに、IT業界で「ベンダー」と呼ばれている会社の多くは、実際にはシステムやソフトウェアを作っています。自社で開発したパッケージを売る会社も、一から受託で開発する会社も、まとめてベンダーです。実際、IPA(情報処理推進機構)の「情報システム・モデル取引・契約書(第二版)」も、発注する側を「ユーザ」、システムを提供する側を「ベンダ」と呼び、受託開発をする会社をベンダと位置づけています。つまり実務の文書では、作っているかどうかではなく、発注者から見た立場で呼び分けられています。

なぜこうなったのか。IT業界では、発注者(ユーザー企業)から見て「こちら側」と「あちら側」を区別する必要が先にあったからだと私は考えています。自社の外にいて、自社にITを提供してくる相手。それを役割としてひとまとめに呼ぶ語が必要で、そこにベンダーが当てはまった。作っているかどうかは、呼び方を決める基準にならなかったわけです。

当社は商談の場で「御社はベンダーですか」と聞かれることがあります。この質問に一言で答えにくいのは、まさにこの二重性のためです。当社は2,000名以上のIT人財データベースからエンジニアを直接アサインしているので、売り手であると同時に作り手でもあります。一方で、同じ「オフショア開発のベンダー」という肩書きでも、受注してから外部の協力会社に人を集めてもらう会社もあります。呼び方は同じ、中身は別。この違いを見分ける話は、あとの章で扱います。まずは、紛らわしい言葉との位置関係を片づけておきます。

メーカー・サプライヤー・ディストリビューター・SIerとの違い——立ち位置で整理する

ベンダーの周りには、似た意味に見える言葉が並んでいます。メーカー、サプライヤー、ディストリビューター、SIer、ユーザー企業。これらを1語ずつ辞書的に覚えようとすると、かえって混乱します。原材料から最終利用者までの流れを1本の線で描き、その線のどこに立っているかで整理すると、一度で頭に入ります。

メーカーとの違い——作る人か、売る人か

もっとも多い疑問がこれです。原則から言えば、メーカーは作る会社、ベンダーは売る会社です。メーカーは製品を企画・設計・製造する立場で、ベンダーはその製品を利用者に届ける立場。役割が違うので、本来は並列に比べる言葉ではありません。

ただしIT業界では、この2つが重なることが非常に多くあります。自社でソフトウェアを開発し、自社で販売し、自社でサポートまで行う会社は、メーカーでありベンダーでもある。だから現場では、両方の語がほぼ同じ意味で使われる場面が生まれます。本記事では、開発元が別にいる場合に限って「メーカー」と呼び分け、重なっている場合は呼び分けない、という整理で読み進めてください。

発注する側にとって実務的に効くのは、呼び方ではなく事実のほうです。この会社は自社で作ったものを売っているのか、他社が作ったものを売っているのか。前者なら仕様変更や不具合修正の判断が自社内で完結しますが、後者なら製造元に照会が必要になり、回答までの時間が変わります。

サプライヤー・ディストリビューターとの違い——供給の位置

サプライヤー(supplier)は「供給する側」を指す語です。ベンダーとほぼ同義で使われることもありますが、日本のビジネス文脈では、原材料や部品を他社に供給する会社を指す使い方が一般的です。自動車メーカーに部品を納める会社をサプライヤーと呼び、完成した自動車を消費者に売る会社をベンダーと呼ぶ、という具合に位置が分かれます。つまりサプライヤーは製造の前工程側、ベンダーは完成品の販売側に寄った語です。

ディストリビューター(distributor)は「流通させる側」です。メーカーと販売店の間に立ち、輸入・在庫・配送・販売代理を担う卸の位置にあります。IT業界では、海外メーカーのソフトウェアライセンスを国内で扱う代理店がこれに当たります。ディストリビューターから仕入れて利用者に売る会社も、その利用者から見れば「ベンダー」です。

ユーザー企業(エンドユーザー)は、買って使う側です。IT業界では、供給する側をITベンダー、使う側をユーザー企業と呼び分ける言い方が定着しています。ここで注意したいのは、この呼び分けが会社の属性ではなく、取引上の位置で決まることです。

SIer・ユーザー企業との関係——呼び方は立場で決まる

SIer(システムインテグレーター)は、複数の製品や技術を組み合わせて、業務で使えるシステムとして構築・導入する会社です。企画から開発、運用、保守まで一連の工程を請け負う形が典型で、発注者から見れば「システム全体の売り主」ですから、SIerもベンダーの一種として扱われます。SIerは「何をするか」を表す語、ベンダーは「取引上どちら側か」を表す語で、そもそも分類の軸が違うと考えると整理しやすくなります。

ここまでを1つの表にまとめます。

表の見方でひとつ補足します。同じ会社が、場面によって違う呼ばれ方をします。たとえば、クラウド基盤の上に業務システムを作って販売している会社があるとします。この会社は、顧客から見ればベンダーであり、SIerでもあります。同時に、クラウド事業者から見ればユーザー企業です。さらに、その会社がデータベース製品を仕入れて組み込んでいれば、データベースの開発元にとっては販売チャネルの一部にもなります。

当社も同じです。お客様から見れば当社はベンダーですが、当社がAWSを使えばAWSにとって当社はユーザー企業になります。「ベンダー」という語に、上下関係や会社の格を読み込む必要はありません。取引上、どちら側に立っているかを示すだけの中立な言葉です。呼び方は属性ではなく位置で決まる——これが隣接語をまとめて理解する鍵になります。

ITベンダーの種類——出自による3分類と、提供の形による4分類

ITベンダーの分類は、多くの解説記事で「システムベンダー」「ソフトウェアベンダー」「ハードウェアベンダー」「セキュリティベンダー」と並べられます。覚えること自体は簡単ですが、この並べ方では相見積もりを比べるときに使えません。提案書には、どの会社も「ITベンダー」と書いてくるからです。ここでは、発注先として見たときに何が違うのかという軸で、2通りの分け方を示します。

出自で分ける3分類——メーカー系・ユーザー系・独立系

1つ目の軸は、その会社がどこから生まれたかです。日本のIT業界では、この出自が提案の傾向をかなり強く決めます。

メーカー系は、ハードウェアやソフトウェアのメーカーを親会社に持つ会社です。自社グループの製品に関する知見が深く、大規模な基盤構築に強みがあります。反面、提案は自社グループの製品を軸に組まれやすくなります。

ユーザー系は、事業会社の情報システム部門が分社化して生まれた会社です。金融、通信、商社、製造といった親会社の業務に精通しており、業務要件の理解が早い。ただし親会社の案件が優先されることがあり、繁忙期のリソース確保が読みにくい場合があります。

独立系は、特定の親会社を持たない会社です。製品の縛りがないため、複数メーカーの製品を横断して選べます。規模は数名から数千名まで幅が広く、得意領域も会社ごとに大きく異なります。

この3分類は、提案書に書かれていないことを推測する材料になります。特定製品を強く勧められたときに、それが技術的な結論なのか、出自から来る傾向なのかを一度考えてみる。それだけで質問の仕方が変わります。

提供の形で分ける4分類——SIer・受託開発・SaaS/パッケージ・オフショア

2つ目の軸は、何をどう提供するかです。発注者にとっては、こちらのほうが直接効きます。誰が作り、誰が責任を持ち、契約が終わったあとに何が残るかが、この分類でほぼ決まるからです。

表のとおり、同じ「ITベンダー」でも、実装する主体と契約終了後に残るものがまったく違います。SaaSを選べば作る手間は要りませんが、自社仕様への作り込みはできません。受託開発なら作り込めますが、作った後の保守を誰が担うかを決めておく必要があります。

当社が支援した介護記録SaaSのCareViewerでは、日本語対応のブリッジSE1名とフルスタックエンジニア2名という体制で、製品そのものの継続開発を担いました。SaaS事業者から見れば当社は開発リソースの提供元であり、エンドユーザーの介護事業所から見れば、ベンダーはCareViewerを提供している会社です。同じシステムでも、見る位置によってベンダーが誰かは変わります。

シングルベンダー・マルチベンダー・ベンダーロックイン

分類に関連して、3つの言葉を押さえておきます。

シングルベンダーは、特定の1社の製品だけでシステムを構成する方式です。組み合わせの検証が済んでいるため動作が安定しやすく、障害時の窓口も1つで済みます。マルチベンダーは、複数社の製品を組み合わせる方式です。用途ごとに最適な製品を選べ、価格交渉の余地も生まれますが、障害時にどの製品が原因かの切り分けに手間がかかります。どちらが優れているという話ではなく、安定と選択肢のどちらを取るかという設計判断です。

ベンダーロックインは、特定のベンダーを使い続けざるを得ない状態を指します。公正取引委員会が2022年2月8日に公表した「官公庁における情報システム調達に関する実態調査」では、ソフトウェアの機能改修やバージョンアップ、ハードウェアのメンテナンスなど、情報システムを使い続けるために必要な作業を、それを導入した事業者以外が実施できないために、特定のシステムベンダーを利用し続けなくてはならない状態、と定義されています。

誤解されやすいのですが、この状態そのものが違法というわけではありません。同報告書は、仕様書への自社機能の組み込み、仕様開示やデータ移行の拒否、一括発注の強要、極端な安値応札、ベンダー間の受注調整という5つの行為類型について、独占禁止法上問題となり得る場合を整理しています。あわせて、これらの行為を受けた経験があると回答した官公庁の割合は、行為類型ごとに0.5%(ベンダー間の受注調整)から3.9%(仕様書への自社機能の組み込み)でした(いずれも有効回答数1,009)。民間の発注でも構造は同じで、悪意がなくても、仕様が特定の会社の頭の中にしかない状態が続けば、結果として依存は生まれます。乗り換えと引き継ぎの具体的な進め方については「開発会社の乗り換えと引き継ぎ」の記事にまとめてあります。

さて、ここまでで地図はできました。手元の提案書に並んだ会社は、どの分類に入りますか。

発注者から見たベンダーとの付き合い方——最初に確認する3つのこと

分類の地図ができても、目の前の1社がどこに入るかは、聞かなければ分かりません。提案書の自己紹介はどの会社も似ています。ここでは、初回の打ち合わせで確かめておきたい3つのことを挙げます。3つとも、専門知識がなくても聞ける質問です。

何を頼むかを先に決める——会社名より前にやること

順番を間違えている相談を、これまで何度も見てきました。候補の会社を先に集め、それから何を頼むかを考え始めるパターンです。これをやると、比較の土俵が作れません。会社ごとに得意な範囲が違うので、範囲が決まっていないと、各社が自分の得意な形に寄せた提案を出してきます。結果として、金額も前提もバラバラの提案書が並ぶことになります。

先に決めるのは範囲です。要件定義から任せるのか、要件は自社で固めて実装だけ出すのか。運用と保守はどちらが持つのか。作りたいものが既存のSaaSで足りるのかどうかも、この段階で一度は検討しておく価値があります。範囲が決まれば、前章の4分類のうちどれに相談すべきかが自然に絞れます。評価軸の作り方、面談で聞くこと、見積もりの比べ方といった選定の実務については「システム開発会社 選び方」の記事で詳しく扱っていますので、そちらをご覧ください。

実装するのは誰か——商流を1問で確かめる

2つ目は、実際にコードを書くのは誰かという質問です。「実装を担当するのは御社の社員ですか、協力会社ですか。協力会社の場合、何次まで入りますか」。この一問だけで、見積もりの読み方が変わります。

自社で実装する会社と、受注してから外部に再委託する会社では、同じ金額でも中身が違います。間に会社が入るほど、エンジニアに渡る単価は下がり、発注者と実装者の距離は遠くなります。仕様の確認が何段階も伝言される体制では、修正の反映にも時間がかかる。この構造と、見積もりのどこに現れるかについては「オフショア開発 中間マージン」の記事で詳しく整理しています。

再委託が認められているかを契約書で見る

3つ目は契約書です。再委託に関する条項が、ほぼどの業務委託契約書にも入っています。見るのは、再委託が禁止されているのか、事前の書面承諾が必要なのか、包括的に認められているのかという3点です。ここが包括承諾になっていると、発注者の知らないところで実装体制が変わることがあります。

禁止すればよいという話でもありません。一部の専門工程を外部に出したほうが品質が上がる場面もあります。承諾方式の選び方や条項の書き方は「業務委託契約 再委託」の記事にまとめてありますので、契約書を前にしている方はそちらを参照してください。

当社の位置づけと、向く案件・向かない案件

最後に、当社自身がどのベンダーなのかを書いておきます。当社TALENTBASE VIETNAMは、ベトナム・ホーチミンを拠点とするオフショア開発会社です。2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインする形をとっており、協力会社や紹介を経由する仲介マージンがありません。前章の分類で言えば、オフショア開発会社であり、実装する主体は当社が契約している人財です。

単価は公開しています。実務3年目安で1,500USD(1USD=150円換算で約22.5万円)、5年で2,000USD、ブリッジSEで3,000USD。当社調べで市場相場の約1/2です。最小構成は日本人PMがフロントに立ち、2〜3人月で月額約80万円から。1名から契約でき、最短2週間で開始、増員は約1週間、縮小や交代は1か月単位で対応します。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストを使ったコードレビューの標準化、リリース前のダブルチェックの3点を標準の手順にしています。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

向かない案件も正直に書きます。CMMIなどの認証を必須とする大規模基幹システムの一括構築、数十名規模のチームを一斉に立ち上げる案件は、当社の規模では向きません。大手のSI系ベンダーにご相談いただくほうが確実です。逆に、小規模から継続的に開発していく、仕様が動く、日本語で細かく詰めたいという案件は当社の得意領域です。

ここまでを踏まえて、手元の提案書を1枚開いてみてください。「作っているのか、売っているだけなのか」「実装は誰か」「再委託はどうなっているか」。この3つに印をつけるだけで、その会社との付き合い方の見通しが立ちます。

ベンダーに関するよくある質問

最後に、当社に届く質問のうち、ベンダーという言葉そのものに関するものを5つ取り上げます。短く答えます。

Q1. ベンダーは英語でどう書きますか。「ベンダ」との違いは何ですか

英語では vendor と書きます。「売る」という意味の vend と同じ語根の語です。vender という綴りも Merriam-Webster に異綴りとして掲載されていますが、ビジネス文書では vendor が一般的です。「ベンダ」と「ベンダー」は同じ語の表記ゆれで、工業規格や技術文書では語尾の長音を省く慣習があるため「ベンダ」と書かれます。一般のビジネス文書では「ベンダー」が多数派です。

Q2. 取引先を「ベンダーさん」と呼ぶのは失礼にあたりますか

失礼にはあたりません。取引上どちら側に立っているかを示す中立的な語で、上下関係を含む言葉ではありません。ただし、相手が自社を「開発パートナー」「協力会社」と名乗っている場合は、その呼称に合わせたほうが会話が滑らかになります。社内の会議では「ベンダー」、相手との打ち合わせでは会社名で呼ぶ、という使い分けをしている企業が多い印象です。

Q3. ベンダーロックインは避けるべきものですか

避けるべきなのは「意図せず抜けられなくなっている状態」であって、特定ベンダーとの継続取引そのものではありません。長く付き合うことで業務理解が深まる利点は確実にあります。問題になるのは、ソースコードや設計書が手元になく、他社が見積もりすら出せない状態です。契約の時点で、著作権の帰属、成果物の引き渡し範囲、解約の予告期間を決めておけば、依存の度合いは大きく下げられます。

Q4. SaaSを使っている場合、ベンダーは誰になりますか

そのSaaSを提供している事業者がベンダーです。自社で開発していても、他社の基盤の上に構築していても、利用者との契約当事者がベンダーになります。確認しておきたいのは、解約時に自社のデータをどの形式で取り出せるかという点です。ここが曖昧なまま数年使うと、移行の検討そのものができなくなります。

Q5. 小規模な開発でも、オフショアのベンダーに相談できますか

相談できます。当社の場合は1名から契約でき、最短2週間で開始、増員は約1週間が目安です。最小構成は日本人PMがフロントに立ち、2〜3人月で月額約80万円から。要件が固まっていない段階でのご相談も承ります。合わない案件と判断した場合は、その旨と、どのタイプのベンダーに当たるべきかのご提案。

まとめ: ベンダーは「売る側」を指す語——発注では「作っているのか、売っているだけなのか」から確かめる

ベンダーとは、製品やサービスを販売・提供する事業者を指す言葉です。語源は英語の vendor で、vend は「売る」という意味の動詞。自動販売機を vending machine と呼ぶのと同じ語根です。業界によって指す相手は変わり、飲料業界では自動販売機の設置・運営会社、食品業界では小売店への納入業者、そしてIT業界ではIT関連の製品・サービスを提供する取引先全般を指します。「ベンダ」と「ベンダー」は同じ語の表記ゆれで、どちらも間違いではありません。

紛らわしい隣接語は、供給の流れの上に並べると一度で整理できます。作るのがメーカー、原材料や部品を供給するのがサプライヤー、卸として流すのがディストリビューター、利用者に売るのがベンダー、複数製品を組み合わせて業務システムに仕立てるのがSIer、買って使うのがユーザー企業。ここで押さえておきたいのは、この呼び分けが会社の属性ではなく、取引上の位置で決まるということです。同じ会社が、ある相手にはベンダーで、別の相手にはユーザー企業になります。ベンダーという語に上下関係を読み込む必要はありません。ITベンダーの分類は、出自(メーカー系・ユーザー系・独立系)と提供の形(SIer・受託開発・SaaS/パッケージ・オフショア)の2軸で見ると、実装する主体と契約終了後に残るものの違いが見えてきます。特定の一社を使い続けざるを得ない状態はベンダーロックインと呼ばれ、公正取引委員会も2022年2月8日公表の実態調査で定義と行為類型を整理しています。

発注する立場でこの記事を読んでくださった方へ。用語の理解は、見積もりを読む道具にしてはじめて役に立ちます。初回の打ち合わせで確かめるのは3つです。第一に、何を頼むかの範囲。要件定義から任せるのか、実装だけ出すのか、既存のSaaSで足りないのか。範囲が決まらないと、各社が自分の得意な形に寄せた提案を出してきて、比較の土俵が作れません。第二に、実装するのは誰か。「コードを書くのは御社の社員ですか、協力会社ですか。何次まで入りますか」という一問で、同じ金額の中身が見えます。第三に、再委託の条項。禁止か、事前承諾か、包括承諾か。ここが包括になっていると、知らないうちに実装体制が変わることがあります。選定の評価軸と面談の質問はシステム開発会社の選び方、見積もりに商流がどう現れるかはオフショア開発の中間マージンにまとめてあります。当社TALENTBASE VIETNAMは、2,000名以上のIT人財データベースから直接アサインするオフショア開発会社です。仲介マージンがないため単価を公開しており、実務3年目安1,500USD(1USD=150円換算で約22.5万円)、最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、どのタイプのベンダーに当たるべきかを含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。