コンセプトの明快さと明確さによるコミュニケーションの削減

ダークナイトという映画をご存知だろうか。 名作すぎる名作なので多くはここでは語らない。

作中に二人の悪役が登場する。 一人はジョーカー。 もう一人はトゥーフェイス。

この二人を軸に、「明確なコンセプトはコミュニケーションやマネジメント、摩擦を削減する」「不明確なコンセプトは逆にそれらを増加させる」という話をする。

ジョーカー。 彼は極めて明確な人物だ。何をしでかすかわからないが、とにかく人に有害な悪事を行うという一点で常に一貫している。 もし自分が舞台のゴッサムシティの住人でジョーカーを偶然目撃したらどうすればよいか？ 対策も極めて明確だ。彼の天敵であるバットマンやゴッサムシティ自警団(警察が役に立たないのでそういうのがある)に通報すればいい。 ゴールも同様に明確。ジョーカーがアーカムアサイラムに収容されたらこの事件は解決されたことになる。 注：アーカムアサイラムは精神病院。警察と刑務所が役に立たないので悪党はそこに収容される。

トゥーフェイス。 彼は、作品単位ではともかくシリーズを通しては不明確な人物だ。 成り立ちにも同情の余地があるし、そもそも作品単位で悪役になったり改心して自警団側の脇役ヒーローになったりする。 もし自分が舞台のゴッサムシティの住人でトゥーフェイスを偶然目撃したらどうすればよいか？ もし彼が悪役ならバットマンに知らせるべきだが、自警団側の人間かもしれない。どう対策すればいいのかコンテクストを理解しないと行動できないから調べないといけない。 ゴールも不明確だ。アーカムアサイラムに収容される話もあるし、そうじゃない話もある。途中で自警団を抜けるかもしれない。

トゥーフェイスは不明確ゆえに、彼について対策を考えるときは多くのことを考える必要がある。 ジョーカーは「とにかくジョーカーをぶちのめせばOK」とシンプルであるのに大きな違いだ。

私がプロダクトについてコンセプトや背景を明確にするべきと考えているのは上に通ずる。「一貫したコンセプト」に沿って動いているなら「慎重に吟味」しなくても「聞かなくてもわかる、大体こういう感じなんだろ？」で協力なり支援なりあるいは静観なりの対応を決めやすい。 そうでないなら、情報をもらって協議して慎重に検討した上で判断しないといけない。 つまりそれはコストだ。 プロダクトに協力する側にとっても、プロダクト内から協力を求める側にとっても。

コミュニケーションやマネジメントのコストを削減するために、私は明快なコンセプトを、最初にコストをかけても決めるべきだと考える。それは必ず元が取れるからだ。

社内で考えていた僕の考えた最強のサービス

最近ピクシブ社で仕事でやっていたことはpixivサービスのPHP7対応などの地味〜な仕事なのですが
じゃあプロダクトマネージャーっぽいこと何もしていなかったんですか？
って言われて地味にショックだったので社内で提案した事業一覧です。

エンジニアでも事業について積極的に提言していいよ、というのがピクシブのウリだったんですが
最近の流れとして多数の新規サービスを立ち上げるために開発リソースが払底気味で、提言は新規サービスよりも任されたプロジェクトを高速化できる分野についてのものしか好まれませんでした。
要するに、ビジネスのことはビジネス職が考えるので、お前らは技術的課題やオンスケで開発することにだけ集中しろよって言われてました。

提言内容はどれも却下されたやつなのと、偉い人的には「こんなもの作ったって儲からないよ」って言われたので、社外秘の営業機密には当たらないだろうという判断です。

【pixivにおける再帰間隔と定着率の向上】

