SQLアンチパターン読書会を半年間開催して見えてきたこと

はじめに

学生チーム所属の井田です。

私たちのチームでは、個人の知識・専門性の向上に加え、チーム全体の知識を実務で使える形に定着させること、そしてメンバー間のコミュニケーションを促進することを目的に、半年間にわたり技術書の読書会を実施してきました。

題材として選んだのは『SQLアンチパターン 第2版』です。

本書は、単なる SQL の書き方を解説するものではなく、「なぜその設計が問題になりやすいのか」「どのような背景でアンチパターンが生まれるのか」を豊富な事例とともに扱っており、日々の開発業務と親和性の高い一冊でした。

本記事では、読書会の運営方法、実際の議論内容、そして半年間を通して得られた学びについてご紹介します。

1. 読書会の目的と運用ルール

今回の読書会では、以下の2点を重視しました。

  • 技術書の内容を「理解する」だけで終わらせないこと
  • 各メンバーの経験や視点を交え、実務判断につながる形で議論すること

開催概要

  • 対象書籍：『SQLアンチパターン 第2版』 データベース設計・運用に直結するテーマとして、事前アンケートをもとに選定しました。
  • 開催頻度：週1回 業務への影響を抑えつつ、子育て中のメンバーなど多様な働き方にも配慮し、朝の時間帯に実施しました。
  • 形式：オンライン開催

進め方：その場で読む「30分＋30分」形式

継続性を最優先し、予習を前提としない形式を採用しました。

前半30分：読書と書き出し

  • 各自で該当章を読む
  • 共有ドキュメントに、印象に残った点や疑問、実務との接点などを記載

後半30分：ディスカッション

  • 進行役が章の要点を簡単に整理
  • 各自が気づきや経験を共有し、それを起点に議論

事前に読める場合は予習し、難しい場合でも当日の前半で内容を把握できるため、無理なく参加できる運用となりました。

2. 実際の読書会の一例：第8章「マルチカラムアトリビュート」

ここでは、読書会で扱った内容と議論の雰囲気が伝わるように、第8章を一例として紹介します。

テーマの概要

マルチカラムアトリビュートとは、1つの属性に対して、tag1, tag2, tag3 のように同種のカラムを複数並べて保持する設計です。

CREATE TABLE bugs (
  bug_id INT PRIMARY KEY,
  tag1 VARCHAR(50),
  tag2 VARCHAR(50),
  tag3 VARCHAR(50)
);

この設計は一見シンプルですが、検索条件の複雑化、更新処理の肥大化、要件変更時のスキーマ変更コスト増大など、長期運用で問題を引き起こしやすいとされています。 解決策としては、従属テーブルを作成し、1対多の関係を持たせることが推奨されています。

チーム内での議論と気づき

この章に関しては、現場のリアリティに基づいた活発な議論が交わされました。

  • 初期フェーズでの判断の難しさ

    0→1 の段階では柔軟さを優先し、結果的にアンチパターンへ進んでしまうケースがある。

  • 要件次第での許容判断

    表示数が固定され、増加しないことが明確な場合は、必ずしも即 NG とは言い切れないのではないか。

  • パフォーマンス・運用とのバランス

    正規化が理想でも、結合コストやインデックス設計を含めた現実的な判断が必要。

単に「アンチパターンだから避ける」と結論づけるのではなく、なぜその設計が選ばれやすいのか、どのような状況で許容されるのか、まで掘り下げて議論できる点が、チーム読書会の醍醐味だと感じています。

3. 現場経験から見えたアンチパターンの実態

この章では、読書会に参加したメンバーの実務経験をもとに、アンチパターンが実際の現場でどのような問題を引き起こし、そのときどのような判断や対応が求められたのかを紹介します。

※ いずれも参加者の過去の経験に基づくものであり、特定のプロダクトや組織を指すものではありません。

3-1. アンチパターンが招いた苦労

