Webドクターコラム
> > Web運用におけるPDCAの「C(検証)」のコツ
Webドクターコラム
マーケティング

Web運用におけるPDCAの「C(検証)」のコツ

※気合や勢いも必要ですが、WEB運用におけるPDCAの検証に必要なことは負けた場合の事も予想しておくことです。

 

皆様こんにちは。Web運用担当の中西と申します。

Web運用において、よくPDCAの「 P(計画)と D(実行)はできるけど、C(検証)と A(改善)がおろそかになる」

という話をきくので、ここでは私なりの C(検証)に対する考え方をまとめてみます。小難しい話で恐縮ですがお付き合いいただけると幸いです。

 

そもそもP(計画)を立てる前から検証は始まっている

PDCAですので、P⇒Dの後、結果がどうであったかを検証するのが「C」なわけですが、そもそも「D」の後に考えていては遅いというのが私の持論です。

なぜなら、思うような結果がでなかったら「またダメだった!別の手段を考えよう!」と紋切り型で考えてしまうケースのような感覚に陥りやすいからでしょうか。

とにかく後で考えるパターンはいけません。喜ぶか落ち込むかしかありません。まさに「一喜一憂」。

個人的な経験としては、検証フェーズのことをあまり考慮されていなかったが故に、PDCAにならずに「PDの連発」になったことがあります。

 

 

数字をみて一喜一憂するのは検証じゃない!

前提として、Webサイトに何らかの運用目的があり、その課題を解決するための手段をP(計画)するケースがほとんどかと思います。

計画を立てることは仮説を立てることに等しいです。その仮説を立てる前にまず、「ここがダメじゃないのか」と課題を洗い出すと思います。

計画はその課題にしたがって仮説を立てていくわけですが、ここでかなり重要な考え方があります。

 

「その計画は、いったい何の検証するものなのか」を考える。

 

これです。

この考えを明確にもった上で仮説を立てなければ、検証への道筋が断たれてしまいます。

なぜなら、PDCAはサイクルであり、あたかも先頭に思えるP(計画)はA(検証結果)に対してのPであるからです。

(上手く表現できませんね…)

つまり前工程と後工程をしっかり押さえるという感覚です。

 

もちろん、課題への対策というのはKPIに対するアプローチが大半だと思いますので

「KPIに対して検証すべき数値がどう変化したか」を検証するのは同じなのですが、

その数値変化だけ見て一喜一憂するだけですと、PDCAもそこで終わってしまいます。

 

検証で見るべきはP⇒Dが正しく機能したかどうか

一喜一憂で終わらないためには「原因の仮説」を検証しようという考え方に頭を切り替えましょう。

「成果が出たか?」の検証も重要ですが何より「原因の仮説が正しかったのか?」を検証することこそC(検証)だと考えています。

 

そもそも、課題への対策を考えるときに「原因」を考えていると思います。

例えば

「キーワード広告からの直帰率が自然検索からの直帰率に比べて高い」

となったとき、どれだけの原因が思い浮かびましたか?おそらくWeb運用に慣れた方ならだれでも1つ以上原因が浮かんできたと思います。

 

例えばですが、

①キーワードの選定を間違えている可能性が高いのでキーワードを変更する

②もし変化がない場合広告文とLPにギャップがある可能性も考慮する

③広告文を変えて変化がなければキーワードを戻してみる

④それでも変化がない場合、広告の設定を再度見直してみる・・・

 

という仮説を考えたとしましょう。

単純に、この原因を全てを潰すようなD(実行)でもし直帰率が低下しなければ、

 

仮説の洗い出しが漏れていた

D(実行)が間違っている

 

という事になります。シンプルですね。

 

このように計画(Plan)の段階で原因へのアプローチを明確にしておき、対策(Do)を行ったうえで、上記を検証(Check)することがPDCAの「C」という考え方をしておけば

 検証ができない!なんていうことにならずに済みます。

 

まとめ

P(計画)の段階でC(検証)は始まっています。

課題に対する原因とその対策を洗い出し、

その対策で原因を潰せたのかどうか、原因が漏れていないのかを検証しましょう。

 

最後までお付き合いいただきありがとうございます。

PDCAの「A」のコツに関してもまた今度書こうと思います。