施策のアイデア出しから意思決定までの流れ

多くのWebサービスや会社が存在していて、サービス毎に様々な大なり小なり施策が毎日リリースされていますが、その施策ってどのように決められて実行まで至っているのかってことを解説しようかなと思います。

あくまで僕の担当領域のCGM領域でのやり方、インハウスでエンジニアがいるということが前提ですので、参考程度で読んでもらえると嬉しいです。

アイデアの集め方

まずは実行する施策や改修をするという意思決定するにも、当然そこに上がってくるアイデアが必要です。
アイデアというとなにか目新しくて面白い新規の案を考えなければいけないような感じがしますが、提案やちょっとしたリニューアルも含めてアイデアとここでは定義します。
そうすると、アイデアが生まれる瞬間って主に以下のケースに分類できます。

・個人でのひらめき
・分析過程において思いつくアイデア
・ユーザーアンケートやCSから思いつくアイデア
・チーム内の定例(ブレスト含)で生まれるアイデア
・第三者の提案から生まれるアイデア(上層部からの提案や指示だとこの時点で優先度は高くなりますね)
・他社からパクる、参考にする

など

上記以外のケースもあると思いますが、上げていくと様々なアプローチがありますね。
日々、アサインしているサービスの数値分析、定例会、競合調査などを実施したり、グロースさせる意識を持っているのであれば、意外とアイデアはすぐ出てくると思います。

重要なのは思いついたアイデアをすぐに残すことです。意外と思いついたアイデアって数日経つと忘れてしまいますので、これを徹底すれば結構な数のアイデアが出てくるはずです。

それともう一点重要なことがチームメンバー全員がアイデアを出すこと。
アイデアはとにかく数が大事です。
最終的の実行判断や進行を行うのはプロデューサー側に託されることが多いですが、アイデアレベルではエンジニア、デザイナー含めチームメンバー全員が出しあうことで数も集まるし、様々な視点のアイデアも集まります。

そして、「思いついたアイデアをすぐに残すこと」「チームメンバー全員がアイデアを出すこと」を常時できるようにするためには、下記実践するといいと思います。

１）思いついたアイデアの発信専用のシートまたはチャットルームを作成して、アイデアがあればそこに記載する(うちではSlackでアイデア専用のチャンネルを作成してます)
２）上がったアイデアを管理するシートを作成して、プロデューサーで定常的に更新する

ざっくりまとめると、アイデア部屋で集まった内容をサービス責任者・リーダーが集約して一覧化するといった手法です。
うちで使っている２）のアイデアシートは下記のようなものです。（具体案や名前は隠してますのはご了承を。）

実はこれ施策管理シートも兼ねてますので、アイデアベースでなく別のアプローチから生まれた施策も、全部記入してます。(↑の画像だと黒くなっている列はやめたアイデアです)
通常の施策管理シートはやることだけを入れますが、アイデアレベルで結局やらなかった施策案も一覧化すると、振り返りにも使えるし、過去に出たアイデアや保留中案件も追えるので僕は一緒にすることをお勧めします。

もし、チームメンバー全員の意識やレベルが高いようであれば、上述の１）思いついたアイデアの発信専用のシートまたはチャットルームを作成して、アイデアがあればそこに記載する←ここはいらないかもしれませんが、優先度や判断がつかなかったり、ちゃんと書かないといけないという意識から数が減ったりするので、リーダーが集約するのがいいと思います。

意思決定(実施する施策を決める)方法

施策案が集まったら実施化するものを絞っていく必要があります。ここからはプロデューサー側がより中心となって動くフェーズです。

１）まずは集まった施策案に対して優先度(高・中・小)をつけていきます。場合によっては超高の優先度もあっていいかもしれません。優先度を付ける際のポイントは以下のとおりかと思います。

・KPI、KGIの向上につながりやすい施策
・期限のある施策(またはいつかは必ずやらなくてはいけないと思える施策)
・サービスコンセプトや方向性にマッチしている

一つポイントなのは、エンジニアのリソース都合で優先度をつけないことです。「リソース的に無理そうだから後回し」というのは社内の都合で、ここでつける優先度はサービス数値とユーザーを見て、サービスグロースにとっての良し悪しで判断する必要があります。
リソース都合で調整をするのはその後の段階でいいですし、エンジニアに確認したら意外とリソースがかからないケースもあります。

２）優先度「高」の施策案のざっくり工数をエンジニアに見積ります。「高」の数が少なかったら「中」も含めてもいいかもしれません。

なお、エンジニアに確認するからといって、この段階で仕様書やフレームまで書く必要はありません。代理店や外注企業であればあるかもしれませんが、事業会社で案レベルで詳細を作りこむ程もったいないことはないです。あくまでざっくり工数で良いので、概要レベルで見積ってもらいます。

３）ざっくり工数がわかったら、実施する施策を制定します。
ここからは社内のエンジニア体制や人数で変わってくるかなと思いますが、基本的には「優先度が高くて工数が少ない」ものから施策化していきます。

やると決まったらエンジニアさんよろしくとはならず、、基本的には簡易や仕様書や指示書を作って依頼します。
さっきも少し触れましたが、事業会社での施策はスピードが大事です。なので、簡易な仕様書や指示書で依頼してあまり作りこみすぎないようにしてください。(極端な話わかればいいので)

ここで説明した流れが永久ループです。
うちの場合は、エンジニアタスクは常に3つ程、依頼前(仕様書)のステータス3つ、アイデアレベルたくさんといった感じでタスクや次の施策が常にたまっている状態にしています。（新しいアイデアがたまっている施策を追い越す場合もありますが）

アイデア～施策化で大事なことは、早いスピードでたくさんのPDCAを廻せるサイクルが仕組み化されていることかと思います。

以上です。拙い内容ですが、もし書いてほしいテーマとかあればコメントしてください。