SQLちゃんとやれORMに満足するな昔の自分。的な話

今とても後悔していることがあって、SQLを体系的に学んでこなかったこなかったんですよね。
今までやってきたフレームワークではこんな感じでORMに守ってもらっていました。

• Rails ~ ActiveRecode

• Express ~ Prisma

• Golang ~ Gorm

• Laravel ~ Eloquent

ORMでDBとやりとりする中で、 N+1とかAPサーバに負荷を寄せたいとかには向き合ってきたのでsqlと無縁だったわけではありません。
でも、
「先々月のMAUと顧客の属性比率が知りたい」
「サブスクのプラン複数あるけど、顧客の属性毎にどれを購入することが多いの？」
こんな感じの要望ってPdMとか開発部の人に振ってきがちなニーズで、特にサーバサイドを担当する自分がこれに答えられていない、どころか少しビビっているのは割と罪深い思いです。
こんな感じで、SQLへの理解不足から自分か感じたことについてまとめていきます。

ドメイン理解へのボトルネックになる

エンジニアが事業ドメインを理解していくことの手段として、RDBの構造を理解するっていうのが大きいと思っています。
これを達成するためのアクションとして、SQLを実際に叩くのは最も効果的です。実際に会話してみることですね。
ここでSQLへの理解が足りないと、英語力がイマイチで海外旅行を楽しみきれない人みたいな気持ちになります。
基本構文レベルであればGPTに頼めば良い話なんですけど、プロダクト独自のDBに対する時にはやっぱり自分が集計関数とか複雑な条件の付け方をわかっていることがマストです。

UserStoryを設計に落とし込む時のつらみ

音楽ストリーミングアプリのUserStoryでこんなのがあったと想定します。
例示用にぱっと考えたので、Storyの荒さはご勘弁を…

プランAのサブスクに加入していて加入3ヶ月未満のユーザーかつ、
Karin.さんの楽曲を20件以上ダウンロードしている人
or
Karin.さんの楽曲を20件以上お気に入りにしている人 。
どちらかの条件に一致している人のキャンペーン一覧画面に、Karin.さんのクローズドキャンペーン画面への遷移ボタンを表示したい。

まぁORMで取得する分にもwhereとかorとかincludeとか必要そうですね。
ただ、この条件に該当するレコードを「本当に正しく集計できているか？」の品質にエンジニアはどう向き合うべきでしょうか。
テストコードで確認する、レビューで確認する、色々ありますが一番早いのは「実際にクエリを書く」ことだと思います。
このクエリが間違ってる可能性もあるので、レビューやテストコードは必須ですよちなみに。
このように、要件を設計に落とすことに関して、自信を持ってクエリを書けることの恩恵はとても大きいです。

他事業部との連携

自分が所属している会社ではエンジニアはもちろん、ビジネス組織の方達もクエリを使って仮説を立てることをやってます。
この方達にエンジニアが遅れを取るわけにはいきませんね。BizとDevの共通言語になってくれるのがSQLのいい所です。
「この施策に関する数値はActiveRecodeだと…」みたいな事してる人見たことないですよね。

こんな感じでエンジニアがSQLを操れることは、ソフトウェアへの貢献とビジネスへの貢献の両方に効いてきます。
それが自分のドメイン知識を深め、他事業部の人たちとも仲良くなれます。
SQLはDBだけではなく、人とのコミュニケーションツールでもあるんですね。

終わりに

途中、Karin.さん愛がチラ見えしてしまって申し訳ありませんでした。
結論、みんなKarin.さんの曲を聴けば幸せになれるってことです。SQLなんてどうでもいいです。
おわり