本連載の第1回では、デジタル化プロジェクトを進めていくにあたって直面する問題とそれを解決するためのデジタル化推進ガイドの全体像について紹介しました。第2回から第6回では、デジタル化プロジェクトで直面する5つの主要課題を取り上げ、具体的な解決方法を解説していきます。
第2回では、全体プロセスにおいて開発や市場投入段階でのPoC(概念実証)への手戻りやプロジェクトの頓挫を回避するための、PoC段階の効果的な進め方について解説します。

デジタル技術を活用した新サービス開発などのプロジェクトを推進する際に、ユーザーのニーズ有無や技術的な実現性、プロダクト要件などのプロジェクト開始時点で明らかにできていない要素を検証する手段としてPoCは有効です。従来のウォーターフォール型開発のように、システム全体の要件を最初に決め、開発・リリースまでを一連の工程として進める手法とは異なり、PoCは検証を繰り返しながら徐々に不確かな要素を段階的に明らかにし、要件を具体化していくことができます。
PoCの推進にあたっては、デザイン思考、CRISP-DM、リーンスタートアップなどのプロセスフレームワークがよく参照されます。いずれのフレームワークも仮説を立てて検証を繰り返しながら段階的に前進することを重視しており、短いサイクルで学びを得て次の段階に進むうえで効果的な考え方です。しかし、効果的な考え方であるからといって、PoCを繰り返すだけで自然とプロダクトや事業が完成していく "魔法の杖"ではありません。

実際、PoCの取り組みでは、「何を目的にどの程度繰り返すべきか」が明確に定義されていないケースが少なくありません。その結果、現在の活動段階(進捗状況や残り検証項目)の判断がつかない、目的と異なる検証を実施してしまう、実現性が明らかになってから具体化すべき検証を先行実施してしまう、といった問題が生じています。こうした迷走が続くと、再検討や手戻りが増えてプロジェクトが不必要に長期化し、進捗判断すら難しくなるという悪循環に陥ります。
このような状況に対して、事業部門からは「いつまで実験を続けるのか」「進捗が見えない」「いつゴールに到達するのか」といった声があがることもあります。PoC担当者は良いサービス創出に向けて真摯に取り組んでいるものの、失敗とみなされるケースが続くと「PoC疲れ」に陥ってしまうのです。

一般的なシステム開発では、V字工程など標準的なプロセスが存在し、各工程の目的や具体的な成果物が定義され、終了基準も明確になっています。一方、デジタル化プロジェクトでは、前述した方法論は存在するものの、これらはPoC個々の検証を進める方法としては適していますが、PoC全体を定義しているフレームワークではありません。そのため、PoCを積み上げ型で進めるための検証項目や次フェーズに進む基準が明確にならないことが多いのが実情です。推進するリーダーの経験や勘でPoCのフェーズの区切り方、終了基準、検証事項を定め、推進するプロジェクトは少なくありません。このリーダーの勘と経験に基づいて進められることにより、失敗や非効率が生じてしまった例を挙げてみましょう。

• PoC検証をすれば短期間で明らかにできたはずの前提条件の整理を、プロジェクト開始直後に精緻に進めようとした結果、必要以上に時間を要してしまう
• 開発段階になってから、PoCで検証済みと考えていた検討漏れが大量に発覚し、当初予算の大幅なコスト超過が発生する
• PoCの目的が共有されないまま、「まずは試してみよう」とスタートした結果、開発メンバーは技術的な実現性検証に注力し、事業メンバーは市場性や顧客価値の検証を期待していたため、途中で認識のズレが顕在化。議論が紛糾し、PoCが頓挫する

PoC全体の検証ステップや検証すべき事項を定めずに、属人的な進め方をしてしまうと、前述のような停滞・手戻りが発生しやすくなります。もちろん、デジタル化プロジェクト推進の豊富な経験を持ち、数多くの成功・失敗から学んだリーダーであれば、勘と経験によってある程度は正しい判断ができるかもしれません。しかし、そのような人材は限られており、組織として再現性を持たせるのは不十分です。デジタル技術を用いたサービス開発を目指す企業は、個人の能力に依存しない標準的なプロセスを確立し、組織的なノウハウを蓄積することが急務だといえます。

