プロジェクトをしこうさくご 仕事をしこうさくご

失敗事例に学ぶ、DXを成功に導くプロジェクト推進戦略とは?(2/3)

2020年11月16日

本記事は、400社以上のDXやデジタル推進のご支援をされている株式会社スタンダード 代表取締役CTO・共同創業者 鶴岡友也氏によるセミナーを、全3回の連載でご紹介しています。

同社がこれまで獲得してきたノウハウを基にしたDXプロジェクトの進め方のベストプラクティスを体系的に知ることができる内容となっています。

前回の記事では、DXが必要な理由について説明しました。
第2回目となる今回は実際にどうプロジェクトを行っていけば良いのかを紹介していきます。

株式会社スタンダード
代表取締役CTO・共同創業者 鶴岡友也 氏

【プロフィール】(取材当時)
大学ではコンピュータサイエンスを専攻。在籍中から、AIエンジニアのフリーランスとして複数の開発案件に携わる。複数の立ち上げ初期スタートアップで事業開発に従事し、0→1の立ち上げ経験を積む。東大人工知能開発団体HAIT Labの運営を通じながら、株式会社STANDARDの共同創業に至る。

DXプロジェクトの失敗パターン

DXプロジェクトの全体像を見ると、プロジェクトは三つのステップから構成されているとお伝えしました。

一つ目のステップはプロジェクト企画。
どんな課題を解決するのか、どのように解決するのかを決めていくステップです。

二つ目のステップはPoCです。
PoCとはProof of Conceptの略、日本語では実証実験のような感じで呼ばれています。想定できるリスクや不確実性を、最小限のコストで検証するためのステップです。

三つ目のステップは、ビジネスに適用するために、本格的にシステム開発をしていくステップになります。

このステップの中でも、我々は400社以上のDXプロジェクトを見てきた経験から、失敗パターンを3つに分類しています。

失敗パターン1:アイデアの質が低い

一つ目は、アイデアの質が低いというパターンです。

これは、そもそも誰のどんな課題を解決すべきなのかが具体的ではなく、ふわっとしたままにしているケースです。
解決すべき課題も発見できてない場合、課題は洗い出せているが質の高い解決策になっていない場合、最低限のリソースで解決すべき課題を必要十分に解決できてない場合など、なんとなくプロジェクトはできているが、その課題が本当に収益にインパクトがあるのか考えきれておらず、ROIに結びつかないアイデアになってしまっているパターンです。

失敗パターン2:人を巻き込むのが難しい

二つ目は、人を巻き込むのが難しいというパターンです。

1部門で DX を推進するのは、相当難しいため、そもそも全社で取り組まないといけません。
そうなっていない場合や、現場業務が忙しいなどの理由で、実際の現場でDXの取り組みの優先順位が下げられてしまい、なかなか思うようにプロジェクトが進んで行かない場合だったり、ミーティングをしながらDXを進めようとしても、前提知識にすごい差があって全く議論が噛み合わない場合が、この人を巻き込むのは難しいというパターンです。

失敗パターン3:PoCや開発のマネジメントができない

三つ目は、PoCや開発のマネジメントができないというパターンです。

PoCに限らず、本開発のマネジメントなども、何かを依頼したくてもどういう風にすればよいのかわからない場合であったり、PoCを実施したものの成功の基準がなく、本開発の投資が判断できずにPoCで終わってしまう場合だったり、システムを作ったはいいものの、ビジネス適用されず、運用に繋げられないみたいな場合が、このPocや開発のマネジメントがままならないというパターンに当てはまります。

この三つの失敗原因を、事前にしっかりと対策しながらプロジェクトを進めていくことで、成功の確率を飛躍的に向上させることができると考えています。

失敗パターンを事前に潰すことが重要

三つの課題の中でも特に重要なのが、アイデアの質が低いという問題です。

一番最初のステップで起こる問題のため、ここで躓いて、質が低い状態のまま進んでしまうと、その後が全く成果に繋がらない活動になってしまうため、しっかりと注力していくべきポイントになります。

質の高いDXプロジェクトとは、解決すべき度合い(想定する投資対効果が高いか)と、決策の質の2軸でマッピングした際、このどちらもが高いプロジェクトとのことです。

解決すべき度合いとは、課題を解決した時にどのぐらいの効果とかインパクトを与えられるのかといった度合いと、言い換えることができます。解決すれば多くの利益に繋がるような課題は、解決すべき度合が高いと言えるため、これを定量化して考えることが重要になります。

