NMY

企画を通す・企画を伝える

Webディレクター解体アドベントカレンダー12日目の記事です。今日から3日間は提案・調整編として、企画を如何に通すのか、自分が考えた企画をどう人に伝えるのか書いていこうと思います。今日はまずその基本として、企画を提案して通すというのはどういうことか書いてみます。

ミニマムな提案

企画の提案と一口に言っても、日々のちょっとした改善から大きな方針転換まで、提案する企画のボリュームは様々です。ではまず一番小さい、ミニマムな企画を人に提案するときに必要な要素は何でしょう。これは普段使っている、GithubでIssueを作る時にデフォルトで入るテンプレートです。

f:id:nmy:20201208193152p:plain

たった数行ですが、これが一番ミニマムな要素だと思っています。それはなぜやるのかと、何をやるのかです。解決策の方には「起票段階で解決案や完了条件があるなら〜」とある通り、こちらは最悪無くても良い。解決しようとしている問題の背景をきちんと伝えられていれば、解決方法は後から考えたり、開発チームに任せることもできます。

何かを提案するとき、一番大事なのはこの部分です。企画フェーズで調査・分析が最も大事だったことと同じです。本当に解決しないといけない問題は何なのかを明らかにすること。そしてそれを言葉で説明すること。それが提案をする時に最も大事なことです。

大きな提案

新たに大きな予算がかかるような企画を通そうとする時は、もちろんこれだけでは足りません。解決しないといけない問題だけを提示されて、解決方法は後から考えますという企画を承認する決裁者はなかなかいないでしょう。

前提を共有した後に解決策を提案して、更に具体的な実現方法までが求められます。企画書や提案書を書く時は、だいたいその順番をそのまま踏襲しています。

  1. 前提の共有
    • 現状分析
      • 市場の動向やサービスの現状について。数値の推移などの定量的な分析と、ユーザー動向などの定性的な分析の両面があると良い。
    • 課題整理
      • この提案で解決しようとしている課題を明確にする。前提共有の中で一番大事なパートで、ここがずれているとこの後の提案全部外してしまう。提案前にこの部分だけでも提案相手と擦り合わせておけると良い。
  2. 解決策の提案
    • 全体的な方針
      • 具体的な提案に入る前にどう課題を解決するのか、分かりやすい言葉で方針(戦略だったりコンセプトだったりする)を簡潔に述べる。ストーリーになっていると良い。
    • 具体的な提案
      • 提案内容によって構成は異なるがWebサービスの場合はビジュアルで見せる方がイメージが湧くので画面イメージが欲しい。
  3. 実現方法
    • スケジュール・開発順序のイメージ
      • 実際のリリースまでに必要なマイルストーンを挙げて、スケジュールや開発順序を明示して、実現までのイメージを持ってもらう。
    • 運用体制
      • リリースした後の運用や改善をどういう体制でどういう仕組で行うのか、その場合に必要な体制や予算などを明示する。
    • 予算の見積りやスキームの提案
      • かかる予算の提示と、どう捻出するかや座組みの提案。

インパクトを重視して、最初にいきなり画面イメージからドーンと見せる時もあります。でもあくまで変化球。基本はこの順番です。前提を共有して、本題に入って、現実的な手段に落とす。企画を提案するときの鉄板の順序です。

提案からリリースまで

企画を提案する時、提案相手と決裁者が異なる場合があります。特に案件を獲得するときのコンペとか、こういうケースが結構ある。提案する時、企画を人に伝える時は、誰に伝える必要があるかを意識して内容を調整する必要があります。決裁者が担当者の上司の場合、その人はどういうバックボーンで何に責任を持っているどんな立場の人なのか。Webに詳しい人かそうでないかで、使う言葉や盛り込むべき内容が変わってくるからです。

f:id:nmy:20201208193205p:plain

企画を提案して通った後も、その内容を人に伝える旅は続きます。必ずしもこの図の順番である必要はありません。提案前に開発チームに相談してから提案することも多いし、先に関連部署に根回ししておくこともあるでしょう。順番はどうあれ、最後には実際に使ってくれるユーザーに伝えるところまでが1セットです。

リリースするときの告知の仕方やその内容、どんなユーザーにどんな言葉で伝えるのか。伝える相手によって切り取り方は変える必要はありますが、嘘をつくわけにはいきません。企画を立てて承認を得る時から開発チームや関連部署に伝える時、ユーザーに届けるときまで、切り取る断面は違えども1本の芯を通っているべきです。それには、自分の言葉で企画を伝える必要があります。

自分の言葉で伝える

企画を提案する時、企画の内容を伝える時、いつも気をつけているのは自分の言葉で伝えるということです。今流行ってるからとか、市場がどうとか、競合がどうとか、企画を立てた理由は色々あるでしょう。調査・分析が大事とかあれだけ言ってるわけですから、その背景を説明する必要だってあります。それでもこの企画内容が適切だと考えたのは、他ならぬ企画者自身です。自分がこう考えたから、自分はこうすべきだと思ったから、自分はこれが最も良いと思ったから。企画を提案するときの一人称は常に自分であるべきです。

サービスや機能をリリースする時、ユーザー向けの告知は自分で書くようにしています。そして告知文のタイトルや内容は、いつも主語を一人称にしています。

  • 「閲覧できるようになりました」ではなく「閲覧できるようにしました」
  • 「保存できるようになっています」ではなく「保存できるようにしました」

こうしたちょっとした文面の違いにもまた、企画を人に伝えようという姿勢は現れます。主語はいつも一人称で、自分の言葉を使って伝えること。これが企画を通したり、人に提案する上で大切な姿勢だと思っています。

戦略を考える

Webディレクター解体アドベントカレンダー11日目の記事です。企画編の最後は、単発の企画だけでは実現の難しい大きな目的を達成するために必要な戦略について書きます。

競合と戦う

例えばあなたが「PVで10倍以上の差がある巨大な競合サービスに勝つ企画を考えろ」と言われたらどうするでしょうか。そんな無茶なって感じですよね。そんな企画の1つや2つ考えただけで覆るかよと。

だけど実際Webサービスの企画をする時に、立ち上げ時であれグロース時であれ、どう競合サービスと戦うかを考えなければならないケースは少なくありません。特にWebサービスの場合はネットワーク外部性が働くものが多く、同じサービスドメインの中で生き残ることができるサービスは限られるからです。

