通常、システム導入を開始する前には「要件」定義を実施します。しかしケンブリッジでは、いきなり「要件」定義を実施するのではなく、まず「要求」定義をすべき、と考えています。
ケンブリッジ流にいえば、違いはこうです。
・「要件」定義:これから作るものの中身を厳密に決めること
・「要求」定義:これから作るものの範囲を決めること(ケンブリッジでは普段「Scope<範囲> Phase」と呼称しています)
作るものの範囲を決める、ということは、何を作るか、作らないか、を決める、ということです。特に、作らないものを決めるのが極めて重要です。
「欲しいものは全部作ればいい」というほど潤沢な予算と時間があれば話は別ですが、通常はそうはいきません。ですから、欲しいものをいったんすべて洗い出し、その中から作るものと作らないものに分けるのです。それでも作るものが多ければ、すぐにいるもの、そのうち必要なものに分けるのです。いわば、要求の「優先順位付け」です。
「施策は出し切ってから絞り込め」でお伝えしたヴァージェンスモデルの考え方です。
もちろん、要求の優先順位付けには、明確かつ言語化された理由が必要です。現場からの「欲しいものを伝えたのに、なぜ作れないのか」ともっともな意見に対して、きちんと説明できなければなりません。そのために改革のゴールをまず定め、ゴールに則った将来のビジネスモデルやあるべき業務を策定する必要があるのです。改革のゴールや組織・業務の将来像に対して、きちんとミートした要求を定義することが大切です。
要求定義の結果は、ベンダー選定において見積の確からしさや、今後のシステム導入プロジェクトの予算、期間、フェーズ分けの根拠へと直結します。例えば、ベンダーから「弊社のシステムにはこんなオプション機能があります」と提案を受けても「それは要求に入っていないので見積から外してください」と返すことができますし、ユーザーから「この機能はどうなったか。いつ入るのか」と問われても「それは来年導入することに皆で決めました」と返すことができるようになる、ということです。
これからシステム導入を始めようとしている読者の方の中で、要求定義を実施するための素材がすべて揃っているか不安になった方は、ケンブリッジで実際に使用しているプロジェクト・アセスメントシートでぜひチェックしてみてください。このシートは、ケンブリッジがコンサルティングに入った際に作成する、各フェーズにおけるアウトプットがベースになっています。項目がすべて〇になっていれば、スムーズに要求定義を始められる、ということです。