DXを加速させる新規事業をどう進めるか？事業サイドが身につけるべき能力とその理由

変化に対応するアプローチとは？

前出の2つの課題に向き合う際、「クローズド・エンドか、オープン・エンドか、という観点で捉える必要がある」としたのは、定金氏。前者は、何かしらゴールが決まっていて逆引きして考えればアプローチの仕方も分かるのが特徴で、後者はゴールが分からないのでプロセス設計がしづらいという特徴がある、と解説しました。

では、オープン・エンドの課題にどう向き合うべきなのでしょうか？　定金氏は、「仮説検証を繰り返して、世に問うしかない。あるのは仮説だけだ」とし、「DXはまさにオープン・エンドな課題として取り組むべきもの」だとし、次のように述べました。

「例えば、DXに至るまでには、アナログなプロセスを単にデジタル化しただけの『デジタイゼーション』があり、体験価値そのもののデジタル最適化としての『デジタライゼーション』があり、提供価値の変革である『DX』がある。これを写真に当てはめれば、フィルムの写真からデジカメになったのが「デジタイゼーション」、スマホが「デジタライゼーション」、Instagramのように写真そのものをコミュニケーションに使うために撮るといった体験価値自体が変革したものを「DX」と捉えることができる」。

続いて、「では、“本”のDXとはどういうことか明確に説明ができるだろうか？」と投げかけた定金氏。現在見えているのは、物理的な紙の本からデジタル化された本へ（デジタイゼーション）、そして、アプリへ（デジタライゼーション）、というところまででしょう。

では「“本”のDXは？」というと、「誰もが納得できるような正解は、現時点では想像できない。つまり、DXは『オープン・エンド』な課題に向き合うことであり、その課題の性質に合ったアプローチを取る必要がある。『オープン・エンド』な課題は、事前に明確なゴールや正解がないのだから、仮説をもとにプロダクトやサービスを作って世に問うしかなく、細かく素早く、精度の高い仮説検証サイクルを数多く回していくことが、成功の鍵となる。それを可能にするために用いられるのがアジャイル開発の手法だ」としました。

課題の性質とアプローチを間違えた場合に起こること

では、「オープン・エンドの課題」に対し、馴染みのある計画遂行型のアプローチを行なった場合、どのようなことが起こるのか？　これについて定金氏は、次の5つの“悲劇”を挙げました。

悲劇その１ _ 終わらない要件定義、肥大化する要件
ゴールが「分からない」のに、最初からガチガチに「決める」ことを要求され、「決めた」ら「変えられない」
悲劇その２ _ 失われる時間
１の結果、「使うかもしれない」機能が次々に要件定義に追加され、要件が肥大化。要件定義自体にも時間がかかるので、リリースも当然遅れる。
悲劇その３ _ 過大なコスト
過剰に作り込み過ぎて初期コストが過大に。サンクコストが膨らみ引くに引けなく…
悲劇その４ _ 実現されない顧客価値（＝仮説が外れる）
初期仮説が外れることはよくある。
悲劇その５ _サービス/システムの課題が分かったのに修正出来ない
大切なのは、仮説が外れてもすぐに新しい仮説を立てて、再び検証することであるが、初期コストが過大となりすぎていたり、システムが追加要件に柔軟に対応できない作りになっていると、再検証を回すことすらできないことがある。

これらに加え、顧客が日々変化する今日においては、その変化した要求に対応するだけで手一杯になってしまい、結果的にプロジェクトが停滞してしまうことすら想像できます。

社内外のギャップを埋めるためのスキルとは？～発注側として抑えておきたいポイント～

では、前述のような“悲劇”を起こさないために何ができるのでしょうか？

「発注する開発ベンダーに開発手法やプロジェクトの進め方を変えさせれば良いのか？　という発想があるかもしれないが、それで解決するほど簡単ではない」と、定金氏。むしろ、発注する側にこそ大きな変化とスキルの更新が求められるのがDXと向き合うということだ、と指摘しました。

では、「クローズド・エンド」な課題を解決するためのシステム開発で求められたスキルと、DXに向き合う上で求められるスキルにはどのような違いがあるのでしょうか？　整理してみましょう。

そもそも開発とは、「コト→モノの変換」であるというコンセプトに沿って求められるスキルを定義すると、「ビジネス側はTo-Beを描き、Issueを定義し、（Issueを解く）Solutionを定義するところまでを担う。一方の開発側は、Solutionを開発し、導入し、運用する役割を担う」と切り分けられます。

ビジネスやコンセプト、UXデザインやビジネスモデル、事業計画やオペレーションといった「コト」を明らかにするのはビジネス側の役割で、これを「モノ」として具現化するために開発側に要件を伝えるという“翻訳”をすることも、本来であればビジネス側の重要な役割だと言えます。

ただ、「クローズド・エンド」な課題においては「コト」の内容が想像しやすく、要件定義後の大きな変更がないこともあり、実際には「モノ」を作る開発側が仕様に落とし込んだり、システム構成を描いたりすることが一般的だったのも事実です。

しかし、オープン・エンドな課題に向き合うには、「プロセスはリニア（直線的）ではなくなり、イテレーション（反復）が求められる」と、指摘するのは木下氏です。

オープン・エンドな課題に向き合うとなった場合、以下の図のように、まずビジネス側が新サービスの提供価値の仮説を立て、提供価値を実現するUX等の仮説を立て、仮説を実現するシステム要件仮説を立て、開発側はその意向を受けて集中して開発を行ないます。サービスあるいはプロダクトを世に出した後、市場の反応を見て改善あるいはピボットする意思決定を下し、開発側は必要に応じて改善開発を行なう、というアプローチを繰り返すことになります。

クローズド・エンドな課題とは異なり、オープン・エンドな課題に取り組む際には、上図のIdeaの段階での『正解』が誰にも分からないため、具体的にどのようなものを作り上げるのか？　市場の反応を精査した中で見通される次の一手の最適解は何か？　という事柄と、それを具現化するサービスやプロダクトの仕様やシステム構成の“仮の正解”は、ビジネス側が握っており、プロジェクトの全てにおいてビジネス側が主導的な役割を担う必要がある、といえます。

これをより平易に表現するなら、「『クローズド・エンド』な課題のように開発側が“正解”を類推して行なってきたサービスやプロダクトの仕様やシステム構成への翻訳は通用しづらくなる。そのため、ビジネス側がしっかりと全体をマネジメントし、翻訳能力を身につけて開発側を動かす必要がある」ということです。前述の「発注する側にこそ大きな変化とスキルの更新が必要である」とは、こうした理由からの言葉だというわけです。

多くの担当者は、「このようなオープン・エンドな課題への取り組みをいきなり担当するのは現実的ではない。ハードルが高すぎる」と感じるものだと推察されます。

そうした時、「ビジネス側に立てる外部人材のサポートを受け、スキルトランスファーを受けながら一連の流れを一度体験してみる」というのは、今後の新規事業や新たな開発を進める際にも有用な選択肢だと言えます。

こうしたニーズに対し、電通デジタルでは、クライアント企業とで協働チームを組み、スキルトランスファーも進めながら、MVP（実用最小限の製品：Minimum Viable Product）創出までを一貫して支援する「AGILE EXPERIENCE DESIGN LAB™」というサービスを。そして、電通デジタルとCo-Liftは、「PJ併走型DXスキル研修」というサービスで前掲の「コト→モノ変換」ができる人材の育成と、MVP開発を実践的に取り組む、「併走型DXプロセス定着支援サービス」を、それぞれ提供しています。