はじめに
2026年度に新卒エンジニアとして入社した、たてけんです。
ペパボの開発では日々の業務でデータベースに触れる機会が多くあります。その土台となるDBモデリングを学ぶため、2026年度の新卒エンジニア研修では、igaigaさんをお招きし、特別講義を開催しました。
当日は、DBモデリングの講義と、図書館の蔵書貸出管理を題材にした演習、そして「AI時代の（設計に関する）成長戦略」の講義という構成でした。この記事では、参加した新卒エンジニアそれぞれの視点から、当日の学びをお届けします。
igaigaさんによる過去のワークショップの様子は、『DBモデリングとRSpecのワークショップを行いました』をあわせてご覧ください。
- はじめに
- 講師紹介：igaiga（五十嵐邦明）さん
- なぜigaigaさんをお招きしたのか
- 講義：DBモデリング
- 演習：図書館の蔵書貸出管理を設計する
- 講義：AI時代の（設計に関する）成長戦略
- みんなの感想
- おわりに
講師紹介：igaiga（五十嵐邦明）さん
講師を務めてくださったigaiga（五十嵐邦明）さんは、Ruby・Railsを専門とするエンジニアです。『パーフェクトRails』『Railsの教科書』『Railsの練習帳』など、多くのエンジニアが学びの入り口にしてきた著書を執筆されています。今回の講義や演習も、igaigaさんが公開されている『Railsの練習帳』のDBモデリング基礎講座をもとに進めていただきました。加えて、「AI時代の（設計に関する）成長戦略」と題した講義もしていただきました。
なぜigaigaさんをお招きしたのか
新卒エンジニア研修を担当した、はるおつです。
ペパボの新卒エンジニア研修では、ここ数年igaigaさんにDBモデリングの特別講義をお願いしています。 実際に動き、見た目がそれらしいものをすぐに作るということは、AIエージェントの台頭によってますます容易になっています。一方で数年先を見通したDBモデリングについては、今はまだ人間がAIと並走して適切に判断する力を求められている領域だと感じています。
Railsチュートリアルを終えたばかりの新卒エンジニアには、現実のユースケースからテーブルを洗い出す進め方を学ぶことが、配属後の設計の土台になると考えました。そこで『Railsの練習帳』をもとにした、講義と演習の両方をお願いしました。
AIを使いながらDBモデリングをおこなう時に、「使うだけ」にとどまらない人材となるために、以下3点を習得・体得することを目標としました。
- 説明責任を持てる力: AIが出力したコードやスキーマを受け入れるだけでなく、自ら理解・評価・説明できる状態になること。
- AIに代替されない判断力: データベース設計の基本的な考え方・モデリング手法を習得し、AIの出力に対して適切にレビュー・判断できること。
- 長期的視点を持った設計思想の養成: 10年・100年先を見通した持続可能な設計ができる判断力を育てること。
講義：DBモデリング
GMOペパボ16th新卒エンジニアのmaruと申します。7月からEC事業部へ配属され、カラーミーショップ byGMOペパボの開発に携わっています。まずは当日最初のプログラム、igaigaさんによるDBモデリング講義を紹介します。
「誰が・何を」から名詞を洗い出す
講義で印象的だったのは「モデリングとは、現実世界をコンピュータの世界で扱えるようにするための設計」という言葉です。いきなりカラム名や型を考えるのではなく、扱いたい現実から「誰が・何を」という名詞を洗い出してテーブルの候補にし、テーブル同士の関連を結んでER図にしていく。この進め方を知ってから演習に臨めたのは大きかったです。講義の終わりには検索インデックスの仕組みについての質問が飛ぶなど、質疑も盛り上がりました。
講義中はSlackのスレッドでも実況や質問が飛び交っていました。当日の熱量が伝わる様子を少しだけご紹介します。
当日のSlackスレッドの様子
講義で学んだ「誰が・何を」でテーブル名を出していく進め方は、そのままコードの可読性の話でもあります。後半の「AI時代の成長戦略」の講義では、良い名前や規約は人間の認知負荷を下げるという話がありました。それを聞いて「AIがコードを読む時代でも、この規約はAIへ同じように効くのだろうか」と、AI時代の設計について考えるきっかけになりました。
演習：図書館の蔵書貸出管理を設計する
GMOペパボ16th新卒エンジニアのkimataです。ここでは当日の演習、図書館の蔵書貸出管理のDBモデリングを紹介します。
演習では、図書館の蔵書貸出管理システムを題材に、講義で学んだ進め方を使って各自でテーブル構成を考え、ER図を作成しました。最後に全員で発表し合い、igaigaさんからコメントをいただきました。
実際にモデリングした図の例として、kimataとkeiのER図を並べてみます（上: kimata、下: kei）。同じ課題でも、人によって設計が分かれているのがわかります。
モデリングで一番悩んだ点
一番悩んだのは「本」の扱いです。図書館には同じ本が何冊も置いてあります。たとえば「坊っちゃん」という作品は1つですが、棚にある「坊っちゃん」は3冊あるかもしれません。この「作品としての本」と「棚にある1冊1冊」を同じテーブルで扱うと、どの1冊を貸し出したのかを記録できません。そこでAIと相談しながら、作品（books）と1冊ごとの実物（book_copies）にテーブルを分けました。実際、貸出（loans）は1冊ごとの実物を、予約（reservations）は作品を参照する形になり、「借りるのは1冊、予約するのは作品」という現実の動きをそのまま表せました。
book_copies というテーブル名は AI の提案をそのまま受け入れて決定しました。命名としては通じるものだと思いますが、あとで自分のER図を見返したとき、copy という語に「蔵書の1冊」というより「複製」のような違和感が残りました。1点・1冊を表現できる item を使った book_items の方が自分はしっくりきます。AIの力を借りると設計のたたき台を素早く作れる一方、最終的に判断するのは自分です。そのため、テーブル名ひとつのような細部にも「なぜこうしたのか」を自分の言葉で説明できるように心がけたいです。
みんなの発表を聞いて感じたこと
発表では、みんな AI の力を借りて設計したこともあって、似たテーブル名や ER 図の多さが印象に残っています。そのなかで同期のしんの設計だけ大きく違いました。append-only（イベントソーシング）と呼ばれる考え方で、貸出の状態を更新するのではなく、貸出や返却をイベントとして追記していきます。自分は知らない設計手法でした。
こうした手法を身につけていれば、AIの提案をそのまま受け入れる前にほかのやり方と比べて検討できたはずです。AI時代においても、設計手法も含めて技術を学んでいくことの大切さを実感しました。
講義：AI時代の（設計に関する）成長戦略
GMOペパボ16th新卒エンジニアのkeithと申します。普段の開発ではAIにコードを書いてもらう場面が多く、「このままで技術力が身につくのだろうか」と漠然とした不安を持っていたので、この講義はまさに自分ごとでした。
「遭遇率が上がる」＝成長チャンス
igaigaさんに「AI時代の（設計に関する）成長戦略」についてお話しいただきました。AIが元気よくコードを書いてくれる時代になり、人間がコードを書きながら学ぶ時間は減っていく。一見ネガティブな話に思えますが、igaigaさんの見方は前向きでした。AIによってコードベースの成長・老化のスピードが上がった結果、設計上の欠陥や過去の設計と現状のミスマッチが早く顕在化し、自分がプロジェクトを離れる前に設計上の問題と出会える確率はむしろ上がっている。「RPGで言えば敵との遭遇率が上がって経験値を得やすくなっている」という例えが印象的で、「設計上の問題に早く多く出会える＝成長チャンス」という視点は自分にとってとても新鮮でした。
AIが出した設計を「評価する」側へ
また、これからの私たちに求められるのは「AIが出した設計を理解して評価すること」だというお話も心に残りました。まずはAIのおかげでたくさん見られるようになった設計事例（＝Pull Request）を読み込み、疑問に思ったことを設計した人やAIに聞いてみるところから、設計の「経験値」を積んでいきたいです。
みんなの感想
講義・演習を受けた新卒エンジニアそれぞれの感想を紹介します。
keith
DBモデリング研修の講義を通じて、DB構築に関する多くの知識を学びました。さらに実践課題として、図書館を題材にテーブル設計とER図の作成に取り組みました。主キーの選び方やテーブル間のリレーションなどを自分の頭で考えることで、DBへの理解と印象が一層深まりました。
kimata
AI時代だからこそ設計上の問題に早く多く出会えることが成長のチャンスになるという視点が新鮮でした。実際に図書館システムを題材にDBモデリングを行った際も、自分で試行錯誤しながらテーブル構成を考えることの大切さを実感しました。今後もこうした実践を積み重ねて、設計の判断力を磨いていきたいと思います。
kei
モデル設計の際に「誰が、何を」を考えてテーブル名を出すとか、テーブル同士の関連を入れるなど、具体的なノウハウを知れたことが学びの1つです。印象的なのは、良い設計ができているとはチーム全員が大体同じような設計に合意できている状態だという言葉です。常に最良の設計はないので、現在のコードの状態、チームの状態などの文脈も設計時に考慮しないといけないなと考えました。
maru
図書館システムの課題では、「作品の情報」と「物理的な1冊」をテーブルとして分けるかどうかなど、正解が1つじゃない判断を自分の頭で試行錯誤しました。設計の判断は自分で手を動かさないと身につかないなと感じました。命名と可読性のお話を聞きながら「人間の認知負荷を下げる規約は、AIが読むときにも効くのだろうか」と考えていて、AI時代の設計を考えるきっかけになりました。
のーら
「モデリングとは現実世界をコンピュータの世界で扱えるようにするための設計」であるという言葉が印象的でした。テーブル設計と言われるとつい、すぐにカラム名や型などの細部を考えてしまっていたのですが、大前提として「現実の何をコンピュータで扱いたいのか」を捉える必要があることを知りました。実際、蔵書貸出管理のDBモデリング演習では、「本」という現実の存在を作品（種類）としての本と物理的な1冊に分ける発想が必要でした。ここで、現実の解像度を上げてDBモデリングをすることの重要さを体験しました。
なかなか思うようにできなくて、igaigaさんに「普段どういう順番で考えていますか？」と質問してみました。すると、UIの画面遷移や物理的なものの移動、そこから発生する情報の動きなど、色々な視点から考えることがあると教えていただきました。
AIが何でもやってくれる今だからこそ、やり方を考える機会は非常に重要であり、貴重であるとも思います。この講義で学んだことは今後に活かしていきます！igaigaさん、ありがとうございました！
ゆっきー
自分は大学図書館を題材にDBモデリングを考えました。みんなの感想にもあったように、「本」という1つの言葉でも、作品としての本と図書館に所蔵されている物理的な1冊を分けて考える必要がありました。現実世界をどう切り取るかが設計の難しさだと感じました。特にレビューが現実世界に即した（加味した）レビューになる必要があるため、AIでの自動化もなかなか難しいなと思いました。
しん
演習では個性を出したくて、やったことのないappend-only（イベントソーシング）設計に挑戦しました。実は昔、意味も分からずカラムへJSONを突っ込んでいたことがあって、講義後にigaigaさんへ正規化と非正規化のトレードオフを質問しました。自分の雑な設計に「検索しないデータならJSONもあり、ちゃんと機能化する時は設計し直す」という条件付きの名前をつけてもらえたことが、いちばんの収穫でした。
おわりに
今回の研修では、DBモデリングの講義と演習、そして「AI時代の成長戦略」の講義を通して、正解が1つではない問いに手を動かしながら向き合いました。その中で実感したのは、AIが出してくれた設計をそのまま受け入れるのではなく、自分で理解して、なぜその形にしたのかを説明できることの大切さです。演習で全員の発表を聞き、同じ課題でも設計が分かれるのを見たからこそ、「自分はこう考えたから、こうした」と言えることが設計の第一歩なのだと感じました。
ここでの学びは、配属後の業務にも早速活きています。テーブルを設計する場面で、いきなりカラムや型を考えるのではなく、「誰が・何を」から名詞を洗い出し、現実の何を扱いたいのかを先に固めてから手を動かせるようになりました。AIが設計案を出してくれる時代だからこそ、それを評価するための軸を自分の中に持てたことが、何よりの収穫だったと感じています。
最後になりますが、講義と演習を通してたくさんの学びをくださったigaigaさんに、心より感謝申し上げます。ありがとうございました！
