ポートフォリオの作り方

データベース設計（ER図）を作品に組み込む方法

生田 陸人
監修
LuaGate エンジニア / 現役エンジニア
編集 LuaGate編集部

このレッスンで分かること

  • この記事では「データベース設計（ER図）を作品に組み込む方法」を ポートフォリオ作成 の現場で使える形で整理します
  • データベース設計（ER図）がポートフォリオの評価を左右する理由 をおさえれば、現場で迷ったときに立ち戻れる
  • データベース設計（ER図）の基本とポートフォリオでの重要性 をおさえれば、現場で迷ったときに立ち戻れる
  • なぜポートフォリオにER図が必要なのか？ をおさえれば、現場で迷ったときに立ち戻れる
  • 良いER図の3つの条件 をおさえれば、現場で迷ったときに立ち戻れる

データベース設計（ER図）を作品に組み込む方法 とは

エンジニアのポートフォリオで高く評価されるデータベース設計（ER図）の作り方を解説。評価されるポイント、おすすめ作成ツール、GitHub READMEへの効果的な掲載方法まで、実践的なノウハウが学べます。

データベース設計（ER図）がポートフォリオの評価を左右する理由

エンジニアとして就職・転職活動を行う際、ポートフォリオで最も注目されるポイントの一つが「データベース設計（ER図）」です。多くの初学者の方は、ついつい「動く画面」や「最新のフロントエンド技術」に目を奪われがちですが、採用担当者や現役エンジニアは「裏側のデータ構造がどうなっているか」を非常に重視します。

結論先出し — ポートフォリオは見た目よりデータ構造で評価されます。ER図を1枚添えるだけで、「設計を考えて作っている人」として一段上に見られるのが実情です。

なぜなら、データベース設計にはエンジニアとしての「論理的思考力」と「ビジネスモデルへの理解力」が凝縮されているからです。適切に設計されたデータベースは、システムの拡張性や保守性を高めます。逆に、設計が破綻していると、どんなに見た目が良くても「実務では通用しないコード」と判断されてしまうリスクがあります。

このレッスンでは、ポートフォリオのクオリティを一段階引き上げるための、効果的なER図の作り方と、それをREADME（作品説明）に組み込む具体的な方法を解説します。

データベース設計（ER図）の基本とポートフォリオでの重要性

ER図（Entity Relationship Diagram）とは、データのまとまり（実体＝エンティティ）と、その繋がり（関連＝リレーションシップ）を視覚化した図のことです。

diagram (will load when visible)

なぜポートフォリオにER図が必要なのか？

  1. データの整合性を説明できるは重複データがなく、正しいルールでデータが保存されていることを示せます。
  2. 複雑な機能の実装能力を証明できるは例えば「多対多」のリレーション（例：ユーザーとグループ）を正しく扱えることは、技術レベルの証明になります。
  3. コミュニケーションコストを下げるは図解があることで、面接時に「このテーブルとこのテーブルはどう繋がっていますか？」という説明をスムーズに行えます。

良いER図の3つの条件

  • テーブル名とカラム名が適切であるは誰が見ても中身が想像できる英語名を使っているか。
  • リレーションが正確であるは「1対多」なのか「多対多」なのかが明確であるか。
  • 主キー（PK）と外部キー（FK）が明記されているはどのカラムでデータを紐づけているかが一目でわかるか。

ポートフォリオ向け！ER図作成のおすすめツールと比較

ER図を作成するためのツールは数多くありますが、ポートフォリオで公開することを考えると、「見やすさ」と「共有のしやすさ」が重要です。代表的なツールを比較してみましょう。

ツール名特徴ポートフォリオへの活用方法
dbdiagram.ioコードベースで記述でき、見た目が非常に綺麗。URL共有や、画像として書き出してREADMEに貼る。
Mermaid.jsMarkdown内にテキストで図を書ける。GitHubのREADMEに直接テキストで埋め込む。
draw.io自由度が高く、フローチャートなども書ける。画像（PNG/SVG）として書き出して掲載する。
DBeaver / Sequel AceDB管理ツールから自動生成。実際のDB構造をそのままキャプチャする際に使用。

特におすすめなのは dbdiagram.io です。DSL（専用の言語）で記述するため、修正が容易で、リレーションの線が重なりにくく、非常にプロフェッショナルな印象を与えます。

実践的なデータベース設計のステップ

ポートフォリオを作る際、いきなりツールで図を描き始めるのではなく、以下のステップを踏むと失敗が少なくなります。

1. 必要な機能を洗い出す

例えば「SNSアプリ」を作るなら、「投稿する」「ユーザーがフォローする」「投稿にいいねする」といった機能が必要です。ここから「ユーザー」「投稿」「いいね」「フォロー」というエンティティが見えてきます。

2. テーブルとカラムを定義する

各エンティティが持つべき情報を書き出します。

  • users テーブル: id, name, email, password
  • posts テーブル: id, user_id, content, created_at

3. リレーション（関係性）を定義する

ここで最も重要なのが、「1対多（1:N）」なのか「多対多（N:M）」なのかの判断です。

  • 1対多は1人のユーザーは複数の投稿を持つ（User 1 → Post N）。
  • 多対多は1つの投稿は複数のタグを持ち、1つのタグは複数の投稿に使われる（Post N : Tag M）。この場合は、間に「中間テーブル」を作成する必要があります。

4. 正規化を行う

