ソフトウェアの仕様書は料理のレシピに似ている

　先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。

　こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。

　「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあるが、それにも全く賛成できない。私はこの業界で多くのエンジニアも使ってきたが、優秀なエンジニアとそうでないエンジニアの生産性は（誇張抜きで）２０対１ぐらいである。そんな簡単な作業しか出来ないエンジニアとも呼べないようなエンジニアが沢山いてもマネージメントが大変なだけである。そもそも、就職した段階で詳細仕様書に従ってしかプログラムを書けないような人が、ソフトウェアエンジニアになっても幸せになれるとは思えない。

　そしてもっとも許せないのが、そういった上流→下流という階層構造でプログラムを作る工程そのものだ。

　これに関しては、自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。もちろん、彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。

　実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。（ただし、そんな作り方で作ったプログラムはソースコードが汚くなってしまうケースが多いので、この段階から出来上がったプログラムを、読みやすさ・メンテナンスの高さを重視して大幅に書き直すことを強く薦める。エンジニアによっては、ここで一度作ったプログラムを全部捨ててしまってもう一度全部作り直す人もいるぐらい、この作業は重要だ。）

　世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。

　しかし、私が一度働いたことのあるNTTの研究所では、ほどんど自らソフトウェアの開発をしたことの無い人達が詳細資料書を書き、それを外注に発注してプログラムを書かせる、というソフトウェアの作り方をしていた。学生時代からプロとしてソフトウェアを作っていた私は、新入社員にも関わらず「こんなやりかたじゃ良いソフトは作れません」と上司たちにくってかかったのだが、誰一人として理解してくれなかった。

　私には、この「自分でプログラムを書かない上流のエンジニアが詳細設計書を作り、下流のエンジニアがコーディングをする」という工程そのものが、根本的に間違っているとしか思えないのだ。「下請け」という弱い立場にあり、経験も少ない下流のエンジニアが、「仕事を発注してくれる大切なお客様」である上流のエンジニアに対して、「この部分は、設計を少し変更をした方がプログラムがシンプルに書けるし実行効率もあがると思うんですが、変えちゃっていいでしょうか」などと言うことが出来るとは思えない。下流のソフトウェアハウスの経営者にとっても、そんな余計なことを言うエンジニアよりも、仕様書通りのプログラムを納期以内に黙って作るエンジニアの方が使いやすいのではないだろうか。

　日本のエンタープライズ系のソフトウェア業界は、そんな根本的に間違ったソフトウェアの作り方を長年してきたために、まるで建築業界のような下請け・孫請け構造が出来てしまい、下流のエンジニア達が十分な経験も得ることが出来ずに低賃金でこき使われ、業界全体として国際競争力をなくしてしまう、という状況に陥ってしまったのではないか、というのが今回の私の仮説である。

　もちろん、米国に住む私が得られる限られた情報だけから立てた仮説でしかないので、何か大きな勘違いをしているのかも知れないが、少なくとも今の日本を見ると、階層構造化されたエンタープライズ系のエンジニアたちよりは、オープンソース系の「設計からコーディングまで全部自分でやる」エンジニア達の方がずっと元気があるし幸せそうだ、ということだけははっきりと言える。

　ちなみに、この話を書いていて思ったのだが、プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューするのは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。もちろん、レストランに行く側の立場になってみれば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。

Comments

[DKA]

なんというかソフト業界だけでなく半導体業界でもsatoshiさんのいう通りの状況になってます。RTL(Register Transfer Level)設計をしたことがない人間が旨い仕様なんか作れる分けないのに、無意味に分業し、しかも、RTLやSystemCによる「テスト」を軽視。何度も繰り返しが起こり、かえって工数を増やしてます。仕様検証を人手、しかも基本的には机上／目視チェックのみでなんとかしようという考え方。複雑な規格に対応するんでなければこんなやり方でもうまくいくのかもしれませんが。
一部だとは信じたいです。。。

[夏モード]

とんでもなく同感します。とはいっても私は就職活動中の学生なのでプロではないのですが…
設計からコーディングまでできる会社を探しているのですけど、日本ではなかなか見つからないんですよね…
UIE Japan（もしくはUIE）では新卒採用は行わないのでしょうか？

[kzgs]

