PoCについてまとめてみた
社内の勉強会でPoCについて触れる機会があったので、まとめてみます。
PoCとは
Proof of Concept の略。日本語に訳すと、「概念実証」という意味です。
新しいITソリューションが本番運用でも使用できるか？ということを
技術的な観点・顧客満足度など、様々な評価軸を用いて検証するフェーズのことです。
PoCは要件定義フェーズの前で行われるものであり、
「新しいソリューションを導入する前に、そもそも使えるかどうか」を検証していきます。
PoCの目的
システム開発の提案の際に用いられます。
顧客が導入するシステムにおいて、
「本当に投資をする価値があるのか？」と判断する際に、
より効果的な提案をするために、よりプロジェクトのリスクを低下させるために行われます。
野村総合研究所において、ビジネスITソリューションでの、PoCフェーズの重要性が説明されています。
PoCの流れ
PoCは大きく分けて、以下の3つのステップに分かれています。
・準備
・仮説検証
・評価
準備
Pocフェーズでは、対象業務の選定において、
提案者の方で、業務仮説を立て、顧客にヒアリングして進めていきます。
これは、業務のイメージが当初はぼんやりしているため、提案者が仮説を立てることで
対象業務をより明確に選定するためです。
このステップでは、業務ごとのINPUT/OUTPUTを意識することが重要です。
仮説検証
使用するソリューションが実際に使用できるかどうか、ソリューションの試用版を作成します。
試用版を作成する場合には、ソリューションに精通したメンバーにアドバイスをもらうなど
PoCフェーズに参加していないメンバーの協力を仰ぐことも重要です。
評価
PoCフェーズでは、顧客においての評価軸を設定し、PoCフェーズが効果的であったかを
評価してもらう必要があります。
ここでは、主に業務適合度やユーザビリティといった評価軸が用いられます。
業務適合度は、先述の「準備」ステップでおこなった際のヒアリング内容を用いて、
よりクリティカルな業務を選定する必要があります。
効果的に実施するには
スモールスタートで取り組む
PoCは検証や提案を目的としたフェーズのため、出来る限りスモールスタートで行う必要があります。
あくまで投資をする是非を評価するフェーズのため、必要最低限のソリューションを作成する必要があります。
しかし、本番運用した際のシステム構成と異なる部分が多いと、受注後のシステム構築で、認識違いや実現不可能な要件が多発してしまうため、スモールスタートのスコープを適切に設定することが大切です。
実運用で検証する
顧客の環境と近いレベルのソリューションを作成して、顧客に検証してもらうことが大切です。
顧客が使用するデバイス・ネットワーク環境・実際の業務の動きなど、
顧客の環境を意識したソリューションを提供すると、評価がされやすくなります。
PDCAサイクルの実行
評価がされやすくなったタイミングで、最初に提案したソリューションをさらに顧客の要望に近づけるために、当初定義した仮説をさらにブラッシュアップし、またソリューションに適用していきます。
これにより、顧客満足度の高いソリューションに近づけることが出来ます。
まとめてみて
PoCフェーズ自体、自分は初見だったので、
要件定義前にこういった活動をしているのかと、気づきが多い勉強会であった。
ただプロジェクトによっては、要件定義フェーズとの被りが出てしまったり、
そのあたりのやりようは考えなくてはいけないと感じた。
ただ、ソリューションの検証は個人的には顧客との意識違いをなくすいい手段だと思ったので
システム開発以外のフェーズも意識して、プロジェクトの流れを俯瞰していこうと感じた。
おわりに
今回はPoCフェーズについてまとめてみました。
提案活動は自分にとっては疎い分野であるので、今後も未知の仕事を流れを
積極的に見ていこうと思います。
