ER図とは？初心者でもわかる基本の読み方と目的

ER図とは、業務で扱う情報の実体(エンティティ)と実体同士のつながり(リレーションシップ)を図で整理する設計手法です。1976年に提唱されて以来、データベース設計の基礎として使われてきました。本記事はコンサルタントの歩み編集部の独自調査に基づき、記号の読み方から要件定義フェーズでの実務的な使い方まで、発注者や非エンジニアにも説明できる基礎を整理します。

ER図とは何か—業務で使われる目的を整理する

ER図は、データの実体と関係を図式化し、システム開発の土台となるデータ構造を関係者間で共有するための設計図です。

ER図(Entity Relationship Diagram、実体関連図)は、業務で扱う「顧客」「注文」「商品」といった実体(エンティティ)と、実体同士のつながり(リレーションシップ)を図で表現する手法です。この考え方は1976年にPeter Chen氏が発表した論文「The Entity-Relationship Model」で提唱されたもので、以来データベース設計の基礎的な手法として広く使われています。目的は、システムを作り始める前に「どんな情報を、どんな単位で、どうつなげて管理するか」を関係者全員で共有し、開発途中の手戻りを防ぐことにあります。

データベース設計における位置づけ

ER図は、要件定義で洗い出した情報を概念設計・論理設計・物理設計へと具体化していく起点に位置づけられます。

データベース設計は一般的に、業務上の情報を整理する「概念データモデル」、テーブルや項目の形に落とし込む「論理データモデル」、実際のデータベース製品の仕様に合わせる「物理データモデル」という3段階で進みます。ER図はこの最初の概念データモデルの段階で作成され、後工程である論理設計・物理設計の精度を左右する起点となります。

なぜコンサルタントもER図を理解すべきか

ER図を読めると、開発ベンダーの説明を鵜呑みにせず、要件定義の抜け漏れを自分の目で確認できるようになります。

コンサルタントの歩み編集部が要件定義・PMO業務に携わる独立コンサルタントを対象に行った独自調査では、非エンジニアの立場でプロジェクトに参画する際、ER図を読み解けないために開発ベンダーの説明を検証できず、要件の認識齟齬に気づくのが遅れたという声が複数聞かれました。ER図の基礎を押さえておくことは、発注者側の代弁者として要件定義を主導する立場のコンサルタントにとって、案件の質を左右する実務スキルのひとつだと言えます。

ER図に登場する基本記号とその読み方

ER図は主に、四角形(エンティティ)・項目名の並び(属性)・線(リレーションシップ)という3種類の記号で構成されます。

それぞれの記号が何を表すのか、実際の業務データに近い例で確認します。

エンティティ・属性・リレーションシップの意味

エンティティは管理対象の実体、属性はその実体が持つ情報項目、リレーションシップは実体同士のつながりを指します。

エンティティは「顧客」「注文」「商品」のように管理対象となるまとまりを指し、四角形の記号で表します。属性はエンティティが持つ個々の情報項目で、「顧客」であれば顧客ID・氏名・メールアドレスなどが該当し、エンティティの中に項目名として書き込まれます。リレーションシップはエンティティ同士のつながりを示す線で、たとえば「顧客」と「注文」の間には「1人の顧客が複数の注文を行う」という関係が引かれます。以下は架空の業務を想定したER図の記載例です。

カーディナリティ(多重度)の表記ルール

カーディナリティは、1つの実体に対して相手の実体がいくつ対応するかを1対1・1対多・多対多の3パターンで表します。

「顧客」と「注文」の関係のように、1人の顧客が複数回注文できる場合は「1対多」、1つの注文に1つの請求書が必ず1件だけ紐づく場合は「1対1」、「商品」と「注文」のように1つの注文が複数の商品を含み、1つの商品が複数の注文に登場する場合は「多対多」と表記します。多重度は線の両端に記号や数字を書き添えて表現し、実体同士の関係の強さや必須・任意の区別を示します。

ER図の代表的な表記法の違い

同じER図でも、IE表記法とIDEF1X表記法では線や記号の描き方が異なり、混在させると誤読を招きます。

代表的な2つの表記法の違いを整理します。

IE表記法とIDEF1X表記法

IE表記法は「鳥の足」に似た記号で多重度を表し、IDEF1X表記法は米国の標準規格として策定された経緯を持つ表記法です。

IE表記法(Information Engineering表記法)は、線の先端が枝分かれした「鳥の足」に似た記号でカーディナリティを表現する方法で、実務やWeb上の解説記事でもよく見られます。一方のIDEF1X表記法は、1993年12月に米国国立標準技術研究所(NIST)がFIPS Publication 184として制定した表記法で、実線・破線と端点の丸印の組み合わせでエンティティ同士の関係と多重度を表現します。IDEF1Xはその後2012年にISO/IEC/IEEE 31320-2として国際規格に統合されており、公的な標準に基づく表記法という位置づけです。どちらの表記法が優れているというより、プロジェクトやツールによって採用されている表記が異なる点を理解しておくことが実務上は重要です。

表記法選定で発注者と認識をそろえる方法

表記法そのものより、記号の意味を示す凡例をあらかじめ共有しておくことが認識齟齬を防ぐ近道です。

