【まとめてみた】D X デジタルトランスフォーメーション レポート ～IT システム「2025 年の崖」の克服と DX の本格的な展開〜

経済産業省における研究会で「デジタルトランスフォーメーションに向けた研究会」というのがあるそこで以下のレポートが公開された、2年前と若干古いがそれを今更よみまとめてみる。正直長いが内容としてはかなりいいあとで超訳◯◯みたいな資料でまとめてみたい。 ↓まとめて見た↓

docs.google.com

D X デジタルトランスフォーメーション レポート ～IT システム「2025 年の崖」の克服と DX の本格的な展開〜 https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_03.pdf

ちなみに【】は読んでいる現在での私の率直な感想・疑問である。読んでいて解決された部分もあるが疑問に残っている部分もあるので今後対応したい。

1.検討背景の背景とスコープ

デジタル技術による新たなるビジネスモデルが展開され、既存プレイヤーがディスラプトされる現状がある。 既存プレイヤー達もDXを進めようとPOC(価値検証)はするがデジタル変革につながっていない。 その課題として経営戦略の方向性や既存システムの老朽化があげられる。 特に既存システムに関しては以下のような問題がある

  • 老朽化によるブラックボックス化によりデータ活用の限定的になっている
  • 既存システム刷新による現場からの抵抗
  • 既存システム運用、保守に資金が流れすぎ投資できない

これらを放置していた場合、既存システムはますます運用・保守コストが高騰し技術負債が増大、人材は枯渇しセキュリティ上のリスクも高まる。 本書ではDXを実現していく上でのITシステムの現場・課題を整理し実行する上での経営戦略・体制・企業内の仕組みの構築について議論した。

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

2.1DXを実行する上での経営戦略における現状と課題

DX実行には新たなデジタル技術を活用してどのようにビジネスを変革していくかの経営戦略そのものが不可欠である 戦略がないと「AIで何かやれ」と経営者が言っておしまいになるパターンで終わることが多い。

2.2既存システムの現状と課題

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

DX実行するには環境の激変に対して、ITシステムが柔軟かつスピーディーになる必要がある【柔軟かつスピーディーとは？→のちに出てるマイクロサービスのことか。。。】 約８割の企業が「レガシーシステム」を抱えていて、７割が「レガシーシステム」がデジタル化の足かせになっている【it投資が少ないからか？】 レガシーが足かせになる理由は「ドキュメントが整備されていない」「データ連携が困難」「影響が多岐に渡るため試験に時間を要する」など技術面の老朽化、システムの肥大化・複雑化ブラックボックス化が問題 DXのためには既存システムがデータを最大限活用できるように見直ししていくことが重要。

2.2.2 既存システムの問題点

レガシー問題の本質は、ブラックボックス化、自分の手で修復できない、これは古いテクノロジーを利用している技術面だけでなくマネジメントの問題でもある、マネジメントが行き届かずこまめなアップデートを行えていない 日本では初期のITシステムは作業の自動化が目的、ベンダーが一括受注するためウォーターフォール型となった。【一括受注→要件定義などもまるなげだから？】 米国も当初は同じだったが、1980年大の全米航空管制システムの再開発時に莫大な損失を生み、失敗を学ぶ、根本的な見直しがおこった。 逆に日本では大した問題が起こらず、その体制が温存、ベンダーと企業の契約の曖昧さも残り見直しに至らないままとなった。 当時要件定義していた世代もいなくなり、その後のシステム変更もないため要件定義自体ができなくなっている、動いているならそのままでと放置しされている

2.2.3 既存システムの問題点の背景

日本は世界に先駆けてシステム化した、この時に事業部ごとに最適化したため、それが今の情報システムが全社的なデータを活用することを阻んでいる。【80年代から90年代はit投資が多かった？】 諸外国は社内エンジニアが小規模にメンテナンスを繰り返す細やかなアップデートが可能、そして、ノウハウが残る。 一方日本は受託開発が主流、ユーザー企業にノウハウが残らない、ウォータフォールで開発が行われることが多く要求仕様を整理・調達し契約を結びとなり非常に時間がかかる。 また、終身雇用が前提の日本企業は企業内にノウハウを形式知化するメリットが少ない上に、2007年問題（団塊の世代の大量退職）などにより既にノウハウを持っていた人材がいなくなり、ブラックスボックス化している可能性がある。 さらにスクラッチ開発が好きでカスタマイズが好きであり、そのために独自メンテナンスの必要がありお金が高くなっていく、システム改修が複雑になる一因でもあった。

