けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月30万円というケースもあるという。こんな話を聞くと本当に悲しくなる。第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月30万円とはあまりにも低すぎる。「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあるが、それにも全く賛成できない。私はこの業界で多くのエンジニアも使ってきたが、優秀なエンジニアとそうでないエンジニアの生産性は(誇張抜きで)20対1ぐらいである。そんな簡単な作業しか出来ないエンジニアとも呼べないようなエンジニアが沢山いてもマネージメントが大変なだけである。そもそも、就職した段階で詳細仕様書に従ってしかプログラムを書けないような人が、ソフトウェアエンジニアになっても幸せになれるとは思えない。許せないのが、そういった上流→下流という階層構造でプログラムを作る工程そのものだ。これに関しては、自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム(もしくはプロトタイプ)の作成にかかるのである。実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。(ただし、そんな作り方で作ったプログラムはソースコードが汚くなってしまうケースが多いので、この段階から出来上がったプログラムを、読みやすさ・メンテナンスの高さを重視して大幅に書き直すことを強く薦める。エンジニアによっては、ここで一度作ったプログラムを全部捨ててしまってもう一度全部作り直す人もいるぐらい、この作業は重要だ。)世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。私が一度働いたことのあるNTTの研究所では、ほどんど自らソフトウェアの開発をしたことの無い人達が詳細資料書を書き、それを外注に発注してプログラムを書かせる、というソフトウェアの作り方をしていた。学生時代からプロとしてソフトウェアを作っていた私は、新入社員にも関わらず「こんなやりかたじゃ良いソフトは作れません」と上司たちにくってかかったのだが、誰一人として理解してくれなかった。私には、この「自分でプログラムを書かない上流のエンジニアが詳細設計書を作り、下流のエンジニアがコーディングをする」という工程そのものが、根本的に間違っているとしか思えないのだ。「下請け」という弱い立場にあり、経験も少ない下流のエンジニアが、「仕事を発注してくれる大切なお客様」である上流のエンジニアに対して、「この部分は、設計を少し変更をした方がプログラムがシンプルに書けるし実行効率もあがると思うんですが、変えちゃっていいでしょうか」などと言うことが出来るとは思えない。下流のソフトウェアハウスの経営者にとっても、そんな余計なことを言うエンジニアよりも、仕様書通りのプログラムを納期以内に黙って作るエンジニアの方が使いやすいのではないだろうか。日本のエンタープライズ系のソフトウェア業界は、そんな根本的に間違ったソフトウェアの作り方を長年してきたために、まるで建築業界のような下請け・孫請け構造が出来てしまい、下流のエンジニア達が十分な経験も得ることが出来ずに低賃金でこき使われ、業界全体として国際競争力をなくしてしまう、という状況に陥ってしまったのではないか、というのが今回の私の仮説である。米国に住む私が得られる限られた情報だけから立てた仮説でしかないので、何か大きな勘違いをしているのかも知れないが、少なくとも今の日本を見ると、階層構造化されたエンタープライズ系のエンジニアたちよりは、オープンソース系の「設計からコーディングまで全部自分でやる」エンジニア達の方がずっと元気があるし幸せそうだ、ということだけははっきりと言える。ちなみに、この話を書いていて思ったのだが、プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューするのは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。レストランに行く側の立場になってみれば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。|Commentsなんというかソフト業界だけでなく半導体業界でもsatoshiさんのいう通りの状況になってます。Level)設計をしたことがない人間が旨い仕様なんか作れる分けないのに、無意味に分業し、しかも、RTLやSystemCによる「テスト」を軽視。何度も繰り返しが起こり、かえって工数を増やしてます。仕様検証を人手、しかも基本的には机上/目視チェックのみでなんとかしようという考え方。複雑な規格に対応するんでなければこんなやり方でもうまくいくのかもしれませんが。一部だとは信じたいです。07:33とんでもなく同感します。08:19私もsatoshiさんの意見に同感です。最近はそれに輪をかけて、プログラムをろくに書いたことがない人が詳細設計書を作るためか工数見積もりが異常な内容になっていることが多いです。他に以前受けた仕事にはとんでもないものがあって、(PCも作ってる有名なところから受けた仕事ですが)最終的にできあがったコードの行数で開発費を支払います、なんてことをやられました。作る→効率的に動かすために手を入れる→結果的にコードはまとめられてコンパクトっていうのが普通の作業手順だと信じてるのですが、これだとゴミみたいなコードがくっついてるほうがいいんかと。効率のいいプログラムを書いたほうが支払われる開発費が少ないなんてこんなプログラマをバカにしたようなことを平気でやる企業があるなんて異常だと思います。私は精神的におかしくなってプログラマは辞めました・・・。Japanでは、新卒も採用しています。興味があれば、uiejapan(アット)uievolution.comまで連絡を下さい。履歴書だけでなく、ブログだとか自分が運営しているウェブサイトなどの情報も送っていただけると助かります。09:51>効率のいいプログラムを書いたほうが>支払われる開発費が少ないなんてこんなプログラマを>バカにしたようなことを平気でやる企業があるなんて異常だと思います。これに関しては、NTTもまったく同じでした。シンプルで短くて読みやすいプログラムよりも、だらしなく長いプログラムを書いた方がお金が沢山もらえる、というシステムになっていました。これでは、良いプログラムが作れるわけがありませんよね。09:53いつも拝読させていただいておりますが、初めてコメントさせていただきます。某家電メーカーに勤めておりますが、satoshiさんのおっしゃることを明言するソフトウェアマネージャーはおりませんし、少なくとも理解している人とは3人ほどしか出会ったことがありません。自分としては、「プログラムを書く」「詳細仕様書を書く」に加えて、「書いたコードのテストをする」ことを開発者が行うことが全体の開発効率を上げることにも、開発者のモチベーションを上げることにもつながると思っています。開発者は、「動いた」ことに満足するだけでなく「すべてのケースで問題がない」ことを喜びとしたいしするべきです。開発者は抜け穴を見落とすことも多いのでさらにその後の段階としてテスト技術者が綿密なテストを行うことも必要ですが、「プログラムを書く」ことで次の人に渡す人も多く、とがめる人は少ないことが品質の低下につながっていると思っています。そもそも、IPAのがソフトウェア技術者試験の試験区分と評価基準に定めている内容が、「プログラムを書く」ことと「詳細仕様書を作る」ことを分離したような内容になっており、経済産業省の影響の大きいIPAがこのようなことになっていることを鑑みるに、国のリーダーシップを取る人がsatoshiさんのような視点でものを見ている人があまりに少ないということではないかと思います。自分がおもっていることにあまり自信がなかったのですが、satoshiさんのような第一線で開発されていた、いや開発されている方が明言されると重みが違いますね。いうことを明言できるソフトウェアマネージャーがいない会社は今後落ち込んでいくだろうと危機感を覚えました。10:05門外漢ですいませんが、私は脚本を書いたり物語をつくったりしている者(アマチュア)です。料理のレシピになぞらえた点を拝読して、「モノをつくるというのは皆同じなんだな」と改めて確認。話をつくるのも始めに構成から入りますが、それだけで「話ができあがる」訳ではなく、それに沿ってト書きや台詞を埋めていって初めて他の人にわかる物語になります。その過程で必ずと言っていいほど「この方が面白そうだ」と話が変化していきます。書き上げた時にははじめの構成とは別の物語が(しかもよりよい完成度で)できあがります。その後の校正で、また全体構成をやり直して書き直すこともあります。構成だけを指示してもよい話はできあがらないと思っているのですが、日本のプログラマの世界では普通なんですね。15:50以前からこちらをのぞかせていただいておりました。あまりにも心が動かされたので、はじめてコメントさせていただきます。私は15年以上システム開発に携わって参りました。satoshiさんがここでかかれていることは、的のど真ん中を射てると思います。私も長年、へんてこな構造に悩まされてきた一人です。ソフトウェア業界に心の病が多いのもこういった構造が少なからず影響しているとさえ感じています。「システムを造る中で、一番偉い人は実装する人である」が私の信条です。16:53うちの会社でも、上流工程だけ社内でやって下流工程は海外へ外注しろ、という方針になっているのですが、それで本当に良いのかなという疑問はありますね。外注を否定する訳じゃないけど、外注するならするで、受注側で設計からテストまで一貫して行えるようにしないといけないでしょうね。17:39以前の業務で売上情報共用Webを発注した時のことです。仕様固めに発注先にお邪魔しエンジニアの方と打ち合わせた時に、「東北の小さな会社がコーディングしているのでこの点の変更は間に合うかわからない」、と言われたのにはびっくりしました。それなりの品質テストに合格させてベンダーブランドとして出荷されるのでしょうが、社内用語とかもわかっててもらっていたエンジニアたちが開発コーディングするのではなかったのにがっかりした(不安を感じた)覚えがあります。17:55日本のSIerが、トップが現場に来て「説明はいいからソースコードを見せて」なんて言うチームと勝負できるわけないですね。18:06予想外に沢山の方々からコメントをいただき、感謝しております。shiroさんの「脚本の作り方も同じ」という点は興味深いですね。ちなみに、それで思い出したのですが、「キャリー」などのベストセラー作家のスティーブン・キングも同じようなことを言っていました。最初からストーリーを決めつけて書くよりも、登場人物の性格設定や状況設定だけを最初に定めておき、後は登場人物自身に物語を作らせるようにすると良いものが出来る、という話だったと思います。ソフトウェア作りではさすがにそこまではしませんが、最初にたてたアークテクチャをコードに落とし込む段階で、設計を変更した方が素直にコードが書ける、コードがシンプルになる、ということが必ず生じます。そこで柔軟に設計を変更できるかできないかで、最終的に出来上がってくるものの出来が大きく違って来ます。私はその過程が良いソフトウェアを作るためにとても大切だと信じているし、そこにこそエンジニアが腕を発揮できる「楽しみ」があると思っています。その一番大切な部分をないがしろにする、上流→下流というソフトウェアの作り方では、良いものも作れないし、人も育たない、と感じている私です。18:19全く同感です。Satoshiさんの仰ることの背景には、1970~80年代に叫ばれていた「ソフトウェア危機」、そしてその解決として考えられていた「ソフトウェア工学」、すなわちソフトウェアを工業製品として第2次産業的に捉える考え方があるように思います。上流の概要設計から詳細設計、徐々に粒度を細かくして下流のプログラミング、テストに到る、という当時もてはやされたウォーターフォールモデル。私が業界に入った20数年前、すでに上級SE(コンサル、概要設計)、SE(詳細設計)、プログラマー(あるいはコーダー)などの職種が厳然と区別され、ゼネコンの様に元請けが下請け、孫請けを搾取する構造はもうすでに存在していました。上流の人間はソフトウェアのことを全く知らないにもかかわらず、ビジネスナレッジを知っている俺たちのほうがプログラマーより偉く、より高い給料をもらってしかるべきだ、とうそぶく風潮が強くありました。「2種=コーダー」「1種=プログラマー」「特種=SE」なんていう「下流から上流へ」のノリで業界の覇権を通産省と争っていました。現在のIPAがらみのコメントを読みますと、この状況は本質的には全く変わっておらず、馬鹿の一つ覚えのように詳細設計、コーディングなどと繰り返している官僚の姿が浮かびます。誰も何も考えずにお上に規制・指導されてきたコンピュータ・メーカーやシステム・インテグレータは、こういう業態にどっぷりつかって今に至っているということでしょう。Satoshiさんのように、プログラマーのあるべき姿を実践し、それを公に発言していくひとがどんどん増えてゆくと、すこしは日本も変わるかもしれないと考えているところです。今はそれを可能にする仕組みがかなりそろってきていますから。それに、そういう手練のソフトウェア技術者が増えてくること、ひいては日本のコンピュータ・サイエンスの教育の充実、これも鍵の一つだと思います。コンピュータ・サイエンス学部がつくられたときには、アメリカの大学・大学院から教授陣をごっそり引き抜いてそのままアメリカのコンピュータ・サイエンス教育を移植してしまった荒業がありましたが、その程度のことをしないと日本のソフトウェアのレベルも容易には上がらない気もします。18:38すみません。トラックバックしたら文字化けしてしまいました。削除しちゃってください。>十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。>だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム(もしくはプロトタイプ)の作成にかかるのである。20:18たくゆさん、丁寧なコメント、ありがとうございます。国が定めている情報処理試験にまでこの上流・下流という考え方が反映されている、という見方は興味深いです。学生時代に情報処理試験の参考書を手に入れて見たときに妙な違和感を覚えたことを覚えていますが、これだったのかも知れません。これは結構根が深い問題なんですね。20:39地方でオープンソース系エンジニアをやってると、そんな日本でも流れが変わりつつあるのかなと思います。いうのもエンタープライズ系ベンダーのシステムリプレースを請け負うことが増えているからです。リプレースすべく彼らのシステムを拝見すると、立派な社名とは名ばかりのずさんな内容に唖然とするよりも笑ってしまうことが多々あります。彼らも、条件さえ許せばもっといいものが作れるのでしょうが、いかんせん価格と品質が釣り合っていません。したら「東京の」とつくだけでありがたがる地方相手の仕事だからなのかもしれませんけどね。「弊社以外のベンダーが入ると品質が保証できません」という脅し文句のせいか、納入先もオープンソース系への転換に二の足を踏んでいるようです。それでも彼らの半分以下の価格で倍以上の性能を実現できることが多く、最近はお客さんも増えています。この業界は最先端であるようでいながら、護送船団的構造が色濃く残っているようなので若い人にはオープンソースの世界に飛び込んでどんどん価格破壊を進めてほしいです。##身の回りにはパソコン黎明史に出てきそうな博物館級のマシンで動くシステムが、「誰もメンテナンスできないけど、とりあえずまだ動いている」状態でたくさんありますよ。失われた10年で地方にばらまかれた公共投資がいろんな形で流れ込んでいるようです。21:04satoshiさんが言及されている状況は昔から変わっていませんね。1990年代、私はいわゆる階層構造の下のほうのソフト会社でプログラマーをやっていました。考えるところがあって仕事でソフトウェアを作ることをやめてしまいました。ソフトウェア業界で働いていて思ったのはまじめに働ける業界ではないということでした。コードを書くのは下々の者だなんて思われている環境で誇りを持って仕事なんてできませんでしたね。その当たりを私のblogでも書いていますので、よかったら読んでみてください。http://gowest.hustle.ne.jp/blog/archives/2005/06/post_42.htmlメーカー系と半官半民企業に支配されている日本のマーケットではピラミッド構造的な産業構造になってしまうのかもしれません。ソフトウェア技術はこれからもっと重要になっていくと思います。あらゆるものにコンピューターが埋め込まれネットワークでつながるようになるとソフトウェアも複雑になっていくと思います。このままだとそんな時代にまた日本は乗り遅れてしまうのでしょうね。なんとかこの状況を改善できないかとも考えてしまいます。要は日本の経営者の考え方が問題なのではないでしょうか。23:58中島さんの言っていることは家電業界ではそれほどでもないような気がします。私は大手5~6社の開発の現場を見る機会があったのですが、開発の流れとしては3パターンありました。1試作機が既にある開発(1)お試しセット(プロトタイプ基板+ソフト)を作っている優秀なメーカが数社あり,そこから回路図+ソフトウェアを購入する。(2)それをもとに自社で盛り込みたい機能を自社のエンジニアが仕様書にまとめる。(3)グループ企業の中のソフトウェアの強い企業が開発を担当する。2メーカに常駐PGが存在する。(1)基板の設計、開発は自社で行う。(2)日本には組み込みに強いメーカが数社あり、そこのエンジニアが企業に常駐している。彼らは非常に優秀である。彼らが何年も企業に常駐し開発を行う。3人材派遣会社から人を集める。日本には基板開発、プログラムともに派遣で仕事をする人達がたくさんいます。実力差がばらばらで開発もスマートでありません。この方法の開発体系をいくつかみましたが大抵トラブルを起こしていました。仕様書を書いたことがないということと,書く人がいつも発注先であるため仕様書を軽視する風潮がありました。彼らがオリジナルを仕様書なしで開発し、失敗に到る経験も私は見ています。設計と開発は同じくらい大事なのではないのでしょうか。人間的には苦労が多い分、ポジティブで人を思いやるやさしさを持つ人が多かったです。ソフトウェアは3流というか、責任を負わせられるのが怖いためか、自社で行うことはまれでした。組み込みプログラミングは何人も必要ないため、一部の優秀な人間が何度も開発を担当することがほとんどなのではないのでしょうか。現在はMCU(DSP)やOSが複雑になってきたため、ハード、ソフトともにサポートベンダーやRTOSベンダーとの協業を行わないと開発が進みません。したがって、ほぼ全ての大企業がサポート体制を万全にしているため、ソフトウェアの質が低いことはあまりありませんでした。家電業界では、ほとんどがグループ企業で行われるため、発注の発注はほとんど存在しませんでした。下流のプログラマーの収入の低下というのはないと考えられます。(他のプログラマ業界のことは分からないです。)プログラミングできない人間が仕様書を書いているというのは結構ありましたが、すり合わせを頻繁に行う文化が家電業界にはあり、仕様書は開発とともにどんどん変更されていきます。仕様書を書く人とプログラマの間では何度もすり合わせを行います。そのための旅費も会社はきちんと準備しています。ソフトウェアがこっち側とあっち側(iPodとitunesような)にまたがり、ソフトウェアの質が商品の質につながる現在、優秀なソフトウェアエンジニアが自社のエンジニアでない場合が多いため、発言権のイニシアチブを取れないことが問題となり、開発者が信頼ある開発者でない場合(経験の薄いエンジニアでその企業の信頼を勝ち得ていない)相当苦労することもまた事実です。毛並みの違うソフトウェア(Webと家電::perlとC)開発は部署間のコミュニティの形成がかぎをにぎるような気がします。私が思うに、メーカのハードウェア上位の気質が、ソフトウェア開発の軽視や、他企業への発注につながったのだと考えられます。02:34いつも愛読させて頂いています。現場からの意見をトラックバックさせて頂きました。参考になれば幸いです。(一応リンクをここにも。)「日本の受託系ソフト開発の現状」http://dorablue.blog51.fc2.com/blog-entry-153.htmlではでは、失礼します。03:22はじめまして。いつも拝読させていただいております。エントリーで語られています"根本的に間違ったソフトウェアの作り方"が何故なくならないかを、デフィンシブなシステム開発・オフェンシブなシステム開発という切り口で論じているエントリーを以前読みました。http://d.hatena.ne.jp/kuranuki/20060116/p1企業向けシステムを受託開発しているSIerに身をおく私が常々疑問に思っていた事が明快に示されており、なるほどと腑に落ちた反面、酷く絶望的に思った事を憶えています。07:59>でもあくまで会社は証券会社ですので金融関連の業務が多いとは思うのですが,例えばこういったところでプログラマーとしてソフトウェア開発に関わってきてた人というのは,いわゆるIT市場においても通用できる余地というのはあるのでしょうか?十分可能性はあると思います。私が一緒に仕事をしたことのある人の中には、もともとが理論物理学者で、研究の過程で物理シミュレーションのためにやむなく覚えたプログラミングをいつのまにか本職にしてしまた、という人もいましたから。結局のところ、「プログラムを書いていて楽しいか」、「自分はソフトウェアで勝負すべきか」などを根底に近い部分を重視して決めるのが良いと思います。私のまわりには「ソフトウェアを作るために生まれてきた」ような人たちが沢山いますが、彼らの強さは「経験」ではなく「新しい技術を習得するスピード」と「問題解決能力」にあります。いった素養さえ持っているのであれば、「金融関連のソフトウェアしか作ったことがない」点にが、ハンデにはなったりはしないと思います。08:37いつも拝読させて頂いています。コメントさせて頂きます。私も皆さん同様、激しく同感です。私は某SIerでエンタープライズ系のSEをやっています。新人の頃、開発ができなくて設計ができるわけがない!と思っていて、上司にとにかく開発をやらせてくれ!と何度も頼み、運良くやらせてもらうことができました。それでも2・3年です。私の周りの上司や後輩を見ると私と同じ経験をしてる人間はほとんどいません。開発などやったことがない人間が、設計と呼ぶには甚だおかしいレベルの設計書を作成します。そんな設計で開発をやらされる側はたまったもんじゃないなと思います。プロジェクト原価の面からして、ある程度の年齢になった社内の要員に開発をやらせるわけにもいかず、外注するしか手段はなく、社内における開発スキルは空洞化しています。発注する側の我々でさえそのような矛盾した構造の中で仕事をしているのが現状です。エンタープライズ系は特にそうだと思いますが、顧客の業務に密接に関わるシステムですから、当然高度な業務スキルが必要になるわけです。開発経験がなく適当な設計書を作成して開発を依頼する設計者も問題ですが、私は開発の人間ですので業務のことは一切わかりませんといった開発者にも困ったものです。ものすごくグレーで難しいところですが、エンタープライズ系のシステム開発においては、設計者側(発注者側)にはもっと開発スキルを、開発者側(受託者側)にはもっと業務スキルをという構造や流れが生まれない限り変わらないのかな?と思います。11:16まったくそのとおりだと思います。私もPHPやRubyを使って、40過ぎてもプログラムを作っています。プログラムに創造性が含まれると思っています。仕様書だけ書いてプログラムを外注するようなシステムは、銀行のオンラインプログラムやEコマースサイトのように、中身は複雑でもオリジナリティのないものではないでしょうか?目を見張るクールなプログラム、新奇性のあるプログラムは、人に任せることはできません。それは数学上の新しい仮説やアルゴリズムを考え出すように、オリジナリティに満ち溢れたものにちがいありません。どちらのプログラムを作り出すかによって、全然種類の違うプログラマーであるはずです。普通のビルや家を作る建築会社、設計士か、それともアントニオ・ガウディのような建築家か、まったく違うものであるはずです。大前研一氏が、前者を知的ブルーカラーと呼んでいて、後者の知的ホワイトカラーと区別していました。11:20『SOAについて、技術的なことは分からないが、経営にとって重要だ』。ある上流コンサルタントが発した言葉である。このフレーズを聞いた瞬間に、ソフトウェア業界の階層構造における問題点があることを実感した。自分が仕事を委託する側であったとしたら、分からないひとに任せたくないからだ。反対に、技術だけでビジネスを知らない場合も同様だろう。その後、ゼロからシステム構築を行っていた頃を思う出すことが多くなった。一緒に開発していた外資系コンサルティング会社でも、既に社内の階層構造ができあがっていた。経営コンサルタントはSEやプログラマよりも高収入を意味していた。現場のプログラマの不満は、自分を含め当時と変わっていないのではないだろうか。彼らの強さは「経験」ではなく「新しい技術を習得するスピード」と「問題解決能力」にあります。Satoshiさんのご指摘に同感です。ソフトウェア開発では、生産性向上の工夫が開始され、例えば、カレンダーモジュールの共通化や画面モジュールの標準化など、優秀なエンジニアの生産性は一般のプログラマと比較して、数倍、いや、二桁は違っていたと記憶している。元米サン創業者のひとりであるビル・ジョイ氏も、ソフトウェア開発シーンは誰よりもロジックが先行し、キーボードは休むことなく連続して動いていたという。問題・課題を解決するためには、幅広く良質な情報を選択しなければならない。次に、情報にプライオリティ付けし、再利用できるよう、効率化や工夫を実施する。リミックス繰り返しながら、新しい自分のアイデアを反映して行く。『情報』を『知識』に転換する必要があるだろう。組織としては、個人が持っている『知識』や『暗黙知』を高く評価する仕組み・文化を醸成する必要があると思われる。process』と呼んでいる。欧米式の成果主義は、プロセスよりも結果を重視している。良い結果を導き出すためには、優秀なプロセスを伴っているものと予想される。最近、米国の経営書を読んでいると、米国IT企業トップの経営ロジックに関する意見・見解が増えている気がする。14:35みなさんのコメントを読んでいて、友人の言葉を思い出しました。「B29を竹槍で落とすような仕事だ。」これが日本の受託系ソフト開発の現実ですね。トラックバックしたのですが、反映されないので再掲します。「日本の受託系ソフト開発の現状」http://dorablue.blog51.fc2.com/blog-entry-153.htmlではでは、失礼します。15:29毎回楽しく拝見しています。私もSEの端くれで40歳を越えましたしが、いつでもプログラムを書くことをモットーに仕事に望んでいます。さんのご活躍はいつも励みになります。業界全体として国際競争力をなくしてしまう部分で、私も日頃から危機感を感じています。そのためにはどうアクションを起こせば良いのか、まだ答えは見つかりませんが、少しでも改善できる方向を模索しています。17:18こんにちは、はじめまして。「上司たちに食ってかかったのだが、誰一人として理解してくれなかった」という部分が気になったのでコメントします。その「上司たち」も、若いエンジニアがシステムの要求仕様を把握して、設計から製造、試験までトータルに実施してくれることを心強く思っているはずですが、気にしているのはリスクだと思います。若くて高度な技術力を持ったエンジニアは、たしかに何も言わなくても何でもソツ無くやってくれてありがたい反面、じゃあその人(たち)が途中でごっそり居なくなったら(病気になってぶっ倒れたら、もっと待遇の良い会社に引き抜かれたら)どうなるのか?その開発プロジェクトは一気に危機的な状況に陥るかもしれませんね。品質はどうでしょう?開発の全工程を少数精鋭固定メンバで実施すると、仕様から設計に落とし込む際に、プログラムコーディングの都合の良いように仕様を解釈したり、考慮漏れが発生しやすくなるというリスクがあります。昨今の多様化、複雑化した要求仕様から設計して、製造して、試験するという一連の作業をそこそこの生産性で品質よくトータルに実施するというのを、「上司たち」はオーバーワークじゃないかと思うわけです。たしかにプログラムを作ったことが無い人に設計出来るのか?と言われれば、ノーと言うしかないのですが、それと「設計した人が製造もやった方が良い」というのは別問題だと思っています。ソフトウェア会社に夢を感じて入社したばかりの人が、職場で最初に経験するのは何でしょう?喧騒のうちに突き進む開発プロジェクトの中で、何とか泳いでいるという感じじゃないでしょうか?それで数年立ったときにその人は何になれるのか?・・・まずいのは、新人から上級マネージャまたは上級エンジニアに至るまでのキャリアパスが曖昧になっていて、各段階での育成方法が確立していない、下手をすると議論すらされていないという状況下で、多くの人が不況にもがき、解決に向けて投資もままならない・・・という現状に不安を感じているということじゃないでしょうか。19:46ノブりんさん、新人時代の私の判断なので間違っているかも知れませんが、当時の上司達は、そこまで考えていたとは思えません。それよりも、「このやりかたで今まで何年もやってきたのだから、いまさら変えるとなると大騒ぎだ。私達には私達のやりかたがあるのだから任せておけ」的な反応がとても強かったのを覚えています。当時(1985年)は、NTTも民営化されたばかりで勢いもあり、内部に危機感は全くありませんでした。その時にも思ったし、今も思うのですが、大きな会社において「自分自身がこれまでのやりかたを変える人になる」というのはとてつもないエネルギーが必要なので、99%の人はそこは回避してしまうんですね。08:16いつも楽しく読ませてもらっています。システム系の皆さんに比べたら超お気楽なゲームプログラマです。いやぁみなさん苦労されてるんですね。プログラム書いたことのない人に実装の詳細まで指示されるなんて、全くあり得ない世界ですね...ゲーム開発の現場では当然SEはおりませんので、設計から実装までプログラマが行うのは当たり前です。具体的には、まずゲームシステムのプランがあって、絵があって、こんなふうにリアルタイムで表示したいんだけど出来る?ってデザイナやプランナに聞かれて、あとは全て任せてもらえます。やりがいありますよ~~。あとは、若くてかわいいデザイナの女の子がたくさんいるところがゲーム開発現場の良いところですかね(笑)そのかわり仕様変更が頻繁で、プランナやデザイナの作業の遅れを最終的に全てプログラマが尻ぬぐいしなければならないので、ラストはめちゃめちゃ残業することになりますけれど。プログラマの生産性の話、同感です。20倍の差はホントありますよね。最近、生産性の差は集中力の差なのかなぁと思ったりしています。web構築(システムやプログラムも含む)でも同様です。内部外部の差がある話ですが、使い勝手がよいものなら頼むのも作るのも容易だろうといったユーザの視点に立たない依頼態度をもとに、価格も期間も削られる地方(特に地方省庁や行政の)意識の深さ(ミーハーと不勉強)はなお痛いです。01:02こんにちは、はじめまして。設計側に開発スキルが必要という点、同感です。「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」はその通りですね。仮設計-->仮開発(orプロトタイピング)という方法論も、深いですね。効率性としては納得ですが、オフショアの場合に興味があります。ぼくは企業財務系システムのSEしてます。開発はインドにオフショアリングです。インド人は金融の素人です。勘違いしてとんでもない開発をしてくることもありえます。ゴールを勘違いして、「船が山にのぼる」リスクがあります。まずければいったん開発しても「ちゃぶ台ひっくり返し」(笑)ですね。インドに渡す前に開発はじめろよ、とおっしゃるかもしれませんが、それではインドの体制を厚くした意味がなく、コスト削減・スピードアップになりません。「仮設計」と言われる部分に工夫する必要があるのかな、と感じています。オフショアなのでインド開発側と設計側との場所が離れています。それにSOX対応でユーザー要件の設計書ベースの受け渡しが必須です。この場合、十分にユーザー要件を記述したドキュメントは開発前に必要です。Satoshiさんは詳細設計せずに仮設計だけでプログラムを始め、未知数の部分をイメージし肉付けしていく。アジャイル開発の手法に近いですね。Front」をつくれ、それも開発者ではなくリーダー(ゲームならディレクター?)がデザインしろと言ってます。アジャイルではないんですね。ユーザーが体験するサービスをできるだけ書き込んでおけ、後で変わってもいいと。プロトタイピングと同じ趣旨ですが、ユーザー要件仕様書ですね。Design」も変わってきます。ちなみにここはアウトソースのようです。Interviewなどの手法で、どう使われるのか開発側にイメージさせてあげるのが効果的なのかな、と感じています。11:29エンジニアを10年経験して非常に共感しました。出来る人ほど常に完成(動く)ソフトウェアを作ることからはじめています。最終的なできあがりとのギャップがないようにしています。本当に料理のレシピだと思います。最終的な美味しい料理を作って最後に顧客が自分で味の調整や料理が自分でできるようにレシピを作っておく。料理を作ったことないシェフが集まったレストランでレシピと料理の想定図ばかり作って別の調理人に作らせて結果まずい料理をお客に出す店が本当に多いです。本当に美味しい料理を出す小さな料理屋に気がつく顧客も少ないのも今の現実ですかね。私は、ジジイになっても料理場で美味しい料理を作るシェフでい続けたいです。07:26前にも書きましたが、ほとんどコードレベルの仕様書は作る必要がないと思っています。自動的に作れるものは、全て自動で作るべきでしょう。本文にもあるように、これを納品先の方に理解していただくのは難しいと思いますね。そのため、ツールを使うメリットを強調して、切り抜けるようにしています。みんなの無駄な作業が減る、何かの参考になれば。02:27●関連サイトも書いておきますね。02:39おいしいわけがない、とまで言えるのかなぁ?むしろ伝わらないところに問題が出てくるんじゃないだろうか。02:27すごく同感したので、はじめてブログというものにコメントさせていただきます。現在所属する会社がまさに完全な下請けで、上から指定された何とも使い勝手の悪い開発環境で、ご大層な設計書をもとにつくられたシステムの中身をみて驚きました。オフショアに出したときに書かれたと思われる意味不明な変数名、変な日本語コメント、その後いろいろな下請け会社がくっつけていったと思われる様々なレベルのコード。設計から実装まで一貫してやっていればそんなことにはならないのにと思うのですが、なぜ日本のこの業界は上流・下流という構造なのか理解できません。ものづくりとか技術が日本の強みとか言うわりにこれでは...と悲しくなります。「創る」ことが好きな自分としては設計から実装まで全部やりたいと思うのです。自分は大手SI企業のように設計にだけ携わった物には責任が持てません。こんな考え方はきっと会社には理解してもらえませんが。04:22自分はプログラマーです。文章から熱い感情と思いやりが感じられる素晴らしいコラムだと思い居ても立っても入れなくなりコメントしました。業界の事より今ある事しか見えなくなる時があり反省をしました。思い込みなんでしょうね。プログラム経験のないステレオタイプ指向の人の言う事なんでしょう。18:56うーん、月30万か...インド人Javaプログラマーでも4,50万は貰わないと、やってけなかったなw真面目に答えるとプロトタイピングがすらできない「開発リーダー」が都市銀行の第三次オンライン位まで確かに「存在」した。情報系だけでもCOBOL換算で最低500万STEP以上あるから、アーキテクチャの基本設計以外は構造化設計して仕様書「だけ」で分割するより方法がなかった。仕様書の変更に20個のハンコがいる稟議書制度でっていうと信じられないだろうが、事実だった。逆に言うと(特にメインフレーマー)SEにはキーボードすら打てない人間ができてしまう。実際に元日本IBMの上司が電子メールを秘書室に「打たせていた」(社長が激怒したが)。RADやプロトタイピング、オブジェクト志向型言語(クラス)がでてくる訳だが中々採用されなかった。COBOLとPL/1(最悪は)RPGしか使ったことのない人間に理解できなかったから。膨大な無駄だったが「日本的」業務は「個別対応」すべきだと主張して結局はERPに全て淘汰されてしまった。この体質を持ってる人間が管理職レベルにいるから零細SIPSあたりはもう悲惨。勝手に原価割れの仕事取ってくるは勝手に無料で仕様変更を認めてしまうは未だに生産性が極めて低い。いうブラックにいるのならsatoshiさんの様に自ら勉強して生き残りをしなければいけないが、ちょっと優秀で素直な人間は上から言われることを鵜呑みにしてしまう癖がある。嫌な思い出が思い出がある。satoshiさん位の歳に社長と掛け合って新人コンサルタントの講師をした。会社初めてのUNIX研修。telnetでloginしてviとgccでサンプルプログラムをコンパイル実行するだけなんだが、反応は良かった。逆に上司からは恨まれた。オフコンの運用に使う筈の新人だったから。半年後、その新人に会ったらリースシステムの運用管理をしていると言う。「やっぱホストっすよね!」目を輝かせていた。S/38(AS/400ですらない)は「ホスト」とは云わん。半年後、RDBMSの外資に転職した。300人のRPGプログラマーを喰わせてやって欲しい、と。実際3年以内に全員クビにされたそうだ。なると誰が悪いのか良くわからんね。18:07いつも拝読させて頂いています。私はエンジニアの生き方を読ませていただきました。私は現在就職活動中の4回生です。私はIT業界で中島さん本で述べていた「客が何を本当に必要としているのかを見つけ出す」というレストランのウェイターのような役割のSEを目指しています。09:32大きなプログラムを一人で書いたことがあり、ソフトウェア開発の全体像を分かっていることが、効率の良いプロジェクトの上流プログラマに求められる条件なのは当然なのに、現在のありかたは非効率で理不尽だと本当に同意します。プログラミングというものづくりはもっと創造的であるべきで、ストレスにまみれた泥仕事であってはならないと、一人のアマチュアプログラマーが願っています。このような記事を通して、少しでも多くの方が影響されて考えを変えれば良いのですが。20:18大きなプログラムを一人で書いたことがあり、ソフトウェア開発の全体像を分かっていることが、効率の良いプロジェクトの上流プログラマに求められる条件なのは当然なのに、現在のありかたは非効率で理不尽だと本当に同意します。プログラミングというものづくりはもっと創造的であるべきで、ストレスにまみれた泥仕事であってはならないと、一人のアマチュアプログラマーが願っています。このような記事を通して、少しでも多くの方が影響されて考えを変えれば良いのですが。20:18とても共感します。勝海舟はこういう言葉を残しています。『アメリカでは、政府でも民間でも、およそ人の上に立つものは、みなその地位相応に怜悧でございます。この点ばかりは、まったくわが国と反対のように思いまする』鳩山元首相やら菅元首相を見ると、こういうのは日本人の体質なのかもしれません。全体を監督する立場の人に必要な能力とは何なのか?サッカーボールに触ったことの無い人がサッカーチームの監督になんてなれるはずがない。TypepadTop。