僕も同様に就職活動中の身ですが，この時期だけにいろいろな会社の話を聞くとやはりドキュメンテーションに関する時間がほんとに長くて，そこらへんで時間を調整しないと時間が減ってしまい人月が減ってしまうということを聞きました．いろいろな技術を習得してコーディングの効率が良くなっても結局時間が減ってしまうと予算が減ってしまうということなんでしょうか？

[Ossan]

私もsatoshiさんの意見に同感です。
最近はそれに輪をかけて、プログラムをろくに書いたことがない人が
詳細設計書を作るためか工数見積もりが異常な内容になっていることが多いです。

他に以前受けた仕事にはとんでもないものがあって、
（PCも作ってる有名なところから受けた仕事ですが）
最終的にできあがったコードの行数で開発費を支払います、
なんてことをやられました。

一旦作る→効率的に動かすために手を入れる
→結果的にコードはまとめられてコンパクト
っていうのが普通の作業手順だと信じてるのですが、
これだとゴミみたいなコードがくっついてるほうがいいんかと。

効率のいいプログラムを書いたほうが
支払われる開発費が少ないなんてこんなプログラマを
バカにしたようなことを平気でやる企業があるなんて異常だと思います。

私は精神的におかしくなってプログラマは辞めました･･･。

[Satoshi]

＞UIE Japan（もしくはUIE）では新卒採用は行わないのでしょうか？

UIE Japanでは、新卒も採用しています。もし興味があれば、uiejapan（アット）uievolution.comまで連絡を下さい。履歴書だけでなく、ブログだとか自分が運営しているウェブサイトなどの情報も送っていただけると助かります。

[Satoshi]

>効率のいいプログラムを書いたほうが
>支払われる開発費が少ないなんてこんなプログラマを
>バカにしたようなことを平気でやる企業があるなんて異常だと思います。

　これに関しては、NTTもまったく同じでした。つまり、シンプルで短くて読みやすいプログラムよりも、だらしなく長いプログラムを書いた方がお金が沢山もらえる、というシステムになっていました。これでは、良いプログラムが作れるわけがありませんよね。

[ごん]

いつも拝読させていただいておりますが、初めてコメントさせていただきます。

某家電メーカーに勤めておりますが、satoshiさんのおっしゃることを明言するソフトウェアマネージャーはおりませんし、少なくとも理解している人とは３人ほどしか出会ったことがありません。自分としては、「プログラムを書く」「詳細仕様書を書く」に加えて、「書いたコードのテストをする」ことを開発者が行うことが全体の開発効率を上げることにも、開発者のモチベーションを上げることにもつながると思っています。開発者は、「動いた」ことに満足するだけでなく「すべてのケースで問題がない」ことを喜びとしたいしするべきです。
もちろん、開発者は抜け穴を見落とすことも多いのでさらにその後の段階としてテスト技術者が綿密なテストを行うことも必要ですが、「プログラムを書く」ことで次の人に渡す人も多く、とがめる人は少ないことが品質の低下につながっていると思っています。

そもそも、IPAのがソフトウェア技術者試験の試験区分と評価基準に定めている内容が、「プログラムを書く」ことと「詳細仕様書を作る」ことを分離したような内容になっており、経済産業省の影響の大きいIPAがこのようなことになっていることを鑑みるに、国のリーダーシップを取る人がsatoshiさんのような視点でものを見ている人があまりに少ないということではないかと思います。

自分がおもっていることにあまり自信がなかったのですが、satoshiさんのような第一線で開発されていた、いや開発されている方が明言されると重みが違いますね。そういうことを明言できるソフトウェアマネージャーがいない会社は今後落ち込んでいくだろうと危機感を覚えました。

[shiro]

門外漢ですいませんが、私は脚本を書いたり物語をつくったりしている者（アマチュア）です。
料理のレシピになぞらえた点を拝読して、「モノをつくるというのは皆同じなんだな」と改めて確認。話をつくるのも始めに構成から入りますが、それだけで「話ができあがる」訳ではなく、それに沿ってト書きや台詞を埋めていって初めて他の人にわかる物語になります。そしてその過程で必ずと言っていいほど「この方が面白そうだ」と話が変化していきます。書き上げた時にははじめの構成とは別の物語が（しかもよりよい完成度で）できあがります。もちろんその後の校正で、また全体構成をやり直して書き直すこともあります。
つまり構成だけを指示してもよい話はできあがらないと思っているのですが、日本のプログラマの世界では普通なんですね。驚きました。