そういう時に必要になるのが全体を束ねる大きな方針、戦略です。競争を避けるのか、それとも正面から競争を挑むのか、如何に違いを生み出し、如何に生き残っていくのか。最初に方針が必要になります。サービス開発の大きな方針、その呼び方は様々ですが戦略という軍事用語が使われることが多い。

国家間の戦争や競合製品との競争の中で長い歴史をかけて多くの人々が様々な戦略を練り、戦略について語り、後世に語り継いできました。だから戦略について書かれた記事や書籍は沢山あり名著も多い。その中から2つ、言葉の定義と戦略の良し悪しについて書かれたものを2つ紹介します。

「戦略、作戦、戦術そして兵站」

戦略、作戦、戦術そして兵站「経営者とは、肩書きや地位を指す言葉ではなく、能力を指す言葉だ」-清水亮さんの神ブログの再編再掲|元Google/アフターデジタル 尾原のITビジネスの原理実践編|note

この記事は元々2012年に清水さんという方がはてなダイアリーに書かれていた記事の再掲です。元々が軍事用語である戦略という言葉の定義として、戦略とよく混同される作戦と戦術、そして戦略を実行するときに不可欠な兵站について説明されたものです。詳しくは上記の記事を読んでいただけると理解が深まりますが、ここに図表に記載された説明を引用します。

  • 戦略
    • 競争を行う際の方針と目的、方向性
  • 作戦
    • 戦略を実現するための具体的方法や計画
  • 戦術
    • 作戦を実行する際に必要となる戦い方、スキル
  • 兵站
    • 戦略全体を支える仕組み f:id:nmy:20201210222625p:plain

戦略と戦術はよく混同されますが、マクロな全体の方針が戦略で、ミクロな現場のオペレーションが戦略です。そして複数の戦術を束ねて、戦略を実現するための計画が作戦というわけです。兵站はそれらを支えるための人員だったり、開発費用だったり、必要な設備などのハード面も含まれます。

自分が戦略と呼んでいるものが本当に戦略になっているのかを点検するときに、よくこの概念を思い出します。自分は戦略だと思って考えていたものが、個別の戦術に過ぎなかったり、せいぜい作戦止まりだったりしないか、たまに振り返って意識してみると道に迷いにくくなると思います。

「良い戦略、悪い戦略」

戦術でも作戦でもなく、マクロにサービス全体の方針を考えているという時でも落とし穴は存在します。それは悪い戦略の罠にはまっている時です。戦略関連本の中でも有名な「良い戦略、悪い戦略」という本には、最初にまず悪い戦略の特徴がアンチパターンとして挙げられています。

  • 空疎である
    • 内容がない。専門用語が並んでてそれっぽいけど普通のことしか言ってない。ミッションやビジョンと混同している。
  • 重大な問題に取り組まない
    • 1番の問題を見てみぬふりをする。目の前の成果の出やすい課題を解決しようとする。調査分析が足りてない。
  • 目標を戦略と取り違えている
    • 「120%成長」「MAUを伸ばします」「お客様に愛されるサービス」など目標になっているもの。どうなりたいかの希望だけあって道筋がない。
  • まちがった戦略目標を掲げる
    • 重大な問題とは無関係である。実行不可能である。

特に3つ目の目標になっちゃってるやつ。全社員が集まった機会に、サービスの方針として誇らしげに掲げた思い出が蘇ってきました。今思い返すと恥ずかしさのあまり身悶えします。他にもそれっぽいけど中身がないやつとか、どこかで見た覚えのある特徴がいくつかあります。

逆に良い戦略の基本構造として挙げられているのは「診断」に基づいていいること、課題にどう取り組むかの「基本方針」があること、具体的な「行動」に繋がることです。ここでも最初に診断が挙げられています。企画の前提に調査・分析があったように、正しい現状認識とその分析がなければ良い戦略は立てられません。良い企画と同じです。

戦略を考える時に気を付けていること

実際、戦略は大きな企画だと思っています。スコープが大きくなっただけで、何をするか決めることに変わりはありません。最初に調査・分析が必須なのも同様です。

ただ戦略ならではの考慮しないといけないポイントもあります。ここでは私が戦略を考える時に特に気をつけていることを3つ挙げてみます。

  • 対競合戦略になっているか
    • 戦略のほとんどは対競合戦略である。対競合戦略ではない場合、本当にそれで良いのか何度も疑った方がいい。
    • まだ競合の存在しないブルーオーシャンに漕ぎ出す場合でも、後から追いつかれないための戦略が必要になる。
    • 対競合戦略になっているか、なぜ競合はその戦略を取っていないのか論理的に説明できる必要がある。
  • ストーリーになっているか
    • 数百文字程度の短文に落とし込んでみる。エレベーターピッチとも言う。
    • 他人に口頭で論理的に説明ができるかどうか。
    • なぜ?に答えられるか。誰もが考えつく疑問に答えられなかったら話にならない。
  • やらないことを決める
    • 成功するか不安だとどうしてもあれもこれもと作戦の数を増やしがち。
    • 保険のために作戦を増やして得られる安心感に抗うのは難しい。
    • 明示的にあらかじめ、やらないことや諦めることを決めておく。

「コア&モア戦略」

戦略と言うのは基本的に対競合戦略なので外に明かすことができません。ここまで書いてきたことは概念的で1つも具体例がない。これまでに考えた戦略の例を挙げながら説明できればもう少しわかりやすいと思うのですが、歯痒いところです。それでも、これまでに考えた戦略を振り返ってみて共通する要素を探してみると、結局コア&モア戦略になっていることが多かったです。

既存のユーザーを大事にしながら、どう新規のユーザーを獲得していくのか。自社のユーザーを囲い込みながら、どう競合サービスからスイッチしてもらうのか。Webサービスは多くの場合ネットワーク外部性が強く働くから対競合戦略を考えざるを得ない。そうすると自然にコアを育てながらモアを獲得していくという形態になることが多くなる。

常連客(コア)に来店頻度を高めてもらいながら、女性客や子ども連れなど新しい客層(モア)を獲得する「コア&モア戦略」を掲げた。 https://toyokeizai.net/articles/-/332729

これは吉野家の例ですが、Webサービスの戦略を考える上でも参考になる考え方が沢山あります。対競合戦略になっていて、ストーリーとしても美しい。語られる戦略はだいたい成功した戦略だからかもしれませんが、優れた戦略はいつも美しい物語を読んでいるようです。いつしかそんな、不朽の名作を書いてみたいものです。

