PR
藤原 宏高(ふじわら ひろたか)氏
写真:室川 イサオ

要件定義とビジネスモデルの関係はどうなるのですか。

 システム開発を成功させるためには、発注者であるユーザーに十分な能力と運用するためのノウハウが必要になります。ユーザーにすべてを求めるのは難しい。要件定義の経験のあるユーザーはそれほど多くありません。

 それでも大企業は社内に技術者を抱えているのが一般的ですから、それなりのレベルの要件定義が可能ですが、中堅・中小企業にはソフトウエアに詳しい人材すらいないことがあります。システムの要件定義の経験者がいる企業になれば、さらに数は減るはずです。

 この問題を解決するには、要件定義を支援するコンサルタントを育成するのが最も現実的ではないでしょうか。こうでもしない限り、要件定義の問題を回避することはできないはずです。

既存のシステムコンサルタントとは全く違うコンサルタントですね。

 はい。そして要件定義を支援するコンサルタントと、作成した要件定義を基にシステムを開発するベンダーを別々に選ぶ。要件定義を基に、開発するベンダーを指名競争入札で決めるといえばいいでしょうか。

 そのためには、要件定義の支援がビジネスとして成り立つようにしていく必要があります。コンサルタントの資格制度を検討すべきでしょう。

今までは、システムを開発するソリューションプロバイダが、いわば無償サービスとして要件定義してきました。

 だからよくないのです。要件定義は無償ですから、急いで開発に進もうとする。ユーザーへのヒヤリングが不十分なまま開発を進めても、うまくいかないでしょう。しかもどの段階で仕様が確定したのかが、はっきりしません。

数年前から大規模なシステム障害が相次いだこともあって、システムの信頼性を確保すべきだという議論も活発になっています。

 システムの利用の仕方について考慮したうえで、信頼性については議論すべきです。

利用の仕方が違うとは?

 ユーザーによって必要なシステムの信頼性には違いがあります。レベル感の違いをユーザーに正しく伝えなければなりません。

 世の中のすべてのシステムを、何十億円もかけて開発するわけではないのです。これらのシステムは、わずかなミスも許容しないことが前提になっているものが大半です。

 中堅・中小企業が、そこまで高品質のシステムを求めることはほとんどありません。普通のソフトウエアの開発には、何らかの問題が出てくるものです。その中でユーザーとベンダーがお互いにどうやって、システムを運用していくのか、ということです。

どうすればよいのですか。

 開発すること自体がリスクなんだということを、しっかりと理解してもらうことです。業務を見直すこともあり得る作業だと伝えるのです。

 そのうえで、運用まできっちり任せられるベンダーを選びます。ソフトウエアは生き物と同じで、運用の段階でも使い続けていく中でバージョンアップしたり、手直ししたりして常時、改善していかなきゃいけない生き物のようなものですから。

分かっていても、ユーザーは安価にシステムを開発してくれるベンダーを選びがちです。

 リスクを認識すれば、安値受注を恐れるようになるはずです。手抜きされる可能性に気付きます。

 無理に安い価格で開発させようとすると、ベンダーはどこかで手を抜くわけです。まず間違いなく、下流工程でのトラブルの原因になります。

具体的にはどんなことが起こるのですか。

 問題が起こる確率が高いのは、データ移行にかかわるテストです。現実に、本番環境でテストしなかったり、ユーザーに納入して一発で本番稼働させたりすることがあります。

 ユーザーもコストを削減したいので、事前テストはやらないで結構ですと言ってしまう。本番稼働させると案の定、何らかのトラブルが発生してしまう。

 プロジェクトが頓挫したときのリスクを考えてください。場合によっては、何年も社員が進めてきた仕事が全部なくなるわけです。しかも多くの場合、契約には賠償額について、開発費を上限とするといった条項が付いていますから、間接損は請求できないですよ。

 ユーザーのリスクは高いんです。

ひかり総合法律事務所 弁護士
藤原 宏高(ふじわら ひろたか)氏
1954年生まれ。78年に慶応大学卒業。85年に弁護士登録。2003年度、04年度、日本弁護士連合会コンピュータ委員会委員長。06年度、第二東京弁護士会副会長。07年度、経済産業省 情報システムの信頼性向上のための取引慣行・契約に関する検討委員会委員。

(聞き手は,中村 建助=日経ソリューションビジネス編集長,取材日:2008年11月6日)