一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス石橋秀仁 Hideto Ishibashi @zerobase 先日某社のIT担当者と話して着々とベンダー(SIer)外しが進んでいる実態を知った。新規案件はどんどんAmazon EC2に構築し、委託先もウェブ系の制作会社やソフトハウス。それに対応できない大手ベンダーの「ジレンマ」。まあ対応せず潰れてください。社会のために。 2011-02-05 15:45:49
「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について（METI/経済産業省）
本件の概要 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 担当 商務情報政策局 情報処理振興課 公表日 平成21年7月31日(金) 発表資料名 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について(PDF形式：12KB) 報告書(PDF形式：2,175KB) Acrobat Readerをダウンロード（Adobeサイトへ） このページの先頭へ
株式会社スターロジックの羽生章洋が書いてるブログ:元請けにこだわる理由 - livedoor Blog（ブログ）
私は文系の大学中退（まぁ高卒ですよね）です。最初に入ったのがソフト会社で、その次もソフト会社でした。最初の会社では未経験のど素人だったのでオペレータやパンチャー、運用と保守からやらせて頂きました。その後転職した2番目の会社で、絶対に忘れないと感じる出来事に出会いました。 ＃ とりあえず、以下のエピソードのあと、新婚早々に残業400時間/月とかやってて ＃ さすがに「これは死ねるかも」と思う程度に、月に200時間残業とかするのは ＃ 当然と思っていた、それでもそれが苦にならなかったほどに一体感を持つことが出来た ＃ 今思うに幸せな時代の話です。私は当時の会社を今でも誇りに思っています。 2番目の会社にはその年の1月に入社しましたので、その年の夏のボーナス（賞与というよりも私にはボーナスという言葉の方がゴージャスに聞こえるのでこれで押しますｗ）は当然出ません。というわけで、お金に困っていた私は
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
やはり情報サービスは斜陽産業なのか - 雑種路線でいこう
前のエントリid:mkusunok:20051224:carrierについて、id:fromdusktildawnさんから素晴らしいコメントをいただいた。考えてみると昨今IT業界で元気がいいのはApple, Google, AmazonといったB2C企業や、OracleやSAPといったB2Bでもパッケージ製品を多数の企業に展開している企業である。日本をみてもプロ野球に名乗りを上げたYahoo!、楽天、Livedoorいずれも大量の顧客に対しサービスを提供している。*1パッケージソフトウェアに強いジャストシステムやOBCも、同様に無数の小さな顧客をたくさん持っているといえるだろう。*2 少数の大きな顧客と取引するから、その顧客と力関係で負けて、おいしくなくなりがちなのであって、無数の小さな顧客をたくさんもてば、それは土方的でなくなるという指摘は、受託開発よりもパッケージや販売といった製品ビジ
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
SI業界で起きているデッドロック:渡辺聡・情報化社会の航海図 - CNET Japan
先週末土曜に久しぶりの通常開催版となったEmerging Technology研究会にて、頭に汗をかく議論に参加してきた。テーマはいつかどこかでやらなければとなっていたSIビジネスの今後について。当日の簡単な感想と参加者のエントリクリップはこちらでまとめているので、個別参照頂くとして、幾つか論点を絞って追記を。 参加者は大きいところにちょっと偏りがあるとはいえ、 ・SIer ・ソフトベンダー ・サービスベンダー（ネットの） ・コンサルファーム ・メディア と周辺領域も含めて充実したやりとりとなった。 SIのI シンプルに考えると、そもそものSIビジネスの存在価値はSIのIにある。インテグレーション。プログラム開発を行うことももちろんあるが、ハードやデバイス、アプリケーションを適時組み合わせて足りない部分を足し（ソフトに限らず、場合によってはハードの調整も行い）、顧客の要望に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
(コ)の業界のオキテ
クラウドを超えた先の企業システム像 20091008 JJUG CCC