PR

ユーザー企業には「発注者責任」がある。ところが最近、この責任が希薄なばかりに、外注したシステム開発が頓挫したり、ITベンダーとのトラブルにつながったりするケースが増えている。今回、匿名を条件にITベンダーから「こんな発注は勘弁してほしい」との本音を聞いた。プロジェクトを成功させるために、ITベンダーの声に耳を傾けてほしい。


(木村 岳史)


【無料】サンプル版を差し上げます 本記事は日経コンピュータ6月15日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集2」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。 なお本号のご購入はバックナンバーをご利用ください。

 「開発着手の1週間前になって本当に申し訳ないが、今回のプロジェクトは一時延期することになった。今期の投資案件の全社的見直しのため、経営サイドから待ったがかかってね。ただ、このプロジェクトは重要案件だから、数カ月後には着手できると思うので、少し待ってくれたまえ」。

 準大手のITベンダーの営業担当者は、ユーザー企業のシステム部長からそう通告されて血の気が引くのを感じた。このプロジェクトのために50人の技術者で開発体制を組んでいる。開発着手が1カ月延びるだけで、6000万円ほど売り上げが吹き飛ぶ計算だ。「いったい、どうしてくれるんだ」と、営業担当者は心の中でうめいた。

 この話は、複数のITベンダーの営業担当者の経験談を基に構成した。1週間前に通告というのは極端な例だが、この手のケースはよくある話だ。実際、心当たりのあるユーザー企業の読者も多いことだろう。ユーザー企業からすればやむを得ない事情によるものだが、これでITベンダーはパニックに陥る。後で述べるが、その結果、遅れて着手したプロジェクトが失敗するリスクに直面することになる。

発注にも“QCD”が問われる

 最近、システムトラブルでユーザー企業の発注者としての責任が焦点になるケースが増えてきている。スルガ銀行が日本IBMを訴えた裁判や、現在も継続中のみずほ証券と東京証券取引所の裁判も、単純化すれば「システム開発の発注者にトラブルの責任があるのか」が最大の争点である。

 ただ、訴訟に発展した事件や「動かないコンピュータ」として表面化したトラブル以外にも、“責任の所在”を巡るあつれきは数多い。内部統制強化などの観点からユーザー企業、ITベンダーともあいまいな取引を排除するようになったからだ。そこで今回、ITベンダーの事業部長、営業部長クラスの人に匿名を条件に、「発注者責任」について本音の話を語ってもらった。また、ユーザー企業からも発注者責任を果たすための取り組みを聞いた。

 その結果、見えてきたのは、多くのユーザー企業が「当たり前だ」と考えている発注姿勢に重大な問題が隠れていることだ。まずはのチェックリストを確認してほしい。一見すると、それこそ発注者として“当たり前”の項目が並ぶが、そこにプロジェクトの混乱・失敗につながる可能性があるのだ。実は発注にもQCD(品質、コスト、期日)が問われる。“Q”は発注内容(要件定義など)の品質であり、“C”はITベンダーと握る料金の問題。そして“D”とは、冒頭で紹介したような開発着手などの期日を巡る問題である。

図●「発注者責任」を果たすためのチェックリスト
図●「発注者責任」を果たすためのチェックリスト

 以下、こうしたQCDの観点から、チェックリストの項目のなかに隠れた発注姿勢の三つの問題を分析する。プロジェクトを成功させるために不可欠な発注者責任の意味も、そのなかから見えてくるはずだ。

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

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

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

 何を作ってほしいかを明らかにする要件定義は、ITベンダーの支援を受けたとしてもユーザー企業の責任でまとめるべきこと。ただ、システム化の要件が複雑化している現状では、完ぺきな要件定義は難しい。設計・開発・テストの段階になって隠れていた要件が顕在化し、手戻りの発生などのトラブルも増えている。


続きは日経コンピュータ6月15日号をお読み下さい。この号のご購入はバックナンバーをご利用ください。