見出し画像

問題解決の仕組みを学んだことがない方向けに、問題解決をできるだけ細かく説明してみる

「創業からHRトレンドブログ公開数400本間近!2022年カウントダウンブログリレー」という企画を12/1からスタートしております!そして、今回は第10弾となります。当社ごとですが、会社として出したブログ公開数が2022年11月末時点で380本!12月は毎日(営業日)ブログを公開するとちょうど400本に到達する!ということで多くのメンバーが参加するブログリレーを実施することにいたしました。スケジュールはこちらとなります👇

では、ご覧ください。

問題解決の手法/仕組みを覚え、身に付けることによって人生のあらゆる場面で活用することができます。問題解決と聞くと難しく捉えがちですが、シンプルに考えると後はそれに当てはめるだけになるので、一生使うこともできます。

例えば「お金が貯まらない」「仕事に身が入らない」「上司とうまくいかない」「人生で楽しみを見出せない」「友達と喧嘩をしてしまった」など、人生においては仕事を含め様々な問題が発生します。ただ、その問題に対して「何とかなるだろう」「まぁいいか」と放っておくと問題は解決されない。「時間が解決してくれる」という言葉がありますが、これは「たまたま」です。論理的に、必然的に解決されるわけでは無いことを理解しておいていただきたいと思います。

とは言いつつも、本文章は仕事をするうえで参考になる内容を書きたいと思いますので、仕事に寄せた内容にしたいと思います。


0. 問題とは?

「問題」という言葉を見るとネガティブな捉えられ方をするのですが、決してネガティブではありません。なぜならば、問題解決において問題の「特定」が最も難易度が高く、問題さえ見つかってしまえば後は解決するだけで物事がうまく進むからです。

そもそも問題とは何か?
様々な定義があるかと思いますが、山根の定義は「理想と現実とのギャップ」です。理想というのは「ゴール/目標」と表現したほうがイメージがつきやすいかもしれません。皆様も、日々生活していくなかで「理想」が存在するかと思います。

起きる時間の理想
朝ごはんの理想
通勤時間の理想
仕事内容の理想
ランチの理想
人間関係の理想
仕事のスピードの理想
帰宅時間の理想
夜の過ごし方の理想
成長の理想
自己実現の理想

様々な「理想」がなんとなく存在するかと思います。
これらの理想を強く願う場合に、現実とかけ離れている場合が発生するかと思います。その「かけ離れている尺度」が問題であり、問題の大きさと表現できるかと思います。

わかりやすい具体的な事例を記載しましょう。

あなたは営業マンだったとします。毎月の売り上げの目標は1,000,000円。ただ11月25日段階で売り上げが300,000円しか進捗していなかった。これは問題でしょうか?

結論としてはこれは「問題」です。11月25日段階では1ヵ月の80%程度が経過してしまっています。そのため1,000,000円の目標であれば800,000円程度進捗していなければならないところを、300,000円しか進捗していなかった。これは約500,000円の「理想と現実のギャップ」が発生しているわけです。これは明らかに問題と言えるでしょう。

上記はわかりやすい事例でしたが、そもそも問題とは何か?と感じてしまうことも多くあるため、次項で説明していきたいと思います。


1. 問題解決のフロー

話が行ったり来たりしてしまいすみません。まず各論から入る前に全体感の話をしましょう。問題解決のフローについてです。結論を記載します。

問題の特定
仮説(原因)のピックアップ
仮説(原因)の優先順位設定
仮説(原因)を解決するための施策の設定
施策の優先順位の設定
施策の担当者/期限の設定
施策の振り返り

こんな感じのフローかなと思います。
では具体的な説明をして参りましょう。


2. 問題の特定

諄いようですが問題とは「理想と現実のギャップ」です。そのため「理想」の状態を定義できなければ問題を特定することができません。問題解決の様々な本に記載がありますが「問題解決の中で問題の特定が最も重要」という発信をしている方も多く、山根もそれに対して賛同しています。