はいめっちゃ地味なやつ。
地味すぎて却下されました。
有料会員数増加に向けた施策です。
ソシャゲ界隈だと割と常識なんですが、ユーザーのログイン再帰間隔と平均滞在時間が課金額と相関しています。
そのためユーザーのログイン再帰間隔をあげようとします。メジャーな施策はログインボーナスです。
そこで「ユーザー指定の特定のキーワードやジャンルの作品で」「一週間以内に投稿されたもので」「ブクマや評価などが一定の足切りラインを突破した」作品のみで構成されたタイムラインをつくり、それを見せようとしていました。
感じとしてはいにしえのふたばチャンネルの二次裏が近いと思います。
無料ユーザーだと人気順検索ができないため、ログインしなければ「一週間以内」の枠から外れて人気作品を見逃すことになります。pixivの投稿数は非常に多く、投稿作品全ての中からタグで絞ったとしても人気作品をすべて見るのは大変だからです。
逆に「一週間以内」の枠の中でログインし続ければ人気作品を見逃しづらくなります。
一昔前、学校であった「みんな見ているテレビ番組を自分だけ見逃す」、に近い現象が起き得ないよう、仲間内の話題に乗り遅れぬよう、ユーザーは話題の作品を見逃さないよう頻繁にログインさせようとすることが狙いです。
また頻繁なログインによる閲覧はサービス中におけるお気に入りやフォローなどの「サービス内資産」を増加させます。「タイムラインの人気作品へのキャッチアップ」がどこかで限界に達しても、その資産を捨てることをもったいないと感じるユーザーは、課金することで有料課金機能を使って「人気作品だけのタイムラインへの、タイムシフトによるアクセス権」を手にいれることを狙います。
事実上のアップセルなのでこれが狙いの一つです。
またpixivは広告収入が主体なので、アップセルせずとも頻繁なアクセスは広告収入の増加につながります。

【ファンクラブ式パトロンサービス】

国内だとfantiaやentyが行っているパトロンサービスです。
月額課金によってユーザーはクリエイターを支援します。
他サービスとの差異点は、最低額課金に対する課金ユーザーが得る対価として「ステッカー」を用意する点です。
ステッカーは原価が低く、またクリエイター側が用意しなければならないものは既存作品をデザイン流用したイラストのみであり作成負荷が低く、またユーザーとしては課金の対価をファングッズとして得やすい点です。
つまりクリエイター側はファンへの対価になるサービス提供に忙殺されるという既存サービスにありがちなデメリットをつぶしやすいです。
事実上割高な買い物ではありますが、物品に対する月額販売サービスと言えるのがポイントです。
またアイドルのファンクラブを見るとわかるように「一度のみの販売で、古参ファンのみが持ち得る古参の証」はファンにとってのステータスです。
原則同じデザインの再販がないステッカーを作ることで「俺はこのクリエイターをxx年間支援してきた。にわかとは違う」という一種の優越感をファンに与えやすく、また「今ファンになっておかないと、あるデザインのステッカーを買い逃す」というタイムリミット設定型の買い煽りができます。

ターゲットとしていた市場だと一人の作家に対する熱心なファンの課金額は年額2,000~3,000円がボリュームゾーンでした。MAXでも6,000 ~8,000円を超えると急速にしぼんでいきます。
この層に対して更にプラスαの課金を求める場合対価になるサービスの質が求められます。
しかしそうなると「熱心なファン」の中の更に「高課金可能な一部のファン」がターゲットになります。
・彼らは数が少なく、課金額を非常に高く設定するに足るサービスを設定するか
・あるいは安価な課金を満足させる省省労力のサービスを設定するかの二択です。
トータルで見ると収益額の低い少数のファンを満足させるために、マスターゲットの本業より大きな労力を払うことは本末転倒です。
ステッカーの場合その年に出した代表的作品の表紙絵を流用することを前提としていました。
その場合
・流用なので省労力
・表紙絵から刊行時期がわかるため、いつ頃からファンかが分かる
　・ファンコミュニティにおいて重要な古参ファンアピールになる
　・二度と手に入らない点がはっきりする
というメリットと訴求点があります。
また安価で簡易なステッカーをフックとして、そこから高額かつ少数のファンクラブ限定直販でアップセルを稼ぐというプランでした。
ファンクラブにおける古参ファンアピールが有効なのは既存のアイドルのファンクラブ制度を参考にしました。

