TaniumのCISOとして、クリストファー・ホドソン氏は、企業規模の技術リファクタリングの取り組みを推進する役割を担うCIO、CTO、CISOの方々と頻繁に面会しています。こうした取り組みでは、情報の保護やビジネスの回復力を維持するために必要な前提条件が整っていない場合が少なくありません。 このブログは、規制遵守が厳格化されている時代におけるデジタルトランスフォーメーションを検証する 3 回シリーズの第1回です。まずは、頻繁に使われながらも誤解されがちなこの用語そのものを、どのように捉えるべきかについて考察します。
「デジタルトランスフォーメーション」とは、一般的に、業務プロセスの改善を図るためにプロセスとテクノロジーを融合させることを指し、その一環として、手作業に代わる、あるいはそれを補完するコンピューティング機能の導入が行われます。 これは、特に取締役会レベルにおいて、経営陣からますます頻繁に求められる方針となっています。デジタルトランスフォーメーションは自動化を促進し、それによって業務の複雑さを軽減し、企業の健全な収益を確保し、顧客満足度を維持することに寄与するからです。 これって、気に入らないわけがないですよね？
ここでの危険性は、「デジタルトランスフォーメーション」の実現を急ぐあまり、組織が、特にセキュリティやIT運用に関して、本末転倒な対応をとってしまうことが多いという点にあります。 ITプロセスを自動化する製品が増えても、ネットワークに接続されているものについて可視性のギャップが生じているようでは、ビジネスの効率化にはつながりません。 また、基本的なITの衛生管理がしっかりと行われていない限り、自動化によって組織のセキュリティが向上したり、他の形態の混乱に対する回復力が強まったりすることはありません。
ここでは、デジタルトランスフォーメーションにおいて不可欠な3つの重要な考慮事項をご紹介します。
1. 「変革」には、自分たちが何を持っているかを把握することが必要です
いや、本当に、すべてを把握できているのでしょうか？
事業運営と顧客体験全体を大幅に改善するためには、組織は現在のソリューションやプロセスを把握する必要があります。企業全体にわたるサービス提供内容やプロセスを把握し、従来の業務手法を理解して文書化する必要があります。 変革は、テクノロジーとプロセスの交差点においてのみ起こります。 テクノロジーだけでは、いかなるビジネス上の課題も解決することはできません。 私の経験上、デジタルトランスフォーメーションにおける「デジタル」という側面が、業務手順を根本的に変革する必要性よりも優先されがちであり、それが後々大きな問題を引き起こしています。
プロセスの不透明性に関する課題を克服するため、私が関わっている多くの企業では、ビジネスプロセスモデリング（BPM）から多大な価値を得ています。 BPMを活用することで、企業は既存の業務プロセス全体にわたる非効率性、手作業による負担、および課題を特定し、変革に向けたビジネスケースを作成することができます。 BPMは、デジタルトランスフォーメーションのビジネスケースを策定することが多く、半定量的な投資収益率（RoI）の算出を可能にします。
しかし、BPMの導入の有無にかかわらず、デジタルトランスフォーメーションの取り組みに着手する企業は、自社の「現状」のシステム環境の全容を把握し、それが単なるアプリケーションの不完全な一覧ではなく、以下の点についてアーキテクチャを軸とした評価であることを認識することが不可欠です：
- 組織構造
- 重要な業務プロセス
- データの分類
- 用途
- エンドポイント資産
- データの流れと処理
私はこれまで、デジタルトランスフォーメーションを、より強固なコンプライアンス体制の構築、複雑性の軽減、およびソリューションの市場投入までの期間短縮を促進する原動力として活用している、数名のCIOの方々と協働してまいりました。 セキュリティおよびテクノロジーの責任者たちは、ビジネスアナリストと連携し、ビジネスサービスを機能レベルから、それを支えるアプリケーションやそこに格納されたデータに至るまで、具体的に具体化しています。 このようなモデルは、規制上の立場を明確にし、重要なビジネス上の活用例を浮き彫りにする上で、極めて有用です。
2。 私たちが具体的に何を行うのか、そして誰が責任を持つのかを明確に定義する必要があります。
組織は、サービス提供について、一連のアプリケーションを展開するまでの時間や、ワークロードを「オンプレミス」からクラウドへ移行するまでの時間という観点で考えることがあまりにも多いのです。 多くの場合、バリュードライバーは、「本番稼働」後に顕在化する問題だけでは満足しません。
私は長年にわたり、「サービスの産業化」という用語を用いて、アプリケーションやインフラストラクチャを環境に導入するプロセスを説明してきました。 このプロセス全体における成功の指標は、「導入までの時間」や不透明なプロジェクトコストに基づくべきではなく、組織との適合性に重点を置くべきです。 次のような点を理解しないまま、新しいアプリケーションが社内に導入されるケースをあまりにも多く目にします：
- このサービスの所有者は誰ですか？
- ステークホルダーは、どのようにこのサービスを利用しているのでしょうか？
- このサービスを運営するには、何人必要でしょうか？
こうした根本的な疑問に答えられないと、よく言われるように、アプリケーションやサービス自体がどれほど堅牢であっても、その進捗は遅れてしまいます。
3。 「変革」を急ぐあまり、デジタルデータの無秩序な増加を招くことのないようにしましょう
IoT、一時的なクラウドワークロード、Dockerコンテナ、マイクロサービス、そしてビッグデータ――これらそれぞれの技術が、デジタルトランスフォーメーションの基盤となっていると言えるでしょう。 とはいえ、これらもそれぞれ企業の「デジタル排気」の一因となっており、テクノロジーアーキテクチャ全体において不適切に管理されたり、適切に考慮されなかったりすると、上記の「1」および「 2 」に関連する課題の一因となってしまいます。
「変革」をうまく乗り切る
「デジタルトランスフォーメーション」という言葉には、さまざまな意味が込められています。多くの場合、婉曲表現であり、時には注意をそらすための言葉でもあります。 例えば、CIOの方々がクラウド移行について語っているのを耳にすることがありますが、実際には、パフォーマンスの低いモノリシックなアプリケーションスタックを、別のデータセンター（例外なくクラウドサービスプロバイダーが所有するものです）へ「リフト・アンド・シフト」しているに過ぎないのです。 デジタルトランスフォーメーションは、単にビジネスサービスを劇的に変えるだけのものではありませんし、単に「機能」を追加するための、コスト効率の良い好機というだけのものでもありません。 これは、一歩引いて、アプリケーションのアーキテクチャ全体を見直す機会となります。
このブログシリーズの第 2 回では、アプリケーションアーキテクチャを見直すことが、デジタルトランスフォーメーションが約束するビジネスの生産性向上を実現するだけでなく、GDPRやCCPAをはじめとするプライバシー規制がIT環境を一変させ、それを支えるチームに新たな課題をもたらしているこの時代において、常に一歩先を行くための鍵となる理由について解説します。
Taniumの実際の動作をご覧になりませんか？ の個別デモをご予約いただくか、毎週開催されているウェビナーにご参加ください。 「 」の今後のイベント（）にて、当社のTaniumエキスパートにご相談ください。