ではどのように問題を特定するのか?いくつかのパターンに分かれます。

 2-1. 自分で理想(ゴール)を設定する場合

自分が何かを成し遂げたいときに、自己実現をしたい時などは、自分自身で目標設定をすることがあるかと思います。目標設定=理想(ゴール)の設定とご理解ください(本ブログでは「理想(ゴール)」=目標」を同義語として使用します)。
この場合は問題の特定自体はシンプルにすることができます。なぜならば、自分が掲げた目標に対してのギャップを調べてみれば良いからです。ただ1つ注意していただきたいのは「目標の大きさ」です。目標が壮大(大きい)であればあるほど目標達成までの期間が長く必要になり、仮に確固たる目標を設定したとしても、それを「分解」しなければならない可能性もあります。「分解」とは何かというと、皆様に馴染みがある(かもしれない)言葉で表現すると「KPI」のイメージで良いかと思います。

少し話がずれますがKPIをシンプルに説明すると「その目標を達成するために最も重要視すべき指標(数値)」です。例えば、不動産の賃貸会社であれば来客数、アパレル店舗であればお客様へ接客できた数、などのイメージです。先ほど目標を「分解」と表現しました。目標が大きければ大きいほど、この「KPI」を「目標」にしてしまう場合があります。なぜならば、目標が大きければ大きいほど「KPI」を達成するための「KPI」が発生してしまうことが多いからです。

例えば、SDGsをイメージしてください。詳細な説明は割愛しますが、地球に住んでいる全世界の方々が意識して初めて達成できることかもしれません。そうなった場合「〇〇年までにSDGsの17の項目を達成する」という目標がある場合に、それを達成するためには様々な項目の「分解」が必要なわけです。

日本ユニセフさんのページを引用させていただきました。上記をご覧いただけるとご理解いただける通り、17に分解して考えています。そして、分解した各目標も壮大な目標であることが多いため、さらにこの分解された目標について、さらに分解をしていく、そしてさらに分解をしていく、この繰り返しの作業が必要です。

話を戻すと、「自分で理想を設定する場合」は、その大きさが重要であり、そして大きさによっては分解する必要があることをご理解いただければと思います。

 2-2. そもそも理想(ゴール)がわからない場合

このパターンはビジネスにおいて割と多く発生することが多いです。特に、自分が担当している業務が、在籍企業において過去の経験/事例が少なければ少ないほど、目標の設定自体が難しいです。また、「これくらいの数値であれば問題ないであろう」という設定自体も、前例がなく苦労します。そして、顧客の概要/状態によってカスタマイズしなければならない場合もあり、目標の設定自体の難易度が高いことがあります。
ただ、どのようにすれば理想(ゴール)を設定できるのか。重要になるのは「データ」です。

ここまでの話を整理しましょう。
本ブログは問題解決の手法/仕組みを説明しています。

問題解決をするためには、まずは問題の特定をしなければなりません。
問題の特定をするためには、理想/ゴールの設定をしなければなりません。
では、理想/ゴールの設定はどのようにすれば良いのか?

↑ 今ココの説明をしています。

先ほど理想/ゴールの設定をするために「データ」が重要になるとお伝えいたしました。この「データ」は3通り存在しています。

1つ目は「自社」のデータです。
問題を特定するために対象となる「業務」において、自社で過去にその業務経験/実績があるのであれば、そのデータは参考にすべきです。なぜならば、自社が歩んできた軌跡が目標設定において大きく参考になるからです。今まさにサッカー ワールドカップが行われているためサッカーの話をしましょう。サッカー大国ブラジルの目標は「優勝」かと思います。日本の本大会の目標は「ベスト8」と聞いています。これは、ブラジルと日本の「過去の実績/データ)」をもとに算出された目標と言えるでしょう。つまり、自社における過去の経験/実績をもとに目標を設定するのは仕事のみならずスポーツ界や様々な領域において取り組まれている1つの手法なのです。

