Google、Amazon、Facebook、Appleといった、いわゆる「GAFA」に代表されるような「デジタル技術を駆使した企業の一人勝ち」や、新型コロナウィルス、働き方改革、SDGsといった社会的な様々な出来事が重なって、日本企業の中でも「デジタルトランスフォーメーション(以下DX)」へのニーズが高まっています。
この記事をお読みになっている皆様の企業でも「うちの会社もDXだ！！」「DXのプロジェクトをやるぞ！！」といった話題が上がっていることも多くなっているかと思います。
しかし、「DXプロジェクト」をこれまでの「ITプロジェクト」などと一緒に考えて取り組んでしまうと、思ったような成果が得られないということが起こり得ます。
なぜなら、DXプロジェクトというものは、「正解がない」「実績がない」「全社的な協力がないと進まない」という、これまでのITプロジェクトとは違った特徴を持っているからです。
今回は、そうした「DXプロジェクト」ならではの特徴を、従来のITプロジェクトと比較しながら、事業会社の方が「DXを企画・発注」したりする場合の参考にして頂けるように解説していきたいと思います。
特徴その１「業務要件という正解がない」
通常、ITプロジェクトというものには「要件」や「要望」というものが付きまといます。
これは、システム開発を請け負うITベンダーなどの企業が、ユーザー側(発注側)の企業に対して、「どのようなシステムを作りたいのですか？」という「目的」や「目標」を出してもらい、システム開発に取り組んでいく、というものです。
出来上がったシステムを使ってみると、「思っていたシステムと違った」とか「機能は色々あるけど、ほとんど使いこなせない」といったことがよくありがちです。
なぜこうしたことが起こるかと言えば、もちろんベンダー側の開発能力が期待値よりも低かった等の理由もありますが、発注側が「こういう機能を持って、こういう課題を解決できるシステムを作ってほしい！」と明確に依頼をすることをせずに、ベンダーにほとんど「丸投げ」してしまうがために、「イメージと違った」システムが生まれてしまうことが、日本企業の特徴であり欠点だ、ということが様々なところで指摘されています。
したがって、通常のITプロジェクトでは、開発前の「要件定義」の質によって、成果物の「質」も大きく左右される、ということになります。
一方、「DXプロジェクト」についてはどうでしょうか。
そもそも、「なぜDXをしたいのですか？」「DXをしてなにを実現したいのですか？」という問いに明確に答えられる企業や担当者はほとんどいないのではないかと思います。
でも、「DXをやらなければならない」という状況に立たされています。
つまり、発注側が「何がしたいか」「何ができるか」「どんな成果物を期待するか」といったことを明確に定めることができないため、ITベンダーやコンサルティング企業も通常のITプロジェクトのような「要件定義」ができない、ということになります。
これが、通常のITプロジェクトとDXプロジェクトの大きな違いです。
通常のITプロジェクトでは、「要件定義」をしっかりと行うことができれば、期待値に近いシステムを開発できる確率は上がります。
しかし、DXプロジェクトにおいてはシステム開発の前提となる「要件定義」が非常に難しいため、手探りで「仮説」を決めて、「まずシステムやサービスを作ってみて反応をみる」しかありません。
もちろん通常のITプロジェクトであっても「一発で完璧なシステムを作り上げる」ということは難しいことではありますが、DXプロジェクトにおいては「最初から正解にたどり着く」ということはほぼ不可能に近い、ということになります。
ですので、発注側の企業としては、「最初から完璧を求めない」「数年間赤字が出ても耐える覚悟」というスタンスが重要になりますし、弊社のような協力企業にとっては、「ユーザーと一緒に要求や要件を決めていく」という姿勢がとても大切になります。
これまでのように、発注側がITベンダー等に「発注しますのですべてお任せします」「お金を出しているのだから納期を厳守してください」というスタンスでは、成功する可能性がほぼゼロに等しい、ということはぜひ念頭に置いて入れて頂ければと思います。
特徴その２ 「採用技術に実績がない」
DXプロジェクトでは多くの場合、AIやIoT(Internet of Things)などの新しい技術を利用します。
このため、「当初の想定よりも精度が出ない」「データが思うように集まらない」などのリスクが生まれやすくなります。
これまでのITプロジェクトや、特に「基幹系システム」と呼ばれるようなシステムの導入などの場合には、過去に実績を積んでいるシステムを採用する場合が多いと思います。
したがって、システム導入の流れや、導入後の使い方などのイメージ、コスト算出などもしやすい面があります。
しかし、DXプロジェクトにおいては「これまでほとんど実績のない技術の採用」や「様々なチャネル・デバイスから収集されたデータの活用」といったことが必須になってきます。
特に「AI開発」などが絡んでくる場合においては、「データを持っている部署や関連会社が、なかなかデータを提供してくれない」ですとか、「手持ちのデータを機械学習にかけてみたけど思うような精度が出ず、コインを投げて結果を決めるのと変わらない」といったことが起こりがちです。
このように、「これまでの実績がない技術」「導入してみないとどんな成果が出るか分からない技術」「活用したいデータに価値があるのかは、やってみないと分からない」という、不確実性が非常に高いため、スムーズにプロジェクトが進むことのほうが珍しい、と捉えたほうがよいでしょう。
ですので、「手戻りが発生する」ということを前提としていプロジェクトを進める必要があり、「PoC（概念実証）」のようなアプローチも大切になります。
したがって、「DXプロジェクト」のスケジュールは、あまりタイトに設定せずに、ある程度の余裕を持たせて進めていくほうがよいでしょう。
経営者や発注責任者にそうした理解がなければ、「とにかく早く、早く」となりがちです。
「とりあえずDXをやりました！」という実績を作りたいのであればそれでも良いかもしれませんが、競合他社をダントツで引き離すような「真のDX」をやるためには、「目先のスケジュールや利益に捉われない」という大局的な姿勢も大切です。
特徴その３ 単独の部署だけでは完結できない
これまでのITプロジェクトでは、成果物を活用する部署は基本的には「1つ」という前提で設計され、運用されてきました。
例えば、「生産・物流・購買」といったプロセスを管理したいのであれば「SCM(Supply Chain Management)」、顧客との関係を継続的に築いていくために導入するシステムとしては「CRM(Customer Relationship Management)」といったシステムがあります。
前者は「購買・物流」といった部門でメインとして使われ、後者は「マーケティング」を行う部門で使われることを前提としています。
したがって、「部門間を超えてシステムを活用する・データを共有する」といったことは基本的には考慮されておらず、多くの企業ではバラバラな基盤や保守体制で運用されており、システムの改修やデータの統合は非常に大掛かりな作業になりがちです。
一方、DXについては「新しいビジネスやサービスを生み出す」というプロジェクトになるため、ユーザー企業の1つの部署だけで完結できる場合が少なく、複数の部署が連携して取り組んでいく必要があります。
プロジェクトの内容にもよりますが、「経営企画」「マーケティング」「各事業部」「IT部門」といったあたりの部署が関係してDXプロジェクトに取り組む例が多いようです。
通常のITプロジェクトですら、色々な関係者が色々なことを言うため、なかなか思うように進まないといったことがありがちです。
DXプロジェクトにおいては、大企業であれば相当な人数の社員や協力会社の人材がプロジェクトに関わることから、これらの意見や意向をまとめて方向性を決めていくことは並大抵のことではないことがお分かり頂けるかと思います。
そのため、プロジェクトを請け負ったITベンダーやコンサルティング企業は、ユーザー側に組織横断的なチームを作ることを提案したり、社長や役員が直接意思決定する枠組みを作ってもらうなどの工夫が必要です。
DXプロジェクトは前述のように、手戻りが発生するなどして「進捗状況」が見えづらくなる場合もありますので、部門責任者同士のマメなコミュニケーションや、プロジェクトの「見える化」の仕組みなどの設計も大切になります。
まとめ 「DXはどっしり構える」
今回は、「DXと通常のITプロジェクトの3つの違い」として、
● 業務要件という正解がない
● 採用技術に実績がない
● 単独の部署だけでは完結できない
というDXプロジェクトならではの特徴を簡単にご紹介致しました。
「DXをやりたい！」と思ったとき、ユーザー企業がベンター等に発注する場合の注意点としては、
・「丸投げ」ではなく自分たちがリーダーシップを持って進める(自分のビジネス！)
・当初の要件通りには進まない可能性が高い(頭を柔軟に！)
・スケジュールには余裕を持って取り組む(バタバタしない！)
・数年赤字が続いたとしても将来を信じて耐えぬく(ビジョンを持つ！！)
といったことが大切になります。
ぜひ私たちと共に「真のDX」を目指していきませんか？
今回も最後までお読みいただきありがとうございました。
