PoCとその先にある新規事業を成功に導く3つのメソッド−検証サイクル構築編−

PoCとその先にある新規事業を成功に導く3つのメソッド−検証サイクル構築編−

はじめに 〜本記事について〜

モンスターラボの社員より

ソリューションアーキテクトが起こす、小さな現場革命 〜「炎上案件 ゼロ」を実現する上流工程の仕事術〜 (2023年11月発刊)
ソリューションアーキテクトが起こす、小さな現場革命2 〜「プロジェクト円滑化」を実現するコミュニケーション術〜 (2024年03月発刊)

という2冊の書籍をKindleより出版いたしました。

書籍の出版後、弊社のソリューションアーキテクトに対して、ITサービス開発に関するお問い合わせやご相談が増えており、

  • ・サービスの実現方法が見え、イメージが膨らんだ
  • ・プロジェクトに潜むリスクが早い段階で提案され助かった

といった嬉しいお言葉を多数、頂戴しております。

そんな現役のソリューションアーキテクトから、今回は「新規事業を成功に導くPoCの進め方」をテーマにPoCの正しい進め方や検証結果の評価方法を連載形式でご紹介させて頂きます。

[こんなお悩みを解消します!!]

生成AI、データドリブン、ブロックチェーンなど高度化するIT技術をミニマムでクイックに検証し、新規サービスに組み込めるか検証してみたい。

企画・検討しているサービスがユーザに受け入れられるかを事前に検証し、安心して事業開発を進めたい(そのために必要なPoCの正しい進め方を知りたい)

➡︎【生成AI×モダナイゼーション】ブラックボックス化したシステムを生成AIが紐解く「CodeRebuild AI」

PoCとは?

PoC(読み:ポック / ピーオーシー)は「Proof of Concept」の略語で、よく概念実証や実証実験という言葉で表現されます。新しい概念・理論・アイデアを実際の開発に移す前に、実現可能性や効果を検証する工程のことを指します。
したがって、その目的は「不安を排除し、確証を得る」に集約されます。

  • ・新規で企画しているサービスが技術的に本当に実現できるのか
  • ・利用者にとって本当に必要とされているニーズは何なのか
  • ・市場価値のあるサービスと認め、投資に踏み切るか

新規事業やサービスを企画された経験のある方なら、立ち上げ当初にこのような不安を抱いたことが多いのではないでしょうか?

これらはプロジェクトを遂行する上で避けては通れないリスクであり、もしプロジェクトの途中でこれらの不安が的中してまった場合、ワーストケースではサービスのリリース前にプロジェクトが終了となり、それまでの努力と投資が無駄になってしまうこともあります。

このような最悪のシナリオを避けるため、プロジェクトを正式に開始する前に、その実現性や有用性を検証し、不安を取り除くことを目的に実施するのがPoCです。

★PoCについて詳しくはこちら

PoCの実施イメージ

こちらは弊社のCodeRebuild AIを用いた実際のPoC実施イメージになります。

[注釈]
CodeRebuild AIは、ドキュメントやマニュアルが残っていないレガシーシステムに対して、生成AIを活用した解析を行い、新システムへの刷新をサポートするサービスです。

★CodeRebuild AIについて詳しくはこちら

このときは、AIによるレガシーシステムの解析において人が実際に行う作業と比較して

  • ・時間はどれだけ短縮されるのか?(どれだけコストカットできるのか)
  • ・人の解析結果と同等の精度があるのか?

といったことをプロジェクト発足前にミニマムでクイックに検証することで、クライアントが抱える「AIは使い物になるのか」という不安を払拭したという事例です。

最初にある程度の実現性と方向性が示されれば、プロジェクトの関係者は安心して今後のプロジェクトの進行に注力できます。逆にPoCでサービス構想の実現に避けては通れない課題が見つかった場合は、その課題をクリアするための方法を検討することがプロジェクト成功の最短ルートとなります。

誤解から生まれるPoCのマイナスイメージ

PoCは、プロジェクトの成功確率を高めるための重要なステップであり、新規事項における今後の方向性を決定する貴重な情報源になりえるプロセスです。

