下請け構造がなくならないのは大手SIerの社内人件費単価が高いから - ひがやすを技術ブログ
今のSI業界は、大手SIerを中心とした多重下請け構造ですが、その原因の1つには、「大手SIerの社内人件費単価の高さ」があります。 ここでは「社内人件費単価」の意味をプロジェクトに課せられる社員一人当たりの単価とします。 大手SIerでは、社内人件費単価が外注の単価と比べて、べらぼうに高いことが多い。だから、プロジェクトマネージャも利益を出すために、社員の数を抑え、できるだけ外注しようとするのです。 なぜ、大手SIerの社内人件費単価が高いかというと、1つは、大会社であるため、オーバーヘッドが大きいことです。もう1つは、もともとの人件費の単価が高いこと。優秀な人を集めようとすると、必然的に単価を上げざるを得ません。 それ以上に大きな原因は、単価を下げようとするインセンティブが働かないことです。 大手SIer通しの競争もありますから、ぬるま湯なビジネスをやっているわけではありません。 見積
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ
例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
勘違い化が進む池田信夫 - ひがやすを技術ブログ
「全文を出さずパーマリンクなし」という仕様が、日本のすべての新聞・テレビ・通信社のサイトで例外なく採用されていることだ。その編集委員は「新聞協会で申し合わせたわけではないが、暗黙の談合みたいなものだ」という。競争をきらう風土によって、日本のウェブはいびつなガラパゴス化した進化を遂げているのである。 ガラパゴス化した進化というのは、日本の携帯のように、ほかでは通用しないような独自の進化を遂げたものについて言うんでしょう。 日本のメディアのサイトが、「全文を出さずパーマリンクなし」というのは、単に時代に後れているだけで、進化とはいわないよ。 新聞サイトも、購読料モデルから検索に最適化してアクセスを稼ぐ方向に転換し、グーグル化しているのだ。 ページビューを稼ぐ方針にサイトを変えることを「グーグル化」というのか、知らなかったよ。たぶん、おいらが無知なせいだと思うけど、違和感あるな。 これに対して、
Seasarに関してこの2年間やってきたこと - ひがやすを技術ブログ
おととい、Seasarの理事、主にまさたかさんと、しばらくぶりにちゃんと話しました。そこで、おいらが、この2年間くらいの間、何を考え、何をしていたか話したんだけど、「ひがさんが何をしていたかしらなかったよ」と、まさたかさんがいってたので、きっと、コミッタの人やユーザーの方も同じだと思うので、Seasarに関してこの2年間やってきたことについて書いておこうと思います。 まさたかさんと、ここんとこ話をしていなかったのは、別に仲が悪かったわけではなく、はぶさんが理事を抜けた後、飲み会とかやらなくなったから、というのが原因。後、おいらも結婚したので、あまり外で飲まなくなったってのもあります。 2年前のSeasarがどのような状態にあったかっていうと、ちょうど、キャズムに陥っている状態。そこそこの知名度はあるけど、アーリーアダブタ以外は手を出さない。 そこで、私が行なったのは、HOT deploy、
コミッタには気楽になっていいんだよ - ひがやすを技術ブログ
コミッタは自分で名乗り出てなるものではない と思う。もちろん、自分自身で新しい何かを作った時は、自動的にそのプロダクトのコミッタに就任しても良い。しかし、他人のプロダクトに対して、 「コミッタにならせてください」 っていきなり名乗り出るのは、OSSの世界を知らないにも程がある。 「コミッタにならせてください」っていきなり名乗り出てもいいと思うよ。 基本的にOSSのプロジェクトの方針は、そのプロジェクトのリーダーが決めるもの。よういちろうがリーダーをやっているプロジェクトなら「コミッタにならせてくださいといきなり名乗り出るのはありえない」という方針でもいいでしょう。でも、その考えをOSS一般の考えのように言うのは違和感あるよ。 OSSを知らない人が、よういちろうのblogをみたら、間違いなく「コミッタにならせてくださいといきなり名乗り出るのは間違ったことだ」と思うでしょう。 OSSはそんな窮
優秀なプログラマの給料が低いわけ - ひがやすを blog
昨日の開発生産性が低い方が収入が多いって変だよねのエントリでは、企業レベルの話だと、生産性が低いほうが売上が上がるという話をしたんですが、実は同じようなことが、個人レベルでも言えます。 生産性の高い超優秀なプログラマより、社交性の高いそこそこ優秀なプログラマのほうが、評価が高く給料も多くもらえるようになるのです。さすがに、個人レベルだと生産性の低い人が評価が高いということはあまりないけどね。一時的には残業が多くて給料が増えるときもあるかもしれないけど、それはあくまでも一時的なこと。 評価が高いということは、上司にそれだけ認めてもらっているということですが、それではなぜ、優秀なプログラマは、上司に高く評価されないのでしょうか。 「上司に技術をきちんと評価する力がないから」それも多少はあります。でも、主な原因ではありません。会社によって違うと思いますが、評価における技術力の部分は2,3割りに過
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、本当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会
泥のように働く重要性 - ひがやすを技術ブログ
IT企業はほんとに泥のように働かされるのかの記事を見てみたんだけど、かなり違和感がある。 「泥のように働く」の定義はこちらを参照してください。 http://d.hatena.ne.jp/higayasuo/20080715/1216126229 「入社2年目ごろの時点で、仕事の全体が見えていたか？」という質問に対して、全員が○と回答しているんだけど、少なくともSIerでそんなことはないと思う。 全体が見えるためには、要件定義、外部設計(基本設計)、内部設計(詳細設計)、プログラミング、テスト、移行、メンテナンス、プロジェクトマネージメントなどを一通り身につける必要があります。これらの作業が入社2年目ごろの時点で一通り身についているとはとても思えません。 しかも、これらの作業は、1回やったくらいじゃ身につきません。それこそ「泥のように働いて」身につけるものです。 デスマはみんな嫌いだよね。
型にはまった人生で勝て - ひがやすを技術ブログ
「『勝ち組』と呼ばれてみたかった」。実はこの時点で、負け決定。 私の目から見て「この人は『勝ち組』って呼ばれてるんだろうな」という人は、「勝ち組に入ろう」なんてちっとも思っていない。確かに「組」を利用する気持ちはあるし、その過程で組に入ることもあるけれども、それはあくまで客として。「組員」になる気なんてまるでない。本当に興味があるのは、組の中の序列でなくて自分自身。だからその組が自分の居場所じゃないと悟れば、とっとと組を捨ててしまう。 「勝ち組」は、自分が組のなかのどの位置にいるかどころか、そもそも組の中にいるかどうかすら気にしない。その代わり、昨日の自分と比べて、今日の自分がどれだけ成長したかはすごく気にしているし、寝る前には、いや夢の中でも明日の自分は今日の自分よりどうすればより自分らしくなるかを考えている。 弾さんのエントリには全面的に同意する。 誰かに対して勝った負けたと考えている
Javaなんてうんこ(もちろん部分集合) - ひがやすを技術ブログ
なんなんだろうなー、Rubyをまったく知らないのにRubyKaigi行ってトラウマになりましたとか、ネットで10分見ただけで『言うべきじゃない』とか、Java屋さん（もちろん部分集合）のいうことはわけわからん。ろくに調べもせず論説を垂れるマスゴミと変わらんじゃん。 最近は、釣りと知ってて釣られるのがはやっているみたいですね。もちろん、おいらも釣られてみますよ。 ちなみに、RubyKaigi行ってトラウマの件は、RubyとJavaの人は仲が悪い?のコメント欄で、解決しているので、そんな人いないと思うけど、本気で「RubyとJavaの人は仲が悪い?」と思っている人は、みておいてください。 そもそもRuby会議なんて１０分ほどUSTで見ただけの私が書いてみるのエントリそのものがネタじゃないですか。10分しか見てないから、もちろん勘違いしているよっていうネタなわけです。 コミュニティが内輪ネタで盛
軸がぶれないって危険なことかもね - ひがやすを blog
「軸がぶれないことが重要」っていう人は、結構多いと思うんだけど、危険なことかもね。最初に決めたことがあっているならそれでいいけど、あってるとは限らないからね。 「だからこそ最初に良く考えるんだろう」っていいそうだけど、どんなに良く考えたって、間違いはある。人間は、未来のことはわからないんだから。 私は、XPのYAGNI(You Aren't Going to Need It)の考え方が好きです。「今必要のあることだけをやれ」っていう考えが。 「人は未来のことはわからないんだから、できる限りの予想をして未来に備えよう」ってのと真逆な考えで、「人は未来のことはわからないんだから、予想するのはやめちゃって、今必要最小限のことだけをしよう」ってことです。 そして、「現実にあわせて素早く舵を切る」のです。 私は、XPにふれて以来、ずっとこの考えに従っています。 先のことは予想しない。 現実にあわせて
アルファギークと学生の討論会 - 速報 - ひがやすを技術ブログ
以前、IT業界の重鎮に期待せず、アルファギークと学生の討論会はいかがという提案をしたのですが、技術評論社さんのおかげで実現できそうです。 ありがとう、技術評論社さん。 日にちは、9月上旬の土日(たぶん9/6以外)。200名くらい入る場所で検討中とのことです。興味のある方は、予定を空けておいてください。 司会は、弾さんということで交渉中。 で、肝心の討論会なんですが、アルファギーク4人くらいと学生10人くらいの討論会を2時間1セットとして、2セット計画しているそうです。時間をたっぷりとるのはいいんだけど、学生との討論会を2セットやるよりも、もう1セットは、SI業界の重鎮との討論会のほうが面白いと思うんですが、みなさんの意見をお聞かせください。 技術評論社さんの関係者は、ここを見てると思うので、ブクマにコメントしてもらえると技術評論社さんに伝わると思います。たくさん要望のある方は、直接コメント
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
Seasar2でサクサクか炎上か - ひがやすを技術ブログ
可燃プロジェクトに飛び込むことになりました。下記のような炎上する要素満載。 関係者各社に告知済みのためカットオーバーは伸ばせない 外部仕様を策定した会社は行方不明 外部仕様はあるが、OS も AP サーバも環境もアーキテクチャーも未定 外部仕様を分かる人がいないw 開発は 3 社合同なのにソース管理方式も決まってない DB アーキテクト不在っぽい フレームワークに詳しい人がいない AJAX っぽいのたくさん お金がない、規模はわりとでかい、納期短い、残業禁止、増員不可 最初このエントリを見たとき、4/1だったこともあり、一瞬ネタかなと思ったんですが、その後に、SAStrutsとS2JDBCに対する具体的な質問がいくつもあり、私のほうもできる限り質問に答えました。 その後、どうなったのか気がかりだったんですが、今見たらこんな書き込みが 開発メンバからは、簡単で楽でいい！ 1 機能が 1 時間
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
