企業システム開発の現状と課題(2)
残念ながら、システム開発プロジェクトは失敗するケースが多いが、プロジェクトの成否を左右する最大の要因は顧客側にある。
重要なことは、顧客システム担当のシステムスキルレベルだけでなく、ユーザー部門との力関係、顧客企業を取り巻くビジネス環境なども大きく影響してくる。
しかしベンダー側はプロフェッショナルとしてプロジェクトに参加しているのであるから、失敗した場合の責を免れることはできない。
これまで関わった失敗したプロジェクトを振り返り、ベンダー側の反省点を以下のように挙げてみよう。
- スキル・技術力不足
業務知識やコンピュータシステムに対する知識とセンスが欠如しているベンダーが担当したシステムは失敗する可能性が高い。
特に最新の技術を取り入れて構築しようとしているシステムの場合は致命的である。
知らないことを分かったように取り繕って、いい加減にシステム構築をおこなおうとするのは、プロとして不誠実であり、同業者として恥ずかしい。 - マネジメント力不足
システム開発にあたって本質的な管理ができていないプロジェクトがある。
それは、数字の辻褄を合わせることで問題点を先送りし、終盤に来て破綻するケースにつながる。
特に元請けが標準化や共通部品を担当する場合、いっこうに成果が出てこないまま、プログラミングが終わってからようやくバギーなものが出てきて、開発担当にしわ寄せが来ることが多い。 - 見積りの失敗
最初に述べたように、最大の要因は顧客側にあるため、初見のお客さまの実際のシステム構築費用を見積もるのは不可能である。
そうは言っても、予算を確保しないとシステム開発はスタートしないため、様々な手法を使って見積もりをすることになる。
しかし時間をかけて見積もりしても、顧客の思惑により予算額が最初から決まっている場合がほとんどである。
そんなだったら最初からいくらでやってくれと言ってもらった方が、お互いに良いと思うのだが。
値切られ、叩かれ、機能カットなどをおこない、見積もりを顧客予算に合わせて提示して、ようやくスタートすることになる。
終わってからプロジェクトを締めてみると、最初の見積もりがいかに正確であったかを実感することもあるが、もうその時点では遅い。
往々にして予算が不足しているプロジェクトは、最初のコンサルを入れた検討段階や、ヘッドベンダーが担当する分析段階で予算をオーバーしてしまい、その後のシステム開発にそのしわ寄せがくることになる。
特にこれまでの業務を大きく変えようとする野心的なプロジェクトに、このケースが多い。
