初音ミクに感じた「それ」
Haloを作ったBungie StudioがMicrosoftからスピンアウトした件について

「渡された仕様書を実装するサラリーマンプログラマ」の悲哀

 @ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。

チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。

業務用途でRubyを使う上での課題 − @ITより引用】

 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッカーが警告したとおり、そこに第二次産業におけるマスプロダクションの手法を取り込んで「ソフトウェア工場」を作ろうとすること事態に無理があるのだ。

 この一番肝心なところを勘違いして国内のIT産業を長年「保護育成」してきたおかげで、業界はいびつな形で育ち国際競争力をすっかりと失ってしまっている。その結果そんな会社に投資した株主たちが損するだけならばまだ良いのだが、不幸なのはそのまっただ中に自分のキャリアパスをはめ込んでしまい、この記事で思いっきり見下されてしまっている「渡された仕様書を実装するだけのサラリーマンプログラマ」になってしまった人たち。

 私も実際にそんな立場にある人と飲みに行ったことがあるのだが、彼が「私の仕事なんて所詮、人が書いた『仕様書』をマシンが理解できる『プログラム』に翻訳するだけの仕事。クリエーティビティなんてこれっぽっちも必要ない」と嘆く姿を見て、どう慰めて良いものか分からなくなってしまった。

 Railsはプロダクティビティを格段に上げると言われているが、この手の進化が目指すところは、最終的には「人間が書く仕様書=マシンが理解できるプログラム」の世界。そんな世界が実現されれば「渡された仕様書を実装するだけのサラリーマンプログラマ」は必要なくなってしまう。

 プログラマとして生きて行くつもりなら、「渡された仕様書を実装するだけのサラリーマンプログラマ」よりは遥か上を目指すべき。そうでないなら、他の仕事を探した方が良い。自分のキャリアパスを見つけ出す責任を持つのは、会社でも上司でもなく、自分自身なのだから。

Comments

Dora

こんにちは。

日本の企業で人が書いた『仕様書』がまとなことなんてめったにないので、本人の意識次第でどんどん上流に上がっていけると思います。淘汰されるか生き残るか。全ては本人次第だと思います。

ではでは。

サラリーマンプログラマ

これはやヴぇい!
危機感を感じました。

お世話になってます

>Doraさん

「ソフトウェアの仕様書は料理のレシピに似ている」を始めとした中島さんのエントリをきちんと読んでいれば【上流】なんて言葉はでてこないと思います。ぜひとも読んで頂きたい。

まちゅ

> ドラッカーが警告したとおり

この箇所に興味を持ちました。できれば出典を教えていただけないでしょうか。

satoshi

>この箇所に興味を持ちました。できれば出典を教えていただけないでしょうか。

ドラッカー氏の本はたくさん読んだので具体的にどの本の何ページだったかは覚えていませんが、おすすめは、ここでも紹介している「明日を支配するもの」です。彼はこの本で知識労働者の生産性の向上がこれからの鍵であり、その答えは肉体労働者の生産性の向上とは大きく違う方法を採るべきだと主張しています。これはまさに私がここで指摘したい日本のITゼネコンの問題点。知識労働者を肉体労働者のように扱っては生産性も上がらなければ国際競争力もつけることはできない、ということです。

humu

わたしも職業プログラマの一端ですがその実

・要件定義,基本仕様書,詳細仕様書,エライ人に説明するためのプレゼン資料
・プログラム,実装,デバッグ,テスト,導入
・現場への説明,レクチャー指導,取り説作成,改善内容の調査から実装まで
・満足度向上のための御用聞き,Etc

全てやります・・・少なくともわたしのいるところでは上流とか下流とか無いです
それ以前に人手は足りないけどやることだけは沢山あるのでなんでもやらないと
会社が回りません・・・
プロジェクトによってある程度の分担はありますが,全員攻撃,全員守備みたいなサッカーです

サラリーマンプログラマ予備軍

いつも拝見させて頂いております。
エントリーの総論としては同感です。一点だけ指摘させて頂きます。
>この一番肝心なところを勘違いして国内のIT産業を長年「保護育成」してきたおかげで、業界はいびつな形で育ち国際競争力をすっかりと失ってしまっている。
http://enterprise.watch.impress.co.jp/cda/topic/2007/10/01/11267.html
最新の調査では日本のIT産業の国際競争力は世界第2位だそうです。
仮に競争力が無いとしても、原因は「保護育成」ではなく、
http://d.hatena.ne.jp/kibashiri/20070323/1174629051
このエントリーで書かれているようなことにあると私は思います。
「保護育成」とは具体的にはどのようなことでしょうか?

