BRMS アプリケーションPOC⇒プロトタイプ構築支援
BRMSの導入が有効かどうかを判断する簡易アセスメント（無償）の結果を踏まえて、POC（proof of concept、概念実証）を行います。
評価の規模感をヒアリングしてご提案を行いたいところですが、傾向として、規模感や難易度などの詳細を聞いてしまうと話が纏まらないケースが多く見られます。例えば、ルールの条件やアクションが各5つのDecision Tableを作成するとしても、要件を確認するための工数、1つ1つの条件の内容や難易度によって規模感がガラッと変わってきます。
決める
先ず評価の期間を決めます。だいたい、1ヵ月～ 2ヶ月位です。もともとBRMSに興味をもたれている場合は、案件ありきで急がれているかと思いますので、評価期間としても2ヶ月以内を目標とするケースが多いです。
逆に、「BRMSとは」から始まるような情報収集レベルの場合は、簡易アセスメントを元にPOCを行うか行わないかのご判断をしていただきます。
決める
次に、POCの目的を決めます。BRMSをご検討中の場合、既に目的が決まっていることが多いかと思われます。目的としては、例えば以下があげられます。
自社システムでBRMSの適用効果が見込めるかどうかの評価
BRMS をどこに適用すればよいのかの評価
自分達でBRMSを評価する為に必要な知識の習得
BRMSを利用した汎用的な開発標準の策定
決める
POCの目的に応じて、目的達成の評価項目や達成基準を決めていきます。評価項目の内容や数が、POCの規模感、実際に実装するビジネスルールの数や全体工数に関わってきます。
機能/ 性能：システムで必要な機能/ 性能を満たしているか。
移行：既存資産を BRMSへ移行可能か。既存設計書は、流用可能か。
費用（移行難易度/ 工数/ 費用）：移行工数（費用）は想定範囲内か。
スケジュール：マスタスケジュールに間にあうか
メンバースキル：開発メンバーが BRMSの機能を理解し開発することが可能か
標準化：開発標準化をどこまでするべきか（品質・保守、開発工数削減）
決める
ここまでのプロセスの中で、対象システムの情報を共有し、実装対象の機能選定を行います。評価期間、POC目的、評価項目、対象機能が概ね決まったところで、スケジュールを引きます。
ここまでくると、評価期間でルールをどれくらい実装できるのかが見えてきますから、紙面に起こした上で認識あわせを行います。後は認識あわせを繰り返し、提案書の精度を上げていきます。