ただし当時はBOOTHにおいてBOOSTという、「購入時にさらに支払額を任意に増やすことでクリエイター支援ができる」というシステムでfantiaやentyに対抗するという計画だったためサービスの重複を嫌ってボツりました。
ターゲットもユースケースも違うので重複はしないと考えたのですが経営判断なので覆せず、です。
（追記：pixiv fanboxという月額500円のサービスが後に出たようです。）

プロダクトオーナーの異常な雑用 または私は如何にしてプログラムするのを止めて雑用をするようになったか

タイトルについて

映画のパロディです。
ジョニーの凱旋が流れるシーンが好きです。

私の担当

チームにおける私の配置は

• プロダクトオーナー
• チーフエンジニア
• 雑用係

の３つです

経緯

私は業務外でゲーム開発チームを運営しています。
役割分担は「システム」「シナリオ」「デザイン」の３人でした。
ひとまず開発が落ち着いた段階で、製品そのものはゲーム性を備えたので、販売を強化しようということになりました。
すなわち、販売強化に関わるタスクを誰かが受け持つ必要がありました。新しく人とかまだ雇えないし。
この時点でデザインさんは投入可能時間と要求作業量が均衡しており、新しいタスクは振れません。
シナリオとシステム、どちらが作業したほうがゲームのプロダクト価値をあげられるか、と考えた時、データ分析から、明らかにシナリオ量のほうがユーザーに訴求することが明らかでした。また、ゲームシステム開発はひと段落し、新たにシナリオスクリプトを投入すればほぼ追加開発がなくてもゲームリリースが回る状態になっており、システムのタスク需要が大きくなかった、という判断から、システム担当がシステム開発の時間を削り、販売強化にまつわるタスクを受け持ちました。

販売強化is何

大きくあげると「マーケティング」「販売宣伝」「カスタマーサポート」「データ分析」「売上集計」「渉外ぜんぶ」に分化されます。
あとでイラスト絵などの「外注管理」も加わりました。

そのあとも「いま、誰の作業時間を"本業"に当てれば最もプロダクト価値が上がるか」は常にリリース単位で検査の対象となりました。結果は上下するものの、「最も価値に寄与しない」最下位と判断されたのは常にシステム担当でした。
こればかりは同じゲームエンジンを使いまわすというプロダクト戦略の都合上やむをえません。
そのため、私は常に「雑用係」を担当しました。

雑用と便宜上言っていますが、こうして並べると分かる通り、製品開発以外の「超重要な業務」です。ないとプロダクトとして機能しません。作って終わりではありませんから。ですので、私もかなり真面目に取り組みました。
特に、マーケティングと販売宣伝には注力し、１年間で売上８倍の売上を達成しました。

担当の基本

１人に複数の役割を振ってもいいですが、責任を持つ役割を同列の２人に振ってはなりません。常識です。コーラを飲んだらゲップが出るレベルの。(エッセンシャルスクラムにそう書いてあった)
そのため、雑用係は輪番制や共同担当制をしかず、常に私が受け持ってきました。

担当制

ながらく担当として一人に担当すると「強い責任感」と「ノウハウの蓄積」による高いパフォーマンスが期待できます。逆に「どうでもいい仕事」で邪魔をしてしまうと「自分は軽んじられている」と感じて"本業"にも"副業"にも責任感を感じられなくなります(出典：ピープルウェア)
メンバーを専門職として尊重し、"本業"に高い生産性を出させるためには、誰かが"落穂拾い"を引き受ける必要があります。今回の場合はそれがプロダクトオーナーである私の仕事でした。

自分が担当したことによる利益