2つ目は「他社/他者」のデータです。
「自社」だけに目を向けていると、視野が狭くなりがちです。また、仮に自社の実績が芳しくない状態が続いた場合、自社の数値を参考にし続けると、大きな実績を上げることができないことが多いです。つまり、目標設定自体のレベルが低くなるパターンです。
そんな中、その対象となる業務を競合他社が既に実施していることがあります。競合他社における実績がどの程度なのかを知ることによって、目標設定をしやすくなります。仮に自社よりも他社の方がはるかに大きな実績を「同じ環境」で作れていたとしたら、自社のデータを参考にせずに、他社のデータを参考に目標設定をするべきかなと思います。

3つ目は「日本/市場」のデータです。
前述しましたが、自分自身が取り組む業務において、自社ならびに他社でも事例が「ない」場合もあります。その場合は「そもそもデータがありません」「データがないから目標設定ができません」というのもあまりよろしくない事はご理解いただけるかと思います。
その場合は目標設定をするために必要な「周辺のデータ」をあらゆる調査をして持ってくる必要があります。例えば、2018年頃からトレンドとなっているSaaS企業の場合、誰も開拓したことがない、そして誰も提供したことがないゼロからイチを創出するプロダクトであることも多いです。その場合、「その業界の規模はどの程度なのか」「そのプロダクトが解決したい課題においてどの程度の人件費がかかっているのか」「そもそもその業界には利益が蓄積されているのか」など様々な周辺データを活用して目標設定をします。この場合 目標設定は「仮説」が含まれる場合もありますが、自社/他社でデータがない場合は、あらゆる周辺データをかき集めて、目標設定をすることもあります。

本項において、当社ポテンシャライトの話をしましょう。当社はIT/Web業界、ベンチャー企業向けに採用支援をしている企業です。採用ブランディング、採用マーケティング、媒体/エージェント様を用いた採用実務支援、ほか様々な支援をしています。特に、「採用実務」においては様々な媒体/エージェント様のご支援をさせていただき採用活動を進めています。ここで、仮に「1ヶ月で1名のエンジニア採用を成功させる」という目標があるとしましょう。何度も説明していますが、目標との差分が問題なわけです。この差分が発生した場合 問題となりますが、問題を分解したときにどのような内容が想定されますでしょうか?

例えば、カジュアル面談数が少ない、1次面接数が少ない、内定からの入社承諾率が低い、スカウト返信率が低い、スカウト送信数がそもそも少ない、などが想定されます。
ただ、皆さまここで質問です。前述した「〇〇が低い/少ない」は、何を基準に低い/少ないと論証できますでしょうか?

カジュアル面談数が少ない、と言い切れる「基準値」は何なのか
スカウト返信率が低い、と言い切れる「基準値」は何なのか
各媒体におけるスカウトの返信率は異なるのではないか
それであれば各媒体におけるスカウト返信率の「基準値」は何なのか。

お気づきの方はもういらっしゃるかもしれませんが、問題を「特定」するためには、一定の「知識」が必要です。ただ ご安心ください。知識がなくても「データ」をしっかり出せる環境にいれば何も怖くありません。もちろん仕事をするうえでパーフェクトな知識を身に付けておけば素晴らしいですが、さすがにそんなにパーフェクトな人材はいません。そのため、まず仕事をするうえで必要になりそうなデータの"在処(ありか)"を知っておくこと。そしてさらに重要なのは「あれ、問題を特定するためにこのデータ(基準値)がなければならないな」と気づくことです。

本ブログで最も重要な箇所の1つがこれかもしれません。このデータ(基準値)を、どう考えても自分自身で回収できない場合はどんなに努力してもあまり意味がありません。ここでは即座に上長や他のメンバーに確認しましょう。

「今、問題を特定するためにこのようなデータを探しています。自社にこのようなデータはありますか?もしくは他社調査をしたり媒体側に確認したほうが良いでしょうか?」

という質問をできるかできないかが仕事をするうえでは非常に重要です。

