mixi投稿記事より

[システムエンジニアの部屋] トピックに投稿したものだけどオープンなところでほえてみたいのでこちらにもマルチポスト。導入は他の投稿に対するものなので略

私の場合詳細設計書までは一応書きます。テスト仕様書も一応書けます。でもコードを書いてみないと実際はわからないところがたくさん出てきます。コードにしてみないとバグが入りやすいところ、データの扱いを慎重にしないとまずいところ、クリティカルになる部分、パフォーマンスが必要になる部分(裏返しに観るとボトルネックになる部分)が見えないことが圧倒的に多い。

このトピックを読んで結城さんのエントリを思い出しました。
http://www.hyuki.com/d/200606.html#i20060616

最近この手の話題がブログスフィアで盛り上がっているようです。自分で考えがまとまっているわけではないのですがソフトウェア「工学」という見方が適用できるケースはほとんどないのに当てはめてしまっていることが問題なのでしょう。そしてそれに変わる概念が無い。また意識あるエンジニアはこの問題がわかっていますがPMクラスではあまり意識されていない、ましてユーザはそういう見方をしていないということが問題の深刻化につながっていると思います。

もう一つ、エンジニアの内側をみると同じエンジニアという言葉でくくるのは無理があるほどスキルや生産性に差があるのが現実です。しかしいまや IT業界は雇用吸収の巨大なベースになっています。底上げをして個々の生産性を上げるより単価の安い人員を大量にいれた方が予算がつきやすい構造になっています。これってソフトウェアの市場がある程度の規模になってからは常態化しているみたいです。
http://www.pro.or.jp/~fuji/mybooks/okite/index.html

私は中国の企業と仕事したことがあります。
商品に欠陥が発覚した場合に対処法で日本と中国の発想の違いに驚きました。
製造業のばあいですが日本だと
1)商品に欠陥が発見される。
2)修正のために金型を直す必要がある。
3)納期が１週間延びて型代が必要。
中国では
i)商品に欠陥が発見される。
ii)修正のために手作業で問題のある部分を削ったりする。
iii)１００人の工員を３交代で動員して納期が３日延びる
というような感じです。日本ではiii)のような手段は人件費の問題もあるし労務の問題もあってまずペイしないのでそもそもそのような発想はしません。
でも中国では人件費が安いのでむしろ合理的な運用方法です。

でもソフトウェア開発の現場では人海戦術で何とかするって現場ありますよね？
単価がやすいからこういう発想が生まれるのです。単価が高ければそんな運用はしません。

そして本当に優秀な人はこういう仕事が嫌いです。そうならないように仕事を進める能力を持っている人は多くは無いですがそこそこいます。
しかししかし、現場では基本仕様が変わったり、複雑な政治的問題のために結局現場にしわ寄せがきていることが多いでしょう。

私自身が目指すエンジニア像は提案力や営業力までカバーしたゼネラリストです。しかしここに政治力を入れることはちょっと躊躇してしまいます。