『PoC』でプロジェクトの質と成功率を上げる！

PoCのメリット・デメリット

PoCを実施する事による、主なメリット・デメリットを以下にまとめました。

リスク・課題が存在し、それらがプロジェクトを進める中で障壁になることが明確な場合は、PoCの実施をおすすめします。

例えば…

• 新しい業務を考えているのであれば、To-Be業務フローを引き、一部メンバーで実施してみる。
• 新しい技術を取り入れるのであれば、実際にプロトタイプを構築して使ってみる。

前述したデメリットに「延期発生」「コスト増」と記載していますが、リスクや課題があるにも関わらず「とりあえずやりながら考えよう」で進めてしまうと、後から思わぬ障壁にぶつかり、プロジェクトの遅延や延期、最悪は中止する状況になり、PoC以上のコストが発生してしまいます。

なおSalesforceの場合、すぐに使える環境を払い出すことができ、ノーコードで機能構築が可能ということで、とてもPoCに向いているプラットフォームになっています。

まずはPoC実施する前に計画を立てましょう。

「とりあえず、目の前にあるものから作ってみよう」という進め方にしてしまうと、目的・ゴールを見失い、必要な検証ができずに検証期間が終わってしまいますので、目的・ゴールは必ず明確にします。

PoC開始時に関係者を集め、キックオフを実施しましょう。

参考として以下に計画書に記載するべき内容例をご紹介します。

▼計画書の内容例

• PoCの目的とゴール
• スコープ（対象の業務・機能）
• スケジュール
• 体制（関係メンバー一覧、コミュニケーションルート）
• 会議体（メンバー、打ち合わせ計画、使用するツール）
• 作成物
• 完了基準・評価方法

実行フェーズでは、計画書の内容に従ってPoCを進めていくのですが、実施している最中は必ず課題管理・ＱＡ管理を実施しましょう。

PoCが進む中で、次々と決定事項・検討事項・要求が発生するので、発生したタイミングで確実に管理しておきます。（後からまとめるとかなりの労力になります…） 課題はその場でPoC解決せずとも、関係者で認識を併せ明確にしておく必要があります。

またPoCを進めていくと「作ること」が目的になったり、徐々に思わぬ方向に逸れて進んでしまったりすることが多いため、定期的に計画書に立ち返り、当初目指した目的・ゴールを関係者で認識合わせするようにしましょう。

PoCが完了したら、（何をゴールとし、評価するのか決めているので）計画書に従い、完了状況・結果を整理します。

全てのリスクや課題が解決できていることがベストではありますが、なかなかそのような状況になるのは難しいため、今後の方針を定めておきます。

残課題に関しては5W1H（いつ・どこで・誰が・いつ・何を・なぜ・どうやって解決するのか）を明確にして、関係者と合意します。

十分な評価が得られれば、そのままスムーズに後続の工程に進むことになります。

簡単ではありますが、以上がPoCのご紹介となります。

PoC工程を上手く活用することでリスク・課題を早期に確認・解消し、プロジェクト全体の品質や成功率を上げることができると考えます。

「DX」に限らずとも、これからシステム導入・業務改革を予定されている方には、ぜひPoC実施の検討をおすすめいたします。