「SELECT 文の書き方は分かったみたいなんですが、なんでこのテーブル設計になっているのかは、まだ全然伝わってなさそうで…」。受託開発の現場で新人を教えるリーダーから、こういう相談をよく受けます。SQL の構文だけは覚えた、ER 図の読み方も研修で習った、それでも案件のテーブルを前にすると手が止まる。教える側からすると、「どこから直せば腹落ちするのか」が見えにくい状態です。
新人にデータベースを教えるとき、最初の1週間でやってはいけないのは、いきなり SQL 構文の練習問題を渡すことです。順序を間違えると、文法は覚えるのに業務でなぜそのデータがそうなっているかが永遠に分からない、という人が出てしまいます。本記事では、受託開発のシニア・リーダー向けに、新人 DB 教育を「SQL を書く前に見せるべき3つの視点」で設計し直す進め方を整理します。教える側の指導設計のたたき台として読んでください。
なぜ SQL 構文から教えると新人は伸び悩むのか
新人 DB 教育がうまくいかないとき、ほとんどのケースで原因は新人側ではなく、教える側の順序設計にあります。
SQL 構文から入ると、新人は「文法を覚える対象」として DB を扱い始めます。SELECT、WHERE、JOIN、GROUP BY を順番に練習すると、構文は書けるようになります。ところが案件に入った瞬間、テーブルが30個並んだ ER 図を渡されて、「このデータがどこから来てどこに使われるのか」を聞かれると、答えられません。
理由はシンプルで、構文の練習では「業務データがそこにある理由」を扱わないからです。書ける ≠ 設計が読める、です。教える側が SQL 構文を起点にカリキュラムを組んでしまうと、新人は文法から逆算してテーブルを見ようとするので、業務側からテーブルを見る視点が養われません。
もう一つのつまずきは、抽象用語の早出しです。「正規化」「トランザクション」「ACID」と最初の研修資料に書いてあると、新人はこれらを「覚えなければいけない用語」として処理します。意味は分からないが試験には出る、という扱いです。これでは、案件で「なぜここを正規化していないのか」「なぜここでトランザクションを切っているのか」を判断できる状態にはなりません。
教える側がやるべきなのは、SQL 構文の前に、新人の頭の中に「業務データを見るときの3つの視点」を作っておくことです。
最初の1週間で見せたい3つの視点
3つの視点は、業務データの流れ・正規化・トランザクションです。順序にも意味があります。
1つ目の視点：業務データの流れ（どこで生まれ、どこで使われるか）
最初に見せるのは、テーブル定義ではなく、データが業務のどこで生まれて、どの画面・帳票・連携先に流れていくか、という流れそのものです。
たとえば EC 案件なら、「注文データはユーザーが注文画面で確定した瞬間に生まれて、出荷管理画面で参照され、月次の売上集計バッチで集計され、会計システムへの連携 CSV にも出ていく」という、生まれてから使われ尽くすまでの一本の線を描きます。ホワイトボードで十分です。
この線が頭に入っていない状態で SQL を書くと、新人は「画面に出すために SELECT する人」になります。線が見えると、「このカラムは、いま画面のためだけに作られているのではなく、後段の集計とも整合させる必要がある」という発想が生まれます。テーブル設計の議論に新人を入れるための、最初の入口です。
教えるコツは、いま自分が関わっている案件の、ごく一部の業務だけを切り出して、A4一枚に手書きで流れを書かせることです。きれいな図は不要です。「自分の言葉で流れを言語化させる」ことが目的で、これができれば1つ目の視点は合格です。
2つ目の視点：正規化（なぜテーブルを分けるのか）
流れが見えたら、次に見せるのは正規化です。ただし、第1正規形・第2正規形・第3正規形の定義から入るのは、ほぼ毎回失敗します。
代わりに使うのは、「もし一つのテーブルにまとめてしまったら、業務でどんな事故が起きるか」という具体例です。注文テーブルに顧客の住所を毎回コピーして持たせていたら、住所変更があったとき、過去注文の住所をどう扱うかで揉めます。商品名を注文明細にコピーで持っていたら、商品名を直したときに過去明細の表示が変わってしまい、経理から問い合わせが来ます。
正規化は「データの責任の置き場所を分ける」考え方だ、と言い換えると新人に伝わりやすくなります。顧客マスタが顧客情報の責任を持ち、注文テーブルは「注文時点でどの顧客だったか」だけを参照として持つ。住所変更のときに過去注文の表示を当時のまま固定したいなら、注文時点の住所をスナップショットで持つ。この判断を、用語ではなく業務シナリオで教えます。
第3正規形まで暗記させる必要はありません。「業務上、どこに責任を置くか」を毎回問える状態になっていれば、現場の議論には参加できます。
3つ目の視点：トランザクション（なぜ整合性が必要か）
3つ目は、トランザクションです。これも定義から入らず、業務事故から入ります。
たとえば「在庫を1減らして、注文確定レコードを書き込む」という処理が、途中で落ちたらどうなるか。在庫だけが減って注文が残らない、あるいは注文が立ったのに在庫が減っていない、どちらも実害が出ます。「全部成功するか、全部失敗するか」を業務として選ぶ必要があるシーンが、世の中にはたくさんある、というのがトランザクションの出発点です。
ここまで来てはじめて、ACID やロックといった用語を「業務事故を防ぐための仕組み」として位置づけられます。新人にとっては、用語が「業務事故と紐づいた覚え方」で頭に入るので、忘れにくくなります。
3つの視点を、業務の流れ → 責任の分割 → 整合性の保証、という順序で見せると、新人の中に「業務 → 設計 → SQL」と上から下に降りていく筋道ができます。SQL 構文の暗記は、この筋道ができたあとで初めて意味を持ちます。
1週間の指導設計：Day1〜Day5 の組み立て方
3つの視点を、実際の1週間に落とすときの素案です。教える側の準備時間が取れない前提で、最低限の構成にしてあります。
- 1日目：担当案件の中から、業務フローを1本選んで、データの流れをホワイトボードで一緒に書く。SQL は触らない
- 2日目：そのフローに登場するテーブル2〜3個の定義を一緒に読む。「なぜ分かれているか」を業務シナリオで議論する
- 3日目：分かれていないと困るケース・分かれすぎていて困るケースを、過去の不具合チケットから1件ずつ拾って共有する
- 4日目：トランザクションの境界がどこに引かれているかを、実際のソースコードで一緒に追う。ACID は最後に名前を出すだけでよい
- 5日目：新人本人に、いまの案件のうち別の業務フロー1本を、3視点で言語化させて発表させる
この5日が終わってから、SQL の構文練習に入ります。順序を逆にしないことが、いちばん大事です。
属人化した OJT を仕組みに寄せる発想は、リーダーの評価設計と地続きの話でもあります。新任マネージャー側の整理は IT受託のマネージャーが最初につまずく評価面談と1on1 もあわせてどうぞ。
よくある失敗3パターン
教える側が陥りやすい失敗を、3つだけ挙げておきます。
- 自分が新人のときに使った教科書をそのまま渡してしまう。教科書は構文網羅型なので、業務文脈が抜けています。教えるための導線を別に作る必要があります
- 「正規化って何？」と聞かれて、第1〜第3正規形の定義を答えてしまう。新人にとっては別のテストの質問になり、業務に戻ってきません。必ず業務シナリオで返します
- トランザクションを「DB の機能」として教える。中身は「業務として全部成功か全部失敗かを選ぶ判断」であり、機能の話はその実装です。順序を逆にしないようにします
これらは、教える側の「自分が分かっているからつい近道で説明したくなる」気持ちから生まれる失敗です。新人の頭の中に視点を作る、という目的に立ち返ると避けられます。
教えたあとの自学導線をどう作るか
3つの視点を1週間で渡したあとは、新人本人が自分のペースで体系を埋めていける教材を渡すのが効率的です。指導する側がすべてを口頭で教え続けると、属人化が戻ってきます。
データベースそのものの体系学習には、図書館のたとえでテーブル設計・正規化・SQL 検索までを一気通貫で扱う 【IT基礎】データベース入門：図書館の仕組みでわかる保存・設計・SQLの基本 が、新人の自学導線として相性がよい構成になっています。本記事の3視点と地続きで、用語を業務感覚に紐づけて学べる作りです。
DB と並行して、要件定義書の読み方で新人がつまずくケースも多いはずです。そちらは 【IT基礎】要件定義の読み方入門：家を建てる設計図で学ぶ要件の構造 を渡しておくと、業務 → 要件 → DB という上流からの目線が育ちやすくなります。
まとめ
新人にデータベースを教えるとき、最初の1週間は SQL 構文の前に「業務データの流れ・正規化・トランザクション」の3視点を、業務シナリオで見せ切ることに集中します。順序を、業務の流れ → 責任の分割 → 整合性の保証、と固定するのがコツです。
教える側の整理ができたら、新人本人の体系学習は教材に任せます。指導側が3視点を渡し、教材が用語と構文を埋める。この役割分担で、属人化していた DB 教育が仕組みに寄っていきます。
新人の自学導線として渡せる体系教材としては 【IT基礎】データベース入門：図書館の仕組みでわかる保存・設計・SQLの基本 が、本記事の3視点と地続きで使えます。あわせて要件定義側の補強には 【IT基礎】要件定義の読み方入門：家を建てる設計図で学ぶ要件の構造 を組み合わせてください。