デジタル化プロジェクトのPoCを着実に進め、本番開発・市場投入へとスムーズに移行するためには、最終的な投資判断に耐えうる検証ステップを明確にし、その目的と評価基準を定義しておくことが不可欠です。デジタル化推進ガイドでは、PoCを進めるうえで、以下の3つを段階的に実施することを推奨しています。いずれも、最終的な投資判断を行うための重要な要素となります。

• 1効果検証(仮説の効果の明確化)
• 2実現性検証(システムやツールの実現可能性)
• 3事業性検証(システム化による投資対効果の最終確認)

このような検証を順序立てて行うことによって、活動が試行錯誤型から積み上げ型の確実な進行に変わり、プロジェクト全体の見通しを持てるようになります。結果として、投資対効果の予測精度が高まり、取締役会や投資家への説明責任も果たしやすくなります。
また、企業として検証プロセスを明確に定め、検証すべき事項や評価基準を定義することで、チームメンバー全員が目的や進め方を共有し、チーム内コミュニケーションを効果的に行えるようになります。これにより、PoCの停滞や手戻りを防ぎ、後続工程である開発や市場投入における成功確率の向上が期待できます。

以下、それぞれの検証について説明します。

• 1効果検証
  まずは、企画段階で設定した仮説が実現した場合にどれほどの価値を生み出せるか、そのポテンシャル(最大効果)を定量的・定性的に把握することが重要です。ここでは、実現可能性は一旦置いておき、純粋に効果の大きさやインパクトを測ります。この時点で効果が十分でないと判断された場合、活動自体を中止・転換する判断も必要になります。逆に、大きな効果が見込まれる場合は、その効果に見合うかたちで実現手段を模索していくフェーズへ進みます。検証手段としては、業務データの分析、ユーザーの課題の深掘り、プロダクトイメージの具体化などを通じて、効果額や影響範囲を見積もることが中心となります。
• 2実現性検証
  続いて、効果の高い仮説がどうすれば実現できるかを検証します。ここでは、必要となるシステム構成、業務プロセスの変更、使用ツールや外部連携などを洗い出し、実現のための要件・制約・課題仮説を明らかにします。単に「できる/できない」ではなく、「どうすれば実現できるか」「その際に何を工夫すべきか」「過渡期的にどう運用すればよいか」など、前向きに実現性を追求する姿勢が求められます。プロトタイプやモックアップを使った検証を通じて、業務運用要件やユーザーインタフェース、既存システムとの整合性などを具体化していきます。
• 3事業性検証
  最後に、開発直前のフェーズとして、PoCで得られた要件を踏まえた開発戦略と投資判断を行います。
  ここでは、効果・実現性の双方が確認された上で、
  
  • どの範囲を初期開発するか(全体構想 or MVP)
  • アジャイルかウォーターフォールかといった開発方針
  • 必要となる開発・保守運用コストと、それに見合う投資対効果(ROI)
  といった項目を整理します。加えて、周辺機能、組織体制、リリース後の運用やモニタリングのあり方などもこの段階で検討しておくことで、開発後の想定外の対応や手戻りを防ぐことができます。

今回は、PoCを実施したにもかかわらず、プロジェクトが遅々として前に進まないといった現場の課題に着目し、その背景と解決の方向性を説明しました。私たちは、PoCの現場では、いずれかの検証に大きく偏った検証を行ってしまった結果、開発になってから検証漏れが発覚してPoCへの手戻りが起こったり、プロジェクト自体が頓挫してしまうケースを多く見てきました。また、走りながら考えればいいと、検討すべきことを検討せず、「とりあえず分析すればいいや」や「とりあえずモックアップを作成しよう」といったPoCも散見されます。今回紹介した3つの検証ステップに沿ってPoCを設計・推進することで、デジタル化プロジェクトを確実に進められるようになることを期待しています。