.../articles/

DX(デジタルトランスフォーメーション)の全体像をざっくり解説

もはやバズワードと化したDXという言葉ですが、実際何を意味しているのか? どのようなことをしたらいいのか? といったことを相談されるようになってきたので、DXをイメージするための全体像をざっくり解説します。

コロナの影響もありDXという言葉はバズワードのように至る所で聞くようになりました。
同時に、言葉からどのようなことを意味しているのかが分からないと言った声をよく聞くようにもなりました。

2020年も残り少しとなって、大手企業だけでなく中小企業でもDXをという話が出るようになりましたが、そもそもそれが何かのか、何をすればいいのかというところから話が始まることが多いです。
今回はDXはどういうものなのか?を理解するためにDXの全体像をご説明します。
(長文のため、さくっと知りたい方はまとめだけご覧ください)

目次


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

デジタルトランスフォーメーションの説明でよく目にするのが経済産業省が発表した以下の資料があります。

あとは、広告や記事などでもDXという言葉が多く使われ、それらに「IoT」「AI」「ブロックチェーン」「アジャイル」「バイモーダル」「内製化」など多くのキーワードと共に登場するのを目にしていると思います。
しかしこれらを見ても結局よく分からないというのが本音だと思います。

分かりにくい理由としては、いろいろなキーワードが登場しすぎて何をどうするのがDXなのかという全体感が見えづらくなっているということでしょう。
DXの一部でしか無いキーワードごとにしか語られないため、まずは全体像の把握をすることが大切です。

DXの全体像は以下の様なフェーズ1、2と分かれると考えています。
フェーズ1, 2というのは今回私が勝手に当てはめただけですが、DXを実現する上でフェーズ1の状態ができてない中でフェーズ2には移れないと考えています。
各フェーズで言われていることはどういうことなのかは、以下で説明します。

フェーズ1(デジタイゼーションとデジタライゼーション)

  • レガシーシステムの刷新
  • 内製化、技術・ナレッジの蓄積
  • 組織・業務プロセスの変革

フェーズ2(エンドユーザーへの新たな価値提供)

  • 技術の利用したプロダクトやビジネスモデルにより競争上の優位性を確立

DXのフェーズ1(デジタイゼーションとデジタライゼーション)

レガシーシステムの刷新

まずレガシーシステムの刷新ということですが、レガシーシステムとはなんでしょうか?
DXの文脈では自社システムの中身が不透明であり、自分等の手で修正できない状況に陥ったシステムをレガシーシステムと呼んでいます。
レガシーシステムを使っていることの問題は、自社システムがブラックボックス化してしまい社内の人間では触れない状態と言えます。
DXレポートでも以下の様なレガシーシステムの問題が書かれています。

新しいデジタル技術を導入したとしても、データの利活用・連携が限定的であるため、その効果も限定的となってしまうといった問題が指摘されている

また、レガシーシステムが生まれてしまう原因としては、以下のような背景があります。

  • 過去に構築したシステムに関する技術を持った人材がリタイアしシステムを触れる人がいなくなってしまうこと
  • ベンダー企業への丸投げによるシステムを理解した人材が社内にいないこと
  • メンテナンスを行わず日常的に活用できている間はレガシーであることは自覚できず、ハードウェアやパッケージの維持限界を迎えた時にレガシーシステムであることに気づく

これらレガシーシステムにおける刷新とは以下の内容を挿します。

  • 今でも変更が発生している機能、または、ビジネスに活用可能な機能はクラウド上で再構築
  • 不要な機能があれば廃止

レガシーシステムの刷新をする上で重要になるのは、ただクラウド化すればいいなどという話ではなく、次の「内製化、技術・ナレッジの蓄積」の項目が重要になります。

内製化、技術・ナレッジの蓄積

DXを語る上で内製化、技術・ナレッジの蓄積はとても重要なポイントとなります。
技術・ナレッジが指すものは、プログラミングスキルやシステム開発の知見だけでなく、統計分析などが含まれます。

レガシーシステムの問題で、システムがブラックボックス化してしまうことだと上でお話ししました。
そのブラックボックス化させないという部分でも重要になるのが、内製化や技術・ナレッジの蓄積という部分です。
例えば、レガシーシステムを刷新しようとして、ベンダーに丸投げしたとして、そのシステムの知識はどこに溜まるでしょうか?
請負ったシステムベンダーには知見がたまりますが、ユーザー企業には開発ノウハウは溜まらずシステムもブラックボックスになってしまいます。
それではDXに向けてシステムを刷新した意味がありません。
自分たちで要件定義を行い、技術選定や設計に入り込んでいき、ベンダー企業の知識を自分たちのものにするという認識が必要になります。

