
システム開発の成功確率を上げたい
要件・技術の不明確な部分を明確化したい
と言った悩みはどのSEが抱える永遠のテーマです。
この成功確率を上げる方法がPoCです。PoCを上手く導入することで、システム開発の成功確率を上げることができます。本記事では、「PoC(概念検証)の上手な進め方 」、「PoCの勘所」 を分り易く解説します。
PoCを正しく導入できれば、システム開発にとって全体リスクを低減させ、コスト削減も可能です。
PoC(概念検証)のよくある失敗とは?

ちなみに、読み進めていただく際に、心の中で【PoC】を何度も読まれると思うので、先に【PoC】の読み方の紹介です。
PoC=Proof of Conceptの略です。
PoCは、結構みなさん「ポック」と呼んでいます。
ちなみに、PoCは『概念検証』 『理論検証』と言ったりもします。
本題に戻ります。
PoCでよく発生する失敗は、
①PoCを始めるはいいけど、最後にはゴールがあやふやになり終わらない
②PoCは完了したけども本プロジェクトに何の役にも立たない
この2つです。
システム開発視点では①が恐ろしく、ネバーエンディング開発地獄です。
一方、ビジネス視点では②は最悪で時間とお金の無駄です。
なぜPoCは失敗してしまうのか?どうやって失敗を回避できるか?
答えからすると以下の3つが必要です。
① 正しいPoCのプロセスの理解
システム開発においてアウトプットの精度を上げるには、インプット(成果物)の質をあげ、開発プロセス(この場合はPoCプロセス)を上げるに尽きます。至極シンプルです。
② 失敗の勘所を理解しておく
①に関連しますが、成果物・プロセス準備も平押しで全部頑張るのでは疲弊します。物事には勘所があります。PoCもしかりです。そのPoC固有の癖・失敗しやすさを学ぶ必要があります。
③ 正しい知識に基づいて行動する
①②があっても実際にプロジェクトを勘所にそって構成する・進行中であれば変更する必要があります。簡単に書きましたは一番難しい点です。プロジェクトオーナーとの利害関係・PoCの進み具合では相当骨の折れる点です。
プロジェクト管理で上手くいかないと悩んでいる人には、「プロジェクトマネージメントとは?手法よりも大切な本質|プロ直伝」の記事がおすすめです。
本記事では①PoCの進め方を解説します。
PoCの失敗事例に関しては以下の2つの記事で詳しく解説しています。合わせて読んでみてください。


PoC(概念検証)のプロセス・進め方を理解しよう
一般的な、システム導入でのPoC(概念検証)は、以下のプロセスで導入されます。
(システム開発の全体プロセスは【システム開発のプロセス全体概要を理解から始めよう】の記事で解説しています)
✔一般的なシステム開発・導入時のPoC(概念検証)導入タイミング
一番良く見かけるケースは以下のPoCではないでしょうか。

- 企画・ビジネスケース
- 購入 or 構築検討
- PoC (概念検証)実施
- 本格開発 or 本格導入
- 運用
企画が完了し製品選定も完了。しかし、まだ技術的・ビジネス的な観点で不明確な点が残り解決しておきたい!
そんなときに導入されるのがPoCのプロセスです。
PoCの重要性を語るうえで前後の工程が非常に重要になります。上記のステップを使いまずは流れを解説していきます。
① 企画・ビジネスケースの検討

一般のシステム開発と同様、PoC(概念検証)実施の際に最も重要な工程です。
『企画・ビジネスケース作成』工程で、何の目的でシステム開発導入しようとしているか明確にする必要があります。
万が一、この工程で、目的が曖昧だったり、間違ったゴール設定してしまうと、間違いなくPoCは失敗します。
✔間違ったゴール設定の例
- 技術検証が目的になってしまっている
- ビジネスケースが明確でない
- 目的が明確化されておらずあやふや
- 誰がオーナーなのか明確化されていない
通常の開発と同様に最新の注意が必要です。
✔アドバイス
間違ったゴール設定を未然に防げれば最高です。
実際には、経験を積まないと、ゴール設定を上手くできないのも事実です。繰り返される開発でしっかりとノウハウを蓄積する為に、ゴールの明文化(書き出していないと振り返れません)と、プロジェクト完了後の振り返り(プロジェクト開始時のあなたの思考と向き合う)を実施しましょう。
これを着実に実施する人だけが成長できます。
あわせておすすめ記事
システム開発の遅延理由50%は要件定義の失敗:事例と回避策
② システム購入 or システム構築(開発)か検討

