読者です 読者をやめる 読者になる 読者になる

大多数が犠牲なる仕組みを事前に張り巡らせてそれがいつまでも継続されるという罠

仕組み化の目的は、仕組み化の対象が目指す目的を最大化するため、また、それを持続可能なために行うものかと思います。
ただ、その仕組み化に必要なプロセスである「事前検証」が原因になって大多数が犠牲になる仕組みを構築してしまう場合があります。

事前検証が原因になって大多数が犠牲になる仕組みを構築する具体的なケース

「事前検証が原因になって大多数が犠牲になる仕組みを構築する」具体的ケースを想定してみます。

{{想定ケース}}

  • サービスベンダー企業が主体
  • その企業は同業他社の中では中位程度
  • BtoB
  • サービスの具体的な説明のために、マーケティング部門主導でセミナーを開催する
  • 同セミナーはマーケティングリードからセールスリードへの移行を目的としている

この想定のような、セミナーを仕組み化する場合には、ざっくりと * セミナーコンテンツ * 受付方法 * 告知方法、対象 * 来場促進施策 * 来場後のフォロー (セールスへの引渡し)

等々を仕組み化していく必要が生じます。(この仕組みが本旨ではないので、本当にざっくりですが、、)

仕組み化の事前検証を行なっていく中では、様々な例外対応を想定する必要に迫られてきます。
「満席になった場合の締め切り」「キャンセル待ち処理は」「登録完了メールが不達だった場合」...等々

この例外対応を考えていく中で、競合の参加は排除しなければ という事が話題に上がったとして、「事前検証が原因になって大多数が犠牲になる仕組みを構築する」罠にハマることを考えてみます。

例外を細部にわたって想定するのが楽しくなってしまう。

この罠にはまってしまう時の会話を「偉い人」と「担当者」という2名の登場人物で単純化して妄想してみます。

偉い人: 「このセミナー、きちんと競合対策考えているの?重要な情報が漏れたらまずいからね。」
担当者: 「はい、そうですね。会社名を見て、競合と判断したら断りのメールを入れるようにします。」
偉い人: 「同じ企業でも部門によって、競合であったりなかったりするから部門まで見るべきだな。」 担当者」 「は、はい」 偉い人: 「あと、いったん受け付けた後に、断りメールとか失礼になるかもしれないから、はじめは仮受付にしてあとで受講確定のメールをしたらどうだ。」
担当者: 「なるほど、では一旦仮受付して、OKとNGを後からメール送る形にします。」 偉い人: 「お客様を待たせてはダメだから、一日一回は必ずチェックするんだよ!!あと、はじめのメールで申込完了ではない旨はわかりやすく表示しておくように。タイトルに(仮)といれたり、冒頭の登録完了ではありません。とか記載したり」 担当者: 「。。は、はい」 偉い人: 「しかしアレだな。これは、受付システムで競合企業のデータベースと突合して自動で判断できないものか?」 担当者: 「ただ、会社名はローマ字で入力されたり略称だったり揺れてしまいますから、、、」 偉い人: 「そうか、、ではIPアドレスで会社名が分かるサービスがあるらしいから、そのあたりと連携してはどうだ」 担当者: 「モバイル機器からのアクセスだったりすると無理になりますし、、あと、予算が、、」 以下、喧々諤々。。。その後 偉い人: 「では、一旦は手作業で回して問題が発生したら随時見直すという事で」

かなり極端かと思いますが、詳細を考えるのが楽しそうですね。。
また、競合対策というのは「きちんと」という枕詞によって反証が難しい正当性を持たされています。

このような会話を経て、このセミナーは

  • 申込者がセミナー申込をすると「(仮)申込受付完了」という謎のタイトルのメールが配信される
  • その後、担当者が会社名、部署名等を確認したあとに正式に登録完了のお知らせが申込者に届く

という仕組みが構築されてしまいます。

目的が手段かして、オペレーションは疲弊していく。顧客はイライラする。

この仕組が運用フェーズに入っていくと、どうなるのでしょうか?

担当者は、毎日毎日申込者リストを確認してOK,NGメールを配信し続けます。
もしかしたら、配信漏れ防止対策として「配信結果のダブルチェック」等もあるかもしれません。。

悲しいですね。