2.2.4 既存システムの問題の難解さ

レガシー問題は潜在的である、ハードやソフトウェアの維持限界がこない限り問題の重要性が顕在化しないため、長期かつ手戻りの可能性もあるシステム刷新にインセンティブが生じない またレガシー問題はベンダーも発見できない、ユーザー企業の自覚がない事が多く改修時に問題が発覚して赤字にもなりやすい、訴訟にもなりやすいため旨味がないことが多いまた複数ベンダーが入っているためシステム全体を俯瞰できない モダナイゼーションは自社の経営陣の理解を得にくい、さらに費用はかかるが以前のものより使い勝手が悪くなることがある

2.2.5 既存システムの運用・保守に割かれてしまう資金・人材

日本のIT投資の80%は現行のビジネスシステムの保守運用、米国のように多くの攻めのシステム投資をしているわけではない 長期的な保守運用は費用を高騰化する、つまり技術負債となっている【保守できる人が少なくなり単価が上がる？】 短期的なシステム開発の足かせ、短期的なシステム開発開発とはリリース時点では最善の仕様技術の採用、でも期限やコスト制約の中で取り込むべき機能が取り込めていない、リリース当時は最新だがその後のアップデートを取り込めていない

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

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

DXの成功のタネは経営層の強いコミット、全体最適や、標準化を求めるため各部門にも変革を強制する必要がある、トップダウンの強い指令が必要 米国では取締役会の評価が標準かされており、全米取締役協会のガイドラインを守る必要がある、その中にitシステム・サイバーセキュリティとのガイドラインも含まれておりそれを理解しCIOに丸投げせず実行できるCEOでないと価値が問われる、将来のビジョンを示すモチベーションになる日本のCEOは果たしてコミットできているのか？

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

CIO米国は開発の主導はCIO失敗も含め全てCIOのせい、責任転嫁できないのでベンダーを客観的に選ぶ 日本のCIOはベンダー企業のせいにする、要求仕様や指示に抜け漏れがあっても、ベンダーの選び方も付き合いとかになりがち CI Oの意識が低い

2.3.3 事業部門と情報システム部門役割分担

事業部門と情シス部門の役割分担も重要、本来はシステム開発はビジネスがうまく行ったかどうかで評価されるべきそのためには、事業部門に関してはプロジェクトのオーナーシップを持って仕様決定、受け入れテストを実施していくことが重要 事業部門と情シス部門でのコミュニケーションがない場合も多い、結果競争力向上につながらない

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

IT人材の不足が深刻、以下のような2種類の人材が必要

  • 業務システムと周辺システムの関係を明確化して将来のあるべきシステムのビジョンを描く
  • ビジネス上どんな脅威に晒されているかを分析しそれに対して新しいデジタル技術で何ができるかを企画できる人材

老朽化したシステムの人材の確保、若手がこうした仕事につくと辞めがちその確保は問題【寧ろ老朽化したシステムの刷新に触れるべきでは結局新たなIT人材が取れなくなるかもしれない失うだけ→あとでそう言及されてる】 IT人材の7割以上がベンダーに所属する日本、IT人材の確保と教育が必要

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

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

要件定義から請負契約する日本、そもそも何を開発するか自体決めてもらっているようなもの、これが常態化するとアジャイルのようなユーザー企業もコミットメントを求められる開発方法も難しい 要件の詳細はベンダーと一緒に作るとしても要件の確定はユーザー企業がすべき

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

ユーザー企業はベンダー企業に業務委託するケースがほとんどで、請負契約や準委任契約が適用される。契約の前提として、ユーザー・ベンダー関の責任、役割分担を明確化する必要がある。 だが以下の問題から、明確化されていないことが多い

  • 現行システムの肥大、複雑性を把握せず、仕様が不明確なまま、現行機能保証という条件で発注
  • 情シス部門と事業部門、経営企画部門の連携がなく要件が不明確

結果として、テスト工程で手戻りが発生しコストが無駄に、不明確さが災いし互いに責任転嫁し、紛争、訴訟へ ベンダー企業がユーザー企業のことを理解しているという前提がこの問題をひきおこしている。【事実理解しているベンダーも多いと思うが、その前提に立っては行けないということだと思う】

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