企画力を磨く

Webディレクター解体アドベントカレンダー10日目の記事です。昨日は企画方法の一つとして、アイデアを閃く方法について書きました。

アイデアは企画の中でも複数の問題を解決するような、飛躍的な発想が必要なケースで出番が回ってきます。問題がシンプルで順序立てて考えることで答えが導き出せる場合は、論理的思考の出番です。Web開発の現場では必要に応じて飛躍的発想と論理的思考を使い分ける必要があり、総合的な企画力が求められます。だから他の専門職と同様に、普段から鍛錬をして鍛えておく必要があります。今日は企画力の磨き方についてです。

小さな企画から始める

企画も他の技術と同様で、まずは入門編として簡単な企画から始めるのが良いと思います。企画は誰にでもできるものだから、世の中にはそんな練習しなくてもいきなり大学生の顔写真図鑑を思い付くような天才もいますけど、少なくとも私はザッカーバーグではないので、そうしてコツコツ企画をやってきました。

企画における入門編とは何でしょうか。例えば「今週の日曜日に何するか決める」というのも企画の一つですよね。家族と何処に行って何をしようか考えたり、友達を誘って食事に行こうと考えたり、そういうのもミニマムな企画の1つだと思います。規模が小さいだけで、立派なイベントの企画ですよね。

もう少し実務的なレベルでの小さな企画だと、日々のサービス改善の中でもちょっとした企画があります。最近ユーザーさんからのお問い合わせが増えてるあの画面のわかりにくさを改善したいとか、最近コンバージョンが落ちてきたあの登録フローを改善したいとか。こういう課題が明確だったり、課題が1つしかない場合は考えやすい。こういうのを日常的に考え続ける癖みたいなのを付けると、毎日ドリルやってるみたいな感じで企画力がついていきます。以前紹介したユーザーフィードバックに毎日返事を書くというのも、まさにそれです。

勝手に企画する

Webサービス以外の企画をやってみるもの良いです。私がよくやるのは、勝手に他人の店とか事業の再生計画を企画するという遊びです。例えば妻と道を歩いてる時に、あの店いつも客入ってないよな、どうしたらいいかなと考え始めます。この立地だとターゲットとする顧客層はこういう層だから、まずはメニューから見直したほうがいいんじゃないかとか。いやまずは外装を見直して集客の解決が先でしょうとか。いやいやザルに水注いでも仕方ないんだから既存顧客の食後の満足度向上のために、デザート何とかした方がいいよねとか。そんな悠長なこと言ってたら潰れちゃうからまずはランニングコスト抑えるためにあの部分仕組み化しようとか。

勝手な想像で適当なこと言ってるだけなんですけど、想像力を働かせてどこにボトルネックがあって、解決するのにどんなアイデアがあるか考えるのも楽しいものです。そうやって妻とあーでもないこうでもないと、企画会議をするっていう遊びをやっています。

例えばエンジニアの人たちだと業務外の自分の趣味で何か作ったりとか、ソフトウェアじゃなくてハードウェアちょっといじってみたりとか、そういうところから仕事に活かせる技術力につながることって結構ありますよね。企画も同じで、やっぱり普段からやってると強いです。課題を洗い出し、目的を明確にして、解決策を導き出し、時には突飛なアイデアを思いついて、実行可能なプランに落とし込んでいく。そういう一連のプロセスを普段から考えていると、企画力がついていくと思います。

設計まで踏み込む

何をやるか決めるのが企画ですが、決めた何の具体性を上げていくと、企画がさらに膨らんでいきます。具体的な設計まで踏み込んで企画を膨らませて、また最初にもどって企画を見直してみるという方法も有効です。先に画面のイメージを考えてから、何をやるか決めるという主従が逆転したような順序でものを考えてみるわけです。手段が目的化してしまうと本末転倒ですが、思考が硬直したときにやってみると新しい道が開けたりします。

実際私も企画と同時に、よく画面の設計を一緒に考えます。XDでもSketchでも、Keynoteでもパワポでも手書きでも何でもいいんですが、こういう画面でここを押したらこうなってこういう遷移をするというところまで、勝手に描いて妄想するんです。実際、画面のワイヤーフレームが元になった企画も多いです。

とあるコンテンツのビューワを企画したときは、画面のイメージを描き出したのが最初でした。こういうビューワがあったらいいなというのが先にあって、その後にビジネスモデルやどこにどう提供するかを考えました。

ミニマムな企画には画面や仕様の設計までは必要ありませんが、あえて設計にまで踏み込んでみて、そこからもう一度企画を振り返ってみるということを繰り返していくと、設計から逆算するという手法で企画の幅を広げられるようになります。

俺より強い奴に会いに行く

学習というのは、フィードバックが大事ですよね。企画を考えて、企画をぶつけてみて、返ってきたフィードバックであそこが良かったとかそこの詰めが甘かったとか反省して、次に活かすっていう。そういうフィードバックループを回すのが大事です。そのためには企画力の高い、強い人に企画をレビューしてもらうのが効果的です。

実際、企画を提案したときによくわからない反応が返ってきたことないでしょうか。良いか悪いのか良くわからない反応だったり、どこがどう良くないのか具体性がない指摘だったり。そういう場合、どう改善したら良いかわからず、次に活かせません。

やっぱり強い人に本気で企画をぶつけてみて、本気のフィードバックが帰ってくる時が、一番強くなれると思います。実際に私も何度か震えるような強い人や憧れのあの人に自分の企画をプレゼンしてぶつけてみたことがありますが、今でもその全てを鮮明に覚えています。

格闘ゲームみたいですが、どの分野でも共通することなのかもしれません。強い奴を見つけるの大変ですし、そうそう見つかるものでもないと思いますが、見つけたら本気で自分の企画をぶつけてみてください。きっと良いフィードバックが返ってくると思います。

f:id:nmy:20201129015535p:plain

アイデアを閃く方法

Webディレクター解体アドベントカレンダー9日目の記事です。調査・分析フェーズで材料が出揃ったら、いよいよ企画を始めていきます。今日の記事では企画する上での論理的思考と飛躍的発想の違い、そしてアイデアを閃く方法について書きます。

論理的思考

目指すゴールがはっきりしてて、現在地がわかってていて、その間に立ちはだかる問題も明らかになっていて、本当にそれが問題だと確信できていたら、意外とそのまま論理的に考えて答えが出ることもあります。

