※議論の成果は2026年に「DX白書」（仮）として今秋、出版予定です。
―――「ブームに乗れば正解」なが時代は終わり、混沌としたデジタル優位時代に、DXを成功させ、テクノロジーを最大限に活かす企業経営とは…。（上からの続きです）
未来を語れるビジネスパーソン
山本：
DXを進めるにあたり重要なのは、ビジネスとテクノロジーの関係を認識することです。上野さんはScrum@Scale（※）もスタディしていますよね。
※）スクラムの原則を「チーム単位」から「企業全体」に拡張する考え方
上野：
改めてスクラムの組織モデルはよく考えられていると認識しています。ビジネスとテクノロジーの関係で言えば、両者が適切な牽制関係を築くことが、企業の理想像です。ビジネス側に立ち、「何を作るのか」に責任を持つプロダクトオーナー（PO）と、IT側に立ち「どう作るか」に責任を負うスクラムマスター（SM）、二つの機能がそれぞれ意思決定と改善を行い、細かくサイクルを回し、両者をエンタープライズ（全社）レベルまで落とし込む、というのはスクラムを採用していない企業にとっても一つの組織モデルとして学ぶべきものと感じます。
山本：
牽制関係とは、性質が異なるからこそ互いにフィードバックを返し合い、連携する構造ですね。エンタープライズアーキテクチャ（EA）で捉えるなら、ビジネス側はビジネスアーキテクト（BA）、IT側はデジタルアーキテクト（DA）でしょう。この関係は「What」と「How」に換言できますね。
上野：
分かりやすいですね。「What」はビジネス側が見据えている「目的」であり、「How」は目的を達成させるためにIT部門が取る「手段」ですよね。
山本：
「What」と「How」は相互作用的な関係にあります。性質は異なるものの、連携するという構造でなければなりません。しかし、情報システム部門からビジネス側に対してフィードバックが増えた現在、「手段」であるはずのテクノロジーが、ビジネス側の「目的」の決定に非常に大きな影響を与えてしまうケースが増えました。この現象は、エンタープライズレベルだけでなく業務、インフラといった現場でも発生しています。
この歪みが適正化されれば「アーキテクチャのイメージ」が社内の共通認識として生まれ、ビジネスとテクノロジーが、相互に新たなアイデアをフィードバックし合う「進化し続けるEA」を誕生させられると考えています。
上野：
その視点はこれから益々、大切になりますね。一方で、どこまでいってもやはりビジネス側が「ありたい姿」、つまりビジョンを語ることの重要性も変わらないと思います。業務もシステムも複雑化する中で、そういったプロセスビジョンを語れる方はそれほど多くはないですが。
山本：
残念ながら、日本企業は変革のビジョンを明確に語るということは苦手としているように思います。
上野：
ビジネス側が、自分たちが責任を負っている業務プロセスに対して、自分ごととして捉えきれていないからだと推察します。例えば全社の新しいDXロードマップを作成することを想定します。
私は「他社との差別化要素、競争力の源泉への投資をどうするか」「変化にさらされる領域はどこか」といった議論を投げかけます。しかし、特に業務プロセスという観点で「自分たちの競争力の源泉が何で、今後の外部変化に対してこのように変革していきたい」などと自分の言葉で語れる人は少ないのが現状です。議論は最終的に、工数をどれだけ下げられるかといった分かりやすい効率性の話に帰着してしまいがちです。
デジタル教育だけでは「X」にならない
山本：
ビジョンを語れない背景には、国民性や歴史的背景も関与しそうです。加えると、DXにおける「X（トランスフォーメーション、変革）」の意識が低いことが挙げられるでしょう。DXを推進するのであれば本来、ビジネス側こそ「X」に適応してもらう必要があるのですが。
DX教育は「ソリューションを使う教育」と捉えられがちです。個人のデジタル武装はもちろん大切ですが、ビジネス側に対して「Ｘ」がない「D（デジタル）」だけの教育に熱心です。解決策はありますか。
上野：
シンプルですが、こんなチャートがあります。業務プロセスが競争力に資するかを判断するうえで、要求変化の大きさと業務の独自性の軸で業務を棚卸して評価します。Bの業務プロセスが今後も変化し続けることが競争力の源泉になるのであればアジャイルチームを立ち上げて積極的な投資を行う、Cであれば、独自性および変化が少なく競争力強化に資することはないため、パッケージに沿ってシステムを構築する等の方針が見えてきます。
ここで「X」の考え方を知っているかどうかで、組織の動き方は大きく異なります。マネジメント層がこうした枠組みを持てば、変革の一つの指針になります。このメリハリがないため、「とにかくコストを抑えて効率化」となってしまうのです。
常時最適化し続ける開発と運用の融合
上野：
また、ビジョンを語るためには、ケイパビリティを明確にすることも必要です。そのためには、戦略を持った上でビジネスアーキテクチャを分析し、常に周囲の環境を注視して変化に対応し続けなければなりません。システム開発後も運用と並行しながら環境に合わせて常時最適化し続ける―DevOps（開発と運用の融合）的状態です。
山本：
常時最適化を図ろうとすれば必然的に、システムの管理はそのライフサイクル全般に及ぶことになります。マネジメントサイクルに寄った「運用も含めて仕組みを管理していく」、つまりプロダクト・ライフサイクル・マネジメントですね。
上野：
「運用も含めて仕組みを管理していく」ことは、システムトラブルの主因であるブラックボックス化を防ぎます。また、環境変化によって効果が見込めないと判断された開発プロジェクト（PJ）を止める、損切りの判断材料にもなります。
山本：
そこで参照されるのはプロダクト・ポートフォリオ・マネジメント（PPM。ここでは企業が保有するデジタルプロダクトの構成や関係性を管理・分析する手法）です。また、イニシアチブポートフォリオ（企業や組織が戦略的な目的を達成するために立ち上げるPJや取り組みの構成）を定期的に評価し、後続するPJの改廃を間断なく続ける体制の構築が求められます。
増え続けるシステムは開発・保守が複雑化してしまうため、連携が鈍化しないよう機動的かつ効率的な運営を行うことが求められます。
上野：
はい。そして、プロジェクトは単体ではなくEA全体との関係を意識した視点で管理し、個々のシステムが個別設計される以前にEAとの相互評価を行ことが肝要ですね。
山本：
ただし、理想的なEAをはじめから構築することには相当な労力が伴います。さまざまなデジタル施策を推進していきながら、徐々に理想的なEAに収斂させていくのも一つの手段です。
役割が変化する各組織
山本：
EAの機動的かつ効率的な運営には、社内部門間の連携が不可欠となります。今後の環境変化次第では、これまでとは異なる役割を持つ部門も現れることがありそうですね。
上野：
例えばテクノロジーの原点に回帰する部門も出てくるのではないでしょうか。テクノロジー市場動向を調査・研究し、自社へ影響を与える可能性について戦略、業務・事業部門、フロントといった社内各部門と共有・協議する役割を担うのです。業務効率化に関するものは業務・事業部門へ、デジタル基盤やセキュリティに関するものは情報システム部門さらに経営と連携する、というイメージです。
山本：
同感です。補足すると、市場やテクノロジー動向をくまなく調査することは不可能なため、競争優位性や他領域に影響を与えるもの、自社の業界等に優先順位をつけることになりますね。
上野：
調査時は外部研究機関（情報機関）との連携が必須となるため、ベンダーとの関係は「自社業務の委託先」から「情報の連携先」となるのがよいと思います。技術に強みを持つエンジニアリング組織が構築されれば、自社が関係する領域へのソリューション選択も明確になるはずです。
山本：
ここまでありがとうございます。ソリューション導入が先行しがちなデジタル優位時代に、“真の企業DX”を実現するために必要なことを整理します。
エンジニアリング部門から連携された情報を踏まえ各部が検討の末、全体のアーキテクチャが意図しない方向に進まないよう、しっかり手綱を握ってエンタープライズアーキテクトを制御し続けること。言葉では簡単ですが、実現するにはまず、ビジネス側が企業として未来にありたい姿、ビジョンを語ることが出発点になりますね。
エディター・ライター
2021年にLTSへ入社後、LTSリンクのエージェントサービスにて出向社員として営業業務に従事。現在はLTSのマーケティングチームに所属し、CLOVERの企画・執筆や企業SNSの運用・管理を行っている。趣味は旅行、食事、犬猫動画を漁ること。（2024年6月現在）