[もけけ]

以前からこちらをのぞかせていただいておりました。
あまりにも心が動かされたので、はじめてコメントさせていただきます。
私は１５年以上システム開発に携わって参りました。
satoshiさんがここでかかれていることは、的のど真ん中を射てると思います。
私も長年、へんてこな構造に悩まされてきた一人です。
ソフトウェア業界に心の病が多いのもこういった構造が少なからず影響しているとさえ感じています。
「システムを造る中で、一番偉い人は実装する人である」が私の信条です。
（偉いというのは、必ずしもお金のことをいっている訳ではありません;-)）

[Baatarism]

うちの会社でも、上流工程だけ社内でやって下流工程は海外へ外注しろ、という方針になっているのですが、それで本当に良いのかなという疑問はありますね。
まあ、外注を否定する訳じゃないけど、外注するならするで、受注側で設計からテストまで一貫して行えるようにしないといけないでしょうね。

[&]

　以前の業務で売上情報共用Webを発注した時のことです。仕様固めに発注先にお邪魔しエンジニアの方と打ち合わせた時に、「東北の小さな会社がコーディングしているのでこの点の変更は間に合うかわからない」、と言われたのにはびっくりしました。それなりの品質テストに合格させてベンダーブランドとして出荷されるのでしょうが、社内用語とかもわかっててもらっていたエンジニアたちが開発コーディングするのではなかったのにがっかりした(不安を感じた)覚えがあります。

[ゾフィ]

日本のSIerが、トップが現場に来て「説明はいいからソースコードを見せて」なんて言うチームと勝負できるわけないですね。残念なことです。
http://itpro.nikkeibp.co.jp/article/NEWS/20060314/232488/

[Satoshi]

　予想外に沢山の方々からコメントをいただき、感謝しております。しかし、shiroさんの「脚本の作り方も同じ」という点は興味深いですね。ちなみに、それで思い出したのですが、「キャリー」などのベストセラー作家のスティーブン・キングも同じようなことを言っていました。あまり最初からストーリーを決めつけて書くよりも、登場人物の性格設定や状況設定だけを最初に定めておき、後は登場人物自身に物語を作らせるようにすると良いものが出来る、という話だったと思います。

　ソフトウェア作りではさすがにそこまではしませんが、最初にたてたアークテクチャをコードに落とし込む段階で、設計を変更した方が素直にコードが書ける、コードがシンプルになる、ということが必ず生じます。そこで柔軟に設計を変更できるかできないかで、最終的に出来上がってくるものの出来が大きく違って来ます。私はその過程が良いソフトウェアを作るためにとても大切だと信じているし、そこにこそエンジニアが腕を発揮できる「楽しみ」があると思っています。

　その一番大切な部分をないがしろにする、上流→下流というソフトウェアの作り方では、良いものも作れないし、人も育たない、と感じている私です。

[たくゆ]

全く同感です。Satoshiさんの仰ることの背景には、1970～80年代に叫ばれていた「ソフトウェア危機」、そしてその解決として考えられていた「ソフトウェア工学」、すなわちソフトウェアを工業製品として第2次産業的に捉える考え方があるように思います。上流の概要設計から詳細設計、徐々に粒度を細かくして下流のプログラミング、テストに到る、という当時もてはやされたウォーターフォールモデル。私が業界に入った20数年前、すでに上級ＳＥ（コンサル、概要設計）、ＳＥ（詳細設計）、プログラマー（あるいはコーダー）などの職種が厳然と区別され、ゼネコンの様に元請けが下請け、孫請けを搾取する構造はもうすでに存在していました。しかも最も上流の人間はソフトウェアのことを全く知らないにもかかわらず、ビジネスナレッジを知っている俺たちのほうがプログラマーより偉く、より高い給料をもらってしかるべきだ、とうそぶく風潮が強くありました。アメリカではすでに80年代にこのモデルの有効性が徹底的に論破されていたにもかかわらず、日本では官僚がこのモデルのみこしを担ぎ、「90年代にはプログラマー人口が何百万人不足する」などと危機感を煽った旧通産省が「シグマ計画」などで国民の税金を無駄にし、旧郵政省（「機械振興課」！）が「情報処理技術者試験」などで「2種＝コーダー」「1種＝プログラマー」「特種＝ＳＥ」なんていう「下流から上流へ」のノリで業界の覇権を通産省と争っていました。現在のIPAがらみのコメントを読みますと、この状況は本質的には全く変わっておらず、馬鹿の一つ覚えのように詳細設計、コーディングなどと繰り返している官僚の姿が浮かびます。誰も何も考えずにお上に規制・指導されてきたコンピュータ・メーカーやシステム・インテグレータは、こういう業態にどっぷりつかって今に至っているということでしょう。