購入のコンバージョン上げようとしていて、ボトルネックになっているページがわかってたら、そのフローをユーザビリティテストしてみてみんなが迷ってるポイント明らかにして、後はそこのUIを改善していけばいい、みたいな。これはわかりやすい例ですけど、企画といってもそんなに突飛な発想とか、そういうのいらないケースも結構あります。いや、むしろそっちの方が多いのかもしれない。

だからやっぱり最初の調査分析フェーズと、本質的な問題を見極めることが大事なわけです。何度も繰り返して申し訳ないですけど、目指すゴールと現在地とその間に横たわる問題が明確になっていれば、勝ったも同然です。後は論理的に順序立てて筋道を追って考えていく。そうして企画を組み立てていきます。論理的思考で企画するケースです。

f:id:nmy:20201129010853p:plain

飛躍的発想

だけどそう一筋縄でいかないこともあります。ゴールと現在地の間に立ちはだかる問題が山ほどあったり、めちゃくちゃ巨大だったり、真っ直ぐ解決に進めない制約が存在していたり。問題がてんこ盛りで何から手を付けたらいいのかわからないケース。進出しようとしているサービスドメインに超巨大な競合が存在してネットワーク外部性でガチガチのケース。予算や期間の制約であれもこれもできないケース。そういう時に、飛躍的な発想が必要になってくる。いわゆるアイデアが必要になる場面です。

f:id:nmy:20201129010908p:plain

任天堂の宮本茂さんは「アイデアというのは複数の問題を一気に解決するものである」と言われていたそうです。有名な言葉ですよね。この記事を読んでから、企画を考えるときによくこの言葉を思い出します。

複数の問題を一気に解決するには、複数の問題を正しく認識していないといけません。やっぱりそこが大事です。問題だと思っていたことの根源を辿っていくと、本当の問題は実は別に存在していたりする。本当の問題を見極めて、正しいKPIを設定するのがどれだけ難しいか。でも正しく問題を認識できたら、それらを一気に解決する方法を閃くだけです。

閃くだけ。そんなわけないですよね。それがまた難しいんだから。ではアイデアはどうやったら閃くことが出来るのか。

アイデアを閃く方法

頭の中を材料でいっぱいにして、ついつい考えちゃう状態を作って走る。それが私の考える、アイデアを閃く方法です。

f:id:nmy:20201209011504p:plain

「あっ、いいこと考えた!」っていう時ありますよね。閃きの瞬間です。閃きが起こる時、頭の中にあるあれとこれとそれが考えもしなかった経路でぱっとつながります。思いついてしまえば何だそんなことかと、当たり前のように感じるでしょう。でもその経路を知る前は、あれとこれがつながるなんて全く思いつきもしなない。

意外な経路を発見するには、あれやこれや、頭の中に繋がるための材料が沢山あればあるほど良い。例えばサービスの定量的なデータ、どのページがどれだけみられていて、コンバージョンに至るまでのボトルネックがどこで、リテンションの障壁は何なのか。例えば定性的な情報、ユーザーさんから日々送られている問い合わせにどんなものがあって、ユーザーインタビューしたときに田中さんが言ってたあの一言とか、あの時見せたあの表情がひっかかってるとか。他にも最近の技術でこういうことができるようになってるとか、チームメンバーの誰々が最近こういう開発したいと言ってたとか。競合サービスの弱みだったり、自社の強みだったり、最近の市場の状況だったり。

サービスの周りにある色んな情報が材料として頭の中にパンパンに入っていればいるだけ、意外な経路が現れてくるものです。

頭が材料でパンパンになったら、あとは閃きやすい状態に自分を持っていきます。アイデアを閃くとき、机に向かってうーんうーんと考え続けてひらめくケースもあるでしょう。でも意外と、全く仕事とは関係ない場所で閃くこと多くないですか。

前にNHKスペシャルでやってたんですけど、脳って「ぼーっと」している時に閃きやすいんですって。人はぼーっとしているときに脳の広い領域が活性化している「デフォルト・モード・ネットワーク」という状態になって、無意識のうちに脳の中の記憶の断片がつなぎあわされて、閃きが生まれているんじゃないかと。まあ一つの説なので眉唾ですけど、でも言われてみれば確かにそういうことあるなと。

ぼーっとぼんやり何かを考えている時って、どんな時でしょうか。お風呂で頭を洗っている時、トイレで用を足してる時、散歩している時、ジョギングしている時、寝る前にベッドでまどろんでいる時など、スマートフォンやPCの画面を見ていない時が多くないですか。

f:id:nmy:20201209011022p:plain

私の場合は圧倒的に走っている時が多いです。よく平日の朝、仕事の前に1時間くらい走るんですが、その時にその日にやる仕事のことをぼんやり考えたりするんですよね。これまでの企画の多くは、そのランニングコースで生まれました。特に山を走ってる時が多いです。加えて何か解決しなきゃいけない問題があって、仕事が終わってもどうにもモヤモヤ気になって、ついつい想いを馳せてしまう状態になっている時です。ありますよね、風呂入ってる時にもつい仕事のこと考えちゃってたとか。

そうやって、何となくついつい考えちゃう状態を作り上げましょう。頭の中が材料でパンパンだったら、つい考えてしまうはずです。そのことで頭がいっぱいなんだから。後はその状態で走るわけですが、走るの部分は人それぞれです。散歩がいい人もいれば、シャワーがいい人も、トイレがいい人もいます。スマホやPCやテレビを見てない時間を意識的に作るのもいいと思います。それでぼーっとして、ぼんやりと考えをめぐらせる。

そうすればアイデアは閃きます。たぶん。

ユーザーインタビューをしよう

Webディレクター解体アドベントカレンダー8日目の記事です。定性調査にもいろんな種類がありますが、一番代表的なのはユーザーインタビューだと思います。ユーザーさんに直接向き合う機会で得られるものも多いですが、きちんと意識してやらないと有効な情報が得られません。今日はユーザーインタビューのやり方や、気を付けるべきポイントについて書きます。

目的を明確にする

