はじめに
データベースの設計は、書くコードの量のわりに気を遣う作業です。
理由は単純です。運用を始めてから構造を変えるのが、とにかく大変なのです。カラムを1つ足す程度ならまだいいのですが、テーブルを分割する、複数のテーブルを統合する、となると話が違ってきます。既存のデータをどう移行するのか。動いているシステムに影響は出ないか。アプリケーション側のコードはどこまで書き換えるのか。考えることが一気に増えます。しかも本番運用中なら、既存の機能を止めずに安全に変更しなければなりません。
それだけに、データベースはシステムの中でも後戻りしにくい、重要な部分だと考えています。
この記事は、そんなデータベース設計で、AIが発展した今、人間にどんな能力が求められるのかを考察したものです。対象は主にリレーショナルデータベースのスキーマ設計です。正規化、リレーション、NULL制約、論理削除といった基本は、読者が知っているか、少なくともAIへの指示に含められる前提で進めます！
AIに代替されにくいのは「ユースケースを洗い出す能力」
これまで、データベースをうまく設計するには次のような能力が必要でした。
- 技術的な知識： 正規化、リレーション、制約などを理解する能力
- 構造を設計する能力： 要件をテーブルやカラム、リレーションに落とし込む能力
- 実装する能力： 設計した構造をSQLやORMなどで実装する能力
- ユースケースを洗い出す能力： 今の要件だけでなく、将来の機能追加や仕様変更も見据えて、システムで起こり得るケースを網羅的に考える能力
こうした能力を組み合わせて設計してきたわけですが、AIの登場でこの構図が変わりつつあります。私は、このうちユースケースを洗い出す能力以外は、いずれほとんどAIで代替できるようになると考えています。
どんなテーブル構造にするか、リレーションをどう張るか、どの制約を付けるか。こうした技術的な判断は、要件を正しく伝えればAIが提案してくれますし、その設計をSQLやORMのモデルに落とすところまで任せられます。将来の仕様変更も、想定されるケースを伝えれば、どんな設計がよいかAIと相談できます。
従来は人間が担っていた「どう設計するか」の大部分は、もうAIに渡せるようになってきました。
では、何が残るのかを考えたときに私は、そもそもどんなユースケースを想定すべきかを考える能力だと思っています。
AIは、知らされていないユースケースには対応できない
例として、ユーザーと組織を管理するシステムを考えます。「ユーザーは1つの組織に所属する」という要件を渡せば、AIはそれに合ったデータベースを設計してくれるでしょう。
しかし実際の運用では、次のようなケースが出てくるかもしれません。
- 一人のユーザーが複数の組織に所属する
- 組織ごとに異なる権限を持つ
- 組織を脱退しても過去の活動履歴は保持する
- 組織が削除されても一部のデータは残す
- 将来的に複数の組織を統合する
これをAIに伝えなければ、最初に渡した要件だけを満たす設計が返ってきてもおかしくありません。
以前開発に関わったアンケート集計システムでは、従業員の回答データを管理する必要がありました。
単に「従業員が質問に回答し、その結果を保存する」という要件だけなら、データベースの設計はそれほど難しくありません。
しかし、翌年も同じ従業員が回答する場合はどうでしょうか。途中で部署が変わった場合、過去の回答結果は現在の部署にひも付けるべきでしょうか。それとも回答時点の部署でしょうか。
こうしたユースケースを想定できるかどうかで、必要なデータの持ち方が変わってきます。
AIは技術的に適切な設計を提案できます。しかし、過去の回答をどのように扱いたいのかというサービス固有の要件は、開発する側が明確にする必要があります。
もちろん「考えられるユースケースを全部洗い出して」と頼めば、一般的なケースはある程度挙げてくれるはずです。ただ、そのサービス特有の事情や、実際のユーザーの動き方、事業がこの先どこへ向かうのかまでは知りようがありません。そこを一番よく知っているのは、現場や事業に関わっている人間です。
なのでAI時代のデータベース設計で人間の価値が残るのは、テーブルをどう組むかより、そのテーブルが対応すべきユースケースをどこまで洗い出せるかだと思ってます。
洗い出したユースケースを、すべて最初から設計に入れる必要はない
ただし、ひとつ注意点があります。洗い出したユースケースを、最初から全部データベースに反映する必要はありません。
起こるかもしれないことをすべて織り込むと、必要以上に複雑なデータベースになりがちです。その機能が本当に必要になるかどうか、作る時点では誰にも分からないのです。将来起こり得るケースを把握したうえで、今どこまで対応するかを決める。求められているのはこの判断です。
この判断も、AIに相談できます。たとえば次のように聞きます。
将来的に、ユーザーが複数の組織に所属する可能性があります。ただし現時点では、1つの組織にしか所属しません。最初から中間テーブルを作っておくべきでしょうか？
AIは、将来の変更コストと今の実装の複雑さを比べて、いくつかの設計案を出してくれるはずです。
人間が将来のユースケースを洗い出してAIに渡し、どこまで設計に反映するかを一緒に決める。今後はこうした進め方が当たり前になっていくと見ています。
おわりに
AIのおかげで、スキーマを設計してコードに落とすハードルは大きく下がりました。
とはいえ、データベースの基礎知識がいらなくなったわけではありません。AIが出した設計を評価するにも、障害の原因を突き止めるにも、知識は今も欠かせません。
それでも、人間が力を発揮すべき場所は変わってきています。「どう設計するか」より、「何を想定して設計するか」を考えることです。現場の業務を理解し、ユーザーの行動を想像し、将来起こり得るケースを洗い出す。その情報をAIに渡して、設計に落とし込んでいく。
これまで「設計力」と呼ばれてきたもののうち、技術的な部分はAIが担う割合が増えていきます。そのぶん、ユースケースの発見や要件の整理が、人間の仕事の中心になっていくと考えています。