要件定義を提案したら怒られる
以前、提案したときに要件定義フェーズを設けたら、提案説明に行った営業が怒られたと帰ってきた。先方が言うには『要件はこちらで決めるものだ』『要件定義は既に終わっている』なのだそうだ。
ごもっともである。SIerとしては、要件は顧客が決めるもので、その要件の中からシステム要件を抜き出し、その要件のシステム方式、実現仕様を仕様に落とし、コードに変換するのが理想である。ぜひそうありたい。
だがしかし、これまで要件が決まっていたことは大規模プロジェクト以外では１度もなかったと言う経験則がある。その経験から言えば、先の案件は非常に危うい。特に、これまでITのシステムが存在しなかった業務領域の場合はリスクが高い。なぜなら、一度も業務を可視化したことがない可能性が高いからだ。
システムリプレースであったとしても、単なる再構築ということはありえない。なぜなら、それでは多額の費用の稟議が通らないからだ。必ず、機能追加や非機能要件が追加されるか、再構築費用と維持管理費用が削減された上で、機能追加になることが多い。
情報システム・モデル取引・契約書（P14）をよく見直すと、契約形態に準委任契約とあり、開発基本契約とあるから要件定義は（委託を受ければ）SIerがやることも認めている。まあ、もっと遡るとシステム化の方向性までたどり着けるので、システム化要件を決めるところから、冒頭の考え方も間違っているわけではないということだ。
では、冒頭の場合は、要件定義をやらない（＝提案しない）前提で提案して良いのか。
答えは、NGである。要件定義をしたと言っているが、システム要件定義をしているとは限らない。そのリスクがプロジェクトで発現した場合、その作業は含まれていないと明確に主張できる準備ができているケースはとても少ない。
要件定義をやらない場合、つまり、基本設計から開始するための前提条件をつけ、システム化要件を記述したドキュメントの精査をプロジェクトの契約に含める必要がある。これが実際に起きてしまうとプロジェクトの雰囲気は最悪になるだろう。なにせ、プロジェクトの開始条件を満たしていないとSIer側がリジェクトすることになるからだ。
冒頭の提案では、要件定義とはせず、要件定義と基本設計の間にワンクッションの工程を設け、さらに前提条件を加えてリスクを回避する案を提示した。
覚えておきたいのは、SIerが要件定義と言ったら、システム化要件の定義である。業務要件をする気はさらさらない。一方、顧客がシステム化要件をスラスラと書けるかといえば、まだITで実現したこともない業務を文字や図表で可視化すること自体やったことがないのでイメージを持っていないから躊躇してしまうし、システム化要件以降の工程で欲しいインプット情報に何を必要としているかも知らない。本当は知っていて欲しいが。
