Episode 2 Structuring your Digital Transformation

デジタル変革失敗の構造的および技術的要因
ダレン・W・パルシファー博士
シリーズ: デジタル変革が失敗する理由 — O-DXAが存在する理由

デジタル変革は、20年以上にわたって経営陣の議題の一部でした。
その間、組織は技術の世代を次々と経てきました：
オンプレミスERP、サービス指向アーキテクチャ、クラウドプラットフォーム、自動化、分析、AI。

各波が来るたびに、ツールは進化し、より良くなります。
それでも、変革の結果は妙に見覚えがあります。

• プロジェクトは稼働します。
• パイロットが成功します。
• ダッシュボードが点灯します。

そして——3年から5年後、組織は前回の変革イニシアティブが解決すべきだった多くの同じ問題に対処するために、新たな「変革」イニシアティブを立ち上げます。

これは孤立した話ではありません。
それはパターンです。

このシリーズの第1回は、そのパターンを持続的で体系的なものとして整理しました：
セクター、技術、リーダーシップの変化を超えて繰り返される失敗。
今回のセッションでは、一歩進んで、なぜ技術中心の説明では不十分なのか、
失敗の主な原因が構造的でアーキテクチャ的であり、技術的ではないのかを検討します。

私たちの目標は、構造的な原因を技術的な症状から区別し、
戦略、実行、ガバナンスの間の不整合が、
どのようにしてデジタル変革の成果を停滞させるのかを示すことです——どんなツールを購入してもです。

より良いツールがパターンを解決しない理由

変革の取り組みが停滞すると、事後検証はしばしばお馴染みのものになります：

• 「間違ったプラットフォームを選んでしまった。」
• 「ベンダーが期待に応えられなかった。」
• 「その方法論は私たちの文化には合わなかった。」
• 「チームに必要なスキルがなかった。」

これらは架空の苦情ではありません。
実際の問題を描写しており、プロジェクトを台無しにする可能性があります。

問題は、これらの説明が誤りであることではありません。
問題は、それ単独ではあまりにも小さすぎることです。

デジタル変革の失敗が再発する様子を考えてみてください：

• 異なる技術世代を超えて (モノリシックERPからSOA、マイクロサービス、クラウド、AIまで)。
• 異なるベンダーとパートナーと共に (新しい波のたびにプロバイダー、コンサルティング企業、またはプラットフォームを交換)。
• 異なるリーダーシップチームのもとで (CIO、チーフデジタルオフィサー、またはプログラムスポンサーが交代する)。

もし根本的な原因が「間違ったプラットフォーム」や「間違ったパートナー」であれば、
それらの選択が修正されると結果が異なるはずです。
代わりに、組織はしばしば経験します：

• 意思決定の遅延が同じ。
• パイロットを超えてスケールするのが同じく困難。
• ローカルの最適化とエンタープライズの成果の間に同じ緊張。

言い換えれば：
観察可能なパターンは、ベンダー特有でもツール特有でもありません。

技術的な説明——設定ミス、未成熟なツール、テストカバレッジの不足、弱いDevOpsプラクティス——はリアルです。
それは1つのプロジェクトを沈めることができます。

しかし、それだけでは、なぜ類似の失敗が異なる世代の技術、
複数の組織で、数十年にわたって現れるのかを説明できません。

異なるツールが同じ構造的成果を生み出すとき、構造こそを調査する必要があります。

技術的な事後検証がポイントを見失う理由

技術的な事後検証は、具体的に感じるため魅力的です：

• 誤設定されたシステムを指摘できます。
• 特定の設計選択による障害を追跡できます。
• 見積もりが不十分な複雑さによるオーバーランを帰属させることができます。

これらの物語は、学びと改善にとって重要です。
しかし、それには2つの根本的な盲点があります。

1. ローカル条件に焦点を当てる

技術的な分析は、プロジェクトやシステムのローカル環境に焦点を当てます：

• 特定のスタック、インフラ、またはアーキテクチャ。
• 特定のチームとそのプラクティス。
• 特定のデリバリーライフサイクルと制約。

彼らはめったに尋ねません：
周囲のシステムの何がこの結果を可能にしたのか？

例えば：

• なぜ決定権はそこで留まっていたのか？
• なぜ資金承認がそのように構造化されていたのか？
• なぜガバナンスフォーラムが機能横断的な成果を強化するのではなく、サイロ行動を強化したのか？

これらの質問がなければ、各失敗は局所的な異常として扱われ、
共有された構造的パターンの証拠とは見なされません。

2. 各新しい技術波でリセットされる

技術的な事後検証は、多くの場合、特定のスタックに「バージョンロック」されます：

• 「私たちはその方法でモノリシックを設計しないことを学びました。」
• 「次のクラウド移行では二度とその過ちを犯さないつもりです。」
• 「次のAIプロジェクトでは、最初からMLOpsを取り入れるつもりです。」

しかし新しい波が襲いかかります。
新しいパターン、新しいバズワード、新しい制約が登場します。

組織は新しいスタックの周りで「学びをリセット」し、
同じ構造的制約の多くを引き継ぎます：

