SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受

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

2009-01-29 最初に言っておくと、結構いい指摘だと思います。せっかくなので、私のほうでも答えましょう。 だから、メンテナンスの不安の問題は、メンテナンスが行われてないということではなくて、メンテナンスが行われているのにメッセージとして発信されていないということだと思う。 ひがさんは上にあげた以外にもちょこちょことSeasar2のメンテナンスは続けられるということをブログに書いているのだけど、やはりブログという刹那的な形態ではなく、公式サイトに常設されたメッセージとしてメンテナンスをやっていくよということを書いていないといけないと思う。 これは、おっしゃるとおり。ただ、こういう政治的なメッセージは、理事会のほうから出したほうがいいと思います。そういう流れで、打ち合わせも進んでいたはず。 私は、プロダクトを作ることに専念するために、理事を辞めたので、プロダクトを作ることに専念したい。そ

Java でも比較的先進的な考えを持つフレームワークがたくさんあります。そして、先進的なフレームワークは作者でさえ、流行っている、たくさん利用されていると錯覚する場合があります。利用者となるプロジェクトには大抵、新しいことが好きな先進的な人がいて、アーキテクチャを決めてしまいます。そういう人はよくネットなどで情報を発信します。また先進的であれば、記事や書籍でこぞって取り上げられ（もちろん中の人の努力もあります）、流行ってるように見えてしまいます。実際には出来れば新しいことには手をつけたくない人のほうが圧倒的に多いにも関わらず。 どこかの掲示板で、DIは疎結合のためにあるとか、そのためにインターフェースと実装を分離するんだとか、再コンパイルせずに、設定ファイルの変更のみで実装を変更できるんだとか、書いている人を見て、懐かしく思いました。 こんないいもの(たとえばDI)を理解できないのは、理解

「全文を出さずパーマリンクなし」という仕様が、日本のすべての新聞・テレビ・通信社のサイトで例外なく採用されていることだ。その編集委員は「新聞協会で申し合わせたわけではないが、暗黙の談合みたいなものだ」という。競争をきらう風土によって、日本のウェブはいびつなガラパゴス化した進化を遂げているのである。 ガラパゴス化した進化というのは、日本の携帯のように、ほかでは通用しないような独自の進化を遂げたものについて言うんでしょう。 日本のメディアのサイトが、「全文を出さずパーマリンクなし」というのは、単に時代に後れているだけで、進化とはいわないよ。 新聞サイトも、購読料モデルから検索に最適化してアクセスを稼ぐ方向に転換し、グーグル化しているのだ。 ページビューを稼ぐ方針にサイトを変えることを「グーグル化」というのか、知らなかったよ。たぶん、おいらが無知なせいだと思うけど、違和感あるな。 これに対して、

これは，1社に“丸投げ”する代わりに，そこが使っている下請け企業を調べて，何社かの下請け企業に直接発注する方法です。元請け企業の“オーバーヘッド費用”を削減できるので，この方法を有効に活用できると，おおげさではなく，開発費用は半減します。 上流工程と下流工程で発注するベンダーを変える(分離発注)ことにより、競争によってコスト削減を目指す。これは、まぁわかりますね。ありそうでなかったのがSI業界における分割発注です。 元請けに頼まず、複数の下請けに対して分割で発注するわけです。下請けにとって見れば、元請けがマージンととらないから、利益率が上がる。発注元にしてみれば、元請けに余分なマージンを払わなくてすむ分、コスト削減ができる。 この方法の懸念点は、元請けがSIをやらない分、その負担は、発注元のシステム部が追うことになります。それが可能なら、この「分離発注」と「分割発注」は、十分に有効な方法で

2008年5月に行なわれた大手調査会社の結果が興味深いものでした。従業員50人以上の企業をランダムに6000社選び、アンケートをとったそうです。日本の結果で、数値は%。言語は、Javaだけではなく、すべての言語が対象です。 EJB3.0(11) 独自フレームワーク(10.6) Struts(10.2) JSF(3.2) TopLink(2.4) Hibernate(1.1) Seasar類(0.9) iBATIS(0.4) Spring(0.4) Torque(0.4) その他(6.7) 利用なし(59.8) Seasar類か、微妙な表現だ(笑)、数値は意外と高いですね。EJB3やJSFが高いのが意外。Strutsが意外と低い。TopLinkがHibernateより高いのも意外。.NET系は利用無しに含まれているんでしょうね。 Seasarがトップ10に入っているなんて、とても光栄です。今