長くなりましたが問題の「特定」については以上です。ただ、ご安心いただければと思うのですが、問題の特定ができたら後は割とスムーズに進むことが多いです。僕もよくメンバーに伝えていますが、「問題がわからないことが不健全な状態、問題が明瞭になればそれを解決するだけで良いので、話がすぐに前に進む」という感じです。


3. 仮説(原因)のピックアップ

さて、問題が特定できました。問題が特定できたら次に仮説(原因)のピックアップをしましょう。

繰り返しになりますが、本ブログは当社ポテンシャライトのメンバー向けに執筆しています。そのため、当社メンバーのわかりやすい事例を用いて説明したいと思います。

仮に、「スカウトの返信率が低い」という問題を特定できたとしましょう。その場合、「スカウトのテンプレート(文章)を変えよう、スカウトの件名(タイトル)を変えよう」と、すぐに施策にジャンプしてしまう方が多いのですが、これはよろしくありません。なぜならば、「スカウト返信率が低い」という問題に対して、「スカウトのテンプレートが好ましくない」ことが原因ではない場合ももちろん発生します。例えば、「調べてみたところ、直近1ヵ月間そのスカウト媒体にログインをしていない方々にスカウトを送信していた」という実態が分かった場合、それが原因の1つになります(1ヵ月間ログインをしていない方々に対してスカウトを送信しても効果が得られにくい理由は割愛します)。

話を戻して、「スカウト返信率が低い」という問題を特定できた場合は、出来る限り多くの仮説(原因)をピックアップすることがファーストステップになります。例えば、

テンプレート(文章)が好ましくない
件名(タイトル)が好ましくない
送信アカウントが好ましくない
送信タイミングが好ましくない
送信先の求職者のレベルが高い
送信先の求職者の転職意向が低い

挙げればキリがないのですが、このような仮説(原因)が想定されます。誤解がないように申し上げると、これらはあくまで仮説に過ぎません。つまり、特定できた問題に対して「仮の原因」になります。ただ、仮説を論証する必要があります。仮説を論証するためには繰り返しになりますが「データ」が必要になります。

例えば「テンプレート(文章)が好ましくない」という仮説が正しいかどうかを調べるためにはどうしたら良いのか。各論になりますが、スカウトメールは「そもそも開封されているか」「開封されており返信に至ってないのか」という2つの分岐があります。前者であれば、そもそも開封されていないため、ユーザーがテンプレートに達して(閲覧して)いません。後者であればテンプレートを見てはいただいているため、1つの理由になり得る可能性があります。

ただ、あくまで1つの理由になり得るという話です。もし仮にそのスカウトメールが、「スカウトメールのテンプレート(文章)」のみで候補者様が返信をするか否かを決める場合は、テンプレートが好ましくないという仮説は正しいと言えますが。

ここで皆さん少しイメージしてみてください。
例えば、候補者様がスカウトメールを開封して、テンプレート(文章)を見たとしましょう。もし仮に皆さまが候補者側であれば、スカウトメールのテンプレート(文章)「のみ」を見て返信するか否かを決定しますでしょうか?「はい」と回答する方もいらっしゃるでしょうし、「いいえ」と回答する方もいるかと思います。仮に「いいえ」である場合は、こんなことが考えられます。

その求人内容の別のページに見に行った
求人内容に記載がある写真を見た
求人内容を見たうえで会社のホームページに遷移して見に行った

などの可能性が考えられるかと思います。もちろんこれは可能性の話です。繰り返しになりますが、スカウトメールの「テンプレート(文章)」のみを閲覧して返信するか否かを決める方もいらっしゃるでしょうし、そのうえで返信するか否かを判断するために別の「何か(のページ)」に遷移する方もいらっしゃるでしょう。

話を戻すと、このパターンでは「テンプレート(文章)が好ましくない」という仮説が100%正しいとは言い切れません。ただ、その理由としては正しいでしょうし、この仮説が70%正しいと言えるかもしれません。本件を判断するにあたり、やはりスカウトメールをそもそも開封しているか否か、という部分までは確実に抑えておきたいものです。

