上司に目標を与えられた！その後どうする？
ウェブサイトを運営しているあなたは、上司から「資料請求数を1年後に前年比110%まで成長させて欲しい」と目標を与えられました。
あなたならどうしますか？
今回は、そんな時に考えるべき一連の流れをまとめてみました。
まずは、前回の記事「目標設定の重要性について」で書いたように、与えられた「目標」を意識しましょう。
それを踏まえた上で、次に何をするか？
以下に、大まかな流れをまとめました。
C.現状分析／課題発見
P.企画立案
D.実装／リリース
C.効果検証／課題発見
A.次の企画立案（以後、DCAを繰り返し）
皆さんご存知のPDCAサイクルです。そんなに難しい話ではありません。
PDCAサイクルを理解することは難しいものではありませんが、PDCAと名前があるからか、いきなり「Plan」から入って実装フェイズに入ってしまうことがあるように感じています。明らかに不具合が生じているバグであれば、課題が明らかになっているためよいのですが、個人的には「Check」から入る方がよいと考えています。
それは、イシュー（解決すべき課題）を意識して、企画を考えることができるからです。
この工程を省くと、目標との結びつきが弱くなってしまい、思いついたアイディアをやることが目標になりがちです。その場合、行動したことに満足してしまい終わってしまいます。
そういった理由から、私は最初に「Check」を行うことをオススメします。
自社サイトの現状を分析（Check）するための方法として、次のようなものがあります。
このブログでは、私自身が最も得意としている「アクセスログ解析」を中心に取り上げていきます。
他の2つは両手両足で数えられる程度の経験しかないため、圧倒的に知見が少なく経験してきたことをお話することはできますが、薄っぺらい内容になりそうなので。。。
ということで、アクセスログ解析で課題を洗い出しましょう（具体的な方法は後日）。それも、一つではなく、できるだけたくさん。何故、一つだけではダメかというと、見つけた課題から場当たり的に対処していたのでは、限られた時間の中で最大の成果を得られないからです。
何故なら、サイトには無数の課題が眠っているからです。
限られた時間の中で最大の成果を発揮するためには、それらを可能な限り洗い出し、その中から最も重大な課題（改善できれば効果を見込める）を見極めることです。ちなみに、すべての課題を洗い出すことは無理だと割り切りましょう。よって、分析に掛ける時間をあらかじめ決めておき、そこで発見した課題のなかから選択します。
そして、企画を立案します。ここでもいきなり企画するのではなく、「何故、課題が発生しているのか？」その真因を考え、仮説を立てることに、課題発見〜企画立案の醍醐味があると思っています。そこで考えた仮説が具体的であれば打ち手も明確になりますし、リリース後に何を検証すべきかもわかるためPDCAをうまく回せます。
よくあるダメな例が、モノをつくってから効果検証するための方法を考えることです。事前に設計していなかったがために、取るべき数字が取れなくて結果が良かったのか、悪かったのかがわからないということに陥ったりします。これではPDCAが回せませんね。
そして、企画を練り上げたら効果見込みを出すことです。今回与えられている目標は1年間で前年比110%まで成長させることです。仮に、その企画を実現することで110%上がる見込みが出たとしても、1年間掛かるプロジェクトの場合、一発勝負になります。
事業はギャンブルであってはいけません。未来は予測できないからこそ、いかに成功確率を高めておくかが重要です。よって、打率を設定しておくことが大事です。個人的な経験則からいくと、1〜3割くらいで置いておくのが、無難な気がしています（当然、能力に左右されると思いますが）。
企画ができたら、「解決したい課題」を実装するデザイナーやコーダー、エンジニアに共有します。ここで重要なのは、「解決したい課題」を共有することです。
決して、これを省いて企画内容だけを伝えてはいけません。最終成果イメージだけを伝えると「何にためにつくっているのか」が伝わらないためクリエイターからのアイディアを引き出すことができませんし、間違った解釈をされてしまう可能性も高まります。
あとは、作業を暖かく見守ります（冗談です。当然、プロジェクトマネジメントは必要ですが、このエントリーでは割愛）。
無事にリリースされて、データが溜まったところで効果検証をします。企画時点で設計しているため、あとは集計作業をするだけです。そのデータから結果がわかります。
ただ、「数値が上がってよかった、数値が下がって残念」で終わってはいけません。何故、そのような結果（上がったのか、下がったのか、変わらなかったのか）になったのかを検証します。検証結果は全部で4パターンに分類され、その後のActionが変わってきます。
①仮説が当たって、効果も出た場合
これは、企画冥利に尽きるパターンです。祝杯をあげましょうw
更に突き詰めて改善をしていくか、別のプロジェクトに進むかを検討しましょう。
②仮説が外れて、効果は出た場合
結果が出たのでよしとしましょう。ただし、今後のプロジェクトのためにも、何故そうなったのかを検証しておくことで、次回以降のプロジェクトの仮説精度が高まります。
③仮説が当たって、効果は出なかった場合
④仮説が外れて、効果も出なかった場合
どちらも同じ失敗パターンですが、この二つを見分けることが非常に難しいことが悩ましいです。
ちなみに、③の効果が上がらなかった原因は、以前の記事「ユーザーエクスペリエンスを意識したサイト改善」で書いた、5つのSのいずれかに問題があったと集約できると思っています。
- Strategy（戦略）
- Scope（要件）
- Structure（構造）
- Skelton（骨格）
- Surface（表層）
上に行くほど、そもそもの部分になってきます。
このケースに該当した際の明確な答えは、私の中にもありません。
仮説を信じて突き進むか、仮説を疑い引き返すかは担当者のセンスによる部分かなと思っています。
ということで、今回も具体的な話がないまま終わってしまいましたが、果たして誰かの役に立っているのか不安ですが、自分の脳内整理には役立っているためよしとしよう。
※[写真] Official U.S. Navy Imageryの作品を利用