解決策の質とは、最低限のリソースで解決すべき課題を必要十分に解決しているか、ということです。質が低くなるパターンとしては、技術がマッチしてないことや、他社事例をそのまま真似してしまうようなパターンがあげられるので、このようなパターンに陥らず、どのようにしたら最低限のリソースで、解決すべき課題を必要十分に解決できるのか、しっかりと見定めていくことが必要です。

DXプロジェクト企画はみんなで進めるべき

では実際に、DX全体の一つ目であるプロジェクト企画をどうやって進めていけばいいのかを話していきたいと思います。

課題発見フェイズの進め方

プロジェクト企画には、課題発見フェイズと解決策フェイズの2つのフェイズがあります。
その中で課題発見フェイズは、課題の洗い出しや絞り込みを行っていくフェイズになります。

ご存知の方も多いと思うのですが、課題を見つけるための考え方のベースとして、課題とはあるべき姿想像と現状のギャップのことです。

課題が中々出てこないというのは、理想が見つけられないか、理想が正しくないか、現状の認識がずれているかの、大きく三つパターンがあるので、自分たちがどの状況なのかを話し合いながら、正確に自己認識をしていき、理想が見つけられなかったり、理想が正しくない場合であれば、正しいあるべき姿を想像・定義することから始めていきます。

現状の認識がずれている場合は、人によってずれてることが多いので、定量的なものをベースに現状認識を揃えていくことから始めていくと課題を見つけやすくなります。

ロジックツリーのような、木を使いながら課題を切り分けていったり、後はやはり一人で出せるアイデアは限界があるので、メンバーを集めながらグループワークで進めていくのも良いですね。

課題を洗い出したら、実際に課題を絞り込んでいきます。

緊急と重要という二軸で絞り込んでいく方法もありますし、課題を定量化していくことで、数字順にどれぐらいインパクトが高いのかを出してから、課題の絞込みをしていくこともあります。

解決策フェイズの進め方

次に、プロジェクト企画の解決策フェイズです。

先ほどお話しした通り、質が低くなるパターンとして、技術がマッチしていないことや、他社事例をそのままマネしてしている、二つのパターンがあるので、本質に立ち返って考えていく必要があります。

どうやって解決策を選んでいけばいいのか、とよく聞かれますが、最低限のリソースで必要十分に解決することを目的に考えているので、より簡単な解決策から順に検討していくことが重要になってきます。

まず一つ目に検討するのは、ITを使わずにルールやオペレーションで変えることで解決できないかという視点です。業務プロセスを見直したり、人事配置を変えたり、コミュニケーションを改善することで解決できないか考えていきます。

それが無理なら、ITツールやSaaSで解決できないかを考えていきます。
そして、最後に検討するのが、独自開発です。

稼働しているシステムの改善や機能追加を検討していくこともありますし、ゼロベースで理想的なシステムの開発をしていくこともあります。

後者になるにつれて、難易度が上がっていくため、より簡単でシンプルな解決策を選ぶことが成功のポイントになってきます。

洗い出す中で、再度解決策を考えたり、評価もQCDのようなフレームワークを使ったり、どのような軸を最重要視していくのか、みんなで議論しながら進めていくことが、解決策の評価につながっていきます。

どの軸を重要視するのかという基準を、社内で揃えることが大切になので、ここでしっかりと議論を深めていきます。

多産多死スタイルがDXの大前提

DX全体の二つ目であるPoCの進め方を説明します。

不確実性の高い、攻めのIT活用にはPoCが効果的

まずこのPoCとは何か、について説明します。

デジタル技術がどんどん進化していき、売上高や利益を上げていく攻めの IT 活用が多くなってきました。

今までIT活用は、システムツールのように守りのシーンが多かったと思うのですが、逆に攻めのITは、大きな成果を上げる可能性がある一方で、技術的な問題でプロジェクトが失敗したり、投資対効果が得られないリスクが存在するため、いきなり本開発に進むのではなく想定できるリスクをしっかりと最小限のコストで検証することが必要です。

このプロセスがPoCというものです。ですので、不確実性が高くないプロジェクトであればPoCはなくても大丈夫です。しかし、攻めのIT活用となると、どうしても不確実性が高くなってしまうため、その場合は必然的にやらなくてはいけないものになります。

ただし、システム開発や AI 開発は、実際にある程度作ってみないと、精度がわからないというリスクはあります。

