[経験談シリーズ]システム開発がうまくいかなかった訳(2)～”論理”＝”物理”

以前、このシリーズ(？)の第一回として、論理”から”物理”の際の抜け落ちというのを書かせていただいたが、今度は逆パターン、というか、亜流というか・・・。

前回は、DOA的アプローチで、論理ERDから物理ERDにモデリングをする際に、項目の条件が変わってしまった、という話だったが、今度は、論理＝物理として実装したお話。

実は今回の場合、業務アプリケーションそのものにおいては、現時点直接的には問題は発生していない。

じゃあ何がうまくないのか？というと、OLAP・BI等での利用について、である。

マスターのような情報、トランザクション情報だけではなく、フラグ、およびトランザクションデータの属性情報のようなものまで、全て論理的に別エンティティになっているものが、そのまま物理的実装がされており、結果として、BI等でそのエンティティそのままでビューを作ると、実ユーザーは、そのエンティティのリレーションをもの凄く意識して作らない限り、自分達の求める情報を導き出すことができなくなってしまった。

したがって、代理である程度システム提供側で決め撃ちのリレーションをはったビューを作成することになったのだが、そうなると当然、実ユーザーによっては、本来求めたい結果を導き出すことができないケースが出てくる。そうなると、結果として、一旦BIツールで抜き出した結果を、更にCSV等で出力後、マクロ等で加工する、という必要が出てきてしまい、本来のBIツールの利用法が全くできなくなってしまった。

とは言え、情報系での利用目的を最重視してしまうと、当然、業務系のアプリケーションで今のパフォーマンスが導き出せているかどうか、という保証も無い。

自分が直接関わった案件では無かったが、業務系と情報系のDBを両立させる、もしくはどのように切り離すか、というバランスの取り方が非常に大事である、ということは話を聞いて改めて痛切に感じた。要求側自身も「DB設計は開発側の仕事」と決め付けずに積極的に関わり、開発・実装側自身も「今のデータの使われ方は一元的な利用とは限らない」と要求側自身の関与を求める、という歩み寄りが必要だと感じている。