私はよくシステムの開発を家を建てるのに例えて説明する事があります。
設計の段階で図面をよく考えておくのが大事だよ。
いったん付けちゃった窓はそう簡単に10cm右にずらすわけにはいかんよ。
どうしてもやりたかったら壁を丸ごと引っぺがしてやり直しだけど、当然費用と納期は大幅アップですよ。
とか、まあ他にも色々と引き合いに出すんですが、その昔『設計をする建築家がSEで、のこぎりやかなづちを使って実際に家を作る大工がプログラマですよ』という例えをユーザーにした事があります。しかしこの例えは正しくない気がします。いや実際は正しいんでしょうが、意図を間違って受け取られやすいって事です。
この業界には 営業＞SE＞プログラマ というヒエラルキがあるようです。実際にシステム開発会社の多くで指揮系統がこのようになっています。新人君はまずプログラマ見習いから始まって、何年か修行したらSEとして設計を覚える。まあここまではいいでしょう。ベテランSEになってくると、もっぱらユーザーとの打ち合わせとプロジェクトのマネージメントだけが仕事で、自分でコードを書く機会は全く無くなります。この辺から様子がおかしくなってきます。
まずマネージメント能力はプログラミングスキルとは全く別物で、プログラマを何年経験しようが出来ない奴には出来ないものです。
次に開発の第一線から離れると技術に着いていけなくなるという問題があります。そもそも経験だけは長い割に大したスキルも無い人間の方が多いという話もありますが。
営業に至ってはスキルうんぬんどころの話ではありません。営業マンの問題は「システム会社の営業マン」で語っています。
で、そういう人間が指揮系統の上にいるという構造が、プロジェクトが火を吹く一番の原因だと私は考えています。
営業とかSEってそんなに偉いのか？どう考えたって実際に動くプログラムを書いてる（書ける）人間が一番すごいでしょ。
そもそも営業と開発サイドはどっちが上とかの話じゃなくて役割の違いです。営業が仕事取ってくるから開発者は開発が出来るし、開発してくれるエンジニアがいるから営業マンは営業が出来るって事なはずなのに、多くの会社では営業マンがエンジニアに対して仕事を与えてやってるっていうスタンスです。営業がユーザーに言われるままに無茶な予算と納期で仕事を取ってきて、あとはエンジニアに押し付けるだけではこっちはたまりません。
SEの場合は役割分担という事とはちょっと違うと思います。ロクにコードも書けないSEがユーザーと要件定義をやったりすると、無茶な仕様が出来上がって作る側が苦労する事になります。コードを書けない人間に設計は出来ない、というのが私の持論です。コードを書けないという事は極端な言い方をすれば、プログラムがどうやって動いているのか知らないという事です。それを知らずにユーザーの要望をハイハイと何でも安請け合いすると、やっぱり苦労するのは開発者です。
大工が建築家の先生の指示に従って家を建てる、という構図はSEとプログラマの間には当てはまらないだろうと思うんです。
設計はプログラマの中でも上級のプログラマの仕事だと思います。その場合に 設計者＞コーディング担当者 の関係ができるのはもっともな事だと理解できるのですが、設計＝SE，製造＝プログラマ という分業があって、SEは設計しかやらない（できない）人という定義はおかしいんじゃないでしょうか。だから私は自分のことをプログラマですって言っています。
営業やSEは上級職でプログラマは兵隊としてこき使われるっていう扱いは不当だと思います。でも本当にそういう会社とか現場が多いんですよ。
