■

要望指向プログラミングへの雑感

　つまり、ソフトウェアの要件定義と設計・実装を分離してしまうのではなく、
むしろ要件定義を確定させるための設計・実装を行っていく、というものである。

　実装のための設計ではなく、要望のために設計し、要望のために実装する。

UMLがやらんとしたことと似たよな感じ。
途中の要望書(システム設計書)がわかりにくいし作りにくいし作っても意味なさそうだし
ってところから、もっと具体的にわかるのつくろーぜって勢いで作られたのがUMLだ
って思ったおいらはそう感じますた。
っつことは方向性としてはそいつらと一緒ってことです。
効率を模索した時にたどり着く境地はみな同じ。(･ω･)人(･ω･)人(･ω･)ﾅｶﾏ

ついでに。
大規模プロジェクトでは、上に立つものほど技術に興味がなくなる傾向にあります。
営業的には数字の大きいのが好まれる傾向にあるので、
　(1)：1億の仕事をとって、8千万で終わらせて2千万の儲け。
　(2)：1億5千万の仕事をとって、1億3千万で終わらせて2千万の儲け。
なら(2)のほうがイバれます。なんてったって1億＜1.5億なんですから
実質なんて二の次です。
結果として利益率は(1)の方が高くても、それが出るまでには現実の時間があります。
その時間が出るまでには
次の仕事とってこなきゃいけないし忙しいしでいちいち結果を振り返ることなどしません。
都合の悪い結果になるならなおさらです。
つまり。
過程を洗練し、1億の仕事で6千万の利益を出すことよりも、
自身の成果として目に見えやすい4億5千万分の仕事を取るほうを選ぶでしょう。
営業畑のサガみたいなもんです。

ってなことを踏まえたときに。
うまくいくか、想像もできないよくわからない内部の過程を洗練する作業に予算を費やすよりも、
これこれいくらの利益がある〜っと世に言われている方法を選択し、満足する人が存在することに気づくでしょう。
技術の知識など毛ほどもないのですから良し悪しの判断もできるわきゃありません。
興味の大半はオカネの流れにあるのですから、
そのような傾向をもった人がオカネ以外を学習しようとするなんて稀有です。
余分なリスクを背負ったことにすら気づけない人がいるのです。
現場と離れ、学習機会そのものにも恵まれなければそうなることはある意味必然です。

結論として。
それでもわかる人はわかる。そういう人に出会ったららっきーです。
でもそうでない場合の誘惑とか勧誘とか説得作業とかは、
上記の傾向によりむっちゃ大変です。
ってことを覚悟する必要は、明日の心の安定のために必要かもしれませんね(;´ー｀)┌フッ