パッケージベンダーへの質問には特徴がある

提案を受けるベンダーが「パッケージベンダー」であれば、そこに特化した質問があります。

なぜならば、スクラッチ開発とは異なり、既にシステムが存在するからです。

そこに焦点を当てて、質疑応答で確認していくことになります。
 

ウォーターフォール開発??

例えば、あるベンダーの提案スケジュールを確認したときのことです。

「要件定義」
「設計」
「開発・単体テスト」
「結合テスト」
「総合テスト」
「受入テスト」

が順番に並んでいます。普通にこのスケジュールだけ切り取ると、何もおかしなところはありません。

しかし、これを提案しているのが「パッケージベンダー」となると、とたんに話は変わってきます。

パッケージということは、基本的には「システムが既にある」状態です。それなのに、設計→開発→テストと、あたかもこれからガッツリと作り込んでいく「ウォーターフォール開発」というのは、パッケージが存在しないのと一緒です。

そして、パッケージに大幅な「カスタマイズ」という名の「スクラッチ開発」のため、期間も長く、費用も高くなってしまいます。

実は、このようなケースはわりと多いのです。確立されている業種ではあまりないのですが、ニッチな業種では普通に起こります。

このような場面でも、質問が有効です。

「パッケージなのに、なぜ開発前提なのですか?」

「ノンカスタマイズの実績XX件とありますが、その時もこのスケジュールでしたか?」

すると、たいていは次のような回答が返ってきます。

「汎用的な作りになっており、顧客ごとに使いやすいようカスタマイズするためです」

一見、もっともらしく聞こえますが「カスタマイズ前提」というところに違和感があります。

パッケージであれば、プログラムには手を入れずに「設定」だけで顧客の業務に適応させるのが、本来の姿です。

ベンダーもパッケージに自信があるなら、安易に顧客に合わせるのではなく、逆に「我々のパッケージに御社業務を合わせてください」とBPR前提で提案すべきです。

「ノンカスタマイズ+BPR」をベースとし、どうしても設定だけでは対応できない個社の特殊性だけが「カスタマイズ」という選択肢になります。

その場合、パッケージ本来のスケジュールはどうなるのでしょうか?

まずは「パッケージの仕様」と「顧客の業務」を比較し、差異をあぶり出します。それが「フィット&ギャップ分析」です。業務に適応できそうなものが「フィット」、そのままでは適応できない差異が「ギャップ」に分類されます。

その上で「ギャップ」に対して、運用を変えてパッケージに合わせるのか、どうしても合わせられないのかを掘り下げていきます。

そこでどうしても合わせられないものが「カスタマイズ」として、スケジュールに組み込まれます。

しかし、それはパッケージ全体から見ればほんの一部であり、本体のスケジュールと並行し、「脇道」として組み込まれるべきです。

「フィット&ギャップ分析」後の本体スケジュールとしては、

「新業務フロー作成」
「移行データ準備&設定」
「マニュアル作成」
「ユーザートレーニング」

などが続きます。ウォーターフォール開発からみれば、大幅な「ショートカット」となります。
 

もう1つのキラークエスチョン

またスケジュールについて、パッケージベンダーへの代表的な質問はもう1つあります。

「プロトタイプ環境はいつから触れますか?」

この環境がいつから提供されるかが、パッケージの完成度を代弁しています。

極論すると、パッケージは存在するのだから、基本的な設定さえすればいつでも触れるはずです。これが早期に提供できないのは、パッケージの完成度が低いからです。

カスタマイズ開発が前提にあると、いろいろな理由をつけてプロジェクトのかなり後半になってしまうはずです。

逆に自信のあるベンダーは、即答で「設定すればいつでも」と返ってきます。

そして「ただしクラウド環境利用料がそのタイミングから発生します」と言ってきたら、そのベンダーは実績豊富とみなしてよいと思います。

ここで、健全なパッケージベンダーだった場合は、次の質問に続きます。

「アジャイル開発(またはスパイラル開発)の具体的な進め方を教えてください」

プロトタイプ環境が提供されているということは、それをベースに設定変更したり、カスタマイズを加えたり、データ移行したりして、「環境を成長させていく」やり方が確立されているはずです。

最初に70点のものを用意して、80点→90点→100点と完成させていくイメージです。
 

パッケージの完成度を確認していく

このように、パッケージベンダーであれば、スケジュールやプロジェクト計画に「パッケージの完成度」があらわれてきます。

「既に動くシステムがある」という前提で「パッケージに自信を持っている」提案なのかどうか。

これらをベンダーに質問して、提案パッケージの実態を確認していきます。
 

(プレゼン評価の関連記事)
【プレゼン評価1】プレゼンの効果を高める5つの観点とは?
【プレゼン評価2】ベンダープレゼンAgendaの作り方(サンプル画像付き)
【プレゼン評価3】プロジェクトマネージャーにどんな質問をするか?
【プレゼン評価4】パッケージベンダーにどんな質問をするか?

ベンダー提案評価資料の作り方(サンプル画像付き)

(プレゼン評価の関連コラム)
RFP後のベンダー提案プレゼンで話しているのは誰?