次は、「どのようにそのシステム構築するか? 」 を検討する工程です。
PoC必要性もこの工程で決まります。
ビジネスケースに基づき、実現方法を検討したいが不明確な部分がありもう少しリスクを減らしたい場合に、PoCを導入します。
一般的な、商品・サービス選定の選択肢
- 既製品のパッケージをそのまま標準導入
- 既製品のパッケージを一部カスタマイズ
- スクラッチ開発し導入
です。
この選択肢と、先ほどのビジネスケースの組み合わせで、どのようにビジネス目的を実現可能か?を検討します。
PoCする箇所を特定するサンプル
図で表すと以下の様になります。

例えば、既存システム改修を検討してみます。
A・B・Cのビジネス要求を、既存システムの改修か。新技術の導入いずれかで達成できるか検討します。この場合では、既存システム改修では、ビジネス要求のBを満たすことが出来ません。こういった場合に、Bの検証を切り出してPoCを実施します。

ビジネス要求に対しての、新技術等での適合性確認検証がPoC(概念・もしくは実証検証)になります。
PoC死してしまう、失敗するPoCの構図
PoC死(PoCが失敗)してしまう実態としては、新技術ありきでどのように既存ビジネス等に導入できるか?が横行しています。

そんなのあるわけない!って思うかもしれません。
しかし、実際には社長・役員のプレッシャーにより多くのプロジェクトがこのケースに陥っています。なぜなら、彼らはビジネスのプロフェッショナルかもしれませんが、ITは素人の場合が多いからです。
尚の事、あなたの知識でのリードが重要になります。
本来のPoCの構図と、失敗するPoCの構図

失敗してしまうPoC死の殆どがこのケースです。
重要なポイントは、 PoC死・PoC倒れを起こさない為にも、ビジネスコンセプトの選定後にPoCへ移行する事が最重要 です。
技術検証ありきのPoCは必ず失敗します。
ネット上でのPoC失敗の例
客「3ヶ月で外注してPoCやる、失敗したら撤退」
— くるぴー (@kurupical) November 7, 2019
3ヶ月後
客「会社の成果目標にPoC成功って書いたしお金もかけたし失敗して評価下げたくない…」
AI企業「成功して次に繋げたい…」
両者「よし、無理やり成功したことにしよう!」
っていうの多くないですか?
「AIのPoCプロジェクトの失敗率は98%」(アクセンチュア調べ)
— みき (@mikisan_39) November 1, 2019
PoCにおける目的の重要性。正しいPoCの目的図解
つまり、PoC工程でまず行うべきことは、以下の明確化です。