kazumichi

世界市場向けのソフトウェア開発を真剣に行えば
自然と国際競争力が出てくるのではと思います(^-^)b

satoshi

 「保護育成」の話はコメント欄では語りきれないような話ですが、電電公社時代から電話交換機を作る国内の会社を特別扱いしてきた件から始まって、最近の携帯電話機事業まで、日本では色々な「保護育成」をしてきています。ソフトウェアに関しても、官庁のシステムにしても銀行のオンラインシステムにしても、資本主義とは思えないようなことがされて来たことは否定できないと思います。そういう制作は、短期的には効果的だったんですが、結果的にはメーカーから国際競争力を奪うことになってしまいました。
 特にソフトウェア産業に関して言えば、ここ20年ぐらいの間の米国でのプログラマの地位(収入・労働環境を含めた)の向上は著しいものがあります。それに比べて日本でのプログラマの地位は低すぎます。私から見れば、それの根本的原因は日本独特のゼネコン型ソフトウェア開発で、それが劣悪な労働環境を作り出しています。

山崎

完了責任を伴うシステム開発の受託において、集団の中の個が持つクリエイティビティはマネージャにとってリスクと捉えられがちです。
そんな受託案件を次々渡り歩くようなスタイルで、そこに万年居続けるとキャリアパスを描くのもそれはそれで厳しいし、会社全体がそうした傾向をもっていると、中島さんがおっしゃっている「遥か上」を目指そうにもモデルケース不在となっていることもしばしば。
気付けばサラリーマンプログラマは翻訳機として機能するしかなくなっていたりします。

なかなか難しいところだとは思います。
僕は会社を辞めて起業することでしかその活路を見出せなかったのですが。

satoshi

>全員攻撃,全員守備みたいなサッカーです

仕事に対する熱意が伝わってくる言葉ですね。がんばってください。

satoshi

>僕は会社を辞めて起業することでしかその活路を見出せなかったのですが。

 キャリアパス作りの最終責任は本人にあることを考えれば、転職や起業という選択肢も含めた上で考えることは当然だと思います。「会社は何もしてくれない」と本気で思えるのだったら、別の選択しを真剣に考えるべきとき。自分がやりたいことのベクトルと、自分が属する組織のベクトルが一致したときが人間一番ちからがだせますから。

done

>山崎
>仕事に対する熱意が伝わってくる言葉ですね。がんばってください。

偉い方が訪れた。

サラリーマンプログラマ予備軍

お返事ありがとうございます。エントリーとは直接関係無い話で恐縮ですが、コメントについてお返事させて頂きます。
>電電公社時代から電話交換機を作る国内の会社を特別扱いしてきた件から始まって、最近の携帯電話機事業まで、日本では色々な「保護育成」をしてきています。
この部分については私も存じ上げております。
>ソフトウェアに関しても、官庁のシステムにしても銀行のオンラインシステムにしても、資本主義とは思えないようなことがされて来たことは否定できないと思います。そういう制作は、短期的には効果的だったんですが、結果的にはメーカーから国際競争力を奪うことになってしまいました。
NTTグループ、日立、NEC、富士通等のメーカーのことでしょうか。上記のようなメーカーがシステム案件の国際競争力が無いというのであれば、私も同じ認識です。では、海外でこれらに相当するメーカーで、システム案件の国際競争力があるメーカーは存在するのでしょうか。
>ここ20年ぐらいの間の米国でのプログラマの地位(収入・労働環境を含めた)の向上は著しいものがあります。それに比べて日本でのプログラマの地位は低すぎます。
この部分についてはおっしゃる通りだと思います。
>私から見れば、それの根本的原因は日本独特のゼネコン型ソフトウェア開発で、それが劣悪な労働環境を作り出しています。
保護育成と国際競争力の話からずれてしまったので、これは分けて語る必要があると思います。一部のプログラマの労働環境で、おっしゃる事象が発生しているのは事実ですが、それは日本の開発体系が原因ではなく、日本の雇用事情が原因だと私は思います。保護育成については私と同様の認識であることが分かりました。ですが、日本のIT産業について語る場合、保護育成、国際競争力、労働環境、IT産業内の業種、プログラマの地位は分ける必要があると思います。お返事では保護育成と国際競争力の相関については、一部のシステムメーカーやハードメーカーにしか当てはまらないと思います。研究・ソフトウェア・サービスでも保護育成され、国際競争力が無いというのであれば、ご教示頂けないでしょうか。これ以上コメント欄でやり取りするのはご迷惑かと思いますので、記載のメールアドレスへお返事頂ければ幸いです。

