// シス担のミカタ
発注の基本

ユーザー企業 ゆーざーきぎょう

発注者ベンダー企業IT調達情報システム部門システム発注甲乙
ユーザー企業って何？

簡単に言うとこんな感じ！

ITシステムを「買う側・使う側」の会社のことだよ！ソフトウェアを作って売るメーカーじゃなくて、そのシステムを導入して業務に使う立場の企業のこと。要するに「お客さん側の会社」ってイメージでOK！

ユーザー企業とは

ユーザー企業とは、ITシステムやソフトウェアを自社の業務に活用するために導入・利用する企業のことを指します。システムを「作って売る」側ではなく、「買って使う」側の立場です。製造業・小売業・金融業・官公庁など、業種を問わずITを業務に取り入れているあらゆる組織がユーザー企業にあたります。

IT業界では、ユーザー企業に対してシステムを提供する企業をベンダー企業（またはITベンダー）と呼びます。契約書の文面では、ユーザー企業が「甲」（発注者）、ベンダーが「乙」（受注者）と表記されることが多く、この甲乙関係がIT調達の基本的な構図です。

「情シス（情報システム部門）が強い会社じゃないとユーザー企業じゃないの？」と思うかもしれませんが、そんなことはありません。専任のIT担当者がいなくても、クラウドサービスを業務に使っている会社はすべてユーザー企業です。この辞典を読んでいるあなたの会社も、間違いなくユーザー企業の一つです。

ユーザー企業の立場と役割

IT調達の現場では、ユーザー企業とベンダー企業がそれぞれ異なる役割を担っています。

観点ユーザー企業（甲）ベンダー企業（乙）
主な役割要件を定義し、発注・検収・運用するシステムを設計・開発・納品する
責任範囲業務要件の明確化・予算管理技術的な実装・品質保証
契約上の呼称甲・発注者・クライアント乙・受注者・ベンダー
専門性業務知識（業務ドメイン）IT技術知識
成果物の帰属多くの場合、著作権の交渉が必要開発したシステム・ソースコード

「ユーザー」という言葉の意味

「ユーザー」は英語で「利用者」を意味します。IT文脈では「システムを使う人・組織」を指し、個人レベルでは「エンドユーザー（end user）」とも呼ばれます。ユーザー企業はその企業版、つまり「組織としてITを使う側」という意味です。

社内体制のパターン

ユーザー企業内でIT調達を担う部門・人物はさまざまです。

  • 情報システム部門（情シス）がある企業 — 専任チームが要件定義・ベンダー選定・保守管理を一手に担う
  • DX推進部門がある企業 — デジタル化推進の観点から新規システム導入をリード
  • 事業部門が主導する企業 — 現場の業務部門が直接ベンダーと交渉し、情シスはサポートに回る
  • 総務・管理部門が兼務する企業 — 中小企業に多く、IT専任者がいない状態で発注を行う

歴史と背景

  • 1960〜70年代 — 大型コンピューター（メインフレーム）の導入が始まり、大企業が「コンピューターを使う側」として登場。この頃から「ユーザー企業」という概念が生まれた
  • 1980年代 — パソコンの普及により中小企業もITを導入。ユーザー企業の裾野が広がる
  • 1990年代 — ERPパッケージ（SAPなど）の登場で、業務システムを「買う」文化が定着。社内SEという職種が一般化
  • 2000年代 — インターネット普及によりWebシステム発注が増加。ユーザー企業のIT投資が急拡大
  • 2010年代 — クラウドサービス（SaaS）の台頭で、システムを「持つ」から「借りる」へシフト。小規模な企業でも容易にITを導入できる時代に
  • 2020年代 — コロナ禍によるDX加速で、ほぼすべての企業がユーザー企業化。IT部門を持たない企業でも、業務部門が直接クラウドサービスを選定・契約する「シャドーIT」問題も顕在化

ユーザー企業とベンダー企業の関係図

IT調達では、ユーザー企業とベンダー企業が明確な役割分担のもとで協働します。

ユーザー企業（甲） 経営層・事業部門 情報システム部門 DX推進部門 発注・要件定義・検収 業務ドメイン知識が強み 発注・要件定義 納品・保守サポート ベンダー企業（乙） プロジェクトマネージャー システムエンジニア（SE） プログラマー・デザイナー 設計・開発・テスト・運用 IT技術知識が強み

「甲乙」を覚えるコツ

契約書で迷いがちな「甲乙」の覚え方：「甲（こう）＝高（こう）い立場＝お金を払う発注者」と覚えましょう。発注者のユーザー企業が甲、受注者のベンダーが乙です。

ユーザー企業が発注時に直面しやすい課題

ユーザー企業の立場でIT調達を進める際には、特有の難しさがあります。

課題内容対策のヒント
要件定義が曖昧「何を作りたいか」を言語化できない業務フローを図式化してからRFPを書く
ベンダーとの情報格差技術的な提案を評価する知識が乏しい第三者のITコンサルを活用する
スコープクリープ開発中に要望が膨らみ、予算・工期が超過変更管理プロセスを契約に明記する
検収の難しさ納品物が「完成」かどうか判断できない受入テスト（UAT）の基準を事前に決める
保守・運用の引き継ぎベンダー依存が続き、自社にノウハウが残らないドキュメント納品・ソースコード開示を契約に入れる

関連する規格・RFC

※ ユーザー企業とベンダーの契約関係・調達プロセスに関連する国内外のガイドラインを参照。

規格・ガイドライン内容
共通フレーム2013（SLCP-JCF 2013）IPAが定めるソフトウェア開発・取引の共通枠組み。ユーザーとベンダーの役割分担を規定
情報システム・モデル取引・契約書（IPA）ユーザー企業とITベンダーの取引を適正化するためのモデル契約書

関連用語