Satoshiさんのように、プログラマーのあるべき姿を実践し、それを公に発言していくひとがどんどん増えてゆくと、すこしは日本も変わるかもしれないと考えているところです。今はそれを可能にする仕組みがかなりそろってきていますから。それに、そういう手練のソフトウェア技術者が増えてくること、ひいては日本のコンピュータ・サイエンスの教育の充実、これも鍵の一つだと思います。90年代後半、香港科学技術大学のコンピュータ・サイエンス学部がつくられたときには、アメリカの大学・大学院から教授陣をごっそり引き抜いてそのままアメリカのコンピュータ・サイエンス教育を移植してしまった荒業がありましたが、その程度のことをしないと日本のソフトウェアのレベルも容易には上がらない気もします。

[civic]

すみません。トラックバックしたら文字化けしてしまいました。
ざっくり削除しちゃってください。

>十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。
>だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。

非常に共感しました。

[Satoshi]

　たくゆさん、丁寧なコメント、ありがとうございます。国が定めている情報処理試験にまでこの上流・下流という考え方が反映されている、という見方は興味深いです。学生時代に情報処理試験の参考書を手に入れて見たときに妙な違和感を覚えたことを覚えていますが、これだったのかも知れません。しかし、これは結構根が深い問題なんですね。うーん。

[passageiro]

地方でオープンソース系エンジニアをやってると、そんな日本でも流れが変わりつつあるのかなと思います。というのもエンタープライズ系ベンダーのシステムリプレースを請け負うことが増えているからです。

リプレースすべく彼らのシステムを拝見すると、立派な社名とは名ばかりのずさんな内容に唖然とするよりも笑ってしまうことが多々あります。たぶん彼らも、条件さえ許せばもっといいものが作れるのでしょうが、いかんせん価格と品質が釣り合っていません。もしかしたら「東京の」とつくだけでありがたがる地方相手の仕事だからなのかもしれませんけどね。さらに「弊社以外のベンダーが入ると品質が保証できません」という脅し文句のせいか、納入先もオープンソース系への転換に二の足を踏んでいるようです。

それでも彼らの半分以下の価格で倍以上の性能を実現できることが多く、最近はお客さんも増えています。この業界は最先端であるようでいながら、護送船団的構造が色濃く残っているようなので若い人にはオープンソースの世界に飛び込んでどんどん価格破壊を進めてほしいです。

##身の回りにはパソコン黎明史に出てきそうな博物館級のマシンで動くシステムが、「誰もメンテナンスできないけど、とりあえずまだ動いている」状態でたくさんありますよ。失われた10年で地方にばらまかれた公共投資がいろんな形で流れ込んでいるようです。

[Anthony]

satoshiさんが言及されている状況は昔から変わっていませんね。
1990年代、私はいわゆる階層構造の下のほうのソフト会社でプログラマーをやっていました。
しかし色々考えるところがあって仕事でソフトウェアを作ることをやめてしまいました。
ソフトウェア業界で働いていて思ったのはまじめに働ける業界ではないということでした。
コードを書くのは下々の者だなんて思われている環境で誇りを持って仕事なんてできませんでしたね。
その当たりを私のblogでも書いていますので、よかったら読んでみてください。

http://gowest.hustle.ne.jp/blog/archives/2005/06/post_42.html

メーカー系と半官半民企業に支配されている日本のマーケットではピラミッド構造的な産業構造になってしまうのかもしれません。