yama

「遥か上を目指す」ためには具体的にどういうアクションを起こせばいいのでしょうか。
起業するとかアメリカに渡るとかかなり思い切った行動をとるしかないのでしょうか。
遥か上を目指す意識はあっても何をすればいいのかわからずにいる人も多いような気がします。

HALion

>本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、
>建物をデザインするのと同じ「創作活動」である。
僕もそう思います。
会社員として、と言うか線表に沿ってプログラミングせざるを得ない環境だと
そうはなかなかいかないでしょうけど。

>不幸なのはそのまっただ中に自分のキャリアパスをはめ込んでしまい~
中小企業でプログラマやってるとそうなりやすいですね。自分のことですが(^^;)
「ソフトウェアの仕様書は料理のレシピに似ている」でも書いてらっしゃいますが、
大手SIerでPGやらずにSE的な業務をやらされるのも不幸ですよね。

>プログラマとして生きて行くつもりなら、
>「渡された仕様書を実装するだけのサラリーマンプログラマ」よりは遥か上を目指すべき。
ほんとそう思います。
こう思ってる人はけっこう多いと思います。
しかし現実問題そういうPGにならなくても今のところは生活できているので危機感を感じず
サラリーマンプログラマで妥協しているんだと思います。
そうは思ってもなかなか行動に移さない・・・。不思議ですね。
#そんなことよりもっと不思議なことがあるんですが!・・・

中島さんの引用のオウム返しみたいなコメントになってしまいましたが
せっかく書いたので投稿させていただきます。

anonymous

1. コードのスパゲッティ化と仕事の形態は全く関係ない。言われたことを実装するだけの人でもメンテナンス性の良いコードを生産する人はいるし、フリーの人間や芸術家気取りの中でもスパゲッティを生産する人間はいる。言われたとおりにコーディングする職業を不当に貶めていないか。

2. コーディングが「創作活動」であるなら、「人間が書く仕様書=マシンが理解できるプログラム」の世界の実現はおそらく100年単位で先になると思われる(創造的な音楽や文学を機械的に生成するという研究が未だにほとんど成果に結びついていないことを考慮せよ)。どのタイムスパンで議論をしているのか。意図的に恐怖心を煽ろうとしていることはないか。それともSFと現実の区別があいまいになってはいないか。

3. コーディングとは、仕様通りにコードを生成することに他ならない。仕様を作るのが自分か他人かの違いはある。だが、仕様の変更権が仕様を書く人間には与えられない場合もある。他人の仕様を他人の言うとおりにコードに落とすことが下等な作業であれば、自分で自分に仕様を書くように命じ、自分で自分の仕様をコードに落とすように命じる人間がもっとも高等な仕事をしていることになる。コーダーとしての価値を高めるために企業のリソースを使うことを選び、仕様に対する影響力を捨てるという選択は考えられないのか。

あっき

> 「遥か上を目指す」ためには具体的にどういうアクションを起こせばいいのでしょうか。

質問されている本人ではないのですが、思うところを少々言わせてもらいます。厚かましくてごめんなさい。

satoshiさんがおっしゃっている「遙か上」は、そんなことやってないで料理人のようなプログラマになれということかと。

まあ、本人に伺ってみないことにはなんとも、、、ですが。

yamamo

少し上の方へ。
「人間が書く仕様書」っていつまでもOfficeで書いてるわけでなし,例えば(組み込み方面ですみませんが),MATLAB+Simulink→C,HDLソース生成とか。
Web方面含め単なるコードへの翻訳作業に終始する作業(者)は,既にツールやフレームワークにリプレースされつつあるんじゃないですか。

aJapaneseSE

乱暴かもしれませんが、私見を。

以下、IT産業=ソフトウェア+サービスとして考えております。
ハードウェアは抜きです。

○日本のIT産業に国際競争力が無い?

理由1 経営者がエンジニアをコストとして捉えている
→投資として考えるマインドがあればもちっとマシなのかもしれません。

