キャッチーな見出し
IT業界に激震走る
なかなか興味深い、激震、というほどではないけれど、この世界では会計基準というか、見積もりの妥当性とか、あってないようなもので、あまり見えない。この記事では、SI側が作業工程ごとに収益総額、原価総額、進捗度をお客様に見せる。となっている。要は工程ごとにかかったお金をユーザー企業に報告しなさい、ということらしい。まぁ、誰も正直に原価を見せたりはしないんだろうが。いずれにせよ、基準ができるのはよいことだと思う。
現実には、こういう流れが改善されるのであれば喜ばしいことだと思う
で、他ならぬ、日経コンピュータ自身が、こういう流れはよくご存知らしく「現場に蔓延する“ひどいRFP”」という記事もタイムリーに公開している。
ユーザー企業が、要求を出さない。（はっきり出しちゃうと、自分たち（ユーザー企業）が仕様バグを作っちゃった場合に相手（SI屋）を責められない。相手を責められる場合は無償か、格安でバグ修正の名の下に「機能改善」させれるからね）
SI側は、要求があいまいでも、商談は、というよりも、目先の金は獲得したいから、要求定義も程々にして一括の開発として受注しようとする。だって、要件定義なんて設計でやればいいじゃない。（というのが、大きな誤り）
よくわからない条件のもと、一括で費用を見積もる（だって、ユーザー企業は「はっきりと要求を出さずにいかにSI屋に仕事をさせるか」を考える、もしくは、「ユーザー企業は自分が何を望んでいるかわからない（これは、笑い話ではなく、本当にある話）」）そして、受注する。
SI屋は、設計時にユーザー企業の要望を聞く。聞くたびに、夢を語られ、凄まじい量の開発が必要だと分かる。既に一括で受注してるため金額は決まってる、が、どう考えても開発量に見合わない金額だと次第に思うようになる。開発担当は曖昧な部分があれば、それを解決するために、ユーザー企業担当者に仕様を聞きに行く、そのたびに、費用に見合わない要求を突きつけられる。聞けば聞くほど赤字になる。矛盾を抱えたまま、作業を進めると、まぁ誰かが病気になってポシャる。そういうユーザー企業の無茶な夢に対応する担当者を、一昔前までは、いや、今でも、聞き出すスキルに問題がある、と、言われたりする。
聞き出すスキルに問題があったのは、営業なのか、開発担当なのか、両方なのか、それとも、ユーザー企業なのか、よくわからないまま、反省もなく、現場は作業を進める。みんながみんな泥沼をなんとか泳ぎ切るのに必死だ。
開発担当者の「予算は使い果たしてしまいました」とか言う声が上層部に「ユーザー企業からのクレーム」として届き、上層部が赤字プロジェクトに気づいて赤字の原因を探ろうとする、が、時すでに遅し、、、
