検索
連載

DXプロジェクトはなぜ頓挫するのか? まず実施すべき「幹線の抽出」とは何か現場から見た「DXの真相」(2)

デジタルトランスフォーメーション(DX)の価値を経営層が認め、具体的なプロジェクトとして動きだす。一見、理想的なDXの進み方に思えるが現実は厳しい。せっかくのDXプロジェクトなのに頓挫してしまう、その原因とは何なのだろうか。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

 第1回の「単なるバズワードではない『DXの正体』とは何か」ではデジタルトランスフォーメーション(DX)の正体について解説しました。第2回は「いざDXプロジェクトを立ち上げたはいいが、いろいろな壁が立ちはだかって前に進まない」といったプロジェクト推進時に発生する問題について解説します。そもそも「なぜいろいろな障壁が発生するのか」という根本的な原因についても触れていきます。

なぜ一貫性のある目的が必要なのか

 第1回では本来あるべきDXのゴール、推進する上での前提条件について触れました。大切なことなので、改めておさらいすると「経営戦略、事業戦略、IT戦略と各戦術に一貫性があること」です。一貫性が保たれている状態とは、経営者、事業責任者、IT責任者といったDX主要メンバーの目的意識が統一され、彼らのコミットメントが得られた状態になります。するとプロジェクトマネジャーの「やりやすさ」が倍増します。もし、これらの一貫性がない状態でDXプロジェクトを立ち上げてしまうと、最悪の場合プロジェクト自体が頓挫してしまうこともあるでしょう。

 プロジェクトには必ず目的が存在し、プロジェクトオーナーやステークホルダーが定義します。DXのような「大規模かつ部門横断的なプロジェクト」においては目的自体の定義が難しく、曖昧な目的を設定しがちです。そして目的が曖昧であれば、その解釈も誤ったものになります。そうなれば皆さんの想像の通り「目的に遠く及ばない不要なもの」が出来上がってしまいます。

 この「目的の議論」には相当な時間を費やすことが必要です。一貫性は言うまでもなく、後に評価可能なKPIを設定しなければなりません。プロジェクト完了後の評価フェーズにおいて、KPIを達成したかどうかがプロジェクトの成績であり、成功の判断材料となるのです。終了後だけでなく、プロジェクト推進中にも目的は重要です。プロジェクトには判断の必要なシーンが多々あり、その判断軸として目的が機能します。

DXプロジェクトで陥りがちな「一度に全てを完成させる」というスコープ

 プロジェクトマネジメントの世界には「プロジェクト憲章」という文書が存在します。簡単に言うとプロジェクトを立ち上げる際の要望書みたいなものです。本来は経営者や事業責任者、IT責任者が作成し、プロジェクトマネジャーに渡すものになります。

 プロジェクト憲章の策定やプロジェクトベースライン策定で気を付けたいのが「スコープ定義」と「プロジェクト体制」です。プロジェクト体制については第3回に詳しく解説しますので、今回は「スコープ定義」について解説します。

 スコープ定義はその名の通り「プロジェクトの範囲」を定義するものです。多くのプロジェクトオーナーは一刻も早く目的を達成するため、短い納期で大きな結果を享受したいと考えます。プロジェクトマネジャーはできるだけその意思をくんだスコープ定義をします。ここに「最初のわな」が潜んでいます。著者が見てきた「頓挫したプロジェクト」のほとんどが、目的達成のために「一度に全ての範囲を完成させる」といったスコープ定義をしていました。

画像

 全ての範囲をスコープとすれば当然、現状分析や将来像を描くために相当な時間と費用を費やします。苦労して現状分析を終え、いよいよ開発だと意気込んだのもつかの間、開発会社から想定を超える多額の開発費用とスケジュールが提示される……。こうしてプロジェクトそのものが頓挫してしまうことが非常多いというのが著者の実感です。

 どんな複雑なシステムであっても必ず「幹線」が存在するというのが著者の考えです。幹線とは業務やサービスの幹であり「最悪、この幹線だけ動いていれば事業は継続できる」というメインストリームです。目的の達成にも同様に幹線が存在すると考えます。この幹線の抽出をはじめに行い、できる限りスコープを小さくすることが成功への近道となります。

 もしスコープを小さくすることができず、目的を達成できない場合には、その目的自体が「達成不可能なもの」か、もっと「ブレークダウンが必要なもの」の可能性があります。その場合は手戻りにはなりますが、目的の見直しをすべきでしょう。

「DX初心者」が取るべき手段とは?

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る