木村の主張「人月商売や多重下請けは滅びの道」、読者はどう考えるか
私が書いた前回の「記者の眼」で、人月商売と多重下請け構造に代表される日本のIT業界の現状と今後について、読者に意見を求めた（関連記事：読者に問う！ IT業界の二大悪「人月商売」「多重下請け」の今後）。私自身はIT業界の悪弊とも言える人月商売と多重下請け構造は解体に向かうと考えるが、はたして皆さんはどう思っているのだろうか。 この人月商売と多重下請け構造の問題は、IT関連の仕事に携わる多くの人にとって重大な関心事。そのため、SIerや下請けの受託ソフトウエア開発会社の技術者、経営層、営業担当者、さらにユーザー企業のIT部門の技術者など83人に上る読者から真摯な意見が寄せられた。今回は、そうした意見を紹介しつつ、はたしてIT業界が変わり得るのか否について深掘りしたいと思う。 そもそも読者に意見を求めようと考えた発端は、やはり以前この「記者の眼」で書いた記事だ（関連記事：IT業界の人月商売、多重
IT業界の人月商売、多重下請けがもたらす45の害毒
私は自分のコラム「極言暴論」で、ユーザー企業のIT部門とITベンダーの問題点や課題を極言し、暴論してきた。だが、特にITベンダーあるいはIT業界の話を書くと、空しくなることがある。私が指摘する問題点は、ITベンダーの経営幹部なら随分前から自覚している。それでもITベンダーや業界は何も変わらない。 「極言暴論」の読者にも「以前に何度も聞いた話」とシニカルに受け止められてしまったりする。「このままでは日本のIT業界に未来は無い」と叫んだところで、「またですか」とオオカミ少年扱い。やはり“ゆでガエル”状態になっている人には、湯の温度が多少上がったぐらいでは危機感を持って受け止めてはもらえない。 それでもクラウドの世となり、ITベンダーを丸ごとゆでる湯の温度は急激に上昇している。今起こっているパラダイムシフト、パワーシフトは以前のダウンサイジングやインターネットの爆発的普及のときの比ではない。シス
（第2回）ダメ発注その1、要件定義もできない“低クオリティ”
ユーザー企業には「発注責任」がある。しかし実際には、この当たり前のことをわかっていないユーザー企業は数多い。その結果、システム開発プロジェクトが頓挫し、ユーザー企業とITベンダーの双方が大きな打撃を受けるケースが頻発している。この特集では、ユーザー企業がシステム開発をITベンダーに発注する際に陥りがちな問題点を、発注のQCD（品質、料金、期日）の観点から分析する。 今回は“Q”、つまり発注の品質にフォーカスして問題点をあぶり出す。なお、この特集は日経コンピュータの2008年6月15日号に掲載した記事をベースに、内容を一部修正して著者の現時点での認識などを加えたものだ。オリジナルは4年半前の記事だが、ITベンダーの事業部長、営業部長クラスの人に匿名を条件に語ってもらった“事実”は、今でも全く古さを感じさせない。 一括契約はここが恐ろしい 発注の品質、つまり要件定義の問題は、ほぼすべてのITベ
（第1回）ベンダーが呆れる「発注責任」の放棄
ユーザー企業には「発注者責任」がある。ところが最近、この責任が希薄なばかりに、外注したシステム開発が頓挫したり、ITベンダーとのトラブルにつながったりするケースが増えている。今回、匿名を条件にITベンダーから「こんな発注は勘弁してほしい」との本音を聞いた。プロジェクトを成功させるために、ITベンダーの声に耳を傾けてほしい。 あらかじめ断っておくが、この特集は日経コンピュータの2008年6月15日号に掲載した記事をベースにしている。つまり、オリジナルは4年半前に書いたものだ。だが、そのオリジナルをいま読み返しても、全く古さは感じない。ITproのコラム「極言暴論！」で最近、大きな反響のあった記事とも深く関わる話なので、一部を加筆・修正して掲載することにした（関連記事：法外な開発料金の見積もり根拠、「客には絶対に言えません」）。 ITベンダーがパニックに陥った顧客の暴挙 「開発着手の1週間前に
急速なビジネスの変化に対応できる「BRMS」の常識
急速なビジネスの変化に対応できる「BRMS」の常識：企業システムの常識をJBossで身につける（終）（1/4 ページ） 企業向けアプリケーションのさまざまな“常識”をJavaのオープンソース・フレームワーク群である「JBoss」から学んでいきましょう。企業システムを構築するうえでの基礎となる知識をリファレンス感覚で説明していきます。初心者から中堅、ベテランまで大歓迎！ 貴社では、ビジネスルールを定めていますか？ 企業における「ビジネスルール」について、読者はどのようなものを想像しますか？ その名のとおり、「ビジネスにおけるルール」というものを想像するのではないでしょうか。企業を取り巻く環境は、常に急速な変化が伴います。このような変化に対応できるように、昨今の企業では、一定のビジネスルールを定義しておき管理するケースが増えています。 今回は、ビジネスルールの概要について説明し、企業におけるビ
あなたの知らない超高速開発
あなたが携わるシステム開発プロジェクトで、開発速度が10倍速くなったらどう思うだろうか。「利用者にすぐに使ってもらえたり早く帰れたりするので、嬉しい」と思うか、「人月で見積もっているので売り上げが減ったりこれまでのマネジメントの方法が変ったりするので、嬉しくない」と思うか。 いずれにしろ、その後にこう思うことだろう。「そもそも10倍なんてできるわけないじゃないか」。だが、実際にできているユーザー企業が登場している。 記者は今年の1月と2月、日本と韓国で25社以上のユーザー企業を訪ねた。日経コンピュータの3月15日号に掲載した特集「『超高速開発』が日本を救う ～サムスンは既に始めている～」の取材のためだ。その中で、スクラッチ開発と比べて「10倍以上に開発効率が高まった」という声を、いくつも聞くことができた。三井住友海上火災保険や朝日生命保険、東京都足立区役所などである。 これは簡易的なシステ
“スルガ銀−IBM裁判”を振り返る - 週末スペシャル：ITpro
「約111億円」という巨額の損害賠償を求めて、スルガ銀行が日本IBMを提訴したのは2008年3月のことだ。それから3年余り、裁判は終盤戦を迎えているという。システム開発に多少のトラブルは付きものだが、これほど大きな損害賠償請求に至ったのはどうしてか。ここで、裁判で示された問題を振り返ってみよう。 プロジェクト破綻までの経緯と裁判の様子 スルガ銀行は勘定系の次期システムとして、IBMのパッケージ「NEFSS/Corebank」の導入を決め、2004年9月にプロジェクトがスタートした。だが、要件定義を3回繰り返すなどシステム開発は難航。2008年1月の稼働予定を延期した。日本IBMはスコープの大幅な縮小や追加費用を要求したが折り合わず、2007年5月にスルガ銀はプロジェクトの中止を決断した。 スルガ銀が日本IBMを提訴、システム開発の債務不履行による損害など111億円超を賠償請求 スルガ銀行と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日経BizGate｜課題解決の扉を開く
テクノロジー : 日経電子版
テクノロジー : 日経電子版