ユーザーインタビューを設計するにはまず、その目的をはっきりさせる必要があります。何のためにやるのか、どういう情報を得たいのか、その目的にとにかく自覚的になることが最初のステップです。私がこれまでにやってたインタビューを例にすると、以下のような目的がありました。

  • ターゲットユーザーの課題を探る
    • サービスを立ち上げる前の調査フェーズで、ターゲットになるユーザーの現在行なっている代替手段が何で、そこにどういう課題があるかを掘り下げていった
  • サービスのコアバリューを確認する
    • サービス開始からしばらく経ったサービスで、実際にサービスを利用しているユーザーが何を理由に自分たちのサービスを選び、なぜ使い続けてくれいるのか、その最もコアになる価値の確認を目的とした
  • 導入を考えている大きな企画を開発前に検証する
    • お金の絡む機能など開発に大きなコストがかかる場合に、開発を始める前に企画をパッケージデザインにまとめて直接見てもらい、その反応をうかがったり感想を聞いたりして実際に受け入れられそうかどうかを検証した
  • すでに提供している機能の利用シーンや課題の洗い出し
    • 既に提供しているがあまり有効に活用されていない機能に対して、普段使っている時の様子を普段使っている端末から再現してもらったり代替手段を教えてもらったりして、どこに問題があるのか(UIの問題なのかそもそもの課題設定が間違っているのか)確認した

目的によってインタビューのやり方も、誰を何人呼んで何を聞くかも、全てが変わってきます。1回のインタビューで2つ以上の目的を持つこともありますが、その場合は優先順位を付けるなど、目的をより明確にする必要があります。

グループインタビューと個別インタビュー

目的が明確になったら、実際にインタビューを設計していきます。インタビューは複数人一緒に話を聞くグループインタビューと、1人ずつ話を聞く個別インタビューがあります。

インタビューというのは聞き手(インタビュアー)が質問して、受け手(インタビュイー)が答えるというのが基本のやりとりですが、そうするとインタビュアーが質問したことしか聞き出すことができません。つまり、聞けることがインタビュアーが知っている範囲に留まります。例えばおじさんのインタビュアーが学生にインタビューしているところを想像してみてください。学校で何が流行っているのか、学生たちの間で起きている独自の文化をその外側から、外側の社会の言葉を駆使して聞き出すのは困難です。

そういう時にはグループインタビューが役立ちます。インタビュアーが「最近何が学校で流行ってますか?」とグループに向かって一石を投じると、参加者の間で「あれが流行ってるよね」とか「あれまじ楽しいよな」とか、自由に話し始めることがあるのです。参加者同士で通じる世界観の中で自由に会話してもらい、その様子を観察させてもらうという方法が有効に働くことがあります。

一方、グループインタビューでは同調圧力が強く働きます。みんなが良いと言っているものに対して、1人だけ異を唱えるのは勇気がいります。そしてインタビューの場でそんな勇気を発揮できる人は少数です。何となくインタビュアーが振った話題に同意してみたり、グループのみんなの意見に賛成してしまうことがよく起こります。そういう場合は1人ずつ個別に話を聞く方が良い。

グループインタビューも個別インタビューも一長一短があるので、私は可能なら両方一緒にやっています。例えばユーザーさん5人に集まってもらって、最初にグループインタビューをしてから、個別に1人ずつインタビューをする。個別インタビューでは「さっきこう仰ってましたけどどうですか、自分が実際に使っているところのイメージ湧きますか」という感じで、深堀していきます。これを人数分繰り返していくわけです。

この方法には個別インタビューを待っている残りのメンバー間で雑談が発生しやすいという利点もあります。インタビューですから緊張してなかなかスムーズに話せない方も多い。そういう方でも、一旦インタビューはここで終わりです、個別にお話を聞かせていただくまで自由時間ですと言って、みんなでお茶を飲んだりお菓子を食べたりしていると、自然とさっきはこうだったよねとか話し始めてくれることがあります。個別インタビューを行うインタビュアーとは別の担当者を待合室に配置して、それとなく話を振ってみるのも効果的です。

リクルーティング

インタビューの方法が決まったら、参加してくれる方を探して参加を依頼します。いわゆるリクルーティングです。既存サービスの課題を洗い出すのが目的ならサービスの利用者から、新サービス立ち上げ時のニーズの調査ならユーザーになってもらえそうな属性の人から参加してくれる人を探します。

サービスの利用者を対象したケースの方がアプローチが楽です。よくやるのは、まず最初にアンケートをとる方法。サービスの利用者にインタビューする場合、特にこういう属性の人に聞きたいという指定があることが多いです。例えば週N回以上投稿しているヘビーユーザーとか、一度も投稿したことがないけど毎日訪問している閲覧者とか。そうした属性の指定がある場合に、まず最初にユーザーアンケートを行なって普段の利用状況を質問して、最後にインタビューに参加してもらえるかどうかを聞きます。あとはアンケート結果の中から、該当する条件を満たしていてインタビュー参加OKの方に直接メール等で連絡をして日程の調整をしていきます。

サービス立ち上げ前や、サービスを使ったことがない人を対象にしたインタビューではリクルーティングに苦労すると思います。お金をかけられるならリサーチ会社に希望する属性の人を集めてもらうといいのでしょうが、立ち上げ前だと予算がついてないことも多く、何より気軽に行うことができません。そもそもターゲットユーザーが探せないとなると、実際にサービスを立ち上げた時にどうやってアーリーアダプターを獲得したらいいかわからなくて困ります。だから苦労してでも、なるべく自分の足で探すのが良いでしょう。

f:id:nmy:20080514172022j:plain

これは昔、スターバックスで学生さんに声をかけてインタビューした時の写真です。さすがにいきなり知らない人に声をかけるのは恥ずかしくてもうやりたくないけど、この頃はまだ若くて度胸がありました。他にはユーザーさんにお願いして、まだサービスを使っていないご家族の方を連れてきていただいたこともありました。いろんな工夫をしながらユーザーさんを探すその経験自体が、後の獲得フェーズでも活きてくると思います。

質問表を作っておく

インタビューの形式や参加者が決まったら、あとは実際にインタビューといきたいところですが、事前に準備しておくことはまだまだあります。1つは質問表を作っておくことです。

インタビューは個別の場合、インタビュアーと書記の2名でやることが多いです。インタビュイーの方にご同意いただければ、会話を録音しておいて後から書き起こしても良いのですが、例えばその場で見せた表情や仕草など、録音データに残らない情報もあります。そうした言語外の情報も書き残しておけるように、インタビュアーとは別に書記を用意してインタビュー中にリアルタイムで記入していってもらいます。

