DXをサクセスさせる：2 ロードマップを描く
前回は、組織が目指す姿を明らかにして、関係者を動機づけるためのVision作りについて説明した。今回はそのVisionを着実に実現するためのロードマップ作りについてみていこう。
ロードマップの重要性
ロードマップとはゴールに対する道筋を表したものである。DXに限らず、さまざまな戦略、企画、計画等にロードマップは存在する。
通常、ゴールは、一朝一夕には到達できないため、順を追って、時間をかけて取り組み、少しずつゴールに近づいていく感覚をイメージしていただくと良い。
そのゴールへの近づき方を描いたものがロードマップである。
DXの文脈では、実現する機能、サービスを中心に表現されたロードマップはテクニカルロードマップやソリューションロードマップと呼ぶこともある。以降は、特に断りのない限りロードマップとして説明する。
ロードマップはハイレベルな重要性や方向性を示すもので、構築プロジェクトのスケジュールの様な詳細は求められないが、今後の予算計画、人員計画などさまざまな場面で利用されることになる。
ロードマップの構成要素
戦略マップ等で、組織が実現したいビジネス目標を特定した後、ビジネス目標を達成するための取り組みや実現する機能、サービスを特定し、１〜3年先までの将来をロードマップとして描く。
ロードマップに反映されるべき情報としては次のようなものがある。
ビジネス目標を達成するために必要なIT能力（IT Capability)
順序性 ビジネス面から見た実現サービスの優先度、アーキテクチャ面から見た実装順番の適切性
タイムライン どの機能を使ったサービスがいつごろ実現されるかおよその時期やマイルストン
ビジネス成果 その実現によって組織が達成したいビジネス成果とIT能力の関係づけ
図1 にロードマップに上記で挙げた情報を含めた枠組みの例を示す。
実効性のあるロードマップ作りのポイント
ロードマップを作る際の、実際の経験を通じて見えてきたポイントをいくつか挙げる。
Visionと整合したものにすること
ロードマップを作る段階になって、なぜDXをするのかが置き去りにされることがよくある。Visionをどのような道筋で達成するのかを表すのがロードマップであることを忘れないようにしたい。
外部パートナー、ベンダー任せにせず、必ずDXの責任者が説明できるようにすること
製品やサービスの利用を増やしたい外部パートナーやベンダー、あるいはコンサルティング会社がロードマップ作りに協力してくれることはよくあるが、DXの責任者はロードマップの検討を彼らに任せすぎないようにしたい。
外部のメンバーは、情報量が限られることが多く、経験からくる想定と仮説で補ってロードマップを作らざるを得ない場合がある。そのため、一見それらしい見た目になっていたとしても、組織の考える優先度などディーティルのところまでは詰められていないこともある。
DXの責任者は、必要な社内情報やリソースにアクセスすることができる立場であるはずなので、正しい情報に基づいて、外部支援者と共に検討することを推奨する。
また、ロードマップの内容をDXの責任者が自分の言葉で説明可能な内容にすることも重要である。責任者が説明できないものを関係者が理解しロードマップを進捗させることはできない。ロードマップが形骸化すると、誰も参照しないドキュメントの1つになる。そうなると組織はVisionを達成するための手段を1つ失うことになる。
定期的にメンテナンスすること、そのためのチームを作ること
ロードマップは一度作成して終わりではなく、例えば年1回など定期的に更新が必要である。時間経過によりビジネス環境が変化すれば、あるべき姿も変わりロードマップも変更が必要になる。そのために定常的にロードマップを管理する役割を作る必要がある。
ロードマップの具体化（ServiceNowを題材に）
ロードマップは、製品やサービス、ソリューションを限定しないが、作り方を解説するためにここではServiceNowのロードマップを題材として取り上げる。ServiceNow以外のロードマップを作る際にも基本は変わらないので参考にしていただければ幸いである。
ロードマップのインプット情報
ロードマップを作成するためには、さまざまなインプット情報を利用する。ServiceNowの場合には、図2 テクニカルロードマップと他のアウトプットとの関連に示すような情報を集める。
ServiceNowのロードマップを作成する際には、先に説明した戦略マップに加え、Value Blueprint（価値の青写真）、ケイパビリティマップと呼ばれる製品の提供する主要機能の一覧、製品が想定する標準的な実装順番を示すRecommended Implementation Sequence、SNのデータモデルであるCommon Service Data Model（CSDM）などが参照される。
このような技術情報は更新されるため、検討の際は各ベンダーに相談し常に最新版を確認することをお勧めする。
ロードマップを作成するためのインプット情報が集まったら、ビジネス観点での情報群と技術観点での情報群を組み合わせていく。このタイミングがビジネスとITの繋ぎのタイミングになる。
ロードマップはDXの責任者の関与の元、エンタープライズアーキテクトのような全社のITを俯瞰してみられるようなリーダーがビジネスの責任者や有識者を巻き込みながら作成するのが望ましい。
ロードマップが出来上がったら、一刻も早く機能（サービス）を実現したい気持ちはわかるが、他のDX関連活動の計画と整合が取れているかを確認することを最後にすると良い。組織には様々なDX関連活動が並行して走っており、それらとの関連を考慮することも大事なポイントである。
上記のようなレビューを経てロードマップが完成する。次は、これをDXの関係者によく浸透させて、個別のサービスの構築に入っていこう。
この記事が気に入ったらサポートをしてみませんか？