施策を失敗させるための7つのポイント
はじめに
前回の記事でPDCAをまわす際のポイントを簡単に書きましたが、書いた後に「PDCAをまわす中で多くの失敗を経験してきた＝もっとみなさんに伝えられることがあるでのは？」と思いました。
私は比較的スタートアップ歴が長く（6年ぐらい）、いろいろ好きにやらせてもらえることが多かったので業務を通してPDCAサイクルをまわす機会に恵まれていました。
それもあって「自分はPDCAをまわすことが得意だ」と思い込んで生きてきました。
ただ、「思い込んで」と書いていることからもお分かりいただけると思いますが、今となっては完全に思い込みだったと感じています。
もしかしたら多少はできていたのかもしれません。
ただ、それは挑む課題の複雑性が低い時のみできていただけで、課題の複雑性が上がるにつれて自分のPDCAスキルの圧倒的な低さを痛感するようになりました。
そして、特にこの半年ぐらいで、書籍やwebの記事を読みながらあれこれ考え、それを実践してきました。
これを読んでいただいている方はPDCAを日常的にまわされていて、特段苦手意識はないかもしれません。
ただ、私が壁にぶつかったように、今の方法で進んだ時に今までのやり方で成果が出なくなる日が訪れる可能性は0ではありません。
この記事では私がhacomonoのカスタマーサクセスとして2年弱の中で犯してきた失敗と、それを踏まえて現時点で考えている「施策を打つ際にはこういう点に注意するといいのでは？」を書いていくので、「今までのように成果が出せなくなってきたなぁ」と感じた時に読み返してもらえると嬉しいです。
失敗7選
前置きが長くなりましたが、実際に犯してきた失敗について書いていきたいと思います。
失敗① 仮説の上に仮説を重ねる
「オンボーディング中にクライアントからAに関する問い合わせが頻発する」という事象が起きていたとします。
「問い合わせが頻発する＝クライアントに迷惑をかけている」という状況なので多くの方はこれを改善するための施策を考えると思います。
望ましくない状況を解消することが目的なので「施策を打つ＝問題解決」と言えて、問題解決のプロセスは「問題の特定」と「解決策の決定」にわけられます。
なので、本来であれば問題を特定したうえで解決策を考えるべきなのですが、私は以下のように進めてしまっていました。
Aに関する問い合わせが多い→この原因はxx（だろう）→それを解消するためにはooが最適（だろう）→よっしゃ、ooを実施しよう→爆死
「だろう」の上に「だろう」を重ねる、まさに「仮説の上に仮説を重ねる」という状態です。
これは医師が「患者がxxって言ってるから胃がんっぽいな。放射線治療してみよう」という思考プロセスを経て治療方針を決めるぐらい乱暴な思考プロセスです。
原因が特定できていない中で施策を打つので施策が成功する確率は非常に低くなります。
ちなみに、この「仮説の上に仮説を重ねる」は東京大学 FoundXの馬田先生がスライドの中で詳細に説明されているので、こちらのスライドをお読みいただくことを強くオススメします！
（どうでもいいですが、hacomonoのカスタマーサクセスチームでは仮説の上に仮説が重なった状態を「仮説のミルフィーユ」と呼んでおり、常にミルフィーユになっていないかを自問するようにしています）
失敗② 施策の具体的な内容をいきなり作り込む
「クライアントからAに関する問い合わせが本稼働後に頻発する。その原因はクライアントがhacomonoを使った店舗オペレーションを本稼働前に実際に一通り体験できておらず、『わからないことがわからない』状態のまま店舗オープン日を迎えてしまうこと（Aに関する問い合わせは本来的には事前に解消できる）」というところまでは事実としてわかったとします。
そして、これに対して「本稼働前に店舗でhacomonoを使うスタッフさんが本番を想定したロープレができるといいのでは？」という解決策の仮説が浮かんだとします。
ここで「よし、スタッフさんがロープレができるようにロープレ台本をつくろう」と考えると高確率で失敗します。
「ロープレ台本を提供する」という具体的な手段がうまくいく可能性があるのは「本稼働前にスタッフさんに通しで業務を体験してもらうと習熟度が上がり、本来はオープン前に解消されるべき不明点が質問として出てくる」という前提が成立することを検証できている場合のみです。
ロープレ台本はスタッフさんの習熟度を上げるための手段なので、「習熟度が上がるとオープン前に解消されるべき不明点が質問として出てくる」という前提が検証できていないのであれば、ロープレ台本をつくった時間は高確率で無駄になります。
失敗①と②を踏まえると、施策を考える時は
課題・ニーズの特定
課題解決にあたって必要な機能（課題を解決するために対象の相手がどういうことができないといけないか。広義の意味での機能、コア部分）の特定
手段（コア部分を実際にどういう形で提供するか。狭義の意味での機能）の特定
という流れで進めるのが良いのですが、これをわかりやすく言語化することがなかなか難しいです（でも個人的にはこの失敗②が一番重要だと思っています）。
特に上記の2の部分は「広義の意味での機能」「コア部分」「ジョブ」「役割」「コンセプト」等、いくつかの表現ができそうなのですがビタっとハマるものが見つけられていないです…。
少しでもわかりやすいように例を使うと以下のような感じでしょうか。
課題・ニーズ：外出することなく、好きな時に、好きな店の料理を食べた
広義の機能・コア・ジョブ：自宅からxxkm圏内にある飲食店の料理を1品から注文できて、自宅で受け取れる
手段：Webで注文できて届けてくれるサービス、紙の出前カタログ、等
ちなみに、この考え方は「正しいものを正しくつくる」という書籍に記載されているのでお読みいただくことを強くオススメします！
※この書籍では以下のように表現しています
課題、本質
機能、ソリューション、実体
インターフェース、形態
失敗③ 仮説の検証単位を大きくしすぎる
ちょうどいい具体例がないので、ここは違った説明の仕方をさせていただきます。
「風が吹けば桶屋が儲かる」という言葉がありますが、これが「風が吹けば桶屋が儲かる説」だったとします。
この仮説を検証するために、
・風を吹かしてみる
・桶屋が儲かったかを確認する
というアプローチをとったら、仮に桶屋が儲かっていてもそれが「風が吹いたから」と判断するのは難しいですよね。
この因果関係自体が正しいかは置いておくとして、主張としては「風が吹いて砂が飛ぶ→視覚障がいの方が増える→三味線弾きを職業にする人が増える→三味線が売れる…」のようなプロセスを経て「桶屋が儲かる」に行き着くことを想定しているので、本来的にはこのプロセスが本当に連鎖しているかを確かめる必要があります。
このプロセス分解をせずに最終結果だけ見て施策（ここでは「説」）を評価してしまうと、施策がうまくいっても偶然の可能性が高く再現性を担保できないのと、施策がうまくいかなかった時も結局どこに問題があったのかを検証できないので改善が難しくなるという不都合が生じます。
また、仮説の検証単位を大きくしすぎると、
・最終的な結果が出るまでに時間がかかる
風が吹いてから桶屋が儲かるまではきっと1ヶ月以上はかかるはずです。
・100%当てはまるサンプルを探すのに時間がかる
「風が吹いたら砂が飛ぶ」「出歩く人が多い」「三味線を売っている店がある」「猫が多くいる」といった条件を全て満たす町を探すのは大変で、なかなか検証が進みにくいです（「桶が齧られると桶の買い替え需要が発生する」という仮説なら比較的簡単に検証できるかもしれません）
ということが起こり、PDCAのスピードが落ちるという不都合も発生します。（百害あって一利なし…）
失敗④ 全ての仮説を等しく扱う
施策を打つにあたっては多くの仮説（前提条件と言った方がイメージしやすいかもしれません）があり、それらを丁寧に検証しながら進めていかないと失敗する確率が高まる、とここまで記載してきました。
なので、仮説を検証していくことはもちろん重要です。
一方で、仮説（前提条件）が10個あった時にそれらを全て検証していくと時間がかかり、PDCAのスピードが落ちてしまいます。
それに、9個目の仮説までは1ヶ月かけて検証できたとして、10個目の仮説を検証した時に「違った」ってわかった時の絶望感を想像すると恐ろしくなりますよね…。
「クライアントからのAに関する質問を減らすためにサポートサイトにコンテンツを載せよう。それもテキストだとわかりにくいから動画にしよう」という施策を考えた時に「テキストより動画がクライアントにとってわかりやすい」「クライアントはサポートサイトの存在を認知している（認知していなくてもさせる方法がある）」等の前提がクリアできたとしても、「クライアントは困った時はサポートサイトを見る」という前提がクリアできなかったらそれまでの仮説検証は全て無駄になります。
実際に我々もサポートサイトのコンテンツをつくったものの、「Aに関する質問は会員さんとの会話の中で発生することが多い。そしてその会話を会員さんとスタッフさんがする際は近くにPCがなかったり、時間的猶予がなくてサポートサイトで検索していられないからサポートサイトのコンテンツを拡充しても解決につながらない」ということが後になって判明するといったことがありました。
失敗⑤ 仮説検証のためのプロトタイプの作り込みに時間をかけすぎる
「Aに関する質問を頻発させないためには、クライアントに対する事前のインプットが大事」という仮説は検証できたとします。
次は「どの形でのインプットが効果的か」を検証していく必要があり、そこで「動画を使ったインプットが効果的」という仮説を検証することに決めたとします。
検証するには当然プロトタイプがあった方がいいので動画コンテンツをつくる必要が出てくるのですが、ここで注意するべきは初期の動画コンテンツ（プロトタイプ）の過度な作り込みです。
プロトタイプを作り始めると細部までこだわりたくなってしまうのですが、細部までこだわるのは「動画が効果的」ということがわかってからやるべきです。
検証の段階では最低限のものにしておかないとプロトタイプ作成に投資した時間が無駄になる可能性が高くなります。
失敗⑥ 施策の成功の定義を定量的に表現しておかない
今まで書いてきた失敗はどれも初歩的なもので書いていて恥ずかしくなりますし、読んでいただいている方は「当たり前すぎて役にも立たない」と思っているかもしれませんが、この失敗⑥はその中でもトップクラスに当たり前なことです。
「施策Xを打つことでAという指標が5ポイント改善される（それ未満なら継続しない）」
文字にするとより一層当たり前感が強くなるのですが、実施している施策全てに対してこのフォーマットで答えられる方は意外と少ないのではないかと思っています。
「施策Xを打つことで今抱えているBという問題がいい感じになる」
ぐらいになっていることがわりとありませんか？
当たり前のことしか書いていないのですが、定量化できないものは正しく評価することが難しく、評価することが難しいということは継続することも改善することもできないという状態を引き起こします。
（うまくいっているかどうかわからないゾンビのような施策が多くある場合は要注意です）
失敗⑦ 全体の流れの中で検証せず、部分の成功で満足する
「Aという問題は、本番稼働前に時間がなさすぎてクライアントが十分に準備ができないことによって起こる」という事実があったとします。
これに対して「オンボーディング中のxxの作業をhacomonoが代行することでクライアントの時間を創出し、事前に準備をできるようにする」という施策を考えたとします。
そして、実際にこの施策を試したところクライアントの時間が創出され、本番稼働前に準備もできるようになり、Aという問題は解消されました。
ここまでだと「めでたしめでたし」です。
ただ、以下のような続きがあったとしたらどうでしょうか？
「オンボーディング中のxxの作業を代行したことでクライアントのシステムに対する理解度が大幅に低下し、B、C、Dといった問題が新たに起こるようになった」
よろしくないですよね…。
このように、施策を打ったことで当初の問題は解決されたものの、その施策によって別の問題が発生するということもあります。
そうならないために施策を前後の文脈と切り離して検証・評価するのではなく、文脈の中に入れ込んで検証するべきなのですが、施策の検証が狙い通りに行くと浮かれてしまうのでこのステップを忘れてしまいがちです。
失敗を踏まえた施策立案のステップ
ここからは「じゃあどうしたらいいの？」というみなさんの疑問に対して、現時点で私が考えていることを書かせていただきます。
※現時点での考えなので今後変わる可能性は大いにあります
基本的には失敗7選の裏返しになるのでここまでお読みいただけていたらもう80%ぐらいはお伝えできているのですが、少し補足しながら書いていきたいと思います。
ステップ① 問題の原因を特定してから解決策を考える
これはさっきの医師の診察の例で言うと、ちゃんと内視鏡検査とかして症状の原因が「胃がん」であることを確定させてから治療方法を考えるということです。
ちなみに、私が好きな問題解決のアプローチは
理想と現実を比較して、ギャップ（＝問題）を把握する（What）
問題がどこで起きているかを特定する（Where）
問題がなぜ起きているかの原因を特定する（Why）
解決する方法を考える（How）
という大まかな流れです。
（個人的に問題解決はこの書籍を一冊読めばOKだと思っています）
ステップ② 施策の具体的な内容を固める前にコア部分を検証する
問題を特定できたらここからいよいよ施策を考え始めます。
ただ、ここでいきなり具体的な内容まで作り込む前と失敗するので、施策のコア部分の仮説検証を行います。
先述の「ロープレ台本をつくって渡す」は「本稼働前にスタッフさんに通しで業務を体験してもらうと習熟度が上がり、本来はオープン前に解消されるべき不明点が質問として出てくる」というコア部分の仮説（前提）が正しくないと成立しないので、まずその前提が正しいかを最初に検証するようにします（手段はどうあれ、習熟度を上げて、不明点が質問として出てくるかを検証する）。
具体に手をつけるのはコアを検証してからです。
手を動かしていると仕事をしている感じがしますし、形（アウトプット）ができてくると前に進んでいる感も出るのでついすぐに作業に取り掛かりたくなるのですが、グッと堪えます。
これを踏まえるとステップ①で記載していた問題解決アプローチは以下のように発展させられそうです。
理想と現実を比較して、ギャップ（＝問題）を把握する（What）
問題がどこで起きているかを特定する（Where）
問題がなぜ起きているかの原因を特定する（Why）
課題解決にあたって必要な機能（広義）・コア部分を特定する（広義のHow）
その機能をどういう形で提供するのがベストかを特定する（狭義のHow）
ステップ③ コア部分を分解して検証する
コア部分を検証する際は、「風が吹けば桶屋が儲かる」の例で言うと「風が吹いた時に桶屋が儲かったか」のように最終結果をいきなり確認するのではなく、「風が吹いたら砂が飛んだか？」「砂が飛ぶと失明する人が増えるのか？」のようにプロセスを分解して検証していきます。
上記のhacomonoの例で言うと、「一通り業務を体験してもらうと習熟度は上がるのか？」「習熟度が上がると不明点が事前に質問として出てくるのか？」に分解します。
プロセスを分解することで、
・最後まで待つ必要がない
・全ての条件を満たすサンプルでなくても部分的に試せる
ということも起こり、PDCAを早くまわすことも可能になります。
ステップ④ コア部分の検証は特に重要な仮説から行う
コア部分に関する仮説が成立するには大抵いくつかの前提条件があります。
リソースの関係でそれら全てを検証することが難しい場合もありますが、とは言っても検証しないのも失敗のリスクを高めるだけです。
そこでオススメするのが、「結果へのインパクトが大きい」「現時点で確からしさが低い（わからない）」の2つに該当する仮説（前提）から検証することです。（簡単に言うと後で分かった時に「それ早く言ってよ〜」となる要素から検証するということ）
さっきのhacomonoの例で言うと「習熟度が上がると不明点は質問として出てくる」という前提が崩れると仮説は一発アウトなので、そこから検証する必要があります。
こちらに関しては既に前半にリンク貼っていますが、馬田先生のスライドが大変参考になるので是非お読みください！
ステップ⑤ 仮説の検証はコストがかからない方法で実施する
検証するべき仮説がはっきりしたということは大きな進歩です。
一気に道筋が見えてきた感があります。
次に気を付けるべきは、その仮説の検証をするためにリソースを使いすぎるということです。
コア部分の仮説を検証するのに3ヶ月ぐらいかかるとなると、仮にその仮説が正しいことが検証できたとしても、その後にそれを具体的な形に落とし込んでさらにそれを検証するといった後工程が控えているので施策を正式に展開できるのはそこからさらに1-2ヶ月後、つまりコア部分の仮説の検証を開始してから4-5ヶ月後になります。
スタートアップにとっての4-5ヶ月というのはかなり重みのある期間です。
かつ、スタートアップは環境の変化が激しいので「4-5ヶ月経ったら前提条件が変わって、コア部分の仮説が正しいと言えなくなった」ということも起きます。
こういったことを防ぐためにも、コストをかけずに仮説を検証する方法を考えることが重要になり、ポイントは2つあると思っています。
①大事な仮説に絞って検証する
ステップ④と同一です。
あれこれ検証しようとするとMVPがMVPでなくなっていくので「結果へのインパクトが大きい」「確からしさが低い」の両方を満たす仮説に絞って検証していきます。
結果へのインパクトが小さいもの、確からしさが高いもの、あとは「後からでも挽回可能なこと」は優先順位を下げて問題ないと考えています。
②ユーザー視点を重要視する
例えば、「ジムにwebで入会した際、入会完了と同時に身長体重、ジムに通う目的に応じてオススメのトレーニングをリコメンドすると入会直後の2週間の来店頻度が1.5倍に増える」という仮説があったとします（中身は適当です）。
この仮説を検証するために実際にこの機能を開発するのはリソースが膨大にかかります。
ですが、「スタッフが手動でオススメのトレーニングをLINEで送る」であればすぐにでも検証可能ですし、コストもほぼかかりません。
このような形で、裏側の運用（ユーザーから見えいない部分）にはこだわらず、ユーザー体験の同一性に重きを置くとコストをかけずに検証できるようになります。
上記の手法については、この書籍で「プレトタイピング」として紹介されています。
ステップ⑥ 施策の成功の定義を定量化する
一番基本的ですが、一番忘れがちなステップです（少なくとも私は一番忘れがちです）。
「どの指標が」「どの水準になったら」成功と言えるかを事前に定義しておきましょう。
これをしておくことでPDCAのCheckが圧倒的にやりやすくなります。
ただ、計画時にどれだけ厳密に定量化するべきかはやることによって少し変わると思っているので、その点はこちらの過去記事をお読みいただけると幸いです。
ステップ⑦ 細部を磨き込む前に全体の中に入れて検証する
コストがかからない方法で仮説の検証を行い、狙い通りの結果が出たからと言って施策の細部を磨き込む、正式に展開するのはまだ早いです。
「施策Xを実施したことで当初の問題Aは解消されたが、そのかわり問題B、C、Dが新たに発生した」となってしまっては施策Xは継続する意味がないので、磨き込むのに使った時間も無駄になってしまいます。
そうならないために、施策X単体の検証ができた後は一連の業務プロセスに組み込んでも不整合が起きないかを検証することをオススメします。
ここで不整合が起きなかったらようやく施策を細部まで磨き込み、正式に展開していきます。
補足 失敗に対する向き合い方
上記7ステップは比較的テクニカルな要素が多いのですが、これらが機能するうえで重要な要素があると思っています。
それは
「失敗は悪ではなく、成長の材料」として捉えるマインドセット
です。
いくら考え抜いたとしても一発で成果が出るなんてことはあり得ません。
今回書いたステップを踏むことで成功確率を上げることはできますが、それでも必ず失敗はします。
むしろ、上記ステップは失敗をしながら成功に近づいていく方法なので、失敗を認められないと何も始まりません。
だからこそ、失敗を恐れるのではなく、成長の材料として歓迎しましょう。
個々人がこの考え方を持てていると、チームにもいい影響が出てきます。
全員が失敗を歓迎していればチームの中で失敗事例がどんどん集まり、そこから学ぶことでチームの力がついてくるからです。
また、お互いに指摘し合うことで致命的な失敗を事前に防ぐことも可能になります。
この「失敗を歓迎できる組織文化」をつくっていくには、個々人が上記のようなマインドセットを持ち、実際に何かがうまくいかなかった時に人を責めるのではなく、「どういう構造が失敗を引き起こしたのか」のように原因を構造に求めることも重要だと思っています（失敗した時に誰かが責められるのをみていると他の人は失敗を共有したくなくなるので）。
2年弱、多くの失敗を積み上げてきましたが、唯一「これはできてたかも」と言えることがあるとしたら、それは「失敗をすぐに認められた」かなと思っていたりします。
最後に
いろいろ書いてきましたが、上記は現時点での私の仮説です。
なので、上記について「やってみたらこうだった」「自分はこう思う」「この書籍・記事がオススメ」「xxのところについてもう少し聞いてみたい」等ありましたらお話しさせていただきたいので、TwitterのDMでご連絡ください。
参考文献
記事内でも一部リンクを入れていますが、以下の3冊＆1スライドは本当に素晴らしい内容なので強くオススメします…！
本当に最後に（恒例の…）
今回書いた内容はhacomonoのカスタマーサクセスチーム全員の日々の取り組みの賜物です！
失敗を悪ではなく成長材料として捉え、挑戦と失敗を繰り返しながら学び、どんどんパワーアップしている組織なので少しでもご興味もっていただけましたら、ぜひ以下からカジュアル面談にお申し込みいただけると泣いて喜びます！
※カスタマーサクセス以外も絶賛採用中です！
この記事が気に入ったらサポートをしてみませんか？