Proof Of Concept（PoC）は、Proof of Value（PoV）とも呼ばれ、あるシステムやソリューションが問題や課題の最終的な解決策となる可能性があることを証明するためのラフプロトタイプです。
このラフプロトタイプは、提示された問題に対して提案されたシステムやソリューションの可能な限界を徹底的にテストするのですが、このトピックをアウトシステムのエコシステムに関連付けると、PoCは新規顧客のセールスサイクルにおいて非常に一般的になることを知っていますか？
セールスサイクルの1つのステージは、プラットフォームの技術評価となります。
通常、この段階では、見込み客はOutSystemsのプラットフォームを市場で入手可能な他のプラットフォームと比較し、プラットフォームが彼らが考えているすべての技術的および非技術的な要件を満たしているかどうかを理解しようとし、さらに、長期的なソリューションとしてのプラットフォームの将来性を理解するために、プラットフォームの限界に挑戦しようとするのです。
この段階は、実行可能性を確立し、技術的な問題を切り分け、全体的な方向性を提案し、予算編成やその他の社内の意思決定プロセスにフィードバックするために不可欠であり、非常に強力となるでしょう。
また、技術的な課題だけでなく、プラットフォームの使いやすさや、技術者ではない人の学習曲線など、技術的ではない質問にも対応できます。
PoCを成功させるためには、適切な期待値を設定し、PoCの開発が行われている数日間に起こるすべてのことを監視することが重要です。
PoCの望ましい結果は、見込み客がプラットフォームの力を明確に理解し、組織の人々が熱心に使用し、役員がこのソリューションがもたらす価値を理解することでなければなりません。
この価値は、より一般的にはROIへの直接的な影響で測定されますが、満足度や幸福度、環境改善などの指標に影響を与えることで間接的な影響を与えることもあるのです。このような情報はすべて、PoCの間に見込み客といくつかのレベルで関わりながら収集し、発見しなければなりません。
前述のように、PoCは非常に強力ですが、提案されたソリューションのガバナンスを維持するためには、いくつかのルールがあるのですが、PoCは大まかなプロトタイプであり、プロトタイプとしてのみ使用されるべきものといっても過言ではないでしょう。
つまり、量産品に発展させてはいけないということなのです。
見込み客がプロトタイプに熱中し、いくつかの（常にほんの少しの）機能を追加したいと考え、プロトタイプを製品化したいと考えることは珍しくありません。
注意として、PoCの開発では、「手抜き」をしないようにすること。
要件に変更が生じることもありますし、そうでなければ、削った角が役に立つかもしれません。
これは、たとえそれがラフなプロトタイプであることを知っていても、私は常にベストプラクティスに従うことを個人的に好んでいるということなのです。
最も不都合なことは、最終的なデモの最中にアプリケーションが壊れてしまい、せっかく準備した旅の途中で立ち往生してしまうことでしょう。
PoCを成功させるために必要なもの。少人数でありながら経験豊富なチームであること。
適切な期待値の設定。PoCを開始する前に相互に合意し、実行中も定期的に確認し、作業終了時には再検討しなければなりません。
ミーティングやデモには、見込み客の中から適切な人を参加できるように行動喚起を促します。
見込み客から適切な人材を確保することは、優れた仕事を実行することと同じくらい重要になりますね。彼らがいなければ、あなたのピカピカで印象的なPoCは意思決定者の目には映らないでしょう。
※この記事は、LinkITSytemsのCEOであるRúben Bonitoによって書かれた “The Importance of Outsystems POC “がMediumに掲載されたものです。
※日本向けにリライトしています。