DXを実行しつつ事業に落とし込んでいくには、仮説検証を素早く行えることと、それらを企画・設計・開発・運用と一気通貫して技術を活用することが求められます。
その際に技術・ナレッジを社内に蓄積するのは当たり前に必要となり、内製化の体制を社内で持っておくというのはDXには必要不可欠な要素となってくると考えられます。

ただし全てを内製化するというのは難しいと思いますので、ベンダーのリソースは活用しつつ、今までのウォーターフォールでの請負契約を見直し、アジャイル開発やラボ型開発が可能な契約形態などを模索し、社内外のリソースをうまく活用しながら、社内の体制を作っていくのが良いかと思います。

組織・業務プロセスの変革

DXを実現する上で組織でまず変わらなければいけないのは、経営層だと考えています。
経営層がITへの理解を深め、先端のテクノロジーにより会社とビジネスをどう変えていくかのビジョンを自分たちが持った上でトップダウンで変えていく必要があります。
テクノロジーとそれらを使う人材の必要性と価値を理解した上で、その組織を作るのは経営層です。
内製化の一歩も経営層から動かないことには組織は変わらないでしょう。

次に業務プロセスです。
DXを唱えながらも紙への署名やハンコを利用したアナログな業務があらゆる部分で残っていると、RPAなどを導入しようにもその業務がネックになることが想像できます。
DXはデジタイゼーション(デジタル化)とデジタライゼーション(デジタルデータを用いたプロセス)の上に成り立ちます。
したがって、業務プロセスが変わっていない状態でDXを進めることは不可能ということになります。


DXのフェーズ2(エンドユーザーへの新たな価値提供)

技術の利用したプロダクトやビジネスモデルにより競争上の優位性を確立

フェーズ2はDXの本題で、以下の内容がポイントとなります。

  • AIやIoT、AR/VRなどのデジタル技術の利用したプロダクトやビジネスモデルを作る
  • 新たな顧客体験の提供により価値を生み出す
  • それらにより競争上の優位性を確立する

AI、IoT、ブロックチェーンなどの個別の技術については言及しませんが、それらのプロダクトを作り新たな顧客体験の提供を目指す上でアジャイル開発やDevOps、デザイン思考という手法や考え方が必要になります。
それらを下で紹介します。

■ アジャイル開発

アジャイル開発は、今までのウォーターフォールと異なり要件変更を前提とした開発手法です。
全ての機能を作り終えてリリースするウォーターフォールと異なり、小さい粒度と短いサイクルで開発とリリースを繰り返し検証を行うことができます。
またアジャイル開発のメリットは小さい粒度でリリースするため、一つ一つの機能を検証しシステム全体としてバグが少ない状態を保てることかと思います。
ウォーターフォールで作られたシステムを受入する際に、バグをチェックしたら数百のバグがありベンダーと揉めたなんて会社さんも多いのではないのかと思います。
また受入の際にユーザー企業が考えていた仕様と違い、リリースが遅れるなどのパターンもあったかと思います。
アジャイル開発ではそれらの問題が起きづらい状況を作ることができます。
ユーザー企業のコミットメントが求められバグの責任をベンダーと共有するなどのデメリットもありますが、DXを進める上で素早い対応が必要になる世界では、アジャイル開発がよりメジャーになることが考えられます。

■ DevOps

DevOpsは、Dev(開発)チームとOps(運用)チームを合わせて従来より速いペースで製品の改善を行い市場に提供するという考え方です。
従来開発チームと運用チームを別々にする場合が多いかと思いますが、DevOpsでは開発チームと運用チームを一つのチームにすることで以下の様な利点を得るものです。

  • 開発から運用までを一つとしてチームとしてのコミュニケーションを増やす
  • エンドユーザーからの製品へのフィードバックを早く実装し提供することで製品の改善速度向上
  • テストやデプロイなどのリリース処理を自動化

新しく製品を作ったとしても、半年・1年とアップデートがないような製品は今の世の中では受け入れられないでしょう。
DevOpsは昨今のアプリケーションのような週次や月次での更新を実施するには必要な考え方になります。

■ デザイン思考

デザイン思考は、デザイン制作における思考方法と手法を利用して、プロダクト開発やビジネスを変革・解決するための考え方で、一般的にデザインと聞いて思い浮かべるものとは異なります。
エンドユーザーのニーズが多様化し便利なものが溢れた現代ではただプロダクトを作れば良いということはなく、誰がエンドユーザーとなりえるか? エンドユーザーがどのようなものを求めているか? どういう体験を実現するとエンドユーザーの欲求を満たせるのか? といったことを考える必要があります。
それゆえ、エンドユーザーに提供する顧客体験(UX)を考える上でデザイン思考というものが必要になっています。


まとめ

長くなってしまいましたが、DXの全体像をざっくりいうと以下の様になります。