• 同じ断片化されたガバナンス。
• 同じサイロ化された資金モデル。
• 同じ不整合なインセンティブ。

技術は変わります。
構造は変わりません。
ですから、結果——エンタープライズレベルでは——は変わらないのです。

デジタル変革における「構造」の本当の意味

失敗の構造的原因を理解するためには、
この文脈での構造の意味を明確にする必要があります。

構造は隠喩ではありません。
それは、実際に仕事がどのように行われるかを形成する持続的な配置の集合です。

最低限、その構造には以下が含まれます：

• 決定権
  誰が、何を、どのレベルで、どのタイムスケールで決定できるのか？ 例として：

  • クロスファンクショナルチームは重要なプロセスを変更できますか？それともステアリングコミッティにエスカレーションする必要がありますか？
  • 複数のビジネスユニットにまたがる決定を誰が所有していますか？

• 資金モデル
  投資はどのように提案、承認、更新されるのか？
  予算は：

  • プロジェクト、部門、プラットフォーム、またはバリューストリームに従っていますか？
  • 継続的な調整をサポートしますか、それとも大規模でエピソディックなプログラムのみですか？

• ガバナンスフォーラム
  クロスカッティングな問題はどこで解決されるのか？

  • ローカルな自律性とエンタープライズの一貫性をバランスさせるメカニズムはありますか？
  • リスクおよびコンプライアンス機関はデジタル配信と統合されていますか、それとも連続的なゲートとして存在していますか？

• バリューおよびワークフロー
  仕事はどのように境界を越えて進むのか？

  • プロセスは顧客の旅やミッション成果周辺に設計されていますか、それとも組織図に基づいていますか？
  • ハンドオフのどこで摩擦や失敗のモードが生じますか？

これらの構造の要素は、特定の技術スタックの上および周りで機能します。
それらは以下を形成します：

• どのプロジェクトが資金調達されるか。
• どのトレードオフが許可されるか。
• 戦略的意図が実行可能な決定にどれだけ迅速に流れ込むか。

私たちが変革の失敗が構造的であると述べるとき、
私たちが意味するのは：

決定権、資金、ガバナンス、バリューの流れの配置が、
宣言された戦略から実行を系統的に引き離すことです——たとえ個々のプロジェクトが技術的には成功しても。

構造的不整合：戦略、実行、ガバナンス

構造的な原因をより明確に見る方法の一つは、
戦略、実行、ガバナンスがどのように乖離するかを見ることです。

• 戦略 — 意図と方向の声明：

  • 「私たちはデータ駆動型の組織になります。」
  • 「私たちはシームレスなエンドツーエンドのデジタルサービスを提供します。」
  • 「私たちはミッションに近いチームに権限を与えます。」

• 実行 — 実際の作業：

  • プログラム、プロジェクト、製品。
  • 日々のプロセスやワークフロー。
  • チームの人員配置や評価の方法。

• ガバナンス — ルールと監視メカニズム：

  • リスクとコンプライアンスのポリシー。
  • 予算編成およびポートフォリオのプロセス。
  • 標準および承認ゲート。

変革の取り組みがつまずくとき、以下のようなパターンがしばしば見られます：

• 戦略は機能横断的でユーザー中心のサービスを約束します。
  実行はまだ部門プロジェクトの周りに組織されています。
  ガバナンスは提案を部門ごとにレビューします。

• 戦略は権限を持つアジャイルチームを求めます。
  実行チームはアジャイルの用語を採用します。
  ガバナンスは基本的な変更のために依然として数か月にわたる承認サイクルを要求します。

• 戦略はデータ駆動の意思決定を強調します。
  実行チームは分析ダッシュボードを構築します。
  ガバナンスプロセスは依然として静的なレポートと手動での承認に依存しています。

各場合において：

• 技術は最新です。
• デリバリープラクティスは最新です。

しかし、戦略、実行、ガバナンスの間の構造的関係は不整合です。
そして、その不整合が持続的な変革を最終的に妨げます。

構造が不整合であるとき：

• 実行チームは効率的で能力がある場合でも——間違ったものを最適化しています。
• ガバナンスフォーラムは注意深い場合でも——サイロを強化し、体系的な変更を遅らせます。
• 戦略文書は魅力的ですが——日々の行動にあまり影響を与えません。

結果はお馴染みです：

• ローカルの勝利。
• エンタープライズの停滞。
• 数年後の別の変革プログラム。

不整合が新技術で増幅される方法

ここで逆説的な現実が浮かび上がります：

構造的不整合が存在する場合、より良い技術が問題を悪化させることがあります。

なぜですか？

なぜなら現代のツールは：

• 実験のコストを下げます。
• ローカルな意思決定の速度を上げます。
• 個々のチームや部門が独自に前進するのを容易にします。

周囲の構造が整合していない場合：

• チームは異なる方向に素早く動きます。
• ローカルな最適化が増えます。
• 統合とガバナンスの課題が増加します。

同期した変革の代わりに得られるのは：

• 重複する能力を持つ複数の「戦略的プラットフォーム」。
• 同様のポリシー（例：セキュリティ、データ保護）の不一致な実装。
• 同じ問題に対する並行ソリューション、それぞれがエンタープライズ全体でスケールしません。

