papanda 私が「デジタルトランスフォーメーション(DX)」という言葉に込める内容は、本来の定義とは少し異なるのかもしれない。私は、(1)技術 (2)プロセス (3)チーム (4)システム・プロダクト (5)ビジネス いずれかの領域もしくはすべておいて、これまでの在り方を変えていく標語として使っている。技術、プロセス、チームの在り方が変わることで、プロダクト作りをアジャイルにすることができる。アジャイルなプロダクト作りによって、状況に適応した、人々に必要とされるプロダクトやシステムに近づくことができる。そうしたプロダクトが新たなビジネス、事業を駆動する力になる。この5つの領域はそれぞれに繋がりがあるということだ。
こうしたプロダクト、事業づくりを行うためには、チームの育成が要になる。プロダクトの価値は、Problem-Solution-fit(PSfit)の度合いによって評価されるが、その検証とともにProduct-Team-fitができているかも問われる。すなわち、取り組んでいるプロダクトの開発に適したチーム構成(役割と専門性)、マインドセットとなっているかどうかだ。たとえ、PSfitしている構想だとしても、チームがそのプロダクト開発についていけてなければ、やがて行き詰まってしまうだろう。
DXの文脈で企業内で何を優先して構築するのか？は意見が分かれるところだろうが、私はDXに挑めるチーム、人材を整えていけるかどうかが最も問われるところだと考えている。新たなビジネスのために何らかのMVPを作り上げたところで、そのビジネスを本当に立ち上げられるかは高い不確実性がつきまとう。一発一発のMVPに賭けるような進め方ではなく、仮説検証とMVP作りを対応できるようなチーム作りを優先したい。肝いりのプロダクトに関する市場からの評価がたとえ散々なものであっても、適応力のあるチームがあればそこから学び、次のプロダクト作りに繋げることができる。
DXの取り組みを難しくするのは、そうしたチーム、人材の理想像と、現状のイマココとの間に大きな開きがあるところだ。DXを必要とする組織のチーム、開発部門は、それまでの主任務であるSoRの開発に最適化した人材構成になっていることが多い。SoRを適切にモダナイゼーションする取り組みを継続していれば良いが、そうした状況にあるのは稀だろう。構築時の技術のまま、アジリティの低い開発プロセスで開発を繰り返し、現状維持を第一と置く、その在り方に最適化してしまっている状態がDXをより難しくさせる。
ゆえに、チーム作りファーストでDXのプランニングを行いたいところだが、何をつくるのか？という点が課題になる。既存のSoRの文脈で、モダンな技術、アジャイルなプロセスに臨むのには困難を伴うだろう。既存の仕組み、システムがこれまで醸成してきたしがらみに足を取られ、一歩も進められなくなってしまいかねない（というか、そのような状況のためにDXが求められるわけなのだから）。既存との文脈から切り離して、スタートを切る必要がある。そのために、最初の一歩はSoEを題材とした小さなプロジェクトに置きたい。
DXが必要な組織ではSoEがほぼ育ってないということが珍しくない。それはつまり、エンドユーザー接点においてやるべきことが山積しているということだ。いくらでも構想が練れるはずだ。ただし、ポイントは既存の文脈との距離感。つまり、最初期においてはSoRとの連動をほぼゼロに置きたい。少なくとも最小限のデータ連携にとどめたい。
DXとはこれまでの在り方を越えていく「越境」にほかならないが、アプローチはむしろ「分断」が要となるというのは皮肉にも聞こえる。だが、DXとは変革に他ならない。20年、30年蓄積してきたことを一気に一新するというのは日本の多くの企業においては現実として不可能に近い。そのアプローチは段階になる。ただし、目的地が見えない当てのないプランニングではない。到達したい場所を見据えながら、その過程を動的に組み替えていく旅路（ジャーニー）のようでありたい。どのような段階を置くか。段階の設計と、それを関係者で共通理解にすることが、DXの出発点である。
こうした旅路はSoEの文脈だけを突き進めば良いというものではなく、やがてより価値を出すために、これまでの資産を活かすために、SoRへとたどり着く。どのようにして、SoRのモダナイゼーションに取り組むかという境地に必ず達する。ここからが本丸になるわけだが、それまでにチームがどれだけ練度を高められているかが鍵になる。
(Photo on VisualHunt)