DX実行の上でアジャイルのような開発形態が求められることがあるが契約形態が整っていない

  • 請負契約は完成物責任があり仕様が不明確なまま開発が難しい
  • 準委任契約は完成物責任がなくユーザー企業が不安

またユーザー企業のアジャイル開発の理解が低い場合、全く要求、仕様をまとめずプロダクトのオーナーシップの責任まで放棄してしまうことになりかねない

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

2.5.1 情報サービス産業の概観

ベンダー企業は実質ユーザー企業組織の一部を構成。

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

2.5.2グローバル・クラウドの成長

情報システム産業の成長性はわずかだが、パブリッククラウドのグローバルプレイヤーは数十%〜100%の成長を継続、周辺のSI費も合わせると、情報サービス産業の5%にあたる経済規模

メガクラウドはITシステム構築に必要なほとんどの機能を提供し、個別開発を圧縮。IT投資効率を高める

  • システム構築に必要な機能を個別調達していた時よりもコストは削減され機能適用は迅速化システムの競争力は高まる
  • 基盤ソフトウェアはIaas.アプリケーションはSAPなどに標準化、投資効率は高まる

【言いたいことわかるがちょっとピンとこない】

クラウド型データセンターの普及はユーザー企業におけるサーバー設置や調整作業が不要となり従来のシステム開発を変える

2.5.3ベンダー企業における人員の逼迫、スキルシフトの必要性

以下の構造的な問題からDX人材の確保は難しい

  • 雇用不足は常態化し、かつ拡大化している
  • IoT,BD,AIなどの新技術の経験を積む実務の場がない

またスキルシフトも必要である、これまでの業務上の重要なデータを蓄積・管理していたシステム（SoR = System of Records）だけでなく顧客のニーズ、行動パターンに柔軟に対応するシステム（SoE = Systems of Engagement）の開発まで求められる そのためのスキルセットは以下であろう

  • 要件変更を前提としたアジャイル開発の活用
  • システムを機能ごとに分割し短いサイクルでリリース
  • API/WEB APIベースのモジュール化されたサービスの利用により、コストとリスクの圧縮【これはSAASとかの利用も前提かな？】

デジタル技術を使いユーザーに価値を提供する人材を生み出し、安価なIT人材という現状から脱却すべきである

2.5.4 ビジネスモデルの転換の必要性

ベンダー企業のこれまでの受託事業のモデルは、大型開発の一巡、企業統合による情報資産の共有、クラウド化により規模は縮小傾向にある。 この意味でユーザー企業同様、ベンダー企業も単独で取り組めない課題に直面している、両者の新たな関係性を模索する必要がある。ベンダー企業は新しいビジネスを顧客と一緒に考えるパートナーへの転換などが求められている。 しかし既存のシステム保守運用に投資が向いてしまい、新たな方向性にシフトできていない現状では、新たなデジタル技術を駆使する人材が流出し早晩競争力を失う。

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

2.6.1 既存システムの残存リスク

既存システムの運用、メンテナンスは年々コストが増大、全貌を知る社員が高齢化、退職により更新リスクも高まる。 ハードウェア、ソフトウェア共にメーカーのビジネス状況悪化により製品からの撤退が起こる可能性もある。ユーザー企業からすれば外部圧力によりシステムの再構築、コスト上昇、サービスレベル低下に見込まれる可能性がある。

2.6.2 既存ITシステムの崖(2025年の崖)ー12兆円/年の損失ー

複雑化・老朽化・ブラックボックス化した既存システムが残存した場合、経済損失は2025年以降、最大12兆円/年　現在の3倍※となる このままであれば ユーザー企業はデジタル競争の敗者となる可能性があり、また業務基盤そのものの維持・継承が困難となる。 ベンダー企業は既存システムの運用・保守にリソースを割かざるを得ず成長領域手が出せない、さらに現在の人月商売から脱却できないと想定される。

※の根拠