なにが悲しいのでしょうか。このセミナーは本来「マーケティングリードをセールスリードに移行する」事が目的だったはずです。 であるならば、その目的のために最大限のリソースを割くことが望ましいです。 しかし、このオペレーションでは、競合排除という手段のためにかなりの工数を割かなければなりません。

常考えて、排除しなければならない競合がかなり多く申し込まれるという事は想像できません。あっても数回の開催で1回、もしかしたら、過去に数回あっただけかもしれません。
これでは圧倒的少数の「競合排除」という物のために、担当者、顧客が我慢を強いられるという仕組みになってしまっています。

少数の競合を排除するために、顧客、担当者等大多数が不利益を被っています。
これで誰が幸せになっているのでしょうか。。

これは俗にいわれる、手段の目的化と呼ばれているものですよね。
さらに悪い事に、「検閲作業に時間がかかるために直前に申し込まれると困る」という問題を解決しなければならない。
そのためには、「申込をある程度前に締めきって検閲作業時間を確保しなければならない」というような手段が目的を排除するという様な状況も発生するかもしれません。。

申し込んだ顧客からしても、有料のスキルアップセミナーなどならいざしらず、このようなセミナーで(仮)とか言われても困ってしまいますよね。

なぜ、発生してしまうのか

なぜ、このような手段の目的化が発生するのでしょうか?

原因として考えられるのは、目的を忘れ手段の詳細化を楽しんでしまったという事でしょう。 例外パターンの詳細を思いつく。それを潰す方法を考える。このサイクル自体を楽しんでしまうという事です。 上記の想定でいうと、競合対策の必要性是非が語られずに、いかに競合対策を詳細に考えて実施するのかという事に力点が置かれて、さらにその事象の詳細が次々とでてしまっている状態です。

確かに、仕組み化を行う上では事前に検証する事は必要ですし、例外対応を事前につぶしておくことは大事です。さらに、そのような例外の詳細を想定できることも優れた能力、経験の一つです。
ただ、それら全てに対応する必要があるかといえば、それはまた別のお話ですよね。

どうやって避けるのか?

こんなことを書いておきながらですが、、この手段の目的化というのはとてもとてもハマリやすいものであると思っています。こうすれば避けられるという銀の弾丸は存在しないでしょう。 ただ、「目的を明確に意識する」という事である程度は避けられると思っています。

また、話題が例外の詳細な事象に及んだ時には、

  • その例外の発生頻度はどう程度なのか?
  • その影響度は?
  • その例外は本当に防げるのか?
  • もっと言えば防ぐ必要があるのか?
  • 代替回避策はないのか?

などを考えれば避けやすいのでは無いかと思います。

競合排除で考えると、過去にどの程度競合は申し込んできたのか?それが過去数回であれば積極的に工数をかけるのは難しいと言わざるを得ないのではないか。
競合がセミナーに申し込んできたとしたらどの程度の影響があるのか?必ずダメといっている人の手元には競合の情報があったりしないのか?競合相手の情報は入手できているのに、自社情報は競合に流れるのを防げるというのは少し厳しいのではないのか?
そもそも、競合に情報が流れるのを防ぐということが優先順位高いのであれば、セミナーという行為自体どうなんだ。(本末転倒)
上記の仮受付にして排除しようとしても、競合が別の会社名で申し込んできたらどうするのか?結局競合に情報が流れるのは避けられないのではないのか?

などを考えていけばとりあえず仮受付にしようかという意思決定は避けられるのではないかと思います。

事前検証は仮説であって事実ではない。はずだった

検証している時に避けるために意識をできてさけるのがいいのでしょうが、どうしてもそうならない時もあるかとおもいます。 そのために、その事前検証の仮定が正しかったのか?という検証が必要になります。これが以外に抜けてしまいます。

事前検証は、過去の経験から導き出されれたり、仕組み化以前の現象をもとにした仮説です。
本来は、継続的にそれを検証し続けなければならないのですが、、
そもそも、そのオペレーションが必要であった前提を検証することなく、さらなる最適化だけになったりすると、、、何時までたっても悲しいオペレーションはなくならないですよね。
洗練された悲しいオペレーションが出来上がるだけです。

その事前検証は正しかったのか? 事前検証の時に出された数字は今も正しいのか?を問いかける仕組みが必要になってきます。
正しくないこともいっぱい出てきて辛い事も一杯でてきますが、、それが、当たり前になることが現実解としていいのではないかと思っています。