技術は「悪くない」です。
ただ、見つけた構造を増幅しているだけです。

もし決定権、資金モデル、ガバナンスメカニズムが断片化している場合、
現代のデジタルツールは断片化を加速します。

アーキテクチャを構造的なディシプリンとして捉える

ここでアーキテクチャが物語に登場します——それは図のセットとしてではなく、
構造的なディシプリンとしてです。

多くの組織では、アーキテクチャは以下のように認識されています：

• リファレンスモデルや標準のリポジトリを維持するチーム。
• 設計レビューに参加し、プロセスの後半で「いいえ」と言うグループ。
• 実世界の変化に遅れをとるドキュメンテーション機能。

構造的な枠組みでは、それだけでは不十分です。

構造として理解されたアーキテクチャは、
以下についてです：

• 戦略的意図を運用上の制約とパターンにエンコードする
  地域の決定がエンタープライズの成果に積み重なるように。

• 決定経路を形成する
  新しいイニシアティブが現れたとき、一貫した原則に従って流れるようにすることです。

• 戦略、実行、ガバナンスを橋渡しする方法として：

  • ポートフォリオがどのように構成されるかを情報提供する。
  • 資金モデルが一貫性を強化する方法に影響を与える。
  • ガバナンス機関が適用できる共有原則を提供する。

言い換えれば： アーキテクチャは主に成果物ではなく、統治システムです。
時間の経過とともに人、プロセス、ポリシー、技術を整合させるものです。

この構造的なディシプリンとしてのアーキテクチャの層が機能しないとき：

• 変革は切り離されたプロジェクトの連続として実行されます。
• 各プロジェクトは自ら整合性を交渉しなければなりません。
• ガバナンス機関はサイロを越えた決定を行うための共有フレームを欠いています。

結果は「技術的失敗」のように見えますが、より深い問題は：

• 条件が変わる中で実行を戦略と結びつけるための構造的メカニズムが存在しないことです。

構造的問題を技術的問題として扱うことが失敗する理由

組織が構造的問題を技術的問題と誤診断するとき、
彼らは予測可能な方法で対応する傾向があります：

• 遅い配信を「修正」するために、大規模な再プラットフォームを立ち上げる。
• 景観を「単純化する」ために、一つのベンダーエコシステムを別のものに入れ替える。
• 銀の弾丸として新しい方法論や運用モデルを導入します。

これらの応答は限られた意味で貴重です。
特定の環境の側面を改善するかもしれません。

しかし、決定権、資金、ガバナンスの根本的な構造が変わらなければ：

• 新しいプラットフォームは同じ承認ボトルネックと不整合なインセンティブを引き継ぎます。
• 新しいベンダーは前のものと同じサイロ間の対立に遭遇します。
• 新しい方法論は古いガバナンスと予算のリズムに適合させられます。

組織は変化に多大な投資をし——その後、
その軌道はほぼ同じであることに気づきます。

誤診断の特定のコストが際立ちます：

1. 蓄積された複雑さ
   各サイクルは以下を追加します：

   • 新しいプラットフォームと統合。
   • 追加のガバナンスプロセス。
   • より重複した能力。
     複雑さは増します。
     構造的整合性は改善されません。

2. 本当の構造的変化の能力の減少
   数回のサイクルの後、利害関係者は懐疑的になります：

   • 「私たちはすでに三つの変革プログラムを実施しました。」
   • 「アジャイル/クラウド/分析を試したが、問題は解決しなかった。」
     より深い構造的変化への欲求は低下し、
     必要性が高まるにつれて増加します。

統合されたアーキテクチャ対応に向けて（プレビュー）

この講義とそのブログ版は意図的に以下に焦点を当てています：

• 持続的な失敗が個別のツールやプロジェクトを超えた系統的な原因を示すこと。
• 戦略、実行、およびガバナンスの間の構造的不整合が、これらの失敗の主要な推進要因であることを主張すること。
• この不整合に対処できる構造的なディシプリンとしてのアーキテクチャの再定位——事後的な文書作成の運動としてではなく。

私たちはまだ特定の解決策の枠組みや運用モデルを説明していません。
それはシリーズの後半で取り上げます。

特定のアプローチを紹介する前に、私たちは以下の明確で共有された理解を持つ必要があります：

• 不整合が人、プロセス、ポリシー、技術にどのように現れるのか。
• ガバナンスの断片化と決定権のパターンが予測可能な失敗モードをどのように生むか。
• アーキテクチャが本当の統治システムとして機能することの意味。

次のインストールでは、これらの構造的パターンに深く入り込んで、
繰り返される失敗が現在の組織のアーキテクチャからどう生じているのかをマッピングし、
デジタル変革を時間をかけて整合化するための統合されたアーキテクチャモデルが必要です。

今のところ、重要なポイントは明確です：

繰り返される変革の失敗がツール、ベンダー、技術の波を超えて同じに見える場合、
問題は主に技術的ではありません。
それは構造的であり、構造的なディシプリンとして扱われるアーキテクチャで作業を始める必要があります。