2017.11.18

要件定義力を徹底的に再構築する：②プロジェクトの失敗は、要件定義が出来ていないことに起因する

プロジェクトの失敗は、要件定義が出来ていないことに起因する

誰もが納得することだろう。開発の三大失敗理由は、「要件定義が終わらない」、「パフォーマンスが出ない」、「移行が出来ない」である。かつて、筆者が外資系ファームに属している際に、失敗プロジェクトの総括というものを数多く手掛けているが、失敗の理由は、ほぼこの3つの事象に収斂する。
もっとも、パフォーマンスが出ないというのは、HWの構成やサイジングを誤っていることや、SWの構成や相性が悪くて起こることが多いため、これはこれで要件定義時にきちんと検討できなかったと考えることができる。また、移行が出来ないというのも、要件定義段階での移行方針、移行計画が適当に作られてしまうことで、着手タイミングがむやみに遅れてしまったり、実際の移行プログラムの作成やデータの投入に本来は多大な工数がかかるにも関わらず過小に見積もることなどで起きるとも言え、これも要件定義が出来ていないことに起因すると言えないこともない。
すなわち、プロジェクトの失敗は、ほぼ要件定義が出来ていないことに起因するのだ。逆の言い方をすれば、要件定義を成功することが出来れば、ほぼすべての案件で成功することが出来るともいえる。また、運用をきちんとする…すなわち、障害を発生させることなく、効率的に運用を行うにも、要件定義がきちんとすることが寄与する。システム障害の70%程度は、新規や追加開発のリリース後、1か月以内に起きる。すなわち、開発がきちんと行えれば、運用段階での障害も劇的に減らすことが出来るのだ。

こうしたこともあり、筆者は、要件定義力こそ、情報システム部門にとっての「核心的能力」だと思っている。

情報システムのライフサイクル的にみて、もっとも重要なフェーズが要件定義だ。システムのライフサイクルで見たときに、ほとんどの企業で要件定義終了後、ベンダーへ委託する。多くの場合、請負で委託することが多いだろう。そして、開発受注をしたベンダーがそのまま保守・運用局面を担っていくだろう。ライフサイクルで見たときの大きな転換点が要件定義であり、その機能性、安定性、経済性を決定づける。システムの成功と失敗の分水嶺が要件定義にあるということだ。
情報システム部門の使命から考えても、要件定義がその使命の達成のために極めて重要な業務であることは明白である。情報システム部門の役割は、IT-ROIを継続的・長期的に最大化していくことにある。そのために、良質なシステムを安価で装備し、安定的かつ効率的に運用していくことが求められる。
良質なシステムとは、経営、ユーザーそして顧客にとって効果をもたらす機能を装備することであり、障害のない安定的な運航を可能とするシステムである。安価・効率的であるとは、委託契約段階で価格する価格内に、開発作業や運用作業を押さえることで達成される。こうした、質の決定、価格の決定は要件定義を通じて行われるもので、この業務こそが情報システム部門のパフォーマンスを決定づけることに異論はないだろう。
これ以外の能力が重要ではないかと言うと、決してそんなことはないのであるが、要件定義能力の「核心度」から比べると、「周辺度」が高い能力が多くなってくる。最近では、IT-ROIの管理の重要性が高まり、ITのコストの詳細把握が求められ、効果管理の重要性は高まっているが、要件定義でベンダー委託をする際の見積もりの明細度、具体性、比較容易性を確保しておかなければ、コストの把握自体が難しくなる。また、ベンダーマネジメントの重要性も、ベンダーとの利益相反が大きくなっている現代では、重要度は高まっているが、ベンダーに何をどういう条件で委託をするか、能力の見極めをどう行うか、は要件定義時のRFP~ベンダー選定プロセスで実現できるものが多い。ユーザーへの業務改善・改革提案は、イノベーティブな改革を望む経営やユーザーが増えてきていることにより、一層の重要性を増しているが、要件定義を経て実際にどれくらいのコスト、実現性で可能となるのか、業務改革自体の成否がそこで決まることとなるため、やはり要件定義が核心的な影響をもたらす業務であることには変わりはない。

情報システム部門にとって、高い要件定義力というものは不可欠なものである。そして、落ちこぼれているIT部門は、間違いなく要件定義力に問題を抱えている。要件定義力を回復することが、情報システム部門を落ちこぼれから脱するための核心であり、一丁目一番地の最重要課題となるのだ。