ITスキルアップ PoCの始め方 オススメ記事

PoC無茶ぶりつらい「PoC(概念検証)プロセス」の進め方とは?

Poc無茶ぶりすぎる。PoC(概念検証)プロセスの進め方とは?ITスキルアップ

IoT・AIに代表される最新技術によるイノベーションのニーズが高まり、システムエンジニア・社内SEは、役員・事業部等からPoCのプレッシャーに迫られています。

役員・上司
役員・上司

『最新の技術を弊社にも導入しろ! 』
『うちのビジネスに最新の技術適用できないのか?検討しろ! 』

このような無茶ぶりでよく登場する「便利で恐ろしい工程がPoC(概念検証)」です。

✔システムエンジニア・社内SEの悩み

あなたの悩み
あなたの悩み
  • PoCを始めたいけど、どう進めればいいのかわからない
  • 失敗しないようにしたい!
  • 効率的に始めたい!

と言った悩みを抱えています。

本記事では、「PoC(概念検証)の進め方 」 、「PoCの準備方法 」 を解説します。PoCを正しく導入できれば、システム開発にとって全体リスクを低減させ、コスト削減も可能です。

✔記事の信ぴょう性

米にてシステムエンジニア→現、某一部上場企業の情報システム部門、管理職として活躍中。基幹システムの刷新やグローバル10拠点以上の国々へシステム導入・展開の実績。そういった、システム開発の過程で、PoCの失敗と成功も痛いほど経験し学びをえています。幾度のPoC現場経験からリアルな知識を提供できます。

PoC(概念検証)の言葉の意味を理解しよう

 PoC(概念検証)の言葉の意味を理解しよう

PoCの読み方です。

PoC(Proof of Concept・ポック)=『概念検証』 です。

もしくは、『理論検証』 と言ったりもします。

PoC何て読むの?(Proof of Concept・ポック) の読み方・用語解説

PoC(概念検証)のプロセス・進め方を理解しよう

一般的な、システム導入でのPoC(概念検証)は、以下のプロセスで導入されます。

✔一般的なシステム開発・導入におけるPoC(概念検証)のプロセス

  1. 企画・ビジネスケース
  2. 購入 or  構築検討
  3. PoC (概念検証)実施
  4. 本格開発 or 本格導入
  5. 運用

上流のステップから順に解説していきます。

① 企画・ビジネスケースの検討

企画・ビジネスケースの検討

一般のシステム開発と同様、PoC(概念検証)実施の際に最も重要な工程です。

『企画・ビジネスケース作成』工程で、何の目的でシステム開発導入しようとしているか明確にする必要があります

万が一、この工程で、目的が曖昧だったり、間違ったゴール設定してしまうと、間違いなくPoCは失敗します

✔間違ったゴール設定の例

  • 技術検証が目的になってしまっている
  • ビジネスケースが明確でない
  • 目的が明確化されておらずあやふや
  • 誰がオーナーなのか明確化されていない

通常の開発と同様に最新の注意が必要です。

✔アドバイス
間違ったゴール設定を未然に防げれば最高です。しかし、実際には、経験を積まないと、ゴール設定を上手くできないのも事実です。繰り返される開発でしっかりとノウハウを蓄積する為に、ゴールの明文化(書き出していないと振り返れません)と、プロジェクト完了後の振り返り(プロジェクト開始時のあなたの思考と向き合う)を実施しましょう。これを着実に実施する人だけが成長できます。書き出し大事!

② システム購入 or システム構築(開発)か検討

システム購入 or システム構築(開発)か検討

次は、「どのようにそのシステム構築するか? 」 を検討する工程です。

PoC必要性もこの工程で決まります。

ビジネスケースに基づき、実現方法を検討したいが不明確な部分がありもう少しリスクを減らしたい場合に、PoCを導入します。

一般的な、商品・サービス選定の選択肢

  1. 既製品のパッケージをそのまま標準導入
  2. 既製品のパッケージを一部カスタマイズ
  3. スクラッチ開発し導入
    です。

この選択肢と、先ほどのビジネスケースの組み合わせで、どのようにビジネス目的を実現可能か?を検討します

PoCする箇所を特定するサンプル

図で表すと以下の様になります。

例えば、既存システム改修を検討してみます。

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

ビジネス要求に対しての、新技術等での適合性確認検証がPoC(概念・もしくは実証検証)になります

PoC死してしまう、失敗するPoCの構図

PoC死(PoCが失敗)してしまう実態としては、新技術ありきでどのように既存ビジネス等に導入できるか?が横行しています。

PoC死してしまうプロジェクトの構図

そんなのあるわけない!って思うかもしれません。

しかし、実際には社長・役員のプレッシャーにより多くのプロジェクトがこのケースに陥っています。なぜなら、彼らはビジネスのプロフェッショナルかもしれませんが、ITは素人の場合が多いからです。

尚の事、あなたの知識でのリードが重要になります。

本来のPoCの構図と、失敗するPoCの構図

本来のPoCの構図と、失敗するPoCの構図

失敗してしまうPoC死の殆どがこのケースです。

重要なポイントは、 PoC死・PoC倒れを起こさない為にも、ビジネスコンセプトの選定後にPoCへ移行する事が最重要 です

技術検証ありきのPoCは必ず失敗します

ネット上でのPoC失敗の例

PoCにおける目的の重要性。正しいPoCの目的図解

つまり、PoC工程でまず行うべきことは、以下の明確化です。

PoCにおける目的の重要性。正しいPoCの目的図解
  • 検証の目的は何か?
  • 時間軸は?
  • 判定の基準は?
  • 誰が判断するのか?

これら観点をPoC開始前に決めていない場合ゴールがあやふやになり失敗します。