しかしソフトウェア技術はこれからもっと重要になっていくと思います。
あらゆるものにコンピューターが埋め込まれネットワークでつながるようになるとソフトウェアも複雑になっていくと思います。
このままだとそんな時代にまた日本は乗り遅れてしまうのでしょうね。

しかしなんとかこの状況を改善できないかとも考えてしまいます。
要は日本の経営者の考え方が問題なのではないでしょうか。

[central_dogma]

中島さんの言っていることは家電業界ではそれほどでもないような気がします。
私は大手5～6社の開発の現場を見る機会があったのですが、開発の流れとしては3パターンありました。

①試作機が既にある開発
(1)お試しセット(プロトタイプ基板＋ソフト)を作っている優秀なメーカが数社あり,そこから回路図＋ソフトウェアを購入する。
(2)それをもとに自社で盛り込みたい機能を自社のエンジニアが仕様書にまとめる。
(3)グループ企業の中のソフトウェアの強い企業が開発を担当する。

②メーカに常駐PGが存在する。
(1)基板の設計、開発は自社で行う。
(2)日本には組み込みに強いメーカが数社あり、そこのエンジニアが企業に常駐している。彼らは非常に優秀である。彼らが何年も企業に常駐し開発を行う。

③人材派遣会社から人を集める。
日本には基板開発、プログラムともに派遣で仕事をする人達がたくさんいます。しかしながら、実力差がばらばらで開発もスマートでありません。
この方法の開発体系をいくつかみましたが大抵トラブルを起こしていました。
仕様書を書いたことがないということと,書く人がいつも発注先であるため仕様書を軽視する風潮がありました。しかしながら彼らがオリジナルを仕様書なしで開発し、失敗に到る経験も私は見ています。設計と開発は同じくらい大事なのではないのでしょうか。
だけど、人間的には苦労が多い分、ポジティブで人を思いやるやさしさを持つ人が多かったです。

3つにいえることは大手メーカは基板設計、開発、量産は一流です。しかしながらソフトウェアは3流というか、責任を負わせられるのが怖いためか、自社で行うことはまれでした。組み込みプログラミングは何人も必要ないため、一部の優秀な人間が何度も開発を担当することがほとんどなのではないのでしょうか。
また、現在はMCU(DSP)やOSが複雑になってきたため、ハード、ソフトともにサポートベンダーやRTOSベンダーとの協業を行わないと開発が進みません。したがって、ほぼ全ての大企業がサポート体制を万全にしているため、ソフトウェアの質が低いことはあまりありませんでした。
家電業界では、ほとんどがグループ企業で行われるため、発注の発注はほとんど存在しませんでした。下流のプログラマーの収入の低下というのはないと考えられます。
(他のプログラマ業界のことは分からないです。)

プログラミングできない人間が仕様書を書いているというのは結構ありましたが、すり合わせを頻繁に行う文化が家電業界にはあり、仕様書は開発とともにどんどん変更されていきます。仕様書を書く人とプログラマの間では何度もすり合わせを行います。そのための旅費も会社はきちんと準備しています。
ただソフトウェアがこっち側とあっち側(iPodとitunesような)にまたがり、ソフトウェアの質が商品の質につながる現在、優秀なソフトウェアエンジニアが自社のエンジニアでない場合が多いため、発言権のイニシアチブを取れないことが問題となり、開発者が信頼ある開発者でない場合(経験の薄いエンジニアでその企業の信頼を勝ち得ていない)相当苦労することもまた事実です。
また、毛並みの違うソフトウェア(Webと家電::perlとC)開発は部署間のコミュニティの形成がかぎをにぎるような気がします。

私が思うに、メーカのハードウェア上位の気質が、ソフトウェア開発の軽視や、他企業への発注につながったのだと考えられます。

[Dora]

いつも愛読させて頂いています。

現場からの意見をトラックバックさせて頂きました。参考になれば幸いです。（一応リンクをここにも。）

「日本の受託系ソフト開発の現状」
http://dorablue.blog51.fc2.com/blog-entry-153.html

ではでは、失礼します。

[tak.hasegawa]

はじめまして。いつも拝読させていただいております。
エントリーで語られています"根本的に間違ったソフトウェアの作り方"が何故なくならないかを、デフィンシブなシステム開発・オフェンシブなシステム開発という切り口で論じているエントリーを以前読みました。