その記入用のシートが質問表です。いつもGoogleスプレッドシートで作っています。あらかじめ聞きたいことを洗い出しておいて、書記の人にはインタビューを聞きながら該当する項目にメモをとっていってもらいます。もちろん質問表にないことも聞きます。インタビューで盛り上がって脇道に逸れることも結構あるので、その場合は欄外にメモしていってもらえば良いです。

インタビュー中はインタビュアーも書記も、同じシートを見ながら進めます。そうするとインタビュアーがこの辺りは情報が薄いから掘り下げようとか、インタビュー中に軌道修正しやすいのです。そうして質問表を書記がリアルタイムで埋めていき、インタビュアーも後から補足があったら追記します。

インタビュー中に気を付けること

インタビュー中、質問するときに気を付けるべきこともあります。それはあんまり直接的な質問に頼りすぎないということです。

直接的な質問とは、例えばとある企画へのユーザさんの反応が知りたい時にする「これ使ってみたいですか」という質問です。聞いてもいいんですけど、その質問に頼りすぎると思わぬ落とし穴にハマることがあります。それはインタビュアーをがっかりさせたくない、相手に直接ネガティブなことを言いにくいというバイアスです。それほど使ってみたいと思ってなくても、開発者でもあるインタビュアーを喜ばせようと、使ってみたいと答える人も多いのです。

そういう場合には「実際に使うとしたらいつどんな時に使いますか」というような、具体的な利用シーンを聞くような質問をするといいです。自分だったら生活の中のこういう場面でこんなふうに使うと、具体的にイメージできていたら実際に使ってもらえる可能性が高いでしょう。逆に何となく具体性のない回答が帰ってくる場合は、相手に価値が伝わっていないか、価値を感じてもらえていないかのどちらかだと思います。

インタビューの後にやること

インタビューが終わったら、インタビューに参加したスタッフ全員で感想戦を行います。インタビューを行った直後というのは、一番ホットな感覚が残っている時です。その記憶が薄れる前に、1人ずつインタビューの感想を言葉にして他人と共有しましょう。言語化しておくというのがポイントです。自分が得た大量の情報の中からエッセンスを抽出して他の人でも理解可能な状態にするその工程が、ユーザー理解そのものだからです。

感想戦が終わったら、最後に主な質問を縦軸に、インタビュイーを横軸にしたマトリックス状の一覧表を作ります。インタビュー中はふとした仕草さ表情など得られた情報は何でもメモしていきますが、最終的にはある程度言語化した回答のまとめを作っておかないと、後から参照したときに大変です。インタビューに参加していない開発メンバーにもわかりやすいように情報をまとめておけば、開発チームの共通言語として使えるようになります。インタビューの時にあのユーザーさんがこんなことを言ってたよね。そういう会話がチームの中で共有できる状態になっていることが理想です。

f:id:nmy:20201207234314p:plain

ユーザーインタビュー、実際にやろうとするとコストもかかるし大変です。私は何度やっても終わった後に全身の活力を全て使い切って抜け殻みたいになります。それでもユーザーさんの直接の声を定期的に受け取りながら、定性と定量の両輪でサービスの企画を進めていくべきだと思い、歯を食いしばってやっています。

定性調査とアンケート

Webディレクター解体アドベントカレンダー7日目の記事です。今日は調査・分析の中でも定性調査の概要と種類について、そして定量と定性の両面を併せ持つアンケートについて書いてみます。

定性調査

定性調査はユーザーから発せられる数値以外の情報全てを対象にしています。主に言語を通じて語られるサービスの感想や要望はもちろん、顕在化していないユーザーの潜在的なニーズを引き出したり、言語化できていないサービスの真の価値を明らかにするために、表情や仕草などから情報を読み取ることもあります。

定性調査は直接対面で話を聞いたり直接行動を観察させてもらう「対面型」と、インターネット上のテキストを読んだり分析したりする「テキスト型」に分けられます。あとはテキスト中心ですが、定量の側面も持つアンケートですね。アンケートは定量・定性両面の特性があって特殊なので、個別に詳しく説明します。

  • 対面型
    • グループインタビュー、1対1のインタビュー、行動観察、ユーザビリティテストなど、同じ場所に集まってもらって直接対面(もしくはテレビ通話)で調査・分析する方法。
  • テキスト型
    • サービスのフィードバックや問い合わせフォームなどから直接送られたり、Twitterやブログなどで言及されたサービスに対する意見や感想、要望などを拾い集めて調査・分析する方法。
  • アンケート
    • 選ばれた選択肢の数を定量的に分析する側面と、記入された自由記述のテキストから訂正的に読み解く2つの側面を併せ持つ。

対面型とテキスト型、もちろん両方やるのが望ましいですが対面型の方は実施のコストが高く、そう日々日常的に行えるものではありません。一方テキスト型はエゴサーチしたり、日々届く問い合わせのメールを見たりと実施のコストが低く、日常のルーチンの中に組み込めるものです。

特によくWebサービスで設置されている、ご意見・ご要望のフィードバックフォームから届く意見は切実なものも多く重要です。私はいつもサービスのフィードバックフォームから送られた意見は全て自分のメールアドレスで受け取れるようにしていて、自分のメーラーから1通ずつ目を通しています。1件1件その全てに対応できるわけではありませんが、ユーザーが今何に課題を感じていてどういう要望が多いのか、当たり前のように日々浴び続けているとその潮目や温度感の変化を敏感に感じ取れるようになります。

コストをかけてきちんと設計をして行う定性調査も勿論大切ですが、こうした日常のテキスト型情報の摂取で得た肌感覚をベースにして、その土台に基づいてユーザーインタビューやユーザーアンケートを設計していけると良い調査ができます。

定性情報を言語化する

定性調査では、ただ調査を行うだけでなく、如何に言語化するかが重要です。一昨日の記事では、定量でも定性でも調査・分析は「複雑でカオスなユーザー心理を単純化してデフォルメして、人間が理解可能にする行為」だと書きました。定量調査は数字が結果を語ってくれますが、定性調査の結果は言語です。大量の定性情報を、自分で解釈して自分の言葉で言語化したアウトプットが、最終的な分析結果になります。

この言語化が大事なポイントで、調査を行った感想になってしまってはいけません。感想というのは、自分がこう感じたという、主語が自分の行為です。定性調査の結果を語る時、自分の解釈で自分の言葉で言語化する必要はあるものの、あくまで主語はユーザーでなければならない。主体がすり替わっては本末転倒です。

