DXレポートの2025年の崖　要約

〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜

こんにちは、KiYOです。　システムエンジニアをやってます。

仕事でレガシーシステムのモダナイゼーションやDXについて調査することがあったので、経済産業省が発表した「DXレポート」を読んでみました。　57ページと長く、お国さまの硬い表現でわかりずらかったので、私の独断と偏見でまとめてみました。

まず、DXレポート？

2025年の崖？

という言葉の前提を説明し、現状の課題とその対応策を解説していきます。

みなさんの会社のIT資産の有効活用やダウンサイジング成功の一助になれば嬉しいです。

どうぞご覧ください。

DXレポートとは

まずDXレポートとは、2018年9月に経済産業省から「DXレポート〜2025年の崖〜」が発表されました。

このレポートの立て付けは以下の通り

1. 検討の背景と議論のスコープ
2. DXの推進に関する現状と課題
3. 対応策の検討
4. 今後の検討の方向性

日本企業のシステムを新しく見直し作り直ししておかないと2025年に痛い目にあうので、このDXレポートを参考にして、2025年までに各社課題の洗い出しと対策をしてくださいね。というものです。

（お偉い教授や多くの大企業のトップが4回に渡って討議した内容です）

2025年の崖とは

2018年9月に公開された経済産業省から発表された「DXレポート〜2025年の崖〜」には、ブラックボックス化してしまう基幹業務システムが原因で、2025年には全国で年間最大12兆円もの経済損失が生じる危機が述べられました。

2025年までに刷新しなければ崖に落ちると提言しました。

なぜ、DXレポートを書いたのか？

「検討の背景と議論のスコープ」というお堅い言葉で書かれてわかりにくいので、私なりに解釈するとこんな感じかなと思います。

【背景】

• あらゆる産業で新しいビジネス・モデルを展開するにはデジタル技術は欠かせない
• その為に、デジタルトランスフォーメーション(DX:DigitalTransformation)をスピーディーに進める

(出典)Japan IT Market 2018 Top 10 Predictions: デジタルネイティブ企業への変革 – DX エコノミー においてイノベーションを飛躍的に拡大せよ, IDC Japan プレスリリース, 2017 年 12 月 14 日 

【問題点】

• 既存システムが老朽化・複雑化・ブラックボックスする中では、データ利活用は難しい
• 既存システムの運用保守に資金を割かれ、IT投資にリソースを振り向けることができない

既存ITシステムがブラックボックス化していない企業や、そもそも大規模なITシステムを持ってない企業の場合、問題ないが日本国内全体を見るとこれらの問題を抱えている企業は少なくないということで、政府がDXレポートをまとめました。

DXの推進に関する現状と課題

ITシステムが今後DXを実行していく上で大きな課題であることは、上記の問題点で分かっていただけたかと思います。

DXレポートの研究会で上がった現状の課題を整理したいと思います。

DXの足かせとなっている既存システム

既存システムで以下の要素を持っているシステムを「レガシーシステム」と定義しています。

1. 技術面の老朽化
2. システムの肥大化・複雑化
3. ブラックボックス化

上記を持ったシステムは経営・事業戦略上の足かせとなり、高コスト構造の原因となっているようです。

JUASのアンケート調査によると、8割近い企業が「レガシーシステム」を保有しており、7割近い企業が自社のデジタル化の足かせになっていると回答しているようです。

(出典)一般社団法人日本情報システム・ユーザー協会「デジタル化の進展に対する意識調査」(平成 29 年)を基に作成 

既存システムのブラックボックス化

古いシステムを使っているから必ずブラックボックスが発生するわけでもない。適切なメンテナンスを行うITシステムマネジメントを行っている場合は、起きにくい。ただし、開発から時間が経過していくとレガシー問題の発生確率は上がる傾向のようです。

怖いのは最新のクラウド技術などを適用しても、時間の経過とともにレガシー問題が発生するということです。（適切なITシステムマネジメントしてないとレガシーになるでしょうね）

不十分なマネジメントによるレガシー化の繰り返し

レガシーシステムはマネジメントの問題でもあります。「ブラックボックス化」する原因を追求しておかないと、システムをモダナイズ（システム刷新）しても、時間の経過とともに再度レガシー問題の発生確率は上がります。

有識者の退職等によるノウハウの喪失

