実際の開発は、トップダウンとボトムアップの悪いほうを足して２で割ったかんじ（その１）

　おととい、トップダウンの記事、昨日、ボトムアップの記事を書きましたが、実際の開発は、この２つの悪いほうをあわせて２で割った感じになると思います。

　実際には、システム開発を行うとき、偉い人が、のりのりで、こんなのをやりたい！とか、目標とか、夢をかたっちゃいます。

　これをかっこよく、to-beモデルとかいってるかもしんないけど、とにかく、偉い人が考えた、コンピューターを導入した、まだ、やっていないことです。抽象論です。

　で、その偉い人は、「あとはよろしく」なのです。
　具体的に、きっちり出来るところまで、見切ってはくれません。
　具体論は、部下にまかせて、できないと、怒るだけなのです。

　そうです、わがままいって、出来ないと怒る、ちいさいだだっこの子どもと一緒です。

　彼らにとっての要求仕様とは、小さい子のだだっこと一緒です。

　これだけの金をあげるから、コンピューターシステムをつくって、こんだけ儲けさせてくれという「だだ」です。
　当社の要素技術は、これであり、この技術をこう結ぶと、こういうことができるはず！という絵があって、それを結びつけたシステムを要求しているのではありません。

---

　で、現場では、なんとか、その実現方法＝具体案をかんがえないといけません。
　つまり、この技術や、この人をこう結ぶと、こういうことができるという絵をつくって、それを結びつけたシステムをつくんなければいけませんが。。。

　上の人は、だだをいっただけで、それができる裏付けをとったわけではありません（要素技術をくみあさせて、できる！と読みきったわけではありません）。
　だから、実際、具体化していくと。。。あ、むすびつかない！できないということもあります。

　そうやって、気が付けばまだましです。

　具体化する方法すらわからない人もいます。

　方法がわからない人は、それでも、まだましです。
　
　自分は具体化しなけりゃいけないという仕事の内容すらわかってない人がいます。

　要求仕様とは、

　　・エラーい人が言ったことを目標として紙にまとめ、
　　・自分の思ったことを要求として、非機能要件とかいうかっこいい名前を付けて、
　　・現状をコンサルやＳＥに分析してもらって、
　　・それをきれいなユースケース図などというものとかに書いてもらえばいい。
　　・あとは、レビューというやつに出て、おかしいところを指摘すればいい。

　そんな、甘い考えで、システムなんて、できるわけねーだろ！
　だれが、その要求仕様のシステムができるっていう、裏をとるんだよ！

　めからびーむ！！

---

　といいたいところなんだけど、下請けである、フリーのウィリアムのいたずらは、言えるわけはないので、システム開発になると、
　自分で、たぶん、要素技術はこれで、
　（コンピューターだけでなく、業務の技術もある。
　　　在庫のピッキング方法、
　　　ＢｔｏＣでの集金方法（＝クレジット、口座引落、振替、代引きなど））
　こういう絵を書けば出来るんだろうというもんをつくって、
　もっていくと、非難ごうごう。

という形で、やっとスタートラインにたてるわけです（システムとして、出来るめどがたつ）

このはなし、つづく