変革プランナーにとってのDX推進の急所第5回 DXキャンバスとその使い方

DXキャンバスとは？

DX企画を検討するために何か良い方法はないかと考えたときに、真っ先に思い浮かんだのが、「ビジネスモデルキャンバス」でした。これは、世界的に著名なビジネスモデル・アドバイザーであるアレックス・オスターワルダー氏とローザンヌ大学教授のイヴ・ピニュール氏が共同で考案した、事業活動に関わるアイデア出しに活用されるフレームワークです（図1）。

具体的には9つの要素で成り立っているのですが、それらをカテゴライズすると大きく4つに分類できます。まずど真ん中に価値（Why）があり、その右側に誰に何を伝えるか（Who、What）、左側に価値をどうやって創造するか（How）があり、下側には収益インパクト（ROI）があるという構造になっているのです。

ビジネスモデルキャンバスをベースにするのがよいと考えた理由は大きく2つあります。1つは、Whyがど真ん中にあることです。再三申し上げていますが、DXというとまずHow、つまりどのデジタルテクノロジーを使うかから考え始める人が多いのです。しかしビジネスモデルキャンバスを見れば、まずWhyが重要だということを思い出しやすいのではないでしょうか。

もう1つは、しっかりROI（投資対効果）があること。ビジネスモデルですからROIがなければ話にならないのですが、DXではROIをあまりしっかり考えずに始めるケースが多いのです。これについては後述するアジャイルに関する誤解が原因だと思うのですが、そもそもDX企画ではROIを算定できないと勘違いしている人さえいます。

しかしDXもビジネスに関わる取り組みですから、ROIを考えないわけにはいきません。その上で戦略的に赤字を見込んで着手するケースもあるかもしれませんが、ROIを計算した上でなければ、どれだけ損をするかわかりませんし、うまくいかなかった場合に投資をやめる判断もできません。

さてビジネスモデルキャンバスを元に考案したDXキャンバスですが、図2の通り、構成要素は8つとなっています。ただ、大きく4つにカテゴライズされるのは、ビジネスモデルキャンバスと変わりません。比べてみてください。

アジャイルごっこになっていませんか？

ところで『DXレポート』はご存知ですよね。あのレポートの中で、DXに向いている開発手法として強調されていたものは何だったか、覚えていますか？そうです。「アジャイル開発」です。

【関連】

• 【前編】DXレポート2.1を解説。DXで企業が目指す「デジタル産業」とは？経産省が描く企業の経営課題と将来像
• 【後編】DXレポート2.1を解説。DXで企業が目指す「デジタル産業」とは？経産省が描く企業の経営課題と将来像

あれを読んで、「DX＝アジャイル開発」と思い込んでいるとしたら、少し雑だと言わざるを得ません。そもそもデジタルトランスフォーメーションにおいて、デジタルは形容詞であると考えるなら、本質はトランスフォーメーション、すなわち変革であって、変革のための手段（開発方法）は何だっていいはずです。それこそウォーターフォール型のほうが向いている開発案件もあると考えられます。

ただアジャイル開発には大きな利点があり、それがゆえにDXに向いているというのも事実です。その利点については後述しますが、その利点を得るためには正しいアジャイル開発をすることが必要です。

ところが正しいアジャイル開発ができている企業が少ないのです。ベンダー側にも正しいアジャイルと間違ったアジャイルの区別が付いていない人が多いと感じます。そこで、正しいアジャイル開発とはどんなものだったか、おさらいしてみましょう（図3）。

図3に書かれてある中で、最も重要なことは「規模は小さくてよいが、業務に利用可能な品質のものをリリースする」ということです。ここは極めて重要ですので、できれば記憶するまで読み返してください。

業務で利用できるレベルのものを迅速に開発し、何度も何度もリリースしていくのが「アジャイル」という言葉の意味なのです。すぐに改良版がリリースされるスマホのアプリなどは、まさにアジャイル開発の賜（たまもの）だと言えるでしょう。

ところが多くの企業が、アジャイル開発と称して、全然違うことをやっています。それは「スパイラル開発」です（図4）。

スパイラル開発はかなり昔から存在する開発手法で、従来のウォーターフォール開発の難点を克服するために考案されたものです。