1. DXのフェーズ1(デジタイゼーションとデジタライゼーション)は会社のデジタルな土壌づくり

  • 誰も触れなくなったシステムがビジネスの速度を落としているから、機能を取捨選択してクラウドなど新たなプラットフォームに載せ替えて、利用しやすいメンテナンス可能なシステムにする
  • 誰も触れなくなったシステムを新しくする上で、自分たちで触れる様に自分たちで知識をつけて社内の開発体勢を整える
  • 会社のトップがソフトウェアやITを理解して、トップダウンで会社と業務プロセスを変えて行う
  • アナログな業務を減らして、デジタルツールで置き換えられる様に整理する

2. DXのフェーズ2(エンドユーザーへの新たな価値提供)はテクノロジーをビジネスに活用して価値を生み出し続けるための活動

  • 開発フロー、製品リリースフローの変革をする
  • 高いユーザー体験を提供するための変革をする
  • テクノロジーの活用をしたプロダクトやビジネスモデルで競争上の優位性を確立する

3. フェーズ1が出来てない状態ではフェーズ2には移れない

  • 土台が整ってこそのDX

いきなり全てを行うのは難しいかもしれませんが、変革のチャンスは目の前に来ています。
ユーザー企業、ベンダー企業、それぞれの変化が求められる世界になりました。
この波に乗って、攻めの姿勢で会社を作りましょう!


弊社ではDX推進のサポートをしております。
新規事業やPoCの受託開発だけでなく、業務プロセス改善、テクノロジーの社内勉強会やUIUXの改善などご相談だけでもお申し付けください!

.../articles/

Articles

記事

AWS AmplifyにmonorepoのNext.js(App Router)をデプロイする

AWS AmplifyにmonorepoのNext.js(App Router)をデプロイする

monorepo管理しているNext.jsをAmplifyにデプロイしようとした際にいくつか躓く内容があったのでまとめておきます。

リモートワーク・オンライン会議でも、スムーズに制作を進めるために大切なこと[資料編]

リモートワーク・オンライン会議でも、スムーズに制作を進めるために大切なこと[資料編]

コロナ禍の影響により、リモートワークの導入をおこなっている制作会社も多く、実際に弊社でも導入しています。

売れるECサイトデザインを作るために。参考にしたいおしゃれな事例の探し方。

売れるECサイトデザインを作るために。参考にしたいおしゃれな事例の探し方。

売れるECサイトのデザインは、「この形式」という決まりはありません。ECサイトで売り上げを上げるなら、しっかりとしたコンセプトと、コンセプトを決定するまでのリサーチが必要です。

制作会社の考える、業務効率化ツールのおすすめ。個人でも使いやすいサービスなど。

制作会社の考える、業務効率化ツールのおすすめ。個人でも使いやすいサービスなど。

新型コロナウイルス感染拡大の影響で、リモートワークが主流になり、弊社でも週のほとんどは各自宅で作業をしています。

Figmaでデザインのコミット履歴を残せるプラグイン【Thought Recorder】をリリースしました

Figmaでデザインのコミット履歴を残せるプラグイン【Thought Recorder】をリリースしました

Figmaを利用するWebデザイナーの助けになれると嬉しいです。使い方は本記事をご覧ください。

ECの構築方法、おすすめのECサービス。

ECの構築方法、おすすめのECサービス。

ファッションや家電、スーパーの買い物でさえもECサイトを利用することが当たり前になりました。加えて新型コロナウイルスの影響もあり、弊社にも「どんなプラットフォームを利用したら良いか」「どれくらいコストがかかるのか」などECに関するさまざまなご相談を頂きます。

FastAPIのスキーマクラスをOpenAPIから生成する方法

FastAPIのスキーマクラスをOpenAPIから生成する方法

PythonでAPIを構築する要件があり、フレームワークに比較的モダンなFastAPIを採用しました。FastAPIはバックエンドの開発を行えば自動でOepnApi定義を生成する機能が備わっていますが、今回はこれを使わず、事前に用意したOepnApi定義からFastAPIで利用するスキーマクラスを生成する方法を紹介します。

Laravel 日本一解りやすい全文検索のマイグレーション記載方法解説

Laravel 日本一解りやすい全文検索のマイグレーション記載方法解説

Laravel + MySQLで全文検索を実装する

GiFT1号目新卒デザイナーの2021年振り返り

GiFT1号目新卒デザイナーの2021年振り返り

いつの間に、年末ですね。入社してもう、9ヶ月も立っていたようです。2021年の振り返りを記事にしました。

TimesclaeDBのデータ圧縮に関して

TimesclaeDBのデータ圧縮に関して

TimescaleDBはデータベース内の一部のテーブルを時系列データとして扱えるPostgreSQLの拡張です。PostgreSQLの機能拡張なので非常に手軽に導入できます。今回はこのTimesaceDBの圧縮について調べたので備忘録として書き綴りました。

すべての記事

お問い合わせ