システム開発の肝｢要件定義｣はなぜ失敗するのか ｢丸投げ｣は絶対NG､開発の成否はここで決まる

企画実現のために必要な条件を整理する要件定義。不十分だと失敗リスクが一気に高まる。

議論の中で課題を解決していくことも重要（写真：PIXTA）

特集「文系管理職のための失敗しないDX」の他の記事を読む

『週刊東洋経済』2023年3/4号では「文系管理職のための失敗しないDX」を特集。アマゾンでの購入はこちらから。

企画の段階では何を実現したいかを決めたが、要件定義では、企画を実現するための要件＝必要な条件を整理する。そのうち、システムで実現する必要があるものを設計・開発（プログラミング）してつくり上げる。

要件定義は、主に2種類ある。「業務要件定義」と、その業務を実現するために必要な「システム要件定義」だ。順序は必ず業務要件定義を先に行う（スケジュールの都合上、途中から並行で行うことも多い）。業務のためにシステムを開発するので、システム要件を先には決められないからだ。

業務要件の中にはシステム以外の方法で対応できるものもある。当然、それらに関してはシステム要件定義を行う必要はない。

このとき、時間をかけて細かく要件定義を行っても、100点満点にするのは不可能と考えていただきたい。そもそも要件をすべて出し切ること自体が難しいうえに、ビジネス環境の変化で要件自体が変わることはよく起こるからだ。

丸投げは絶対にNG

肝に銘じたいのは、要件定義の内容に責任を取るのは「自社」だということ。外部のコンサルティング会社やSIer（システムインテグレーター）と一緒に検討することが多い工程だが、丸投げは絶対にNGだ。

外注先との契約上の責任の所在の話だけではなく、要件定義の失敗によって使えないシステムが出来上がっても、その被害を受けるのは実質的に自社であり、裁判となり勝訴したとしても、失った時間は取り戻せない。

企画を実現できる要件をしっかりと出せていること。プロジェクトの成否はこの時点で決まっていると言っても過言ではない（この先の工程で失敗することもあるので、成功の可能性がなくなるという言い方のほうが正しいだろう）。

少し古い話だが、米国のアラン・M・デービスという教授が1990年代に出版した著書『ソフトウェア開発201の鉄則』の中で、「要求時点の誤りの修正は、設計段階だと5倍、開発段階だと10倍、テスト段階だと20倍、リリース時点だと200倍のコストがかかる」と指摘している。

いかに上流工程で正しい設計ができるかがコスト面でも大きく響くということを知っておいてほしい。