しかし、その一方で実際にPoCを実施した人たちのなかには

  • ・実施にコストがかかり、その投資分が無駄になった
  • ・せっかくの企画がPoCで課題がたくさん見つかり、継続が困難になった

といったマイナスイメージや失敗談を耳にすることも、残念ながら少なくありません。

PoCにより様々な成果や成功体験が生まれる一方で、なぜこのようなマイナスイメージや失敗談が生まれてしまうのでしょうか?

その原因の多くは「PoCを実施すれば、新規事業は成功する」といった勘違いから、実施が目的となってしまっているケースにあると考えられます。

確かにPoCを実施し、新規事業開発における不安要素を取り除ければプロジェクトは成功に近づきます。しかし、それは不安要素を排除したからであってPoCを実施したからでは決してありません

目的はあくまで「不安を排除すること」であり、そのための手段としてPoCがあることを忘れてはいけません。

またこれに関連して「PoCをさっと終わらせて、完了という功績をもって新事業開発を早く始めたい」といった事例もこれまで目にしてきました。

これもやはりPoCの実施が目的になってしまっている間違ったケースといえ、正しい検証内容と実行結果をもって、新規事業開発につなげていく、その検証プロセスも非常に重要です。

PoCとその先にある新規事業を成功に導く3つのメソッド

ここまで、PoCの重要性と、その成功には正しい理解と進め方が必要なことを紹介してきました。
では、具体的にどのようにすれば新事業の成功に繋がる正しいPoCを行えるのか?
それは、ここに紹介する3つのメソッドに集約されます。

適正な検証サイクルの構築

構築・検証・フィードバック・評価といったPoCの実施スケジュールと検証サイクルを今回の目的にあわせた適正な形で最初に計画します。

今回はユーザのニーズ調査が主目的なので「検証アプリはモックアプリなど最低限に留め、利用者へのヒアリングに多く時間を費やす」といった目的に応じてどこにお金と時間を投資するのかを決めていきましょう。
また、後ほど詳しく説明しますが検証とフィードバックのサイクルは、最低でも2回構築することをおすすめしています。

定量的な評価指標の事前策定

PoCの成功・失敗を判断するための評価指標を、PoC開始前に定量的な数値で策定しましょう。

これによりPoCの開始から終了まで一貫したブレのない目的が明確になり、結果を正しく評価するとともに関係者にも安心を提供できます。

明確な事業継続の判断基準

たとえITベンダーとクライアントの現場メンバーがPoCの結果に満足したとしても、実際の利用者や投資を行う重要ステークホルダーが、その結果に満足していないと新規事業の継続は暗礁に乗り上げてしまうでしょう。

独りよがりの検証にならないためにも、新規事業の継続判断に必要なステークホルダーが誰で、いつ会話して、どのように新規事業の継続を判断するのかを計画しましょう。

今回の記事では、この3つのなかでも「適正な検証サイクルの構築」をテーマに、PoCの開発・検証プロセスにおいて、どのような進め方をするのがよいか、実際の失敗事例と成功事例を比較しながら見ていきます。

[注釈]
本ブログは連載形式となっており、他2つのテーマは次回以降に順次公開していきます。
第2回はこちら

➡︎【生成AI×モダナイゼーション】ブラックボックス化したシステムを生成AIが紐解く「CodeRebuild AI」

PoCにおける適正な検証サイクルの構築

それでは、ここからは3つのメソッドのうち、PoCにおける適正な検証サイクルの構築についてくわしく解説していきます。

失敗談:目的と手段の入れ違い(PoC完遂が目的に…)

まずは失敗談として、これは新規で企画しているアイディやアプリの機能が、利用者にどれだけ受け入れられるかをデモやアンケートを用いて検証したニーズ調査の事例です。

ニーズ調査における検証実施までの進め方は間違っておらず、1回目の検証ではユーザから高評価を得られた収穫もありましたが、逆に指摘や改善要望など課題もいくつか見つかりました。

ここで本来なら見つかった課題に対して分析を行い、対策を立て、必要に応じて2回目の検証を行うことで、その課題が解消されるかを確認する必要があります。

