普段は都内のEdtech系ベンチャー企業でWebディレクターなどをしています。学生時代1年間インターンをし、そのまま新卒入社、現在社会人3年目です。これまでWebサービスに関わる、大小様々な企画やディレクション案件に関わってきました。
スタートアップなので社内にノウハウがなかったり、そもそも専任のディレクターポジョンの人もいないような状況で、失敗を繰り返しながら手探りでここまでやってきました。
企画の立案方法や進め方ってなかなか身につけるのが大変だったり、「KPIを○○%上げるように改善して」などいきなり任されて何をどうしたらいいのか分からない…そんな方も多いのかなと思います。
そこで今回は個人、会社員問わず、Webサービスやアプリの企画やディレクションに関わる方に向けて、企画の考え方、特に何かを改善する場合の企画立案ステップや進め方のコツをまとめていこうと思います。
完全に僕個人の進め方かつ試行錯誤中であるので、もっとよい方法もきっとあると思いますが、ひとまず自分なりの考えを備忘録としてまとめてみます。
サービス改善企画における7つの立案ステップと考え方
まずは改善する案を出すまでのステップを、7つに分けてご紹介します。
企画の考え方(1) 改善する目的と目標値を再整理する
まずいきなり施策を考え始めるのは止めましょう。今回改善する目的・意図は何か、また数値として何をどれくらい改善するのかを具体的に定めいったん整理します。
そこの軸がブレていると、これから考える打ち手も全てブレてしまう上に、企画の振り返りの際に良し悪しが判断できなくなり、もし失敗し撤退する場合の基準なども曖昧になってしまいます。目的を改めて再整理し、社内やチームでの認識を揃えておくべきでしょう。
またこれは根性論とかになってしまうのですが、「絶対にこのKPIを達成する」という強い意思がなければ、なかなか良い施策は出ない気がします。企画者の本気度や熱意は企画の成功に大きく直結するので、その点でもここで改めて目的を自分なりに定めることは重要かなと思います。
企画の考え方(2) 現状分析：課題点の仮説を立てる
次に現状の数値を達成できていない課題点、その理由の仮説をいったん自分なりに考えてみます。ペルソナとなるユーザーはどんなことに困っていたり詰まったりしているのか、何が行動の阻害要因になっているのか。
課題点をいったん全て洗い出し整理、それが本当に課題なのか、突き詰めて考えてみるべしです。ここでの仮説の精度が荒ければ、その分解決策の精度が下がり、つまり企画の不成功に繋がります。
仮説の精度はかなり重要で、出来る限り小手先ではなく、本質的な課題にアプローチすべきです。表面上の課題をいくら解決しても、結局大きく課題を解決することはできず、また違う問題が表面化するだけです。課題のボトルネックになっている、真の課題を捉えるべきです。
企画の考え方(3) 現状分析：データを見る、有識者＆ユーザーにヒアリング
ここでようやく過去のデータや数値を見ます。課題として置いた要素が、本当に課題になっているのか客観的な指標から判断します。上記で出した課題は、どんな数値を見ればそれが課題だと証明できるのか？その当てをつけながら数値を深掘りしていきましょう。
施策を出す時にいきなり数値を見るのは止めておくべきです。もちろん数値を見て新たな課題に気付くことも多いので、ケースバイケースな部分もあるのですが、数字の海に溺れて収拾がつかなくなったり、本質的な課題を掴み取りづらくなる場合があります。個人的にはまず課題の仮説を立てた上でデータを見る方が良いかなと思います。
仮説を裏付ける数値が出ないのであれば、その仮説は間違っているのかもしれません。いったん課題をもう一度考え直すというのも手です。また数値化できない領域であれば、社内のナレッジがある人（ユーザーと直接関わる人や業界知識がある人など）に意見を聴くのもよいです。
またプロジェクトに時間や予算的余裕があるのであれば、社外の有識者やユーザーにもヒアリングした方が課題の精度が上がります。特に重要なKPIに直結するような企画の場合は、数人でもユーザーへのヒアリングはしておくべきでしょう。
企画の考え方(4) TO BE（理想の状態）を定義する
(2)のステップでまとめた課題に対し、もっともベスト・理想的な状態を描きます。その課題が解決された状態は、つまりどのような状態なのか、言語化し定義しましょう。
また同時になぜそれが理想の状態であるのか、どのようなメリットがあるのか、ユーザー視点で整理します。理想の状態の候補が複数ある場合は、どちらの選択肢がユーザーにとってベストか、再度課題の本質に立ち返り考えてみましょう。
企画の考え方(5) 施策の洗い出し
下準備が整ってきたところで、いよいよ具体的な施策を考えていきます。
現状課題がある状態を、いかにして解決するのか、どのような施策が打てるか、全て洗い出します。その際は先ほど考えた理想の状態・あるべき状態にどう近づけるか、ということを念頭に置きましょう。理想から逆算し、現実とのギャップを埋める工程ですね。
この段階で競合サービスや提供しているUXが類似する別業界での他社サービスなども色々見てみて、施策として取り込めそうな機能やデザインの参考にしましょう。また改修する機能を軸に（検索機能、一覧ページなど）、色々なサービスを横串で見ると施策アイディアのヒントになることもあります。同じような課題を抱えたサービスがどのようにそれを解決したのか、その背景がちらっと垣間見えたり。
施策のアウトプットの質と量は日々のインプットに比例するので、常日頃いろいろなサービスをウォッチしておきましょう。
企画の考え方(6) 施策の優先度を精査
施策を洗い出したら、複数の項目別（コンテンツ、UIなどの大カテゴリ、またPC・SPなどデバイス別、ページや機能別など）にグルーピングするなど、整理整頓・精査していきます。
恐らく1つの課題に対して複数の解決策が出ることが通常だと思いますので、実行する優先度も決めましょう。KPIへのインパクト（課題解決度）、工数（開発が関わる場合は開発・デザイン工数をざっくり見積もってもらう）、実行コストなど複数の軸で精査します。
できればKPIへのインパクトが大きく、工数が最小の施策から実行するのが常套手段です。手間がかかるものはいったん後で回しでOKですが、時としてコスパのいいものは本質的な解決策でない場合も多く、ある程度そのサービスに携わった上での知見や経験則で判断する必要があります。
また個人的にはコストがかかってでも、本質的な打ち手をいかにしっかりやり切るかだとは思います。しかし資金的に余裕のある大企業ではなくスタートアップや中小企業などの場合、まずはいったん目先の数字を上げてから、本質的なことをやるなど、事業や企業の状況を見ての判断が必要なケースも多々あるかなとは思います。
企画の考え方(7) おおよその実行スケジュールを切る
施策の整理と優先順位付けが完了したら、全体のスケジュールを設計します。
個々の施策別に、企画、デザイン、開発の工数を見積もり、デバックや調整踏まえたバッファー期間を含め、いつまでにリリースするのか定めていきます。まだそれぞれの担当者も定めて置きましょう。
複数の施策が同時平行する場合は、いつもスプレッドシートでガントチャートをつくり進行管理していますね。
企画・施策の進行ディレクションで心がけておきたいこと
ここでは僕の過去の教訓を踏まえ、企画を実行・ディレクションしていく上で心がけておきたいことをさくっとまとめました。何か参考になれば幸いです。
企画進行のコツ(1) CVに直結するページの改修は最大限に慎重をきすべき
CVつまり売上に直結する重大なページや機能を改善していく場合は、最大限慎重に企画の実行を進めましょう。
大変でも抜本的な施策を打たなければ、大きく数値を改善することは難しい場合もあります。しかし大きく改修する場合は、逆に大きくマイナスにも左右する可能性もあります。スタートアップなどの場合、CVRが少し変動しただけで大ゴケする場合も。
どんなに考え抜いた自信のある企画でも、フタを空けてみたら想像と大きく乖離する可能性もあります。実際にリリースするまで分からないことも多々あるのです。
構想は大胆に、しかし実行は慎重に移しましょう。
企画進行のコツ(2) 改修は必ずリーンに実行すべき
基本的に既存のサービスを改善する場合は、施策を更に細かく分割して、ステップごとにリリースしていくべきです。
その方が開発工数を抑えることができるケースも多く、小刻みにリリースすることで早い段階でユーザーの反応を確かめながら企画を進めていくことができます。もしKPIや予想していなかった部分でマイナスに左右する場合、その時点で企画を再考することも可能で、リスクを最小限に抑えることができます。
例えばPC版で反応が良ければスマートフォン版で、一部のページで反応が良ければ別のページにも施策を適応する、まずはデザインを改修してから機能改修をするなど。
改善を焦り一気に大きく改修するような企画はせず、必ずステップを刻み、ユーザーの反応を見ながら実行すべきです。
特に先ほど紹介したCVに直結するページの改修は、必ずリーンに実行すべし！（経験者は語る……）
企画進行のコツ(3) 企画進行では関係者をかならず巻き込む
企画を進める際は、社内メンバーの巻き込み方も工夫すべしです。必要であれば個別に、またはミーティングを開き、企画、デザイン、ステージングとリリースまでのそれぞれの段階で小刻みに進捗を共有し、さまざまな意見を聞き、ブラッシュアップをより重ねるべきです。
特にKPIへの寄与が大きい企画は、かならずCS（カスタマーサポート）のメンバーなど、ユーザー知見のある社内メンバーにまずは意見を聞いてみましょう。
またその改修するページや機能変更の影響を受ける関係者や部署の意見も事前に聞いておくと、企画のブラッシュアップはもちろん、改修に伴う混乱を最小限に抑えることも可能です。
企画者・ディレクターは独りよがりにならず、いろいろな人と積極的に関わるスタンスをまずは持つべきです。
企画進行のコツ(4) 有識者やユーザーへのヒアリングも
大規模な機能改修やCVに直結するページ改修の際は、社内メンバーだけでなく、できれば外部の有識者やユーザーへのヒアリングも実施すべき。
当初想定していた仮説と、ユーザーのニーズにすれ違いが生じる可能性を少しでも減らすために、ユーザーへのヒアリングをしていくと良いです（プロジェクトに当てられた時間や予算にもよりますが）。
また外部の知見ある有識者や、自社サービスより一歩先を行くサービスの運営者（別業界で……！）の意見も聞く機会を設け、企画のブラッシュアップをしましょう。
企画進行のコツ(5) 企画段階で細部の仕様を詰めるべし
企画する際は、大きな改修の方向性などに目を奪われがちですが、企画の細部についても必ず事前に考え抜き、デザイナーやエンジニアとすり合わせをしておきましょう。
例えば以下のような項目です。
・表示するコンテンツ
（文字数のmax値とmin値でのデザイン検証、コンテンツがない場合の表示）
・データ周り
（データベースの仕様上、そのデータを引っ張れるのか、加工できるのかなど）
・メタタグやディレクトリの切り方
・対象箇所を改修したことによる、別の機能やページへの影響
・KPIの計測方法（GAのイベントやパラメータ、DBでの計測かなど）
etc……
開発している段階や、リリース直前のタイミングで、この仕様だと実現できないなどなると、関係者がみんな不幸なことになります。またデザインや仕様を途中で調整しまくると、デザイナーや開発陣にも不満が溜まり、チーム全体のモチベーションが低下してしまうことも。
事前に全ての要素を企画段階でヌケモレなく考え抜くのは、知見と経験がものをいうので難しいとことですが、出来る限りここもしっかり考え抜いておくべきです。
企画進行のコツ(6) 振り返るタイミング、撤退基準を持つ
時に施策で想定通りの数値にいかない、もしくは大きく下回る場合もあります。冷静に状況を分析・把握し、企画や開発の工数に関わらず差し戻すという選択肢も常に持つべきです。
そのためにも事前に施策を振り返るタイミングや、撤退する基準、また撤退した後別の企画を追加で打つ場合はその進め方も事前に考え、関係者と意思共有しておくと色々とスムーズに物事が進みます。
引くことも選択肢の1つとして、手札に持っておきましょう。
企画は一筋縄ではいかない…
ここまでWebサービスやアプリの改善施策を企画する際に、抑えておくべき立案ステップや、企画を進行する際の心構えを、個人の見解を交えてまとめてみました。
企画と一言で言っても考える領域はかなり広い上に、企画する対象や、企画者によっても方法は異なるでしょう。なかなか方法論を確立するのは難しいところです。ですがベースとなる要素などはだいたい同じような気もします。
よりよい企画・ディレクション方法について日々経験を重ねながら試行錯誤しているので、また随時ブラッシュアップしていければと思っています。
最後までお読みいただきありがとうございました。
UXを踏まえた企画やユーザーインタビューについては、下記記事も参考にしてみてください↓↓