本項では「仮説(原因)のピックアップ」と題しているのですが、この仮説についてはなるべく多く挙げてみると良いかと思います。
なるべく多く挙げる理由は次項に答えを書きます。


4. 仮説(理由)の優先順位の設定

前項で詳細に説明いたしましたので、本項は端的に説明していきたいと思います。

仮説(原因)をできるだけ多くピックアップしましょう、という話をしました。何故かというと、1つ目に思いついた仮説が本質的な原因ではない可能性もあり、思考すればするほど仮説は多く生まれてくるものです。仮説を出来る限り多くピックアップした後にする作業としては、その仮説の中で「優先順位」を設定します。

先出しをすると、優先順位をつけた後は、その仮説(原因)を解決することができる「施策」の考案をします。この「施策」の考案について、仮説(原因)の数が多ければ多いほど、施策を考案すべき数も増えていきます。もちろん20の仮説があるのであれば、その20を解決することができる施策を20通り考えても良いのですが、やはり大変です。そのため、仮説(原因)の優先順位を設定して、問題の大小によりけりではありますが、3つほど施策を立てる手法がオーソドックスです。

優先順位の設定の仕方については、前項で触れましたが「データ」が重要です。ここで1つ誤解がないように説明をすると、特定できた「問題」とその「原因」は捉え方によっては両者ともに「問題」と考えることができます。例えば、先程の「スカウトメールの返信率が低い」という問題が特定できた場合、「テンプレート(文章)が好ましくない」という「原因」があるとします。ただ、捉え方によっては「テンプレート(文章)が好ましくない」という「問題」とも言えますよね。そのため問題の大小によりけりですがと表現したのがその理由ではあるのですが、「問題」と「原因」は見る角度によっては両者とも問題と捉えられる、という補足だけしておきます。

話を戻します。
優先順位の設定については、「データ」が重要という話をしました。様々な仮説(原因)をそれぞれのデータを見ながら、仮説(原因)の「重さ」を見比べてみることが重要です。
例えば「スカウト返信率が低い」という問題があったときに、「スカウト開封率が低い」「スカウト開封からの返信率が低い」という2つの問題に分解してみましょう。前者の市場平均が70%に対して、自社は20%。後者の市場平均が30%に対して、自社は25%。ここで言う前者と後者で見比べたときにどちらの優先順位が高いでしょうか?言うまでもなく「前者」ですよね。ただ、この事例を見れば一目瞭然にはなるのですが、ここまできちんと問題特定⇒仮説(原因)を出来る限りピックアップする⇒仮説(原因)の優先順位を設定する、というオーソドックスな手法に沿って問題解決をする人は僕の社会人経験の中でもそこまで多くは見たことがありません。優秀な方は感覚的にこちらを実行しているケースが多いですが、意識しないとこの手法の通りにやらない方が多いのではないでしょうか。

このような手法で「優先順位」を設定すると、次に、原因を解決することができる施策を立案するステップに進みます。


5. 仮説(原因)を解決するための施策の考案

前項で説明した通り、施策の考案をするステップです。どのような問題なのか、そしてどのような仮説(原因) なのかによって施策が変わってきます。非常に重要なのは、

「仮説(原因)」を解決するための施策であること

です。
ポテンシャライトで「それって施策ドリブンだよね」と指摘し合ったりすることがあるのですが、これは「問題」から「施策」にジャンプしていることを指します。本ブログのどこかに記載したのですが、別の事例を改めて記載します。

例えば、ダイエットしたい人がいるとします。その際に「ご飯を少なくする」という施策に一気にジャンプをする人がいます。これは結果的に体重が減るかもしれないのですが、そもそも体重が減らない「原因」をピックアップしてみてから、その原因を解決するための「施策」を立ち上げた方が効果的です。もしかしたら「代謝を上げたほうが良い」かもしれませんし「食べるモノを変えれば良い」かもしれませんしね。

そのため、僕自身よく注意をしているのは、施策を考案するときに頭の整理をすることです。例えば、

◆原因
 - 1-1. ●●
 - 1-2. ▲▲
 - 1-3. ○○
