SIビジネス「消滅の日」は近い？ ユーザー企業視点で考える、脱“SIer丸投げ”の方策：SIerはどこから来て、どこへ行くのか（1/2 ページ）

SIerに頼らざるを得ない状況を生み出し、維持してきた「強力なビジネスモデル」はどのような背景から生まれ、なぜ今、崩れようとしているのか。また、ユーザー企業が脱丸投げを図るときに取るべき方策とは。

[室脇慶彦，SCSK株式会社]

この連載について

　ユーザー企業にとって、SIerはITシステムの導入から運用、故障時の対応や更新などに欠かせない存在です。

　ただし、その関係性はと言うと、対等なパートナーと言うよりも、ユーザー企業はSIerに対して丸投げしがちで、SIerも「お客さまであるユーザー企業の要望は断りづらい」ために、ユーザー企業のITシステム全体の最適化よりも、その場その場のニーズへの対応を重視しがちな「御用聞き体質」が指摘されてきました。

　しかし今、DX案件の増加やIT人材の慢性的な不足、ユーザー企業の内製化志向などのさまざまな環境変化によって、ユーザー企業とSIerとの関係は変わらざるを得なくなりつつあります。

　この連載を通じて、SIビジネスを取り巻く構造的な問題を掘り下げ、ユーザー企業とSIerが目指すべき関係の在り方を探っていきます。

　第1回では、SIビジネスに40年携わってきた筆者の視点から、SIビジネスやユーザー企業を取り巻く環境の変化を解説した。

　日本特有ともいわれるSIビジネスは、ユーザー企業のITシステムの構築や運用を通じて、日本のITシステムの土台を支えてきた一方で、ユーザー企業が自社のITシステム全体を外部企業であるSIerに「丸投げ」する状況も生んだ。

　しかし、いま状況は大きく変わりつつある。連載第2回となる本稿では、不満を感じながらもユーザー企業の多くがSIerに頼り続けている理由、つまりSIビジネスの「強み」を明らかにしつつ、そのような強みがあるにもかかわらず「SIビジネスが崩壊に向かっている」と筆者が考える背景を述べる。

「強み」があるのに崩壊に向かっている？　

大規模ソフトウェアの受託開発（出典：経済産業省「DXレポート2」）

　図1は、大規模なITシステム（部門システム相当を想定）を開発する際の人的体制の変化を表している。ITシステムの要件の整理から、大まかな設計、インプット・アウトプットの設計、それを実現するためのプログラムなどの具体的ソフトウェアの詳細な設計、プログラム開発（「段階的な詳細化」）と、工程が進むごとに成果物の量は拡大していく。

　プログラムの作成とそのテストの時に作業量はピークを迎え、人員が最大になる。その後は機能単位にまとめて機能が正しく稼働するかどうかのテスト工程に進む。機能統合が進むと、詳細なテストケースが順次、統合機能のテストに移行し、テストケース数は減少する。それに合わせて体制もシュリンクし、リリース後の保守体制レベルに縮小する。

　このように、全てのプログラムを手作りしているソフトウェア産業は、明らかに労働集約的だ。

　ソフトウェア業界のもう一つの特性である、「ソフトウェアは完成後も変化する」点も重要だ。

　建設業やエンジニアリング業で、建築物や石油精製の製造ラインなどの成果物を完成当初から大きく変更することは基本的に考えられない。「石油精製能力を2倍にしたい」などの要望に対しては、最新の技術と機器を活用して再構築するしかないだろう。しかし、ソフトウェア業界では、新しく「消費税の徴収の仕組み」が必要になった場合は、再構築ではなく既存のソフトウェアの機能変更で対応する。

　例えば、ユーザー企業の業務量が拡大したり、部署が拡大したりするとどうなるか。組織の機能分割に伴って、業務自体が変わり、ソフトウェアは入力画面などさまざまなものが分割されていく。

　つまり、ソフトウェアは生き物のように常に変化し、機能はどんどん増加する。まるでエレベータのない3階建てのアパートが、30階建てのタワーマンションに変貌するようなものだ。当初作成した設計書は、変化とともに意味のない代物になっていく。

　そのため、ソフトウェアを正しく維持管理するには、重要な設計情報を正しく更新する必要がある。設計情報には、業務フローなど本来はユーザーサイドが維持管理すべきものが多い。

　先ほどの例えで言えば、もともとの3階建てのアパート部分を内部に抱えるタワーマンションは現在の日本にはないだろうが、部分最適になるような対応を続けた結果、巨大化した「複雑怪奇なITシステム」を抱える企業は多い。

