＜ゲーム開発に必要な心得＞ ソフトウェアエンジニアが支え るゲームUX MIXI　23年卒ゲーム研修 開発本部CTO室 クライアントG サステナビリティ 学校教育推進担当 田那辺輝 tanabe akira 

自己紹介 

株式会社MIXI 開発本部CTO室クライアントグループ所属 クライアントソフトウェアエンジニア 中学生プログラミングカリキュラムと教材ソフトウェア 開発者、および同カリキュラム講師 ゲームを中心としたソフトウェアエンジニアとして活動 しており、コンシューマゲームやブラウザゲームとス マートフォンアプリの開発、Webサービスやゲーム企画 ・ディレクションも経験。近年は教育現場に向けて、 「プログラミング学習」を推進する講師としてその学習 ソフトウェアやカリキュラム開発と併せて取り組んでい る。 https://www.linkedin.com/in/akira-tanabe/ 田那辺　輝 tanabe akira 

株式会社MIXI サスティナビリティおよび、地域貢献と次世代 育成の視点で様々な取り組みを展開しています https://mixi.co.jp/sustainability/ 本プロジェクトで取り組んでいる活動 ○ 渋谷区を中心とした中学生向けプログラ ミング学習支援 ○ 次世代育成を目的としたエンジニア職の 理解と訴求 

①中学生向けプログラミング学習支援 1. 渋谷区における中学校（公 私立）技術科授業など 2. 渋谷区の部活動に向けた Pythonプログラミングなど 3. 中高生向けエンジニア職業 講話 4. 全国の中学高等学校からの 企業訪問実施先として、ま たは出向き、プログラミン グ体験とエンジニア職業講 話を随時実施 

②中学生向けPBL授業支援 1. 社会課題・情報学習ができ るオリジナルICT学習教材 でグループ探究するプロ ジェクト型学習（Project - Based - Lerning）授業 2. 実社会課題の解決をPython 作品制作で探究する課題解 決型学習 （Problem - Based - Lerning）授業 3. など順次展開 

③学生向けUnity開発・学習指導 1. 私立コンピュータ部活動に おけるUnityゲーム開発講座 （4日間 全8時間） 2. 全国対象中学生向けUnity ゲーム開発ハンズオンイベ ント（3時間ｘ2日） 

④新卒予定者向け・Unity学習支援 ○ Unity Engine Challenge by MIXI（2019年〜毎年開 催） ■ 第4回「Unity Engine Challenge by MIXI ＃4」　 10/15に開催（終了） ● 大学、大学院、専門学校、高専のため のUnity課題挑戦イベント ● （私からは）第1回目から利用している 「スコアボード」と「回答システム」 なるイベントシステムをUnityで作成し 運用 ● （私からは）第1回目から「マルチプレ イ課題」および「課題対戦用通信bot」 を提供、第3回目から「Audio課題」を 提供 ● 開催当日もチューターや問題解説者と して参加 

おしらせ ● 書籍紹介 ○ 技術書典#13 にてMIXIから「mixi tech note ＃08」無料 配布中　 ● https://techbookfest.org/product/6QFxk7A 275p0z8L4t9tZ9y ● 第5章「学校教育ソフトウェアで問題解決」 を田那辺から寄稿 ● （要無料アカウント登録） ○ 過去出版作　#06 / #04 / #03 でもUnityにおける原稿 を書いてます ● 上のサイトから入手可能 ● mixi tech note #06 ／できるよUnity DOT ● mixi tech note #04 ／Behavior Treeでゲーム AIに取り組んで思う ● mixi tech note #03 ／Unity で作る競技型イ ベントの回答システム ○ NEW 技術書展 #14 にて出版予定 「MIXI TECH NOTE #09」 に寄稿しました（5/20開催） 

NEXT 

この章で話すこと ● ゲーム開発工程とありがちな問題についての解説 ● よいゲームの開発に必要なことの提案 ● 望ましい開発姿勢についての提案 本講義は「ゲームの素晴らしさを重視する」ことを軸にした開発は どう取り組むべきかについて解説します。 