その甲斐あって、２つの利益が得られました。
１つは他の担当を雑用から解放したことで、プロダクト価値に寄与するシナリオやデザインの生産性が常に上がり続けたこと。
もう１つは、プロダクトオーナーが雑用を行ったことでユーザーのニーズや考えていること、販売媒体が我々に期待すること、売れ線の把握などがそのまますぐにプロダクト戦略に反映されたことです。

インメモリ理論

コンピューターサイエンスのセオリーとして、記憶媒体のI/Oを行わず、高速なメモリ上のみのデータを使って計算を行うとスループットが向上します。
同様に担当間で情報をやりとりするより、一人の人間が別の担当として仕入れたノウハウを別の担当としてふるまうときに利用することで、高いスループットと強力なシナジー効果が得られました。今回のケースで言えば、「カスタマーサポートや渉外担当、データ担当」という外向きの担当とプロダクトオーナーを兼任していた点です。
もっというならプロダクトオーナーがシステム担当も兼ねていたので、システム側のギミック実装が極めてスムーズでした。

プロダクトオーナー＋エンジニア＋雑用係

この組み合わせが機能したのは、私が比較的企画よりのエンジニアだったこと(逆に言うとガチガチの技術よりではない)と、なんでも一通りこなせる「便利屋」的なスキルを備えていたことが影響していると思います。
経験としては楽しかったですし、新規事業とかやるときにはまたこういうことをやってもいいな、と思いました。

データを見る限り、私が雑用することでチーム全体のパフォーマンスは向上しています。
「誰の本業がプロダクト価値に寄与しているか？」は計測していてよかったと思いました。

悲しい現実

上ではかっこいいことを言っていますが、なにか「必要なタスク」があるとわかったとして、みんな自分の仕事に全力投球しているので、新しいタスク引き受ける余裕なんてないんですよ。
雑用振れるような新卒メンバーがいるのは大きい企業だけなんです。
ということは、そのタスクは誰かが(主に自分)引き受けなければいけなくて、そのためには本来予定にあったタスクを外すか、あるいはその新しく湧いたタスクを後回しにするかの二択をせまられるわけです。
その現実から目をそらして、「無理してでも両方やろう」とか言えないわけですよ。特にある程度以上のタスクサイズなら。
そこで腹をくくって現実を受け入れて、計画修正するのがプロダクトオーナーの仕事だと私は思ってます。

結論

プロダクトオーナーならチームのために雑用とかやっても楽しいです。結果が出ている場合は特に。 。

プロダクトオーナーの異常な雑用 または私は如何にしてプログラムするのを止めて雑用をするようになったか

タイトルについて

チームにおける私の配置は

• プロダクトオーナー
• チーフエンジニア
• 雑用係

の３つです

経緯

私は業務外でゲーム開発チームを運営しています。
役割分担は「システム」「シナリオ」「デザイン」の３人でした。
ひとまず開発が落ち着いた段階で、製品そのものはゲーム性を備えたので、販売を強化しようということになりました。
すなわち、販売強化に関わるタスクを誰かが受け持つ必要がありました。新しく人とかまだ雇えないし。
この時点でデザインさんは投入可能時間と要求作業量が均衡しており、新しいタスクは振れません。
シナリオとシステム、どちらが作業したほうがゲームのプロダクト価値をあげられるか、と考えた時、データ分析から、明らかにシナリオ量のほうがユーザーに訴求することが明らかでした。また、ゲームシステム開発はひと段落し、新たにシナリオスクリプトを投入すればほぼ追加開発がなくてもゲームリリースが回る状態になっており、システムのタスク需要が大きくなかった、という判断から、システム担当がシステム開発の時間を削り、販売強化にまつわるタスクを受け持ちました。

販売強化is何

大きくあげると「マーケティング」「販売宣伝」「カスタマーサポート」「データ分析」「売上集計」「渉外ぜんぶ」に分化されます。
あとでイラスト絵などの「外注管理」も加わりました。

