トライアルとは

トライアルとは何でしょうか？

よく広告で見かける「動画配信サービスの1カ月無料トライアル」「化粧品やサプリメントのお試しセット」「ゲームの無料版ダウンロード」などと一緒です。気に入ったら購入し、気に入らなかったら購入しない。

パッケージシステムも同様です。正式購入や契約をする前に、試しに使ってみて「機能」や「操作性」を確かめる、ということです。

これは、スクラッチ開発にはない大きな相違点です。スクラッチ開発では、まだシステムが存在しないので、試しに使うことはできません。パッケージシステムは、システムが固定化され、既に存在しているからこそ、試すことができます。

ベンダーによって異なりますが、最近はトライアルに応じてくれるベンダーは多くなっています。
 

トライアルの目的

トライアルは、「市場パッケージの標準機能を体感する」プロセスといえます。その目的は3つあります。

① 現場で使えそうか判断する

パッケージかスクラッチかで揺れ動いている場合、実施にパッケージを触ってみて、行けそうか判断できます。パッケージを用いた運用イメージを固めて、おおよそ運用が回るかどうか、BPRで業務をシステムに寄せられそうか、どこにカスタマイズが必要か、などを見極めることができます。

もしそこで「パッケージはやはり厳しい」となれば、この時点で早めにスクラッチ開発へ起動修正できます。RFPを出す前に、手戻りを最小化します。
 

② RFPの精度を上げる

市販パッケージを触っていると、機能的に弱い部分や自社の独自機能と思われる部分が浮き彫りになります。それらを要求事項として明確化し、RFPに反映していきます。

パッケージのイメージを明確に持てた上で、BPRを前提とした要求に変えることもできます。一般的に、現行システムがスクラッチ開発の場合、RFPは現行そのままの要求（As-Is要求）に偏りがちです。それしか知らないので仕方ありません。

それをパッケージという「業界標準」に触れることで、あるべき姿の要求（To-Be要求）にRFPを進化させることができます。

トライアルをしていると「これ便利だわ」「コレがあれば今までの作業はいらないよね」など、新しい着想が得られます。すると、現行システムの仕様に固執せず「要求一覧」から、取り下げできるものが出てきます。
 

③ 現場の「反対派」の不安をぬぐう

このトライアルを活用して、現場の不安を解消していきます。

不安の根源を探っていくと「イメージがわかない」「新システムが見えない」と実物がなく想像するしかない中で、判断を迫られているからです。現時点では、現場で使えるかどうか、全く分かりません。うまくいく根拠がない限り、無難に「反対」となります。

実際、現場の人に使ってもらうのは「諸刃の剣」です。そこで猛反発を受ける可能性もあります。しかし、猛反発を受けるなら、遅かれ早かれそうなります。つまずくなら早い方がいい。その分、立ち直りも早くなるからです。逆に気に入ってもらえたなら、それはプロジェクトとしては成功に大きく近づきます。

トライアルは、その分余計に時間がかかってしまいますが「急がば回れ」です。そもそも、現場の協力が得られないシステムを導入しようとしても、上手くいくわけがありません。長期的に見たら、最初の段階で現場を味方につけた方が、その後の導入が加速し、結果的に早く導入ができます。

＊＊＊

↓関連記事↓
パッケージシステムのトライアル方法