ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 35才(2004年)でプログラマとしてオープンソースを始め、今年で42才になる俺が通りますよ。 35才までは、SIerの中でSEをやってたので、そんなにプログラムは書いたことがないです。 上記のエントリには、いろんな戦略が書いていますが、ぶっちゃけ戦略は一番重要なことではなく、一番重要なのは、常に自分の価値を高めるために努力し続けることです。 努力や挑戦をやめたら、自分の価値はどんどん陳腐化して下がっていくのは当たり前なのです。 自分がどんなことに挑戦してきたのかちょっと書いてみますね。 2004年1月、プログラマとして何か新しいこ

ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの

自分の人生を日記ネタにして生きているhigayasuoです。昨今の不景気風ビュービューふきすさぶ中、皆様いかがお過しでしょうか。 inspired by 2009-01-04 S(Strengths、強み) 大手企業で働いていたってのは、それほど、強みでないと思う。天下りなどで特別な力がない限り、勤めていた会社は関係ない。もちろん、ポジション(肩書き)も関係ない。 勤めていた企業はあまり関係なくなっているところが、よしおかさんの世代との違いかも。 自分が何をやってきたかが重要だと思う。会社名に助けられて仕事してきた人も多いと思う(自分もその一人)けど、会社名は自分の実力とは直接結びつかない。 もちろん、会社名は、利用したほうが良い。使えるものは何でも利用すること。でも、個人の実力で作り上げたものをきちんと持ってなければ、特に不況のときなどは相手にされない。 他人と簡単に交換できない価値を発

「ごめんね」といわれたら、「そのうちきっと見つかるよ」とやさしく応えて、あれこれ聞かない。 まるはんのお姉さんが見つけてくれるかもしれない。 悲しそうな顔をしていたら、何も言わずに頭(髪)をなでてあげる。 手をつないで一緒に寝る。 実際にこれらの行動でよかったかどうかは、よくわかんないんだけどね。 なくした理由をあれこれ聞くのはやめましょう。理由は、わからないことがほとんどです。 怒るのはやめましょう。怒ったからなくしたものが見つかるわけじゃないし、彼女を傷つけるだけです。 で、この後、おいらは、どういう行動をとったらいいんだろう。 同じ指輪を買ってあげる? 違う指輪を買ってあげる? 見つかるまで待ってる? 誰か続編を書いてください。

日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ

「世界最大・最先端のRubyビジネス拠点を構築する」――こんなかけ声の下、福岡県で8月4日、「福岡Rubyビジネス拠点推進会議(F-Ruby)」が産声をあげた。プログラミング言語「Ruby」で福岡県のソフトウェア産業を活性化させようというもので、産官学が一体となり、ビジネスの視点からRubyを活用していく。 一般的な客にとっては、開発言語に何を使うかは、どうでもよくて、自分の思っていることが、安くできればそれでいい。 だから、Rubyできますってことで、ビジネスが成り立つとは思えないんだけどねぇ。 Rubyは、もちろん良い言語だと思う。ただ、生産性が他の言語と比べて高いかというとそんなこともないでしょう。生産性という切り口だと、言語よりも良いフレームワークがあるかということが、重要なポイントになると思うけど、いまどきのフレームワークは、どのフレームワークもお互いに学びあっているから、そんな

昨日の開発生産性が低い方が収入が多いって変だよねのエントリでは、企業レベルの話だと、生産性が低いほうが売上が上がるという話をしたんですが、実は同じようなことが、個人レベルでも言えます。 生産性の高い超優秀なプログラマより、社交性の高いそこそこ優秀なプログラマのほうが、評価が高く給料も多くもらえるようになるのです。さすがに、個人レベルだと生産性の低い人が評価が高いということはあまりないけどね。一時的には残業が多くて給料が増えるときもあるかもしれないけど、それはあくまでも一時的なこと。 評価が高いということは、上司にそれだけ認めてもらっているということですが、それではなぜ、優秀なプログラマは、上司に高く評価されないのでしょうか。 「上司に技術をきちんと評価する力がないから」それも多少はあります。でも、主な原因ではありません。会社によって違うと思いますが、評価における技術力の部分は2,3割りに過

開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、

Slashdot.jpでPHPカンファレンスのパネルディスカッションのテーマを募集していますね。 http://slashdot.jp/developers/article.pl?sid=08/07/09/0341255 タレコミ子の個人的な思いとしては、以下のようなものがあります。 PHPカンファレンスに来た人にPHP以外の文化を知ってほしい。 PHPカンファレンスに来た人にPHPに関してDISられて損をさせた気分のまま帰って頂きたくはない それでも無難な終わり方をするセッションにはしたくない こうした思いを議論に反映させたいと考えつつ、正直なところその内容に悩んでいます。また、タレコミ子一人の考えることより皆様のご意見をいただければよりよいパネルディスカッションとなると考えています。 アレゲな皆さんの視点からは、どのような話をパネラーにして貰いたいと思いますか？ 「激論！PHPの次に学