そのあとも「いま、誰の作業時間を"本業"に当てれば最もプロダクト価値が上がるか」は常にリリース単位で検査の対象となりました。結果は上下するものの、「最も価値に寄与しない」最下位と判断されたのは常にシステム担当でした。
こればかりは同じゲームエンジンを使いまわすというプロダクト戦略の都合上やむをえません。
そのため、私は常に「雑用係」を担当しました。

担当の基本

１人に複数の役割を振ってもいいですが、責任を持つ役割を同列の２人に振ってはなりません。常識です。コーラを飲んだらゲップが出るレベルの。(エッセンシャルスクラムにそう書いてあった)
そのため、雑用係は輪番制や共同担当制をしかず、常に私が受け持ってきました。

担当制

ながらく担当として一人に担当すると「強い責任感」と「ノウハウの蓄積」による高いパフォーマンスが期待できます。逆に「どうでもいい仕事」で邪魔をしてしまうと「自分は軽んじられている」と感じて"本業"にも"副業"にも責任感を感じられなくなります(出典：ピープルウェア)
メンバーを専門職として尊重し、"本業"に高い生産性を出させるためには、誰かが"落穂拾い"を引き受ける必要があります。今回の場合はそれがプロダクトオーナーである私の仕事でした。

自分が担当したことによる利益

その甲斐あって、２つの利益が得られました。
１つは他の担当を雑用から解放したことで、プロダクト価値に寄与するシナリオやデザインの生産性が常に上がり続けたこと。
もう１つは、プロダクトオーナーが雑用を行ったことでユーザーのニーズや考えていること、販売媒体が我々に期待すること、売れ線の把握などがそのまますぐにプロダクト戦略に反映されたことです。

インメモリ理論

コンピューターサイエンスのセオリーとして、記憶媒体のI/Oを行わず、高速なメモリ上のみのデータを使って計算を行うとスループットが向上します。
同様に担当間で情報をやりとりするより、一人の人間が別の担当として仕入れたノウハウを別の担当としてふるまうときに利用することで、高いスループットと強力なシナジー効果が得られました。今回のケースで言えば、「カスタマーサポートや渉外担当、データ担当」という外向きの担当とプロダクトオーナーを兼任していた点です。
もっというならプロダクトオーナーがシステム担当も兼ねていたので、システム側のギミック実装が極めてスムーズでした。

プロダクトオーナー＋エンジニア＋雑用係

この組み合わせが機能したのは、私が比較的企画よりのエンジニアだったこと(逆に言うとガチガチの技術よりではない)と、なんでも一通りこなせる「便利屋」的なスキルを備えていたことが影響していると思います。
経験としては楽しかったですし、新規事業とかやるときにはまたこういうことをやってもいいな、と思いました。

データを見る限り、私が雑用することでチーム全体のパフォーマンスは向上しています。
「誰の本業がプロダクト価値に寄与しているか？」は計測していてよかったと思いました。

結論

プロダクトオーナーならチームのために雑用とかやっても楽しいです。

チーム用チャットにサマリーKPI通知bot作ってみた

Advent Calendar

この記事はProduct Owner Advent Calendarの３日目です。 Product Owner Advent Calendar 2015 - Qiita

挨拶

こんにちは、瀬宮です。 プロダクトオーナーの役割の１つとして、チームをまとめ、市場的成功のために努力するというものがあります。 今回はチームメンバーの意識をまとめ市場的成功のほうを向かせる努力をした話をします。

やったこと

他社のチャットで定期的にプロダクトのサマリーデータを通知するbotがいて、便利そうだったので自分のプロジェクトでも実際に作ってみました。
このbotはチーム向けチャットに自動でつぶやきます。
チャットに載せる情報はチームメンバー向けです。

注意

この記事ではbotの実装には触れません。 hubotで作った系列と直接Slack APIを叩く系列があります。

botにデータを流させることで達成したいこと

