松田 幸裕 記
前回の投稿「ITの多重下請け構造は不滅なのか？ その１」で、ITの多重下請け構造について概要レベルで触れ、多重下請け構造により生じる問題をいくつか挙げました。本投稿ではこの多重下請け構造の原因の一つを挙げ、解決策を探ってみたいと思います。
多重下請け構造の原因の一つに、「ユーザー企業によるITベンダーへの任せ方」があると考えています。
日本ではユーザー企業内にIT人材が少ない場合が多く、社内の人材で開発・導入はおろか、プロジェクトをハンドリングすることすら厳しいという状況もあります。その場合はITベンダーにプロジェクトのほぼすべてを丸投げする形になります。さらに、このようなことを続けていると、IT部門内には開発・導入・ハンドリングする能力も養われず、リソース面のみでなくスキル面でもITベンダーへ丸投げせざるを得ない状況となります。
そして、プロジェクトがもしうまく進まない場合に自分たちで軌道修正することもできないため、最初から「責任をとることができるITベンダー」に依頼（依存）する形になります。そして、責任をとることができるITベンダーは人件費が高く、自分たちで手を動かしていては赤字になってしまうため、下請け業者に流す…という形で多重下請け構造の完成です。
このようにプロジェクトのほぼすべてをITベンダーに任せる場合、要件定義を準委任契約で、開発・導入を請負契約で行う場合が多いです。このような形で進められるプロジェクトでよくあるのは、「使われない無駄な機能まで多く盛り込まれる」「使いにくい」という問題です。
ITベンダーとしては赤字プロジェクトになることを避けるために、次々と出てくるユーザー側からの要望を要件定義フェーズで出し切り、計画的に開発・導入を進めたいという思いがあります。しかし要件定義フェーズで適切に要求を出し切れることは少なく、作ってみたらユーザーから「使いにくい」「使えない」と言われることも多くあります。また、ユーザー側としては要求を受け入れてもらえるのは要件定義フェーズまでであるという意識があるため、「こんな機能も必要かも」という程度で将来使うかわからないような機能まで盛り込もうとします。その結果「使われない無駄な機能まで多く盛り込まれる」という現象が発生し、結果としてコストの割に効果が少なく、無駄に高いシステムが出来上がります。
これらの問題を解決するには、「ユーザー企業によるITベンダーへの任せ方」を変えていく必要があると思います。
ITの領域によって、多くを任せるべき場合と任せるべきでない場合はあるでしょう。ただ、少なくとも自分たちでは何もわからないという状況にはせず、イニシアティブをとり、ハンドリングできる状況を維持するべきです。
責任は自分たちでとる、という覚悟や勇気を持ち、全体を俯瞰し、常にプロジェクトを「全体の中の部分」として考え、「部分」を作っていく。「言うは易く行うは難し」ですが、、、これからのユーザー企業の情シス部門には、このような意識が求められているのではないかと思っています。