DX関連プロジェクトが求めるアーキテクトの役割【第4回】

“Why”“What”“How”を深堀する

　プロジェクトやプロダクトは予算の下で管理されています。プランニング時には資金回収期間（Pay Back Period）を意識しなければなりません。競争優位性を獲得するためには、すぐには効果が得られない“改革”と、すぐに効果が得られる“改善”とをバランスよく実現する必要があります。

　そのためにDX関連プロジェクトにおいて、ビジネスバリューコンサルタントは主に“Why（なぜ）”を、エンタープライズアーキテクトは“What（何）”を、テクニカル アーキテクトは“How（どのように）”を深堀することが役割だとも言えます。その観点から、3者の動き方を、もう少し具体的に説明します。

　まずビジネスバリューコンサルタントは、ビジネスリーダーとの間で、ビジネスモチベーションがどこにあるのかという“Why”を確認することが重要です。そのために、ビジネスのトレンドや改革などに対する長期的（1〜3年）な視点から、第1回で紹介した「DPA：（Digital Process Automation Platform）」のようなデジタルプラットフォームの導入メリットに加え、改善の視点から期待できるハードセービングなどを分析し説明しなければなりません。

　ビジネスモチベーションを確認できたら、その実現に必要なビジネスケイパビリティ（戦いにおいて兵士が必要とする兵器や装備に相当）を分析します（図2）。ビジネスアーキテクチャーからのアプローチとしては例えば、顧客にバリューを提供するためのエンドツーエンドのプロセス示す「ビジネスバリューストリーム」などを利用し、個々のバリューステージを実現するために必要なビジネスケイパビリティについて、現状とのギャップを分析・把握します。

図２：ビジネスケイパビリティの例

　ここでエンタープライズアーキテクトが、デジタルプラットフォームの活用で期待できるビジネスバリューの実現に向けて、最適な投資対象となる“What”を特定します。

　デジタルプラットフォームは、必要なデータをインテグレーションし、必要なツール群（テクノロジー）と必要なチャネルを介したデジタル体験の連携を図ることで、大規模なシステム投資を避けながらサイロ化の問題を解消できます（図2）。エンタープライズアーキテクトは、その特性と、現状のIT環境を大きく変えずに既存のアプリケーションやシステムを最大限に再利用できることを考慮して、投資対象を見極める必要があります。

図３：デジタルプラットフォームの例

アーキテクトらが連携しPDCAサイクルを高速に回す

　このように、コンサルタントやアーキテクト、あるいは事務企画部などに属して同じ役割を果たす人たちが、組織の抱える課題と解決・改善すべき問題をより鮮明に視覚化することで、DX関連プロジェクトの目的を明確にしていくことが、その推進・成功には非常に重要です。

　一見単純な図式のように見えますが、各役割の橋渡しがうまくいかないと次のような失敗談になりかねません。

• プロジェクトの目的・ゴール設定までは非常によく進められたが、計画実行が不充分で開発したアプリケーションを実装するデリバリープロジェクトの途中で頓挫した
• 課題抽出からプロジェクト化するまでは首尾よく進行したが、様々な要因・事情から本来の目的を徐々に見失い、いつしかデリバリーすること自体が目的化してしまった
• デリバリーを達成しても後の効果測定を忘れ、結局プロジェクト実行がビジネス的に意義あることだったのか否かの評価すらできない

　莫大な費用と時間をかけて高機能でバグのないアプリケーションを開発・実装したとしても、それを利用してビジネス的に価値を創出できないのであれば何の意味もありません。たとえ軽微な障害を１年に数十件起こしてしまうシステムだとしても、それを大きく上回る価値を生み出せているのであれば、それはビジネス的には合格点といえるのではないでしょうか。

　各アーキテクトが有機的に連携して機能するということは、“Why → What → How”のサイクルをより高速に、時には大胆に方向転換しながらも繰り返し実行していけるということです。そうしたプロジェクトの実行には、ローコードやノーコードのツールも不可欠です。

　次回は、プロジェクトデリバリーを中心に、CoE（Center of Excellence）を紹介します。