PoCとその先にある新規事業を成功に導く３つのメソッド−評価指標策定編−

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

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

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

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

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

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

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

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

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

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

前回までのあらすじ

前回の記事ではPoCの必要性と検証サイクルの構築について詳しく紹介させて頂きました。

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

ここでは簡単に前回までの内容を振り返りながら、今回のテーマについてご紹介させていただきます。

PoCとは？

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

したがって、その目的は「不安を排除し、確証を得る」に集約されます。

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

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

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

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

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

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

新規事業を成功を導くためにPoCで最大限の効果と結果を得るには、PoCへの正しい理解と進め方が必須となります。
では、具体的にどのようにすれば新事業の成功に繋がる正しいPoCを行えるのか？
それは、ここに紹介する３つのメソッドに集約されます。

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

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

また、前回の記事でもご紹介させて頂いた通り、検証とフィードバックのサイクルは、最低でも２回構築することがおすすめです。

★検証サイクル構築編はこちら

【！！今回のテーマ！！】定量的な評価指標の事前策定　

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

これによりPoCの開始から終了まで一貫したブレのない目的が明確になり、結果を正しく評価することで関係者にも安心を提供できます。
今回はこのメソッドについて後ほどより詳しく紹介していきます。

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

たとえITベンダーとクライアントの現場メンバーがPoCの結果に満足したとしても、実際の利用者や投資を行う重要ステークホルダーが、その結果に満足していないと新規事業の継続は暗礁に乗り上げてしまいます。
独りよがりの検証にならないためにも、新規事業の継続判断に必要なステークホルダーが誰で、いつ会話して、どのように新規事業の継続を判断するのかを計画しましょう。

PoCにおける定量的な評価指標の策定

ここからは、今回の記事テーマである「定量的な評価指標の事前策定」について、失敗談と成功談をそれぞれ比較する形で詳しく見ていきましょう。

失敗談：PoCの目的と検証項目がブレてしまったケース

まずは失敗談として、これは会議の内容をAI OCRによって検証したPoCの事例で、具体的には会議の音声データをAIが解析し、文字起こしによって議事録を自動で作成するというものです。

開始当初は本プロジェクトにおける一番の課題は「AIによるOCR（文字起こし）が本当に実用的なのか？」にあると考え、この精度を検証する目的でPoCを開始しました。

この考えやPoCへの取り組みは非常によいものでした。
しかし、実際にPoCを開始すると「録音自体がやりにくい」といった課題が会議の現場から多く集まり、その声に応えようとした結果、検証内容が「利用者の要望を満たす録音方法は？」に途中から入れ替わってしまいました。

最終的には本来は一番時間をかけて検証すべきであった「AIは実用的なのか？」の検証が不十分で曖昧なままPoCの期限を迎えてしまうことに・・・。

このようにPoCを実施していくと現場の声を中心に新たな課題が浮き彫りになり「その課題も検証しないと」という焦りの気持ちが芽生え、本来解決すべきだった課題が疎かになってしまうというケースがよくあります。
しかし、当初の目的が達成できないことは本末転倒であり、仮に他の課題が見つかった場合は「プロジェクト正式発足後に解決」「別途、PoCを実施」など解決の代替手段を検討し、当初のミッションの達成を最優先に考えるべきです。

PoCに軸を通す定量的な評価指標

先程の失敗事例のようにPoCの実施内容にブレが生じ、当初の目的を見失ってしまうような事態をどうやって防げばよいか？
それは、PoCの最初に行う計画段階で「今回のPoC検証で何を検証するのか？」といった検証目的や内容をしっかり吟味し、PoCの成功有無を評価・判断できる基準をしっかりと策定することが大切であると私は考えます。

仮にPoCの途中で新たな課題が発生した場合でも、PoCの成功有無を判断する基準が明確に決まっていれば「それを達成するために必要な行動か？」を判断でき、課題に振り回されることなく目的に向かって走り抜くことが可能になります。

この評価指標は数値で表現されていることが望ましく、新規事業開発を見据えたPoCなら、できる限り定量的評価で達成度を判断できる計画を策定すべきです。
ここからは、その具体例を成功事例から見ていきましょう。

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

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

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

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

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

定量的な評価でAIの有用性を評価

このPoCにおける評価を以下のように行いました。

例えば品質の評価ではPoCによる検証を人とAIそれぞれで実施し、人の解析結果に対してAIの解析がどれほどの差異があるかで精度を測定しました。

上記の通り検証は２回実施し、２回目の検証結果を見ると１回目と比較して解析精度は格段にあがっており誤差９％となっています。

★検証サイクルについて詳しくはこちら

これは１回目の検証結果から精度が悪い原因を解析し、チューニングを行い、その改善効果を検証する目的も含まれていました。
次にAIの網羅性検証では、AIがソースプログラム全体に対して、どの範囲まで解析ができるかを検証しました。

こちらも１回目の検証と比較して、チューニングを行ったことで２回目の網羅性があがっていることがわかります。

このように品質や網羅性といった観点で

• ・品質や網羅性といったどのような観点でPoCの結果を評価するのか
• ・それらの評価項目をどのような数値で測定し、評価を行うのか

といった具体的で定量的な指標を設けたことで「AIによる解析が信頼できるか」をより具体的にブレなく検証できているかと思います。

まとめ：定量的な評価指標の策定ポイントを整理

今回はPoC途中で発生する課題に振り回されることなく、当初の目的に対して正しく検証と評価を行うために必要な定量的な評価指標の策定について説明させて頂きました。

しかし、開発が正式スタートしてない段階から、より具体的で定量的な指標を作るのは難しいのも現実です。そこで最後に過去の事例を元に評価指標の策定例をご紹介します。

評価指標は、PoCの目的ごとに分類分けを行い、段階的に「何を」「どうやって」をイメージできるかで策定・改善していくことが有益と言えます。

実現性の検証であるなら「AIによる解析精度が90%」などとあった場合、パッと見は定量的な評価指標に見えますが少し深堀りしてみると「何を持って90%とするか？」という点が評価しづらい印象があります。
そこで例えば人が実際にやった場合とAIを用いた場合を比較して、その誤差が10%以内を指標とすれば当初の精度90%は「人と比較して」という指標で、検証や比較が進めやすいものとなります。

次にサービスのリプレースなど性能要件などの検証を目的としたPoCの事例を見ていきましょう。

「新規サービスの応答性能がシステム要件を満たす」などについては、どこから・どこまでの時間やアクセス量がといった部分が曖昧で検証中の測定に迷いが生じそうです。

そこで先程と同様に比較対象を定めてみると状況がクリアになります。
上記の図にあるように従来のシステムを比較対象におき「比較して」という形であれば検証も両者を比較しながら進めるイメージがわいてきます。

また応答性能などを見る場合は、単に「５秒など」ではなく「どこから・どこまで」をより具体的に記載しておくことも忘れないようにしましょう。

関連情報ご紹介

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

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

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

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

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

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

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

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

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

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

セミナー開催のご紹介

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

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

書籍のご紹介

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

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

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

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

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

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

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

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

案件の相談はこちら