JUASの調査によると、システム導入プロジェクトの7割がQCDの観点で失敗しています。また、同調査によるとシステム発注側であるユーザ企業が関わる部分に原因があったと捉えている企業が多いようです（参考：企業IT動向調査2017[JUAS]）。
本コラムではシステム導入を成功させる為に、ユーザ企業が陥りやすい落とし穴を順次紹介します。
今回は落とし穴その３「要件モレ」について解説します。
落とし穴事例
- 受入テストに入った段階で、全国各地の拠点独自のローカルルールがあることが判明した。
稼働遅れをさける為、当面手作業でカバーすることとなり、業務負荷が増大した。 - システム利用者が増加することが今後見込まれたが、
要件定義では機能面に注力し、利用者増加に伴う影響への考慮・検討が十分にできなかった。
稼働して1年後、システムの利用者が増え、動作が重かったり、システムダウンが頻発してしまった。
原因の深堀り
よくある下記２ケースで解説します。
（ケース１）ユーザ企業が担当する場合
～SIベンダーから「システム要件をください」と依頼を受けた～
ユーザ企業は、システム化したい自社業務の内容は把握していますが、その業務を他社（業務を知らないSIベンダー）に伝える事には慣れていません。
また、参考資料になりそうな既存の業務マニュアル等は揃っていない、または資料自体が無く、SIベンダーに伝える為の資料を手探りで作成する場合が多くあります。
作成した資料は日次業務にフォーカスが当たりがちで、
・月次、年次業務
・管理系業務
・他システムとの連携
・非機能要件（性能、セキュリティ等）
等には触れられていない場合がほとんどだと思います。
SIベンダーは、提示された資料について記載内容や一般常識的なシステム制御（ログイン要否等）は確認しますが記載されていない要件については「要件無し」と判断します。
その結果、要件モレが発生します。
（ケース２）SIベンダーが担当する場合
～ユーザ企業から「システムのことは分からないから全部おまかせします」と依頼を受けた～
要望をシステム要件に落とし込むことには慣れているSIベンダーも多いですが、ユーザ企業の業務は知らない為、多忙な担当者と調整の上、まずは業務ヒアリングから始まります。
作成した資料はユーザ企業側から見るとシステム依りの用語が多く、良し悪しを判断できない場合が多くあります。「相手はシステムのプロだから大丈夫だろう」という思い込みで先を進めると、終盤で要件モレが発覚しプロジェクトが失敗します。
要件定義は考慮すべき観点が多岐にわたるため、
ユーザ企業だけ、またはSIベンダーだけで漏れなく実施することは現実的には難しい一面があります。
次回コラムでは落とし穴その４「運用準備の見落とし」について解説します。