通常ソフトウェアエンジニアがゲーム開発PJに求めること 1. 未知の発見・技術的課題の解決を重視する 2. パフォーマンス向上を重視する 3. レンダリング（描画）向上を重視する 4. 開発・運営環境、 ビルド環境を重視する 5. ゲームの素晴らしさを重視する これらを複合的に取り組むことでしょう。 本講義は「ゲームの素晴らしさを重視する」ことを軸にした 開発はどう取り組むかについて解説します。 

ゲーム開発工程と ありがちな問題 

開発工程 よくある状況 

よくある工程 1. （プランナー）企画が上がる 2. （エンジニア）仮実装する 3. （デザイナー）素材が上がる 4. （エンジニア）素材を組み込む 5. （プランナー）仮設定を入力する 6. 〜幾重にもこれを積み上げる〜 7. 内部プレイ会 8. 外部プレイ会 

チームが感じてること（いつどこをレビューするのか） 1. （プランナー）企画が上がる 2. （エンジニア）仮実装する 3. （デザイナー）素材が上がる 4. （エンジニア）素材を組み込む 5. （プランナー）仮設定を入力する 6. 〜幾重にもこれを積み上げる〜 7. 内部プレイ会 8. 外部プレイ会 …目新しい企画でキャッチーだね …狙ったように動いて期待できるね …いいビジュアルだね …いいビジュアルで狙ったように動くね …パラメータやステージが予定通りだね …未完成箇所があって通しでは見れないな …いつも見てて課題も分かるので自分たちを信じよう …「おもしろい」「おもしろくない」の捉え方がさまざま 

何が問題か 

何が問題か 1. 問題があるかどうか分かるまでがとにかく「遅い」 ので手遅れになりがち 2. 「おもしろい」の定義とその時間軸もさまざまで基 準が共有しづらく主観に頼りがち 3. 何年も携わって中身をよく知るほどに解らないこと が分からない状態にあることに気付けない 4. （だからこそユーザーテストがある） 

どうすればいいのか 2つの提案 

どうすればいいのか１ 特定パートだけでは「おもしろい」が決定されないが、どのパートからでも「お もしろくない」が誘因されることを理解しましょう（ビット演算 1 AND 0 …0） 1. 機能的だけど操作性や視認性や反応が悪い 2. 読み込みや前処理でテンポが悪い 3. 通信や実行パフォーマンスなど負荷が大きい 4. スピード感や演出で没入感がない 5. 選択肢や変化が少なく飽きが早い 

どうすればいいのか２ 一人一人が「おもしろい」に寄与する仕事だと意識して、ゲームとしてのこだわりと愛情を持って仕事をしましょう 1. ゲーム開発にとって依頼通りに作ることはただのスタートライン a. 仕様を発行する側もあくまで未知、変更や破棄も頻繁である 2. クオリティにこだわる仕事ぶりと技能におけるリスペクトは他パートにも伝播する 好循環 a. いい仕事には敬意が集まり、いい仕事でしか応えられなくなるでしょう 3. 無理難題や違和感に気づいたのならば問題解決のチャンス a. 難しい要求やなぜか感じる違和感に目を背けなければ技術革新やレベルアップの好機 4. それでも感覚だけではない良し悪しの理由があることを認識する a. インプットを増やすことで技術的知見や既に解決している事例に出会う 

おもしろい 「ゲームUX」 

おもしろい「ゲームUX」 ゲームがプレイヤーに与えるあらゆる体験。 ゲームUXはユーザビリティとエンゲージアビリティ（ゲーマーズブレインより） 1. ゲームUXは楽しいビデオゲーム体験を指す。UXとは別の定義 2. ユーザビリティは、システムの意図や使用方法が伝えられているか、不要なフラスト レーションがない 3. エンゲージアビリティは、プレイヤーに没頭してプレイを継続してもらえるか、動機 付けが柱 ゲームUXと他のデジタル製品との重要な違いは、ゲームUX デザイナーがアクションやタスクを簡単 にしようとしないこと。UX チームが他のデジタル製品と同じようにゲームにアプローチした場合、 「Kill All Enemies」ボタンが表示され、ゲームが終了するだろう。（Jakob Nielsen） 