理由2 日本人はエンドユーザ・経営者を問わずソフトウェアに対する評価が低い
→ハードウェアやブランド物には金払いがよいのに…
PCはゴージャスなのに1ライセンスのMS Officeをコピーしている
会社がなんて多いことか(ITの会社だったりする)
こんな文化?国民性?ではIT産業が成長しません。

○IT産業の中でプログラマーの地位が低い

これは事実ですね。本当のPGはスゲエ売り上げやスゲエ
コスト圧縮を実現可能なのですが…

理由1 日本の会社ではゼネラリストが好まれる。
→マネージメントしやすい「サラリーマン」が重宝されるんですね。
どんなに技術力のあるPGでも能力が偏っていたり
性格が尖っていたり仕事を選ぶやつは疎まれる。

つまり会社側が、エンジニアが特定の分野の
プロフェッショナルと化すことを望んでないのです。
会社はなんでもこなせるゼネラリストを望む。
テスター兼PG兼SE兼PM兼営業…結果として採用人数を
抑えることができ、固定費が下がります。経営は楽になりますね。
仕事量が多かったとしてもサービス残業させればいいですから。
(サービス残業を受け入れる労働者が一番タチが悪いようにも思います)
 
(c) エンジニア・マインドに乏しい?

エンジニアとしてではなく、サラリーマンとして就職しているようです。
技術力をつけるだけでなくエンジニアとしての気概みたいな
ものを身に付けていってほしいですね。

以上、なんちゃってエンジニアの戯言です。

Be aGlobalSE!

>プログラマとして生きて行くつもりなら、「渡された仕様書を実装するだけのサラリーマンプログラマ」よりは遥か上を目指すべき。そうでないなら、他の仕事を探した方が良い。自分のキャリアパスを見つけ出す責任を持つのは、会社でも上司でもなく、自分自身なのだから。

同感です。と、いうよりも日頃から痛感してます。

>つまり会社側が、エンジニアが特定の分野の
>プロフェッショナルと化すことを望んでないのです。
>会社はなんでもこなせるゼネラリストを望む。
>テスター兼PG兼SE兼PM兼営業…

これも同感。で、最後の「テスター兼PG兼SE兼PM兼営業…」すべてについてプロフェッショナルを目指し日々努力し続けることが、私にとっての「遥か上」であり「目指すべき」方向性なのかなと。私はテクノロジー大好きな「理科系おたく」なので、文科系の人には真似できない領域にまで突っ込んだ「ものづくり」ができるスゲエ・エンジニアになりたいなぁ、と常々思ってます。たとえ戯言だと言われても、、、