更に詳しく、 PoCで失敗しない勘所に関しては、PoC死って何?増加の原因を理解し無駄死にしない方法【基本】の記事でご紹介しています。


✔アドバイス
システム開発で、「手段が目的になる 」 のは、PoCに限った話ではなく、よく発生する悩みの一つです。そうならない為に、常にITエンジニアは、この仕組みを何の目的で構築するのか、自問・チームへ投げかける必要があります。この考え方で、強くお勧めが「逆算思考」です。常に、ゴールから物事を逆引きする事で、目的達成の為に、その機能は必要か?今その改修しなければいけないのか?を冷静に考える事が出来ます。【逆算思考のやり方】課題を素早く解決するロジカルシンキング の記事で詳しく紹介しています。

ちなみに、なにも役員・上司からのPoCのプレッシャーがあり四苦八苦されていると思いますが、あなたの工数を使わずに同実装・PoCが出来るかをとりあえずシステムベンダーに見積もってもらうのも手です。ビジネスゴールが明確であれば、多少コストがかかってもペイするなら圧倒的に効率的です。意外と見落としがちですが、PoCをする技術=先進性が高く、上手く利用すると競合を凌駕出来る可能性を秘めています。失いたくないのはその機会であり、もっとも重要な事は、コスト以上に時間という概念もあります。

株式会社doubLeのサービス【システム開発の外注複数社を完全無料で比較】で、以下の名だたるシステム開発ベンダーに一括見積可能です。こういったサービスでの時短も選択肢になります。

もしくは、既存の保守ベンダーにお願いもいいですが、その場合保守ベンダーは後々の保守を考え守りに入るリスクを理解して打破する必要があります。

③ PoC(概念検証)を実施

システム導入において、検証が必要な個所の特定が完了したらいよいよ、PoCの開始になります。

概念検証とは言いますが、実際にはスコープを狭め、本番稼働の一部分を実証検証する場合もあります。

✔PoCの実行における重要なポイント

  • PoCで検証する項目と時間軸の明確化
  • 結果を判断する責任者も明確化しておく

何もこれは、PoCに限った話ではないですが、物事を進める上で非常に重要な概念になります。

④ 本格開発・本格展開を実行

PoCで満足いく結果を得られたら、そのシステム導入を本格開発、もしくは、本格展開へとスケールしていきます。システムエンジニアにとっては、愚直な実行力が非常に重要になります。

PoCをへて検証が完了し、システムが決定しても油断してはいけません。良くある典型的なリスクが、「導入を決めたPoC技術の知見者・有識者が少ない 」 リスクです。

PoCで検証した新技術を導入する際の注意点

  • 導入に十分なリソースを確保できない・もしくは、コストがかかる
  • 技術を導入する人材が多忙すぎて本格導入が大分先になってしまう

導入に十分なリソースを確保できない

このリスクを プロダクトライフサイクル を使い解説します。PoCを実施するような最新技術は、往々にして「導入期・成長期 」 にあります。(Bのエリア)

Bのエリアの製品・技術・サービスは、市場自体がそれほど大きくありません。つまり、そこで従事するシステムベンダー・その技術をあつかえるエンジニアリソースも限られています。

一方、Aのエリアに移行した製品・技術は、マーケットの拡大に伴い扱う従事者も拡大します。(この時期には価格競争も始まり低価格化ものぞめます)。

PoCで最新技術導入を検討・チャレンジする場合は、このようなリスク理解と管理が重要になります。この製品ライフサイクルとシステム開発におけるリソースの関係は覚えておくと便利です。

  • Aのエリアに存在する製品であれば、市場でもその製品を取り扱える人材も豊富でリソースの調達も容易
  • Bのエリアの新技術は、そもそも扱える人材が希少(裏返すと、だからこそそういった技術の導入によりビジネスチャンスが広がる可能性も高い)

⑤ 導入されたシステムを運用する

導入されたシステムを運用する

本格導入が完了したら、最後にそのシステムの運用フェーズになります。

実際は、このフェーズでも人材の問題はつきまといます

特に他社に先駆け新しい技術を導入した場合、その製品の運用は既存ベンダー等では難しい、もしくは、リスクを取りたがりません。

繰り返しになりますが、だからこそ、実装できビジネスの価値を生み出せれば大きな成果につながる可能性があることも事実です。

システムエンジニアとしては、運用の観点もビジネスオーナーと会話が必要です。

少々、コスト増にはなるかもしれませんが、場合によっては、そのまま開発したSierチームがしばらく運用チームとして活躍する調整もありです。

ここまでの流れを一連のPoCの進め方にそって、失敗を未然に防ぐチェックリストにまとめています。「PoCの失敗・疲れを簡単に回避するチェックリスト【具体的手順】」を参照ください。

PoC無茶ぶりすぎる。PoC(概念検証)プロセスの進め方とは?まとめ

PoC(概念検証)の進め方の一般的な工程を紹介しました。

流れは、『ビジネスケース作成 』 → 『 購入or 開発検討 』 → 『 PoC実施 』 → 『 本格開発or導入 』 → 『 運用 』 です。

重要なポイントは、PoC(概念検証)は、ビジネス要求に基づき、技術の適合性を確認する手段であり、PoC自体が目的ではありません。

多くの企業のつまずきは正しいPoCの目的とプロセス理解不足にあります。Facebookの失敗事例等を「PoC(Proof of Concept)失敗事例で学ぶ本質とは?【必見】」の記事で紹介しています。あわせてご覧ください。


✔あわせておすすめ
システム開発で上流工程を上手くさばく方法も、「 『システム開発の失敗』の原因は要件定義!どうすれば回避可能? 」の記事で紹介しています。合わせて参照ください。