ユーザー企業には「発注責任」がある。しかし実際には、この当たり前のことをわかっていないユーザー企業は数多い。その結果、システム開発プロジェクトが頓挫し、ユーザー企業とITベンダーの双方が大きな打撃を受けるケースが頻発している。この特集では、ユーザー企業がシステム開発をITベンダーに発注する際に陥りがちな問題点を、発注のQCD（品質、料金、期日）の観点から分析する。

　今回は“Q”、つまり発注の品質にフォーカスして問題点をあぶり出す。なお、この特集は日経コンピュータの2008年6月15日号に掲載した記事をベースに、内容を一部修正して著者の現時点での認識などを加えたものだ。オリジナルは4年半前の記事だが、ITベンダーの事業部長、営業部長クラスの人に匿名を条件に語ってもらった“事実”は、今でも全く古さを感じさせない。

一括契約はここが恐ろしい

　発注の品質、つまり要件定義の問題は、ほぼすべてのITベンダーが指摘するところだ。例えば準大手ITベンダーの事業部長は次のように証言する。

　「当社のSEが支援する形で、ある顧客の要件定義をまとめた。システム部門と利用部門の意思疎通の悪さが気になったが、システム部門がOKを出したので開発に着手した。ところがテスト段階で利用部門から要求した機能がないとのクレームが出て、結局は仕様変更に。追加の開発費を巡り、顧客と随分やり合うことになった」。

　何を作ってほしいかを明らかにする要件定義は本来、ITベンダーの支援を受けたとしてもユーザー企業自身の責任でまとめるべきことだ。しかも、その内容にはITベンダーが開発費を厳密に見積もれるだけの詳細さがほしい。

　大手ITベンダーの元社長は次のように話す。「私がシステム開発に携わっていた随分前ですら、一概に外為システムと言っても、ユーザー企業の要件によってプログラムの大きさで40倍もの開きがあった。どこまでの機能が必要なのか、明確にブレークダウンしてくれないと、開発費がどれくらいになるかはわからない」。

　しかも今日では、システム化の要件がはるかに複雑化している。例えばサプライチェーンの変革を目指すような案件は、ユーザー企業の経営戦略そのものであり、取引先の対応をどうするか、工場のラインをどうするかなど、システムだけではないトータルな変革が課題である。何が課題で何をしたいのかはITベンダーからは分からない。ユーザー企業が考えるべきことである。