LASSIC Media らしくメディア

2018.04.01 事例紹介

初心者でも分かる「PoC（概念実証）」と支援パートナーの選び方

PoCとは？

PoCとは、Proof of Concept、概念実証の略で、あるコンセプト（概念）の実現可能性を検証することを言います。

新たな概念やアイデアの実現可能性を示すために、簡単かつ不完全な実現化（または概要）を行うこと。 あるいは原理のデモンストレーションによって、ある概念や理論の実用化が可能であることを示すこと。
出典：Wikipedia（概念実証）

POCとは、新しい概念や理論、原理などが実現可能であることを示すための簡易な試行。一通り全体を作り上げる試作（プロトタイプ）の前段階で、要となる新しいアイデアなどの実現可能性のみを示すために行われる、不完全あるいは部分的なデモンストレーションなどを意味する。
出典：IT用語辞典e-Words（POC）

PoC（概念実証）自体は、さほど新しい概念ではありません。

医薬品業界では新薬の開発の初期段階において、ある成分が特定の疾病の治療に有効なのではないか、という仮説を検証しますし、映画業界でも、“このCG技術を使えばこんなに斬新で面白い映画が作れる”といったコンセプトを制作会社や投資家、配給会社にプレゼンするためにその技術を使った短い映像を制作する、といったことが行われてきました。

しかし近年はビジネス環境の変化が激しくなり、さまざまな業界で新たな技術や領域へ進出をはかる動きが活発化し、PoC（概念実証）を実施することが増えたことで、広く知られるようになってきました。

特にIT、デジタル化の分野においては、これまで「業務効率化」が主な目的であったのに対して、既存路線にない「新規・サービスや事業開発を目指す」という目的に変化したことで「不確実性」が増し、PoCの実行は欠かせないプロセスとなりつつあります。

「不確実」な事柄を「確実」にするプロセス、それが「PoC（概念実証）」なのです。

失敗する「PoC」、成功する「PoC」

PoC（概念実証）に取り組んだ多くの企業の中には、無事に課題解決に成功した企業がある一方で、成果に結びつかず疲弊してしまった企業もあり、「PoC疲れ」などという言葉も生まれたほどです。

失敗するPoCと、成功するPoC。
その違いはどこにあるのでしょうか？

失敗するPoC

PoCは、実証したいコンセプトによって進め方も内容も大きく異なるため一概に言えない部分もありますが、一般的に多い失敗例のポイントをあげてみたいと思います。

●ゴールが明確になっていない

PoCを始めるにあたって、その目的や評価軸、期間、投資可能コストを明確にしていないケースです。たとえば、AI導入について検証するPoCでAI導入自体が目的になっているなど、PoCを行う目的が、PoCを行うこと自体やプロトタイプを作ること、何らかの技術を導入することになっていたりするのです。
本来は、何らか解決したい事業上の課題があり、その課題を解決するための手段としてAIが想定されるから検証するのですから、そのAI導入が本当に課題を解決するのか？がPoCで確認すべきことであり、検証の結果、課題解決につながらないならば、AI導入は見直されるべきです。
しかし、AI導入自体が目的となってしまっていると、AI導入そのものを見直すという結論を出すことはできません。
また、投資の上限コストを設定しておらず、良い結果が得られるまでPoCを繰り返しているうちに、とんでもなく費用が膨らんでいた、という事例は、特に資金力がある企業に見られるケースです。

また、安易に他社の事例を真似してしまうケースもあります。 ニュースやプレスリリースなどで他社の事例を見て、「うちもこれで行こう！」とゴールに設定して進めてしまうのです。
しかし、目にした他社事例が必ずしもその会社の課題を解決できているわけではないこともありますし、さらに言うと、マネタイズできていないケースも多いのです。

●検証の優先順位が適切でない

例えば技術ありきで発想されたコンセプトのPoCでは、技術的な実現性ばかりにフォーカスしてしまうことがあります。
いくら技術的に実現可能でも、戦略上の効果・効用が意図した通りに見られないのであれば、コンセプト自体を見直さなければならないので、戦略上の効果・効用の検証や、そもそもの課題を真に解決するのかどうかの検証を優先しなくてはなりません。

●PoCが成功する前提で計画が進んでいる

