Seasar3の開発を担当する予定だった小林さんが、Seasar3開発のモチベーションが萎えちゃったようなので、開発を一旦中止します。 http://d.hatena.ne.jp/koichik/20100806#1281070800 お前がやればいいじゃないかと言われそうですが、今、丸山先生が、Spring/Rooをとても熱心に追っかけているんです。 http://maruyama.cloud-market.com/cloud-doc/Roo.pdf http://www.ustream.tv/recorded/8600913 丸山先生が熱心に追っかける技術は流行らないというジンクス(先生ごめんなさい)を私は真面目に信じているので、小林さんがヤル気をなくしたのもあり、Seasar3の開発は中止したいと思います。 ちなみに、去年PDCというマイクロソフトの大きなイベントに行って、Azure

なぜなら、Google App Engineを学ぶために一番必要なのは、「何ができないかを知ること」だからだ。そして、この本にはそれが書いてある。それしか書いていないといってもいい。 App Engineは、Googleのインフラを最も効率よく使うことにフォーカスしている。Genericなアプローチではなく、Specializedなアプローチだ。 何かを得ようとするならば、それと等価の何かを支払わなければいけない。App Engineは、Googleのインフラを最も効率よく使うために、「いくつかのAPIが使えない」という対価を支払った。 だからこそ、App Engineを知るためには、最初に何ができないのかを知らなければいけないのだ。 あなたは、その制限という対価と引き換えに、Googleから安価なスケールするプラットフォームを手に入れることができる。 EC2はGenericなアプローチだ

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

例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働

結局のところ、そのおばさんに給与を払っているのはそのスーパーの客で、そのスーパーの客がオバサンの才能に価値をさほど認めていない、というのがその答えになる。 レジのおばさんに給与を払っているのは、スーパーの客じゃなくて、スーパーのオーナーだよね。これは、実は重要なこと。給与に反映されているのは、実際にお金を払っている客の評価ではなくて、オーナーの評価だから。 もちろん、客の評価が上がることで、それをオーナーが認め、給与が上がることもあるでしょう。でも、客の評価が上がっても、オーナーがそれを認めなければ、給与は上がらない。逆に、客の評価は変わらなくても、オーナーの評価が上がれば、それは、給与に反映されます。 自分は、能力(例えばプログラミング力)があるのに評価が低いと嘆いているギークもいるでしょう。それは、経営陣があなたの価値を認めていないことが原因です。あなたにどれくらい能力があるかは、関係

今のSI業界は、大手SIerを中心とした多重下請け構造ですが、その原因の1つには、「大手SIerの社内人件費単価の高さ」があります。 ここでは「社内人件費単価」の意味をプロジェクトに課せられる社員一人当たりの単価とします。 大手SIerでは、社内人件費単価が外注の単価と比べて、べらぼうに高いことが多い。だから、プロジェクトマネージャも利益を出すために、社員の数を抑え、できるだけ外注しようとするのです。 なぜ、大手SIerの社内人件費単価が高いかというと、1つは、大会社であるため、オーバーヘッドが大きいことです。もう1つは、もともとの人件費の単価が高いこと。優秀な人を集めようとすると、必然的に単価を上げざるを得ません。 それ以上に大きな原因は、単価を下げようとするインセンティブが働かないことです。 大手SIer通しの競争もありますから、ぬるま湯なビジネスをやっているわけではありません。 見積

10/16(木)に日本Javaユーザグループでクロスコミュニティカンファレンスというイベントを行ないます。クロスコミュニティということなので、Javaにこだわらず、ギークにもこだわらず、楽しくお祭りしようよというイベントです。 前回はこんな感じ。 http://www.java-users.jp/contents/events/ccc2008spring/ 私は、160名の会場を4コマ(13:00から17:00まで)まかされたので、ぜひ、みんなに楽しんでもらえるイベントにしたいなと思っています。 テーマは、「華のある自由なイベント」。 「この人にこういうテーマでしゃべってもらいたい」だとか、「自分でこのテーマでしゃべりたい」だとかアイディアがあれば、ブクマのコメントや直接コメントやトラックバックをもらえたら幸いです。 いまのところ、1コマはヨシオリで決定。ヨシオリに華があるのかというお叱り

