SIプロジェクトで要件定義は合わない

SIerの立場なら、SIプロジェクトで要件定義をやらないと危なくてやってられないし、ましてや要件定義を請負なんてご辞退案件であることはよくわかる。だから要件定義とUATは準委任契約しろと契約モデルでも言うわけだ。

 

SIプロジェクトでの要件定義は実は要件定義ではない。SIerのやりたい要件定義は、『システム』要件定義でそれ以外の要件は顧客自身で整理してくださいね、と切り分けるものでもある。

 

本来の流れからいえば、経営や事業上の課題、問題からToBeを描き、そのToBeを実現したときに備わっている要件が業務要件である。その内、ITで解決することに決めたのがシステム要件である。

 

であるから、SIerでやりたいのは業務要件からシステム要件を抜き出すことであって、できればそれは顧客で勝手にやっておいて欲しいものである。ToBeから業務要件は何かを探求することの計画は立てにくい。

 

なぜなら。業務を知っているのは顧客だけだからだ。いくらSIerが業務知見を持っているとしても業務を行っているのは顧客であり、業務プロセスの意思決定や制度設計に影響を与えているカルチャはSIerにはわからない。

 

ましてや顧客自身が要件を決められない、導き出せていないままにSIプロジェクトで要件定義をやろうとしても、スコープを決められない(スコープは要件定義できまることを忘れてはいけない)のだから、工程計画は成立しない。

 

ばくっとした工程計画にしか書きようがない。

 

結局、計画を立てられないから、請負えもできず、WBSも作れない。これをウォーターフォールでやるのは筋が悪い。念のために繰り返すと顧客が要件を決められていない場合は、である。

 

ここでの問題は、SIプロジェクトで『システム』要件定義をすることでもないし、要件定義をウォーターフォールでやることでもない。

 

問題は、要件を決められない顧客である。要件を決められないと言うことは、業務で何を達成しなければならないかを顧客自身がわかっていないと言うことの裏返しであり、そんな顧客の言うことは二転三転しそうで危なかしくて近寄りたくない。

 

視点を変えて顧客、業務オーナの立場では、要件の前にToBeモデルを自分でモデルかし、ToBeが備えている要件を抽出できないならSIプロジェクトを切り出してはいけない。内製化して、確かめながらやる方が痛手を負ったとしても小さくて済むし、社内的にはチャレンジの範囲で済むだろう。

 

SIプロジェクトとしてRFIRFPを出し始めると撤退戦をやりづくなる。