HOME    BRMS徹底活用コラム    PoCとは? メリットや進め方、成功のポイント、事例を詳しく解説!

BRMSの今がわかる!
BRMS徹底活用コラム

どのようにディシジョンをモデル化するのか?DMN : Decision Model and NotationPoCとは? メリットや進め方、成功のポイント、事例を詳しく解説!

システムを本番導入する前に、その効果などを検証するPoC。事前に詳細な検証を行うことで、導入後に期待する効果が得られないリスクを低減できるため、PoCを行うケースが増えています。一方で、「どのようにPoCを進めればよいのか分からない」「PoCを実施しても、なかなか本番導入に進まない」といった悩みも多いようです。本記事ではPoCの概念から進め方、成功のポイントを詳しく解説し、事例をご紹介します。


PoCの定義、メリットを整理する

PoCは「Proof of Concept(概念実証)」の略で、新たな概念や技術について期待する効果を得られるのか、検証することを指します。開発費用や期間、機能などが自社の要件に合致しているのかを明確にすることができ、さらに導入時のリスクを本番導入前に洗い出すことができます。製品や用途によっては、PoCで作成したものを本番導入時にそのまま活用できるケースもあり、必ずしも検証だけへの投資ではなくスムーズな開発にもつながるため、幅広くメリットを得ることができます。

最近では、DX(デジタルトランスフォーメーション)推進によってIoT・AIなど費用対効果が出しにくい案件が増えていることもあり、PoCを実施するケースが増加しています。特に、これまでシステム化されていなかった領域にIT製品を導入するといった難易度が高いケースではPoCの実施が効果的です。


PoCを進めるための4つのステップ

一般的には、導入を検討しているシステムの操作性をハンズオン(製品検証)で確認し、本番導入前に期待する効果を得られるかを検証するPoCを実施します。製品によっては、本番導入前にプロトタイプの作成を行う場合がありますが、このプロトタイプとPoCの違いが曖昧になりがちです。本番導入に向けて動作を確認するためのプロトタイプに対し、PoCはあくまでも「概念や技術の効果検証」が目的です。実施期間や指標を定め、一度立ち止まって効果を検証することが重要です。


PoCは大きく4つのステップで進めます。

ステップ1:ビジネスゴールを明確にする

「PoCだけ実施して終わり」といった事態を避けるためにも、まず始めに「最終的に何をしたいのか」という目的を明確にすることが重要です。システム導入することで、社内のどんな課題を解決したいのか、何を改善したいのかが分からなければ「何を検証すべきか」も定まらないまま進めることになりかねません。

ステップ2:体制を確立する

PoCは単に「システム導入できるかどうか」だけではなく、導入後の業務への影響や、ビジネス上の効果まで含めて検証するプロセスです。その効果をきちんと測るためにも情報システム部門、業務部門、経営層などを含めPoC実施の体制を整えて臨む必要があります。

ステップ3:実際の製品を用いて技術検証を行う

実際の製品を用いて技術検証を行う際は「あれもこれも」と幅広く検証するのではなく、機能や要件を限定することが有効です。これにより、要件自体が定まらずPoCが進まない事態を避けられます。また、簡単な機能や要件を検証してもあとから「より複雑な業務に展開できない」といったことになりかねないため、PoC対象としては難易度が高い、処理が複雑な業務やフローを選ぶことがポイントです。

ステップ4:検証結果を基に今後の対応を検討する

事前に設定した指標について、クリアできたかどうかを確認します。クリアできなかったものについても、許容範囲なのか、改善策はあるのかなどを検討します。「本番導入見送り=PoC失敗」ではなく、各指標に基づき「今回は導入を見送る」「体制を整えて改めて導入を検討する」などを判断できたこと自体がPoCの大きな成果と言えます。

PoC成功の鍵を握る、事前の「ゴール設定」

PoCの進め方のステップ1でも述べたように、PoCを成功させるには実施前の「ゴール設定」がポイントです。ゴール設定には2種類あり、一つは「何のためにPoCを実施し、システム導入を目指すのか」といったビジネス上の目的です。ここでは検証する概念・技術がどのような課題を解決し、どういった効果を期待できるのかをベースに、自社のビジネスにおいて投資に値するものなのかを意識して目的を設定する必要があります。そのため、現場担当者だけでなく意思決定権を持つ経営層などを巻き込んで、目的を共有することが重要です。