インタビューを行った結果得られた反応や表情、日々フィードバックで寄せられる意見や要望、そういった情報を一旦全部取り込んだ上で咀嚼して解釈して、ユーザーがサービスに対してどう感じ、どういう思いで使い、どこに課題を感じているのか、そうした分析結果を導き出す必要があります。

言語化を身につけるのに良いトレーニングがあります。それは日々フィードバックフォームから寄せられる意見に、1件1件返事を文章で書くという方法です。実際に返事を送る必要はありません。私は以前、社内向けのグループウェアで毎日のようにフィードバックに対する返答を書いてました。これを日々やっていると、その要望の真意は何なのか、本当は何が課題で何を望んでいるのか考える癖がついて、それを言語化してだからこういう改善を行うといいのではないかという回答にまとまります。実際、そんなに全部の要望に応えられるわけではないので無駄になる考察も多いのですが、日々フィードバックを受け取るのと共に習慣にしていると、定性情報を言語化するための良いトレーニングになると思います。

定量・定性の両面を持つアンケート

定性調査の中で、定量の側面も持つコウモリみたいな存在がアンケートです。一般的にアンケートは定量調査の方にカテゴライズされることの方が多いかもしれません。だけど私は、どちらかといえば定性調査を行う時の脳でアンケートを設計します。それは、ユーザー心理を考慮した定性的な設問設計が必要になるからです。

例えばサービスのユーザー向けに「この機能に満足していますか」とか「新しくこんな機能を開発予定ですが使ってみたいですか」と直接聞かれる設問。こうした直接的な聞き方では、なかなかユーザーの本心を引き出せません。ちょっと昔、リーンが流行った頃からWebサービスを使ってる時にこういうアンケートをよく見るようになりました。

「このサービスを、家族や友人など親しい人にどの程度勧めたいと思いますか?」

このタイプよく見ますよね。人に勧めたいか聞いてくるやつです。直接自分が満足しているか訊くよりも、人に勧めるというある種自分の信頼に関わるような行動に置き換えて訊く方がより正確な評価になるということで、みんなこういう聞き方を採用しています。

これは分かりやすい例ですけど、直接「満足しているか」や「使ってみたいか」を訊くのではなく、より正確な評価が得られやすいように設問を工夫する必要があります。

  • 問. お金を払いたいと思えるものはどれですか
    • お金を払うという高いハードルを課して、それを超えてでも利用したいと思えるものを選んでもらう。
  • 問. 実際に使い始めた時に選んだ理由を教えてください
    • 今から選ぶ時に基準とすることではなく、実際に過去に行った選択の理由を訊く。
  • 問. 普段サービスを使う時に気に入っているものを選んでください
    • サービスのコアバリューを確認したい場合も、普段日常的に意識していることを訊く。仮定の話をしない。

こうした選択式の調査は結果が定量的に得られますが、定性調査で行うユーザーインタビューの設計と似た思考が求められます。

アンケート設計のコツ

アンケートを行う時には、個別の設問だけでなく、全体の流れや聞き方にも様々な工夫が求められます。以下はアンケートを作る際に個人的に工夫していることです。

設問の流れ

属性を聞く設問 -> 本題の設問 -> フォローアップの設問

アンケート全体の流れはだいたいこの順番にしています。

いきなり本題に入る前に、まず回答してくれる方の属性を分類するための質問をします。アンケート結果で属性ごとに差が出るのか比較するため、クロス集計ができるように属性情報を集めるわけです。例えば年齢や職業などの基本属性に加えて、サービスの利用頻度や利用環境、利用目的などを聞きます。

次にアンケートで一番聞きたい本題の設問を持ってきて、最後がアンケートで回答しきれなかった意見を拾い上げるための自由記述の設問や、アンケート回答者に後からユーザーインタビューを行うための、インタビュー参加意向を問う設問で締めます。

パッケージデザインを用いた設問

まだ提供前の機能や企画についての反応を知りたい時がありますが、まだ出ていないものを文字だけで説明するのは難しいものです。そういう場合にパッケージデザインと呼ばれる、その機能をリリースした時に作るバナーのような1枚絵を作って、それを見てもらった感想を聞きます。

パッケージデザインは1枚の画像なので、デザイナーさんに作ってもらうこともありますが、自分でパワポやKeynoteで作る場合もあります。パッケージとは、ユーザーが商品を手にとる時に目にする、そのサービスを象徴するようなキャッチコピーや図案が描かれたビジアルです。Webサービスの場合、広告を打つ時のLP(ランディングページ)をイメージすると分かりやすいかと思います。LPのファーストビューのワイヤーフレームを作ってる気持ちで1枚の画像を作って、それをアンケートフォームに貼り付けて設問に使っています。

狙いを外した時のリカバリーを考えておく

これから開発をしようとしている企画について、開発前に感触を伺って軌道修正の必要がないか確認するためのアンケートを実施する場合があります。いい反応が得られれば良いのですが、思いっきり外してしまった場合に打つ手がなくなって困るので、もし狙っていた企画が外れても挽回するための設問を設けておいて、改善の足掛かりにしています。

挽回するための設問というのは、例えば改めてモチベーションを聞く設問だったり、プランBやプランCを用意しておいてそっちの感想も聞いておくような設問です。たとえプランAへの反応が悪くても、こういうモチベーションが強いならそっちを柱にしてもう一度練り直してみたり、用意しておいた別のプランに切り替えるきっかけにすることができます。アンケートは漠然と聞くだけでなく、ある程度回答傾向をいくつかのパターンごとに予測しておいて、意図をもって質問内容を吟味しておくことが大切です。

アンケートはあまりコストをかけずに気軽に行える良さがありますが、しっかりと意図を持って設計に工夫を施すことで、定量的なデータに加えて定性的にユーザー心理を理解する助けになります。設問内容や選択肢のテキスト1つ取っても、工夫次第で得られる情報量が全然違ってくる。たかがアンケート、されどアンケート。腕の見せ所です。

KPI設計から始める定量調査

Webディレクター解体アドベントカレンダー6日目の記事です。前回の記事で調査・分析はカオスなデータの単純化であり、人間が理解可能な意味付けを行うことであると書きました。今日は定量調査の中でも、データに意味を見出す方法について説明します。

データに意味を見出す

私は小さい頃から勉強ができなくて、その中でも特に算数が嫌いでした。三つ子の魂百までとはよく言ったもので、40過ぎた今でも数字が苦手です。当然定量調査も苦手です。

