この研修には何の意味がある？ 修了後の見通しを持つための『DXスキルツリー』
DX人材育成が難しいのは、DXの全体像が分かりづらいから
DX人材が足りない。もう何年もそういう声を聞き続けています。一方で、研修プログラムを受けた人材が、そのスキルをうまく活用できていないという話もよく聞きます。これって少しおかしいですよね。足りないんだったら、育成した人はなぜすぐ不足を埋められないのでしょうか。
個人的な感覚ですが、DXの進め方が分からないのがその原因だと思っています。どんな人材が、どういうタイミングで、どんな役割を果たすのか。その共通認識がないままスキルだけを身に着けても、実戦で混乱するのは目に見えています。
DXの人材とスキルを整理した資料は多数出ているのですが、実はその人材がいつどういう役割を果たすのか、全体像が書かれているものは多くありません。特に (DX専任ではない) ビジネス側の人が何をすればいいのかは明確に定義されないまま、リテラシーを高めるような記載が多いと思います。その辺りの理解度を深め、DX活動の解像度を上げることが重要なのではないでしょうか。
DXの流れと人材を網羅している「DXスキルツリー」
残念ながらひっそりと公開されている「DXスキルツリー*」は、その辺りの問題を強く意識して作られたフレームワークです。こちらの解説記事に詳しいので、ここでは簡単に紹介しましょう。
まず重要なのは、DXの流れです。まず、大枠でどんな問題に取り組むべきかを決定します。このとき、経営陣に設定された経営課題と、現場から上がってきた現場課題との交点を選択することが重要です。というのも、現場課題であっても経営課題でなければ、それは会社にとって些事なので人員や予算を割く訳にはいきません。逆に経営課題であっても現場課題でなければ、抽象論を具体化する際に何かを間違えてすれ違ってしまったか、あるいは経営課題が机上の空論だったか、いずれにせようまく実装し運用するのは難しいでしょう。
さてそうやって決められたイシューに関して、より具体的に何を解決するのか構想します。問題を掘り下げ、それを解決できそうな技術を探してきて、だいたいこんな感じで行けそうだという案を作成するのが構想ステージです。
次が最も抜け落ちがちなステップです。DXで何より意識しないといけないのは、そのDXがうまくいったら嬉しいのかどうかです。成功しても誰も喜ばないような活動に時間とお金を掛けるのがナンセンスだというのはあまりにも自明ですが、実際にはDXが目的化してしまい、システムが構築されたにも関わらず誰も使わないようなケースを耳にします。したがってこの価値PoCステージでは、成功したときに誰がどう嬉しいのかを検証すると共に、この早い段階でオーナーシップを持って牽引する人に参画してもらわないといけません。DXのような、抽象度が高く自由度の大きい活動では、How以前の、WhyとWhatを決められる人が最も重要な役割を果たすからです。ここは後で少し補足します。
その次のステップで、ようやくITの専門家が本格的に動員されます。データサイエンティストやITのエンジニアが活躍するのは、この技術PoCステージです。通常はアジャイルに、初歩的な分析や簡単なアプリを作ってみながら、構想ステージと価値PoCステージで要請されるものが本当に作れそうなのかを確かめます。
こうして、経営課題と現場課題の両方を満たし、技術的に可能で、成功した際に誰がどう価値を感じるのか検証されたアイデアが出来上がり、その後に本格的なシステム開発が行われる流れになります。この開発ステージは従来の情報システムと大きな差異はありません。アジャイルの方が生産性は高いですが、契約の関係でウォーターフォールが好まれることも多いです。
DX専任チームからすると、システムが完成したら終わった気持ちになるかもしれません。しかし、こうしてビジネスモデルやプロセスが変更され、システム開発が終わってからがビジネスの始まりです。これも従来の業務システムと同様に、ビジネス側とIT側で連携する運用ステージになります。ただしビジネスに深く根差したDXの場合、頻繁に機能を改廃するDevOpsや、機械学習のモデルを随時更新するMLOpsが有効なことも多いです。これらの必要性を判断するためにも短いサイクルでのパフォーマンス評価は欠かせません。
この流れを読んだとき、おそらくは想像していたよりIT色が薄いのではないでしょうか。それが重要なことです。DXはデジタルでビジネスを変革することですので、主役はビジネスです。将来のビジネスにデジタルが深く関わるほど変革の度合いは大きくなりますが、それでも主客逆転することはありません。仮にデジタルでビジネスの姿が大きく変わることがあっても、あくまで目的はビジネスを良くすることだからです。
DXに必要なプロダクトマネジメントという思考法
さて本稿ではこれ以上の各論に踏み込むことはしませんが、ひとつだけ重要なことをお伝えしておきます。それは、「プロダクトマネジメント」という考え方です。
プロダクトマネジメントとよく似た言葉で「プロジェクトマネジメント」があります。プロジェクトとは、定常業務に対比される概念で、固有かつ有期の仕事のことです。このプロジェクトを成功に導くための様々な考え方や活動のことをプロジェクトマネジメントと呼びます。近年は多くの仕事がプロジェクト化していると言われ、その重要性は皆さんご存じのことでしょう。
ここでのポイントは、通常のプロジェクトマネジメントには、目的の設定は含まれないということです。プロジェクトマネジャーは目的を達成するために何をすればいいか、総合的な視点で物事を考えますが、なぜこのプロジェクトが必要か、最終的に何を成し遂げたいかということを決める権限を持ちません。ファシリテーションなどを通じて関係者の認識を合わせる役割です。
ではプロジェクトがなぜ必要なのか。そのプロジェクトから何を得たいのか。どこから先は求めないのか。これらを考える立場を、これまではプロジェクトオーナーと呼んでいたと思います。もちろんそれでも構わないのですが、オーナーというと、どっしり構えた受け身な役割を想像しないでしょうか？ DXスキルツリーではその役割を、製品開発のトップであるプロダクトマネジャーと重ねて考えています。『INSPIRED』という本に詳しいですが、プロダクトマネジャーとは方向性を考え決断する役割です。しばしば「ミニCEO」と称されると言えばイメージが湧くでしょうか。
この、プロダクトマネジメントという考え方こそがDXに有用だと思っています。DXとは変革活動ですが、そのアウトプットは (ITを伴った) 新しいビジネスモデル、ビジネスプロセスなどです。これらを広義のプロダクトと解釈したときに、プロダクトマネジメントが効果的だろうと考えている、という意味です。
おまけ： DXボードゲーム『ころがせ！DX』
このDXスキルツリーにヒントを得てデザインされたボードゲームが株式会社インフォバーン様から発表されているのをご存じでしょうか。『ころがせ！DX』と題されたこのゲームは、構想ステージ・価値PoCステージ・技術PoCステージを繰り返しながら成果を創出していくというものです。かなり簡略化されているとはいえ、ここまで述べてきたDXの流れをイメージができるかもしれません。DXは抽象度の高い活動ですので、様々な試みで理解を深めるのは有効だと思っています。
*DXスキルツリーはクリエイティブ・コモンズの下で公開されています。 CC-BY 4.0 by Tetsu Isomura, Takayuki Nakamichi, Yu Ito, Risa Nishiyama
この記事が気に入ったらサポートをしてみませんか？