GDC報告会資料 海外に見る「生産性改善」動向
•Download as PPTX, PDF•
0 likes•1,241 views
GDC2018セッションから、生産性改善にまつわるセッションをご紹介します。また、急遽渡米することになった際に起きるさまざまな問題についての知見も共有いたします。
Recommended
Recommended
More Related Content
Similar to GDC報告会資料 海外に見る「生産性改善」動向
Similar to GDC報告会資料 海外に見る「生産性改善」動向 (20)
More from Masatoshi Itoh
Recently uploaded
Recently uploaded (12)
GDC報告会資料 海外に見る「生産性改善」動向
- 1. Copyright CYBIRD Co., Ltd. All Rights Reserved. GDC報告資料：海外にみる「生産性改善」動向 ＆ 代打でGDCにいくときの注意点 2018/4/8 株式会社サイバード 伊藤 雅俊
- 2. Copyright CYBIRD Co., Ltd. All Rights Reserved. 2 「代打でも何とかGDCいけるものだなあ」という話… ESTA ご存じですか？
- 3. Copyright CYBIRD Co., Ltd. All Rights Reserved. 3 公式ウェブサイトより ESTAは、米国国土安全保障省（DHS）により2009年1月12日から義務化され ました。このオンラインシステムは、ビザ免除プログラム（VWP）の一部で、短 期商用・観光目的（90日以下）の目的で旅行するすべてのビザ免除プログラ ム渡航者は、米国行きの航空機や船に搭乗する前にオンラインでESTA渡航 認証を受けなければなりません。 ということは？ 日本はビザ免除プログラム対象国なので… 事前にウェブから登録してくださいね、というシステム ちなみに申請に14ドルかかり、有効期限はパスポートの有効期限もしくは2 年間のどちらか短い方。 ESTAとは
- 4. Copyright CYBIRD Co., Ltd. All Rights Reserved. 4 定義 ESTAは、米国国土安全保障省（DHS）により2009年1月12日から義務化され ました。このオンラインシステムは、ビザ免除プログラム（VWP）の一部で、短 期商用・観光目的（90日以下）の目的で旅行するすべてのビザ免除プログラ ム渡航者は、米国行きの航空機や船に搭乗する前にオンラインでESTA渡航 認証を受けなければなりません。 ということは？ 日本はビザ免除プログラム対象国なので… 事前にウェブから登録してくださいね、というシステム ちなみに申請に14ドルかかり、有効期限はパスポートの有効期限もしくは2 年間のどちらか短い方。 ESTAとは
- 5. Copyright CYBIRD Co., Ltd. All Rights Reserved. 5 WHAT’s happened 当初参加予定だった人が直前でESTA不通過が判明、GDCに参加できなく なった 64時間後には代役の伊藤が機上の人に ESTAとは
- 6. Copyright CYBIRD Co., Ltd. All Rights Reserved. 6 申請時の注意点に… ビザ免除プログラム参加国の国籍の方で、2011年3月1日以降にイラク、イラ ン、スーダン、シリア、リビア、ソマリアまたはイエメンに渡航また滞在したこと がある方 (ビザ免除プログラム参加国の軍または正規政府職員として公務を 遂行するためにこれらの国に渡航した場合は特例あり)、またはビザ免除プ ログラム参加国の国籍と、イラン、イラク、スーダンまたはシリアのいずれか の国籍を有する二重国籍者の方は「ビザ免除プログラムの改定及びテロリ スト渡航防止法」をご覧ください。 ESTAとは
- 7. Copyright CYBIRD Co., Ltd. All Rights Reserved. 7 申請時の注意点に… ビザ免除プログラム参加国の国籍の方で、2011年3月1日以降にイラク、 イラン、スーダン、シリア、リビア、ソマリアまたはイ エメンに渡航また滞在したことがある方 (ビザ免除プログラム参加国の軍 または正規政府職員として公務を遂行するためにこれらの国に渡航した場 合は特例あり)、またはビザ免除プログラム参加国の国籍と、イラン、イラク、 スーダンまたはシリアのいずれかの国籍を有する二重国籍者の方は「ビザ 免除プログラムの改定及びテロリスト渡航防止法」をご覧ください。 ESTAとは
- 8. Copyright CYBIRD Co., Ltd. All Rights Reserved. 8 WHY happened 3年前にイラン渡航歴があった！ ESTAとは
- 9. Copyright CYBIRD Co., Ltd. All Rights Reserved. 9 WHY happened 3年前にイラン渡航歴があった！ → 家族旅行！ ESTAとは
- 10. Copyright CYBIRD Co., Ltd. All Rights Reserved. 10 今回のフライト 行き 乗り継ぎ2回 成田 17:30→ サンフランシスコ 18:35 Lessons Learned サンフランシスコ
- 11. Copyright CYBIRD Co., Ltd. All Rights Reserved. 11 今回のフライト 行き 乗り継ぎ2回 成田 17:30→ポートランド 10:51 8h ポートランド 12:11→ サンフランシスコ 18:35 Lessons Learned ポートランド サンフランシスコ
- 12. Copyright CYBIRD Co., Ltd. All Rights Reserved. 12 今回のフライト 行き 乗り継ぎ2回 成田 17:30→ポートランド 10:51 8h ポートランド 12:11→ロサンゼルス 14:34 2h ロサンゼルス 17:00 →サンフランシスコ 18:35 1h Lessons Learned ポートランド サンフランシスコ ロサンゼルス
- 13. Copyright CYBIRD Co., Ltd. All Rights Reserved. 13 今回のフライト 行き 乗り継ぎ2回 成田 17:30→ポートランド 10:51 8h ポートランド 12:11→ロサンゼルス 14:34 2h ロサンゼルス 17:00 →サンフランシスコ 18:35 1h 帰り 乗り継ぎ1回 サンフランシスコ 23:00 →アトランタ 06:31 4h アトランタ 11:16→成田 14:35 14h Lessons Learned アトランタ サンフランシスコ
- 14. Copyright CYBIRD Co., Ltd. All Rights Reserved. 14 今回の宿 Lessons Learned
- 15. Copyright CYBIRD Co., Ltd. All Rights Reserved. 15 今回の宿 Lessons Learned
- 16. Copyright CYBIRD Co., Ltd. All Rights Reserved. 16 渡米にあたっては、ESTAは早めに申請しましょう ※ESTA申請時、現地滞在先の記入欄あり サンクコストに引きずられないよう、状況によっては諦めも肝心 Takeaways
- 17. Copyright CYBIRD Co., Ltd. All Rights Reserved. 17 アルストツカに栄光あれ
- 18. Copyright CYBIRD Co., Ltd. All Rights Reserved. 18 話す人について 海外にみる「生産性改善」動向 技術選択 社内組織の改組 開発時 リリース前後 運営中（CS） まとめ アジェンダ
- 19. Copyright CYBIRD Co., Ltd. All Rights Reserved. 19 話す人は... 株式会社サイバード 開発統括本部 技術統括部 伊藤 雅俊 ( @masatoshiitoh ) 話す人
- 20. Copyright CYBIRD Co., Ltd. All Rights Reserved. 20 RBB SPEED TESTという回線速度測定サービスのオリジナル開発者で す ※画像は初期の計測画面です 現在もspeed.rbbtoday.com（株式会社イード）にて運営されているのでご興 味のある方は一度アクセスしてみてくださいね 自己紹介オマケ
- 21. Copyright CYBIRD Co., Ltd. All Rights Reserved. 21 自己紹介オマケ オライリー「ゲームクリエイターが知るべ き97のこと 2」 こちらで、「発表・講演は、前半にメディア 向けの「おみやげ」を」という項を書いて います。
- 22. Copyright CYBIRD Co., Ltd. All Rights Reserved. 22 イケメン大奥◆恋の園 (2012/6/14) イケメン恋戦◆平清盛 (2012/9/10) イケメン源氏◆恋物語 (2012/10/29) イケメン王宮◆真夜中のシンデレラ (2012/11/30) 新章イケメン大奥◆禁じられた恋 (2013/3/18) イケメン夜曲◆ロミオと秘密のジュリエット (2013/8/26) イケメンシリーズ6年、アプリ14作の歴史 (1/3)
- 23. Copyright CYBIRD Co., Ltd. All Rights Reserved. 23 イケメン幕末◆運命の恋 (2013/12/9) 100日間のプリンセス◆もうひとつのイケメン王宮 (2014/6/5) スイートルームの眠り姫◆セレブ的贅沢恋愛 (2014/9/11) イケメン王国◆女王と真実のキス (2015/2/17) イケメン戦国◆時をかける恋 (2015/6/22) イケメン革命◆アリスと恋の魔法 (2016/10/20) イケメンヴァンパイア◆偉人たちと恋の誘惑 (2017/7/31) イケメンシリーズ6年、アプリ14作の歴史 (2/3)
- 24. Copyright CYBIRD Co., Ltd. All Rights Reserved. 24 イケメンライブ 恋の歌をキミに イケメンシリーズ6年、アプリ14作の歴史 (2/2)
- 25. Copyright CYBIRD Co., Ltd. All Rights Reserved. 25 話す人について 海外にみる「生産性改善」動向 技術選択 社内組織の改組 開発時 リリース前後 運営中（CS） まとめ アジェンダ
- 26. Copyright CYBIRD Co., Ltd. All Rights Reserved. 26 Multi-platform production from day zero Speaker: Ido Yehieli (tametick.com) HTML5で開発することで、iOS/Android/Mac/Windows/Linux等に出して います、という発表 対象マーケットをローコストに広げる戦略 同時展開ゆえのオーバーヘッドも デバッグ ブランチ管理 生産性改善：技術選択
- 27. Copyright CYBIRD Co., Ltd. All Rights Reserved. 27 Teams are stronger than heroes: Bungie development evolved Speaker: Patrik O'Kelley (Head of Production - Destiny 2) Bungie社事例。 Destiny2開発にあたって、従来、 Animation, Art, Design, Test, Engineeringの技能別 プロダクション組織としていたの を、ごく小さな（ Animation/ Art/Design/Test/Engineering 1名ずつ）ファンクショナル チームの集合体に組み替えた、 という発表 講演タイトルにはBungieの過去の苦悩も？ 生産性改善：社内組織の改組
- 28. Copyright CYBIRD Co., Ltd. All Rights Reserved. 28 生産性改善：社内組織の改組
- 29. Copyright CYBIRD Co., Ltd. All Rights Reserved. 29 生産性改善：社内組織の改組
- 30. Copyright CYBIRD Co., Ltd. All Rights Reserved. 30 生産性改善：社内組織の改組
- 31. Copyright CYBIRD Co., Ltd. All Rights Reserved. 31 Rebuilding Your Engine During Development: Lessons from 'Mafia III‘ Jan Kratochvil (Technical Director, Hangar 13 Games) エンジン置き換え理由 データ増、チーム拡大、スタジオ拠点の分散、に対応するため 主な変更点 ゲームエディタ オブジェクトシステム ビルドシステム ローカルのイテレーション ビジュアルスクリプティング ミドルウェア統合 物理、アニメーション、ナビゲーション、UI、オーディオ 生産性改善：開発（Mafia III）
- 32. Copyright CYBIRD Co., Ltd. All Rights Reserved. 32 Procedural World Generation of 'Far Cry 5’ Etienne Carrier (Technical Artist, Ubisoft) プロシージャルの利用 ツールチェーンの整備 自然なフィールドの生成 崖の地層表現 前作→技術使わず（手作業） 今作→ツールチェーン化 Biome（生物群系）の表現 →生物・地学で習ったような話が多数 ツール化されている →自然なエレメント配置を実現 生産性改善：開発（Far Cry 5）
- 33. Copyright CYBIRD Co., Ltd. All Rights Reserved. 33 ベータリリースやソフトローンチの活用報告（複数） Beta vs soft launch in mobile games Speaker: Mladen Dulanovic (Nordeus) Game as a service is dead Speaker: Michael Gordon (Iron Horse Games, LLC) 'C.A.T.S.' Postmortem: concept development through the eyes of a designer and artist Speakers: Eugene Yailenko (ZeptoLab), Aleksei Kalibin Atomsky (Zeptolab) 膨大な努力で開発した作品を、リリースの工夫でさらに上手く売るのも、また大事な 「生産性改善」！ 生産性改善：リリース前後
- 34. Copyright CYBIRD Co., Ltd. All Rights Reserved. 34 Game as a service is dead Speaker: Michael Gordon (Iron Horse Games, LLC) リリース直後にユーザーレビューで 評価を汚さない！ →ベータ公開を上手く使おう メタデータの調整によるDL率改善 スクリーンショット入れ替えサイクル アイコンの更新サイクル 生産性改善：リリース前後
- 35. Copyright CYBIRD Co., Ltd. All Rights Reserved. 35 Rocket League's Language ban system Devin Connors (Psyonix) やったこと チャット報告に対するバン作業自動化 当初、報告に人力で対応（対応工数が膨大、ユーザー視点では機能不全） 報告対応を自動化したことでCSが改善 ハラスメントレポートが 28,700件/90日→42800件/90日 やらなかったこと 報告に依らない「全チャットの自動監視」 テキストチャット以外の監視＆BAN 生産性改善：運営中（1）
- 36. Copyright CYBIRD Co., Ltd. All Rights Reserved. 36 Root causes in player behavior（パネルセッション） Dylan Rogerson : activision lead data scientist Ruth Toner :twitch senior data scientist kay chan : marketing manager east side games ( community team) Peter Alau : Spirit AI director of business (manage community) Fair Play Alliance なぜ人はオンラインサービスで 敵対的だったりネガティブな 発言をしてしまうのか、と いうパネル 統一の価値観のもと、適切に 管理しないとね、とのこと 生産性改善：運営中（1）
- 37. Copyright CYBIRD Co., Ltd. All Rights Reserved. 37 Robocalypse Now using deep learning to combat cheating in CS:GO John McDonald (Valve) チートプレイヤーの存在→小さくて もマッチングが汚れていく Trust Score : Good actors同士で プレイしてもらいたい 生産性改善：運営中（2）
- 38. Copyright CYBIRD Co., Ltd. All Rights Reserved. 38 チートプレイヤーの報告作業にML を併用できないか？ 人はチートユーザに気づくことがで きるようだ 機械学習の出番！ MLを利用することで、不正検出率 が上げられる→図 生産性改善：運営中（2）
- 39. Copyright CYBIRD Co., Ltd. All Rights Reserved. 39 VACnet 生産性改善：運営中（2）
- 40. Copyright CYBIRD Co., Ltd. All Rights Reserved. 40 話す人について 海外にみる「生産性改善」動向 技術選択 社内組織の改組 開発時 リリース前後 運営中（CS） まとめ アジェンダ
- 41. Copyright CYBIRD Co., Ltd. All Rights Reserved. 41 工数を減らす生産性改善 ＋ 手を掛ける生産性改善 GDCたのしいよ ESTAは早めに申請してみようね まとめ
- 42. Copyright CYBIRD Co., Ltd. All Rights Reserved. 42 タイトルの収益改善のためにやれることがもっとある 「赤字と黒字では、たとえ1円でも、全く違う」 宮川洋 (イード CEO) 生産性をアップして、事業の継続性を高めて、これからも皆で作品を楽し く作っていきましょう！ Takeaways
- 43. Copyright CYBIRD Co., Ltd. All Rights Reserved. 43 ご清聴ありがとうございました サイバードでは、いっしょに開発・運営する仲間を募集しています！ Contact: masatoshi_ito@cybird.co.jp
Editor's Notes
- はい、サイバードの伊藤です。 今年のGDCはすっかり機械学習ブームに飲まれていましたが、今回伊藤の受講テーマは「生産性向上」でした。 生産性というのは、ご存じのとおり、投下する資源と、得られる成果の比率で、これを改善してアプリケーションのライフタイムバリューを上げるために各社頑張ってましたので、関連セッションをご紹介します。 また、今回私は急遽代打でGDCにいくことになったのですが、いくつか困難がありましたので、GDCに緊急参戦することになった場合の知見も共有できればと思います。
- というわけで、「代打でも何とかGDCいけるものだなあ」という話です。 今回の主役はESTAです。
- ESTAについては、ウェブでといろいろ出てくると思います。 米国の入国管理に関連するシステムで、2001年の同時多発テロを受けて入国審査を厳密にしたいけど、人手は掛けられないという状況での仕組みです。
- 事前審査、というところがポイントです。
- 今回GDCについては、当初の参加予定のひとが、ESTAに引っかかって渡米できなくなり、伊藤がかわりに行くことになりました。
- 実は申請にあたって注意点が提示されていて（改ページ）
- 幾つかの国については名指しで渡航経験をチェックするよといっています。
- 当初予定の参加者に、「イラン渡航歴」があったんですね。
- このひと何しにイランに行ったのかというと、奥様と観光だそうです。 ちなみにこの方、ハネムーンがジンバブエだったそうです。
- 「急遽の渡米」ということについて、今回いろいろと学びがありました。 1つめの学びとして、直前に飛行機を取るツラさですね。 GDCは会場がサンフランシスコですが、直前では直行便がとれないです。 行きは成田からサンフランシスコに向かったのですが、乗り継ぎが2回ありました。
- ポートランドにまず入りまして、
- さらに、ポートランドからロサンゼルスへ。 ロサンゼルスからサンフランシスコで、ようやく到着。待ち合わせもあるので、直行便よりざっと8時間ぐらい長くかかった感じですね。
- 帰りは乗り継ぎ1回（サンフランシスコ→アトランタ→成田）でしたが、いったん東海岸側に飛んでから、戻ったので、直行便より12時間ぐらい長くかかりました。 というわけで、飛行機を直前に取ると、疲れる、時間を使いすぎる、というのがわかりました。
- 第2の学びはホテルですね。 直前にホテルを探すと、いいところ・安いところがないです。 今回は、ちょっと治安の課題を抱えてるエリアで、レーティングが2/5なホテルを選択。 右下はCrime Mapですが、かなりリスキーな場所だというのが見て取れます
- ちなみに会場のモスコーニセンターは右下のあんまり赤くない一角ですが、それでもすぐ近くが赤いです。 会場近くでのパーティもよく行われますが、そこからの帰路についても、気をつけるようにしてください。
- はい、まとめます。 1，渡米にあたっては、ESTAは早めに申請しましょう ESTA申請時、現地滞在先の記入欄があります。 ホテルの予約と同時に申請してしまうのがおすすめです ESTA申請時と実際の渡航時の投宿先が異なるのは問題なさそうでした。 2，サンクコストに引きずられないよう、状況によっては諦めも肝心です。 サンクコストといってるのは、GDCチケット代とか、さいしょのひとのフライトやホテルの費用です フライトやホテルの追加費用や、リスキーなホテルを使ってまでする渡米なのか、考えましょう。いざとなったらチケット代は諦めましょう。 とはいっても、先ほど紹介したクライムマップにあるとおり、そもそもモスコーニに近い場所はかなりリスキーなので、どこでもいっしょという気もしますが。
- ちなみに、もしESTAで拒否されても、ビザが発給されれば入国は可能です ビザの発給は最短4営業日とのことですが、要求される資料類が多いらしいので、 余裕を持って準備する必要があります。 あと、ビザ入国時はリアル「Papers, Please」をがんばってください。 ここまで3分で片付ける
- はい、 あらためまして、海外にみる「生産性改善」動向 という視点でのセッション紹介となります。 簡単に自己紹介させていただいたのち、 プロジェクトの時系列にだいたい沿う感じで 生産性改善に関するセッションをご紹介していきます。
- 簡単に自己紹介です。 サイバードの伊藤 雅俊 と申します。 左はうちのウサギです。 右は中本目黒店の蒙古タンメンです。辛いものは大好きですね。
- だいぶまえになりますが、RBB SPEED TESTという回線速度測定サービスを開発したりもしました。
- このほか、オライリー「ゲームクリエイターが知るべき97のこと 2」に寄稿させていただいています。 自己紹介はこのぐらいにして…
- サイバードでは、イケメンシリーズの技術とインフラもみています。 イケメンシリーズは、スマホ用の女性向け恋愛ゲームのシリーズで、アプリリリース開始から6年目になります。 ちなみに、非常に息の長いシリーズとなっていて、2012年にリリースのイケメン王宮は現在も運営しています。
- GDC最終日の日本人飲み会では、北米の女性ライターさんから「イケメン幕末、日本語でやってます」と言っていただいたりしました。
- こちらが、先月、3月14日にイベントで発表した新作、「イケメンライブ 恋の歌をキミに」ですね。事前登録受付中ですので、ご興味のある方は是非。 このへんで6分経過
- では本題へ。 生産性改善ということで、開発コストの抑制や、改善の高速化、販売数の増加、CSの向上によるセールス改善といったいろいろな側面がありますね。
- 「Multi-platform production from day zero」、スピーカーはイド・イエヘリさん。 インディデベロッパーがローコストに対象マーケットを広げるための技術選択ですね。 HTML5で開発することで、iOS/Android/Mac/Windows/Linux等に出しているという、売りきりのガワアプリの話でした。 左下は、このイドさんのプロダクトの販売ページの一つですね。ペイパルで9.99ドル。 ただし、統合的にQA進めていくツールは見当たらないらしく、デバッグは課題とのこと。 あまり体制的なデバッグはおこなえてないようでした。 もう一つの課題は、ソース管理でプラットフォームごとになっているブランチを統合したい、とも話していました。 ちなみにGDCでは、このように会場の通路脇スペースを使って、スライド使わずにおこなうショートセッションもありますが、聞いていると昼食が取れなくなります。 （改ページ） 8分
- 続いては、社内組織を改組したBungieの事例です。 タイトルは「Teams are stronger than heroes」です。 Distiny2での事例で、アニメーション、アート、デザイン、テスト、エンジニアリングといった技能別の部署をごく小さなファンクショナルチームの集合体に組み替えたという内容でした。 UIやサンドボックス、レイド、戦闘など、機能ごとに、そうしたファンクショナルチームを割り当て、それぞれのチームでアジャイル開発をおこなうという体制にしたそうです。 開発の進捗状態をみて、チームの割当数を変えたりするのがマネージャーの仕事だ、といってました。 （改ページ） 10分 20180321 GDC #7 Teams are stronger than heroes: Bungie development evolved Patrik O'kelley Head of Production - Destiny 2 power of small team framework organization agileかどうかは問題ではない origin story もともとanimation/art/design/test/engineeringでそれぞれプロダクションを組んで、全体のプロダクションを構築していた destiny でチャレンジ 人が増え、チームが増えた。コミュニケーションラインがハードになってきた コンプレックスマップ Part1 小さいクロスファンクショナルチーム 26年で最初のアジャイルチーム 最初にプルーフコンセプトして、そこから全社展開した P2 destiny2 ここで本格的にスモールチームによる開発を開始 新しいスケールのコミュニケーション問題 60の小さいチーム クロスチームの方向性コーディネーションが新しいチャレンジ プレイヤーエクスペリエンスファースト experience team 6～7チームの緩やかなかたまり。 サンドボックスとかも 中央の強力な推進役は？ 小さいプロダクトではともかく、大きいプロダクト part3 Project leaders AreaProductOwner teams program layer teamlayer = small team/user story part4 TODAY scaled agile for games area例 combat キャラクターのモーキャプから設定からサウンドからAIから、、、 1) build areas as systems of teams , not just collections of teams 2) re-think the producer roll as as scale aslige process owner 3) balance unified vision v, autonomy using scaled creative direction 4) なんか 写真なし small team 3つ asset team1ユニット 標準化したパイプライン support team 1 unit leadership team 1unit (producerとAPO) singletons 7 units (writerとか) service team 2(HR/IT) 2:scaled agile process owner producer re-think the producer role as a acale agile process owner producer V. AGILE process owner trad. producer: focus on time / budget keep it fun a team that enjoys working together is unstoppable unit based planning スケジュール 3: scaled creative direction balance unified vision versus local team autonomy using scaled creative direction task out stories project leaer main game directorはビジョンをシェアする。 APOは独立に進める セカンドレベルAPOも必要になる PLからAPO、さらにしたに、、パイパーディテイルなビジョンがおりてくる the servant トラディショナルなコマンドコントロール式ではなく サーバントリーダー scaled agile rituals establish quartery plannning day widen your perspecitive うーん、これAAAタイトルで開発に数百人投入する会社だなぁ、、、 うちに採用できるか？ そもそも社内チームはすでに近い形に分割され始めている ただ、変化をウェルカムする文化をなんとか creative facetime アイディアについて話すためのsafe areaを作る closing plan review 小さい目標をclosingし続ける 大きいアイディアは小さく分割、優先順位をはっきり。 毎日進捗させるためのもの。 メンターシッププロセス small team closing plan review questions what big feature work remains? when do we forecast we wil be done? what is our projected close out plan? what risks do we have? wehat is our bug volume and velocity? what is our transition plan? トリアージチーム か、、、 Part 5? 会社、プロダクトごとに、答えを探せ そりゃそうだ、、、
- これほどドラスティックな組織改編をおこなったという点もすごいのですが、タイトルにある「チームはヒーローよりも強い」ということについて、わざわざGDCで（改ページ） 10分 20180321 GDC #7 Teams are stronger than heroes: Bungie development evolved Patrik O'kelley Head of Production - Destiny 2 power of small team framework organization agileかどうかは問題ではない origin story もともとanimation/art/design/test/engineeringでそれぞれプロダクションを組んで、全体のプロダクションを構築していた destiny でチャレンジ 人が増え、チームが増えた。コミュニケーションラインがハードになってきた コンプレックスマップ Part1 小さいクロスファンクショナルチーム 26年で最初のアジャイルチーム 最初にプルーフコンセプトして、そこから全社展開した P2 destiny2 ここで本格的にスモールチームによる開発を開始 新しいスケールのコミュニケーション問題 60の小さいチーム クロスチームの方向性コーディネーションが新しいチャレンジ プレイヤーエクスペリエンスファースト experience team 6～7チームの緩やかなかたまり。 サンドボックスとかも 中央の強力な推進役は？ 小さいプロダクトではともかく、大きいプロダクト part3 Project leaders AreaProductOwner teams program layer teamlayer = small team/user story part4 TODAY scaled agile for games area例 combat キャラクターのモーキャプから設定からサウンドからAIから、、、 1) build areas as systems of teams , not just collections of teams 2) re-think the producer roll as as scale aslige process owner 3) balance unified vision v, autonomy using scaled creative direction 4) なんか 写真なし small team 3つ asset team1ユニット 標準化したパイプライン support team 1 unit leadership team 1unit (producerとAPO) singletons 7 units (writerとか) service team 2(HR/IT) 2:scaled agile process owner producer re-think the producer role as a acale agile process owner producer V. AGILE process owner trad. producer: focus on time / budget keep it fun a team that enjoys working together is unstoppable unit based planning スケジュール 3: scaled creative direction balance unified vision versus local team autonomy using scaled creative direction task out stories project leaer main game directorはビジョンをシェアする。 APOは独立に進める セカンドレベルAPOも必要になる PLからAPO、さらにしたに、、パイパーディテイルなビジョンがおりてくる the servant トラディショナルなコマンドコントロール式ではなく サーバントリーダー scaled agile rituals establish quartery plannning day widen your perspecitive うーん、これAAAタイトルで開発に数百人投入する会社だなぁ、、、 うちに採用できるか？ そもそも社内チームはすでに近い形に分割され始めている ただ、変化をウェルカムする文化をなんとか creative facetime アイディアについて話すためのsafe areaを作る closing plan review 小さい目標をclosingし続ける 大きいアイディアは小さく分割、優先順位をはっきり。 毎日進捗させるためのもの。 メンターシッププロセス small team closing plan review questions what big feature work remains? when do we forecast we wil be done? what is our projected close out plan? what risks do we have? wehat is our bug volume and velocity? what is our transition plan? トリアージチーム か、、、 Part 5? 会社、プロダクトごとに、答えを探せ そりゃそうだ、、、
- 「チームメンバーが自由に発言できることが重要」（改ページ） 10分 20180321 GDC #7 Teams are stronger than heroes: Bungie development evolved Patrik O'kelley Head of Production - Destiny 2 power of small team framework organization agileかどうかは問題ではない origin story もともとanimation/art/design/test/engineeringでそれぞれプロダクションを組んで、全体のプロダクションを構築していた destiny でチャレンジ 人が増え、チームが増えた。コミュニケーションラインがハードになってきた コンプレックスマップ Part1 小さいクロスファンクショナルチーム 26年で最初のアジャイルチーム 最初にプルーフコンセプトして、そこから全社展開した P2 destiny2 ここで本格的にスモールチームによる開発を開始 新しいスケールのコミュニケーション問題 60の小さいチーム クロスチームの方向性コーディネーションが新しいチャレンジ プレイヤーエクスペリエンスファースト experience team 6～7チームの緩やかなかたまり。 サンドボックスとかも 中央の強力な推進役は？ 小さいプロダクトではともかく、大きいプロダクト part3 Project leaders AreaProductOwner teams program layer teamlayer = small team/user story part4 TODAY scaled agile for games area例 combat キャラクターのモーキャプから設定からサウンドからAIから、、、 1) build areas as systems of teams , not just collections of teams 2) re-think the producer roll as as scale aslige process owner 3) balance unified vision v, autonomy using scaled creative direction 4) なんか 写真なし small team 3つ asset team1ユニット 標準化したパイプライン support team 1 unit leadership team 1unit (producerとAPO) singletons 7 units (writerとか) service team 2(HR/IT) 2:scaled agile process owner producer re-think the producer role as a acale agile process owner producer V. AGILE process owner trad. producer: focus on time / budget keep it fun a team that enjoys working together is unstoppable unit based planning スケジュール 3: scaled creative direction balance unified vision versus local team autonomy using scaled creative direction task out stories project leaer main game directorはビジョンをシェアする。 APOは独立に進める セカンドレベルAPOも必要になる PLからAPO、さらにしたに、、パイパーディテイルなビジョンがおりてくる the servant トラディショナルなコマンドコントロール式ではなく サーバントリーダー scaled agile rituals establish quartery plannning day widen your perspecitive うーん、これAAAタイトルで開発に数百人投入する会社だなぁ、、、 うちに採用できるか？ そもそも社内チームはすでに近い形に分割され始めている ただ、変化をウェルカムする文化をなんとか creative facetime アイディアについて話すためのsafe areaを作る closing plan review 小さい目標をclosingし続ける 大きいアイディアは小さく分割、優先順位をはっきり。 毎日進捗させるためのもの。 メンターシッププロセス small team closing plan review questions what big feature work remains? when do we forecast we wil be done? what is our projected close out plan? what risks do we have? wehat is our bug volume and velocity? what is our transition plan? トリアージチーム か、、、 Part 5? 会社、プロダクトごとに、答えを探せ そりゃそうだ、、、
- 「スーパースターであってもでもToxicな言動を認めない」 と触れる場面もあって、けっこう問題になっていたんだろうなぁというのが伝わってきました。 （改ページ） 10分 20180321 GDC #7 Teams are stronger than heroes: Bungie development evolved Patrik O'kelley Head of Production - Destiny 2 power of small team framework organization agileかどうかは問題ではない origin story もともとanimation/art/design/test/engineeringでそれぞれプロダクションを組んで、全体のプロダクションを構築していた destiny でチャレンジ 人が増え、チームが増えた。コミュニケーションラインがハードになってきた コンプレックスマップ Part1 小さいクロスファンクショナルチーム 26年で最初のアジャイルチーム 最初にプルーフコンセプトして、そこから全社展開した P2 destiny2 ここで本格的にスモールチームによる開発を開始 新しいスケールのコミュニケーション問題 60の小さいチーム クロスチームの方向性コーディネーションが新しいチャレンジ プレイヤーエクスペリエンスファースト experience team 6～7チームの緩やかなかたまり。 サンドボックスとかも 中央の強力な推進役は？ 小さいプロダクトではともかく、大きいプロダクト part3 Project leaders AreaProductOwner teams program layer teamlayer = small team/user story part4 TODAY scaled agile for games area例 combat キャラクターのモーキャプから設定からサウンドからAIから、、、 1) build areas as systems of teams , not just collections of teams 2) re-think the producer roll as as scale aslige process owner 3) balance unified vision v, autonomy using scaled creative direction 4) なんか 写真なし small team 3つ asset team1ユニット 標準化したパイプライン support team 1 unit leadership team 1unit (producerとAPO) singletons 7 units (writerとか) service team 2(HR/IT) 2:scaled agile process owner producer re-think the producer role as a acale agile process owner producer V. AGILE process owner trad. producer: focus on time / budget keep it fun a team that enjoys working together is unstoppable unit based planning スケジュール 3: scaled creative direction balance unified vision versus local team autonomy using scaled creative direction task out stories project leaer main game directorはビジョンをシェアする。 APOは独立に進める セカンドレベルAPOも必要になる PLからAPO、さらにしたに、、パイパーディテイルなビジョンがおりてくる the servant トラディショナルなコマンドコントロール式ではなく サーバントリーダー scaled agile rituals establish quartery plannning day widen your perspecitive うーん、これAAAタイトルで開発に数百人投入する会社だなぁ、、、 うちに採用できるか？ そもそも社内チームはすでに近い形に分割され始めている ただ、変化をウェルカムする文化をなんとか creative facetime アイディアについて話すためのsafe areaを作る closing plan review 小さい目標をclosingし続ける 大きいアイディアは小さく分割、優先順位をはっきり。 毎日進捗させるためのもの。 メンターシッププロセス small team closing plan review questions what big feature work remains? when do we forecast we wil be done? what is our projected close out plan? what risks do we have? wehat is our bug volume and velocity? what is our transition plan? トリアージチーム か、、、 Part 5? 会社、プロダクトごとに、答えを探せ そりゃそうだ、、、
- 生産性改善のために、エンジンをリニューアルしたという事例です。 ハンガーサーティンの「Mafia III」についての報告ですね。 自社エンジン開発あるあるです。 エンジンを更新したのは、データが増大したり、チームの拡大やスタジオ拠点が分散したことに対応するため、ということでしたが、新しいエンジン・新しいエディタのプロダクション投入が、MafiaIIIの開発開始から1年目とのことで、開発の最中に環境の変更やデータのマイグレーションが必要になって、苦労したとのこと。 三宅さんは浪花節といっていましたが、ツール入替やデータマイグレーションなどについては、聞いててちょっと背筋がもよもよするものでしたね。 （改ページ） エディタのプラグインは古い環境のものが継続して使えるようにしたり、 金曜の夜はコミットして帰る！月曜からまたがんばろう！ ＃それ知ってる、あかんやつや 12分 why rebuild game engine? - more data - bigger team - multiple studio locations Major changes New world editor New object system Build system Local iteration Visual scripting Middleware integration Physics Animation Navigation UI Audio 20180322 GDC #7 Mafia III mafia 3 open world 3rdperson action adventure storydriven yet not linear rel oct 2016 why rebuild game engine? - more data - bigger team - multiple studio locations 物量10倍 pain points - world editor - difficult to use pipeline - very bad iteration times - no asset management - code bound entity system エンティティとコードが結びついてる goals - more accessible tools - able to deal with large amounts of data - data driven old world editor bread and butter for most content creators obsolete technology used (Winapi) difficult to extend we had lot of other c# based tools new world editor goals increase productivity simple to extend production ready ASAP new world editor decisions -new tool in C# / WPF w/ DevExpress -Integrate old editor plugins in new editor -use c++ /cli for engine communication -get users involved c# and WPF - it is indeed falster to write tools - difficult to write responsive tools - it is difficult to hire engineers with WFP experience - devexpress has its issues - directx9 support only(WPFの制約？) integrate old editor plugins winAPI plugins fluently integrated in .NET app thre is a price performance of whole editor old plugins dont fit nicely use c++/cli for engine communication it looks ugly and doesnt support modern c++ linking was very expensive >70minutes?? debugging is slow and not reliable get users involved early on shared ownership iterative development based on early feedback trap of too many iterations dealing with layout/colors too soon lesson learned C# and devespress was a good cchoice WPF not so much c++/cli was terrible choice involving users early on is great keeping winapi plugins was necessary 2nd topic : object system new object system asset and file management inheritance and grouping empowering content creators asset and file management goals easy tracking of dependenncies support binary and text format with minimal effort identify objects by ID backward and forward compatible asset and file management decisions use c++ reflection for serialization every object has asunique identifier use c++ reflection for serialization very simple for engineers to expose data reasonable backward and forward compatibility no need for versioning system strong code-data dependency every object has a unique ID free movement of assets around service reading TOC and tracking IDs Easy to query for dependencies There were a lot of objects we had to disable them for some classes unique ID system issues serivice on the background is quite annoying you cant copy files anymore export from external tools is tricky inheritance system increase reusability of assets easy to use by engineers by content creators ability to override anything(システム由来の制限なし） dealt within serialization code based on reflection and unique IDs no restrictions of what can be modified It workded out great but... comapring parent with child on save is fragile 継承した先での変更がうまく保存されないことがあった resave dependents - we didnt figure out how to fix in production - intoroduced a" feature" to resave dependents -very difficult to understand when to use it empowering content creators -ability to compose objects - grouping of objects together - object level scripting flexibility advantages -content creators get more powwful -bery fast prototyping of new features - some prototypes can turn into features as is flexiblity disadvantages - loss of control グルーピングシステム 13オブジェクトぐらいをそうていしったのが1006オブジェクト、とか。 -generic approach is not always great -object level scripting is scary lesson learned - having unique id per object is great generic inheritance system based on comparing parent with child is tricky giving power to user exceeded our expectation everything that the tech allows will be used 3rd point: Deploymen context for release - production started before we were done - we spent a year in isolation - painflu merges from main branch - long data conversions changing plans - world editor and object system together - changed our mind on backward compatibility qa testing - qa involved very early for tools just 3months before deployment for game - game testing was simple - world editor testing was not very effective Power User testing - power user group assembled! - we got better feedbck - quality of feedbacku declined rapidly - lost focus on throw away work - importance of having real goals training people - power users helped again - presentations of new tools and concepts - workstation with new world editor last days before deployment - merging to new engine branch everyday - locking tricky content on main branch - moving some gameplay engineers ahead of time d-day friday everyone submits and go home early dealt with the move over weekend monday everyone golas ot office and starts working on new branch production helped twith setting up everyone post deployment issues not found by power users or QA found few rare workflows engineers didnt know about early feedback not very positive deployment lessons - deployment breaks illusions 期待値コントロール - testing on aritificial content is not effective - missing documentation/explanantions - new features were misusesd or misunderstood inheriting object instead of copying still copying files outside of our tools first year ater deployment - latent issues like resave dependents - lot of bullet proofing - explosion of new components conclusion - upgraded to modern engine -faster learing curve for new users （ああ、これはいいね - consistent control for editor - deployment during production is not fun Bright future we were mature on release DLC production proved the technology
- FarCry5写真は撮らないでねということだったので、テキストで。 プロシージャルを利用しましたよ、というテクニカルアーティストの方からの報告。 Houdiniですね。 もはや手作業で作れる物量ではなく、 自然なフィールドを生成するために、ツールチェーンの整備していて、 崖の地層表現や、生物群系を生成しています。 崖の地層表現 前作→技術使わず（手作業） 今作→ツールチェーン化 Biome（生物群系）の表現 →生物・地学で習ったような話が多数→自然なエレメント配置を実現 Deterministicに生成できるので、条件に変更がなければ、ビルドし直しても同じ生成物が得られる ことで、安心してビルドを回せるし、分散して生成させることができる、ということですね。 （改ページ） 14分 20180322 GDC #2 farcry 5 procedural world generation etienne carrier technical artist introduction / challenges goal of the pipline available procedural tools users point of view pipeline overview cliffs tool in detail biomes tool in detail change of plan conclusion automated - houdini - houdii engine - nightly builds on build machnes deterministic ->複数マシンで分割生成してつながるuserfriendly shelf tools in the editor easy to manage by the users tools freshwater fences and powerline cliffs biomes fog worldmap 4 users point of view terrain terraforming pass freshwarter fresh warter lake/river/stream/warterfalls cliffs generating cliff mehes and terrain biomes painting biomess point of interest setup location roads/ pipeline DUNIA2 <- farcry game engine and game editor | | Houdini from dunia to houdini world information file paths terrain sectors splines and shapes heightmap biome painter 2d terrain masks houdini geometory ptytyon script terraiin is the main input: baking procedural outputs from houdini to dunia entity point cloud terrain texture layers terrain height map layers 2d terrain data geometory terrain logic zones data is saved temporarily as buffers on disk entity point cloud vegetation assets rocks collectibles decals vfx ... tools interconnectivity 上から freshwaters roads fences& powerline clifffs biomes fog worldmap 6 cliff tool previous tech tool input stratification geometory shapes previous tech : none terrain slope slope terrain data-> slope threshold->cliffs input prepare geometory remeshing geological stratification(地層 creating geologic strata strata angle RGB input 地層の角度をRGBで入力できる split noise split geometry optimizing geometory reduce triangle count spilit for export: geometry is divided per sector cliffs shader crumbled rocks erosion エクスポート 7.biome tool generate terrain abiotic data occlusion flow slope curvature illumination altitude - latitude-longitutde- wind imporing 2d data -biome painter data -procedually generated data main biome sub biome (grasses) sub biome (forest) power lines clearing viability 必要な半径で生き残る種が決まる forest canopyの再現 age パラメータ signed distanc field from biability age -> size, distance density サイズごとの可能な密度のコントロール color: インスタンスごとの色のバリエーション viability age terrainにあわせたローテーション 見ずに向かう草 斜面の木 風向きで傾く草 FC5 レシピ biome、604824 entitiesが生成・設置されてる 8 change of plan biome painter gradient vs boolean 最初はグラデーションの予定だった 重なりのデバッグが難しい biomeの結果はグラデーションなしのほうがよかった （good？） terrain data pre-caching on disk 9 conclusion lessons learnded - with great power comes great responsibiity - design elegant tools that opens up possibilities - keep things simple - listen to your users/ observe your users 作業してるところとかよく見よう テラフォーミングを手作業でやってたり - be flexible - balance between control and automation
- 開発に投入した工数を毀損しないリリースというのも、また大事な「生産性改善」です。 よく見かけたのがベータリリースやソフトローンチを上手く使いましょうという発表で、 Google Playの機能を活用した事例が複数報告されてました。 私が受講した中では、3つで、 Beta vs soft launch in mobile games Game as a service is dead 'C.A.T.S.' Postmortem: concept development through the eyes of a designer and artist 画像はCATSのポストモーテムですね。 いろいろなデザインを試したという報告でした。 デザイナー・アーティストの目を通して、とタイトルされていますが、マネタイズ・スケーリングを狙って、ユーザーの反応を見ながらビジュアルデザインを調整して、ソフトローンチをしっかりやった、という事例です。 （改ページ） 16分
- こちら、Game as a service is deadという講演ですね。 ベータリリースで、ユーザーレビューで評価を汚さずに提供を開始できるので、うまくつかいましょうという話。 フィーチャーグラフィックの差し替えでダウンロードは10%程度よく出来る、といった話や、 ASOにはメタデータの調整も重要で、Bundle idはASOに効果があるが、”game” “free”といったワードを説明に入れてもASOには効果が無い、といった話をされていました。 （改ページ） よく見かけたのがベータリリースやソフトローンチを上手く使いましょうという発表 16分
- ロケットリーグの、自動バンシステムについての講演もありました。 このあたりは、運営中のサポートコストの適正化、ユーザーリテンションの維持、やることはいろいろありますね、という話です。 問題のあるチャットをおこなったユーザーについてのバンの自動化 当初、報告に人力で対応していたのですが、対応工数が膨大になるわりに、ユーザー視点では機能不全という状態になっていました。 報告対応を自動化したことでCSが改善した、という報告ですね。 人手でやっていた頃は、ひどい順に手作業していたものが、 自動化してからは報告に対して全数対応できるようになり、 報告して対応される、という安心感を与えたからか、報告数も増加したそうです。 ハラスメントレポートが 28,700件/90日→42800件/90日 報告のあったチャットログを洗って、スコアを個別に設定されたワード（GRAM）でスコア化してバンを実施するというものですが、当初20gramだったそうです。 完全監視＆自動化だと、友達同士のラフな会話にも反応するおそれがあり、これはやってないとのこと。 ツールを手にしても、それをどのくらい適用するかが重要ですね。 困ってるユーザーを放置しない！！という姿勢はコミュニティにたいして大事ですね。（改ページ） 18分
- 類似テーマとして、「Root causes in player behavior」というパネルもありました。 これはフェアプレイアライアンスというブリザードやCCPなどが参加してる団体によるものです。 なぜ人はオンラインサービスで敵対的だったりネガティブな発言をしてしまうのか、というパネルだったのですが、統一の価値観のもと、適切に管理しないとね、と言うことをいってました。 オンラインサービスはレストランのようなもの。「料理が美味くても、フロアスタッフがいなかったり、犬を店内で走らせてるやつがいたりしたら、レストランとしてはだめだろう？」とのこと。 （改ページ） 18分
- で、運営中の改善の2つめとして、こちらはValveによる、Counter-Strike: Global Offensiveでのチートプレイヤー対策の話です。 MLによるチートの検出についてCS:GOでの知見の紹介ですね。 Good actors同士でプレイしてもらいたい、ということを言ってました。 左下のようになると、どこにもチーターが混じってしまうけど右のようにもし組み合わせられれば、Good Actor同士でマッチングさせられるよね、ということですね。 （改ページ） 20180322 GDC #8 Robocalypse Now using deep learning to combat cheating in CS:GO CSのチートをDLで検出するやつ 19分 CSGOにおけるチート aim assist information assist Good news trust score use match making. trust visualized. trust score、6ヶ月間で管理、らしい。 mitigate exploits speedhack, RNG prediction はサーバーサイドの改修やデザインで使えなくなってる 悪人も努力して（？）進化している。 クライアントサイドは検出、サーバーサイドはcorrelationsで。 brief interlude on DL build possible function y = f(X) DL がなければプログラマーが書く DLはパターン認識ですごく活躍。 トレーニングと inferencingの2モード。 MLとDLは、DLがせまい 人はチートを認識できるようだ、ならばDLだ！ OWは99.9%だが、これは2けたぐらい足りない 人がやる経路だけでなく、 VACNETというDLを追加した 改善した VACNETはかなり高精度で報告できる ゲームで必要なシステム replay format replay の送信と
- ざっくり言うと、人はチートしているユーザに気づくことができるようだ。ならば人が出来ることを、「よくわからないけどできるようにする」のがMLなので、適用してみよう！ということですね。 人の報告を前段に置いた場合は精度が低かったが、MLを前段に置いた場合は精度が上がった、ってことで、 人が報告すると15～30％の的中率 VACnetというのは約3500基のプロセッサを搭載したMLのシステムで、こちらを使うと80～95％の的中率だった、とのことです。 （改ページ） 20180322 GDC #8 Robocalypse Now using deep learning to combat cheating in CS:GO CSのチートをDLで検出するやつ 19分 CSGOにおけるチート aim assist information assist Good news trust score use match making. trust visualized. trust score、6ヶ月間で管理、らしい。 mitigate exploits speedhack, RNG prediction はサーバーサイドの改修やデザインで使えなくなってる 悪人も努力して（？）進化している。 クライアントサイドは検出、サーバーサイドはcorrelationsで。 brief interlude on DL build possible function y = f(X) DL がなければプログラマーが書く DLはパターン認識ですごく活躍。 トレーニングと inferencingの2モード。 MLとDLは、DLがせまい 人はチートを認識できるようだ、ならばDLだ！ OWは99.9%だが、これは2けたぐらい足りない 人がやる経路だけでなく、 VACNETというDLを追加した 改善した VACNETはかなり高精度で報告できる ゲームで必要なシステム replay format replay の送信と
- VACnetというのはこういうサーバですね。 3456プロセッサで、将来的に2倍の構成に上げる想定だそうです VACnetに検出させたい場合、ゲーム側には、リプレイフォーマットと、リプレイを蓄積・送信する機能が必要ってことでした。 （改ページ） 20180322 GDC #8 Robocalypse Now using deep learning to combat cheating in CS:GO CSのチートをDLで検出するやつ 19分 CSGOにおけるチート aim assist information assist Good news trust score use match making. trust visualized. trust score、6ヶ月間で管理、らしい。 mitigate exploits speedhack, RNG prediction はサーバーサイドの改修やデザインで使えなくなってる 悪人も努力して（？）進化している。 クライアントサイドは検出、サーバーサイドはcorrelationsで。 brief interlude on DL build possible function y = f(X) DL がなければプログラマーが書く DLはパターン認識ですごく活躍。 トレーニングと inferencingの2モード。 MLとDLは、DLがせまい 人はチートを認識できるようだ、ならばDLだ！ OWは99.9%だが、これは2けたぐらい足りない 人がやる経路だけでなく、 VACNETというDLを追加した 改善した VACNETはかなり高精度で報告できる ゲームで必要なシステム replay format replay の送信と
- ということで、セッションの紹介としてはここまでとなりますが、
- 生産性改善は「人を減らす」こととイコールじゃない、というのを改めて見せてもらえたのが今回のGDCの収穫だった 数値で追いかけながら、手をかけ続けることも生産性改善ということで、アプリケーションのライフタイムバリューを上げることを目的に！ GDCたのしいです。 特に、AAAタイトルを投入するスタジオが報告してくる改善が、驚くほど泥臭かったりして楽しい！！ 一方で、アピールしてなんぼのアメリカ文化圏なので、自慢話にしか聞こえない話も多いですが、あわないと思ったら別のセッションに異動しちゃいましょう。 入退場は基本的に自由なので！ ESTAは早めに申請してみようね なかなかない体験でした 20分
- エンジニアには、タイトルの収益改善のためにやれることがもっとあります。 「赤字と黒字では、たとえ1円でも、全く違う」、というのは、ゲームメディアのインサイドやGame☆Sparkを運営しているイードのCEO、宮川洋 さんがおっしゃっていた言葉です。 生産性をアップして、事業の継続性を高めて、これからも作品を楽しく作っていきましょう！ ということをお伝えして、、、（改ページ） 22分
- 私の発表は以上となります。 ご静聴、ありがとうございました。 一緒にイケメンシリーズを作る仲間 ＆ 運用する仲間を募集しています！