特定の技術者が「有識者」として居続ければ、組織としての管理がおざなりになる可能性が高い。これまでは、有識者が社内にいたため、管理上の問題が顕在化することは少なかったが、2007年問題（団塊世代の大量退職）で多くの企業においてブラックボックス化してきている。

業務に合わせたスクラッチ開発多様によるブラックボックス化

現状業務にピッタリ合った、実は過剰品質になっているシステムを求める声が国内企業には強い。

汎用パッケージやサービスを活用する場合は、ノウハウを持った企業は多くいるが、日本では、汎用パッケージを導入した場合でも自社の業務に合わせた細かいカスタマイズを行う場合が多い。その結果、スクラッチと同様にブラックボックス化する可能性が高い。

皮肉なことに、企業は改善力で日本経済を立ち上げてきた。品質管理（QC、QA）手法を積極的に取り入れ、改善活動に力を入れてきた。その結果、多くの成果を生むとともに、システム改修による複雑化の一因となってきた。

IT関連費用のうち8割以上が既存システムの運用保守に当てられている

日本国内企業のIT関連予算の80％は原稿ビジネスの維持・運営（ラン・ザ・ビジネス）に割り当てられている。ラン・ザ・ビジネス予算が90%以上を占める企業も40%を超えていている。それにより、新たな付加価値を生み出すために必要なIT戦略に対して、資金・人材を十分に割り当てられないという課題がある。

不必要な運用・保守費は負債として捉えることができ、こうした負債は「技術的負債」と呼ばれている。

ユーザ企業における経営層・各部門・人材等の課題

経営層の危機意識とコミットにおける課題

事業部毎に個別最適化されたシステムの全体最適・標準化を試みても抵抗勢力があって前に進まない。既存システムの問題解決に、業務自体の見直しも求められることがあるが、それに対応する現場サイドの抵抗が大きく、いかに進めるかが大きな課題となっている。

こうした各事業部の反対を押し切ることができるのが経営トップのみである。　しかし、そこまでコミットしている経営者が多いとは言えない。

情報システム部門における課題

有名なベンダー企業に頼んだから大丈夫という考えに陥りがちである。ベンダー選定責任は不明確で、何か問題があればベンダー企業側の責任とされることが多い。

自分で考えられず、他責にしたがるようなものです。

事業部門と情報システム部門の役割

事業部門がプロジェクトのオーナーシップを持って、仕様決定や受け入れテストを実施していくことが必要である。

しかし、現状はそうなっていないことが多い。また、事業部門と情報システム部門でコミュニケーションが十分に取られていない場合も多い。

こうした結果から開発したシステムが事業部門にとって議場の競争力に繋がらないケースになることも多い。

全体最適を実現する点で業務をシステムに合わせることも案としてあります。

ユーザ企業におけるIT人材不足

1. DXを進める上でベンダー企業に頼らざるを得ない現状
2. 老朽化したシステムの運用・保守ができる人材の枯渇
3. 困難となるITエンジニアの教育・確保

ユーザ企業とベンダー企業との関係

ユーザ企業からベンダー企業への丸投げ

要件定義から請負契約するケースも少なくなく、ユーザ企業がベンダー企業に要件定義から丸投げの状態になってしまっている。　ベンダー企業に開発するものを決めてくれと言っているのと同じです。ベンダーも売り上げが上がるため要望を受けていているのが現状です。

このような状態では失敗するのは目に見えています。また、アジャイルのようなユーザのコミットメントが強く求められる開発方法では推進するのに無理があります。

詳細はベンダーと取り組んでいく必要はありますが、要件の確定はユーザ企業の責務です。

ここを認識することが重要です。

ユーザ企業とベンダー企業の責任関係

ユーザ企業とベンダー企業との間の責任関係や作業分担を明確にしておく必要がある。

ユーザ企業自身が原稿システムがどのくらい肥大化・複雑化しているか分からず、現行の仕様も不明確であるにも関わらず、現行機能保証という条件でシステム刷新をベンダーに業務委託する場合が多い。

必要とする要件を明確化できないまま発注することもあるため、出来上がったシステムがユーザ企業の意図したものと異なり、テスト工程で手戻りが発生する。それにより開発費用の大幅超過や納期遅延による機会損失が生じる。

このようなトラブルにおける責任がユーザ企業とベンダー企業間で不明確になっているために、責任の押し付けあいに繋がり、紛争・訴訟へと発展するケースも増えている。