• 数値をもとにした行動の改善
• 自分を含むゲーム開発メンバーの士気の向上
• プロダクトの市場反応の監視
• 市場反応の異常値の検知

やったこと

上の４つの目標を達成するために、botを作成し、チャットで色々話させてみました

数値を選ぶ上で

数値を選ぶ基準はだいたい以下の通り

数値が変化すること

滅多に動かない数値を取っても何もできません。

わかると嬉しいこと

その数値がわかることで、なにか嬉しいことがなければいけなません。
特に何かに使うあてもないが、重要そうだから、では数値はとりませんでした。
上の目的に沿わない数字はとりませんでした

数値をもとにアクションを取れること

取った数字をもとにアクションを取れる数字を取りましたた。
アクションにつなげづらいものは後回し＝とりませんでした

わかったこと

botを作ってわかったこと

時間

botがつぶやくのは朝の９時頃がよいです。
一気にやる気が上がるし、今日も１日がんばるぞい感が出ます。
ユーザーの購入は夜中心です。朝だと販売の伸びが一段落していて１日の売上の確報感があります。
逆に夜は売上実績の数字が上がっている最中で、確報感がありません。夜に出そうとするのは良くなかったです。

数値を多数出すのは良くない

出ている数値が多いと、知りたいことを知るためにそれが分かる数値を探すが、それが「ウォーリーを探せ」状態になるからよくなかったです。
チャット上の発言だと特に探しづらいです。
また、各人がその数値の群れからそれぞれ「各人が見たい情報」を拾ってしまう(もっというと、見たいものを見たいように見てしまう)ので、共通の見解が得られないです。
多くの数値を載せることはMTG資料ならそれでもいいですが、チャットの速報は天気予報のように、「短期間で短期的な現状をさっとわかるようにすること」が目的なので今回は避けました。

数値は絞る

各位に「知らせたいこと」をもとに数値をピックアップします。
現状を的確に表す情報は、週報を出すより、日報で出した方がよいです。
必要なら時報でもありです。
逆に多数の数値を並べても景気付け以上の意味はなく、逆に前述のマイナス効果が強くでました。

数値は変える

発売直後と発売一ヶ月後だと数字の伸びがまったく違います。
我々の場合、発売初週で売上の過半を出すので、必然的に時間が経つと日毎売上が萎れていく様が明示されてしまいます。
士気を上げるために景気の良い数値を見せたいので、発売直後は１日ごとの販売数を、販売から期間が経ったら累計数と前作同時期比を表示します。

市場反応にメンバーの興味を向ける

メンバーが数値を毎日目に向けるようになり違いにすぐ気付くようになって、プロダクトと市場反応の関係に興味を示します。
つまりメンバーがユーザー目線を持ち、「このプロダクトは売れるか？」を気にするようになります。

見せる数値は絞るけど裏で貯める

絞っているだけで、想定された事態が惹起されたときに分析するための数値は貯めておきます。
ログそのものは残っていても、何かあったときにそれを取り直すのは面倒があります。
面倒があると「面倒くさいからいいや」になってしまいます。

異常時は知らせる

異常時、つまり急な売上の上昇や沈滞などの事態には、botがメンションを飛ばし「これはヤバイ」感を示す必要があります。
グッドニュースなら祭り感が出るし、バッドニュースなら連携して解決しよう感が出ます。

botを作ってよかったこと

数字を見たチームメンバーから改善案が出たこと

「売上が初週以降すぐ落ちる、パッケージとマーケティングがいけないのではないか」
というような提案がよく出るようになりました。

チームメンバーの意識の変化

常に数字を見せるため最終的な市場での実績をゴールだと考えるようになりました
チームメンバーが製品の開発だけでなく売上のことまで考えてくれるようになりました

酒が美味くなった。

「今回は成功したか？」「前回に比べてどれくらい成功したか？」が明確に分かります。
明確に分かるから、メンバーは、リリース時ではなく、販売直後の販売実績速報値を見て祝杯をあげるようになりました。
このときに気持ちよく酒を飲みたいために、「リリースまでの開発的成功」から「販売の市場的成功」に強い責任を感じるようにマインドが変わりました。