PoCは、「コンセプトそのものの検証を行うプロセス」なので、検証の結果、前提から再考が必要になることは大いにあります。検証→再考→再検証を繰り返す、PDCA（Plan・Do・Check・Action）を回して行くのがPoCですから、コンセプトが課題解決につながらないことを想定していないと、プロジェクトが行き詰まるか、人員・資金の投入計画も大きく狂ってしまいます。

●ステークホルダーの理解が得られていない

PoCが終わっていざ事業化、いざ導入、という段階で、現場や他部署からの反発に合うというパターンです。
反発の調整に手間取って時機を逃せば、計画がとん挫することもあり、それによる社内の混乱や士気の低下などのファクターまで考えれば、損失は多大です。

●現場の運用まで設計していない

コンセプトが具現化した場合に、誰が、いつ、どのように使うのか？といった、現場に関わる具体的な事柄が設計できていないと、実際に導入したのに使われない、使えない、という事態が起こり得ます。

●パートナーの選び方が適切でない

PoCは投資段階であるため、自社で十分な人員や知見、スキルがないことは大いにあり、その場合は、パートナーと進めるのが一般的です。
「PoC支援サービス」を提供する企業も増えてきましたが、それぞれに強み・弱みがあるため、自社の状況・課題に合ったパートナーに外注しないと悲劇を招きます。

失敗例としては、下記のようなパターンがあります。

「本当は、リーン（無駄なく）でミニマルなPoCを行いたかったが、気づいたら、タスクもパートナーのチーム規模も拡大しており、費用もうなぎのぼりになってしまった」
「コンサルティング力は高いが、プロトタイプの開発ができない」
「システム開発力を評価していたパートナーだったが、ビジネス化や戦略レベルの話ができない」
「コアな先端技術力は高いが、システム化・Web化を行う際の具体的な知見・経験が不足している」
「提示するコンセプトが曖昧・抽象的だと、具体化や絞り込みができず、プロジェクトが進まない」

助けてもらうはずが、トラブルに発展することもあり、ぜひとも避けたいところです。

PoC成功のポイント

それでは、成功するためにはどうしたら良いのか？
「成功するためのポイント」を確認していきましょう。

●ゴール・期間・コストを明確にする

  • ゴールを適切に設定する

    ゴールを設定する際には、「イシュードリブン（課題先行）型」で行う、つまり、「自社が解決すべき課題は何なのか」からスタートすることが重要です。
    なお、ゴールはできるだけ定量化します。
    もちろん、定性的なゴール設定もありえますが、定性的なゴールを設定する場合は、「誰が」「どのように」判断するかを明確にしておきましょう。
    また、PoCは知見を蓄積できるプロセスでもあるので、結果に関わらず必ずフィードバックを行い、後に生かせるようにすることも大切です。

  • できるだけ小さく、「スモールスタート」で行う

    不完全でも良いから、とにかく「実証」するために行うのが、PoCです。
    PoCの段階で必要以上のディティールやクオリティを求めすぎると、まさに「PoC疲れ」一直線になってしまいます。
    コアコンセプトの実現性や課題解決の検証という本来の目的に立ち戻り、細部は切り捨てていかなくてはならないため、どこまでを検証し、どこから切り捨てるかという線引きをしましょう。

  • 長期化することを想定する

    小さく検証することを繰り返して行くので、結果的に成果が得られるまでが長期化することはありえます。
    長期化することを想定したスケジューリングを行いましょう。

●検証するポイントに適切な優先順位をつける

検証のポイントと、その優先順位は、検証したいコンセプトの「不確実性」が何であるかによって大きく異なるため一概に言えませんが、代表的なものをまとめると以下の三点になります。

  1. 効果・効用の検証
    設計したコンセプトがそもそもの課題を解決するか、意図した戦略上の効果・効用を発揮するかの検証
  2. 技術的実現性の検証
    コンセプトが技術的に実現可能かどうかの検証
  3. 具体性の検証
    コンセプトを実現する上で必要となる仕様や課題は何かの検証

技術的に実現可能であることが分かっても、戦略上の効果がなければ意味がないので、検証の優先順位も、1.から順に行います。

●ステークホルダーの理解を得る

現場や関連部署のキーパーソンとは事前にしっかり合意形成を行い、できる限りPoCを実行するチームのメンバーに入ってもらうことが望ましいでしょう。
また、ビジネス課題を解決しているかどうかを判断できる責任者はPoCにおいて非常に重要です。必ず実行チームに入ってもらうようにしましょう。