しかし、実際には課題は放置されたまま、得られた収穫部分だけを「成功体験」として評価し、早々にPoCを完了させ本開発に移行してしまったのです。

これは先にも記載したPoCの実施および完了が目的となってしまった、より具体的なケースであり、結果として本開発でリリースされたサービスではPoCで見つかったときと同じ課題がユーザから指摘され、決して満足度の高いものとはいえないものでした。

せっかくPoCで新規事業を成功させるための課題が得られていたのに、それを放置し繰り返してしまうことは非常に残念です。

成功事例:AIのフィッティング検証

次に成功事例として、こちらは今回の記事で冒頭でも少しご紹介した、弊社のCodeRebuild AIを用いたPoCの事例になります。

このときの課題およびクライアントの不安要素は

  • ・時間はどれだけ短縮されるのか?(どれだけコストカットできるのか)
  • ・人の解析結果と同等の精度があるのか?

といった生成AIがクライアントの既存システムに本当にフィットするのか?といったものでした(未知なるAI技術に投資をするわけですから当然不安と言えますね)。

最低2回の検証サイクルを用いて不安を完全に払拭

PoCを実施する場合、最低でも2回の検証サイクルを実施することを推奨しています。

これは1回目のPoC検証では、やってみて初めてわかる収穫や課題が多く見つかるという考え方に起因しています。

やってみたからこそ得られた課題に対して、それらが本開発でプロジェクトの進行を妨げる足かせにならないよう、課題の分析と対策を検討し、2回目の検証で払拭できるかを検証します。

実際に今回のPoCでも、1回目の検証では生成AIが上手く結果を残せなかった部分が目立ち、かつ人の解析と比較して時間も要したという結果が得られました。

これらの課題に対してフィードバックとして「なぜ、起きたのか」「それは解消できるのか」を分析・検討し、いくつかの対策案を用いて2回目の検証を行いました。

結果として、2回目の検証では1回目と比較して解析精度は格段にあがり、人が0から既存システムを調査するよりも時間の短縮が見込まれることが証明されました。

この2回目の検証で有益とされた手法はもちろん本開発でも利用可能であり、この結果をもってクライアントは安心して今回のプロジェクトへの生成AI導入を決断するに至りました。

この成果および評価は検証サイクルを2回組んだからこそであると言えます。

技術検証による時間生産性は検証を2回やって初めてわかる

今回の生成AIを用いた検証もそうでしたが、新技術導入による生産性の評価については、1回の検証で正しい評価を得るのが難しく、検証を2回以上やって初めて正しい数値が得られます。

これは初回の検証では評価対象のシステムに新技術を初めて導入することの初期コストがかかります。また、それらを操作する人も初めての導入で不慣れな点が多く作業に時間がかかってしまいます。

これが2回目となれば初期導入コストは抑えれますし、人の操作にも慣れが生じてくるので生産性は確実にあがると言えます。

実際の新規事業では、初期導入時ほどの時間を要さないが、人の入れ替わりもあると想定するなら、例えば1回目と2回目の中間を生産性とするなどすれば、正しい値と評価が行えそうですね。

➡︎【生成AI×モダナイゼーション】ブラックボックス化したシステムを生成AIが紐解く「CodeRebuild AI」

まとめ

技術の進歩とともに高度化するITサービスとその新規事業開発において、ミニマムでクイックに検証を行うための手段としてPoCは有益な選択肢の1つであり、プロジェクトの方向性を決定するための貴重な情報を提供してくれます。

その方向性にブレを生じさせず、新規事業開発に必要な情報をより多く得るためのメソッドとして、今回は適正な検証サイクルの構築について紹介させて頂きました。

まとめるとこのような形で「計画→構築→検証(検証・フィードバック・チューニング・再検証)→最終評価」のプロセスと、今回の目的に合わせた評価サイクルを適切に構築することが重要になってきます。

➡︎【生成AI×モダナイゼーション】ブラックボックス化したシステムを生成AIが紐解く「CodeRebuild AI」

関連情報ご紹介

