そもそも何のために作るのか

ブックマークしただけで読んでいなかった
http://d.hatena.ne.jp/habuakihiro/20060617#1150545007
を読んで、確かになーと思った。やっぱり、見た目の派手さとかに騙されずにちゃんと本質を見ないといけない。

とりあえず、「こういうDB設計があるとします」なんてところから始まってるプロダクトについては、技術的にいくら素晴らしくてもお客様の使い勝手に対する要件をクリアするということを含めたプロジェクト全体のスループットからみたら、所詮部分最適化でしかも下手したら全体の生産性に逆効果になりかねない代物に過ぎない、と判断します。とりあえず、「そのサンプルのDB設計はどうやればいいんですか？」って問いについて、私が納得できる手法を教えて欲しいですね。それがあれば、ERDレッスンなんて用無しに出来るんですから。

で、その続きに書かれている
http://d.hatena.ne.jp/habuakihiro/20060617#1150552659
にかなり感動。しかも蛇足の部分に。

で、UIってのは単独で存在するんじゃないんですよ。いきなり画面仕様から入るんじゃない、ってのはそういうことです。そもそもやらなきゃいけない仕事があって、それを支援するためにUIが必要になるのです。だったら、何をどのように必要とされているのか、ってことを定義しないと駄目じゃん。だから業務フローから書かなきゃ駄目だってことなんです。
単に、どうやるのか、ってことばかり追っかけてても駄目なんです。やった結果どういう風になりたいのか、ってことです。どうやれば口説けるかじゃなくて、口説いた後どんなお付き合いをしていきたいのか、ってことです。何だって同じことですよ。ゴール指向。Goal Orientedに柔軟にアプローチするのです。

あー、なんか浮気しそうです。この考え方、もうちょっと具体的に知りたくなってきた。困ったな。
で、これは誰が書いているんだろうと思ってプロフィールを見てビックリしました。
さっきRDBMS再入門読んだばっか！