Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,725 views

Published on

ユーザーの時間軸を含めたプロダクトデザイン
プロダクトマネージャーを始めたエンジニア
ユーザーを時間を通じて成長させようとしたときに考えていること

Published in: Engineering

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

  1. 1. 時間軸を含めた プロダクトデザイン -エンジニアがプロダクトマネージャーとして 0からゲームを作ったときに考えたこと-
  2. 2. テーマは成長 出典:マッドマックス
  3. 3. 自己紹介 お仕事  某Webサービスの開発  新機能とか新サービスとか 仕事以外  ゲーム開発  PC向けインディーズゲーム    年販x,000本くらい
  4. 4. 今日する話
  5. 5. エンジニアが
  6. 6. プロダクトマネージャー を経験してわかった
  7. 7. 成長の物語 ジョジョSBR
  8. 8. 人は成長する
  9. 9. マネージャーとして ユーザーとして
  10. 10. 持ち帰って欲しいこと
  11. 11. どうやって人を 成長させるか?
  12. 12. 注意その1
  13. 13. ゲーム制作は プライベートの 時間の話です
  14. 14. 会社は関係ありません
  15. 15. (ほかに行くなら 今のうち)
  16. 16. 注意その2
  17. 17. 直裁的な話し方をします
  18. 18. だって
  19. 19. プロダクトの定義は 遊びじゃない 出典:カイジ
  20. 20. そもそも
  21. 21. 私=エンジニア
  22. 22. なぜエンジニアが プロダクトマネージャー に興味を?
  23. 23.
  24. 24. 超失敗した
  25. 25. ある予算億超えのプロジェクト
  26. 26. 俺、超頑張った
  27. 27. プロジェクトを大改革 スクラム導入 生産効率を10倍以上に
  28. 28. 奇跡の大前進 少ないリソース 大きな仕事
  29. 29. 無事リリース!
  30. 30. 俺は思った
  31. 31. 俺がヒーローだ!
  32. 32. しかし?
  33. 33. 俺はヒーローではない
  34. 34. なぜ?
  35. 35. 生産性は10倍になったが 利益は10倍にならなかった
  36. 36. つまらん
  37. 37. やはりプロダクトは ヒットしてこそ楽しい 出典:カイジ
  38. 38. 俺は思った
  39. 39. プロジェクトには 2つの面がある
  40. 40. HITする製品を定義する 定義された製品をリリースする
  41. 41. HITする製品を定義する 定義された製品をリリースする 今回頑張ったのはこっち
  42. 42. HITする製品を定義する 定義された製品をリリースする こっちに興味がなさすぎた
  43. 43. Scrumの源流
  44. 44. トヨタ式生産方式 の中にこうある
  45. 45. 自動車開発では ユーザーの期待を 理解している人間に 部品設計を担当させろ
  46. 46. 我々の言葉に直すと?
  47. 47. サービスの開発チームの メンバーは ユーザーの期待を理解している 人間でなければならない
  48. 48. ユーザーの期待
  49. 49. 知らんな
  50. 50. よっしゃ学ぼう
  51. 51. 座学+経験だ
  52. 52. 俺がプロダクトマネージャーだ!
  53. 53. HITする製品を定義する 定義された製品をリリースする ここをやってみよう
  54. 54. ということで 自分でサービス つくった
  55. 55. ゲーム
  56. 56. 1作目の開発開始 そして2年
  57. 57. 3つの役割を担当 プロダクトマネージャー 開発リード UXデザイナー
  58. 58. 担当しなかった デザイン シナリオ ゲームデザイン
  59. 59. 2年間の経験から 語る
  60. 60. UX再考
  61. 61. UX is 何?
  62. 62. 世間の理解 UX = スタバ UX = iPhone
  63. 63. オサレなのがUX?
  64. 64. 違う、そうじゃない
  65. 65. 私のUXの理解 ユーザーが「期待したもの」を得るために コストを投下して、行動を起こし 最終的に「期待したもの」「予想外のもの」を 獲得するまでの一連の流れ
  66. 66. UXとユーザビリティ
  67. 67. 私のユーザビリティの理解 期待したものを獲得するためのコストに 対する効率=ユーザービリティ その背景にあるユーザーがコストを払ってでも 得たいものがDesire
  68. 68. 種本
  69. 69. UXとユーザビリティ
  70. 70. 背景には ユーザーの 心理+欲求+行動
  71. 71. それらをデザインするのが マインドデザイン
  72. 72. マインドデザイン
  73. 73. マインドデザイン is 何
  74. 74. マインドデザイン 旧来のビジュアル面と異なる、最近注目 され始めた心理学的な面のサービスデザイン。 ユーザーの「興味」「感情」「欲求」を デザインする。
  75. 75. ビジュアルデザイン 美術的なデザイン マインドデザイン 心理的なデザイン
  76. 76. 別物
  77. 77. マインドデザイン 作り方
  78. 78. ユーザビリティ= ユーザーのコスパの良さ
  79. 79.   ユーザーが得た期待した価値   + ユーザーが得た予想外の価値 ユーザーが投下したコスト ユーザビリティ=
  80. 80. ユーザーは 1.欲しいものを見つける 2.入手する方法を見つける 3.入手のために行動を起こす 4.その過程でコストを払う 5.欲しいものを入手する
  81. 81. この流れの設計が UXデザイン
  82. 82. 一例
  83. 83. ユーザー=小学生
  84. 84. 一人で遠出したい 歩きでは遠くに行けない 自動車は大人の助けがいる
  85. 85. そうだ、自転車だ 自転車に乗りたい
  86. 86. 「遠出」は目的 「自転車」は手段
  87. 87. 我々は  遠出をしたい子供に  自転車を売る
  88. 88. ユーザーのマインドの 経時変化
  89. 89. ユーザーは 経験により 能力を獲得する
  90. 90. 能力によってユーザーの やりたいことはかわる
  91. 91. ユーザーは 新しく手に入れた能力 を試したい
  92. 92. 「自転車に乗れる」 =能力の獲得
  93. 93. 「遠出をしたい」から どこまで遠くに行けるか 試したい
  94. 94. つまりこれが
  95. 95. 夏休みに小学生が隣町で 保護されるメカニズム
  96. 96. ユーザーは経験や達成をへて マインドが変化する マインドが変化すれば 求めるものが変化する
  97. 97. マインドの変化
  98. 98. サービスを 始めたばかりの ユーザーの特徴
  99. 99. 受動 低稼働 受信 無課金 地味
  100. 100. サービスを 使って欲しい ユーザーの特徴
  101. 101. 能動 高稼働 発信 高課金 活発
  102. 102. ユーザーを 成長させたい
  103. 103. ユーザー ライト→ヘビー
  104. 104. マインドセットと 目的の変化が重要
  105. 105. ユーザーの「成長」を促す 最初の段階ではユーザーが 唯一払ってくれるものは「時間」 お金やコミット、投稿は得られない。 そこは期待しない。
  106. 106. 無課金から課金へ
  107. 107. お金を払って欲しい
  108. 108. だからこうやる
  109. 109. 出典:カイジ
  110. 110. 結果 出典:カイジ
  111. 111. 「もっともっと!」
  112. 112. こうなれば 完璧 (いい笑顔)
  113. 113. この段階でようやく お金や投稿が期待できる
  114. 114. 課金にはユーザーの サービスへの 「高い期待」が必要
  115. 115. 「高い期待」   サービス内の「資産」   サービスへの「のめり込み」
  116. 116. これを作ればいい
  117. 117. しかしまずは 始めさせねば
  118. 118. 期待と不安の マネジメント
  119. 119. ユーザーに 明確に伝えたいこと
  120. 120. このサービスを利用した時に 「得られるもの」 と 「支払うべきもの」
  121. 121. 「得られるもの」 「支払うもの」 明確にイメージ可能なもの
  122. 122. ふわふわした言葉は 刺さらない
  123. 123. もう一つ
  124. 124. 不安を取り除くこと
  125. 125. 実例
  126. 126. 私の今度の新作 ゲームは こんな感じ
  127. 127. 大略奪!スマッシュ大蛮族 今なら ¥1,000 岩明均 ヘウレーカ
  128. 128. 裏面はこんな感じ Civ5
  129. 129. ユーザーの印象
  130. 130. だいたい中身を イメージできる
  131. 131. イメージ重要
  132. 132. 不安 うちのPCで動く? OS? スペック? タブレットだと?
  133. 133. 決意 よっしゃ買うぜ 俺もヒャッハーする!
  134. 134. OK、売るのはわかった
  135. 135. だがこれだけだと リピートしない
  136. 136. 新規客が来るけど 定着しない
  137. 137. だから
  138. 138. 次に
  139. 139. 購入後のユーザーの マインドのデザイン について
  140. 140. 2年回してわかった ゲームの ユーザー分析によると
  141. 141. 序盤のユーザー
  142. 142. 「壊す!」「楽しい!」 「奪う!」「楽しい!」
  143. 143. 単純で即物的な 快楽に価値を見出す
  144. 144. こんな感じ
  145. 145. この状態では 課金やリピートは 期待できない
  146. 146. 大味ですぐ飽きるから
  147. 147. ハマったユーザー
  148. 148. 考えるの楽しい!
  149. 149. 「都市防衛戦略」 「外交戦略」 「内政経済の整備」
  150. 150. 複雑で戦略的による 成功に価値を見出す
  151. 151. 財産と実力と戦略で 相手を圧倒する
  152. 152. こういうの
  153. 153. ユーザーはサービス内の資産 (友達、資産、地位) を守り、増やすためなら 課金や長時間プレイを惜しまない
  154. 154. この状態だと 廃課金、重リピート が期待できる
  155. 155. なかなか飽きないから
  156. 156. この状態のユーザーを こういう
  157. 157. 信者
  158. 158. 売上、PV、ブーム それらのために
  159. 159. この状態のユーザーが ほしい
  160. 160. この状態のユーザーを 獲得するための
  161. 161. ゲームデザイン
  162. 162. ゲーム中に登場する 陣営は味方と敵に 分けられる
  163. 163. 敵勢力や敵ユニットは 一定条件で味方にする ことができる
  164. 164. ユーザーは勝利のために 資源を求めて行動する 陣取り形式で重要な地形や資源を 確保すると有利になる
  165. 165. ユーザーは味方陣営のために 相手から資源や財産を奪う 逆に脅威や不幸を実力で 相手に押し付けることができる
  166. 166. 背景にある快楽の設計 「下位の存在の庇護、供与、所有化」 「敵対者の抑圧、蹂躙、強制」 いずれも人間の支配欲求を 強烈に刺激する
  167. 167. 支配欲求の刺激 ゲームの売り
  168. 168. 序盤の快楽の設計
  169. 169. ユーザーは最初は「壊す、奪う」という 単純な行為に快楽を見出す ユーザーに訴求するもの 「楽しさ」=「壊してスカッとする」 わかりやすく単純な物。
  170. 170. そのために 「目の前に見えた物にユニットを 当てて壊す」 という単純なUXを経験する。
  171. 171. 高いユーザビリティ= それなりの快感 小さなコスト
  172. 172. これがゲーム後半に いくにつれて
  173. 173. 後半の快楽の設計
  174. 174. 後半を楽しむユーザーのマインドは 「自分の支配欲求を満たす」 ことに快楽を見出す
  175. 175. 後半のユーザーに訴求する楽しさとは 「自分の民衆の庇護」 「民衆の進歩」 「外敵からの防御の計画作り」 という複雑で戦略性のあるもの。
  176. 176. そのために 「資源を傾斜して分配し」 「各種行動のために消費し」 「さらに発展を獲得する」 という複雑なUXを経験する。
  177. 177. つまり客観的には 「自分の支配欲求を満足させる」 ために 「多大なコストを支払っている」
  178. 178. 支払うコストは大きいが、 ユーザーが主観的に得られる 満足感は絶大なため ユーザビリティは高く見える。
  179. 179. ん?
  180. 180. 快楽設計?
  181. 181. なんで難しいことを?
  182. 182. 高い生産性が 欲しいから
  183. 183. 開発チームから 高い生産性を 得るために
  184. 184. プロダクトマネージャーは 製品を定義し 方向性を示し 細部の裁量は現場に任せる
  185. 185. 「最終的にこれをやりたい」 を示すことで実装との ブレを少なくするには
  186. 186. ゲームプレイを通して 「ユーザーが得られる快楽」 「ユーザーが支払うコスト」
  187. 187. を提示するのが 一番効率が高かった
  188. 188. そうすると
  189. 189. テストプレイによる ユーザビリティの品質担保 もとても楽になる
  190. 190. チェックする 判断基準は3つ
  191. 191. このゲーム内の行動で ユーザーは
  192. 192. 想定した通り快楽を得られるか (過小なリターンでないか)
  193. 193. 想定値のコストしか払わないか (過大なコストでないか?)
  194. 194. 想定値のユーザビリティを 確保できているか (ユーザビリティは低下していないか)
  195. 195. この3つで
  196. 196. 設計した通りの快楽と ユーザビリティが 実装されたか を検証可能になる
  197. 197. ほかに 非推奨の行動をとらないか 機能に気づくか どこかで詰まないか もUXレベルでチェックする
  198. 198. 検証したいこと
  199. 199. ゲームが与える 快楽の誘導
  200. 200. ユーザビリティの 高さの維持
  201. 201. 高いユーザビリティの 維持がないと ユーザーが離脱する
  202. 202. つまり序盤から複雑な プレイを要求すると ユーザーは離脱する
  203. 203. これをWebサービス でも言えること
  204. 204. 無料ユーザー 「壊す!」「奪う!」
  205. 205.   それなりのリターン すくないコスト (無料、カジュアル) ユーザビリティ=
  206. 206. ヘビーユーザー 天才的な高度な戦略による 芸術的勝利だ!
  207. 207.   絶大なリターン 大きなコスト (課金、廃人) ユーザビリティ=
  208. 208. 「ライトな入り口」 高ユーザビリティ維持 「課金の促進」
  209. 209. すべての並立
  210. 210. 覚悟はいいか
  211. 211. よくできた例
  212. 212. 最初は
  213. 213. 「女の子かわいい」 「携帯で無料なら」
  214. 214. 次第に
  215. 215. 「課金でマラソン」 「あと100位で報酬が」
  216. 216. よく調教された ユーザー
  217. 217. 「プロダクション戦!」 「推しメンに通帳を 捧げよ!」
  218. 218. よくできたサービス の定義 とは?
  219. 219. 流れがデザイン されている
  220. 220. 「ちょっとした火遊び」 から
  221. 221. 「首まで泥沼」まで
  222. 222. まだ時間ある?
  223. 223. ゲームの売上に 一番貢献したもの
  224. 224. 優れた製品の定義?
  225. 225. 開発の効率?
  226. 226. 優れたゲーム性?
  227. 227. マーケティング
  228. 228. 同一の商品でも タイミングと露出場所 で売上が大きく変わる
  229. 229. 中の人は製品の魅力を ホワイトボックス的に 知り尽くしているが
  230. 230. 新規客とはあなたと あなたの商品を何も知らないし 興味もない客のこと
  231. 231. 短い時間、効果的なタイミングで 製品に興味を持たせる方法が必要
  232. 232. マーケティングの 改善が新規売上には 最も寄与した
  233. 233. 製品を作ってから 売り方を考えるのは 頭が悪すぎる
  234. 234. 「知らない人」に なんといって買わせる?
  235. 235. マーケは最初の 段階で入れないと 効果を発揮しない
  236. 236. 次?
  237. 237. ではシナリオ
  238. 238. シナリオさんとの 私の付き合い方
  239. 239. ではシナリオさんの マインド変化
  240. 240. 最初は
  241. 241. 1KB 1,000円で お願いします
  242. 242. という契約
  243. 243. 相手から質問
  244. 244. 「こういう演出したい」 「何かギミックは?」
  245. 245. 私から回答
  246. 246. 「工数確保するので そちらのプランで指定 して大丈夫です」
  247. 247. シナリオさん 演出のフラグ構成 頑張る
  248. 248. そしてゲーム売れる
  249. 249. シナリオさんに再度 仕事を依頼
  250. 250. 演出仕様も任せる
  251. 251. すると
  252. 252. 前回あれが評判 よかったから今回は これも入れたい
  253. 253. シナリオさん張り切る
  254. 254. 彼のマインドは
  255. 255. 「金で請けた仕事」 から
  256. 256. 俺がヒットさせた ゲームの仕事
  257. 257. 俺の仕事
  258. 258. に変わりつつある
  259. 259. すると
  260. 260. 上がる生産効率
  261. 261. 続々と出てくる シナリオにあった演出
  262. 262. リーダーは 「全部オレのもの」 にしたがる
  263. 263. 「全部リーダーのもの」 リーダー以外にとっては 「他人のもの」
  264. 264. 逆に考えるんだ
  265. 265. あげちゃって もいいや と
  266. 266. 国営農場と個人農場 生産性の違い
  267. 267. Your Biz VS My Biz
  268. 268. 私にとっては
  269. 269. 例えば販売取引先
  270. 270. 「こいつどれくらい売れるの」 「販売条件はどれくらい?」 「在庫残ったりしない?」
  271. 271. 取引先もユーザーの 1つ 期待とコストと不安 をマネジメントする
  272. 272. 最後に自己紹介
  273. 273. あんただれ
  274. 274. レベル: しょくぎょう: しょうごう: 29 プログラマ はいぱーれがしー こーどくりえいた @shin_semiya ともうします
  275. 275. なにか質問が あればこの後に
  276. 276. 今日は最後まで おつきあいいただき ありがとうございます。
  277. 277. Thanks a lot !

×