Flash Player 9 の発表以来、Adobe は ActionScript を ECMAScript 標準第 4 版として提案された ECMA-262 Edition 4 （ES4） に完全準拠させるという目標を公にしてきました。この ES4 は、Adobe, Mozilla, Opera, それから Google を主要なサポーターとして標準化が進められていましたが、一年ほど前に Microsoft と Yahoo! 主導で ECMA-262 Edition 3.1 (ES3.1) のワーキンググループが開始されて以来、2 つの異なる ES3 後継仕様案が並存する状況が続いていました。 先週の発表は、ES4 に関する標準化作業を中止し ES3.1 に集中することが決定されたというもので ECMAScript Harmony プロジェクトと名付けられています。 Adobe, Moz

女。京大生さんの没落エリートの出現―ビジネス社会から疎外される高学歴就職難民たちーのエントリは、高学歴=エリートという定義が反感を呼び、「高学歴就職難民問題は自己責任の問題ではなく社会問題なのだ」という結論がさまざまな議論を呼び起こしました。 それに対して弾さんが学校ってバカを治療してくれんのかのエントリで 高学歴=エリートは間違い 社会の問題にしないで自分で解決したら と弾言したわけだ。 弾さんの言ってるのは正しいと思うけど、どうやって解決したらいいかがわからないんだよね。きっと、それも自分で考えろ甘えんなということだと思うけど、世の中みんなマッチョなわけじゃない。 就職するときに、会社がどういう人材を求めているかから考えてみよう。これはあくまでも、自分の経験によるものなので、一般的かどうかはわからないけど、自分の経験にもとづいて書いてみる。 最も大事だと思う能力は、次の二つ。 自分の頭

筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。 浜口さんが、ウォーターフォールの問題点を指摘している。そして、反復型開発のマイクロソフト版である同期安定化型も今後は検討すべきだとしている。 一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム（３?８人）で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。 わが国の市場の大半を占める企業向けの個別システムに対して

今月開催されました、「PHPカンファレンス 2008」におきまして開催されました懇親会という重要な席で、「モテエンジニアカンファレンス」でしゃべってもらえませんか、といわれたような気がするけど、いつものように酒の場のことは良く覚えていません。PHPユーザではないといえ、パネラーとして参加した者としては許されない失態です。 「飲み会でした約束はたいてい覚えていない」ということをこのblogを読んでいる皆様にお知らせしたい一心で恥を晒した次第です。 酒を飲んでいないときの私の記憶力はかなりいいと思います。その点だけは誤解なきようお願いして、この余計な反省文を終えたいと思います。関係者の皆様、本当に申し訳ありませんでした。 あわせて読みたい。 https://lists.ubuntu.com/archives/ubuntu-jp/2008-July/000994.html

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

大人の男が女に言う、「飲みに行こう」と「美味しいもの食べに行こう」は、 どちらも「あなたとセックスをしたいのですが」ということを意味している という点で同義語ですが、前者だと、女の方が、 「自分は安っぽく思われてるのか？」 と思わせてしまって損なのです。 今、人気急上昇中のPGギャルのエントリ。PGギャル語録はこちら。 http://d.hatena.ne.jp/higayasuo/comment?date=20080719#c ネタ満載だけど、いいことも書いてる。女性をデートに誘うときに、「飲みに行こう」というよりも「美味しいもの食べに行こう」っていうほうが、感じいいよね。 感じよく誘ったのでうまくいったとしましょう。次にすることは、どこに行きたい?(何を食べたい?)ってきくことだよね。でも、それより前にすることがある。イタリアンかフレンチのよさげな店をあらかじめピックアップしておくこと

ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動

クリエイティブな仕事というのはある意味で残酷だと思う。 なぜなら、つくりあげたものが評価に値しないものだった場合に、自由にできる環境があったのに、この程度のものしかできなかったのかという批判が本人に対して直接的に向けられやすいからだ。 自分の企画で仕事ができる場合に、失敗したら自分の責任なのは当たり前だよね。成功したら、自分の評価になるんだから、失敗の責任も自分で負うべき。失敗したときの批判が自分に向くのは当然のこと。 クリエイティブな仕事はハイリスクハイリターンなのです。 エンジニアも何年か仕事を続けていくうちにこうした残酷さに遭遇することが幾度かあるわけで、その中で、自分が傷つきすぎず、ある程度快適に創意工夫していけるように、クリエイティビティのレベルを、自分に合ったものに調整しているのだ。 ローリスクローリターンという選択肢もある。 でもね。選択肢がある時点で、その人は恵まれているわ

