シリーズ：【元ベンダーが教える】小売システム導入 成功の法則　第十回

～「できます」の中身を確認しないと、後で必ず話が変わる～

前回は、

「見積書では見えない導入コスト」

というテーマでお話ししました。

システム本体の価格だけではなく、

• データ移行
• データクレンジング
• 店舗教育
• 社内プロジェクトの人件費
• ハードウェア・ネットワーク
• 本番稼働時の対応
• 稼働後のサポート
• カスタマイズ

など、見積書だけでは分かりにくいコストがある。

そして、

「この金額に含まれていない作業は何ですか？」

とベンダーに確認することが大切だ、というお話をしました。

今回は、その続きです。

ベンダーとの打ち合わせで、こんな会話をしたことはありませんか？

「この機能はできますか？」

すると、

「はい、できます。」

非常に安心する言葉です。

「よかった。」

「これなら今の業務を変えなくても大丈夫だ。」

そう思います。

ところが、プロジェクトが始まってしばらくすると、

「その機能は追加開発になります。」

あるいは、

「技術的には可能ですが、かなり費用がかかります。」

さらには、

「その方法より、別の運用にしていただいた方がいいです。」

という話になる。

「えっ？」

と思いますよね。

「契約前には『できます』と言っていたじゃないか。」

当然そう思うでしょう。

しかし、元ベンダーの立場から見ると、

「できます」という言葉には、いくつかの種類があります。

ここを理解しておかないと、

「言った・言わない」

の話になってしまいます。

今回は、この「できます」という言葉の裏側についてお話しします。

---

「できます」には4種類ある

私なら、ベンダーの、

「できます」

という回答を、少なくとも次の4つに分けて考えます。

① 標準機能でできます

これは一番分かりやすい。

現在のシステムに、

すでにその機能が搭載されています。

設定を変更するだけで使える。

これなら、

比較的安心です。

---

② 設定・パラメータ変更でできます

標準機能ではあるけれど、

自社向けに設定を変更する必要がある。

これも、

比較的問題ありません。

ただし、

「設定作業は誰がするのか？」

「費用はいくらか？」

は確認しておいた方がいいでしょう。

---

③ カスタマイズすればできます

これが、

少し注意が必要な「できます」です。

標準機能にはない。

しかし、

プログラムを追加開発すれば実現できる。

技術的には、

「できます。」

でも、

当然、

費用と時間が必要です。

---

④ 技術的にはできますが、おすすめしません

実は、

これもあります。

システムとしては作れる。

しかし、

「その方法を採用すると、将来のバージョンアップが難しくなります。」

「保守が複雑になります。」

「店舗の操作がかえって増えます。」

というケースです。

つまり、

「できる」と「やった方がいい」は違う

のです。

---

「できるか？」だけでは質問が足りない

例えば、

「現在のシステムと同じ帳票を出せますか？」

と聞いたとします。

ベンダーが、

「できます。」

と答えた。

ここで終わってはいけません。

続けて、

「標準機能ですか？」

と聞きます。

「いいえ、追加開発です。」

となったら、

さらに、

「追加費用はいくらくらいですか？」

と聞く。

さらに、

「その機能は、今後のバージョンアップでも維持できますか？」

と聞く。

こうすると、

「できます」

という一言が、

かなり具体的になります。

---

「技術的にできる」と「業務としてできる」は違う

ここは、

小売システムでは特に重要です。

例えば、

「店舗ごとに違う発注ルールを設定できますか？」

と聞いたとします。

ベンダーは、

「できます。」

と言うかもしれません。

確かに、

プログラムとしては可能でしょう。

しかし、

店舗が500店舗あるとしたら、

500店舗分の設定を管理しなければならないかもしれません。

店舗が増えるたびに設定が必要になるかもしれません。

担当者が変わったら、

誰も設定方法が分からなくなるかもしれません。

つまり、

技術的にはできても、運用としては大変

ということがあります。

だから、

「できますか？」

だけではなく、

「実際の運用では、どのようになりますか？」

と聞くことが重要です。

---

「今と同じにできますか？」は特に注意

小売システムの入れ替えでは、

非常によく出てくる言葉があります。

「今のシステムと同じことができますか？」

これは、

ベンダーにとっても難しい質問です。

なぜなら、

今のシステムには、

長年のカスタマイズが積み重なっているからです。

10年前には必要だった機能。

5年前に追加した機能。

店舗から要望があって追加した機能。

誰が依頼したのか分からない機能。

そんなものが、

たくさん入っています。

---

「同じにする」ことが、本当に正しいのか

例えば、

現在のシステムでは、

発注するまでに、

8回画面を切り替えているとします。

新しいシステムのデモを見たら、

3回でできる。

そこで、