EMCジャパン株式会社の調査をもとにした独立行政法人情報処理推進機構（2016年2月公開、2018年3月更新）がまとめによると 2014年1年間の損失額は国内全体で約4.96兆円。 日系BP社「日系コンピュータ2017.8.3」によると、2010年代のシステムダウンの原因別割合として、 1.セキュリティ29.1% 2.ソフトの不具合　23.1% 3.性能・容量不足　7.7% 4.人的ミス18.8% 5.ハードの故障・不慮の事故19.7% レガシーシステムに起因している可能性があるのは4以外、合計79.6%これらを踏まえて現段階での損失は4.96兆円×79.6%=約4兆円/年 また、日本情報システム・ユーザー協会「企業IT動向調査報告書2016」によると基幹システムが何年前から稼働しているかの調査によると ・21年以上前から稼働　20% ・11年から20年稼働　40% このまま10年後（2025年）を向かえると21年以上稼働しているシステムは60%以上になる、すると現状の3倍程度と想定でき、12兆円／年となる【この算出方法でいいのか？】

3. 対応策の検討

3.1 「DXシステムガイドライン」の策定

ガイドラインを策定する

必要性

DX実行にあたってデータ利活用がきもだか、既存システムが部署最適化されすぎサイロ化横断的なデータ活用ができない 、AI・IoT・ビッグデータなど先端技術を入れても効果は限定的 既存システムの見直しが不可欠であるが、経営層・事業部門・情報システム部門のあるべき役割について十分な理解が浸透してない。 認識を合わせる、共通言語としてガイドラインを提示する。

対応策

ガイドラインの目的

  • 経営者が抑えることを明確化
  • 取締役会メンバーや株主がDXの取り組みをチェクする上で活用できる物にする

DXの経営戦略における位置づけと技術活用、レガシーシステム刷新の適切な体制・仕組み、実行プロセスを盛り込む

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

ユーザー企業が自社のITシステムの内容を正確に把握するための「見える化」指標と診断スキームを構築する

必要性

コストや時間の問題以前に、自社の情報資産が正確に把握できてないがゆえに、どこに課題があり、どう構築していけばいいか分からず、既存システムの刷新できていない。 既存システムを放置した場合、運用、保守のコストが上昇し技術負債化、DX化もできないという問題を経営層が適切に認識できているとは言えない。 経営者が課題を認識し、既存システムを刷新を決断できるためにも非常に重要である。 また既にベンダー企業、コンサル企業でこうした見える化はされているが指標が統一されておらずユーザー企業が比較できないと、他社調査をもとにした依頼を受けられないという問題がある。さらに各社個別の基準はユーザー企業から見れば各ベンダーが有利になるようにしているのではないかという不安感もある。 その解決のために統一的な評価指標が必要である

対応策

1.評価指標の策定 1-1指標は以下の3つ

  • 技術負債の対象と度合い、IT成熟度やデータの利活用状況などITシステムの現状
  • DX実現のためのITシステム構築における体制・仕組みの状況
  • DX実現のためのITシステム構築における実行プロセスの状況

1-2簡易な形で統一的に情報資産を見える化する指標とする 1-3経営トップが経営課題として認識できる指標とする 1-4指標がアクションとつながるよう、項目ごとに数段階のレベルを設定到達度合いに応じてレベルづけを行う

2.診断スキームの構築 中立的な組織として診断を行う。診断ノウハウなどはスキルセットとしてまとめ担い手を増やす。 人材はベンダー企業、ユーザー企業の情報システム部門からだけでなくユーザー企業のビジネスサイドも入れる。 DXがどこまで進んでいるかを把握することに活用する

3.診断によるインセンティブ

3-1高評価の企業は優良企業として攻めのIT経営銘柄と連動させる 3-2他社や業種内での自社の位置づけを経営者に示すツールとして利用できるようにする

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

ITシステム刷新のリスクやコストを抑えつつ実現するためのポイントや対応策を述べる

3.3.1 刷新後のシステムが実現すべきゴールイメージの共有

レガシー刷新だけが目的となり、新システムが再レガシーとならないように、刷新後の目標設定を経営者、事業部門、情報システム部門など、すべてのステークホルダーが認識を共有する。 その一助として「DX参照アーキテクチャ」を今後策定する

3.3.2廃棄することの重要性

システム刷新の効果的な方法は不要な機能を廃棄し、規模と複雑度を軽減すること 事業ポートフォリオの柔軟な見直しが必要とされるように、ITシステムについても既存の物はサンクコストとして新しい分野に投入することが不可欠 見える化診断から廃棄するものを仕分ける必要がある、現場の抵抗も想定されるが経営トップの強固なリーダーシップが求められる。 先行事例に置いては半分のシステムが業務上止めても問題のないシステムと判断しとめたものもある。【その事例めっちゃ知りたい】

3.3.3刷新におけるマイクロサービスなどの活用

既存システムの刷新は大規模かつ長期のプロジェクトになる可能性がある。 刷新後のシステムはビジネス・モデルの変化に合わせて、細かく更新することが求められる。それらはシステムがモジュール化され機能に分割され短いサイクルでリリースすることが求められる。 ビジネス上細かくアップデートが求められる機能については、マイクロサービス化も検討に挙げられる。まだ先行事例も少ないので実証的な検討を行う形でもいいかもしれない

3.3.4協調領域におけるプラットフォームの構築

企業の競争領域に関わらない分野においては協調領域とみなし業界毎や課題毎に共通のプラットフォームを構築することで、早期、安価なシステム開発が望める。（パブリッククラウドはある意味課題毎の共通プラットフォーム） 実施の仕方は協調領域の見極め、業界団体などの旗振り役の存在、共通プラットフォームの利用インセンティブ、諸注意事項など様々にあるが、保険・地銀など先行事例もある。【これは壮大だけど現実感があんまりない…そもそもクラウド移行だけで四苦八苦している現状があるのに…】

3.4ユーザー企業・ベンダー企業の目指すべき姿と双方の関係

ユーザー企業・ベンダー企業のそれぞれの目指すべき姿を明確にし、双方の新たな関係を構築すべく、契約ガイドラインを含め環境を整備していく

3.4.1 DXを通じてユーザー企業が目指すべき姿

ユーザー企業は既存のシステムを活用し本格的なDXが可能になる。既存システムの保守運用に割いていたものを新たなデジタル技術の活用により迅速なビジネス・モデル変革に充当できるようにする クラウド、モバイル、AIなどのデジタル技術を素早く取り入れ素早く新たな製品・サービス、ビジネス・モデルを国際市場に展開していき、国際市場での競争力を高めることが可能になる。 ユーザー企業全てはデジタル技術を駆使する、デジタル企業となっていく。【電気やガスを使わない企業がいないようにコンピュートパワーを使わない企業はいないということか…】

3.4.2 ベンダー企業が目指すべき姿

既存システムの維持管理に費やされていた人材・資金が解放されて最新のデジタル技術活用に重きを置かれるようになる。 デジタル技術の分野で競争力を維持し続けることが重要。ウォーターフォール、アジャイルを使い分けながらこれまでの受託を業務から脱却し、最先端技術活用の新規市場を開拓しアプリケーション提供型のビジネスモデルに転換する必要がある。 ユーザー企業と協働してプロダクトを開発し知財・資産をベンダー企業が保有して他の企業にも販売していくといったことも可能になるかもしれない。ベンダー企業が進む先は様々になるはずである。

3.4.3 ユーザー企業とベンダー企業の新たな関係

ユーザー企業はクラウド、モバイル、AIなどのデジタル技術を活かすべく、自社リソースの充実、他社とのパートナーシップを強化することが必要。 ベンダー企業はデジタル技術にキャッチアップし、ユーザー企業への価値提供の重要性が今まで以上に重要。ユーザー企業はその価値を正当に評価する必要がある。【人月評価をやめろということか？】 ユーザー企業がビジネス価値向上となればプロフィットをシェアするなども期待される。

3.4.4 ユーザー企業とベンダー企業間における契約

契約のあり方を見直す必要がある

1.ウォーターフォール型の開発に関する契約

現状のモデル契約は新規開発を念頭に置いている。現在は既存の刷新を求められるため、既存システム資産の分析、現行業務内容の分析、その分析に要する期間の確保、リスク認識などを契約上なんらかの形で明確化することにより再構築案件も範囲に含めるようにする。また、要件定義・設計開発を分離しユーザー企業の丸投げを防ぐ。

2.ユーザー企業におけるアジャイル開発に関する契約

現場で今後想定されるアジャイル開発は3つのパターンがある

パターンA 内製モデル 全て自社エンジニアで賄うもの…人材確保が困難

パターンB 基本/個別契約モデル プロジェクト全体に共通する事項に基づき基本契約を締結。その後小さな単位ごとに個別契約（請負/準委任）を順次締結する。 契約が複雑化し責任問題が起こりやすい

パターンC ジョイント・ベンチャーモデル ユーザー企業とベンダー企業で共同で組合を作りらジョイント・ベンチャー化する。開発から得られた収益はユーザー企業とベンダー企業に分配される。 事例が少なく、収益分配や責任関係などの契約手法が確立されていない

現状はパターンBが多いはず アジャイル開発に関しての理解が少ないとトラブルが起こりがち、仕様が明確でない場合も多く請負契約よりも準委任契約が相性が良いはずだが以下の見直しが必要

またユーザー企業とベンダー企業がパートナーとしての関係に立てるようにプロフィットシェアのモデルを構築し、ベンダー企業のインセンティブが働くようにする

パターンAについて ベンダー企業のサポートが必要になる場合が多く出向を考える必要もあり

技術研究組合の活用に関して（パターンCの異種型？） ユーザー企業とベンダー企業が協同して開発する場合や、レガシーシステムを刷新する場合に関しては技術研究組合も検討する。 主務大臣の認可を得られれば設立でき、税制上優遇措置があり、組合員は有限責任となる。将来事業化を念頭におきながらも、現時点で事業化はできない、共同で取り組む研究課題が明確になっている場合などは各種要件を満たせば認可を受けられる。 【これらの契約形態をまとめた表がPDFにあり、すごく良い】

3.4.5 トラブル後の対応　ADRの活用促進

裁判外紛争解決でトラブル解決時間の短縮と非公開性を確保することが期待される。 ADRについても契約に盛り込む検討が必要。

3.5 DX人材の育成・確保

スキルを整理し、必要な対策を講じる必要がある

対応策

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

  • CDO:システム刷新をビジネス変革に繋げて経営改革を牽引できる人材
  • デジタルアーキテクト:業務内容に精通しつつITで何ができるかを理解し、経営改革をITシステムに落とせる人
  • 各事業部門でビジネス改革で求める要件を明確にできる人
  • ビジネス変革で求められる要件もとに設計、開発できる人
  • AIの活用などができる人材データサイエンティスト

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

  • 受託開発への過度な依存から脱却、アプリケーション提供型のビジネス成長戦略を描き実現できる人
  • 求められる要件の実現性を見極め、新たな技術を使った実装に落とし込める人
  • UXを設計し要求をまとめられる人
  • デジタル技術をキャッチアップし業務内容にも精通することITエンジニア

3.人材確保・育成に向けた対応策

  • アジャイル開発そのものが、ユーザー企業には開発手法を、ベンダー企業には業務を知ることにつながる
  • IT技術者のスキル標準や情報処理技術者試験の活用により求めらるIT人材スキルの明確化や人材育成が進められることが期待される
  • 大学を含めた産学官連携での人材育成

3.6 ITシステム刷新の見通し明確化

中長期に及ぶシステム刷新のリスク管理を含めた見通しの整理をする

必要性

システム刷新には経営層の中長期的な強いコミットが必要。他方で既存システムの放置による負債は気づかれづらく先延ばしされる可能性もある。特にベンダー企業のサービス終了や高齢のエンジニアが引退する中で先延ばしは致命傷になりかねない ユーザー産業、ベンダー産業全体が一定の時間軸を共有し、DX実現のためのシステム刷新の取り組みを進めていく必要がある

対応策

2025年までに既存システムを刷新し、新たなデジタル技術を活用して新しいビジネスモデルを創出することで2030年に実質GDPが130兆円上積みされる。これよりIT投資を呼び込む ユーザー企業は自社の経営戦略や競争環境を踏まえつつビジネス・モデルの変革を一刻も早く実現すべきところはDXを実行する 他方、既存システムの刷新については見える化指標による診断やDX推進ガイダンスを踏まえつつ自社のデータ資産の評価・仕分けを行なっていき、DX実現シナリオを作る。 【DX実現シナリオのロードマップが参考になる、ちょっとゴミゴミしすぎだけど】 特に社会インフラ関係の業種での老朽化・ブラックボックス化したシステムは災害・サイバーセキュリティ等のリスクが高まり社会的な影響が大きいため、政策的な措置も必要である。 ベンダー企業はシステム刷新のサポートをしつつ最新技術に投資をシフトさせ競争力を高めていく必要がある 

4 今後の検討の方向性

３で挙げた内容の進め方などが書かれている

5 終わりに

2018年のグローバルのIT支出は412兆円、2017年の6.2%成長。しかし日本では2018年〜2022年の成長率は1.1%と予測される。 政府が推進する Connected Industriesの実現のためにもDXは不可欠。DXの重要性は認識されつつも取組は始まったばかり。 だからこそこうした研究会を開いてきた