モンスターラボの社員より
・ソリューションアーキテクトが起こす、小さな現場革命 〜「炎上案件 ゼロ」を実現する上流工程の仕事術〜 (2023年11月発刊)
・ソリューションアーキテクトが起こす、小さな現場革命2 〜「プロジェクト円滑化」を実現するコミュニケーション術〜 (2024年03月発刊)
という2冊の書籍をKindleより出版いたしました。
書籍の出版後、弊社のソリューションアーキテクトに対して、ITサービス開発に関するお問い合わせやご相談が増えており、
といった嬉しいお言葉を多数、頂戴しております。
そんな現役のソリューションアーキテクトから、今回は「新規事業を成功に導くPoCの進め方」をテーマにPoCの正しい進め方や検証結果の評価方法を連載形式でご紹介させて頂きます。
[こんなお悩みを解消します!!]
生成AI、データドリブン、ブロックチェーンなど高度化するIT技術をミニマムでクイックに検証し、新規サービスに組み込めるか検証してみたい。
企画・検討しているサービスがユーザに受け入れられるかを事前に検証し、安心して事業開発を進めたい(そのために必要なPoCの正しい進め方を知りたい)。
➡︎【生成AI×モダナイゼーション】ブラックボックス化したシステムを生成AIが紐解く「CodeRebuild AI」
PoC(読み:ポック / ピーオーシー)は「Proof of Concept」の略語で、よく概念実証や実証実験という言葉で表現されます。新しい概念・理論・アイデアを実際の開発に移す前に、実現可能性や効果を検証する工程のことを指します。
したがって、その目的は「不安を排除し、確証を得る」に集約されます。
新規事業やサービスを企画された経験のある方なら、立ち上げ当初にこのような不安を抱いたことが多いのではないでしょうか?
これらはプロジェクトを遂行する上で避けては通れないリスクであり、もしプロジェクトの途中でこれらの不安が的中してまった場合、ワーストケースではサービスのリリース前にプロジェクトが終了となり、それまでの努力と投資が無駄になってしまうこともあります。
このような最悪のシナリオを避けるため、プロジェクトを正式に開始する前に、その実現性や有用性を検証し、不安を取り除くことを目的に実施するのがPoCです。
★PoCについて詳しくはこちら
こちらは弊社のCodeRebuild AIを用いた実際のPoC実施イメージになります。
[注釈] CodeRebuild AIは、ドキュメントやマニュアルが残っていないレガシーシステムに対して、生成AIを活用した解析を行い、新システムへの刷新をサポートするサービスです。 |
★CodeRebuild AIについて詳しくはこちら
このときは、AIによるレガシーシステムの解析において人が実際に行う作業と比較して
といったことをプロジェクト発足前にミニマムでクイックに検証することで、クライアントが抱える「AIは使い物になるのか」という不安を払拭したという事例です。
最初にある程度の実現性と方向性が示されれば、プロジェクトの関係者は安心して今後のプロジェクトの進行に注力できます。逆にPoCでサービス構想の実現に避けては通れない課題が見つかった場合は、その課題をクリアするための方法を検討することがプロジェクト成功の最短ルートとなります。
PoCは、プロジェクトの成功確率を高めるための重要なステップであり、新規事項における今後の方向性を決定する貴重な情報源になりえるプロセスです。
しかし、その一方で実際にPoCを実施した人たちのなかには
といったマイナスイメージや失敗談を耳にすることも、残念ながら少なくありません。
PoCにより様々な成果や成功体験が生まれる一方で、なぜこのようなマイナスイメージや失敗談が生まれてしまうのでしょうか?
その原因の多くは「PoCを実施すれば、新規事業は成功する」といった勘違いから、実施が目的となってしまっているケースにあると考えられます。
確かにPoCを実施し、新規事業開発における不安要素を取り除ければプロジェクトは成功に近づきます。しかし、それは不安要素を排除したからであってPoCを実施したからでは決してありません。
目的はあくまで「不安を排除すること」であり、そのための手段としてPoCがあることを忘れてはいけません。
またこれに関連して「PoCをさっと終わらせて、完了という功績をもって新事業開発を早く始めたい」といった事例もこれまで目にしてきました。
これもやはりPoCの実施が目的になってしまっている間違ったケースといえ、正しい検証内容と実行結果をもって、新規事業開発につなげていく、その検証プロセスも非常に重要です。
ここまで、PoCの重要性と、その成功には正しい理解と進め方が必要なことを紹介してきました。
では、具体的にどのようにすれば新事業の成功に繋がる正しいPoCを行えるのか?
それは、ここに紹介する3つのメソッドに集約されます。
構築・検証・フィードバック・評価といったPoCの実施スケジュールと検証サイクルを今回の目的にあわせた適正な形で最初に計画します。
今回はユーザのニーズ調査が主目的なので「検証アプリはモックアプリなど最低限に留め、利用者へのヒアリングに多く時間を費やす」といった目的に応じてどこにお金と時間を投資するのかを決めていきましょう。
また、後ほど詳しく説明しますが検証とフィードバックのサイクルは、最低でも2回構築することをおすすめしています。
PoCの成功・失敗を判断するための評価指標を、PoC開始前に定量的な数値で策定しましょう。
これによりPoCの開始から終了まで一貫したブレのない目的が明確になり、結果を正しく評価するとともに関係者にも安心を提供できます。
たとえITベンダーとクライアントの現場メンバーがPoCの結果に満足したとしても、実際の利用者や投資を行う重要ステークホルダーが、その結果に満足していないと新規事業の継続は暗礁に乗り上げてしまうでしょう。
独りよがりの検証にならないためにも、新規事業の継続判断に必要なステークホルダーが誰で、いつ会話して、どのように新規事業の継続を判断するのかを計画しましょう。
今回の記事では、この3つのなかでも「適正な検証サイクルの構築」をテーマに、PoCの開発・検証プロセスにおいて、どのような進め方をするのがよいか、実際の失敗事例と成功事例を比較しながら見ていきます。
[注釈] 本ブログは連載形式となっており、他2つのテーマは次回以降に順次公開していきます。 第2回はこちら |
➡︎【生成AI×モダナイゼーション】ブラックボックス化したシステムを生成AIが紐解く「CodeRebuild AI」
それでは、ここからは3つのメソッドのうち、PoCにおける適正な検証サイクルの構築についてくわしく解説していきます。
まずは失敗談として、これは新規で企画しているアイディやアプリの機能が、利用者にどれだけ受け入れられるかをデモやアンケートを用いて検証したニーズ調査の事例です。
ニーズ調査における検証実施までの進め方は間違っておらず、1回目の検証ではユーザから高評価を得られた収穫もありましたが、逆に指摘や改善要望など課題もいくつか見つかりました。
ここで本来なら見つかった課題に対して分析を行い、対策を立て、必要に応じて2回目の検証を行うことで、その課題が解消されるかを確認する必要があります。
しかし、実際には課題は放置されたまま、得られた収穫部分だけを「成功体験」として評価し、早々にPoCを完了させ本開発に移行してしまったのです。
これは先にも記載したPoCの実施および完了が目的となってしまった、より具体的なケースであり、結果として本開発でリリースされたサービスではPoCで見つかったときと同じ課題がユーザから指摘され、決して満足度の高いものとはいえないものでした。
せっかくPoCで新規事業を成功させるための課題が得られていたのに、それを放置し繰り返してしまうことは非常に残念です。
次に成功事例として、こちらは今回の記事で冒頭でも少しご紹介した、弊社のCodeRebuild AIを用いたPoCの事例になります。
このときの課題およびクライアントの不安要素は
といった生成AIがクライアントの既存システムに本当にフィットするのか?といったものでした(未知なるAI技術に投資をするわけですから当然不安と言えますね)。
PoCを実施する場合、最低でも2回の検証サイクルを実施することを推奨しています。
これは1回目のPoC検証では、やってみて初めてわかる収穫や課題が多く見つかるという考え方に起因しています。
やってみたからこそ得られた課題に対して、それらが本開発でプロジェクトの進行を妨げる足かせにならないよう、課題の分析と対策を検討し、2回目の検証で払拭できるかを検証します。
実際に今回のPoCでも、1回目の検証では生成AIが上手く結果を残せなかった部分が目立ち、かつ人の解析と比較して時間も要したという結果が得られました。
これらの課題に対してフィードバックとして「なぜ、起きたのか」「それは解消できるのか」を分析・検討し、いくつかの対策案を用いて2回目の検証を行いました。
結果として、2回目の検証では1回目と比較して解析精度は格段にあがり、人が0から既存システムを調査するよりも時間の短縮が見込まれることが証明されました。
この2回目の検証で有益とされた手法はもちろん本開発でも利用可能であり、この結果をもってクライアントは安心して今回のプロジェクトへの生成AI導入を決断するに至りました。
この成果および評価は検証サイクルを2回組んだからこそであると言えます。
今回の生成AIを用いた検証もそうでしたが、新技術導入による生産性の評価については、1回の検証で正しい評価を得るのが難しく、検証を2回以上やって初めて正しい数値が得られます。
これは初回の検証では評価対象のシステムに新技術を初めて導入することの初期コストがかかります。また、それらを操作する人も初めての導入で不慣れな点が多く作業に時間がかかってしまいます。
これが2回目となれば初期導入コストは抑えれますし、人の操作にも慣れが生じてくるので生産性は確実にあがると言えます。
実際の新規事業では、初期導入時ほどの時間を要さないが、人の入れ替わりもあると想定するなら、例えば1回目と2回目の中間を生産性とするなどすれば、正しい値と評価が行えそうですね。
➡︎【生成AI×モダナイゼーション】ブラックボックス化したシステムを生成AIが紐解く「CodeRebuild AI」
技術の進歩とともに高度化するITサービスとその新規事業開発において、ミニマムでクイックに検証を行うための手段としてPoCは有益な選択肢の1つであり、プロジェクトの方向性を決定するための貴重な情報を提供してくれます。
その方向性にブレを生じさせず、新規事業開発に必要な情報をより多く得るためのメソッドとして、今回は適正な検証サイクルの構築について紹介させて頂きました。
まとめるとこのような形で「計画→構築→検証(検証・フィードバック・チューニング・再検証)→最終評価」のプロセスと、今回の目的に合わせた評価サイクルを適切に構築することが重要になってきます。
➡︎【生成AI×モダナイゼーション】ブラックボックス化したシステムを生成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による柔軟な開発進行や、国内外のリソースを活用したスケーラブルな開発体制の構築も可能です。 また、リリース後の保守運用や品質向上支援まで伴走可能です。
モンスターラボが提供するサポートの詳しい概要は以下リンクをご確認ください。