要件定義は誰の責任か

　つい最近面白い体験をした。あるプロジェクトで何通かの提案依頼書を発行して複数のシステム開発会社からの提案を受けたのだ。貰った提案書はどれも会社の名を背負った立派なものだったが、面白かったのはシステム開発の要件定義工程における役割分担の表記方法である。

　提案依頼書の中で各工程における成果物と役割分担（特に発注者となる顧客側の作業負担）を示すように依頼していたのだが、出てきた各社の提案書で要件定義工程の役割分担表は以下のようなパターンでバラバラだった。
　ある会社は、発注者（顧客）と受託者（開発会社）の両方に○、別の会社は発注者が○で受託者は支援を表す△、さらに別の会社は逆に受託者が○で発注者が△となっていた。

　このように提案内容が異なるのでその後のプレゼンテーション際に、その意図や内容を確認した。すると今度は各社が口を揃えて、成果物である要件定義書の作成（執筆）は受託者側でやると答えるのだ。同様に、要件出し（要件の提示）は基本的には発注者（顧客）側の担当だとも口を揃える。

　では、何故前述のような差になるのかと、もう少し突っ込んで聞いていくとおぼろげながら各社の要件定義工程へのスタンスというか進め方の違いが見えてきた。まず、発注者○受託者△としてきたA社からは、打合せ時に発注者に要件を提示してくれとの一点張り、提示の仕方は口頭、文書問わないが、受託者は発注者の提示した要件を記録し整理し文書化するという位置づけ。
　次に両社を○としたB社に聞くと、こちらも複数回の打合せで発注者から要件を聞き出すとしている。但し、聞いた要件は次回までに受託者側で資料に纏めるので再度議論をして要件を絞り込んだり明確化をして欲しいという。打合せ回数は多く出来上がりは合作のようなものになるので両社を○としたようだ。
　最後に受託者側が○で発注者側を△としたC社。この会社では過去に類似の開発案件の経験を複数持っており今回採用を予定しているパッケージシステムについても熟知しているので、初回は発注者側に主要な要件を一通り聞くが、その後は手持ちの要件定義テンプレートを修正したものを持ってくるので、発注者はそれをレビューして違う部分を指摘するだけで良いという。そんな都合の良いものがあるのかと聞くと、手持ちのサンプルまでだしてきた。

　ちなみにどの会社も最終的に出来上がった要件定義書を両社合意の上でFIXさせてから次工程以降の最終見積を提示するというのも一緒。だから要件定義書には、両者で責任を持つことになると思うのだが、どうやらその背景に後で揉めた時の予防線をはっているような気配もちらほら。

さて発注者側としてはどのやり方を取るべきか、あるいは信じるべきか。これは前提条件にもよるので一概には言えないが、発注者側からして一般的に一番リスクが小さくなるのは最後の会社のやり方ではある。パッケージ製品のアテがある場合などはC社案が良い。そうではない場合はB社案のほうが良いだろう。案件が流動的でやわやわ、あるいは要件の数が少ない時や急ぐ時ならば、A社のやり方を採択してもよいかもしれない。

　但し、これはまた別の時の経験だが、「要件定義工程は提示・提案型でやります」と言っておきながら、いざその工程が始まったら経験豊富なシステムエンジニアではなく業務知識に乏しいワーカーをあてがわれて、アテが外れたどころか悲惨となった経験もあるので最後は結局"どうやるか"よりも"誰がやるか"であったりもするのだけど。