「hdifes #04　人を巻き込みチームを作る」（2015年4月12日）で行われた、神奈川工科大学の中村隆之氏による講演資料です。

1. 2015/04/12 HDIfes #04
チーム作りとモノ作りの同時進行
ゲーム開発の現場と大学教育の実践 / もじぴったんとアオモリズムの場合

2. 自己紹介
✤ 1995年 ソニー(携帯電話開発)
✤ 1997年 ナムコ(ゲーム開発)
✤ 2010年 独立 ( 研修企画, 講師 )
中村遊び応用研究所 所長
✤ 2012年∼ 神奈川工科大学
特任准教授 (現在)
✤ 2014年1月∼ (株)スマイルブーム
取締役 (2015年1月退職)
中村 隆之(なかむら たかし）
ゲームデザイン教育の
専門家です。

3. 地形リズムアクション「アオモリズム」
3
東京ゲームショウ2013にて最初の展示

4. 地形リズムアクション「アオモリズム」
4
TGS2013 に展示
CEDEC2014
インタラクティブセッション招待
朝日新聞 青森版掲載(10/12)

5. 地形リズムアクション「アオモリズム」
5星野リゾート 青森屋にて2014/12/27より設置

6. TGS2014展示作品(はげピッピッ!)
✤ バーコードリーダーでバーコード
ヘアをピッとしてスキャンする
「スキャン計算アクション」
はげピッ！ピッ！
✤ 伝統ある「ツル多はげます会」
ハゲアワード2014 団体賞受賞
6

7. チーム作りとモノ作りの両立
開発を進めながら同時にチームとしての力をアップさせるには？

8. チームでの開発でありがちな事
✤ チーム内での意見の対立をどうとらえるか
✤ 立場/能力/経験の違いがある以上ある程度起こる
✤ 多様な意見はチームとしてむしろ歓迎されるべき
✤ しかし、チーム内での意見の対立は時に深刻な問題を生み出す
✤ 人間関係の悪化を引き起こす事も
✤ 「完成すればよい」症候群
（問題があると思っても誰も言わない)
チームのモチベーションを保ちつつ商品のクオリティを上げるには？

9. 意見の対立をどうやって解消する？
✤ リーダーが決める
✤ スピードは上がる
✤ しかしリーダーが決めすぎると…
✤ リーダーがいないと決められない
✤ リーダー依存( どうせ自分が意見を言っても…)に陥る
✤ チームで話し合いで決める
✤ より意見の対立が明確になる事も…
✤ 会議で大半の時間が過ぎ去る病に陥る
チームの力を活かし商品のクオリティとメンバーのモチベーションを
同時に高めるには？

10. もじぴったんDSプロジェクトの状況(背景)
✤ 2006年頃 ( ことばのパズル もじぴったんDS = 2007年3月発売 )
✤ それ以前のもじぴったんプロジェクトは中村が細かい部分まで指示を
出していた
✤ 2005年頃に動いていたプロジェクトがリリースが半年以上遅れ
プロジェクトの「かけもち」をする事に
自分がいなくても「決めて進む」考え方/仕組みを導入する
必要があった

11. 合理的なデザインをチームで行うには…
✤ コンセプトの共有を徹底する
✤ 誰に向けた商品か / 優先順位をつけた価値の評価軸の設定
✤ 仕組み化、手法化、ルール化を進める
✤ 同様な問題が起きても既にある知恵で解決する
✤ 問題は「作っているモノ」にある事を意識させる
✤ 「人」に問題があるのではなく「作っているモノ」に問題がある
という視点を徹底する

12. コンセプトの共有(もじぴったんDS)
✤ 仕様決定前：プロデューサーとして下記を明確化
✤ ターゲット
✤ 20代女性 ( DS Liteと一緒に英語漬け等の実用ソフトを買ったが
ゲームらしいゲームはやった事がない[ペルソナ])
✤ 「価値の評価軸」(*) の設定 ( もじぴったんDS )
1. 楽しそう
2. 手軽に遊べそう
3. ためになる

13. 価値の評価軸（優先度付き）
✤ 「NHK 教育の番組」と「民放情報バラエティ」の違い
✤ 「タメになって楽しい」と「楽しくてタメになる」
✤ 価値の評価軸は優先順が変わればコンセプトが変わる
✤ 仕様やデザインについて「価値の評価軸」で評価する事で仕様を決めていく
✤ もじぴったんDSの場合の評価軸（優先順/あくまでイメージ）
1. 楽しそう
2. 手軽に遊べそう
3. ためになる
4. ….