ウォーターフォール開発では、（用語は会社によって様々ですが）要件定義、基本設計、詳細設計、プログラム製造、結合テスト、システムテスト、運用テストといったフェーズがあり、それぞれのフェーズの終わりで次に進めてよいかの確認・承認を取ります。このうち基本設計や詳細設計が文書しかないと、システム開発の専門家ではないユーザーには実際のUIがイメージできません。その結果、システムテストや運用テストに入ってから、意図したものと違うことが判明して、手戻りが発生するといったことが頻発していました。

そこでユーザーが見てわかるプロトタイプを作って、それを見てもらいながら確認して進めていく手法が提案されました。それがスパイラル開発なのです。アジャイルと似てはいますが、ウォーターフォール開発の改良版であり、どちらかと言えばウォーターフォール開発に近いものです（最終成果物ができあがるまでは納品にならないことなど）。

スパイラル開発で中間的に開発されるものは、あくまでプロトタイプであり、主な用途はUIの確認です。したがって通信環境もデータベースも本番環境とは違います。一方アジャイル開発の成果物は、本番業務としてリリースされますから、通信環境もデータベースも当然ながら本番環境のものです。

そして実際のビジネスに使われるわけですから、何らかの収益が発生するはずです。その収益を開発および運用に掛かる費用で割り算すれば、ROIも求められるわけです。一方スパイラル開発の中間成果物は何の収益も生みませんので、ROIの算出もできません。

アジャイル開発の最大の利点とは？

このようにまったく違うアジャイル開発とスパイラル開発なのですが、進め方が何となく似ているので混同されています。しかし最大の違いは、スパイラル開発は最終成果物ができあがるまでは原則やめることができませんが、アジャイル開発は都度業務利用できる成果物をリリースしているので、途中でやめることが可能だということです。

実はこの途中でやめられることが、あまり言われていませんが、アジャイル開発の最大の利点なのです。例えば機械学習モデルを使った需要予測のシステムを作っているとします。実際に業務利用しながら様子を見るという方針で、徐々に予測精度を上げていきました。そして3回目のリリースで85％の精度を達成することができました。

精度が高いのに越したことはないので、さらに開発（主に学習）を進めるという判断もありますが、ここで試算した結果、精度を85％から90％に上げるのに、これまで費やしてきた開発費用と同じだけ必要だと判明しました。さらに95％に上げるとなるともっと必要になることもわかりました。

一方収益に関しては、精度が90％でも95％でも85％の場合と大差ないこともわかりました。だとしたら85％の今が最もROIが高いことになり、ここで開発をやめるという判断もあり得るわけです。しかしスパイラル開発だと、実際の業務で利用していないので収益が読めず、仮に95％の精度が当初目標であったら目標値が出るまで、ずるずる開発が続くことになりかねません。

小さくても業務利用できる品質のものを次々リリースすること、業務利用するからROIが算出できること、ROIが都度わかるからやめる判断も的確にできること――この3つを押さえて、正しいアジャイル開発を実施してください。

DXキャンバスを作ろう！

では、DXキャンバスを実際に作ってみましょう。DXキャンバスの8つの要素には考える順番があります（図5）。

まず事業領域と提供する価値について考えます。この際に検討する要素は「提供する価値や価値の変化」と「DXの対象事業」の2つです。次に具体的な施策内容です。検討する要素は「DXテーマ」「顧客との関係や新たな体験」「DXする顧客接点や販促方法」の3つになります。3番目にどれだけの収益規模が狙えるかで、「期待される収益効果」を皮算用でいいので埋めます。4番目は、正しいチャレンジかどうかの中間確認です。「期待される収益効果」と、「提供する価値や価値の変化」「DXテーマ」「DXの対象事業」「お客との関係や新たな体験」「DXする顧客接点や販促方法」とを見比べて、挑戦すべきテーマかいったん判断します。要するにビジネスインパクトがあるかを見て、大したことがなければ、次の企画に移るわけです。

挑戦すべきテーマだと判断したら、次がいくら投資できるかで、「DXテーマへの投資規模」を考えます。通常は、「期待される収益効果」と比較して、それより小さくなるように設定します。そして最後に投資規模から調達できるリソースを考えます。

テーマとリソースおよび技術を考えてから予算を見積もる人が多いのですが、それとはほぼ真逆の考え方です。最初に提供価値を考え、それに基づいて何を誰に提供するかを考え、実現したときの収益効果を考えてから、最後に投資額とリソースや技術を決めていくのです。この考え方で検討していけば、とりあえずIoTを導入しようとか、AIを導入しようといったことから考え始めるといったことはなくなります。それよりも提供価値とビジネスインパクトを先に考えるようになるのです。