ベンダー企業がユーザ企業のことを理解しているという前提に立っているため、問題が発生するとベンダー企業に責任を押し付けやすいというベンダー依存関係がある。

こうした背景から、ベンダー企業による既存システム刷新の提案を萎縮させている側面もある。

アジャイル開発における契約関係上のリスク

今後、DXを実行していく上で、要求仕様が不明確な状態で小刻みな開発を繰り返すことで具体化していくような案件もある。このような案件では、従来のウォータフォール開発より、アジャイル開発の方が適している場合もあります。

しかし、２点課題があります。

1. 完成責任を伴う請負契約では、仕様を不明確としたまま開発を進めることが行いにくい
2. 完成責任のない準委任契約で進めようとすると、ユーザ企業からすれば、ベンダー企業側により良いシステムを開発するインセンティブがないように見えるため、不安が残る

アジャイル開発に対する理解を得るのは難易度が高い。また、要求仕様を固めずに開発を進めるという性質上、ユーザ企業にとってはどんな企業が必要かということをベンダー企業に任せれば良いと誤解することがあり、プロダクトのオーナーシップの責任まで放棄してしまうと、結果的に開発はうまく進まない。

情報サービス産業の抱える課題

情報サービス産業の概観

情報サービス産業は、実態的にはユーザ企業組織の一部機能を構成している。SIを主とした既存ITシステムの受託開発に適した構造的特徴を持っています。

1. 情報サービス産業は企業数27,375、全売上高25兆円、従業員数97万人の産業となっている
2. 技術を提供するだけではなく、顧客プロジェクトの規模の変化に対応すべく顧客側の人件費の変動費化に貢献している。これは欧米においてユーザ企業側が人員を確保している構図と逆になっている。
3. 顧客の代わりにリスクを請け負う受託契約という形態も他国には見られない特殊なものとなっている。

(出典)独立行政法人情報処理推進機構「IT 人材白書 2017」より 

DXを推進しない場合の影響

既存ITシステムの崖（2025年の崖）

あらゆる産業において、新たなデジタル技術を活用して新しいビジネスモデルを創出し、柔軟に改変できる状態を実現することが求められています。

何をいつまでになすべきかの見極めに苦労するとともに、複雑化・老朽化・ブラックボックス化した既存システムも足かせになっています。

複雑化・老朽化・ブラックボックス化した既存システムが残存した場合、2025年までに予想されるIT人材の引退やサポート終了等によるリスクの高まり等に伴う経済損失は、2025年以降、最大12兆円/年に登る可能性があります。

ユーザ企業はデータ活用しきれず、DXを実現できず、デジタル競争の敗者となる恐れがあります。

ITシステムの運用・保守の担い手が不在になり、多くの技術的負債を抱えるとともに、業務基盤そのものの維持・継承が困難になります。

サイバーセキュリティや事故・災害によるシステムトラブルやデータ損失・流出等のリスクも高まることが予想されます。

（注）経済損出の根拠

1. 2014年1年間の損失額は国内全体で約4.96兆円
2. 2010年代のシステムダウンの原因割合（日経BP社「日経コンピュータ2017.8.3」

1. セキュリティ　29.1%
2. ソフトの不具合　23.1%
3. 性能・容量不足　7.7%
4. 人的ミス　18.8%
5. ハードの故障・不慮の事故　19.7%

仮にこのうちレガシーシステムに起因したものは1)2)3)5) とすると合計 79.6%で、
最大4.96兆円 x 79.6% = 約4兆円/年にのぼると推定されます。

また、日本情報システム・ユーザ協会「企業IT動向調査報告2016」によると、企業が保有する最も大きなシステム≒基幹系システムが、21年以上前から稼働している企業の割合は20%、11年〜20年稼働している企業の割合は40%になります。

仮にこの状態のまま10年後の2025年を迎えると、21年以上稼働している企業の割合は60%になります。

これらを踏まえ、レガシーシステムに起因するトラブルリスクも3倍になると推定すると、レガシーシステムによる経済損失は最大で約12兆円/年にのぼると推定されています。

DXの対応策の検討

DX推進システムガイドラインはDXを推進するための新たなデジタル技術の活用とレガシーシステム刷新に関する指針として作られました。具体的な内容は以下の２点です。

1. DXを実現すべくITシステムを構築していく上でのアプローチや必要なアクション
2. 失敗に陥らないために失敗の典型パターン