14. 仕様の絞り込み
✤ 数十のアイデアの中から
「価値の評価軸」をベースに
絞り込み
✤ 全員の意見を反映

15. 仕組み化、手法化、ルール化
✤ チームの力を引き出す方法
✤ 妥当な結論を導き出すための話し合いのルール
✤ 多数決で決めない / 違う意見なら理由を共有する
✤ 第３のアイデアはないか

16. 妥当な結論を導くための話し合いのルール
✤ 思いついたら口に出す
✤ 他を圧倒しない
✤ 反論されたら「ありがとう」
商品企画エンジン 梅澤 伸嘉 先生

17. 多数決では決めない/理由の共有
✤ 「価値の評価軸」に沿ってい
るかどうかは票を取るが「決
める」事はしない
✤ 候補に１つでも誰かが投票す
れば必ず理由を共有する
チームの強みは
「多様な視点」
理由を共有すると
意外な発見がある事も

18. アオモリズムの元アイデア
(ゲームクリエイター特訓 授業内)
18

19. 第３のアイデアを求める
✤ アイデアAとアイデアBで意見が分かれる
✤ 評価軸に沿って評価すると、
アイデアAは、1.と3.の評価が高いが2は低い
アイデアBは、1.2.の評価が高いが3は低い
✤ アイデアAでもなく、アイデアBでもないアイデアCはないか？
✤ 良いところ取りの改良改善
✤ 逆転の発想
✤ 全く別のアイデアはないか

20. 問題は「作っているモノ」にある
✤ チーム内で意見の対立が起きると「人」に攻撃が行く場合がある
✤ 商品が受け入れられないのは「客のせい」という人も出てくる
フォーカスすべきは、自分達が「作っているモノ」である
お客様が思った通りに操作しないのは「モノ」に原因がある
チーム内の問題は「人」ではなく仕組みにある
アイデアが問題なのであってアイデアを出した人に問題はない

21. チーム内で軋轢
主観的意見をベースにしたチームでの問題解決
✤ 一般のプロジェクトでは開発者の主観＝「意見」で方向性が決まる
✤ チームだと各メンバーにそれぞれ違った思い込みがある
✤ 結果的に意見が食い違いチームがうまく機能しない
(チームで「事なかれ主義」が横行/違うと思っても意見しない)
不明瞭な目標
完成させる事が
目標になりがち

22. 客観的事実をベースにしたチームでの問題解決
✤ 客観的事実はブレない ( ex.お客様が特定の場所で操作を間違える等)
✤ 客観的事実＋明確な目標があれば、解決すべき問題もクリアに
✤ 「思い込み」(仮説)が間違っている事が分かる
✤ アイデアのキレも格段に向上する/建設的な議論が出来る
客観的な事実
明確な目標
チームの団結力
的確なアイデア解決すべき問題

23. もじぴったんDSにおける
ユーザーテストの実例
はじめての「タッチパネル」＋２画面でゲームのUIをどうすべきか？

24. ユーザーテストのプロセス
事前準備
人員確保/会場準備
試作品プレイ
ヒアリング
チームミーティング
お客様の行動の確認
問題点の洗い出し
グループ毎に実施
ターゲットのお客様の層に近い人を
リクルートする(最重要)
行動を観察する事に徹する！
(決して_____________しない！)
聞くことに徹する！
(種明かしは後から→反応をみる)
できるだけ当日中に！
(記憶が薄れないうちに)
説明

25. 思いがけないお客様の行動が重要
✤ 情報を与えない状態でのお客様の行動
＝お客様にとって一番自然な動作 / 操作
✤ つまり「その思いがけない自然な動作」＝意図した結果になる
ようにする事が、UI設計の基本となる
もじぴったんDSでの実例をデモンストレーションします

26. もじぴったんDS(ゲーム中)操作の対応
カメラがうまくいかなかった時用の動画(予備)

27. 神奈川工科大学 情報メディア学科 ゲームクリエイター特訓
ゲーム分析から画面遷移図作成
実際にあるスマートフォンゲームを分析し、画面状態遷移図(画面/イベント)を作成
27

28. でも本当に大切
だったのは…
チームのムード作り( 中村ニガテ )