「今と同じ8回の操作にしてください。」

と言うでしょうか。

おそらく、

言わないと思います。

でも、

現場から、

「今と同じにしてください。」

という要望が出ることはあります。

そのとき、

良いSEなら、

「分かりました。」

だけではなく、

「なぜ8回の操作が必要なのか？」

と聞いてくるでしょう。

そして、

「目的がこれなら、3回でできる新しい方法の方がいいのではないでしょうか。」

と提案する。

これが、

「できます」だけではないSEの仕事

だと思います。

---

「できます」と言わないベンダーが、実は信用できる

これは、

少し逆説的な話です。

ベンダーに、

「この機能はできますか？」

と聞いたとき、

「できます。」

と即答する会社。

一方で、

「その機能は実現できます。ただ、御社の場合はおすすめしません。」

と言う会社。

どちらを信用するでしょうか。

私は、

後者の方を信用します。

なぜなら、

単に契約を取りたいのではなく、

導入後のことまで考えている可能性があるからです。

---

「できません」と言えることも、ベンダーの能力

優秀なベンダーは、

何でも「できます」と言いません。

時には、

「それは、やめた方がいいです。」

と言います。

例えば、

「現在の帳票を全部そのまま再現してください。」

と言われた。

すると、

「できます。」

ではなく、

「できますが、100種類以上の帳票を維持することになります。本当に必要なものを20種類程度に整理した方が、運用しやすくなります。」

と言う。

これは、

お客様の要望を拒否しているのではありません。

本当の目的を考えている

のです。

---

「できます」の後に「いくら？」を聞く

非常に基本的なことですが、

「できます。」

と言われたら、

必ず、

「それは追加費用になりますか？」

と聞いてください。

これだけでも、

かなり違います。

そして、

「なる場合、概算でどのくらいでしょうか？」

と聞く。

契約前なら、

正確な金額は出せないかもしれません。

それでも、

「数十万円程度なのか。」

「数百万円なのか。」

「数千万円になる可能性があるのか。」

それだけでも分かれば、

判断材料になります。

---

「できます」の後に「いつまで？」を聞く

費用だけではありません。

時間も重要です。

「それを実現する場合、導入スケジュールに影響しますか？」

と聞いてください。

追加開発には、

設計。

開発。

テスト。

リリース。

などの工程が必要です。

つまり、

「できます。」

と言われた瞬間に、

プロジェクト全体のスケジュールが変わる可能性があります。

---

「できます」の後に「誰がやる？」を聞く

これも重要です。

例えば、

「データを移行できます。」

と言われた。

では、

誰がデータを整理するのでしょうか？

ベンダーでしょうか。

お客様でしょうか。

それとも、

共同作業でしょうか。

「できます。」

という言葉だけでは、

ここが分かりません。

だから、

「その作業は、御社と当社のどちらが担当しますか？」

と確認する。

これだけで、

後々のトラブルがかなり減ります。

---

「できます」の後に「将来は？」を聞く

システム導入では、

今だけを見ると危険です。

例えば、

「このカスタマイズはできます。」

でも、

3年後にシステムをバージョンアップするとき、

どうなるでしょうか。

「再度開発が必要です。」

となるかもしれません。

あるいは、

「そのカスタマイズ部分は、新しいバージョンでは利用できません。」

となる可能性もあります。

だから、

「将来のバージョンアップでは、この機能はどうなりますか？」

と聞いておく。

これは非常に重要です。

---

「できます」の後に「障害時は？」を聞く

もう一つ、

忘れがちな質問があります。

それは、

「障害が起きたときはどうなるのか？」

です。

例えば、

特殊なカスタマイズを入れた。

通常は動いている。

ところが、

ある条件でエラーが起きた。

そのとき、

「標準機能ではないので、調査に時間がかかります。」

となる可能性があります。

だから、

「できるかどうか」だけではなく、

「問題が起きたとき、誰が責任を持って対応するのか」

まで確認しておくことが大切です。

---

「できること」より「できないこと」の方が重要

私は、

ベンダー選定では、

「できることの一覧」より、「できないことの一覧」

を作ってもらうのも良いと思っています。

例えば、

項目	回答
標準機能	○
設定変更	○
カスタマイズ	○
他社製品との連携	△
過去データ移行	条件付き
特殊帳票	追加開発
オフライン運用	×

こうすると、

システムの特徴が、

かなり分かりやすくなります。

完璧なシステムはありません。

だからこそ、

「何ができないのか」

を知ることが大切なのです。

---

「できます」を一覧表にしてみる

さらにおすすめなのが、

ベンダーから出てきた、

「できます。」

という回答を、

一覧にしておくことです。

例えば、

要望①

「店舗別に発注ルールを変えたい。」