結論

俺たちは登り始めたばかりだ、このチャット用bot実装坂をよう

プロダクトオーナー祭り2015でベストスピーカー賞をいただきました

11/28のプロダクトオーナー祭り2015でベストスピーカー賞をいただきました
gloops様会場提供、日本のプロダクトオーナー会の最先端を突っ走っている関満徳様のPOStudy主催の大規模イベントで、企画が本業でない私がベストスピーカー賞をいただけた点は感謝の極みです。
プロダクトオーナー祭り2015 ～世界を変えるのは俺たちだ！～ - POStudy ～プロダクトオーナーシップ勉強会～ | Doorkeeper

今後ともユーザー目線、市場目線でプロダクトオーナー＋エンジニアの両輪の視点を持ちつつ頑張っていこうと思います。

業務外での活動ということで、社外秘密もなく自分が考えたことを生々しいほどに書きました。
綺麗事ではない課金とゲーム性の両立、ぜひ読み取っていただければ幸いです。

ユーザーの時間軸を含めたプロダクトデザイン from Shin Semiya

www.slideshare.net

なお、ワークショップ部門トップはヤフーの伊藤さんでした。卒業すると認定メトリクススペシャリストがもらえるそうです。我々のチーム The 苦労人's は全員が受託開発経験者かつ「品質」のSQiPなどの活動を認知しているというハイコンテクストなチームだったので話が素早くまとまりました。 メトリクスによる「見える化」のススメ:No 見える化、No 改善

カスタマージャーニーマップの作り方

会社でカスタマージャーニーの話が出ていたのでちょっとここに書く。
カスタマージャーニーについて悩んでいた彼がここを見るかもしれないし見ないかもしれない。
もし見たのなら助けになればいいと思う。
あくまで私の一見解であるので特に勧めたりはしない。
また一見解であるので、真に受けて痛い目みても責任は取れない。

本題

さて、私はカスタマージャーニーとはUX設計の一手法だと思っている。

ここにAirBnbのカスタマージャーニーの図があるんだが、これはわかりやすい。
ただしわかっている人間にとっては。
わかっていない人間にとっては非常に誤解しやすい図だと思っている。

ドツボにはまるケース

わかっていない人間は手続き的にユーザーの動作を列挙しようとしてドツボにハマる。
つまり行動を列挙し、それにともなう感情を付け加え、最後に書き連ねた内容を総括して「結局ユーザーは何をしたい？」を書く。
順番として 行動 > 感情 > 目的の順番でまとめようとする。そしてドツボにはまる。

ドツボにはまらないケース

順番として 目的 > 感情 > 行動の順番でまとめる。話は結論から始まる。論文を書くときに Conclusion comes first って習うでしょう？

AirBnbがシンプルなのはあれを利用したい人間にとっては(少なくとも初回は)楽天トラベルやじゃらんと同じサービスだ。
つまり、旅をしたいときに、金を払って泊めてくれる宿泊先を探すサービス。
目的が明確。

どうフェーズに分解するか？

ユーザーは旅行先での宿泊先を探したいのだ
より分解するなら

• 宿泊先を１つに絞りたい
• 宿泊先オーナーと交渉し契約を成立させたい
• 当日に宿泊先に移動したい
• 利用後に宿泊先を評価したい

となり、それぞれにモチベーションと不安が存在する。
それぞれをフェーズとして分解する

ここで注意すべきなのは最後の「利用後に宿泊先を評価したい」はユーザーが先天的に持ち得る感情ではないため、後天的に動機付けすることで行わせる必要がある。

カスタマージャーニーではフェーズごとに何を書く？

モチベーション実現(あるいは不安解消)に伴うユーザーの感情を列挙し、感情に伴うそれぞれの行動を列挙する

