開発効率とゲームの面白さをあげるために、私が同人ゲームのチーム開発でがんばった１０個くらいのこと

Transcript

• 1. 開発効率と ゲームの面白さをあげるため 私が同人ゲームのチーム開発で がんばった１０個くらいのこと
• 2. こんにちは
• 3. 我々はプライベートで
• 4. ゲーム開発しています
• 5. 前回はゲームを 開発した話を しました
• 6. 我々のゲーム 売上好調
• 7. 最新作が秋葉原に並びました！
• 8. そして瞬殺！ 在庫が３日持ちませんでした
• 9. 売上好調というのは 最高に気分がよいです
• 10. 今日は
• 11. 開発のなかで 頑張ったこと
• 12. という話をします
• 13. 長いから
• 14. あらすじを４行で
• 15. 短期間で色々な機能を作りたい だから開発効率を上げたい あとゲームの面白さもあげたい そのため色々頑張ったよ！ という話です
• 16. 我々のチームの開発は
• 17. 当初はスクラムでした
• 18. ところが第２期開発で 売上や市場動向を 気にし始めました
• 19. 経営 + ソフト開発 が課題に
• 20. そういうのを リーンソフトウェア開発 っていうんだとか
• 21. リーンソフトウェア開発 Lean Software Dev
• 22. リーンソフトウェア開発 というのは 正直よく知らなかったけど
• 23. リーンソフトウェア開発 Lean Software Dev 略称がLSD
• 24. 最高にハイになれそう
• 25. リーンソフトウェア開発 は製品、市場アプローチと ともに開発体制の継続的改善に 言及している
• 26. 製品や市場の話は 前回やったから
• 27. 今回は
• 28. 開発体制の継続的改善 の話をしよう
• 29. 開発体制の改善の中で 今日は特に
• 30. 開発効率の上昇
• 31. という話をします
• 32. 開発効率の上昇
• 33. 最初に結論
• 34. 半年かけて
• 35. 行数ベースで 約３倍に上昇
• 36. ただしその後 ペース低下
• 37. 理由は簡単
• 38. 情報分析や販売宣伝 を頑張ったから 開発以外のタスクにリソースを割いたため 開発のアウトプットが低下した
• 39. ユーザーインパクト ベースで４倍 ただし目標セグメントの変更や 使用する指標の変更など 純粋に比較できない問題あり
• 40. やることは４つ 投入資源の増加 加速要因の増加 減速要因の排除 戦力の集中
• 41. 「投入資源の増加」
• 42. 投入資源の増加 資源 ＝ 時間 x 集中力
• 43. 人間の時間は有限 １週間＝７日 x 24時間。 これは絶対に増えない。
• 44. なぜ時間を投入できない？
• 45. 「忙しいから」 大多数の人間は常に忙しい。待っていても時間はできはしない。 プライベートな時間を使って開発する人間はどんな人間？ 暇すぎて時間を持て余している人間か？ そんなわけはない。 ではなぜプライベートな開発に時間を割けない？
• 46. 「優先順位が低い」 大多数の人間は他のことに時間を割いている ゲームがしたいしアニメが見たいし飲み会に行きたいし 恋人や友達とLINEしたいし、twitterを眺めていたいし 流行りの技術を追いかけたいし、ごろごろだらだらしたい
• 47. どうやって優先順位をあげるか 当人の中でその活動の優先順位をあげればよいか？ 大学時代に部活を強くするために真剣に考えたテーマ ほかの優先順位をあげてしまうイベントはいずれも「楽しい」 すなわちその行動をすることが「楽しい」と感じさせれば良い
• 48. 楽しく感じさせるために 情報分析体制を整えて、売上やユーザーに与えた ポジティブな効果を把握できるようにした。 「あなたが一ヶ月頑張って開発したこの機能は    これだけのユーザー反応につながりました。」 休日にタスク消化はやはりつらい。でも成果が見えると楽しい 逆にチームに必要なタスクだが成果が見えづらいとか 成功が怪しいタスクは自分の担当にした。 タスクのつらさ ＜ タスクの楽しさ になると投入時間が急速に増える
• 49. 集中力の問題 アメリカの研究で、仕事中にtwitterを過度に開いてしまうのは 仕事中のストレスが原因だと言われている (PTSDと同じ。耐えられないストレスから逃避を図る) タスクをこなす上でストレスを与える原因は できる限り排除できるようにした。
• 50. そしてどうなった？ みんな朝型になってアニメを見逃し始めた。 集中してタスクを消化すると疲れる。 疲れるから寝たい。「アニメは録画しているしいいや」で そのまま寝てしまう。 そのままアニメを消化しないまま翌週を迎える。 アニメの優先度が生活の中で下がり始めた。
• 51. きんモザ 今期のきんいろモザイク、シナリオ担当がリアルタイム視聴に 追い付いたのは５話から。ダンまちは４話から。 ニコニコの一斉放送も見逃す経験多数。 チームメンバーは重度のアニオタが多いにもかかわらず そういう事件が増え始めた。 チームの開発の優先度がメンバーの中で 上がり始めた証拠
• 52. 投入資源の増加 メンバーが時間を注ぎ始め 開発速度が上がり始めた
• 53. 「加速要因の増加」
• 54. メンバーは自分の 「興味がある」「やりたい」 タスクを実行させた時 最高のスピードとクオリティを 発揮する
• 55. 現状でユーザー反応のよい ゲームの機能はほぼ リリース２週間以内に発案され リリースまでに取り込まれた
• 56. メンバーが発案し自分から強く 提案してきたタスクに対して 私の回答は１つ
• 57. DO IT ! (やっちまいなー)
• 58. しかし
• 59. メンバーの提案をほいほい 受け入れることはゲームの開発を 混乱させないか？
• 60. それな
• 61. ゲームの開発が混乱するのは ゲームのコンセプトや 今回のリリースの方針とは 異なる「異物」が紛れ込んだ場合
• 62. だから
• 63. リリースごとに開発開始時について 以下のことを確認する プロダクトのゴール ビジョン、コンテクスト、戦略の 計画立案、確認、共有 今回のリリースのミッション 狙うセグメント、アプローチ方法 実現したい成果、達成目標
• 64. プロダクトのゴール リリースのミッション この２つからずれていない限りは基本的に認める この２つに沿う限り、ゲームの開発が大きくぶれることはない 各担当者は自分の担当範囲の専門家。 最大の知見と現場の空気感を有する。 彼らがやるべきだというのならそれは最善策。
• 65. 信頼と委任 「自分は信頼され、権利と責任を委譲されている」 そう考える担当者は120%のパフォーマンスを発揮する やばいときは最後まで踏ん張ろうとするし実装まで責任を持つ。 タスクにおける自分が考えた割合が多いほど、人は当事者意識を持つ
• 66. 信頼と委任 とても大事
• 67. 彼らは「待ち」を 駆逐する
• 68. 指示待ち、判断待ち 指示待ちや判断待ちは作業のリズムを乱し速度を低下させる原因 他人の作業を判断するためには判断させるための 情報を上げさせる必要がある。 ゲームのように選択肢があれば判断は容易だが 現実世界では選択肢を作ることまで含めてリーダーの仕事
• 69. ミッション志向マネジメント ドイツ生まれアメリカ育ちのトヨタ生産方式の従弟 上位者は下位者に「目的のみ」を指示し実施の手段については 委任する。下位者は裁量と統制の範囲内において目的達成のために 最善を尽くす。 手段の選択肢を考えるのは大量の情報とコストを必要とする。 目的はより抽象的であり選択肢を考えるのが容易。 目的のみしか指示しないため、上位者の判断に必要なコストが大幅に 削減され、上位者の負荷軽減と重要事項への集中、 判断のスピードの大幅改善が狙える
• 70. 大事なのはスピード 上位者は現場から情報を吸い上げ、それをもとに判断を下す しかし情報の吸い上げと判断に要する目的と手段の指示を下すまでの 決定コストは大規模になるほど肥大化し 決定が下されるまでのスピードが低下する ミッション志向マネジメントは下位者に手段の裁量を与えることで 上位者の決断に必要な情報量の削減とスピードの向上を狙う
• 71. ミッション志向マネジメント “大規模な行動を戦略とミッションに基づき各級現場マネージャーが 十分な裁量と主導性を持って、高速かつ柔軟な現場判断をもって　　 実行する。それにより常に競合の先手を打ち高速に事態を推移させ 全体の主導権を収め、常に優位にビジネスを進めることができる。” 「十分な裁量と主導性による高速かつ柔軟な現場判断」 「単一の戦略に基づき現場が柔軟に判断することで先手を打ち 主導権のもとに優位に進める。」
• 72. ミッション志向マネジメントが 必要とするメンバー像 自己組織化され 目的とミッションを共有し 十分な経験と知識を持つ人間
• 73. このクラスの人間を配置できれば 柔軟かつ高速な開発を 低いマネジメント負荷で 実現可能
• 74. 我々のチームは コアメンバー全員が アジャイルの知識と経験のあった のでこの条件を満たせていた
• 75. ４人程度のチームのリーダーが この条件を満たしていると マネジメントが格段に楽だった
• 76. ビジョンやゴールを示し 抽象的な指示を適度に行うだけで 細かい指示をしなくても チームは回りプロダクトが完成した
• 77. その間自分は問題発生している チームの面倒をみたり 新規設立したチームに リソースを割いた
• 78. これが最高によかった
• 79. 信頼と委任
• 80. そもそもなんで そんなこと考えた？
• 81. チーム設立当初から 開発効率の上昇は 狙っていた
• 82. ガンガン上がる 開発効率
• 83. しかし途中から
• 84. 自分がボトルネックに
• 85. なぜ？
• 86. 開発効率の上昇 is タスク消化速度の上昇
• 87. タスク消化速度の上昇 is マネジメントコストの増大
• 88. タスクあたりの マネジメントコストは同じ
• 89. 消化速度がn倍になれば マネジメントコストもn倍に なる。
• 90. そもそも
• 91. スクラムは頻繁な 見直しと変更が かかる
• 92. マネジメントコストが 高くつきやすい
• 93. さらに
• 94. 高い開発速度の維持のためには タスク粒度は細かく保つ 必要がある
• 95. かくなる上は
• 96. タスクあたりの マネジメントコストを 減らさなければ
• 97. そして考えた
• 98. どうせこの手の問題は 世界で私が初めて 当たるものではない
• 99. スタンフォード大の論文か アジャイル宣誓の17人の ブログ見れば載っているだろ
• 100. たぶん
• 101. ということで探した
• 102. あったよ 論文が！
• 103. ミッション志向マネジメント
• 104. 正直長い論文の中で 使えるのが２節だけとか 最近問題が発見されたとか いろいろあったけど
• 105. 論文はあったし役に立った
• 106. リーダーを配置できない場合は？
• 107. もちろんあるね
• 108. そのメンバーとは 期間、報酬と要求事項の Input, Outputを定めた 業務委託的な付き合い方をした
• 109. 「減速要因の排除」
• 110. やったことは２つ
• 111. タスク進行の高速道路化 レビューラリーの削減
• 112. タスク進行の高速道路化 レビューラリーの削減
• 113. ちょっと質問
• 114. 自動車で走る時 何kmまでスピードを出す？
• 115. 高速道路
• 116. 100 km ？ 80 km ？
• 117. ガンガン飛ばすよね
• 118. 続いて
• 119. 下町
• 120. 何 km 出せる？
• 121. 30 km？ 40 km ？
• 122. (このあたりでDM乱入)
• 123. 「え、なんで？」
• 124. 同じ自動車で走るだけでしょ？ スピードそんなに変わるのは おかしいじゃん
• 125. なぜ速度を落とすの？
• 126. (って詰められる)
• 127. 違いはどこにある？
• 128. 一本道 皆同じリズムで 走る 視界内に全体像 を捉えている 進行路が不明 速度が違うので リズムが乱れる 突発問題の リスク VS
• 129. つまり速度を高く 保つには
• 130. 明確なゴールと進路 高速で安定したリズム 割り込みタスクの排除
• 131. が必要
• 132. このあたり実は スクラムのアーティファクトを 真面目に運用する リードの割込排除が機能する が揃うと大体できる
• 133. この考え方は トヨタ生産方式の でかんしょ生産の排除 の項に詳しい
• 134. 「減速要因の排除」
• 135. タスク進行の高速道路化 レビューラリーの削減
• 136. 一例
• 137. シナリオ担当が脚本を作る システム担当に渡す システム担当が脚本をスクリプト化 ゲームに反映させ検証作業のため シナリオ担当に戻す
• 138. 変更、誤字、修正、 スクリプトのバグ が発生するたびに シナリオ担当とシステム担当の間を 脚本が何往復もする
• 139. そのたびに 待ち が発生して時間を空費する 最大の原因になっていた
• 140. しかし変更や修正を なくすことは現実的ではない 動かすことで発見が生まれるし フィードバックが得られる
• 141. だからラリーを なくすことにした
• 142. ラリーはレビューや ダブルチェックも 兼ねていた
• 143. ダブルチェックは 何のためにある？
• 144. 当人が気づかない事も 他人の眼なら気付くから
• 145. それなら当人が 気づけるようにすれば いいんだろ？
• 146. ゲームに脚本スクリプト 自動読込機能を実装 シナリオ担当が自分で スクリプトをかけるように
• 147. スクリプトはRuby製 必要なのは 変数組込, フラグ代入 if, sample くらい
• 148. スクリプトのエラー発生時に シナリオ担当が 自分でエラーを発見できる デバッグ機能 をゲームに組み込み
• 149. シナリオ担当が 自分でスクリプトを書いて 自分で検証作業できて 自分でエラーを見つけて 自分で変更、修正できるように 自己完結性を高めた
• 150. 単独って危なくない？
• 151. 工程が単独で 完結するようにした 検証と対策は別途やる
• 152. 他の人間も検証工程で チェックする 最悪の場合でも台詞が 一部でなくなるだけ というフェールセーフ化
• 153. ラリーの削減 リズムが崩れない 作業が高速化 士気が高止まり 他人の作業で手を止められない 浮いた時間を使って質を作り込む流れができた
• 154. 各担当の専門化が進む 裁量による挑戦を促す
• 155. ゲームのUX品質の向上
• 156. めっちゃよかった
• 157. 「戦力の集中」
• 158. 開発全期間を通して
• 159. 常に
• 160. やりたいことは多く 手持ち戦力は貧弱
• 161. 計画を作る上で 心がけたこと
• 162. やりたいことは多い
• 163. でも
• 164. 戦力を薄く広く ばらまかないように
• 165. 戦略レベルでは
• 166. やりたい手段が いくつかあっても
• 167. １回のリリースの ミッションにおいては
• 168. 可能な限り ターゲットを絞る
• 169. Why?
• 170. 多数のターゲットを抱えると 一つのターゲットあたりの配分リソースが少なく 作業開始から完成までに時間が掛かる ▶ 仕掛のムダの温床、変更コストの増大 作業者が複数タスクを行き来することで スイッチングコストが発生する ▶ 作業スピードの低下 スプリントあたりのターゲット数が多ければ 考慮しなければならないファクターが多くなる。 ▶ 判断時の考慮情報や制約の増大
• 171. ターゲットを絞ると 変更コストの低下 作業スピードの増大 判断のコストの低下と高速化
• 172. さて
• 173. だいぶ時間使ったけど
• 174. 残り時間で
• 175. ゲームを面白く するためにやった
• 176. 他のチャレンジを 語ります
• 177. 1. 投資させること
• 178. 前提にしたこと
• 179. ユーザーは自分のリソースを 投資すると、その投資先に 対して強い愛着を持つようになる
• 180. 一例
• 181. イケア： 自分で手間隙かけて組み立てた 家具に強い愛着を持つ ソシャゲ： 時間を費やしたものに対し 「自分がこれだけ時間をかけたからには 価値があるに違いない」となる
• 182. 注意： 投資とはお金に限らず 人のリソース全般の投資を示す
• 183. やりたいこと
• 184. メンバーにリソースを 開発行為に対して 投資させる
• 185. どうやって
• 186. サイドキック理論 サイドキックとはFPSゲームなどで、主人公と行動をともにして 主人公のサポートをする役目 ゲームで必要な説明などを、冗長にならないように プレイヤーに説明する役目を負う
• 187. 例えば
• 188. ヴィクター・レズノフ CODという有名FPSゲームのサイドキック プレイヤーは銃で敵を倒してゲームを進行させるが 常に横についてさまざまなセリフを喋る プレイヤーの没入感を高めるのに重要な役目を負う
• 189. ▶ ステージのミッションの説明(「敵の攻勢を止めろ！」) ▶ コンテクストの説明とフレーバーの演出 ▶ 直近の行動の明示(「建物の上の狙撃手を倒せ！」) ▶ 問題と対策の明示(「戦車だ！バズーカを探して撃つんだ！」) ▶ 成功時のフィードバック(「よし、よくやった！」) ▶ 信頼の表明(「大丈夫だ、君ならできる！」) ▶ 適時のはげまし(「恐れるな、勇気を出せ！」) ▶ 共感の表明(「この結果はやむをえない、我々は最善を尽くした」) 実例としては
• 190. ゲームにおいてサイドキックが プレイヤーの没入に貢献する様に サイドキックのように振舞う事で プレイヤーの投資を促す
• 191. 2. 戦う前に勝つ
• 192. さっき
• 193. 成功により メンバーの士気を 高めると言った 「あなたが一ヶ月頑張って開発したこの機能は    これだけのユーザー反応につながりました。」
• 194. そのためにはメンバーの苦労に 報いるプロダクトの成功が必要 どうやって成功を作る？
• 195. 必要なのは２つ 成功率が高い挑戦をすること 成功を数字で確認すること
• 196. ユーザー分析や情報収集により 「勝算が高い」挑戦をする 成功を証明する数字の取得方法を 企画段階で計画に組み込む
• 197. 種本はアジャイルテスティング リリースのミッションってなに？ なにをもって成功したと定義する？ ユーザーがどう反応したら成功したと言える？ ユーザーの反応を探るためにはどのチャンネルから どういう方法でユーザーの動きを掴む？ ユーザーの動きはどの数字で検証可能？ じゃあ数字はどうやってとる？
• 198. ユーザー分析や情報収集により 「勝算が高い」挑戦をする 成功を証明する数字の取得方法を 企画段階で計画に組み込む
• 199. 例外もある チームには必要だが、成功が検証しづらいものや勝算の低いものは メンバーではなく自分の担当タスクとしてふったりもした
• 200. 3. ゲーム開発 + アジャイル
• 201. アジャイルなゲーム作りって可能？ ゲーム作りってリスク高いのでは？ 成功率とユーザー評価の高さ 両立しづらいのでは？
• 202. 種本はアジャイルなゲーム開発 コストと面白さ、成功率の両立 MVPをどうやって検証する？ 「面白い」ってどうやってデザインするの？
• 203. 4. フェーズの違い
• 204. Civilization ターン制戦略級のPCゲーム フェーズによってユーザーが感じる感情は異なる 燃える段階：敵勢力と互角な状態 楽しい段階：敵勢力を押しまくっている段階 達成感を感じる段階：強かった敵勢力が壊滅し、首都を占領した段階
• 205. 同様にユーザーの抱く感情を コントロールしたい ゲームの局面に応じて 異なる感情を刺激するよう ゲームをデザイン
• 206. 最初は対象は敵対的に振る舞い ユーザーの反抗心を煽る 中盤では対象の「押されている」感を演出し ユーザーの「俺つえー」感を煽る
• 207. 終盤、大勢が決した後はむしろ屈服した勢力 として( 友好 ¦ 従属 ¦ 献身 )的に振る舞い ユーザーに対して愛着を抱かせる ユーザーには対象の結末に選択肢がある 対象を手放し資源を得る 短期的利益よりの案 対象を手元に置き協力させる 長期的利益よりの案
• 208. 5. ナラティブ
• 209. ゲームの根底にある物語性 ユーザーはお使いタスクの繰り返しなどの 「やらされ感」を強く嫌う。 「このプロダクトはどういうものなのか？」 ユーザーは明示的に説明されるのではなく 自分の頭で考えることで行動や目的、結末を 「勝ち取る」ことでゲームを楽しむようになる 問題はユーザーにそれを明示的にせずにどう勝ち取らせるか？ 単純すぎると面白くないが、複雑だと飲み込めなくなる
• 210. 「春風のスネグラチカ」 代表作「無限の住人」の沙村広明作の中編漫画 共産党恐怖政治下のロシアが舞台 ストーリーが最高で中でも第１話が極めて秀逸 「伏線もりもり」「共産党の恐怖」「人が簡単に死ぬ」 「主人公は怪しい男女で謎があり何かを探している」 「共産党の下で抜け目なく立ち回り目的の達成を狙っている」 全体のあらすじをスムーズに読者に呑み込ませている あらすじを見たのであとの密度の高い展開も読者は円滑に飲み込める 途中で明らかになる謎の片鱗、最後のすっきりとした後味 読者は押し付けを感じずに全容を感じ取ることができる
• 211. 我々の場合
• 212. 我々のゲームのナラティブ ユーザーの所有欲と征服欲、収集欲を刺戟する ユーザーは苦労して取得した成果を手放すと資源が増加し 次の「より価値の高い対象」の攻略に入れる ユーザーは効率を追求したプレイをすると全てを惜しみなく 手放さないといけない。しかし何かを手元に置きたいと 願うなら、何かを切り捨て犠牲にしなければいけない。 ただしプレイヤーの技量が高ければ手放すものは少なく 手元に多くを置いた状態でゲームを進行できる
• 213. 「何を手放し何を残すのか」 ゲームで扱う対象は攻略すると「手放す」「手元に置く」という 選択肢がある。 対象が手放されると例外なく幸福とは異なる生き方になることを 何度もユーザーの目に触れさせる。攻略した対象はユーザーに 愛着を抱かせ庇護欲を刺激する行動をとる。 ユーザーが対象を守るには「手元に置く」しかない。 しかし、ゲームの進行上「手放す」ことで資源を作ることが不可欠 複数対象から取捨選択を強要し、プレイ効率に目を向けさせる
• 214. ユーザーの意見は聞かない ユーザーの声で「誰も手放したくない」「全てを手元に置きたい」 という声はかなり多い しかしゲームの面白さは 甲乙つけがたい対象から少数を自身が選ばされること 一つでも多く守るためにはプレイの洗練が必要なこと 他人の生殺与奪を握るという背徳的な全能感を感じること にあるので、何かを見殺しにするという部分は必要 むしろグロテスクに強調する必要がある このあたりはデッドライジングやLAST OF USで着想を得た
• 215. Whyナラティブ ゲームのレベルデザインのため レベルごとのフェーズの移動をスムーズに行うため 最初にユーザーは目の前にある攻略可能な対象から攻略にかかる。 その次にユーザーはより高価値、魅力的な対象の攻略をめざすため 資源の蓄積や獲得を目指した行動を始める 最後にユーザーは、どれを守り、どれを捨てるかという取捨選択を 迫られる。取捨選択せず、すべて守るという幻想のために より効率的なプレイスタイルの追求に走る
• 216. もう少し時間ある？
• 217. じゃあ
• 218. 開発の途中で
• 219. やらなくなったこと
• 220. 1. ヴェロシティの意識
• 221. 途中までは ヴェロシティは 伸びていた
• 222. しかし
• 223. ユーザー価値に重点を置いた場合 捉えどころのないタスクや 成功率の低いタスクが増えて ヴェロシティは低下した
• 224. 伸ばすべきは ユーザー価値か ヴェロシティか
• 225. それはユーザー価値だろJK
• 226. ということでヴェロシティの 地位が相対的に低下した
• 227. いまではアノーマリー 検知のカナリア扱い
• 228. 2. スプリントの制約
• 229. 当初はスプリント終了後に イテレーションレビューして パスしたものだけリリースした
• 230. 現在
• 231. 無理にスプリントで 同期を取らなくても 品質と練度が高ければ 即時リリースで問題ない
• 232. むしろ単位期間内の リリース回数を増やして フィードバックを 増やしたほうが利益が大きい
• 233. ということで
• 234. スプリントはリリースを 制約するものではなくなった
• 235. ただし
• 236. KPTとスプリントレトロスペクティブ リリース単位のフィードバック データに基づいた状況分析 についてはスプリント単位で 定期的に同期しています
• 237. さてそろそろ
• 238. お時間にございます
• 239. お楽しみいただけた でしょうか
• 240. ピザやビールは 足りてますか？
• 241. 最後に自己紹介
• 242. あんただれ
• 243. レベル： しょくぎょう： しょうごう： 29 プログラマ はいぱーれがしー こーどくりえいた @shin_semiya ともうします
• 244. なにか質問が あればこの後に
• 245. 今日は最後まで おつきあいいただき ありがとうございます。
• 246. Thanks a lot !