ランダム抽選機能の停止（第16章 ランダムセレクション）

「少しくらいなら問題ないだろう」として導入された ORDER BY RAND() は、データ量が少ないうちは問題として表面化しませんでした。

しかし、ユーザー数の増加に伴いフルテーブルスキャンが発生。 ランダム抽選機能は完全に停止し、業務・ユーザー対応の両面に影響が及びました。

大量の問い合わせ対応に追われる中で、最終的には、アプリケーション側で乱数を生成し取得する方式へ切り替える判断に。 冷や汗ものの改修でした。

一括購入処理によるシステムパンク（第2章 ジェイウォーク）

多対多の関係をカンマ区切りの文字列で保持していた DB 設計において、特定の利用ケースで想定を大きく超える件数のデータが一度に処理される事態が発生しました。

その結果、

  • カラム長の上限超過
  • 検索パフォーマンスの著しい劣化

といった問題が顕在化し、システム全体への影響が避けられない状況に。

設計を見直し、テーブル構造そのものを修正する判断を行いましたが、対象データはすでに億単位。データ移行・影響調査・段階的切り替えを伴う、大きな改修となりました。

3-2. 「あえて」採用して正解だったパターン

アンチパターンは必ずしも「絶対に避けるべきもの」ではなく、前提や制約を理解したうえで採用することで、現実的な最適解になるケースもあります。

固定数前提のマルチカラム設計（第8章 マルチカラムアトリビュート）

住所1・2、連絡先1・2など、最大数が明確に決まっており将来的に増えないことが保証されている項目については、あえて正規化せず1テーブルで管理しました。

JOIN を減らすことで SQL はシンプルに。 リソース制約のある環境では、結果として保守性が高まるケースもありました。

小規模な ENUM の利用（第11章 サーティワンフレーバー）

都道府県や性別など、変更頻度が極めて低く種類も限定的なデータについては、マスターテーブルを増やすより、ENUM やアプリ側の定数で管理した方が可読性が高まり、保守運用しやすいケースも有りました。

3-3. 「正しい設計」が招いたパフォーマンスの壁

アンチパターンを避け、「教科書通り」に設計した結果、別の問題に直面したケースも共有されました。

JOIN の増加と待機時間の合意（第17章 プアマンズ・サーチエンジン）

全文検索エンジンを使わず、正規化を徹底した SQL で検索を実装。 その結果、B2B 向けの巨大データでは JOIN が重なりすぎ、タイムアウトが頻発。

最終的には、

  • 複雑な分析系処理は夜間バッチ
  • 即時性を求めない画面では待機時間を許容

といった運用面での合意を行い、DB 負荷を抑える構成へ落ち着くケースもありました。

分割によるオーバーヘッド（第18章 スパゲッティクエリ）

巨大な SQL を分割した結果、N+1 問題やアプリケーションと DB 間の往復回数増加によりレスポンスが悪化。

最終的には、ある程度の複雑さを許容した単一クエリに戻し、実行計画とインデックスを最適化した方が高速だった、 というケースも紹介されました。

4. 開催してみての評価

朝開催による出席率と効果

読書会は、業務開始前の朝の時間帯に実施しました。
結果として、少人数ながらもほぼ固定メンバーを中心に、継続的に開催することができました。

参加メンバーの状況によっては、子育てや業務・作業を優先する必要があり、回によって出席人数が上下することもありましたが、

  • 参加できるときに参加する
  • 難しい場合は無理をしない

というスタンスを前提としていたことで、出席人数の増減に左右されることなく、開催自体を止めずに続けられたと感じています。

今後は、密度の濃い読書会を目指す姿勢は維持しつつ、関心を持ったメンバーが参加しやすい形で、少しずつ輪を広げていきたいです。

「30分読書＋30分議論」という時間配分のバランス