感情とは？

宿泊先を選定するにあたり利用者が抱くであろう感情を列挙する

• 宿はどんな感じの部屋？(興味)
• 交通利便性は？(興味)
• お値段は？(興味)
• 宿は写真通りの快適そうな場所か？(不安)
• オーナーは悪党ではないか？(不安)

感情欄に上の感情を書き過度に下がりすぎないようにする
過度に下がると離脱するから。

行動とは？

上記の感情を解決するためのもの。
インサイトにアバウトな解決の方針を書く。
インサイトの方針に沿って実装方針を後で決めることにする(別にカスタマージャーニーマップ内で決める必要はない)
AirBnbで実装された内容はこんな感じ。

• 部屋や建物の写真の掲載
• 地図の表示
• 総額及び内訳表示の終え弾表
• レビューの掲載、貸切かについての部屋タイプ表示
• オーナーの顔写真と素性掲載

ところで上にあるペルソナってなんぞ

ペルソナはユーザーの代表的な属性を書いたもの。
モチベーション、あるいは感情のレベルで「同じ」と判断できるものについてはまとめる。
「同じではないもの」についてはまとめずにペルソナを分ける。

アンチパターン

年齢を10代、20代、30代、40代。性別を男性、女性。家族を独身、既婚でマトリックス化しようとする。
それは目的や感情に影響するか？しないなら無駄だ。いますぐやめろ。

分けるって具体的には

例えば移動手段を選ぶとき
「時間と体力はあるがお金のない学生」は安いがしんどい深夜バスを好む
「時間と体力はないがお金はある老夫婦」は高くても快適な飛行機や新幹線を好む。

AirBnb的に考えるなら

「初めての海外旅行の日本人」は比較的値段が高くても表通りに面した、親切なオーナーの治安が良く清潔な宿泊先を好むだろう
「旅慣れた外国人のバックパッカー」ならば裏通りの、尼崎や西成みたいな比較的下町(婉曲的な表現)の安いドヤ宿や簡易宿泊所のような場所でもよいだろう。

独身男性なら相部屋二段ベッドのシェアでもよいだろうが、小さい子供連れのファミリーなら一戸建て貸切の宿泊先を好むだろう。

このように大きいレベルの目的は同じでも求めているものが違う、感情が異なる、あるいは対象選定の評価基準が異なるユーザーはペルソナを分けたほうがいい。
これらを一緒にして扱うことは、どちらに対しても親切でないごちゃごちゃとしたサービスをつくることにつながる。

ペルソナは適切な分割を必要とするが、どの粒度で分割するかについてはケースバイケースである。
最初は３パターンくらいで作るのがよいかもしれない。
ただし、ヤフオクやメルカリみたいなサイトを分析するならなら「よい買い手」と「よい売り手」のような「ユーザーの最小構成」は作っておく必要がある。

カスタマージャーニーマップとはなにか？

ユーザーは大目的においては共通である。(AirBnbなら旅をしたいときに、金を払って泊めてくれる宿泊先を探す)
しかしペルソナ単位で実際に手に入れたいもの、満たしたい感情や求めている機能は異なる。

ペルソナごとに以下のことを行うことが目的である。

• ユーザーの行動段階に即してフェーズ分けし、ユーザーの段階単位の小目的を定義することこと
• ユーザーの感情に沿って行動を定義することでユーザーエクスペリエンスを設計すること
• サービスには必要だが、本来ユーザーが取りたがらない行動を明確化させ、動機付けの設計を行わせること

またそれらを行うことで以下の利益がある

• UXの設計が行えることで高いユーザービリティを確保できる
• ユーザーの離脱動機が見えるためKPIの設定がしやすい
• ユーザー動線が明確なため、動線単位で設計変更がしやすい
• 離脱率を低下させる

これだけは覚えておいてください

カスタマージャーニーマップ＝ユーザーの求めるものに合わせてUXを設計するための手法。