以上、作り方は説明しましたので、DXキャンバスを埋めることを読者の宿題にしたいと思います。こういうのは一度手を動かしてみるまではよく理解できませんが、やってみるといろいろと気づきがあるものです。実現可能かどうかは問いません。夢のあることを考えてみてください。

本業の改革を企画しよう

実際に企画を出さないといけない場合に、1つだけアドバイスしたいことがあります。それはできるだけ本業で考えるということです。

DXとなると、まったく新しいことを本業の周辺で企画する人が多いのです。しかし本業以外のことで大きなビジネスインパクトを生み出すことはかなり難しいことです。改革プロジェクトでは「スモールスタート、クイックサクセス」がセオリーとはいえ、インパクトが小さすぎると、その価値はなかなか認めてもらえません。そこで投資打ち切りとなる可能性が高くなります。

そこで比較的インパクトが出やすい本業ど真ん中で企画してほしいのです。成功事例の多くは、本業ど真ん中です。商社ならサプライチェーン改革、製造業なら需要予測と生産計画の連動、銀行ならリテール業務の全面的スマホアプリ化などが代表例です。

そのためには自社の本業は何か、強みはどこか、ブランド価値はどこにあるのかなどをしっかりと押さえて、それに基づいて企画することです。海外発の「ベストプラクティス」を真似するのではなく、日本発・貴社発の世界に通用するソリューションをクリエイトするのだといった意気込みで取り組んでもらうことを願う次第です。

人が欲しがるもの、未来が求めるものを作ろう

ここまで全5回にわたって、DXとはそもそもどういうものか、本質的な課題と取り組むべきテーマをどうやって見極めるか、DXは変革であるからには提供する価値を変えていくことが本質だが、そのためには何をどういう順番で考えていけばいいのか、といったことを説明してきました。

最後に一番伝えたかったことをお話しして、この連載を終わりたいと思います。

まずは次のグラフを見てください（図6）。

このグラフからわかることは、1995年から2014年の20年間にかけて、日本ではIT産業だけが儲かったということです。別にIT産業各社が何かずるいことをしていたわけではありません。この20年間、IT投資は盛んに行われてきたが、その効果が出ていないということが言いたいのです。一方でアメリカでは、同じ期間にあらゆる産業が儲けを増やしています。

もちろんベンダー側にも責任がないとは言えません。最適なソリューションが提供できていないから結果が出ていないという見方もできます。ただ落ち着いて考えてみてください。日本のIT産業がこの期間に提供してきたソリューションのほとんどは、海外、特にアメリカ製のものばかりです。つまりアメリカ企業も日本企業と同じソリューションを使ってきたわけです。そしてアメリカ企業はそれらを使って成長し、日本企業は停滞しているということなのです。

日本企業には、ITやデジタルの使い方に問題があると考えざるを得ません。それを大きく変えていかないといけないのではないでしょうか。大きく変えるというのは、まさしく変革です。日本企業には変革が必要なのです。

中部地方だけでなく、日本は全体的に中小規模の製造業が多い国です。そのためかDXと言ってもIoTやデバイス関係などハードウェアの話に向かいがちだと、この連載の冒頭でも指摘しました。だから「あえてテクノロジーの話をしない」ことにしたのでした。

連載の最後で、このことをもう一度指摘します。そして「もっとソフトウェアに寄せよう」と言わせてください。ここで言うソフトウェアとは、アプリケーションだけでなく、データや人の持つノウハウ、そして人間自体も含んだものです。

例えば、世界的に有名なソフトウェア開発者・投資家であるマーク・アンドリーセンは、2011年に「ソフトウェアが世界を飲み込んでいく」と発言しています。また世界で最も有名なスタートアップ投資企業Yコンビネータの創始者たちは「人が欲しがるものを作れ」、「未来に生き、未来に欠けているものを作れ」と言っています。

こうしたトレンドから考えると、「現在における課題を解決するための社内向きテーマにハードウェア志向で取り組む」ことは最悪の選択だと言えるでしょう。しかしそのようなDXの取り組みが日本では多いのが現実なのです。

この機会に発想を変えて、「顧客と社会の未来の課題をソフトウェアで解決する」取り組みを始めませんか？もし貴社が今伸び悩んでいるのであれば、そうすることで何かが大きく開けると、私は確信しています。