読書30分・議論30分という構成は、継続性の観点では機能していましたが、内容によってはバランスの難しさも感じました。

  • 章の内容が濃い場合
    → 30分で読み切る・要点を整理するのが難しい

  • 章の範囲を広げた場合
    → 議論が分散し、フォーカスしづらくなる

  • 章を絞りすぎた場合
    → 本全体としての進行スピードが落ちる

結果として、
一定のスピード感を保ちつつ、議論が深まりすぎず・浅すぎないバランスが重要だと感じました。

今後は、

  • 事前に「その章のどこを重点的に扱うか」を決める
  • 全章を網羅する前提ではなく、議論に向いている章を選んで扱う

といった運用も検討していきたいと考えています。

オンライン開催ならではの工夫と、良かった点・改善点

オンライン開催において特に意識したのは「その場で終わらせず、後から振り返れる形で残すこと」でした。

具体的には、

  • 共有ドキュメントにリアルタイムでメモを残す
  • Google Meet の自動文字起こしを活用する
  • 議事録や音声データを notebookLM に取り込み、要約や解説資料を生成する

といった工夫を行いました。

これにより、

  • 参加者自身が後から内容を整理できる
  • 参加していないメンバーにも共有できる
  • 読書会を個人の学習ではなく、チームのナレッジとして残せる

といった点は、オンライン開催ならではの大きなメリットでした。

一方で、

  • オフラインに比べて雑談的な議論が生まれにくい
  • クローズドになりがちで、活動が広がりにくい

といった課題も感じています。

今後は、あえて雑談の時間を設けることや、定期的な振り返り・ブログでの情報発信などを通じて、読書会の内容を周囲にもアウトプットしていくことを検討しています。

5. 半年間続けてみての所感

「違和感」に名前がついた

現場で感じていた「なんとなく使いにくい」「調査が大変」といった違和感の正体が、名前のついたアンチパターンとして整理された点が印象に残っています。

パターン名を共通言語として使えるようになったことで、「それはジェイウォークだね」「閉包テーブルで解決できそうだ」といった、具体的な議論がしやすくなりました。

by フルゲン

バックエンド・フロントエンドの視点の共有

章ごとに感想や経験談を共有することで、理解が深まるだけでなく、各メンバーの考え方の違いも見えてきました。

バックエンドとフロントエンドで「厄介に感じている箇所」の粒度が異なる点は特に興味深かったです。

週1回・少人数で進めたことで、知見だけでなく背景や意図まで含めたコミュニケーションが取れた点も良かったと感じています。

by アキモト

知識から経験に変わる感覚

参加メンバーは入社から日が浅いメンバーが多く、読書会は学習の場であると同時に、お互いの考え方やこれまでの経験を知る機会にもなっていました。

少人数で全員が発言する形式だったため、

  • 一般論だけでなく実体験が共有される
  • 過去の失敗や葛藤も含めて話せる

といった点が自然と生まれ、書籍の内容が単なる知識ではなく、チームとしての経験に近い形で蓄積されていったと感じています。

by イダ

6. 今後の展望

今回の『SQLアンチパターン』読書会は一区切りとなりますが、チーム内のコミュニケーションや議論の質に対する手応えは大きく、今後も継続していく予定です。

次回以降は、

  • 開発のマインドセット
  • スケジュールやプロダクトへの向き合い方

といった、技術的な How-to に限らないテーマの書籍も候補にしています。

また、全章を網羅する形式だけでなく、テーマを絞ってより深く議論する形式も検討しています。

おわりに：チームの共通認識を作る

今回の読書会を通して、知識を増やすこと以上に、その背景や前提をチームで共有し、共通認識を作っていくことの重要性を感じました。

各メンバーの経験に紐づいた議論を重ねることで、書籍の内容はチーム共通の判断材料となり、共通認識として蓄積されていきます。

今回の取り組みを通して、その価値を改めて実感しました。

ⓒ i-plug,inc. All Rights Reserved.