発注者や非エンジニアの担当者は、IE表記法とIDEF1X表記法の名称までは把握していないケースがほとんどです。ER図をレビューする打ち合わせの冒頭で「四角はデータのまとまり、線の分岐は関係の多さを表す」といった凡例を1枚用意して説明する、線の意味を都度言葉に置き換えて確認する、といった工夫を積み重ねることで、表記法の違いに関わらず認識をそろえやすくなります。

要件定義フェーズでER図が果たす役割

要件定義の成果物として概念ER図・論理ER図を位置づけることで、後工程での手戻りを防ぎやすくなります。

情報処理推進機構(IPA)が公開する「超上流から攻めるIT化の事例集」では、要件定義フェーズの成果物のひとつとして「概念ERD」「論理ERD」「データ項目定義書」が挙げられており、データに関する要件を整理する手段としてER図が位置づけられています。またIPAの「共通フレーム2013」では、要件定義プロセスに国際規格ISO/IEC/IEEE 29148の考え方を取り入れており、要件を体系立てて整理する重要性が示されています。ER図はこうした要件定義プロセスの中で、業務要件をデータの形に翻訳する役割を担います。

発注者・非エンジニアへの説明で使う際の工夫

専門用語をそのまま使わず、業務上のものの名前に置き換えて説明すると、非エンジニアにも伝わりやすくなります。

「エンティティ」「カーディナリティ」といった用語をそのまま使うと、非エンジニアの発注者には伝わりにくくなります。「エンティティ」は「管理したい情報のまとまり」、「カーディナリティ」は「1件に対していくつ紐づくか」のように業務上の言葉に置き換えて説明する、実際の業務データを1〜2件だけ当てはめて具体的にイメージしてもらう、といった工夫が有効です。ER図の記号の読み方を体系的に整理した記事もあわせて参照すると理解が深まります。

要件漏れを防ぐチェックの視点

すべてのエンティティと属性が、どの業務要件に対応するかを逆引きできるかを確認することが要件漏れの発見につながります。

ER図をレビューする際は、図に描かれたエンティティや属性のひとつひとつが「どの業務要件から生まれたものか」を逆引きできるかを確認する視点が有効です。逆に、要件定義書に書かれている業務プロセスの中に、ER図のどのエンティティにも対応しない情報が残っていないかを突き合わせることで、要件の描き漏れに気づきやすくなります。要件定義書などのドキュメント管理を含めた運用ルールを整えておくと、この突き合わせ作業も効率化しやすくなります。

ER図とほかの設計図(DFD・UML)との違い

ER図はデータの構造、DFDは情報の流れ、UMLはシステムのふるまいや構造を表す図であり、それぞれ目的が異なります。

設計工程では複数の図法を組み合わせて使うため、それぞれの役割を切り分けて理解しておくことが重要です。

それぞれの図が担う役割の切り分け

3つの図はいずれも設計工程で使われますが、扱う対象が「データの形」「情報の流れ」「システムの振る舞い」に分かれます。

DFD(データフロー図)は、業務やシステムの中でデータがどのプロセスからどのプロセスへ流れるかを表す図で、情報の「流れ」に焦点を当てます。UML(統一モデリング言語)は、クラス図やシーケンス図など複数の図法の総称で、システムを構成するオブジェクトの構造や振る舞いを表現する目的で使われます。これに対しER図は、データそのものの構造、つまり「何と何がどう紐づくか」を表す図であり、3つの図は互いに置き換えられるものではなく、それぞれ異なる観点から設計を補い合う関係にあります。

独立コンサルタントがER図を理解しておくメリット

ER図を読み解ける独立コンサルタントは、開発ベンダーと対等に会話でき、案件内の信頼を得やすくなります。

最後に、独立後のキャリアという観点からER図理解の意味を整理します。

PMO/PM案件での信頼構築につながる場面

設計成果物を自分の目で確認できることは、資格と並んで案件内の信頼構築につながる実務スキルです。

PMO/PMとしての専門性を示す手段として、PMP(Project Management Professional、PMI認定)のような資格を取得しておくと、スキルシート上で説明しやすいという声はよく聞かれます。もっとも、単価や評価を最終的に決めるのは資格の有無よりも実務経験であり、プロジェクトの規模や担当したフェーズ、体制の大きさが重視される点は変わりません。ER図をはじめとする設計成果物を自分の目で確認できることは、資格の有無にかかわらず、開発ベンダーや発注者から実務担当者として信頼を得るための土台になります。システム開発全体の流れを押さえておくと、ER図が工程のどこで作られる成果物なのかもあわせて理解しやすくなります。

ER図の基礎を押さえておくことは、要件定義フェーズの精度を高め、PMO/PM案件での信頼構築にもつながります。本記事は2026年9月時点の情報に基づいています。

出典・参考情報

1. Peter Chen「The Entity-Relationship Model - Toward a Unified View of Data」書誌情報（2026-09-08参照）
2. IPA(情報処理推進機構)「超上流から攻めるIT化の事例集：要件定義」（2026-09-08参照）
3. IPA(情報処理推進機構)「SEC BOOKS：共通フレーム2013」（2026-09-08参照）
4. IDEF公式サイト「IDEF1X – Data Modeling Method」（2026-09-08参照）
5. PMI日本支部（PM/PMO関連資格に関する一次情報、2026-09-08参照）

本記事は2026年9月時点の情報に基づいています。