経産省のIT(SIer)業界改革案の方向性

2019年4月16日火曜日

DX システム開発 システム業界問題

t f B! P L


デジタルトランスフォーメーション(DX:Digital Transformation)


経産省が進めるDX(デジタルトランスフォーメーション)は最終的には「電子政府」を実現するための計画だ。
以下のサイトで広報されている。


しかし、これを実現するにあたって
で解説した現在のIT(SIer)業界の問題の解消が必要になる。
また、IT(SIer)業界の問題を解消しなければ「2025年の崖」が訪れ最悪IT(SIer)業界自体が瓦解し国民が必要なITシステムの提供を受けられなくなる。


DXは電子政府の設置を目指すにあたり、障害となるIT(SIer)業界の問題を解消することを目指している。
その大きな方向性についてざっくりと解説したい。


上記の資料から「DXシナリオ」と「DXを実行する上での現状と課題への対応策」を引用する。

引用、


DXシナリオ

ユーザ:
  技術的負債を解消し、人材・資金 を維持・保守業務から新たなデジタル技術の活用にシフト
  データ活用等を通じて、スピーディな 方針転換やグローバル展開への対応を可能に
  デジタルネイティブ世代の人材を中心とした新ビジネス創出へ

ベンダー:
  既存システムの維持・保守業務か ら、最先端のデジタル技術分野に 人材・資金をシフト
  受託型から、AI、アジャイル、マイクロサービス等の最先端技術を駆使 したクラウドベースのアプリケーション 提供型ビジネス・モデルに転換
  ユーザにおける開発サポートにおいては、プロフィットシェアできるパートナーの関係に


<中略>

対応策

1 「見える化」指標、中立的な診断スキームの構築
 経営者自らが、ITシステムの現状と問題点を把握し、適切にガバナンスできるよう、
 • 「見える化」指標の策定
 -技術的負債の度合い、データ活用のしやすさ等の情報資産の現状
 -既存システム刷新のための体制や実行プロセスの現状 
• 中立的で簡易な診断スキームの構築

2 「DX推進システムガイドライン」の策定
 • 既存システムの刷新や新たなデジタル技術を活用するに当たっての「体制のあり方」、「実行プロセス」等を提示
 • 経営者、取締役会、株主等のチェック・リストとして活用
 → コーポレートガバナンスのガイダンスや「攻めのIT経営銘柄」とも連動

3 DX実現に向けたITシステム構築におけるコスト・リスク低減のための対応策
 • 刷新後のシステムが実現すべきゴールイメージ(変化に迅速に追従できるシステム に)の共有(ガイドラインでチェック)
 • 不要なシステムは廃棄し、刷新前に軽量化(ガイドラインでチェック)
 • 刷新におけるマイクロサービス等の活用を実証(細分化により大規模・長期に伴う リスクを回避)
 • 協調領域における共通プラットフォームの構築(割り勘効果)(実証)
 • コネクテッド・インダストリーズ税制(2020年度まで)

4 ユーザ企業・ベンダー企業間の新たな関係
 • システム再構築やアジャイル開発に適した契約ガイドラインの見直し
 • 技術研究組合の活用検討(アプリケーション提供型への活用など)
 • モデル契約にトラブル後の対応としてADRの活用を促進

5 DX人材の育成・確保
 • 既存システムの維持・保守業務から解放し、DX分野に人材シフト
 • アジャイル開発の実践による事業部門人材のIT人材化
 • スキル標準、講座認定制度による人材育成


この資料から私なりの解釈で経産省の描く将来像を説明したい。


技術的負債を解消

技術的負債となっているレガシーシステムの問題は以下のように纏められる。
(1)業務ロジックの喪失
(2)全体が全体に複雑に繋がる「田舎の温泉旅館」状態のシステム構造
(3)IT人材不足(保守運用者も確保できず、システム刷新要員も確保できない)

「技術的負債を解消し、人材・資金 を維持・保守業務から新たなデジタル技術の活用にシフト」
「既存システムの維持・保守業務から、最先端のデジタル技術分野に 人材・資金をシフト」
とあるので、レガシーシステムを最終的に廃棄することが想像できる。

ただいきなり現在のレガシーシステムを無くすことは不可能なので段階的に少しずつ、レガシーシステムから新システムへ業務の主役をシフトしていくことを想定していることが窺える。

そこで鍵になってくるワードが「マイクロサービス」と「アプリケーション提供型ビジネス」だ。

マイクロサービスの導入

現在の業務システムはOracleなどのDBMSやミドルウェアはパッケージ製品を導入するが、ほとんどの機能は個々の会社の業務に合わせてSIerがゼロから開発する。
会計や在庫管理など企業の業務には似たような業務は沢山あるが、日本のユーザー企業は「業務にシステムを合わせる」為、会計のような「似たような業務処理」も個々の企業でゼロから開発してしまう。
このような無駄を「車輪の再発明」と呼ぶ。
SIerはこれが無駄なのは理解しながらも発注元のユーザー企業の要望に応えるしかない為、「車輪の再発明」を繰り返している。
「車輪の再発明」を止めて、パッケージソフトのように、一度作った機能を多数の企業で共有すれば、IT人材の不足も多少は改善する。
また、機能を共有する企業が多ければ多いほどソフトの価格は安くできる。