もう一つは、検証する際に基準となる指標です。これらも事前に設定しておかなければ、正しく検証できず本格導入を進めるかどうかの判断材料も得られません。主要な指標としては、「機能・性能」「費用」「メンバースキル」「移行」「スケジュール」「標準化」の6つを挙げることができます。このほか、たとえばAIであれば「データ(分析対象データが揃っているか)」など製品によって必要な指標を用意します。


これらのゴール設定は、自社の業務にあわせて検討する必要があります。そのため、ベンダーにすべて任せるのではなく、自社のことを最も理解しているユーザーもPoCに参加する意識を持ち、積極的にコミュニケーションを取ることが重要です。

事例で解説!「PoCで何を検証し、どう判断するか」

最も複雑な業務でPoCを実施し、システム導入可否を判断

賃貸住宅の家賃保証などの事業を展開する株式会社オリコフォレントインシュアでは、繁忙期の業務負荷軽減、属人化解消を目指しBRMS(Business Rule Management System)の導入を検討していました。BRMSはあらかじめ設定した業務の「ルール(ビジネスルール)」に応じて、業務フローを自動で判断・実行する仕組みです。しかし、細かな条件によってルールが異なり、複数の情報を突き合わせて判断する必要があるなど、業務やフローが複雑で担当者しか分からない点も多く、BRMSで自動化できるか懸念が残りました。

そこで、特に複雑な業務をターゲットに、複数の判定ルールのうち数個をピックアップしてPoCを実施しました。その結果、機能・費用・スケジュールなど事前に設定した指標をすべてクリアし、無事に本格導入することになりました。現在は該当業務への導入が完了し、他業務への展開を進める予定です。

本格導入前にPoCを実施することで、複雑な業務フローをBRMSで自動化できる確証を持てた点は大きなメリットです。またPoCで作成したルールをそのまま活用できたため、無駄なくスムーズな開発が可能になりました。

PoCの実施により本番導入時の課題が明確化

「Falkonry」は、IoTのセンサーデータなどから異常予兆を検知する設備系AI分析プラットフォームです。一般的には自社工場設備に対して活用しますが、設備の卸・販売を手がけるA社は、保守サポートの一環として顧客先に納入した設備に関する異常予兆を検知できないかと考えていました。

そこでSCSK、A社にてPoCを実施しました。実データでAIモデルを作成し、検証を行いました。期待する精度は得られたものの、設備の利用環境が異なるため、顧客ごとにAIモデルを変える必要があることが判明しました。想定よりもモデル作成が複雑になり、顧客の協力も得ながら検討を進める必要があると分かり、更なるPoCは一旦保留となりました。PoCは保留となりましたが闇雲に導入を進めた結果、予算や開発期間ばかり膨らみ終わりが見えないといった事態を回避し、想定される開発規模に合わせて改めて体制を整えることが可能になりました。

「Falkonry」では今回明確になった課題や規模感を踏まえ、このようなケースにおいてどのような体制でPoCを進めるべきかを検討しています。

SIerの強みを活かし幅広い製品のPoCをサポート

PoCは対象業務や製品によって細かなプロセスは異なります。またPoCは単なる技術検証だけでなく、ビジネス上のゴール・目的を意識して実施することが不可欠です。そのため、それぞれの製品に精通しているだけでなく、ビジネス的な観点からの提案・助言を得られるベンダーがベストと言えるでしょう。 SCSKはSIerとして長年培ってきたノウハウをもとに、さまざまな製品のPoCから導入までサポートが可能です。加えて本来意識すべきビジネス上のゴールを明確にするところから、プロジェクト完遂までトータルにマネジメントできる点はSCSKならではの強みです。

BRMSに関するお問い合わせ BRMSならSCSK その理由とは? JBoss Enterprise Middleware セミナー資料ダウンロード
download close

閉じる

[2月16日(木)]

「Progress Corticon」ハンズオンセミナー

詳細はこちら