これは例としよく話してるのですが、一般的にPoCの成功確率は20%と言われており、これを念頭に置きながらプロジェクトを進めることが必要です。20%ということは、同時に5つのプロジェクトを走らせて、やっと一つが成功するかどうかになります。

いわゆる多産多死スタイルで進めるのがPoCだと、社内できちんと共通認識を取る必要があります。そうしないと一つ失敗しただけで、社内から反対の声が上がったり、追加投資のストップが起こる事態になってしまうからです。

ですので、そもそも多産多死スタイルで成果を出すためには、一つ成功すれば大きな成果を得られるようなプロジェクトを企画することが重要だったりします。

要件定義が肝

PoCのフェーズではPoCが上手くいかず、本開発が進まないという問題に陥りがちです。

具体的な要件定義が分からなかったり、成功の基準がなかったり、ビジネス運用に繋げられないことが原因だったりしますが、このことは要件定義の質がプロジェクト成功要因の80%ぐらいを占めていることを示していると言えます。

プロジェクトのアウトプットが不明確であったり、要件が曖昧なまま進めてしまうことが原因なので、ベンダーに任せとけばいいや、というマインドではなくて、要件定義の段階で何を作るか絞り込むことが、後々に大きく効いてくることを覚えておいていただきたいです。

本開発では一部ではなく全体を見るべき

本開発・運用の説明をしていきます。本開発・運用は、本番環境を想定して、システムを作り、作ったものを継続的に運用・改善できる仕組みを作るプロセスになります。

PoCと本開発の違い

PoCと本開発の何が違うかというと、一つ目は方針の違いです。
仮説を立て、実験と学習を繰り返していくことで不確実性を検証していくのがPoC、逆に、最終的にどうあるべきかの理想像を作り、そこから逆算して計画を作っていくのが本開発です。

二つ目は、設計です。
PoCでは、仮説検証を実行しながら、どうすると最適なものになるかを考えていくのに対して、本開発は、一定の品質を担保しながら要件を固めてテストもしていきます。

三つ目は、成果です。
PoCでは、仮説検証の結果を求めた報告書がメインの成果物ですが、本開発では実際に運用できるシステムがアウトプットになります。

四つ目は、議論です。
PoCでは、仮説検証や学びを議論して行きますが、本開発は仕様や要件に関する議論が多くを占めます。

プロジェクトには相互理解が必要

そもそもPoCと本開発では、必要なスキルが少し違うので、お互いの理解がない人たちがプロジェクトを進めていくと、意見が衝突する場合があるため、相互理解が必要になります。

業務プロセスの設計では、開発を進めるための要件を決める際にも、業務プロセスをよりデジタルで改善していきましょうとなった時も、業務プロセスの一部ではなくて全体で見たときにどのような効果が出るのかを考えています。

元々の業務プロセスABCがあったとして、業務Bは効率化出来たが、気づいたら業務Aと業務Cが増えていたとなるケースがあります。

良いパターンのときは、Bをほぼゼロに近づけた時に、他の工程もそこまで悪くなっていないことが重要なため、業務プロセスの全体を見た時に、一部ではなく全体に効果が出るのかを考えていくこともポイントになってきます。

組織全体でDXを推進するには3つのステップがある

これまではDXの一つのプロジェクトの進め方を解説してきましたが、ここからは組織全体として、どのようにDXに取り組んでいくのかというテーマで話していきます。

DX推進には、大きく分けて三つのフェーズがあります。このフェーズの切り方は、色々人によって違いますが、初期軌道に乗せていくまでだとおおよそこの3つに分けられると思います。

レベル1は、各部門がバラバラにプロジェクトを実施しているフェーズ。いわば、個別最適になってるフェーズです。

レベル2は、 DX 推進部門のような集約的な組織を設置して、経営レベルで DX の取り組みが始まっていくフェーズです。

レベル3は、DX戦略を立案し、部門間で連携しながら全社最適なプロジェクトに取り組んでいるフェーズになります。

経営・DX推進・各部門・人事という四つの役割があった時に、そのフェイズごとに何をやるべきかが別れてきます。

次回最終回では、その中でも経営とDX推進担当がそれぞれ何をやるべきなのかにフォーカスして、そのレベルごとの具体的なアクションを説明していきます。
※ご関心お持ちの方は「しこうさくご」メルマガへのご登録をお願いします。






-プロジェクトをしこうさくご, 仕事をしこうさくご
-,

© 2020 一般社団法人日本能率協会