UX（ユーザー体験） 模範的なユーザーエクスペリエンスの第一の要件は、悩ませたり面倒をかけるこ となしに、顧客のニーズを正確に満たすことである。次に必要なのは、製品を所 有することがうれしく、利用することが楽しくなるような、簡潔さと上品さであ る。（Nielsen Norman Group） 関連事項　アフォーダンス、シグニファイ 

ユーザビリティ 1. 国際標準化機構（ISO）による「ISO 9241-11」規格 （wikipediaより 1.1. 学習しやすさ: システムは、ユーザがそれを使ってすぐ作業を始められるよう、簡単に学習できるよ うにしなければならない。 1.2. 効率性: システムは、一度ユーザがそれについて学習すれば、後は高い生産性を上げられるよう、効 率的な使用を可能にすべきである。 1.3. 記憶しやすさ: システムは、不定期利用のユーザがしばらく使わなくても、再び使うときに覚え直さ ないで使えるよう、覚えやすくしなければならない。 1.4. エラー: システムはエラー発生率を低くし、ユーザがシステム使用中にエラーを起こしにくく、もし エラーが発生しても簡単に回復できるようにしなければならない。また、致命的なエラーが起こっ てはいけない。 1.5. 主観的満足度: システムは、ユーザが個人的に満足できるよう、また好きになるよう楽しく利用でき るようにしなければならない。 2. プラットフォームやコンテンツの慣習を考慮する 2.1. 環境やデバイスの性質が配慮されているか 2.2. 慣習的操作と違わないか 

エンゲージアビリティ 1. 没頭できること（おもしろいのゲームデザイン） 1.1. パターンを発見して再現するのが楽しい 1.2. 練習により一連の行動（※チャンク）が上達（※グロック）して無意識的に行動できるよう になると楽しい 1.3. 積み重ねたチャンクがプレイの幅を持たせるから考えることがおもしろい 1.4. 難易度と能力が適切な状態を継続できると没頭できる（フロー理論） 2. 動機付けが十分であること 2.1. 内発的動機付け、外発的動機付け（ウィルビーイング理論） 2.2. ナラティブ（なぜ人はゲームにハマるのか） 

クライアントエンジニアが ゲームUXとどう関われるか 

UXやゲーム性に関する誤解 問題はこれらのUXやゲーム性に関して比較的多く目にするのはエンジニア以外で の情報であって、ここにエンジニアが関与しない分野であると誤解してしまうと ころにある。 ● UXはデザインが定義して解決するもの ● ゲーム性は企画が定義して解決するもの 前項で解説した「ゲーム」という分野での良い体験（ゲームUX）に必要なもの は、アイコンなど限定的な五感や分野に絞られるものではなく、ストレスなく行 動し没頭できる時間を楽しむなかで接触するすべての要素が影響する意味が込め られている。 

クライアントエンジニアがゲームUXとどう関わるか 干渉できるさまざまな機会を生かす 1. 担当領域として仕様理解をして成果物に言及もしくは実装する機会 2. 対象を機能実装をするなかで仕様的に言及されない不確定要素に関わる機会 3. 対象とは直接関与しない機能実装をするなかで動く成果物に触れる機会 4. 内部の関係性によっては仕様提案もしくは改善提案できる機会も 5. チームに貢献するツール等の間接業務で掛け算的に寄与する ● 対象者に恩恵があるとコンテンツに集中してこだわることができ、より 早い段階で内容が整い、成果物の評価が分かり、早く調整に着手できる 

ゲームUXに対してとれる優れた行動指針 5つの提案 

ゲームUXに対してとれる優れた行動指針 1. 先行事例やトレンドに対しエンジニア視点の詳しい機能 分析をして知識を提供 1.1. あのジャンル、あの要素は他作品でどういう動きをしているか、 どう作られているか 1.2. 良い事例悪い事例がどういう要因からそう感じさせるか 