例えば、ITは1980年代以降のものですから、その頃すでに企業の中堅になっていた世代の人たちが、いま企業において決定権を持っているわけですね。その人たちは、新しい技術に適応力を持っておらず、ITが得意なのは若い人です。だから、もし会社の中でITを活用するようなことになったら、下克上が起こる。 そういう人たちがITの導入に積極的な考えを持つとは考えられません。これは、日本型企業のひとつの特徴である年功序列制が、新しい技術の導入に抑制的に働くことを意味します。 会社の中で、ITを活用するようになったら、ITの得意な若手によって下克上が起こるそうです。どんな下克上なんでしょうね。 まぁ、これはネタだと思いますが、でも、鋭いところもある。 「日本のSIの生産性は20年間進化していない」と読みかえてみると、実はあっているんじゃないでしょうか。ITの技術は、常に日進月歩ですよ。これはまちがいない。SI

TERASOLUNAは，NTTデータが開発したフレームワークと開発プロセスである。技術開発や新規事業のために作ってみたソフトウエアではない。NTTデータで1999年から開発を始め，これまで約280の大規模プロジェクトに適用しているソフトウエアと開発プロセスである。NTTデータがオープン系システム開発の標準として現在も使い続けているものだ。 TERASOLUNAは、NTTデータがオープンソース化した(元)社内フレームワークです。あのNTTデータと真昼の対決を企画したのもTERASOLUNAチームです。 「『敵に塩を送ることになるのではないか』，という声もあった」---NTTデータ 技術開発本部ソフトウェア工学推進センタ部長 冨安寛氏は「TERASOLUNA」を公開する際にたたかわされた議論を振り返る。 「敵に塩を送ることになるのではないか」というのは、当事者(それも立場が上の人)にとっては、

私は正直、女子だけの飲み会のほうが怖い。 大学時代は、月2,3回、ワイン会(ワイン飲み会)に行ってたんだけど、ワイン会ってほとんど女子ばっかりなんだよね。後、10年くらい料理教室に通っているんだけど、料理教室も女子ばっかりです。 はっきりいって男子だらけの飲み会に参加するようになったのは、オープンソースをはじめてから。 そんな「女子だらけの飲み会」と「男子だらけの飲み会」の両方を結構の数体験している立場からすると、「女子だらけの飲み会」の方が気が楽です。 「女子だらけの飲み会」の場合、女子は(基本的に)何にも気を使わないんだよね男子に対して。好き放題にしゃべってる。話をちゃんと聞いて、飲み物や食べ物に気をつけていれば大丈夫だから精神的には結構楽。 話の中身は、怖かったりするのかもしれないけど、そこには、深く触れないから問題なし。 それに対して「男子だらけの飲み会」の場合、しゃべらない人が結

Seasarプロジェクトが提供しているSAStrutsと、NTTデータが提供しているTERASOLUNAを組み合わせて、大規模プロジェクトでさくさく開発ができるフレームワークの作成を目指します。 SATELITEは、Super Agile TERASOLUNA Lightの略です。 TERASOLUNAは株式会社NTTデータの登録商標です。 本プロジェクトの活動はNTTデータの業務とは関係ありません。 意表をつく組み合わせですね。真剣にフレームワークに取り組み、オープンに業務外で活動している人もいるということですね。 NTTデータと真昼の対決をセッティングしたのは、TERASOLUNAチームの人なんですが、その後のCTCと夜の決闘の話を見て、CTCとは同じ問題をかかえているかもしれないので、CTCの担当者と意見公開したいから、連絡先を教えて欲しいと私のところにメールして来ました。 このまじ

またアクセンチュアは「業界平均より離職率が高い」が、「IT業界内での人材の流動化は歓迎すべきことと考えている」と話した。IT業界でのキャリアパスには、コンサルタントやプロジェクトマネジャになるだけではなく、「ベンチャーキャピタリストになったり、アカデミックの道に進むなど色々な方法がある。さまざまな経験をした人材が転職によって交流することで、IT業界は活性化する」とした。 離職率の高さは、一見ネガティブに見えるけど、スキルアップを定期的に実感できるようにすることで、自分に自信をつけ、会社から卒業しやすくするってのは、良い考えですね。 社員にとっては、スキルアップで自分の価値を高められる。 一方、会社にとってもモチベーションの高い社員が一生懸命働くことで、生産性が高まり利益率も上がる。逆にモチベーションの低い社員は、止めざるを得ないようにきびしく競争させるんでしょう。 利益率が高いから、社員に