第4回 そして、システムはお蔵入りとなった開発現場の天国と地獄(1/3 ページ)

» 2005年04月26日 12時00分 公開
[佐藤大輔,オープントーン]

 前回までのプロジェクトは地獄になりながらもなんとか納品し、無事稼働を迎えることができました。しかし今回は、特に開発が地獄になることもなく納品こそしたものの、不幸にも本番稼働する機会のなかったプロジェクトをご紹介し、その原因について考えてみたいと思います。

[プロジェクト概要]
名称 プロジェクト4 「最先端Webサービス構築」
案件 BtoB、Webサービス
言語など ASP、VB、oracle
プロジェクトの規模 6カ月以内、8名
結果 カットオーバー成功。大幅黒字。しかし、お蔵入り。
予算 6,000万
経費 4,000万
顧客満足度 ×
[問題点]
作業者の管理
開発プロセス(UP)
開発能力
分析設計
×
チーム全体のコミュニケーション
コメント 開発は成功した。しかし、誰にも使われなかったという事例。困難な技術リスクにも係らず開発は順調に推移した。しかし、このシステムは結局本番稼働を迎えずに「お蔵入り」となる。Webサービスに対する世間の認識が低いときに、先行して実装した案件。最先端の技術をとり入れるという前提で作ったものの、先行しすぎていろいろ損をした事例でもある。
[凡例]
◎=良(問題なし)
○=やや良(ほぼ問題なし)
△=やや難(やや問題あり)
×=難(問題あり)

(1) プロローグ

失敗か成功か

 このプロジェクトは、開発サイドからみれば「成功例」といえます。無事納品も終え、案件としても収束しました。ただし、このシステムは結合テストが完了し、納品された後も本番稼働を迎えることはなく、ユーザーが利用しなかったという意味においては間違いなく失敗例です。では一体どうして稼働しなかったのでしょうか? システムはきちんと当初の仕様どおり作られていました。また、よくある「ベンダの口車に乗せられて不要なシステムを構築」というのも当てはまりません。この案件の企画はユーザー側から出されており、ベンダは肉付けし、実装したに過ぎないからです。

 結果として、開発現場的には「移行フェイズ」で支払うべき作業コストを一切かけずにすんだために非常に「楽な案件」となりました。現場では大きな本番稼働前の「波」もこず、スタッフの稼働状況が徹夜必至の状況にまで追い込まれるようなことは最後までありませんでした。ベンダの目からだけみればまさに「天国案件」といえます。

 こういった場合、ベンダは社内的に「成功事例」として扱う場合がほとんどです。実際に、今回ベンダサイドとしては見積書と請求書の束を差し引きすると、大きな黒字を生んでいました。とはいえ、「プロジェクト自体の成功・失敗例」という観点から見たときには完全なる失敗です。果たして、その後、この案件は顧客サイドでの問題案件となり、結果として顧客のIT投資を縮小させる引き金となってしまいました。

 筆者は常々こう思っています。“本当にいいベンダとは、顧客のつけたプライオリティと予算、期間だけで開発を行うのではなく、常にプロジェクトの「重要度」と「技術的な困難さ」のバランスを考慮し続けるするきめ細かい精神を持った企業である”。

 このことは、「たったこれだけの作業量」で「ユーザーに非常に便利」な場合と、逆に「たったこれだけの機能」にもかかわらず「実装はこんなに大変」という、ユーザーとは違った視点でプロジェクトの質を上げる大きな手助けとなります。

ALT 図1 「重要度」と「技術的な困難さ」とのバランス

最上流工程の見えない「コスト」

 作れといわれているものが、例えば、全く別々のフリーソフトを組み合わせれば実現可能なものであっても、多くのベンダは「そこに発注書があるかぎり」作成しようとします。また明らかに費用対効果が望めず、技術的に困難な割にそれほどユーザーの助けにはならない仕様であっても、「仕様書に書いてあるから」「見積もりに入っているから」として作ろうとしてしまいます。

 その原因は非常に単純で、最上流の要件定義(見積もりの前の)において、ユーザーがそういった「検討」を真剣に行うコストを支払っていないからです。ベンダにはよい提案をしろといいながら「よい提案のために顧客の業務を理解し分析し検討する」費用は与えてこなかったのです。非常に大きな案件では上流工程だけコンサルティングという形でコストを与えるケースもありますが、決して業界の通例として行われているわけではありません。

 現に提案の段階でコンサル的な部分にまで踏み込み真剣に検討し「コンサルティング費用」を構築の見積もりに入れたとたんに「価格で他社さんにお願いすることに……」という事態を何度も見てきました。非常によくいわれる「SIに提案力がない」という顧客の不満も、その分のコストを用意せずに求める顧客が非常に多いことに起因しています。仮に、その提案が素晴らしい場合、(素晴らしい提案をした)A社の提案が顧客の要件定義書に化け、構築作業を見積が安いB社に発注する、という現場も何度もみてきました。

 こうなってくると開発側の競争は、見積もりは何人月でその人月単価をどこまで落とせるか、というチキンレースの様相を呈し始めます。この状況で顧客のビジネスプランを……といっている余裕などありません。もちろん、プロジェクトの発注担当者としては、5%安いB社は大変魅力的な企業です。「コストを5%削減した」という実績は担当者の社内における「手柄」になることでしょう。

 しかし、この「単価と人月の戦い」は、結局自社の業務をシステムという観点から最適化する機会を奪い、今回の事例のような案件を喜んで請ける業界の体質を作ってしまってはいないでしょうか?

 次ページから、どういう過程で“そのような案件”が決まり、その結果、現場では何が起こったのか、事例を分析しながら検証します。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