◆施策
 - 2-1. 1-1を解決するための施策
 - 2-2. 1-2を解決するための施策
 - 2-3. 1-3を解決するための施策

せっかく優先順位の高い原因に辿り着いたとしても、施策が「連動」していなければ意味がありません。そのため、強制的に「原因」と「施策」を連動させるために数値を使うとわかりやすいです。
繰り返しになりますが、施策はあくまでも「原因」を解決するために存在します。そのため、本ブログの本項においては細かく記載はしませんが、ご認識いただければと思います。


6. 施策の優先順位の設定

前項で「仮説(原因)を解決するための施策であること」「原因 と 施策 を連動させる」という話をしました。
因みに、ある原因に対して施策が複数存在していても問題ありません。下記をご覧ください。

◆原因
 - 1-1. ●●
 - 1-2. ▲▲
 - 1-3. ○○
◆施策
 - 2-1. 
  - 1-1を解決するための施策①
  - 1-1を解決するための施策②
  - 1-1を解決するための施策③
 - 2-2. 1-2を解決するための施策①
 - 2-3. 1-3を解決するための施策①

という感じです。
つまり、原因1-1に対して施策が3つ発生することもあり得ます。
ただ、上記において施策が合計5つになりますよね。この5つを全て実行しても良いのですが、単純に施策を実行するのが大変です。また、施策を複数並行する際の欠点があります。それは、

成果が出た際に「検証」ができないこと

です。
仮にこの5つの施策を「同時」に実施したとしましょう。そして成果が出た(良くなった)としましょう。その場合、この5つの施策の中で何の施策がヒットしたのかがわかりません。成果が出たことはポジティブでしたが、「え、結局何がどうなって実績が出たんだっけ?」となりますね。

そのため、施策にも「優先順位」を設定すると良いかと思います。5つの施策を全て実行するのではなく、そのうちの2つを実行してみる、などはありです。もしかしたら「山根さん、施策はいくつまで並行して実施して良いのですか?」というご質問を受けてしまうかもしれません。その際は注意が必要です。それは、施策の結果を「検証」する(できる)箇所が異なるほうが良いこと。

つまり、施策を同時並行した際に「期待したい成果の項目」がありますよね。例えば、スカウトの「開封率」を上げたいのか、「開封からの返信率」を上げたいのか、この2つの問題/原因を解決するために施策を実行する場合、1つは開封率を上げるための施策、もう1つは開封からの返信率を上げるための施策であれば、施策の検証がバッティングしません。一方で、スカウトを開封させるためにスカウトの件名(タイトル)の変更をして、且つそのスカウト開封のために「アカウント名(CEO or 人事?など)」も同時に変更をしていた場合、成果が出たとすると、「件名(タイトル)」と「アカウント名」のどちらの施策がうまくいって成果が出たのかが分からなくなってしまいます。そのため、いずれかを実施してから、もう1つを実施する、というほうが良いかなと思います。

ただ、ひとつご認識いただきたいのは、先ほどの事例にある「件名(タイトル)」と「アカウント名」について、「アカウント名」は「”間違いなく” 人事アカウントよりもCEOアカウントのほうが開封率が高い」という立証がすでにあるのであれば、施策を同時並行してしまうのも手です。補足として、「検証をしたいから一つずつ施策を打っていきましょう」と、そんな余裕もない場合もありますよね。その場合は致し方ないです。最も大事なのは早期に成果を出すことになりますので、打てる施策は全て打ちましょう、というのもアリです。この場合はきちんとステークホルダーの方に説明をしたほうが良いかと思いますが。


7. 施策の担当者/期限の設定

前項で施策の優先順位の話をしました。この後は「では、施策を実行しよう!」というフェーズに入ります。ただ、ここで新たな問題が発生することがあります。それは「担当者」と「期限」の設定です。

ここまで時間をかけて問題を特定し、原因をピックアップし、優先順位を立て、施策を考案し、優先順位を立てました。すごく大変かと思います。
にもかかわらず、施策を考案して満足してしまう方がすごーーーーく多い印象を持ちます。

