DXのロードマップの作り方

DXは小さく始めるべきか、大きな絵を描くべきか


前回はDXのTOBE像を構築するためのヒントを考えてみました。


custle.hatenablog.com



今回はTOBE像構築後のそこに至るためのロードマップの作成について検討してみたいと思います。


その前に、AI導入ではスモールスタートで小さな成功を積み重ねる方が最終的に近道であるという意見を耳にすることがあります。


DXも同じようにまずは小さな成功を重ねていくやり方が良いのでしょうか。


実現できるかどうかわからない大きなTOBEを描いてしまうと、途中でプロジェクトが頓挫してしまう可能性が高くなるのでしょうか。


結論としてはある意味どちらも正解だろうと思います。


ただ、DXの場合はAIのようにシステムのいち機能だけでなく、業務システム全体や広範囲に影響を及ぼすことが多いので、スモールスタートがしにくい面もあるかと思います。


特にシステムの導入や改修となると高額な予算や時間も必要となります。


最初からそうした部分も計画に盛り込んでおかないと、途中で気づいてなんとかしようとしてもなんとかなる可能性は非常に低いです。(私も実際経験しました)


DXのロードマップの作り方


f:id:custle:20200721203025j:plain
oldtakasuさんによる写真ACからの写真


DXの実現方法は最終的にシステム導入や改修になることが多いので、ロードマップ作成もシステム開発につながるようなものになります。


そのため一般的なシステム開発時の流れとそれほど差がないかと思います。


ざっくりいうと、まずは業務要件を定義してそこからシステム要件に落とし込み実現方法を設計し、開発・テストと進んでいきます。


業務要件の定義は、まずTOBEを元に大きな粒度での業務フローを設計し、そこから現場レベルでの業務フローとデータの流れを確認しながら詳細設計に落とし込んでいくことになると思うので、結構大変です。


さらにこれまでに経験のない全く新しい業務などがある場合は、後で想定外や考慮漏れのプロセス等が発生する可能性も高くなるので、最初に手運用もしくはプロトタイプシステムでのPoCなどを実施して業務要件のチェックをしてみるのも必要かと思います。


一部の業界・業種では結構前から業務パッケージの開発・販売がなされており、ある程度業務フローもテンプレートが用意されているので、そうしたものをベースにするのもありかもしれません。こうした業務パッケージの開発は今後さらに進むかもしれませんね。


次のシステム要件をまとめる段階では、既存システムの扱いをどうするかも悩みどころでしょう。


新しい業務要件が既存システムで一部カバー可能なら、丸ごとリプレースではなく、既存システムの一部継続利用も考えられます。


ただし、一部継続利用するならば新しく必要な機能をどう実装するのか、インターフェースやデータなどの連携をどうするか、既存業務に影響が出ないようにするにはどうすればよいかなど、なるべくコストがかからないやり方とリスク面の両方を踏まえて検討する必要があります。


プロジェクト体制も、DX推進を任された担当者だけでなく、対象業務の現場の担当者からシステム担当者など多くの人を巻き込んで歩調を合わせて進める必要があります。


場合によっては外部のコンサルやベンダーも関わるでしょうし、少なくとも数十人の規模にはなるのではないでしょうか。


以上のことを考慮して、DXシステムの導入計画、もといDXのロードマップを作り上げる必要があります。


さらにもちろんシステム導入「後」の運用やリスクと期待効果などについても事前に考えておかなければ、稟議は通らないでしょう。


プロジェクトを失敗させないためには


私の経験した失敗事例です。↓

・TOBEやロードマップがないままプロジェクトが開始され、現場担当者間では何をすべきかまとまらず時間切れ。


・TOBEやロードマップがないままプロジェクトが開始され、一部の業務でそれらを整理してPoCまでは成功しつつも、予定にないシステム予算の追加や既存システム改修が認められなくて断念。


繰り返しますがDXでは大体のところシステム開発や改修といった落としどころになると思われますので、AIやデータ活用といったキーワードを伴うからといってデータサイエンティストやデータアナリストだけで進めるのはおそらく厳しいでしょう。


またDXのようにゴールイメージがあいまいなものは、プロジェクトを見切り発車させずに、時間がかかっても最初にTOBEとロードマップを備えるのはやはり必要でしょう。


その際にもなるべくなら現場の業務担当者やシステム開発プロジェクトの知見のある人たちにも加わってもらった方が良いと思います。


さらにシステム導入まで含めると時間も人手もそれなりに必要なので、そのための体制・予算・スケジュールもあらかじめ確保しておく必要があるでしょう。こうした準備体制を整えておくのもプロジェクト成功のためには非常に重要だと思います。


スモールスタートのDX


DXを進めるに当たって、全ての業務をデジタル化するとか、現在のシステム基盤をデジタル化のために全て刷新するとなると、どれだけ時間や費用がかかるだろうかと途方に暮れてしまうかもしれません。


冒頭でも述べましたが、まずは身近なところでできそうなことからやってみるという考えも間違いではありません。


幸いにもDXは定義こそありますが、具体的でなく拡大解釈が可能なので、これがDXだ!と言い切れば通じると言えなくもありません。(AIも同じかも。。)


業務の一部のみシステム化を行ったり、新たにちょっとしたスマホアプリを開発したり、とりあえず何らかの形ある実績作りを優先してスモールスタートさせることも可能です。


AI導入のケースでいうと、多くはAIによって何かを変えようというよりむしろ「AI導入そのものが目的」であったりします。(PRになるので)


であれば小さく始めた方が成功しやすいのは自明です。それに小さなプロジェクトであってもAI導入の実績ができれば、それを元に周りの人々が感じているAIの敷居の高さや苦手意識を払拭させて、より広められやすくなる土壌も醸成できるようになるかもしれません。


DXも同じようにまずは小さくても実績を作ることを優先するやり方もあります。


ただし、TOBE像とロードマップがないとそれで終わってしまってそれきり続かないということも珍しくありません。


途中で目的がすり替わるパターン(DX推進がいつの間にかアプリユーザ何万人を目指そう!とか)も見たことがあります。


ロードマップの終着点はなるべくブレないようにはしたいですね。


DXシリーズは次回でひとまず最後となります。


custle.hatenablog.com