●現場の運用まで設計に入れる

具現化・導入の前に、検証したいコンセプトの「現場」を設計するプロセス（前述の3.）が必要です。

例えば下記のような内容です。

  • 誰が、いつ、どういう業務で、何を目的として、何を使うか
  • 設置場所はどこにするか
  • どのような業務フローで、既存のどの業務フローに組み込むか

実際に現場を運用する部門からPoCチームにメンバーをアサインし、運用設計を担ってもらうのが一番確実な方法です。

●適切なパートナーを選び、支援してもらう

自社にない要素は、外から調達する必要があります。人員なのか、戦略家なのか、技術者なのか、PoCの内容と自社の状況に応じて、適したPoC支援会社（パートナー）を選択しましょう。

失敗しないパートナー選び

それでは、PoCの支援会社（パートナー）は、どのようなポイントで選べばいいのでしょうか？

前述の失敗例から抽出すると以下のようなポイントがあげられます。

  • 合理的でリーンなPoC計画を組める
  • 費用の算出基準が明確である
  • 「コア技術の知見がある」「ビジネス戦略立案力がある」「コンセプトを、システムやWebに展開する開発力がある」「プロジェクトをリードする力がある」など、自社に足りない力を持っている
  • まだ自社で明確になっていない「抽象的な要望」をカタチにできる

選定にあたっては、どのようなパートナーが適切なのかを知るため、自社の状況・課題を客観的に把握する必要があります。
パートナーに補完してもらいたい事柄が明確になったら、その会社のコアナレッジや、強み・弱みを理解し、必要な要素を満たしているかしっかり見極めましょう。

「最後は相性」とよく言われます。
営業担当者だけでなく、実際にプロジェクトを担当するリーダーや担当者、できれば代表者にも会い、相性の良さを確認するのが理想です。

ビジョンや理念に共感し、熱意を持って伴走してくれる、仲間としてのパートナーをぜひ見つけたいものです。

以上、成功するPoCと、失敗するPoCについて、ポイントをまとめてみましたが、いかがだったでしょうか。
これからPoCを行う方にも、すでにPoCを実施しているが良い結果が得られないという方にも、お役に立てれば幸いです。

お問い合わせはこちら

株式会社LASSICは、「らしく」の実現をサポートする」を企業理念に、創業来、「顧客の“ふわっ”としたニーズから新価値を生み出し、喜ばれ、選ばれる企業に」なること目指し、事業に取り組んでいます。
「何となくのアイデアしかない」「具体的な道筋が見えていない」といった場合でも、弊社コンサルタントやエンジニアが、具現化のお手伝いをいたします。
どうぞお気軽にご相談ください。

株式会社LASSIC　～鳥取発～ITで、地方創生

https://www.lassic.co.jp/
IT事業部
Tel：0857-54-1070
お問い合わせフォーム　https://www.lassic.co.jp/contact/
Mail：contact@lassic.co.jp
拠点所在地：鳥取(200本社)・秋田・仙台・東京・大阪・姫路・米子・岡山・広島・福岡

●実績例

  • データ分析：BPO支援企業様における採用データ解析
  • PoC実施：医療機関のAI・IoT化（ロボット病棟プロジェクト）の PoC実施
  • AI活用支援：テレビ局様における音声認識・字幕生成AI開発
  • AI活用PoC支援：音響メーカー様におけるAIモデル開発
  • AI活用支援：ロボット開発企業様におけるAI連携API開発

●参考・出典

LINEで送る

こちらの記事もおすすめ

テレワークで問われる「ローコンテクストコミュニケーション」への対応力

2020.10.05
リモートワークコラム

【在宅勤務あるある】テレワークの服装と過ごし方

2020.04.20
リモートワークコラム

吉本興業で35年！竹中イサオの“泣く子も笑う”処世術-Vol.15

2017.01.05
らしくコラム

ニーズに合った優秀な人材を全国から登用できるので、依頼できる仕事の幅もますます広がると期待しています！

2015.11.14
お客さまの声

バックナンバー

Category
Home/らしくメディア/事例紹介/初心者でも分かる「PoC（概念実証）」と支援パートナーの選び方
View