OOとかDOAの限界とか

本日、友人たちと飲んでいる最中、一人テンションが上がって「OOとかDOAとかの限界について」みたいな近頃考えている事をたらたらと話してしまい、わりと驚かれてしまいました。

はぶさんのこちらのエントリを読ませて頂いて、私がなんとなく感じていた事はもしかしたらこれなんじゃないか、と思っていたところで、思わぬアルコールが入って吐露という次第です。驚かせるつもりもなかったのですが、いや、ほんと、申し訳ないです。

私が考えていたのは何かといいますと、DOAでもOOでもUMLでも画面モックでも、まぁ何でも良いのですがそういった一連のドキュメントを揃えていって、点描画を見るようにしながらでないとユーザのニーズを見出すのは難しいのかな、他に何か良い方法はないかしらん？という事です。

実際にシステムを使うお客様は、殆どがコンピュータの素人です。（だからこそ、我々のような仕事が成り立っているわけです）その為、お客様にERを見せても伝わる訳もなく、結局は画面モックを見せて機能的な側面からニーズを得ようとします。このアプローチは正しいと思います。（最善かどうかは賛否両論あるかも知れませんが）

でも、お客様の業務を静的なモデルで表そうとすると、画面モックからでは全然分からないので、ERを起こしたりします。同じような理由で、動的なモデルを表すためにUMLを起こしても良いです。これも、正しいと思います。（これも賛否両論あｒ（ｒｙ）

でも、画面モックもERもUMLも、書いてある内容はお客様のニーズそのものではないんですよね。
お客様のニーズを一側面から捉えてそれをモデル化したものです。モデルを書き起こしたドキュメントを渡す相手が実装者なら、とても効率的なコミュニケーション・ツールになると思いますが、相手がお客様だった場合、UMLもERも何も伝えられないです。

ER分析は、実はコンサルとかアナリストの中の人が整理法の一環として使用する、というのであればここまで悩む必要も無いんですけど（例えばMindMapのように）、DOAというアプローチそのものが目指すスコープは、MindMapなんかよりずっと広くて深いので、私自身、DOAをどのように位置付けたものかちょっと迷い始めてしまいました。

このテーマは、私なんぞに収拾させられるものでもないので、多分書き逃げになると思うのですが、こんなこと考えて友人の度肝を抜いてやったぜorz、な記録としてエントリに残しておきますです。