DX推進システムガイドラインの策定

失敗ケース

1. 戦略なき技術起点のPoCは疲弊と失敗のもと
2. 経営者が明確なビジョンがないのに、部下に丸投げして考えさせている（「AIを使って何かやれ！」）
3. レガシーで保守費用が上がると言われて、ビジネスの観点で困っている事が何か、あるべき姿が何かを考えずに刷新に踏み切る
4. システム刷新には経営者のコミットが必要であり、情報システム部門にのみ任せることは失敗のもと
5. 仮説を立てずに実行すること、失敗を恐れて何もしないこと
6. 事業部門がオーナーシップを持たず、情報システム部門まかせとなり、できたものが事業部門の満足できるものとならない
7. ベンダー企業が情報システム部門としか話ができず、事業部門と話ができない
8. これまで付き合いのあるベンダー企業からの提案を鵜呑みにしてしまう
9. 経営者がリスクを懸念して、大手ベンダー企業の提案であれば問題ないとの判断に傾いてしまい、CIO自身もそのような報告をする
10. 要件定義を請負契約にすると、ベンダー企業に丸投げとなってしまう（ベンダー企業も要件定義を請負契約で受けることは慎み、準委任契約とすべき）
11. 現行システムの仕様が不明確であるにもかかわらず、現行機能保証という要望を提示する
12. 刷新後のシステムは継続してスピーディーに機能追加できるものにするとの明確な目的設定をせずに、レガシー刷新自体が自己目的化すると、DXに繋がらないシステムが出来上がってしまう（再レガシー化）

情報資産の仕分け

1. 頻繁に変更が発生し、ビジネス・モデルの変化に活用すべき機能は、クラウド上で再構築
2. 変更されたり、新たに必要な機能は、クラウドへ追加
3. 肥大化したシステムの中に不要な機能があれば、廃棄
4. 今後、更新があまり発生しないと見込まれる機能は、その範囲を明らかにして、塩漬け

見える化指標、診断スキームの構築

DX推進が進んでいない理由として、自社の情報資産を正確に把握できていない為、どこに課題があり、どのように構築していけばいいか判断がつかないことが挙げられます。

まず、取り組む最初としてはITシステムの現状を見える化する。

（健康診断に例えれば、尿検査、血液検査、人間ドック、精密検査のうち尿検査、血液検査までのイメージ）

DX実現に向けたITシステム構築におけるコスト・リスク低減のための対応策

ITシステムの刷新には莫大なコストと時間がかかり、リスクも伴うものです。また、刷新後のシステムが再レガシー化してしまう恐れもあります。こうしたコストやリスクを抑制しつつ、ITシステムの刷新を実現するためのポイントや対応策は以下の4点です。

1. 刷新後のシステムが実現すべきゴールイメージの共有
2. 廃棄することの重要性
3. 刷新におけるマイクロサービス等の活用
4. 協調領域における共通プラットフォームの構築

先行事例として情報資産の現状分析をした結果、半分以上が利用されていないシステムと判断されたケースもあったようです。

DX人材の育成・確保

デジタル技術の進展の中で、DXを実行することのできる人材の育成と確保は各社にとって最重要事項である。ユーザ企業・ベンダー企業それぞれにおいて求められる人材スキルは以下になります。

ユーザ企業において求められる人材

1. CDO（Chif Digital Officer)：システム刷新をビジネス変革に繋げて経営改革を牽引できるトップ人材
2. デジタルアーキテクト（仮称）：業務内容にも精通しつつITで何ができるかを理解し、経営改革をITシステムに落とし込んで実現できる人材
3. 各事業部門においてビジネス変革で求める要件を明確にできる人材
4. ビジネス変革で求められる要件をもとに設計、開発できる人材
5. AIの活用等ができる人材、データサイエンティスト

ベンダー企業において求められる人材

1. 受託開発への過度な依存から脱却し、自社の技術を活かして、アプリケーション提供型のビジネスの成長戦略を描き、実現できる人材
2. 求められる要件の実現性を見極めた上で、新たな技術・手法を使った実装に落とし込める人材
3. ユーザ起点でデザイン思考を活用し、UX（ユーザエクスペリエンス）を設計し、要求としてまとめ上げる人材
4. スピーディーに変化する最新のデジタル技術を詳しく理解し、業務内容にも精通するITエンジニア