前回までのあらすじ
DXが進まない理由について「なにからやればいいかわからない」という場合の理由と対策について学んだ初心さん。学んだ知識を活かしてDX推進プロジェクトを進めているようですが…？
初心さん色々な部署からヒアリングして、改善できそうな課題を見つけてきました！
進方さんでは、次は「概念検証」ですね！
初心さん？？？
DXを実行する前にPoC（概念検証）を行おう
初心さん概念検証ってどういうことですか？
進方さんビジネスシーンではPoCとも言いますね
PoC＜Proof of Concept＞とは、「概念検証」という意味で、新しいアイデアやコンセプトを実際に開発する前に、実現可能かを検証することです。事前に検討することで実現可能かを見極め、期待した効果が得られると判断できればプロジェクトを進めていきます。
PoCを事前に行うメリットは３つです。
●リスクを最小限に抑えられる
事前に不可能なプロジェクトを中止できる他、リスクを事前に回避・軽減する対策を採ることができます。
●コスト・工数削減
工程を考える上で、検討していた方法が適切ではないと事前にわかれば、修正にかかる時間や人的リソースのロスが軽微で済みます。
●投資・開発判断がしやすくなる
事前に効果や工程を検証できれば、プロジェクトに投資すべきか、継続するか、中止すべきかなどを判断しやすくなります。大きな事業失敗につながらないようにリスク対策をしておくことで不安要素が軽減され、プロジェクトに一層注力できます。
初心さんよーし、さっそくPoCやってみます！
進方さんでは、PoCの進め方も解説しますね
PoCの進め方
PoCの進め方は以下の通りです。
目的設定 → 検証内容設定 → 実証 → 結果の評価
目的設定
まずは「なぜPoCをするのか」、目的を明確にしましょう。同時に、どのような結果が出ることが理想なのか、改めてリストアップしてゴールをはっきりさせておきます。
検証内容設定
プロジェクト中のどのアイデア・機能を検証するのか、効果が正しく出そうな検証方法であるかを探り、再度PoCの目的と照らし合わせます。この時、検証範囲（対象）はなるべく限定しておきましょう。課題・問題点を見つけやすくなります。
実証
結果を評価しやすくするため、実際に使用する対象を巻き込んだ実証にすることが大切です。精度の高いデータを得やすくなると、その後の改善にも生かすことができます。
結果の評価
結果をチェックし、実現可能性・リスク・効果・コストなどを評価します。開発を進めるべきか、改善してからにするべきか、そもそも中断すべきかなど以降のプランを考えます。
PoCを実際に行うことで、検証前には見えていなかった課題や問題点が可視化できます。データを残せれば、例えそのプロジェクトが中止になったとしても、自社の開発ノウハウとして蓄積し別のプロジェクトに活かすことも可能です。
DXの取り組みが検証から先へ進まない理由① 検証内容を判断する基準がない
進方さんPoCの流れをつかんだところで、失敗しやすいポイントも抑えておきましょう
PoCの失敗が、「DXの取り組みが検証から先へ進まない」理由に繋がっていきます。どういうことか解説していきましょう。
PoCの進め方の中で、特に重要なのが「目的設定」と「検証内容設定」です。
PoCの目的がはっきりしていないと、何を目指して行動しているのかがわからなくなってしまいます。
また、検証内容を判断する基準がないことで、どの部分を重点的に開発するのか等の優先順位が付けられず、開発現場が混乱してしまいます。
成功の基準がない、ということは結果の判断基準を持たないということです。結果を判断できないので、ローンチするかどうかも判断を下せないというわけです。そのため、ずっとPoCを繰り返してしまう、というケースもあります。
初心さん100％を目指して検証を繰り返しても良くないってコトですか？
進方さんそうですね。プロジェクトのどの部分が何％に達していればローンチする、などの基準が必要です。逆に優先度が高いものから検証すれば短期間でローンチが可能になります
進方さん次にPoCを成功させるポイントもお伝えしておきますね
PoCを成功させるポイント① できるだけ小規模から実践する
PoCの実施範囲を限定して、なるべく小規模から始めることがベストです。
規模が大きくなればなるほど時間がかかってしまうため、開発工数を素早く事前に検討できるPoCのメリットが半減してしまう恐れがあります。
PoCを成功させるポイント② 実際のサービスに近い形を意識する
実際のサービスに近い形を意識したPoCにすることで、正しいデータを収集することができます。あまりに想定していた環境と異なると、開発後に想定外のことが起きる可能性が高まり、せっかくPoCで得たリスク予測が無駄になってしまいます。
初心さん目標を具体的に、優先順位を事前にはっきり決めて、はじめの一歩は小さく…ってコトですね！
DXの取り組みが検証から先へ進まない理由② 予算が取れない
初心さん新規プロジェクトあるある！
進方さん予算って事前にある程度決まっているものですしね…
予算が下りない最もよくある理由としては、経営層に対して事業計画書やプレゼンでしっかりメリットを打ち出せないことです。そのプロジェクトを行うことで、会社にどんなメリットがあるのかを具体的に伝えられるデータをそろえておきましょう。また、ロードマップを描けているかも重要です。
しかし、長期プロジェクトは計画を見通しづらいのも事実です。そこで、以下の2点を採り入れてみましょう。
MVPの考え方を採り入れる
MVP＜Minimum Viable Product＞とは、「実用最小限の製品」のことです。想定するユーザーに対して「コアとなる価値」を提供でき、有効なフィードバックが得られるだけの最小限の機能を持つ製品のことを指します。
開発の手間になる装飾やメイン機能以外を全てそぎ落として最短で開発し、ユーザーの反応を見ながら改良を加えていく手法で、仮にPoCによる仮説が誤っていたとしても、早期に改善・撤退が可能です。
最短、必要最小限で開発を進めることでロスする時間的・人的コストも最小限に抑えることが期待できます。
ROIを明示する
ROIとは「Return On Investment」の略称で、「投資収益率」や「投資利益率」とも呼ばれます。その投資でどれだけ利益を上げたかを知ることのできる指標のことを指します。
算出式は以下の通りです。
ROI算出式
（売上ー売上原価ー投資額）÷ 投資額×100（%）
プロジェクトで何かシステムを導入するなら、ソフトウェア費用やインフラ費用、開発ベンダーへの保守開発にかかる金額を把握する必要があります。その他、人件費も考慮する必要があります。
業務効率化プロジェクトの場合は、担当者の削減時間の他、その削減時間で生み出す利益なども考慮する必要があります。
初心さんROIはRPA導入の時にも算出しました！
参考：初心、RPAを学ぶ：第11回「RPAのROI（投資利益率）を算出しよう！」
DXの取り組みが検証から先へ進まない理由 まとめ
DXの取り組みが検証から先へ進めない（PoC※を繰り返す）理由は以下の３つです。
※PoC＜Proof of Concept＞とは、「概念実証」という意味で、新しいアイデアやコンセプトを実際に開発する前に、実現可能かを検証すること
●PoCを行う時に目的を明確にしていない
●成功基準を明確にしていない
●予算が取れない
DXの取り組みを進めるポイントは以下の２つです。
●PoCで具体的なデータを集める
・できるだけ小規模から実践する
・実際のサービスに近い形を意識してPoCを行う
●予算を獲得するためにROIなど具体的な数字をもとにロードマップを描く
初心さんプロジェクトが失敗しないように、とにかく細かく評価方法や進め方を詰めるってことですね
進方さんそうですね。でも実はDXって途中で失敗してもいいんです。それもノウハウになって次の成功につながっていきますからね。DXの歩みを止めた時が本当のDXの失敗です。
つづく