このひどいブクマのコメント欄を見てください。自重を知らない人たちであふれています。 このひどいブクマに「これはひどい」のブクマをつけようとしたら既にやっている人がいました。 ひどいブクマのブクマ ブクマにブクマできるって知らなかったよ。 ところで、「自重」の読み方って知ってます? もちろん「じちょう」だろうって? 半分正解。 「自重しろ」の文脈で使うときには、たしかに「じちょう」ですが、「船舶・車両・構造物などの、それ自体の重量」という意味で使う場合は、「じじゅう」っていうんです。 http://dic.yahoo.co.jp/dsearch?dtype=2&p=%BC%AB%BD%C5 おいらが、Java-jaの連中に何度も「じじゅうしろ」っていってたのは内緒だ。っていうか、Java-jaの連中、気づいているなら注意しろよ。そんなところだけ、自重しなくていいから。 あわせて読みたい。 な

SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大

SI業界が開発するシステムの目的は何か？　それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない

昨日、CTCに「お前は最近、Railsに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、Railsを嫌っていると思っているRuby関係者は、実際多いようです。 「JavaからRubyへ」の本に対して、それはちょっとおかしいんじゃないのといったことはありますが、Railsを嫌いといったことはもちろんないはず。 呼び出されたのは、Rubyの話じゃなくて、Javaの社内フレームワークの話でした。 Struts、Spring、独自データアクセスフレームワークの生産性を何とかして改善したいという悩みでした。裏を返せば、今が低いと思っているということでしょうね。 あるいは、生産性が低いというより、大手SIerにとって必須の大規模開発をするのには、つらいということなのかもしれません。 CTCの話だと、SAStrutsを使えればいいんだけど、

10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変

蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、本当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会

それゆえ、私には 「エンジニアが幸せになるためにはその産業が国際競争力を持つことだと思う」 というのは、ちょっと違うでしょうってこと。という台詞がひどく罰当たりに聞こえる。もしひがさんが日本以外の国に生まれ育ってオープンソースプログラマーを志したらこんな牧歌を歌っていられるのですか、と。 今の私がオープンソースプログラマーをやっていれるのは、日本のような国際競争力のある国(産業ではない)にいるからってのは、そのとおりだと思います。 しかし、私にとって、「日本に生まれたこと」より、「誰と知り合ったか」がやっぱ重要だなぁ。感謝しているのは、日本というより「まわりの友人たち」。 はぶさんに「Seasarつくってよ」っていわれなかったら、Seasarなんか作らなかった。でたばっかりの無名のSeasarをメディアを通じて広めてくれたのもはぶさんのおかげです。 Seasarが盛り上がってきたときに、仲

ことの発端はこの辺。 国際的に競争力のある産業の中核で働いているエンジニアは幸福感がある。 確かに、国際的に競争力のある産業の中核で働いているエンジニアは幸福感があるかもしれない(これも怪しいと思うけどね)けど、こんな風にかかれると、国際的に競争力のある産業の中核以外で働いているエンジニアは、幸福感は得られないという主張に見える。 残念ながら，日本のソフトウエア業界というのは過去の歴史において国際競争力を持ち得なかった。 あるいは、新しいところで競争力を生んでほしいですよね。ネットの世界はこれからなんです。まだ勝負がついていない。 いわゆるシステム・インテグレーションの業界は，1970年台から競争が始まって，30年かかって今の秩序ができあがった。30年かかってできたインダストリの構造を，ひとりふたりが頑張ったって変えられないですよね この文章の裏には、日本のソフトウエア業界は過去の歴史にお

昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

なぜメモを取るのか。 * 記憶は頼りにならない * メモを取ることで、脳を「考えること」に使える * 記憶は共有できないが、メモは共有できる。メモを書くことは、他人と情報を共有することになる。 などです。メモを取ることは、一手間かかるようで、実は非常に効率的なのです。 議事録を書かなければいけないときを除いて、俺は、メモを取らない。なぜかというと、メモを取ることに気が散って、相手のいうことを考えなくなるから。 メモを取ることで、満足しちゃうんだよね。頭を使わなくなる。だから、相手の話を聞くときには、その話に集中し、メモなんか取らないほうが良い。 メモを取ることで、脳を「考えること」に使うってのは、自分にとっては違う気がする。議事録を提出するために、メモを取ったこともあるけど、メモする以外、何も考えられなかったもの。 忘れるのを避けるために、メモを取る人もいるでしょう。でもさぁ、すぐ忘れる話

「自動車のような産業構造に再編すべきだ」。NTTデータの山下徹社長はインドや中国など海外ソフト会社が日本市場に本格進出してくる前に、ソフト産業の構造改革を実行する必要性を説く。日本のソフト産業が崩壊の危機にあるからだ。 パッケージベンダが自動車産業を参考にするのは、100歩譲るとありかもしれない。消費者に受け入れられるだろうという予想にもとづきプロダクトを開発していくモデルだから。 でも、やっぱないな。車は、多少の違いがあっても、どれも基本的な構造は同じ。パッケージは、いろんなものがあるからね。 それに対して、SIは一品ものだもの。規格(パッケージ)通りじゃないものを作るのがSIです。 マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを