DEVELOPER’s BLOG

技術ブログ

貴社のDXは、もうお済みでしょうか..?

2020.07.22 小林 佑輝
コラム
貴社のDXは、もうお済みでしょうか..?

貴社のDX(デジタルトランスフォーメーション)は、もうお済みでしょうか..?

経産省が警鐘をならす「2025年の崖」。

既にご存知の方も多いと思います。

昨今、企業活動とITが密接に関連する状況において、当該レポートは全ての企業様にとって他人事ではない内容であるように思えました。

あらためて経産省の発表内容を振り返るとともに、本記事が企業様の次の意思決定・行動のリマインドとなれば幸いでございます。


経済産業省からの警鐘

2018年9月に経済産業省から「DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」というレポートが発表されています。

※「経済産業省Webサイト」へのリンクは こちら

このレポートを読むと、大きく2つの内容が語られていると解釈しました。

1)レガシーシステムに起因し、各企業のシステム障害リスクが増加。
  2025年以降、国内のシステム障害による経済損失が 最大12兆円/年の発生する可能性がある。

2)レガシーシステムは、システム障害リスクの要因となるだけではなく、各企業の将来の成長・競争力強化のためのDX
 (デジタルトランスフォーメーション)を実現する妨げにもなっている。


着目すべきは、クラウドやAI、IoTといったデジタル技術の積極採用だけではなく、既存のシステムがレガシー化していないか?また、レガシー化している場合はそれらの対処は大丈夫か?といった、足元に対して警鐘を鳴らしているという点だと感じました。既存システムがレガシー化している場合、既存の環境を維持するだけでも企業にとって大きな損失を招く可能性があるということを示唆しています。

貴社のシステムは、大丈夫でしょうか??


レガシーシステムとは..?

レガシーシステムという言葉の定義を整理すると、
「技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化等の問題があり、その結果として経営・事業戦略上の足かせ、高コスト構造の原因となっているシステム」のことと記されています。

・技術の老朽化 とは..
システムの仕様や使用している技術を把握している人材がリタイアし、メンテナンスのスキルを持つ人材の枯渇が危惧される状態

・システムの肥大化・複雑化 とは..
過剰なカスタマイズが積み重なることで、システム全体の規模が膨らんだり内部のロジックが複雑になっているといった状態

・ブラックボックス化 とは..
技術の老朽化とシステムの肥大化・複雑化が重なり、システムの全貌と機能の意義が分からなくなっている状態


今回の警鐘をうけとめ、まずは企業様内で上記のような事象が発生していないかどうか、発生している場合それはどの程度の規模なのか、早期に確認を行うことが必要と感じます。

ある日突然、いつも使用しているシステムがダウンしたら..、そのダウンしたシステムがレガシーシステムであったら..
復旧にどれほどの時間と労力が必要となるのか..(そもそも、復旧が可能なのか..)復旧までの期間事業に与える業務のインパクトと損失はどの程度になるのか..この記事を読まれた企業様では、このような状況にないことを祈るばかりです。


DX(デジタルトランスフォーメーション)とは..?

DX(デジタルトランスフォーメーション)という言葉の定義についても整理してみたいと思います。

・DXという言葉の発祥
2004年にスウェーデンのウメオ大学のエリック・ストルターマン教授が提唱されたと言われています。
DXとは「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」という概念を示すようです。

概念であるためか、この段階で具体的なアクションへ落とし込むのはかなり難しいように感じます。

・経産省による定義
経産省は、DXという概念を日本向けにもう少し具体化しており、「 DX 推進ガイドライン 」 の中で以下のように定義付けています。

「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」

※経産省の「DX 推進ガイドライン」は こちら

どのような状態になることをDXというのか、それが定義されたことで言葉の意味が具体的になったと感じます。 新時代(新しいルール)へアジャストしていくため、更には新時代でも競争上の優位性を確立していくために、既存の破壊と再構築を視野に入れた変化の取り組みこそがDXだと。そして、レガシーシステムに対する対策だけではなく、このDXを積極的に進めていくべきであると、記載されています。


レガシーシステムの問題点を解消し、企業でDXを推進するための方法とは..?

レガシーシステムの問題とDXに関して、重要であることのイメージをなんとなく持っていただけたかと思います。
一方で、DXの実現は非常に困難であると感じられた企業様も少なくないのではないでしょうか?

経産省のレポートでは、どのようにDXを進めていけばよいか、ガイドラインを示しています。(後述の図1、2)
しかし、各社状況やスタートラインが異なっているため、現実的には安易ではない取り組みになるかと思います。

ただ、困難を困難のままにしてしまうと、それ以上前に進みません。
困難な事をどうやったら実現できるか、問題を解ける状態に分解しながら進めていくことが重要であると考えます。

そのファーストステップは、やはり「現状の可視化と将来に起こり得る事象への定量的なシミュレーション」ではないかと考えます。
今が把握できて、将来の危惧or飛躍を定量的に語れるのであれば、経営陣/現場ともにそれを回避・改善or推進・支援する方向に動こうとなるのではないでしょうか?また、そのような協力を促す説得力のある材料になるのではないでしょうか? (進行方向に崖があるにもかかわらず、昨日までと同じルートと歩き方にしがみついく人がいたのであれば、それは違った意味で危機ですが..)

現在地がわかり、目的地が決まる、その差を埋める行動をNext Actionとする。Next Actionも重要度や影響度から優先度をしっかりと持ち、濃淡を付けて計画的に進めていく..そんな動き出しが必要と考えます。


図1
DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~
出典:「DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」(経済産業省)


図2
DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~
出典:「DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」(経済産業省)


AUCがお手伝いできること

(最後は露骨な宣伝となってしまいますが..)

通常業務と平行してレガシーシステムの対応やDXの推進を行っていくのは至難の業である思います。
また、専任の採用もすぐには難しい対応であると思います。

現状の可視化や今後の展望の検討支援、具体的なシステム開発やインフラ開発とその保守運用。機械学習の企画〜PoC〜システム実装など..弊社がお手伝いできる色々なシチュエーションがあると考えております。

DXがまだお済みでなく、これから本格的に進めていこうとしている企業様、弊社サービス概要ページのリンクを添えておきますので、興味をもっていただけましたら、お気軽にお問合せください。

※「ITコンサルティングサービス」ページは こちら

※「新規Webサービスの構築」ページは こちら

※「クラウド構築・運用保守」ページは こちら

※「お問い合わせ」ページは こちら

関連記事

MacBook Proにログインできない?復旧キーの探し方とロックの解除手順

はじめに 復旧キーとは? 「復旧キーがない場合」を試す まとめ はじめに 先日、私用のMacBook Proにログインできなくなる問題が発生しました。 経緯としては、2台あるMacBook Pro AとMacBook Pro Bを取り違えてしまい、MacBook Pro AにMacBook Pro Bのパスワードを入力し続け、パスワード入力の試行可能回数を超過してMacBook Pro Aにロックがかかりました。 Macのログインパスワー

記事詳細
MacBook Proにログインできない?復旧キーの探し方とロックの解除手順
コラム
AWSマルチアカウント環境でのOS・パッチ・証明書の統合管理

はじめに SSM統合コンソールによる一元管理 OSなど構成情報の可視化 Patch Managerによるパッチ運用の標準化 証明書有効期限の集中監視と自動通知 導入効果と業務改善イメージ 導入時の設計上の留意点 継続的改善を支える「運用の仕組み化」 1.はじめに クラウド活用が拡大し、AWS環境が複数アカウントで利用されたり、複数システムにまたがって利用されることは、システム運用における構成の一貫性を維持することの難易度を

記事詳細
AWSマルチアカウント環境でのOS・パッチ・証明書の統合管理
AWS SRE コラム
AWSの可用性設計を考える:AZ・リージョン・事業継続計画(BCP)のバランス

はじめに 可用性設計の基礎:リージョンとAZの仕組みを理解する 止まらない設計を妨げる単一点障害:単一AZ構成の限界 マルチAZ構成:同一リージョン内での止まらない仕組み マルチリージョン構成:事業継続(BCP)のための冗長化 まとめ:設計段階で「どこまで止めないか」を決めよう 1. はじめに AWSは、数クリックで仮想サーバー(EC2)を立ち上げられるなど、手軽にサービスを構築できるクラウドです。システム企画や開発の初期段階では

記事詳細
AWSの可用性設計を考える:AZ・リージョン・事業継続計画(BCP)のバランス
AWS コラム
[AWS ECS + Rails] スティッキーセッションとCSRFトークンエラー対策

はじめに スティッキーセッション(Sticky Session)とは Railsのセッション管理とCSRFトークン スティッキーセッションを無効化し、redisにセッションを保持させる場合 負荷分散とスティッキーセッションの設定 × セッションの保存場所 1. はじめに AWS ECS上でRails on Railsで開発したWebアプリケーション(以下Railsアプリ)を運用する際、ユーザーごとのセッション管理は重要なポイントです。 負荷分散を行いた

記事詳細
[AWS ECS + Rails] スティッキーセッションとCSRFトークンエラー対策
AWS コラム

お問い合わせはこちらから