　話を戻すが、責任をもって大規模なITシステムを開発するためには、かなりの人員を投入する必要がある。しかし、ユーザー企業は必要になる人員全体の５％未満しか投入できていない。プロジェクト終了後の余剰人員をクビにしづらい雇用慣行があるため、運用開始後のシステムの維持管理に必要な人員以外は、増やせないからである。

　筆者の経験で言えば、優秀なメンバーばかりを揃えたとしても、通常必要とされる人員のうち最低でも15％は確保できなければ責任をもった構築はできない。これを解決するために、ユーザー企業が採用している手段が次の3つだ。

1. 必要な技術者、あるいはユーザー企業がすべき作業を肩代わりする高度な技術者をSIerに提供してもらう
2. 人員が必要な時期だけ技術者を提供してもらえるようにSIerと契約する（筆者はこれを「ユーザー企業の人件費の流動化」と呼んでいる）。
3. 日本独自の契約形態である「受託契約」をSIerと結ぶ

　３については少し補足が必要だろう。1と2のどちらのケースでも、本来ユーザー企業がすべき作業の遂行をSIerに依存しているため、ユーザー企業には、プロジェクトを実施する能力がない。これではプロジェクトの実行がおぼつかないため、完遂責任をSIerに負わせる受託契約を結ぶのだ。

「SIビジネス」は、ユーザー企業にとっても都合がいい

　まとめると、SIビジネスは、「技術者の提供」「ユーザー企業の人件費の流動費化」「ITシステムの完遂責任の提供」というサービスを提供するという、SIerだけでなく顧客にとっても都合がいいビジネスモデルになっている。

　受託契約のリスクを低減するために、SIerは受託開発を幾つかのパーツに分けて中小SIerに分割発注する。こうすることで契約終了時の減員数リスクを低減できる。同様に、中堅SIerは中小のソフトウェアハウスに分割発注してリスクを低減している。

　つまり、多重請負構造は、システム構築の完遂リスクや人件費の流動費化リスクを、業界全体で低減するために作り上げられたものなのだ。

　こうした多重請負構造は「悪いもの」なのだろうか。多重請負構造を単純な「悪」と見なして解体しようとすることは、現状のソフトウェア開発の方法そのものを見直さない限り危険が伴う。筆者は、現状では下請け法の順守こそがユーザー企業のシステムを責任をもって構築するという体制と、中堅SIerや中小ソフトウェアハウスの事業の保護を両立させるために重要だと考えている。

　こうしたサービスを利用した結果、ユーザー企業は、完遂責任も含めて数十年SIerに丸投げし、ITシステムの中身を理解していない状況にある。つまり、好き嫌いはともかく、SIerの支援なしにユーザー企業は生きていけない。SIerはユーザー企業の生命維持装置になっているわけだ。

ユーザー企業が「ITシステムの主権」を取り戻すには？

　しかし今、ビジネス環境の変化にITシステムを柔軟に適応させたいといったニーズや、ITのシステム障害が経営に与える影響の増大などを背景に、ユーザー企業がITシステムを主体的に開発し、運用したいといった要望が高まっている。ITシステムの主権を取り戻すために、今の状況をどう変えるべきか。

　ユーザー企業が要件を整理してITシステムを再構築し、主権を取り戻せばいいという考え方もあるだろう。しかし、ユーザー企業にはそれができない。「ITシステム化」によって顧客業務がITシステムに隠ぺい化（ブラックボックス化）されるからだ。

　手作業で実施していた業務がITシステム化されるとどうなるか。ユーザーは「何を入力すれば何がアウトプットされるか」は理解していても、「システムでどのような計算が実施されているか」は理解しなくてもシステムを使える。

　ITシステムが長く利用されるにつれて、ユーザー企業よりもSIerの方が業務内容に詳しくなる。時間の経過とともに業務プロセスや作業内容が変容する中で、「実際の業務でどのような作業が実施されているか」はプログラムを解析しなければ正確に把握できないからだ。

　また、ユーザー企業が本来実施すべき業務要件の整理もSIerに依存しているケースは多い。

　こういった理由から、ユーザー企業がIT主権を取り戻そうとしても厳しい現実がある。こうなると、「SIerにロッキングされている」「サービス価格が高い」「対応が悪い」とSIerを嫌っている場合ではない。立場はSIerの方が上位にある。

　ただし、このような認識で顧客に接しているSIerはほぼいない、と筆者は見ている。SIerの現場担当者は、相変わらず顧客を必死に支えている。

　いずれにしても、ソフトウェア開発について現状の体制が続く限りは、ユーザー企業がSIerとの関係を見直してITシステムの主権を確立することは困難だ。ソフトウェア開発を変革するとともに、ITシステムの「見える化」を進めるなど、乗り超えるべき技術課題が山積みになっている。