カスタムSIというリスク(2)

まずは「完成品がどんなものになるのかわからないリスク」。カスタムSIでは、通常「どんなシステムを作るか」を考えるところ、いわゆる要件定義からプロジェクトが始まります。言葉をかえれば、「どんなシステムを作るのかを決めないまま、プロジェクトを開始するのがカスタムSI」だと言えます。当然、多機能なシステムを欲するユーザー企業と、簡単なシステムで済ませたいシステム会社の間での調整は困難を極めます。もちろん、要件定義に入る前の契約の段階でシステムの概要はある程度合意されます。なぜならば、価格を確定するためにも、システムの規模を見積もっておく必要があるからです。ただしこの時点での概要は本当に超概要。そんな超概要を元に予算が決まり、契約が行われ、以後のプロジェクトはその予算に縛られます。本来は、要件定義を済ませずに予算を決めること自体に無理があるのです。一部、要件定義を別契約にするプロジェクトもありますが、数はさほど多くありません。要件定義、またその後の仕様設計において必要であることがわかった機能が当初の契約に含まれていたかどうかで、プロジェクトが紛糾することは日常茶飯事です。

そして次に「完成品がどんな技術で作成されるのかわからないリスク」。システム開発は、言語、H/W、S/W、OS、N/W技術、開発手法、設計手法など、さまざまな技術要因が合わさって成り立っています。そしてその複雑度、新製品・新技術の生まれては消えるスピードは、ますます加速するばかりです。単体の製品の複雑化だけでも凄まじいのに、これらの組み合わせということになると、その混迷度はますます深まるばかりです。よって、契約の時点(超概要しか決まっていない時点)でどんな技術を使ってそのシステムを作ればよいのかわからないのは言うまでもありません。それどころか、ある程度大きな規模のシステムになると、詳細な設計が完了した後でもどんな技術を組み合わせてそれを作るのが最適なのか、判断するのはとても難しくなります。そして、「どうやらこの製品とこの技術を使えばよさそうだ」とうい事がわかっても、実際にそれが期待通りに動いてくれるのかはわかりません。全く同じシステムなど世の中には存在せず、そこに潜む技術的リスクは常に未知です(程度の差はありますが)。そういう意味では、全てのカスタムSIは特注品というよりも「試作品」と言えるかもしれませんね。どんな動作をするか、そしてどんなバグが潜むのか、誰にもわからないのです。

そして最後の「そもそも完成するのかどうかわからないリスク」と、じゃあどうしたらいいんだ？ということについて考えるのは…次回に。