費用対効果のはき違え
情報システムのプロジェクトなどで標準化という理想状態を目指すことだけが目的化すると、不毛な結果になります。それは、「スタンダリアン」というお化けのせいなのです。
そのお化けの生態を露わにした本から、一部内容を紹介します。
それから、費用対効果についても部長は変なことを言っていた。論点を分かりやすくするために、例から説明しよう。
こんなマンションを買わされたら怒りますよね
家を買うときのことを考えてみよう。今は賃貸で暮らしているが、マンションの良い部屋を見つけたので購入を検討しているというケースだ。
不動産屋さんは、さかんにマンションをお勧めしてくる。立地、環境、広さ、設備、全てが素晴らしいですよ。それに35年でローンを組めば、今の家賃よりも割安です。絶対にお得です。こんな感じで熱烈に営業を受けて、購入したとする。
ところが、マンションを購入した後で、いろいろと不便なことが発覚する。
駐車場には21時以降入庫できません
理由を聞くと、駐車場を24時間利用できるようにすると、緊急対応等の人件費や設備費が増加してしまうと。そして、21時以降に駐車場を利用する人は少ないので、費用対効果を考えて夜間入庫を停止します。こんなことを言われてしまった。
さらに、年に1回電気がストップするということも判明
電気設備の定期点検のため、マンション全体の電気が使えなくなると。様々な作業手順のため、12時間ほど電気が使えない状況が続くので、その日は外出してくださいと言われた。クレームを言うと、定期点検の時のためだけに非常用電源を増強するのはもったいないので、費用対効果を考えて対応していると言われてしまった。
架空のケースではあるのだが、どうだろう。
こんなマンションを買ってしまったら怒り心頭だろう。どうして、マンションを購入するときに説明しなかったのか。こういった説明があれば、このマンションを購入しなかったのに、と思うことだろう。
情報システム導入で繰り返される同じ風景
では、このマンションの例を理解した後で、部長の発言をもう一度見てみよう。
若手：
前提としているCusCusですが、あくまで汎用的な顧客管理サービスなので植物の分野には向いていない部分もあるんですね。
例えば、植物の場合は同じ商品でもどんどん成長するので、若芽の頃、つぼみの頃、開花の頃で商品コードを変える場合があるんですが、そういうことに対応できないとか。
部長：
なるほど。でも、CusCusは世界的に使われているんだから、対応する方法があるはずだよ。ちゃんと、開発元に問い合わせてみてよ。
若手：
はい。問い合わせもしました。商品コードを細かく分類したうえで、プロモーション実施時に同じ商品となるものを紐づけすることで対応できるそうです。ただ、その紐づけ作業に、それなりの手間がかかりそうで。
部長：
その紐づけ作業まで自動化するとなると、かなりの経費になるでしょ。
費用対効果を考えると、その部分は人手で作業する方がいいと思うよ。
どうだろう。部長の言っている費用対効果というのが、新システム（CusCus）を導入することを決めてから、後出しジャンケンで登場しているということが理解できたと思う。
現在は実現できているのに今後は実現できなくなるという「不便になること」は、新システムの導入を決める前に把握すべきことなんだ。フィット＆ギャップ分析をちゃんとやっていれば、植物の成長過程で商品コードが変化するという問題は事前に把握できたはずなんだ。
しかし、その事前検討をしっかりやらなかったために、こういう問題が次々に発覚することになる。部長は費用対効果という逃げ口上を使って、その場をなんとか収めているけどね。でも、これはただの言い訳であり、本当の意味の費用対効果ではないんだ。
一方通行の形だけのコミュニケーション
独りよがりのシステム導入を進めていた部長だが、設計が進んで具体的な問題が明らかになるにつれて、だんだん不利な立場に追い込まれていく。
しかし、部長は誤りを認めようとしない。色々な策を講じて、なんとかシステム導入を計画どおりに進めようと画策するんだ。
部長の中のお化け（※）：
長年の経験で、こういう人への対応方法には慣れてきたのよ。
Yes – But 法ではなく、Yes – silent 法とでも言うべきかな。
とりあえず聞く耳は持っておく。だけど、できないものはできないので、いつまでも対応はしない。まあ、ヒョージュンカを進める際に抵抗勢力を暴れさせないための、高度な交渉テクニックですね。
象徴的なやり方が、反対意見を無効化するというやり方だ。
反対意見に対して正面から議論をすると、自分が不利になることが分かっている。だから、出された意見に対しては「今後検討します」というような形でいったん預かっておく。でも、預かるだけで、その後も回答は行わない。
とても不親切なやり方だね。
また、そもそも反対意見自体を集めないようにして、目立たたせないという方法もある。
部長の中のお化け：
会議のメンバー選定は、地味に大事なところなんだよな。
ここで、この前の店長みたいなウルサイ人を入れてしまうと、設計内容が全くまとまらなくなるしね。
会議のメンバー選定は、まさに重要なところ。
うるさい人を遠ざけて、システム導入の関係者と言葉を交わす機会自体を失くしてしまう。
まあ、ほんとうに姑息な手だよね。全く。
上記文章は、著書「スタンダリアン：標準化お化け」からの一部抜粋です。