- サーバーサイド
- PM/上流工程
- RPAエンジニア
- Other occupations (38)
- Development
- Business
- Other
どのようにDB設計力を育みましたか? 僕は以下のように育んでいくものと考えております。 ・書籍を読んで基本を抑える ・実務で設計に挑戦して試行錯誤する ・設計をレビューしてもらう 周平さんの考え方をお聞きしたいです。
ご質問ありがとうございます。
基本は質問者さんが挙げられているような手法が正攻法だと思うので特に問題ないと思います。
どの分野にも通じることかと思いますが、ただこれだけだと解答が以上終了しまうので😅
以下私見です。
DBの設計力というのはモデリング力と言い換えてもいいかもしれませんが、いかにして実世界の事象を抽象・捨象してデータ構造に落とし込むかということかと思っています。
具体的にどういった定性的な性質を指してDBの設計が良いといえるのかも意見が分かれると思うので、ここでは継続的な保守や変更に耐えられ過不足無く業務の実現を可能にするサステナブルな構造を作ることとしてみます。
そういった意味で設計を捉えると書籍で学んだ基本的な設計手法に加えて、実際のドメイン知識も重要になってきます。
というのは、実際にソフトウェアエンジニアが直接ビジネスを運営するというのでない限り、必ず実際の業務の構造とデータ構造が乖離してくるからで、ここをいかにして埋めてインピーダンスミスマッチを防ぐのかがDBの設計では重要になってくるからです。
究極的に言えば、データ構造さえ見ればどういった業務を行ってどういった業務フローを実行しているかまで理解出来るようなモデルが理想的なモデルと言えるかもしれません。
そういう意味では、自分は言葉の選択というのも非常に重要になってくると思っていて、論理的なデータ構造+言葉の選択の組み合わせが最終的なモデルの完成度に影響を及ぼすと思っています。
1単語選ぶにしても実際にクライアントの実際の業務内容と乖離していたり、日本語→英語に翻訳する過程でニュアンスの取りうる範囲が変わることで、最終的なモデルや以降の保守性に多大な影響を及ぼすこともよくあります。
なので、基本英語で最終的なコードを書く以上、語学的な勘所もある程度抑えておいた方がいいかなと思っています。
あと国語力が求められる分野なのかなとも思います。クライアントは必ずしも論理的に自分の業務を把握しているわけでもないので、そこを過不足なく論理的なデータ構造に落とし込めるようにするには、論理的でない顧客の言葉を論理的に分析・補完して読解する能力も求められます。
そのため広い意味での国語力を鍛えるという意味で、直接はエンジニアリングに関係ない本でも読むということも重要かなと思っています。
結局のところ、ちゃんと事業を運営するクライアントにインタビューして事業理解していこうよというのがDDDとかでもよく言われてることだと思いますが、まぁそこまで行くとコンサルとかデータアナリストみたいにもなってくるので、あくまでソフトウェアエンジニアとして出来る範囲でどこまでいけるのかみたいな話はありますが…
ドメイン知識を得るために、その業界の標準的な教科書など読んでみたりするのもいいんじゃないかなと思います。
また、個人的な経験で再現性は薄いので申し訳ないんですがIPAのデータベーススペシャリスト試験のようなデータベース専門の試験を受けてみるとかもおすすめです。
学生時代に試験を受けたんですが、その時の経験がなんだかんだ今のデータベース設計の考え方のベースになっている気がしています。
あくまで机上ですが、仮想的に業務例を出されてデータモデリングすることを求められるのでDB設計の訓練になります。(国語力+モデリング力みたいな試験なので )
現実の業務はしばしば顧客の思いつきやら社内の事情やら不確定要素が多く、必ずしも基礎的なモデリング力を上げるために良い題材が回ってくるとも限らないので…
良質な題材が欲しければDBスペシャリスト試験の過去問をさらってみるというのもありかなと思います。
ただ、特定のDBMSに依存しない抽象的なモデリング力の試験のような感じなので、00年代以降のクラウドやNoSQL等も含めた実戦的な知識を得るためにやや物足りないところもあるので、クラウド時代に最適化した設計にするには世間でよく使われている著名なサービスなど分析してみて実際にどういったDBMSやアーキテクチャが使われているのか参考にしてみるのもよい訓練になると思います。
長くなりましたがとにかく奥が深い分野で、ある意味ソフトウェアエンジニアリングの本質的なところだと思うので、あとはとにかく実践あるのみですかね…
回答になっているかわかりませんが参考になれば。
テックリード:@shufo
(社内報 2022年5月号より)