鍵となるワードの一つ「マイクロサービス」とはある程度抽象化された業務処理をある程度汎用的な単機能のソフトウェアとして実装し、Web APIのようにその機能を「ソフト部品」として外部に提供するソフトウェアの構成方法である。
システムはこのマイクロサービスを複数集めて組み立てることで開発する。
ある程度汎用的な機能がマイクロサービスによって出来上がっている為、システム開発はスクラッチ開発(ゼロから開発)するよりかなり簡単で安くできる。
また、マイクロサービスの機能を十分に抽象化し汎用的な製品にすることが出来れば、複数の企業システムでマイクロサービスを共有することができる。
ソフトウェアを多数の企業で共有できれば安い単価でソフトウェアを提供することができる。
それだけユーザー企業の経済的負担は軽くなる。
ITベンダー側も一度作ったソフトウェアを何度も販売できるので受託開発のようなラットレースから抜け出し、人ではなく技術を販売する正常なビジネスを行うことができる。

受託開発からアプリケーション提供型ビジネスに転換

この方法だとITベンダーのビジネスは「受託開発」ではなく「アプリケーション提供型ビジネス」になる。
実際に提供されるのは単独でも機能し、ソフト部品としても機能するマイクロサービスをサブスクリプションや売上に対する従量制で提供することになると思う。
つまり現在の受託開発ビジネスは経産省の構想が成功すれば、ほぼ消滅することになる。
例外は当然残ると思うが。

複数のマイクロサービスを他社から購入して、組み立ててシステムを開発する体制になれば、業務システム開発のコストは安くなる為、ユーザー企業が自分で開発できるようになる。

請負契約からプロフィットシェアへ

「アプリケーション提供型ビジネス」になると請負契約でシステムを買い取る契約は適さなくなる。
機能サービスを継続的に借りる形になる。
従ってソフトウェアの対価はサブスクリプションかプロフィットシェアかレベニューシェアになると思う。
サブスクリプションは月額定額制。
プロフィットシェアとレベニューシェアは売上に対して、何パーセントという形で収益を分ける方式だ。
ユーザーの売上が増加するほどITベンダーの売り上げも増加するため、ITベンダーがユーザーの売上増加に責任を持ち、積極的に貢献するようになる。
現在の請負契約では「ユーザーにどれだけ金を払わせるか」を競うことになるので、ユーザーの利益とITベンダーの利益が一致しない。
経産省は「ユーザーの利益」と「ベンダーの利益」を一致させようとしている。

ちなみにプロフィットシェアは利益を分配するやり方で、レベニューシェアは売上を分配するやり方である。
経産省はプロフィットシェアを押しているようだが、私はレベニューシェアの方が良いと思う。
利益は費用を積み増しできればいくらでも操作できてしまうから、操作の効かない売上を分割したほうが良い。
また、バックオフィスなど売上の補足できないものはサブスクリプションになる。

アジャイル開発の導入

マイクロサービスはユーザーのニーズを受けて随時アップデートを繰り返す為、業務システムもそれに合わせてアップデートを繰り返す必要がある。
現在の請負契約によるシステム買取方式には適さない為、ウォーターフォール開発は使用できない。
必然的に「アジャイル開発」になる。

アジャイル開発は1週間から1ヶ月の周期で反復的に動くソフトウェアを開発しリリースする開発手法で、現在の多重請負による基本設計・詳細設計・開発・テストと工程ごとに担当者も担当社も異なる体制では実施できない。
現在のSIer型多重請負分業体制はリリースまで時間がかかりすぎる為、アジャイル開発に適さない。
アジャイル開発では、全ての工程を同じ担当者が実施することになる。
また、同じ担当者が全ての工程を実施するのならば、現在のSESのように人手が必要になったら情技師(ITエンジニア)をかき集めて、完成したら解約するという雇用形態は適さなくなる。
ユーザー企業とITベンダー共に人の入れ替わりが少なくなる為だ。

まとめ

経産省構想を纏めると、現在のIT業界のあり方は

・一括スクラッチ開発
・受託開発
・ウォーターフォール開発
・請負契約
・SESによる離散集合的な人材配置

となっているものを、

・複数のマイクロサービスの組み合わせによる開発
・ユーザー企業はシステムを内製
・ITベンダーはマイクロサービスアプリケーション提供
・アジャイル開発
・プロフィットシェア・レベニューシェア・サブスクリプション
・ユーザー・ベンダー共にIT人材を長期雇用

へと変えようとしている。

また、数値目標として、
IT人材の分布を2017年時点では、ユーザー企業:ITベンダー= 3:7 となっているものを、5:5 に変更しようとしている。
つまり内製比率を高めようとしている。

IT人材平均年収を2倍にするという目標も掲げている。
これは現在の多重請負体制やSESに代表される仲介業者によるマージンを減らすか無くしてしまえば容易に実現できる。
逆に中抜き(仲介業者を外す)しなければ実現は難しい。
当然、中抜きは実施するつもりだろう。
でなければ、どうやって平均年収を2倍にするか分からなくなる。

経産省の目指す方向は正しいと思う

私は経産省の目指す方向は正しいと思う。
このDXが実現できればユーザー企業にとっても現場で働くITエンジニアとっても利益になる。
損害を被るのは仲介業者だけだ。
ただし、これが実現できるかどうかは未知数である。

私は以前こんな記事を書いたことがある。

経産省の構想と私が理想的と考えるIT業界のあり方が似ていたので、DXは好意的に受け止めている。
個人的にも応援したい。


このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