好きな言葉は
テネーシャスネス(tenaciousness)
諦めの悪さは天下一品!(笑

yama

> satoshiさんがおっしゃっている「遙か上」は、そんなことやってないで料理人のようなプログラマになれということかと。

その料理人のようなプログラマを目指すにはどういうアクションを起こすべきですかと、
お聞きしたかった訳です。
料理人を目指したいのに、毎日ハンバーガーしか食べないような人ばかりの国に住んでいるよ
うなジレンマを感じている人も多いんじゃないかと。


ところで、日本のプログラマの地位や意識が低くなっている原因となっている、設計と実装が
工程としても担当者としても分かれているような開発スタイルは、やはり日本独特のものなん
でしょうか?
microsoftやgoogleはともかく、いわゆる業務系ソフトを開発している現場はどうなんでしょう。

satoshi

 MicrosoftやGoogleでは、たとえ業務用のソフトウェアであっても、「設計する人が自らコードを書く」のが基本です。別のエントリーにも書きましたが、どんなに賢い人でも実際にコードに落とす段階にならないと見えないことがたくさんあり、そこで柔軟に設計変更ができない限りは良いものは作れません。

 ウォーターフォール型の開発の一番の欠点は、この「いざ実装してみないと見えてこない設計の問題点」が、妙な上下関係があるためにキチンとフィードバックされないこと。特に純粋に「人月工数」で仕事を請け負っている下請けとしては、「こうした方がコードがシンプルになり、工数がすくなくなる」とは口が裂けても言えない。逆に上流にいて実装にタッチしない人は、いかに自分の書いた仕様書がどうしようもないか、ということにいつまでたっても気がつかない。結果的に全体の効率が落ちて莫大な開発費がかかってしまいます。

nago

To: satoshiさん。
フィードバックしない状態で開発しているというのは、手法以前の問題ではないですか?
実装を受けもっているのなら、上下など関係なく、実装の観点で問題を指摘するのは義務ですし、
スルーしているような所に設計の発注をすることはないですよ?

「設計に問題があろうと、そのまま黙って実装する。」
それこそ"サラリーマンプログラマ"だと思うのですが…。

To: yamaさん。
↓こんな図が作られたりしてます。海外でも似たようなもんですね…。
http://img.worsethanfailure.com/images/200710/codeToRuin.gif

雨宮

HALion氏のコメントに激しく同意。

真に駄目なのは、一緒にのみに行った人のような、「渡された仕様書を(何も考えずに)実装するだけのサラリーマンプログラマ」だと考えます。

実装という仕事には、具体的にコードをどう書くか?などに考えたり工夫する余地があり、腕の良いプログラマーのそれは高速に動作したり、メモリ消費量が少なくて済んだり、メンテナンス性が良かったり、バグが発生しない、しにくかったりするものです。自分で考える事をやめてしまったプログラマーがいかんのであって、下道高志氏もそういういかん人達を指して危惧していると思います。(そして、Ruby言語の性質上、Javaなどと比べるとそれが顕著に現れる)


それから、日本のソフトウェア産業がかかえる問題と書かれていますが、オフショアっぽい開発で上がってきた外国産ソースコードの品質が似たり寄ったりだったり、もっと質が悪い場合が多々あります。この問題は国を問わず、業界に共通する問題なのでは?と思っています。

だからと言って、日本のIT産業に対する施策が良いとは思いませんが・・・。

中年SE

5年間、開発作業を一切せずに多くのエンドユーザに営業としてヒアリングを繰り返しました。
5年間右往左往して得られた結論は、

「日本にはRailsにおけるDavid Heinemeier Hanssonのように自分が提供しようとしているシステム開発向けに最適なフレームワークを自作できるプログラマーの供給がないから厳しい現実に直面している」

という当たり前すぎる話でした。

日本の情報システムは世界から見ても非常に特異です、要求レベルも世界最高クラスです。
そのシステムを西洋の常識で考えられたフレームワーク上で無理やり作っているから、皆さんの指摘される歪んだSIビジネスになっているのです。
地震の無い国の建材だけを輸入して日本に家を建てるようなものです。

DHHはどうやって勉強してスキルを獲得していったのだろうか?多分、こう考える段階で負けているのだろうけれど。

aaa

nagoさん。
>フィードバックしない状態で開発しているというのは、手法以前の問題ではないですか?
これには同意見です。多重下請け構造とか呼ばれる、日本のIT業界の構造的問題という奴ですね。もうずっと昔から指摘されているけれど、未だに生き残っています。

>実装を受けもっているのなら、上下など関係なく、実装の観点で問題を指摘するのは義務ですし、スルーしているような所に設計の発注をすることはないですよ?

何か思いっきり根本的に勘違いしておられるかと。

発注者はSi業者に丸投げ。
SI業者が「設計書」を作って実装は下請けに丸投げ。

下請けが元請けに逆らうことなど不可能です。逆らったが最後、次から仕事がもらえなくなって、最悪では倒産します。

nago

To: aaaさん。

お返事ありがとうございます。
>下請けが元請けに逆らうことなど不可能です。逆らったが最後、次から仕事がもらえなくなって、最悪では倒産します。
ここがちょっと気になるのです。
別に元請けと喧嘩しろというのではなく、上手に説明、説得ということは考えられないのでしょうか。
それとも、それは自分の仕事ではないと考えてらっしゃるのでしょうか。
(説明、説得は、顧客と話し合いながら仕様に落としていく過程でも大変重要な事です。)

私は、下請け、元請け両方で業務をしていましたが、
関係者皆で協議する場を用意しないと、まず開発は成功しないです。

元請けもプロジェクトが上手くいかないと困るわけなので、説得の余地は十分にあります。
そして、その時の働きによっては間を飛ばして直接受注ということも珍しくはないです。
「良い物を作りたい」というのなら、万難を排してでも
元請けを説得するくらいの気概を見せて欲しい所なのですが。

加えて、ぶっちゃけてしまうと、一度良い関係を作ることができれば
元請けを顧客からの「弾避け」としても利用できますし、大変オススメです。

しん

こんな時は、【A HotDocument】を使えばいかがでしょうか。
http://www.hotdocument.net/

面倒なことは全部やってくれそうです。
http://www.hotdocument.net/main/about.html

The comments to this entry are closed.