→ できます。

要望②

「現在の帳票を再現したい。」

→ できます。

要望③

「既存データをすべて移行したい。」

→ できます。

このままでは、

まだ不十分です。

その横に、

• 標準機能か
• 設定か
• カスタマイズか
• 追加費用はあるか
• 納期への影響はあるか
• 誰が担当するか
• 将来も維持できるか

という項目を追加します。

すると、

「できます」の正体

が見えてきます。

---

口頭の「できます」を放置しない

コンペの場では、

いろいろな会話が行われます。

その中で、

「できます。」

「大丈夫です。」

「問題ありません。」

という言葉が、

たくさん出てきます。

しかし、

会議が終わると、

そのまま忘れられてしまうことがあります。

だから、

重要な回答については、

議事録に残す

ことをおすすめします。

例えば、

「○○機能について、標準機能で対応可能との回答を得た。」

と記録する。

もし追加開発なら、

「○○機能について、追加開発により対応可能。費用・納期は要件確定後に提示。」

と記録する。

こうしておけば、

後から、

「そんな話はしていません。」

となりにくくなります。

---

RFPにも「回答方法」を指定するといい

さらに、

ベンダーから回答をもらう段階で、

「できます。」

だけでは回答にならないようにしておく方法があります。

RFPの回答欄を、

例えば、

対応区分

• 標準
• 設定変更
• カスタマイズ
• 他社製品
• 運用対応
• 対応不可

と分けておく。

さらに、

追加費用の有無

スケジュールへの影響

なども記載してもらう。

そうすると、

ベンダーごとの比較がしやすくなります。

---

「できます」の多さでベンダーを評価しない

ここも重要です。

コンペで、

A社は、

「100項目中98項目できます。」

B社は、

「100項目中90項目です。」

となった。

普通なら、

「A社の方がいい。」

と思うかもしれません。

しかし、

A社の98項目のうち、

30項目がカスタマイズ。

B社の90項目は、

ほぼ標準機能。

だったら、

話は変わります。

だから、

「できる数」ではなく、「どうやってできるのか」

を見る必要があります。

---

実は「できない」と言うベンダーにもチャンスがある

例えば、

お客様が、

「この機能はできますか？」

と聞く。

ベンダーが、

「標準ではできません。」

と答えた。

ここで、

「じゃあ、この会社はダメだ。」

と判断するのは、

少し早いかもしれません。

その後に、

「ただし、御社の目的が○○であれば、標準機能の△△を使うことで、ほぼ同じことができます。」

と提案してくるかもしれません。

これなら、

むしろ優れた提案です。

機能そのものではなく、目的を解決している

からです。

---

「できる」と言われたら、「なぜ？」まで聞く

最終的には、

これに尽きます。

「できます。」

と言われたら、

「どうやって？」

と聞いてください。

「標準機能です。」

なら、

「どの機能ですか？」

「設定変更です。」

なら、

「どのような設定ですか？」

「カスタマイズです。」

なら、

「費用と納期は？」

「運用で対応します。」

なら、

「店舗では具体的に何をするのですか？」

と聞く。

つまり、

「できます」という回答を、具体的な仕事の形まで落とし込む

のです。

---

まとめ

ベンダーとの打ち合わせで、

「できます。」

と言われると、

安心します。

しかし、

その一言だけでは、

何も分かりません。

「できます」には、

• 標準機能
• 設定変更
• カスタマイズ
• 他システムとの連携
• 運用による対応

など、

さまざまな意味があります。

さらに、

「できるけれど、おすすめしない」

というケースもあります。

だから、

「できます。」

と言われたら、

次の質問をしてください。

「標準機能ですか？」

「追加費用はかかりますか？」

「スケジュールに影響しますか？」

「誰が作業しますか？」

「将来のバージョンアップでも使えますか？」

「障害が起きた場合は、誰が対応しますか？」

そして、

「実際の業務では、どのようになりますか？」

と聞いてください。

ここまで聞けば、

「できます。」

という言葉の意味が、

かなり明確になります。

---

次回は、

第11回「カスタマイズを増やすほどシステムは使いにくくなる理由」

についてお話しします。

「今のシステムと同じにしてほしい。」

「この機能も追加してほしい。」

「この帳票も必要。」

そうやって要望を一つずつ追加していくと、

最初は、

「より便利なシステムになる」

と思います。

ところが、

カスタマイズを増やした結果、

「新しいシステムなのに、なぜか使いにくい」

ということが起こります。

なぜでしょうか。

そして、

どこまでならカスタマイズしてもいいのでしょうか。

次回は、

元ベンダーとして実際に見てきた、

「カスタマイズ地獄」

について、少し踏み込んでお話ししたいと思います。