当社では「施策倒れ」という言葉を使いますが、せっかく施策を考案したのに未実施で終えることです。なぜ「未実施」になってしまうのか。原因を飛ばして回答から申し上げると「担当者(責任者)」と「期限」がないからです。

皆さま、小学生のときに自分のクラスに「黒板係」がいませんでしたか?黒板係は「授業を終えた際に黒板を消す」という係かと思います。あれは係として「担当者(責任者)」が決まっているため機能をしています。ただ、「黒板は常に綺麗にしたほうが良いよね」という施策があった場合、「担当者」を決めなければ「え、誰がやるの?」だったり「昨日はできていたけど、今日はできていなかった」という事象が発生します。

「そんなの当たり前だろ」と言う方も多いかと思いますが、仕事においてこの類の事象はものすごく多く発生することが多いです。「え、これって誰かやっているっけ?」「この前の●●の話って、誰がオーナー持っているの?」という類です。つまり、

 - 施策を決めたのにも関わらず実行をしない
 - 施策を実行したりしなかったり徹底できない

この2つは施策倒れの代表的な事例です。

もう1つ大事なことを前述しました。それは「期限」です。
仮に施策が実行できたとしても、「検証」しなければ効果(意味)が激減します。なぜならばその施策がうまくいったのか否かがわからないため、ノウハウが蓄積しないからです。

例えば、「スカウトのテンプレート(文章)を変える」という施策を実行したとしましょう。この施策を検証するためにはどの程度の「期間(期限)」が必要でしょうか?1週間ですか?2週間?1ヶ月?3ヶ月? 意思を持った期間設定であればどれでも問題ないのですが、この施策の検証は「期間(期限)」というよりも「通数」のほうが重要度が高いかなと思います。

少し話を逸らします。先日メンバーからこんな質問を受けました。

「施策の検証をしたいのですが、検証をする上で ”必要な時間/件数” はどのように決めればよろしいでしょうか?」

そうですよね。施策を実行したとして、「いつ」検証をすれば良いのか?と言われると、ケースバイケースと言わざるを得ないかもしれません。
事例ベースで話をしましょう。先ほどの「スカウトのテンプレート(文章)を変える」という施策を実行した事例です。
テンプレート(文章)を変えた後に、もちろんのことスカウトメールの送信をします。10通、20通、30通と送信していきます。何通送信したら検証をしたほうが良いのか?については、そのスカウトをしている媒体の「返信率」が重要です。結論としては、その返信率の「効果検証をすることができる必要数」が検証に最適な件数と言えます。

もう少し詳しく説明していきます。
例えば下記の事例をご覧ください。

◆事例A
 - そのスカウト媒体の返信率は10%であった
 - ★1 スカウトを10件送信してみたが、返信は0件だった
  - 10%であれば10件送信して1件返信が妥当数。
  - ただ、0件であった。
 - ★2 スカウトを合計20件送信してみたが、返信は3件だった
  - 10%であれば20件送信して2件返信が妥当数。
  - ただ、3件であった。

結論としては、僕は上記において「★2」の時点で検証をするようにしています。
「★1」はたまたま成果が出ていないかもしれません。10件送信をして1件返信がなければならないところ、0件であった。ただ11件目を送信して1件返信がくるかもしれません。12件目で返信がくるかもしれません。ただ、20件送信をして1件も返信がこなければ「危ない…」と感じますよね。
この媒体の返信率は10%という記載があるので、10件送信すれば1件返信が妥当数です。この「10件」の2倍の数、つまり20件が「第一次検証タイミング」と僕は設定しています。少し分かりづらいのでもう1つ事例をご覧ください。

◆事例B
 - そのスカウト媒体の返信率は2%であった
 - ★1 スカウトを20件送信してみたが、返信は0件だった
  - 2%であれば20件送信して0.4件返信が妥当数。
  - ただ、0件であった。
 - ★2 スカウトを合計50件送信してみたが、返信は0件だった
  - 2%であれば50件送信して1件返信が妥当数。
  - ただ、0件であった。
 - ★3 スカウトを合計100件送信してみたが、返信は3件だった
  - 2%であれば100件送信して2件返信が妥当数。
  - ただ、3件であった。

