こんにちは。 SQL 大好き！ 
id:kano-e です。
少し前に「弊社の新人エンジニア研修カリキュラムを惜しみなく公開してみる」という記事が、このブログで公開されました。
ご覧いただいて、お気付きになった方もいらっしゃるかと思いますが、
SQL 研修がない
のです。
今日はその辺りの悩みと、そのことに対するアンサーとして行ったテーブル設計ワークショップの内容をまとめます。
そもそも
「研修から SQL 外そうと思うんですが……」
研修の担当だった @sukechannnn から「研修から SQL 外そうと思うんですが、どう思いますか？」って聞かれたある日。
研修のカリキュラムがすでに情報過多だったので、SQL に関しては本を読んで補う形にしたい、という意図でした。
自分はそれを聞いて「そうね、良いと思う」って答えました。
SQL の研修ってどうしても CREATE TABLE して、 INSERT したら SELECT UPDATE DELETE して WHERE 使って……みたいな感じになるかと思うんですが、そもそも「データベースとは」「テーブルを作成してそこにデータを入れるってどういうこと」というのがないまま伝えるのは難しいな、という気持ちがあったんですね、自分は。
それでも、使い方を教えることはできるかとは思うんですが、前年の研修ではその辺りをどうして良いかわからないまま @sukechannnn の研修をしてしまい、でもその反省をどう活かすべきかのイメージがつかないままでした。
なので「SQL についての入門書を渡すのであれば、今後の業務の中で必要な時にそれを手に取ってもらえるなら、それで良いと思う」という賛成でした。
「SQL 研修ってなかったんだっけ？」
だったのですが、「今回の研修って SQL やってないんだっけ？」みたいな話題があったのも確か。
自分は「なくても良いと思う」と言ったこともあるし、 SQL の話だし、そこに対して何かしらの姿勢は見せたいな、と思ってました。
ただ、 SQL って、実際のデータがあって、データを取り出すための目的があって、はじめて「どう書けば良いんだ」という悩みが出てくると思うんですよね。
どんなテーブルにどんなデータが収まってるのかがわからないと SQL も書きようがない。
言ったら SQL はテーブル設計次第とも言えるわけです。
だったらまず、解決すべきは「テーブル設計」なのでは？ と思い至りました。
「テーブル設計する機会がなければ、自分で機会を作れば良いよね」
みなさん、「テーブル設計」ってどのくらいしてますか？
実はテーブル設計って、イチからやる機会って少ないんじゃないかなって思います。
テーブル設計は場数を踏めば踏むだけ強くなれます。何事もそうかもしれませんが、たくさんやるのが大事です。
設計する機会がないなら、自分で設計する機会を作りましょう。
というわけで、勉強会で「SQL 研修あっても良かったのでは？」に対するアンサーとして、テーブル設計ワークショップをやったのでした。
ここまでが、長い前置きになります。
実際にやったこと
みんな大好き ドミノ・ピザ を題材にしました。
最初の時点で、以下の状態になるようにうまいことグループ分けをしてもらっています。
- 3 名〜 5 名程度のグループ
- 1 on 1 だと議論にならない可能性があるので最低 3 名は欲しい
- 全員が話に参加できる限界が多分 5 名くらい
- できるだけ職種がばらばらになるように
- データベース知っている人が誰もいない、ということがないようにしたい
- できるだけ仕事経験年数がばらばらになるように
- 経験年数の長いエンジニアから短いエンジニアへの情報伝達の場にもなると良いな
- 一応「研修」を意識していた
- できればプロダクトもばらばらになるように
- プロダクトが違うメンバーの方が「どうしてそうするのか？」という疑問が出やすいように思う
- 根拠がある訳ではないんだけど、普段一緒に仕事してると、多少暗黙的に決まってしまう物事がある気がする
前半
ドミノ・ピザの注文画面を開いてもらったところで以下のようなお題を提示して、グループ毎にテーブル設計をしてもらいました。
- ドミノ・ピザの注文を管理するためのテーブル設計をする
- 出来上がったものを元にエンジニア同士であれこれ議論ができる程度の情報があれば良い
- 図を綺麗に書くとか ER 図の書き方とか定義書の書き方とか気にしなくて良い
- 対象はピザメニューのみで良い
- サイドメニューは考えなくて良い
- ドミノ・ピザのシステム再現が目的ではないので、サイトの情報を完璧に再現しなくて良い
- カロリー情報とか説明文とか、細かい部分は忘れて良い
- 細かな制約も考えなくて良い (null 許可にすべき？ とかは今回は枝葉)
- 以下の要素は検討されてると嬉しいけど、優先順位は下の方が低い (時間がなければ無理しなくて良い)
- サイズはMとLから選べる
- 生地も選びたい
- トッピングも可能
- 期間限定メニューがある
- X%引き、Lサイズのみ50%引き、1000円引きのクーポンがある
- ハーフ&ハーフも可能
10 〜 15分程度で一度区切って、各グループの設計のやり方や状況を軽く見て回りました。
フロントエンドエンジニアがいるグループだとユーザの行動からリソースを見つけてテーブルの情報に落とし込んでいったり、デザイナがいるグループでは画面構成からリソースを見つけたり、この辺りの色々なやり方が見えたのは、当初の意図にはなかったものですが思いがけず機能していて面白かったです。
後半
後半に入る際に、以下の情報を増やしました。
- ある 1 件の注文の情報をまとめて確認するための SQL は書けそうですか？
- 先週のピザ販売数ランキングが欲しいと言われたら？
- ピザ1枚だけでの注文と複数枚での注文の割合を知りたいと言われたら？
- ピザ1枚だけでの注文と複数枚での注文の時に、それぞれでよく注文されているピザを知りたい、とかは？
その上で、後半スタートです。
後半も 10 〜 15 分程度でした。
最後に、全員の結果を発表して終わりました。
以下、とあるグループの設計の結果です。
30 分という短い時間の中で、ハーフ & ハーフにも対応してくれました 👏
各グループ盛り上がり、「楽しかった」「良問でした」「ピザ食べたくなった」といった感想も上がって、企画実行して良かったです。
わいわい。
「で、SQL 研修は？」
今回のテーブルに対して、「え、このテーブルからどうやって情報を取得したら良いんだ？」ってなったら、そこでようやく SQL の出番です。
後半に入る時に提示した新たな情報は、そこをイメージしてもらいやすくするためのものです。
「こういうテーブルがあって」「こういう情報が入って」「こういうことを知りたい」ところまでいくと「このテーブルとこのテーブルの情報をまとめて見るためには JOIN が必要」「集計するときには GROUP BY する必要がある」みたいな、具体的な話ができるようになるのかと思います。
実際にアプリケーションを作るところまでやれば、より具体的にイメージも湧くのかもしれませんが、さすがにそれは時間が足りません。
各自、その先に想いを馳せてもらえたら良いかな、と思っています。
「量は質に転嫁する」
今回のワークショップは『楽々ERDレッスン』という本の第3部を参考にしています。
- 作者: (株)スターロジック羽生章洋
- 出版社/メーカー: 翔泳社
- 発売日: 2006/04/18
- メディア: 単行本（ソフトカバー）
- 購入: 72人 クリック: 940回
- この商品を含むブログ (120件) を見る
2006 年と古い本ではあるのですが、特定のデータベースシステムに依存せずに、「テーブル設計」をする時に何を考えたら良いのかが実践的にまとまっている良い本です。
実際にテーブル設計する際には「今後の変更の可能性」や「リアルタイムに大量の検索が行われるかどうか」というのは、とても重要な要素なので、 Web アプリケーション向けの設計をしたい場合には、その点は頭の隅に置いて読んだ方が良いとは思います。
「量は質に転嫁する」は作者の方がおっしゃっていた言葉ですが、そのための練習を実践しているのがこの本の第3部で、身の回りの「注文用紙」や「予約申込書」「レシート」などを題材に、なんでもテーブル設計してみよう、という内容になっています。
最近ようやく「量をこなすことでパターンを見出せるようになるから質に転嫁するのでは」ということに思い至りました。
パターンだけ知っても、なかなか見出せないのですよね、現実は複雑なので。
というわけで、こういうテーブル設計の練習の場を作っていくのは良さそうだなと思ってます。テーブル設計チャレンジしていきましょう。
