AI 時代に求められるのは、DB 設計のカードを何枚持てるかだ
はい、どうもこんにちは佐藤です！
社内で、AI 時代だからこそ手書きでソースを書く研修をしよう、って話が出てきました。
ごもっともだと思います。生成されたものを読まずに通すエンジニアばかりになったら、そりゃ怖いですからね。
ただ、ひとつ引っかかっていることがあるんですよ。
課題もなしに書くのは、どうなのかなと。
若手の時間は有限です。手を動かす時間を取るなら、まずはシステム開発においてコアになりやすいところをマスターするのが良いのではないでしょうか。
私の答えはこれです。
AI 時代に求められるのは、どれだけ DB 設計のカードが持てるかだ。
その理由を書いていきますね！
若手の主戦場は、開発基盤ではなく DB 設計と API 設計
まず、どこから手をつけるかという話です。
開発基盤はシニアが作ることが多いので、まだ焦らずともって気はします。CI を整えたり、共通基盤の方針を決めたりというのは、経験を積んでから回ってくる仕事ですよね。
一方、実務でやるのは DB 設計をして API 設計をして、というのが Jr. からミドルの仕事になります。
つまりここが主戦場です。だったら、研修で叩くべきもここでしょう。
AI は動くコードを作れる。でも、最も変更しにくいものはどうか
AI によって、やりたいことをお願いすれば、動くコードを作ることができます。これは本当に速い。
でもそれ、システムで最も変更しにくい DB 設計はどうなのって思うんですよ。
考えてみてください。コードは捨てられます。フレームワークだって、気合いを入れれば乗り換えられますよね。
でも、データは捨てられません。
もしシステムがリプレイスをするとなっても、このテーブルは引き継がれてしまいます。作り直すのは新しい画面と新しいコードだけで、中身のデータ構造はそのまま次の 10 年へ持ち越されるわけです。
そこで仕様と合わなくて、無理やり対応するようなことになれば、それは大きな技術負債。
いやもう、呪いになってしまいます。
たとえば、ツリー構造をどう持つか
具体的に見てみましょう。
たとえば、ツリー状の表現をしたい場合。組織図でも、カテゴリでも、コメントの返信でも構いません。DB 設計には、こういうカードがあります。
- 隣接リストモデル … 各行が親の ID を持つ。素直で、付け替えも楽
- 経路列挙 …
/1/4/9/のようにパスを文字列で持つ - 入れ子集合 … 左右の番号で範囲を表す。読み取りは速いが、挿入で番号を振り直す
- 閉包テーブル … 祖先と子孫の全組み合わせを別テーブルに持つ
これらのカードの特性を全て覚えておく必要はありません。私だって毎回調べます。
でも、どのような時に使うのかの判断は、人間に求められるのです。
AI に「カテゴリのツリーを作って」とお願いすれば、たいていは隣接リストモデルが出てきます。それ自体は悪くありません。ではその選択が、階層をまたいだ集計が毎日走る 3 年後の要件に耐えるでしょうか？
聞かれなかったことに、AI は答えません。要件を投げた人間しか、その先を知らないのです。
ロールパーミッションモデルは、システム開発の「課題曲」だ
ロールパーミッションモデルもそうですね。
これはシステム開発における課題曲と言っても良いと思っています。ほぼテンプレートになっているのだから、担当者が変わっても引き継ぎやすいメリットがあるわけですよ。ユーザーがいて、ロールがあって、権限があって、その間を中間テーブルで繋ぐ。この形を知っていれば、初見のシステムでも権限まわりの当たりがつきます。
ところが、このパターンを知らない場合はどうなるでしょうか？
奇々怪々なテーブルができてしまい、可読も改修も難しい。
ユーザーテーブルに is_admin が生えて、次のリリースで is_manager が生えて、しばらくすると is_admin_2 が生える。見たことありませんか。私はあります。
そして最悪なのは、そのシステムがそのまま何年も動いてしまうことです。誰も直せないまま、権限の追加のたびに列が増えていく。
テーブル設計の手持ちのカードは、それくらい大事なのです。
問題は、経験を積む機会が年 1 回しかないこと
ここで、育てる側の話になります。
このようなお作法は、年 1 回設計するかどうかになっていて、経験が積みにくいんですよね。新規のシステムを立ち上げる機会なんて、そう転がっていません。ほとんどの案件は、誰かが引いたテーブルの上に機能を足していく仕事です。
「自分でやれ」というのもわかります。実際、私もそうやって覚えてきました。
でも、このようなことを経験する仕組みを作るのも、先輩の役割なのではないでしょうか。
だから冒頭の研修に話が戻ります。手書きで書かせること自体に反対はしません。課題を選ぼう、という話です。
同じ要件でツリー構造を 2 通り実装させて、後から「階層をまたいで集計したい」と要件を足す。権限を先に is_admin で作らせておいて、途中で「部署ごとの管理者が必要になった」と言う。選択を間違えた痛みまで含めて、1 日で味わわせるのが良いと思うんですよ。
年 1 回の機会が回ってくるのを待つより、よほど早い。
AI が判断できるようになっても、理解していない側は困る
「そのうち AI がテーブル設計まで最適にやってくれるのでは？」と思いますよね。
たぶん、かなりのところまで来ると思います。でも、それでも困るんですよ。
AI が発達して、このような判断ができるようになったとしても、人間側がどうしてこういう作りになったのかを理解していないと難しいのではないでしょうか。
3 年後、そのテーブルに新しい要件をぶつけるのは人間です。閉包テーブルが選ばれた理由を誰も知らなければ、「よくわからないテーブルがある」という扱いになって、隣に似たようなテーブルがもう 1 つ生えます。
以前 AIコーディング時代だからこそ、BEAM分析と状態遷移図が大活躍する で、AI に何を渡すかという話を書きました。渡す側が構造を理解していないと、そもそも渡すものが作れません。理解は、AI を使うための前提なのです。
まとめ
というわけで、AI 時代に磨くべきは DB 設計の手札だよ！ って話でした！
正確には、カードの枚数と、切りどころの判断ですかね。
コードは書き直せます。設計書も直せます。でもテーブルは、システムが生きている限り引き継がれていく。だからこそ、AI が最も速く仕事をしてくれる領域の隣で、いちばん人間に残る判断がここなんですよ。
……と、ここまで偉そうに書いてきましたが。
正直に言うと、これ、私自身もできていません。
経験する仕組みを作るのが先輩の役割だ、なんて言っておきながら、自分の現場でそういう課題を用意できているかというと、まったくです。年 1 回しか回ってこない設計の機会を、どうやって若手に分け与えるのか。いまだに答えが出ていないんですよ。
若手に手を動かさせるなら、課題はテーブル設計にする。
どうでしょうかね？
もっと良いやり方でやっている方がいたら、ぜひ教えてほしいです。