以前、あれほど話題になったのに、みんな忘れちゃったのかな。もう一度、元の伊藤忠商事の丹羽宇一郎会長の言葉を引用しておきます。 リーダーとしての資質は仕事でしか磨くことができない。うちの会社は入社したら完全なゼロからのスタート。平等に機会を与え、だれにも平安な道を用意するつもりはない。厳しくかつ戦略的に鍛え上げる。 まず入社して十年間は泥のように働いてもらう。はい上がる気力や苦しい時に周囲を思いやる気持ちを育てるには、どん底に突き落とすしかない。入社４年までに全員を海外に研修に出す。海外の若者がどれだけハングリーに働いているかを見てきてほしい。 毎日深夜まで会社にいろとは言わない。本を読み、人と会い、ものを考えることで知的能力を再生産する努力を続けることだ。大変ですよ。ついて来られない社員が出ても仕方ない。 短くまとめると「ハングリーに働く」ということ。もうちょっと分かりやすく書くと「スキル

IT企業はほんとに泥のように働かされるのかの記事を見てみたんだけど、かなり違和感がある。 「泥のように働く」の定義はこちらを参照してください。 http://d.hatena.ne.jp/higayasuo/20080715/1216126229 「入社2年目ごろの時点で、仕事の全体が見えていたか？」という質問に対して、全員が○と回答しているんだけど、少なくともSIerでそんなことはないと思う。 全体が見えるためには、要件定義、外部設計(基本設計)、内部設計(詳細設計)、プログラミング、テスト、移行、メンテナンス、プロジェクトマネージメントなどを一通り身につける必要があります。これらの作業が入社2年目ごろの時点で一通り身についているとはとても思えません。 しかも、これらの作業は、1回やったくらいじゃ身につきません。それこそ「泥のように働いて」身につけるものです。 デスマはみんな嫌いだよね。

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

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

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

浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ

「フェロー」なんて言って「ぼくちんは稼がなくていいんだヨ」みたいなことを言っているのは、 単なる穀潰し としか評価出来なくなってしまう。 おごちゃんの言葉は深く考えさせられる。 特別待遇の人はいてもいいと思うけど、最終的に収支が見合わなければ、会社はやっていけない。稼がない人がいれば、その分誰かが稼がなければいけない。 ただし、収支といっても単純に金を稼げば良いという話でもない。どんな企業にも直接利益を生み出さない間接部門の人がいるが、その人たち無しでは企業はやっていけないのだから。 結局、チームでどれだけのパフォーマンスを出せるかが重要で、0を1にする人が良いとか悪いとかは、関係ないと思う。 特別待遇の人は間違いなく間接部門だ。直接利益を上げている人たちに対して、自分が何をして上げられるのかを常に考えていないければいけない。「自分は稼がなくても良いんだヨ」って思うんじゃなくて。 この話が

エンジニアは、誰でも、人の役に立ちたいと思っているものです。そして、人から頼りにされることに、喜びを感じる生物です。でも、この「頼りにされる」状態は、危険な状態であることもある。 頼りにされるあまり、多くの仕事がその人に任されることになる。できる人に、仕事が集中するのは、よくある話で、その人は、回りの期待にこたえようとして、遅くまで残業して、休日も出社したりする。この状態が、一過性のものだったら良いんだけど、慢性的なものになると、肉体も精神もぼろぼろになっていく。 仕事が慢性的に過度に集中している人は、一度じっくり考えてみたほうが良い。会社は、「あなた」のことを頼りにしてるけど、実際のところはこき使ってるわけですよ。俺なら、ピンチのときにできる人に仕事をいっぱい頼むことはあっても、それを慢性的には行なわない。だって、その人に壊れて欲しくないから。 仕事が慢性的に過度に集中している人は、会社

その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの

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

静岡県を地盤とする地方銀行のスルガ銀行（本店・沼津市）は６日、銀行業務に関する基幹コンピューターシステムの開発を契約通りに行わなかったとして、開発委託先の日本ＩＢＭ（本社・東京都港区）に約１１１億円の損害賠償を求める訴訟を東京地裁に起こした。 詳しい話は、今後徐々に発表されてくると思いますが、この件は、パッケージビジネスの難しさを端的に表しているのではないかと思います。 スルガ銀行の次期基幹システムは、IBMの次世代金融サービス・システム(Next Evolution in Financial Services Systems、以下 NEFSS) をパッケージに採用したものです。 http://www-06.ibm.com/jp/press/2004/10201.html スルガ銀行が最初の顧客のようですが、当初は、みずほCBを想定して作成されたみたいです。 http://itpro.ni

リリースノートはこちら Bug [SASTRUTS-18] - ArrayWrapperでListを実装するようにしました [SASTRUTS-20] - ActionからActionへ遷移できない問題を修正しました Improvement [SASTRUTS-19] - ActionのプロパティがMapの場合も扱えるようにしました ダウンロードはこちら http://sastruts.seasar.org/download.html このバージョンから、チュートリアルに、ResourceSynchronizerプラグインを使ったリッチなエラーページをつけました。ResourceSynchronizerを超ざっくり説明すると、ブラウザからEclipseを操作するプラグインです。 チュートリアルのリッチなエラーページをクリックすると、Ext.jsで作ったリッチなエラーページが表示されます。ス