PoC地獄は、なぜ起きるのか
前回の記事では、IT投資について「何をもって成功とするのか」を、投資を始める前に決めておくことの重要性について考えました。
システムが完成したからといって、そのIT投資が成功したとは限りません。
・期待していた業務上・経営上の成果が実現したのか。
・投じた費用に見合う価値が得られたのか。
・そして、途中で前提が変わった場合にも、なお投資を続ける
合理性があるのか。
そうしたことまで含めて考える必要があります。
しかし、新しい技術や新しいシステムへ投資しようとすると、
もう一つ難しい問題があります。
本格的な投資をする前には、「本当に実現できるのか分からないことが多い」という問題です。
そこで行われるのが、PoC（Proof of Concept：概念実証）です。
いきなり大規模なシステムを作るのではなく、小さく試してみる。
・技術的に実現できるのか。
・想定している業務で利用できるのか。
・期待している効果が得られそうなのか。
こうした不確実性を、本格投資の前に確認する。
一見すると、非常に合理的な方法です。
ところが現実には、PoCを行ったにもかかわらず、本番導入へ進めない。
・PoCをもう一度行う。
・別の条件でも試す。
・別の製品でも試す。
・さらに検証する。
そうして、いつまでも本格的な投資判断ができない。
いわゆる「PoC地獄」と呼ばれる状態に陥ることがあります。
なぜ、小さく試すために始めたPoCが、今度は新たな問題を生み出してしまうのでしょうか。
今回は、この問題について考えてみたいと思います。
1．PoCが成功しても、本番導入できない
PoCでは、よく「成功」という言葉が使われます。
「予定していた機能が動いた」「一定の精度が確認できた」。
「利用者から良い評価を得た」「技術的には実現可能だと分かった」。
これらは、PoCとして重要な成果です。
しかし、ここで考えなければならないことがあります。
PoCが成功したことと、本格投資へ進むべきことは、同じなのでしょうか。
たとえば、小規模な環境では問題なく動いたアプリがあったとします。
しかし、本番導入するとなれば、利用者は数十人から数千人になるかもしれません。
・大量のデータを扱わなければならない。
・既存システムとの連携が必要になる。
・認証、権限管理、セキュリティ、監査、バックアップ、
障害対応も必要になる。
・運用する人員も必要です。
さらに、PoCでは数百万円だったものが、本番化すると数千万円、場合によっては億単位の投資になることもあります。
つまり、「技術的に動くこと」と「企業の本番システムとして成立すること」。「そこまで経営資源を投入する価値があること」は、別の問題です。
私は、ここを分けて考えることがPoC地獄を理解する第一歩ではないかと思います。
2．PoCで証明したものと、経営が知りたいことが違う
PoCでは、ある問いに答えます。
「この技術で実現できるか」。
しかし、本格投資を判断する経営側が知りたいのは、
それだけではありません。
・本当に業務で利用できるのか。
・どの程度の便益が得られるのか。
・本番化にはいくら必要なのか。
・導入後には、どの程度の運用費がかかるのか。
・どのようなリスクがあるのか。
・組織として運用できるのか。
・ほかの投資案件と比較しても、ここへ経営資源を投入するべきなのか。
こうしたことが分からなければ、本格投資の判断はできません。
つまり、PoCでは答えが出た。
しかし、次の投資判断に必要な問いには答えていない。
この状態が起きます。
すると、「PoCは成功しました」という報告に対して、「では、本番開発に進みましょう」とはならず、「もう少し確認した方がよいのではないか」となります。
そして次のPoCが始まります。
3．PoCを始める前に「次に何を判断するのか」が決まっていない
ここに、PoC地獄の大きな原因があるように思います。
PoCを始めるときには、「何を試すのか」は比較的よく考えます。
しかし、「このPoCが終わったあと、何を判断するのか」まで決められているでしょうか。
・本格投資へ進むのか。
・方式を変更するのか。
・範囲を縮小するのか。
・別の方法を検討するのか。
・それとも、この投資自体を中止するのか。
本来、PoCはこうした判断のために行うはずです。
ところが、「まず試してみよう」という形でPoCが始まると、
PoC終了後の判断まで設計されていません。
その結果、検証によって新しい疑問が出るたびに、
「では、それも試してみよう」となります。
・疑問があるからPoCをする。
・PoCをすると新しい疑問が出る。
・その疑問を確認するため、またPoCをする。
これでは、理論上PoCはいつまでも続けられます。
4．成功条件だけでなく、「次の判断条件」が必要になる
前回の記事で、IT投資には成功条件が必要だと書きました。
PoCにも同じことがいえます。
何が確認できれば、このPoCは成功なのか。
何が確認できなければ失敗なのか。
しかし、PoCの場合には、もう一つ必要だと考えます。
PoCの結果によって、次にどの判断をするのかという条件です。
たとえば、以下のような判断が条件となります。
・一定の技術的条件を満たし、期待する業務効果が確認でき、
本番化した場合の費用が許容範囲内であれば、本格投資へ進む。
・技術的には成立するが費用が大きすぎるのであれば、方式を変更する。
・効果はあるが特定条件で重大なリスクが残るのであれば、
そのリスクだけを追加検証する。
・必要な便益が期待できないのであれば、中止する。
このように、PoCの結果と次の判断をつないでおく必要があります。
PoCを「成功か失敗か」だけで終わらせず、「成功したら何をするのか。
失敗したら何をするのか。どのような場合に追加検証をするのか」
まで考えておく。
そうしなければ、PoCが終わっても判断は始まりません。
5．本番化して初めて現れる問題を、PoCでは見ていない
PoC地獄には、もう一つ原因があります。
PoCを成立させるために、検証範囲を小さくしすぎることです。
もちろん、PoCは本番システムではありません。
最初から本番と同じ品質や機能を作ってしまえば、小さく試す意味がなくなります。
しかし、本番化すると重大な問題になる部分まで検証対象から外してしまえば、PoCが成功しても投資判断には使えません。
たとえば、本番では大量のデータを扱うのに、少量データだけで検証する。
複数システムとの連携が必要なのに、単体でしか試さない。
全社利用を想定しているのに、数人だけで評価する。
実運用では継続的な保守が必要なのに、作ることだけを検証する。
セキュリティや権限管理が重要なのに、それを後回しにする。
こうした状態では、PoCによって「動くこと」は分かっても、
「本番で成立すること」は分かりません。
大切なのは、PoCで本番システムを作ることではありません。
本番化したときに投資判断を左右する重要な不確実性を、
PoCの段階で見つけておくことだと思います。
6．PoCの成功を「本格投資の承認」と混同しない
逆の問題もあります。
PoCが成功すると、そのまま本格投資へ進まなければならないような
空気が生まれることがあります。
しかし、これは本来おかしなことです。
PoCで技術的実現可能性が確認されたとしても、本番化費用が想定を
大きく超えているかもしれません。
期待していた便益が小さいことが分かるかもしれません。
現場で利用するためには、大きな業務変更が必要になるかもしれません。
別の方法で同じ成果を、より安く実現できることが分かるかもしれません。
その場合、「PoCは成功した。しかし本格投資には進まない」という
判断があってもよいはずです。
これはPoCの失敗ではありません。
むしろ、大きな投資をする前に「進むべきではない」ということを
確認できたのであれば、PoCは重要な役割を果たしたことになります。
PoCの役割は、本格投資を正当化することではありません。
本格投資へ進むべきかどうかを、より良く判断できる状態を作ることです。
7．「小さく試すこと」と「PoCを繰り返すこと」は違う
IT投資には不確実性があります。
将来を完全に予測することはできません。
だから、大きな判断を一度に行うのではなく、小さく試し、
結果を見ながら判断を修正していくことには大きな意味があります。
しかし、ここで注意しなければならないことがあります。
小さく試すことと、PoCを繰り返し続けることは同じではありません。
小さく試す意味は、判断を先送りすることではありません。
判断が外れたとしても致命的な損失にならない範囲で行動し、
その結果から学び、次の判断をより良いものへ修正することにあります。
つまり、判断する。小さく行動する。結果を見る。そこから学ぶ。
そして、次の判断をする。
この循環が重要なのだと思います。
PoCは、この中の「小さく行動する」ための一つの方法です。
PoCそのものが目的ではありません。
8．PoCの後に「判断」がなければ、学習は前に進まない
ここから考えると、PoC地獄の構造はかなり単純に表せるように思います。
本来であれば、以下のような流れになるはずです。
投資判断
↓
PoC
↓
結果
↓
評価・学習
↓
次の投資判断
ところがPoC地獄では、以下の循環になっています。
PoC
↓
結果
↓
追加検証
↓
PoC
↓
結果
↓
さらに追加検証
もちろん、追加検証そのものが悪いわけではありません。
PoCによって重大な新しい不確実性が見つかり、それを確認しなければ
次の判断ができないのであれば、追加検証には意味があります。
問題は、「何が分かれば判断できるのかが決まっていないまま、
安心できるまで検証を続けること」です。
不確実性をゼロにすることはできません。
どこかの時点で、「この情報で進む」「条件を変える」
「これ以上は投資しない」という判断をしなければなりません。
9．PoCを始める前に、本当に決めるべきこと
私は、PoCを始める前には、少なくとも次のことを決める必要がある
と考えています。
このPoCの後に、何を判断するのか。
その判断を妨げている不確実性は何なのか。
何を確認すれば、その不確実性を十分に減らせるのか。
どの結果なら進み、どの結果なら修正し、どの結果なら中止するのか。
最後に、その判断を誰が行うのか。
この五つが決まれば、PoCの意味はかなり明確になります。
逆に、この五つが決まっていなければ、いくらPoCを精緻に実施しても、
終了後にまた新しい議論が始まる可能性があります。
PoCを設計するということは、実験内容だけを設計することではない。
「PoCの後に行う意思決定まで設計すること」なのだと思います。
10．PoC地獄とは、検証の問題ではなく意思決定の問題ではないか
PoC地獄という言葉を聞くと、「PoCをやりすぎている」「技術検証ばかりしている」という問題に見えます。
しかし、もう少し遡って考えると、違う姿が見えてきます。
PoCを何度も行うこと自体が、本質的な問題なのではありません。
そのPoCによって、「何を明らかにするのか」。
「何を判断するのか」「どの条件なら進むのか」。
「どの条件なら止めるのか」「そして誰が判断するのか」。
これらが定められていないために、
PoCから次の投資判断へ進むことができない。
私は、PoC地獄の本質はここにあるのではないかと考えています。
前回の記事では、IT投資について「何をもって成功とするのか」を最初に決める必要があると書きました。
PoCについても同じです。
ただし、PoCの場合は成功条件だけでは足りません。
その成功や失敗を、次の投資判断へどうつなぐのか。
そこまで最初に考えておく必要があります。
PoCは、何度も試すための仕組みではありません。
大きな投資をする前に重要な不確実性を減らしながら、
次の4つを判断するための仕組みだと考えます。
１．進むのか。
２．修正するのか。
３．もう一度限定的に確認するのか。
４．それとも止めるのか。
小さく試すことの本当の価値は、小さく失敗できることだけでは
ありません。
その結果を使って、次の判断を修正できることにあります。
PoC地獄から抜け出すために必要なのは、
もっと多くのPoCを行うことではない。
PoCを、次の意思決定へつなぐこと。
IT投資を経営として管理するのであれば、PoCもまた、
投資判断の仕組みの中に位置づける必要があるのではないでしょうか。