データの重複を避けるために「正規化」を行います。特に「第3正規形」まで意識して設計できていると、現役エンジニアから「基礎がしっかりしている」と高く評価されます。

ここまでの要約 — 機能洗い出し → テーブル定義 → リレーション → 正規化、の4ステップを 順番に 踏めば設計の破綻はほぼ防げます。図を描く前にこの順序を守るのがコツです。

DB設計は開発の土台です。ここを丁寧に作り込むことで、後のコーディングがぐっと楽になります。設計に迷ったら「このデータは重複していないか？」を自問自答してみましょう！

READMEでデータベース設計を魅力的に見せる方法

せっかく素晴らしいER図を作成しても、ポートフォリオのGitHubリポジトリの奥深くに隠れていては意味がありません。README.mdに効果的に配置しましょう。

1. セクションを設ける

「## データベース設計」という見出しを作り、そこにER図の画像を貼り付けます。画像だけでなく、「なぜこのような設計にしたのか」という意図を数行添えるのがポイントです。

2. Mermaid.jsを活用して「コード」として管理する

GitHubのREADMEはMermaid形式をサポートしています。以下のように記述すると、GitHub上で直接図が表示されます。

diagram (will load when visible)

これを行うと、DB設計の変更に合わせてREADMEも即座に修正できるため、「運用まで考えられている」という評価に繋がります。

3. テーブル定義書も検討する

小規模なアプリならER図だけで十分ですが、テーブル数が多い場合は、主要なテーブルの役割を簡単にテキストで補足しておくと親切です。

よくある失敗：こんなDB設計は低評価？

ポートフォリオで陥りがちな、アンチパターンを紹介します。

  • すべてのデータを1つのテーブルに詰め込むは「正規化」ができていないと、SQLの習得度が低いとみなされます。
  • 適切なデータ型を選んでいないは例えば、日付を string 型で保存していたり、金額を float 型（誤差が出る可能性がある型）で保存していると、実務経験のなさが露呈してしまいます。

良い例

SQL クエリ

-- 日付は適切な型を選択する CREATE TABLE posts ( id INT PRIMARY KEY, created_at TIMESTAMP );

避けたい例

SQL クエリ

-- 文字列型で日付を保存するのは避ける CREATE TABLE posts ( id INT PRIMARY KEY, created_at VARCHAR(255) );
  • 論理削除か物理削除かの考慮がないは実務ではデータを完全に消さずに「削除フラグ（deleted_at）」を持たせることが多いです。これを取り入れていると「実務を意識しているな」と感心されます。
  • インデックスの考慮がないは検索に頻繁に使うカラム（emailなど）に Unique Index を貼っているかどうかも、細かいですがチェックされるポイントです。

まとめ：ER図はあなたの「設計力」の証明書

データベース設計（ER図）をポートフォリオに組み込むことは、単に図を載せること以上の意味があります。それは、あなたが「システム全体の整合性を保ちながら、複雑な要件を整理できる能力」を持っていることを証明するプロセスです。

まずは dbdiagram.io や Mermaid を使って、今の作品のデータ構造を可視化してみましょう。そして、なぜそのテーブルが必要なのか、なぜそのリレーションを選んだのかを言葉にしてみてください。その積み重ねが、面接での説得力ある回答へと繋がります。

次は、この設計を元にどのように開発プロセスを記録していくか、タスク管理やテストの観点から学んでいきましょう。

現場でよくある具体例

  1. Aさん (受託企業内定) は GitHub の README 冒頭に「誰の何を解決するか」を 3 行で書き、デプロイ URL を最上段に置いた。それだけで書類通過率が 2 倍に
  2. Bさん (自社開発内定) は技術選定理由を README の「Why this stack?」セクションに明記。面接が「決定根拠の深掘り」中心になり、暗記質問が消えた
  3. Cさん (落選続き → 内定) はテーブルを切ってコミット履歴を整理。「feat: 機能追加」のような Conventional Commits に変えた途端、レビュー観点での評価が上がった

次にとるべきアクション

  1. 今のポートフォリオを採用視点で 30 秒見直す — README・デプロイ URL・スクショの 3 点が即座に伝わるか確認する
  2. 改善ポイントを GitHub Issue 化する — 「データベース設計（ER図）を作品に組み込む方法」で得た観点を、自分のリポジトリの Issue として 3 件登録する
  3. 実装/修正を次の 1 週間で完了させる — Issue を Pull Request に落とし込み、コミットメッセージにも改善理由を残す

次のレッスン

次は 開発プロセス（タスク管理、テスト）を記録する方法 で、開発プロセス（タスク管理、テスト）を記録する方法 を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

  1. DB設計 ER図 の要点を自分の言葉で説明できる
  2. このレッスンの最小コード (または操作手順) を見ずに書ける
  3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. DB設計 ER図 とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン

参考にした出典

学習を加速したい方へ

未経験エンジニア向けポートフォリオ作成ガイドを体系的にマスターするなら、chotdekiru の無料学習ポータル で実際に手を動かして学習を始めるのがおすすめです。質問・つまずきも現役エンジニアが伴走します。

復習ミニクイズ

SNSアプリで「投稿（Post）」と「タグ（Tag）」の関係を設計する際、1つの投稿に複数のタグを付け、かつ1つのタグが複数の投稿で使い回される「多対多」の構造を正しくER図に落とし込むには、どのような構成が必要ですか？

参考リンク