- 検証の目的は何か?
- 時間軸は?
- 判定の基準は?
- 誰が判断するのか?
これら観点をPoC開始前に決めていない場合ゴールがあやふやになり失敗します。
更に詳しく、 PoCで失敗しない勘所に関しては、PoC死って何?増加の原因を理解し無駄死にしない方法【基本】の記事でご紹介しています。
✔アドバイス
システム開発で、「手段が目的になる 」 のは、PoCに限った話ではなく、よく発生する悩みの一つです。
そうならない為に、常にITエンジニアは、この仕組みを何の目的で構築するのか、自問・チームへ投げかける必要があります。
この考え方で、強くお勧めが「逆算思考」です。
常に、ゴールから物事を逆引きする事で、目的達成の為に、その機能は必要か?今その改修しなければいけないのか?を冷静に考える事が出来ます。
ゴールが明確になったらベンダーから提案を取得
PoCの目的が明文化されクリアになったら次はいよいよベンダーに提案を依頼します。
既に運用しているベンダーにも声はかけると思いますが、PoCで技術検証をするくらいですので、既存ベンダーでは推進できないケースがほとんどです。その場合に非常に便利なのが以下2つのサービスです。
発注ナビ 公式URL: https://hnavi.co.jp/
EMEAO(エミーオ)公式URL:https://emeao.jp/
③ PoC(概念検証)を実施
システム導入において、検証が必要な個所の特定が完了したらいよいよ、PoCの開始になります。
概念検証とは言いますが、実際にはスコープを狭め、本番稼働の一部分を実証検証する場合もあります。
✔PoCの実行における重要なポイント
- PoCで検証する項目と時間軸の明確化
- 結果を判断する責任者も明確化しておく
何もこれは、PoCに限った話ではないですが、物事を進める上で非常に重要な概念になります。
④ 本格開発・本格展開を実行
PoCで満足いく結果を得られたら、そのシステム導入を本格開発、もしくは、本格展開へとスケールしていきます。システムエンジニアにとっては、愚直な実行力が非常に重要になります。
PoCをへて検証が完了し、システムが決定しても油断してはいけません。良くある典型的なリスクが、「導入を決めたPoC技術の知見者・有識者が少ない 」 リスクです。
PoCで検証した新技術を導入する際の注意点
- 導入に十分なリソースを確保できない・もしくは、コストがかかる
- 技術を導入する人材が多忙すぎて本格導入が大分先になってしまう
導入に十分なリソースを確保できない
このリスクを プロダクトライフサイクル を使い解説します。PoCを実施するような最新技術は、往々にして「導入期・成長期 」 にあります。(Bのエリア)

Bのエリアの製品・技術・サービスは、市場自体がそれほど大きくありません。つまり、そこで従事するシステムベンダー・その技術をあつかえるエンジニアリソースも限られています。
一方、Aのエリアに移行した製品・技術は、マーケットの拡大に伴い扱う従事者も拡大します。(この時期には価格競争も始まり低価格化ものぞめます)。
PoCで最新技術導入を検討・チャレンジする場合は、このようなリスク理解と管理が重要になります。この製品ライフサイクルとシステム開発におけるリソースの関係は覚えておくと便利です。
- Aのエリアに存在する製品であれば、市場でもその製品を取り扱える人材も豊富でリソースの調達も容易
- Bのエリアの新技術は、そもそも扱える人材が希少(裏返すと、だからこそそういった技術の導入によりビジネスチャンスが広がる可能性も高い)
⑤ 導入されたシステムを運用する

本格導入が完了したら、最後にそのシステムの運用フェーズになります。
実際は、このフェーズでも人材の問題はつきまといます。
特に他社に先駆け新しい技術を導入した場合、その製品の運用は既存ベンダー等では難しい、もしくは、リスクを取りたがりません。
繰り返しになりますが、だからこそ、実装できビジネスの価値を生み出せれば大きな成果につながる可能性があることも事実です。
システムエンジニアとしては、運用の観点もビジネスオーナーと会話が必要です。
少々、コスト増にはなるかもしれませんが、場合によっては、そのまま開発したSierチームがしばらく運用チームとして活躍する調整もありです。
ここまでの流れを一連のPoCの進め方にそって、失敗を未然に防ぐチェックリストにまとめています。「PoCの失敗・疲れを簡単に回避するチェックリスト【具体的手順】」を参照ください。
2-10 SEの飛び道具|失敗しないPoC(概念検証)の進め方とコツまとめ
PoCを失敗しないための勘所は、
①正しいステップを理解する
②失敗しやすい点を理解しておく
③正しいPoCを実行する・PoCを起動修正する
の3つでした。
本記事では①の進め方を詳しく解説していきました。
②に関しては【PoC死って何?増加の原因を理解し無駄死にしない方法【基本】】で詳しく解説しています。合わせてご参照ください。
③に関しては、このシステム開発ステップアップ講座でかなりスキルアップして実力を伸ばされたと思います。この知識に加え次の記事でお薦めする書籍でもっと理解が必要な領域を読み進めることで更に知識と自信を深められます。