ゲームUXに対してとれる優れた行動指針 2. 仕様意図を汲み機能的補完を提案・提供 2.1. 仕様書が言及しない（できない）細部挙動が多々あるし、企画しか ない場合もある 2.2. ソフトウェア的都合を優先し過ぎずプレイヤーの不要なフラスト レーションを排除する 

ゲームUXに対してとれる優れた行動指針 3. 簡便で間違いが起きにくいデータ・リソース管理の仕組みの提供 3.1. 設定データ・使用素材にルールがあり過ぎて使いづらくないか 3.1.1. 意図を汲んで要求を吸収する仕組み、用途別に分割したほうがいいか、Component設定 要求はソフトウェア解決... 3.2. リストにおいて同じ情報となる部分が何度も個別設定となってしまわないか 3.2.1. カテゴリ化してデータ整理、定型データは削減、テンプレート化など... 3.3. どこに間違いがあるか把握しづらくないか 3.3.1. データシート値範囲、データシートキーワード誤字、データシート構造記述、 Component設定漏れや誤り... 3.4. データ入力者にとって楽で分かりやすい方法になっているか 3.4.1. その量を入力フォームやエディタで手入力できるか、グラフエディタで管理できる規模 なのか... 

ゲームUXに対してとれる優れた行動指針 4. イテレーションしやすくなるツール・デバッグメニューの提供 4.1. 設定作業・素材更新作業で自動化できる部分を巻き取れると、チームは 品質に意識がまわる、早い段階であるほど有用 4.2. データ・素材への静的チェックツールが予めエラー検出できれば作業効 率が向上し、チームはバランス改善や品質向上に意識が向く、早い段階 であるほど有用 4.3. データ・スクリプトのプレビューや設定変更を速やかにテストできる方 法があればより多く試せて、チームはバランス改善や品質向上に意識が 向く、早い段階であるほど有用 

ゲームUXに対してとれる優れた行動指針 5. ゲームUXに影響を与えうる箇所を理解して特にコストをかける 5.1. 山積する作業チケットはどれも並列に見え、鬼上司は効率を無視した作業順を 指示し、今取り組んでいるプロジェクトでは得るものは得たなどと考えたりす るときでさえも、「ゲームUX」とこの行動指針の重要性をいつも忘れない 

最後に 有意義なナラティブと「らしさ」 

有意義なナラティブと「らしさ」 ここまでで ● ゲームの素晴らしさのものさしに「ゲームUX」があることが理解できた ● 開発中に誰もがゲームUXに寄与できることが理解できた Check 最後に伝えること 「ナラティブ」とはプレイヤーがそのゲームでどのような経験・物語を得るのかを 表すことば。その作品は子どもたちの時間の対価に何を伝えるのか。 そのゲームから自分たちが提供したいどんなナラティブがあるのかを認識して共有 することでブレない「私たちらしさ」を持ったゲームが発見できるはずである。 

まとめ 

まとめ 1. ゲーム開発工程とありがちな問題 1.1. 問題があるかどうか分かるまでがとにかく「遅い」 1.2. 「おもしろい」の定義とその時間軸もさまざま 1.3. どのパートからでも「おもしろくない」を誘因 1.4. 一人一人が「おもしろい」に寄与する仕事 2. おもしろい「ゲームUX」 2.1. ゲームUXはユーザビリティとエンゲージアビリティに起因する 2.2. エンゲージアビリティとは、没頭できること・動機付けが十分であること 3. クライアントエンジニアがゲームUXに対してとれる5つの行動指針 3.1. 先行事例やトレンドをエンジニア視点の詳しい機能分析をして知識の提供 3.2. 前向きに仕様意図を汲み機能的補完を提案・提供する 3.3. 簡便で間違いが起きにくいデータ・リソース管理の仕組みの提供 3.4. イテレーションやすくなるツール・デバッグメニューの提供 3.5. ゲームUXに影響を与えうる箇所を理解して特にコストをかける 4. 有意義なナラティブと「らしさ」 4.1. 「ナラティブ」とはどのような経験・ 物語かを表すことば 4.2. 時間の対価にナラティブで何を伝える のか 4.3. 提供したいナラティブを認識して「私 たちらしさ」を見つける 

おわり