本記事に関連して、弊社新サービスのご案内とソリューションアーキテクトが提供する各メディアの情報をご案内いたします。ご興味持たれた方はぜひ関連情報もご覧ください。

CodeRebuild AIがレガシーシステムの刷新を加速度的にサポート

CodeRebuild AIは、レガシーシステムの刷新に不可欠な古いコードの書き換えを支援するサービスです。

  • ・ドキュメントがなく、ブラックボックス化しているレガシーシステム
  • ・増改築を繰り返し、コードが複雑化してしまいメンテナンスが属人化しているシステム

を抱えてお困りではないでしょうか?

設計情報の復元を人のみで行う場合、専門性のある人材が複数名必要で、人材の確保と工数の増大が懸念されます。

CodeRebuild AIを活用すると、システム構造の把握がクイックに可能で、コードの変換においても構造を捉えたコード生成が可能です。これにより、刷新の実現性を検証し、従来よりも検証期間を短縮、品質を保ちながらコストも抑えられます。

本格的なシステム刷新、モダナイゼーションの実現性を確かめるPoCの手段としてCodeRebuild AIを活用してみませんか?

★CodeRebuild AIについて詳しくはこちら

新規事業を成功に導くソリューションアーキテクト

最後に今回の記事を執筆させて頂いた弊社ソリューションアーキテクトが提供するメディア情報についてご紹介させて頂きます。

セミナー開催のご紹介

新規事業を企画、検討中の方々は、PoCについてどのような印象をお持ちでしょうか?

昨今の新規事業開発においては、最新AI技術を既存業務に適用させるなど、革新的な技術を活用したい反面「それらを適切に活用できるのか?」「リスクはないのか?」といった不安を抱えている方も少なくないでしょう。
このような現代のITサービス開発において、初期段階でアイディエーションやPoCを導入することは、その後の新規事業開発を成功に導くための有効な手段の一つです。
本セミナーでは、現役のソリューションアーキテクトが、新規事業開発を成功させるためのPoCの有効活用方法や、サービス全体を成功に導くためのメソッドについてご紹介します。

書籍のご紹介

これまで以下の2冊の書籍を出版させて頂いており「新規事業開発における上流工程の正しい進め方」と「プロジェクトにおける円滑なコミュニケーション術」を紹介する内容となっております。

もし、PoCの先にある新事業開発の進め方にお悩みを抱えておりましたら、お手にとって頂けますと幸いです。

ソリューションアーキテクトが起こす、小さな現場革命 〜「炎上案件 ゼロ」を実現する上流工程の仕事術〜 (2023年11月発刊)
ソリューションアーキテクトが起こす、小さな現場革命2 〜「プロジェクト円滑化」を実現するコミュニケーション術〜 (2024年03月発刊)

サービス・プロダクト開発を検討している企業ご担当者様へ

モンスターラボは、約20年にわたるサービス・プロダクト開発実績から得られたデジタル領域の知見や技術力を活かし、デジタルプロダクト開発事業を展開しています。

先端テクノロジーに対応した高度なIT人材があらゆるプラットフォーム上での開発を支援します。アジャイル開発とDevOpsによる柔軟な開発進行や、国内外のリソースを活用したスケーラブルな開発体制の構築も可能です。 また、リリース後の保守運用や品質向上支援まで伴走可能です。

モンスターラボが提供するサポートの詳しい概要は以下リンクをご確認ください。

➡︎モンスターラボのサービス概要はこちら

案件の相談はこちら

直近のイベント

記事の作成者・監修者

松下 智弘(株式会社モンスターラボ ソリューションアーキテクト エンジニアリングマネージャー)

松下 智弘(株式会社モンスターラボ ソリューションアーキテクト エンジニアリングマネージャー)

SIベンダーにて組込みエンジニアとしてキャリアをスタート。ここ数年はIoT系の新サービスを自ら立ち上げ、販売戦略策定・顧客訪問・セミナー開催・アーキテクチャ設計などサービスリリースに必要な工程を幅広く経験した後、22年にモンスターラボに入社。モットーは「クライアントのご要望を最適な形で実現する」