まず、色々な話をする前に、大きな前提として、
「アプリ寄りなDB設計者、インフラ寄りなDB設計者」
という分析をここで書きたいと思います。
DB設計者のバックグラウンド
一言で「DB設計者」と言っても、もともとはどんな仕事をやっていたのか結構バラバラです。
自分のようにずっとアプリ開発現場でディベロッパーとして実装実装していてDB設計をやるようになった人...
ずっとインフラ側の仕事をしていて、ひたすらOracleやDB2を触っててDB設計をやるようになった人...
もちろん、単純にカテゴライズされないパターンも多くあるかと思いますが、話を単純にするためにこの二つに着目しています。勝手に「アプリ寄りなDB設計者、インフラ寄りなDB設計者」と呼ばさせて頂きますが、実はここで結構すれ違いが発生します。
どちらに寄っているDB設計?
当然のことですが、アプリ寄りなDB設計者はあまりインフラ得意じゃないし、インフラ寄りなDB設計者はアプリの開発効率という面での考慮は得意ではありません。
アプリ最適なテーブル設計をインフラチームが見て、ガッカリすることもあるでしょう。
インフラ最適なテーブル設計をアプリチームが見て、ガッカリすることもあるでしょう。
組織体系がどうなっていようが、システム全体としては両側にうまく適用できないと困る訳で(つまりそれはシステムを発注したお客様が困る)、「DB」という共通物に対して、互いに打ち合わせでしっかり意識合わせをするのが大事です。
システム開発全体がうまくいかなきゃ
一方で、自分は「隣のこと(隣の領域)を知らない」ということをちゃんと認識して、足りない必要な知識を得る努力も大事です。
(せめて必要になったときでもいいので)
調整(相談)する相手すらいない場合は、全て自分でうまく調整する必要がありますから。
それらのことを認識せずに曇ってる領域を曇ったままで先に進むのが一番良くないです。
どっちに最適化されていてもシステム開発全体がうまくいかなきゃただのハリボテです
どんな組織体系だろうが、互いに要望を出し合って歩み寄って「落としどころ」を見つけるのが大事。また、そういう風になるようにマネジメントするのが大事でしょう。
※DBFluteとは直接関係のない話ですが、「非常に近い場所の話」ですので、モノ(フレームワーク)だけを提供するのではなく、こういった内容の記事も書いていきたいと考えます。また、OSS活動(DBFlute)をしてきたことで、こういう話を分析する機会がさらに増えたということもあります。