JUASの調査によると、システム導入プロジェクトの7割がQCDの観点で失敗しています。また、同調査によるとシステム発注側であるユーザ企業が関わる部分に原因があったと捉えている企業が多いようです（参考：企業IT動向調査2017[JUAS]）。
本コラムではシステム導入を成功させる為に、ユーザ企業が陥りやすい落とし穴を順次紹介します。
今回は落とし穴その２「膨らむ要件」について解説します。
落とし穴事例
- 新サービス開始に向けてシステム導入することになった。新サービスということもあり、自社内意見もなかなかとりまとめが進まない。システム稼働時期は決まっているため、要件定義と並行して、システム設計/開発に着手した。開発、テスト段階に入っても要件はまとまらず、システム機能の変更が多発し、その調整に多くの時間がかかった。当初予定していた稼働日には最低限動くものを導入したものの、機能面、品質面で問題が多発した。
- 販売管理システムを導入するにあたり、全国各地の営業担当者にヒアリングしたところ、地域特性や取り扱う件数によって当初想定以上に業務内容がバラバラであることが判明した。システム導入に向けて標準化を検討したが、現場の強い反対にあい、やむを得ず各現場の意向を組み入れてできる限り現状の業務処理を反映した形でシステム化要件をまとめることにしたが、要件は複雑になり、どんどん膨らんでいった。
原因の深堀り
システム導入では、当初想定よりも要件が膨らみ、予算や工期が超過する、というケースがよくあります。
なぜ要件は膨らむのでしょうか。
例えば家を購入したいと思った時、当初、「東京千葉あたりで3LDKのマンションが良い」という漠然とした要望だったものが、不動産サイトで検索したり、不動産屋で話を聞いたり、実際現地を見学すると
・オートロックは必須
・防音設備が整っているほうが良い
・築浅物件が良い
・間取りはやっぱり4LDK
・日当たりは・・
、と具体的な要望が出てきます。
システム導入も同じです。
当初「顧客管理システムを導入したい」という漠然とした要望だったものが、SIベンダーに話を聞いたり、プロジェクトが進む中で成果物（例えば画面イメージ等）が出てくると、新たな要望や課題を見つけ、それを解決する為のアイディア（=要件が膨らむ）が出てきます。
要件は必ず膨らみます。そのため、予め膨らむ前提で対策を立てる必要があります。
次回コラムでは落とし穴その３「要件モレ」について解説します。