http://d.hatena.ne.jp/kuranuki/20060116/p1

企業向けシステムを受託開発しているSIerに身をおく私が常々疑問に思っていた事が明快に示されており、なるほどと腑に落ちた反面、酷く絶望的に思った事を憶えています。

[smallworld]

初めてコメントさせて頂きます．ものすごいコメントの量ですね．私は現在就職活動の身なのですが，私が感じていたことがわかりやすく書かれていて思わず興奮してしまいました笑．私はいわゆるIT企業を志望していたのですが，その多くでまさにsatoshiさんが書かれているように，上流→下流という構図が成り立っており，基本的に大手は上流の部分しかせずに下流の部分はアウトソースするらしいですね．グーグルのようにエンジニアが何から何までやるような企業を見つけるのはなかなか大変そうです．そこで私が出会ったのが外資系証券会社のテクノロジー部門でした．最初私は証券会社のシステムは全部アウトソースしてメーカーの開発しているものを扱っているものと思っていたのですが，実際に話を聞いてみると，システムの90%以上は自社開発でまさにコードも仕様書も自分でやる，というところらしいです．でもあくまで会社は証券会社ですので金融関連の業務が多いとは思うのですが，例えばこういったところでプログラマーとしてソフトウェア開発に関わってきてた人というのは，いわゆるIT市場においても通用できる余地というのはあるのでしょうか？

[Satoshi]

>でもあくまで会社は証券会社ですので金融関連の業務が多いとは思うのですが，例えばこういったところでプログラマーとしてソフトウェア開発に関わってきてた人というのは，いわゆるIT市場においても通用できる余地というのはあるのでしょうか？

　十分可能性はあると思います。私が一緒に仕事をしたことのある人の中には、もともとが理論物理学者で、研究の過程で物理シミュレーションのためにやむなく覚えたプログラミングをいつのまにか本職にしてしまた、という人もいましたから。結局のところ、「プログラムを書いていて楽しいか」、「自分はソフトウェアで勝負すべきか」などを根底に近い部分を重視して決めるのが良いと思います。私のまわりには「ソフトウェアを作るために生まれてきた」ような人たちが沢山いますが、彼らの強さは「経験」ではなく「新しい技術を習得するスピード」と「問題解決能力」にあります。そういった素養さえ持っているのであれば、「金融関連のソフトウェアしか作ったことがない」点にが、ハンデにはなったりはしないと思います。

[smallworld]

私の質問にさっそく答えて頂きありがとうございます．やはりどの業界のプログラマーということではなくて，プログラマーとしての一個人が非常に重要なのですね．まだソフトウェア開発者として重要な要素が全て自分に備わっているかどうかはわかりませんが，とても心強いです．

[estrella_dai]

いつも拝読させて頂いています。
初めてコメントさせて頂きます。

私も皆さん同様、激しく同感です。

私は某SIerでエンタープライズ系のSEをやっています。
新人の頃、開発ができなくて設計ができるわけがない！と思っていて、上司にとにかく開発をやらせてくれ！と何度も頼み、運良くやらせてもらうことができました。それでも2・3年です。
しかし、私の周りの上司や後輩を見ると私と同じ経験をしてる人間はほとんどいません。開発などやったことがない人間が、設計と呼ぶには甚だおかしいレベルの設計書を作成します。そんな設計で開発をやらされる側はたまったもんじゃないなと思います。
プロジェクト原価の面からして、ある程度の年齢になった社内の要員に開発をやらせるわけにもいかず、外注するしか手段はなく、社内における開発スキルは空洞化しています。発注する側の我々でさえそのような矛盾した構造の中で仕事をしているのが現状です。
エンタープライズ系は特にそうだと思いますが、顧客の業務に密接に関わるシステムですから、当然高度な業務スキルが必要になるわけです。開発経験がなく適当な設計書を作成して開発を依頼する設計者も問題ですが、私は開発の人間ですので業務のことは一切わかりませんといった開発者にも困ったものです。
ものすごくグレーで難しいところですが、エンタープライズ系のシステム開発においては、設計者側（発注者側）にはもっと開発スキルを、開発者側（受託者側）にはもっと業務スキルをという構造や流れが生まれない限り変わらないのかな？と思います。