定量調査は非常に専門性の高い分野で、大きな会社だとデータアナリストという専門職の方がいてエンジニアリングも駆使しながら高度な分析を行なっています。文系の自分が付け焼き刃で太刀打ちできるような領域じゃありません。それでもWebサービスのディレクションや企画を行なっていく上で、避けては通れない道です。データ分析の専門家には敵わなくても、データの見方やその意味するところは知っておく必要があります。

代表的なフレームワーク

誰でも簡単にデータに意味を見出せるようにと、先人たちがよくある形をフレームワークに落とし込んだモデルが複数存在しています。まずはツリー構造から紹介します。

f:id:nmy:20201128231223p:plain

例えばある週にPVが増えたとして、まずUUが増えたのか(サイトに訪れる人の人数が増えたのか)PV/UUが増えたのか(1人の人が見るページ数が増えたのか)を見てみます。UUが増えている場合、新規ユーザーが増えたのか、継続ユーザーが増えたのか分解し、新規ユーザーが増えている場合はどの流入元が増えたのか(検索なのかソーシャルなのかリファラルなのかダイレクトなのか)を見ていきます。更にソーシャルやリファラルだったらどのサービスからの流入かを見て、更にランディングページを調べてみます。そうすると「ああこの前の週末にTwitterでこの記事がバズって流入が増えたからPVが増えたんだな」ということがわかるわけです。こうして只の数値の上昇という現象を、人間が理解可能な事象に分解していくわけです。

他には、ファネルと呼ばれる形もよく使われます。ファネルというのは漏斗のことで、だんだんと口が狭まっていく形から名付けられました。ECサイトでの商品の購入や、会員制サービスでの登録数をモデル化するときなんかによく出てきます。

f:id:nmy:20201128231238p:plain

例えばなかなか会員登録数が増えない時に、どのステップがボトルネックになっているか知り、改善効率の良い場所を探すことができます。会員登録ボタンまでは押してもらえるんだけど、その先の確認メール送信まで行ってないからその部分のUIを見直そうとか、施策に活かせるわけですね。

こうしたツリーやファネルのような単純なモデルに加えて、有機的に絡まるユーザー行動に近づけたもう少し複雑なフレームワークもあります。例えばこれは何年か前に流行ったAARRRというモデルです。

f:id:nmy:20201128231316p:plain

AARRRはそれぞれ、Acquisition(獲得)、Activation(活性化)、Retention(継続)、Referral(紹介)、Revenue(収益)の頭文字を繋げたものです。だいぶ流行ったからいろんな記事で解説されているので、詳しく知りたい方はAARRRで検索してみてください。ポイントは、ユーザー行動をモデル化したものだということです。

  • Acquisition:どの経路からどういうユーザーを獲得してくるか
  • Activation:新規で流入してきたユーザーに、最初にどんな良い体験をしてもらうか
  • Retention:一度良い体験をしたユーザーに、何をきっかけに2度目3度目の訪問をしてもらうか
  • Referral:定着したユーザーに友達に紹介してもらう等、どうやって新しいユーザーを獲得するか
  • Revenue:定着したユーザーに、どうやってお金を払ってもらうか

ユーザーの獲得から定着、そして収益化まで、ユーザー体験の全ての流れの中からポイントを5つに絞って計測するという形です。ユーザー行動を一つの行動フローに単純化してモデルにして、それぞれのポイントの数値を計測することで、サービスのどこに課題があるかを発見したり、何が理由で数値が増減しているのかを理解できるようにしています。

KPI設計でユーザー行動をモデル化する

こうしたユーザー行動のモデルは、当然サービスによって異なります。AARRRは友だち招待機能のあるSNSなどのサービス形態にフィットするような形で設計されていますが、例えばこれがECサイトやオウンドメディアのようなサービスの場合はうまくはまりません。サービスによってユーザー行動の設計は異なるので、そのユーザー行動にあわせたモデルで分解していく必要があります。例えばこれは、ユーザーが記事を書いて投稿するようなUGC系のサービスを想定したモデルのイメージです。

f:id:nmy:20201128231352p:plain

まず右半分のPVからピラミッド状に生えているのはツリー構造になっています。そして一番下の右から左に流れるライン、新規回遊からユーザー登録、ログインユーザーの再訪があって、いいねというアクションをしてもらうまでのコンバージョン。ここはファネル構造になっています。こういう感じで複数のフレームワークを組み合わせるのもありでしょう。自分のサービスの体験に合わせてモデル化していきます。こうして一連のユーザー体験の要所要所を数字に置きかえることで、数字に意味を持たせます。そうすると、どこを改善すべきかが段々とわかってくるのです。

モデル化ができたら、この中でKPIとして日々数値の変化をトラッキングして改善していくものを選びます。KPIを選ぶ時のポイントは、ユーザー行動モデルの中で肝となる箇所から選ぶことと、計測可能で干渉可能な数値を選ぶことです。さらっと書きましたけど、これが結構難しいんです。ここが大事だと思ってKPIを定めても、実は施策を打っても全然響かずに、全く別の要素で数字が変動するということもあります。

わかりやすい例だとPV/UUです。検索流入が結構あるサービスの場合、検索流入が増えると新規UUが増えます。検索からやってくる新規ユーザーはPV/UUが低いんですね。そうすると、全体のPV/UUは検索流入が多い時は下がり、少ない時は上がってしまう。そうなると回遊改善施策の効果云々ではなく、検索エンジンのロジックによって左右されてしまいます。だから回遊をトラッキングするためのKPIを選ぶなら、新規ユーザーと継続ユーザーの数値を分けて計測してより注力したい方にします。そんな風に、なるべく実際の施策や開発方針に生かしやすいものをKPIとして選ぶのが良いと思います。

定量調査は、突き詰めるとデータ分析という統計学などを中心とした数学的な専門知識の必要な分野です。それでも、なるべく誰もが理解ができるようにユーザー行動を抽象化して1つの行動モデルに落とし込むことで、開発チーム全体で理解可能な追いかけられる数値にできます。大量のデータを前に闇雲に計測するのではなく、まずユーザー行動を分解して計測してみる。それで施策に活かしにくかったり、行動モデルに合わなかったらKPIをまた別の数値に変更する。そうした試行錯誤を繰り返す過程がまた、ユーザー理解に一歩ずつ近付く道になると思います。