上記の事例Bにおいては「★3」の時点が第1次検証タイミングかなと思います。
返信率が2%と仮定すると「50件」送信して1件の返信ですよね。となると、「50件」の2倍の数、つまり100件が「第一次検証タイミング」と僕は設定しています。

話を戻すと、
施策を実行する上で「担当者」と「期限」は非常に重要です。担当者は前述した通りですが、「いつ検証するのか?(期限)」は施策実行前に決めましょう。そうすることによって強引に検証の機会を得ることができ、非常に有意義です。

ちなみにポテンシャライトでは強引に検証のタイミングを設定するようにしており、そこで振り返りの機会を設定しています。


8. 施策の振り返り

これは前項でほぼ説明をしたため、シンプルに説明をして参ります。

施策を実行した場合に「担当者」と「期限」を設定しましょう、という話をしました。
しっかりと実行ができた場合は「振り返り(検証)」をしなければなりません。繰り返しになりますが、振り返り(検証)をしない施策は効果(意味)が激減します。なぜならば、その施策がうまくいったのか否かが分からないため、ノウハウが蓄積しないからです。ノウハウが蓄積しないと何が起きるかというと、また同じ問題に直面した際に、施策立案時に「あれ、この前の施策って結局成功したんだっけな…」と、同じ問題解決を再度しなければならなくなります。そのため、振り返りが大事というわけです。

ちなみに、皆さま会社単位 / 事業部単位 / グループ単位 で「定例ミーティング」ってありませんか?会社単位でいうと「月次の締め会」、事業部単位でいうと「月次の戦略会議」などなど。これはなぜ実施しているかというと、問題解決において考案をした施策の「検証」が目的の1つであることが多いです。つまり(月次での話に焦点を絞ると)、「今月1ヶ月の施策は●●だったけど、結果は▲▲だった。振り返りとしては…」といった具合いで、施策の「検証」がメインになります。もちろん多くのメンバーの時間を確保するため、細かく振り返りの結果を伝えることはできないかもしれません。つまり「共有」のみで済ませる場合もありますよね。細かい内容は後日朝礼で話しますね、のような感じで。

話を戻すと、施策を考案して担当者と期限を設定したら、必ず振り返りのミーティングなのか、チャットで報告をするのかなどを、忘れないようにしましょう。最も効果的なのはカレンダーに強引に設定することです。メンバー全員が自立できている企業であればそのような仕組みがなくても良いかもしれませんが、仕組みがない場合で全施策の振り返りがなされている企業を見たことがありません。

あとがき

2022年、すでに師走に入りかけていますが、おそらく2022年で最も文字数が多い内容でした。

こちらのブログを書いていて気付いたのですが、「問題解決」について社内のメンバーに伝えているときに「断片的」に伝えていることに気づきました。問題解決は1本の線につないで理解をする必要があると個人的にも思っていましたが、1時間の研修で細かく本ブログの全部の内容を伝えられることもなく、結論としては詳しく書けてよかったです。

また、「問題解決」の手法は皆さまそれぞれの細かいテクニックがあるのではないかと思います。僕も、これまでの社会人人生の中で培った経験を反映しています。ただ感覚的に問題解決を実行していたので、改めて自分自身の問題解決の手法/仕組みの頭の整理ができて本当に有意義な時間でした。

問題解決力は全業界/全職種で活用することができる汎用的なスキルだと思います。活用することで成果が出る度合いは業界/職種によって異なるかもしれませんが、すごく重要だと個人的には思っています。そのため、社会人経験が浅い頃にこの能力を身に付けてしまえば、成長も早いのではないかなと思っています。

繰り返しになりますが、自分自身の問題解決における「手法/仕組み」を頭の中で整理することができ本当によかったです。






この記事が気に入ったらサポートをしてみませんか?