スタッフ/インタビュー一覧/2021年

このページには最終編とそれ以降のネタバレが存在します！！
直接のネタバレはある程度隠してありますが、ネタバレされないことを保証するものでは一切ありません。
ネタバレ部分はクリックで表示できます。

スタッフ | 声優 | コンテンツ別担当スタッフ | デスク紹介集
インタビュー一覧（ 2025年 | 2024年 | 2023年 | 2022年 | 2021年 ）

---

2021/12/03 [プログラミング] ブルーアーカイブ「アロナ」の声を作った「クォン・ミンソプ」エンジニア （Inven） †

Inven に掲載されたKwon MinSeob (GreenGarnet) 機械学習エンジニアの書面インタビュー。

内容は概ねNDC22でのKwon MinSeob氏の講演と重複している。
本インタビューだけに載っている主な情報をまとめると以下の通り。

• Kwon MinSeob 氏は大学院から2020年2月に入社した
  • キム・ヨンハ統括PDがもともと、TTS（Text-To-Speech）がキャラクターとプレイヤーのコミュニケーションを重視する本作の重要なフィーチャーになると考えており、その流れでブルーアーカイブの開発に参加した
• NDC22で出た実績・研究トピック以外に、音ゲーの楽譜作成支援も行った
• 生徒が先生の名前を呼ぶことは技術的には可能。ただし、事業的、企画的に解決しなければならない課題が多く、まだ実装できていない。問題が解決すれば、個人的にはぜひ実装してみたい

2021/06/09 [ビジュアル] [NDC21-ビジュアルアート&サウンド] 〈ブルーアーカイブ〉アートディレクション †

Nexon 主催のゲーム開発者向けカンファレンス「Nexon Developers Conference 2021」で行われた、hwansangことキム・インアートディレクターの講演。

主に、ブルーアーカイブという新規ゲームをアートディレクションするにあたって、方向性の設定や意思決定をどうしたのかがメイン。

以下、字幕をOCRしてDeepLで翻訳したものと、スライドからまとめた要約。

はじめに †

自身の経歴 †

私（hwansang）はこのような経歴を持っています。

• 2013年-2015年 KOG Studios / エルソード
• 2015年-2016年 Nexon Korea / メープルストーリー2
• 2016年-2018年 KOG Studios / エルソード
• 2018年- NAT GAMES / ブルーアーカイブ
• NDC18講演 「エルソード」3次転職ビジュアルコンセプト ポストモーテム

セッション発表の理由：アートディレクション経験の共有機会不足 †

アートディレクションは、目指す人が多いわりに他の分野に比べて経験談が共有される機会が少なく、海外の文献や映像を参考にすることが多いという課題認識があります。

技術的な話よりも、方向性の設定や意思決定のプロセスを中心に、私の経験をお伝えできればと思います。

アートディレクターの定義：ビジュアルの方向性を決める役割 †

まず、アートディレクターとは何かを定義したいと思います。私にとって、アートディレクターとは、単に視覚的な美しさを追求するのではなく、ビジュアルの方向性を設定する役割を担うと考えています。そして、プロジェクトを進める中で、現状と目指す方向性とのギャップを明確化し、調整していくことが、ADの重要な業務と言えるでしょう。

ブルーアーカイブにおける挑戦課題 †

ブルーアーカイブでは多くの課題がありました。新規IP、美少女ゲーム、日本市場への対応、3D+SD、次世代ビジュアル、遮蔽物を利用したリアルタイムバトル、初コラボのメンバーが多いなど。

不明確な状況の中で、特に、以下の3点について大きく悩んでいました。

1. ビジュアルの方向性
2. 意思決定の方法
3. チーム全体で同じ絵を愛情をもって一緒に描いていく方法

セッションの目次 †

セッションの目次は以下の通りです。

• PART #1 方向性設定　　　　：どこへ向かうべきか
• PART #2 魅力的な要素の発見：何が違うのか、何を目立たせるのか
• PART #3 土台づくり　　　　：どのように土台を固めるか
• PART #4 強化　　　　　　　：何を、どこまで強化させられるのか
• PART #5 まとめ　　　　　　：一緒に、同じ方向を探って進むということ

PART #1 方向性の設定 †

1.1 アート合流当時の状況 †

ブルーアーカイブは2018年3月にプロジェクトが開始し、アートは6月から合流しました。入社時の戦闘ビジュアルはこんな感じでした。

アートデザインの前提としては、以下の通りでした。

1. サブカルチャーベースのキャラクター収集型ゲーム
2. 遮蔽物を挟んだ遠距離戦闘
3. 戦闘のビジュアルは3D、キャラクターはSD等身大

1.2 市場分析と差別化戦略：「明るい」×「カジュアル」 †

当時、市場ではミリタリー物の擬人化萌えが人気を集めており、同時に中国の二次元ゲームが台頭してレッドオーシャン化が進んでいました。例：「艦隊これくしょん」（2013年）、「アズールレーン」（2017年）、「少女前線」（2017年）

また、特筆すべきこととして、ビジュアル様式がファンタジーから徐々に現代、近未来コンセプトの重厚なものに移り変わりつつありました。

そこで、「明るい」vs「重厚」と「ハードボイルド」vs「カジュアル」の2軸4象限で考えた場合に、「重厚」×「ハードボイルド」の象限はレッドオーシャン化が進み、対照的に「明るい」×「カジュアル」な方向性に需要があると考え、基本的な方向性を設定しました。

1.3 世界観とキービジュアルの確立：IPの核となる価値を凝縮する †

方向性が決まったら、次に世界観とキービジュアルを具体化しました。

目指す世界観やアートデザインを決めるにあたっては、以下の3つの問いかけに明らかに「YES」と答えられるということをまず前提にして考えました。

1. 戦闘後の平和な日常生活があるか？
2. うつ病やPTSDとは程遠い世界観か？
3. 青春物やラブコメディができるか？

キービジュアルは、アートが今後目指すIPの核となる価値を凝縮したイメージを作り出すのが目的でした。「青春/部活/ミリタリー/青春学園物/明るい未来像」という私たちが考える理想的な世界観の雰囲気とビジュアルの方向性が、新しく入って来たメンバーに見ただけで伝わる、百聞は一見にしかずというものを目指しました。

1.4 IP独自の象徴となるモチーフの導入：ヘイロー †

基本的な方向性と雰囲気が決まったあとに、IPとしての象徴性となる要素を考えました。

「ブルーアーカイブ」では「ヘイロー」をモチーフとして採用しました。キャラクターデザインだけでなく、世界観や背景にも「ヘイロー」を溶け込ませることで、一目で「ブルーアーカイブ」の世界観だと認識できるような、独自性の確立を目指しました。

1.5 制作基盤の準備とR&D：品質基準の模索と試行錯誤 †

世界観と象徴的な要素が決まったら、各アート分野の制作基盤を整え、R&D（研究開発）を行いました。

この段階で、ビジュアルの品質基準を模索しました。後々になると変更が難しくなるため、この期間が品質基準を探るためのゴールデンタイムとなります。狭い範囲で、さまざまな試行錯誤をすることが重要だったと思います。

基準となるような制作物を作るにあたって、以下の3点を特に重視しました。

• ストーリー性：ストーリーが見えるか
• 拡張性：他の媒体での拡張性が見られるか
• クリーン・清々しい：日常・学園ものの清涼感を表現できているか

この中でも特に「拡張性」を重視し、新規IPで美少女ゲームというジャンル特性上、再創造・再創作されやすいように、簡素化とストーリーテリングを意識しました。キャラクターデザインは、分かりやすく視覚的に扱いやすいようにし、世界観の面でも、同僚やユーザーが参加したくなるようなシチュエーションを描いたビジュアルを提示したいと考えました。

1.6 IPのコアキーワード：美少女、ミリタリー、学園、育成恋愛 †

以上のプロセスを経て、「ブルーアーカイブ」というIPのコアキーワードを以下の4つに絞り込みました。この4つのキーワードが、ビジュアル面だけでなく、ゲーム全体の開発方向性を示す重要な指針となりました。

• 美少女　　：集めたくなる様々な美少女
• ミリタリー：遮蔽物を活用したリアルな現代戦ビジュアル
• 学園　　　：爽やかな学校生活、部活をベース
• 育成・恋愛：攻略、恋愛したい魅力的なキャラクター

Part #2 魅力要素探し：差別化とユーザー満足度の追求 †

目指す方向性とIPとしての土台を決めた次のステップは、「どんな魅力をユーザーに提供するのか？」という問いかけでした。

大きく「日常」と「戦闘」の2つの領域において、市場で差別化できる要素を模索しました。

そして、魅力要素探しの前提としてまず以下の3点を考えることで、答えを導こうとしました。

• チーム特性：何を一番よく理解し、できる組織なのか？
• ユーザーにどのような満足感を与えることができるのか？
• 市場での差別化ポイントは？

2.1 チーム特性 †

私たち開発チームは、オタクとして特に90年代から2000年代初頭のアニメ文化への理解がベースになっているメンバーが多くを占めていました。

• 90年代のヒロイン：美樹本晴彦の影響・おてんば娘ヒロインなど比較的立体的な性格・作画のキャラクター
  • 
• 00年代のヒロイン：京アニを中心に全体的に作画が低年齢化・キャラのフォーマット化で立体的な面が少なくなったが、アプローチコストが低くなった
  • 

また、何よりも、以下のコンセプトワークに見られるようなキャラクターの魅力と日常感を、初期に参加したチームメンバーが大きな強みとしていました。

そこで、私たちのチーム特性は軽快でさわやかなビジュアルを提供するのに適したチームではないかと判断しました。

2.2 ユーザーに与える満足感・市場との差別化ポイント †

次に、ユーザーに与える満足感について考えました。

例えば「艦隊これくしょん」についてみてみると、コンセプト＝軍艦、商品＝キャラクター、価値＝キャラクターとの関わり、となっていると考えました。つまり、顧客が実際に購入しているのは、日常生活で得られるキャラクターの愛情と好感度なのではということです。

もしそうであれば、「関係指向」vs「目的指向」と「重い」vs「軽い」の2軸4象限のうち、「関係指向」かつ「軽い」の象限に、答えがあると考えました。したがって、コンセプトを「美少女ミリタリー学園恋愛シミュレーション」にしたら面白いものが見つかるのでは、という考えにつながりました。

そのうえで魅力を探った結果、特にインタラクションを重視しました。美少女キャラクターとのインタラクションで重要なのは、やはりムードとアイコンタクト、この2つに絞れるのではと思います。

こう考えた上で、「性的」vs「情緒的」と「静的」vs「ダイナミック」の2軸で考えると、既存市場のキャラクターは「性的」アピールと「ダイナミック」な動きに焦点をあてている状況だと思いました。そのため、動くことがメインではなく、共感が中心となる感性的なアプローチをしてみようと考えました。

偶然、ゲームの基本コンセプトが学園物でもあったので、以前から需要のあった制服美少女と感性的な絵柄にフォーカスをあてて開発に取り入れました。

2.3 メモリアルイラストの制作 †

以上の考えでR&Dを進めた結果、ロビー画面を埋め尽くす「メモリアルイラスト」を作ることにしました。

制作においては、「生きているような環境感」「多彩な表情変化」「インタラクション（頭をなでた時の反応・目線の追従など）」の3点を工夫し、本作の魅力となるようにしました。

2.4 SDモデルの開発：感情表現に適した設計 †

さらにイラストだけではなく、SDモデルも感情表現に適した方向で開発しました。これは、スキルカットイン・カフェでの反応・編成でのつまみモーションなどに反映されています。

2.5 戦闘におけるインタラクション：オブジェクト破壊や敵との交戦 †

戦闘においても、インタラクションを重視しました。オブジェクトの破壊や敵との交戦の様子を通して、ユーザーがゲーム世界に没入できるような演出を心がけました。

2.6 アート構成におけるポイント：美少女との触れ合いが最優先目標 †

以上の魅力要素の開発においては、美少女との触れ合いを最優先目標としました。アートの構成要素がキャラクターとのコミュニケーションのための仕掛けとして機能するように、構成を工夫しました。

Part #3 土台作り：組織拡大に伴う課題と解決策 †

魅力的な要素を確保した後には、どうやってチームで同じ絵を描けるように土台を固めるられるのか？ が次の課題でした。

方向性と魅力要素が決まると、急速に採用や生産スピードが加速しました。それに伴い、「組織運営」「方向性の共有」「追及する価値の理解・浸透」といった新たな課題に直面しました。

3.1 組織構成と役割・責任の明確化 †

まず、アート分野ごとの組織構成とR&R（役割・責任）を明確にしました。これにより、初期に比べて組織がやや硬直化しましたが、多くの人数が一緒に協業するには早めに定義したほうが良いと考えました。

3.2 フィードバックプロセスの定義 †

定期的なミーティングと、フィードバックのプロセスの枠組みを決めました。これは、突発的なフィードバックによる組織の硬直化や不安感を減らすためです。どのタイミングと段階で決定権者が介入するのか、を定義することで懸念を解消しようとしました。

3.3 振り返り文書とガイド文書の作成：ノウハウの蓄積と共有 †

各分野で実施したポストモーテム（例：プロトタイプの振り返り）の内容や、作成したガイド文書（例：ロビーイラストガイド）などを共有することで、新規メンバーがこれまでの意思決定、成果物、規約を参照し、スムーズにプロジェクトに参画できる環境を整えました。

3.4 コミュニケーション促進：1on1面談や情報共有チャネルの活用 †

定期的な1on1面談も実施しました。シニアおよび役職者を対象（最大時9名）とし、情報共有および潜在的な問題の議論をしました。

また、作業用Slackチャンネルでの情報共有と相談、週単位での定期報告と記録保存によるタスク・制作物の可視化、アニメ上映会やトレンド・好み・技術共有を主催する窓口設置も行いました。

3.5 基準点となるものの明確化：トーン＆マナーの確立、PV制作 †

しかし、生産量が増えるにつれ、魅力度が基準に到達しなかったり、制作完了までの試行錯誤が多すぎるなどの課題が発生しました。

これらの課題が起きるたびに指示を出すようなことをしては、長期的に耐えられないと判断しました。そこで、ADが常に指示を出さなくても、チーム全体が共通認識を持って制作を進められるよう、基準点となるものを明確にする必要性を感じました。

まず、アートトーン＆マナーの確立を試みました。キーワード・文脈・色・パターンなど、分野ごとのガイド文書を集めてアートワーク全体を貫くトーン＆マナーを定義し、ガイド文書にまとめました。さらに、そのトーン＆マナーを体現するマスコットキャラクター「アロナ」を制作しました。アロナは、チュートリアルや業務ページ、ガチャなど、様々な場面に登場し、アートワークの統一感を保つ役割を担っています。

つぎに、プロジェクトの公開が近づくにつれて、プロモーションビデオ（PV）の制作にも着手しました。PVにも、トーン&マナーと世界観の雰囲気・主要な登場人物と勢力を盛り込みました。PVは、外部へのマーケティングツールとしてだけでなく、内部の開発メンバーにとっても、世界観やアートの方向性を共有するための重要なツールとなりました。

PV制作を通じて、やはり、伝達力としては映像媒体が一番いいんだなという思うようになりました。また、2Dアニメーションの制作方式とチーム構成を借りることで、いままでバラバラになっていた作画・色彩・美術の基準をまとめられるきっかけにもなりました。

3.6 基準点とアイデンティティの確立＝伝えたいことと見せ方の明確化 †

これらの取り組みを通して、IPとしての基準点とアイデンティティを確立することができました。これは、「自分たちが何を伝えたいのか」「どのような魅力をどう見せるのか」をユーザーに伝える前に内部で明確にすることでもあり、こうしないと、ユーザーにも魅力が伝わらないと考えていました。

Part #4 強化：更なる品質向上と独自性の追求 †

アルファ版開発段階になりビジュアルが安定期に入ったころ、「何を、どこまで強化していくか」という新たな課題に取り組み始めました。

4.1 開発後半当初：マイクロマネージメントと個人制作作業 †

開発の後半では、「反復」と「磨き上げ」を重点的に行いました。業務としては、運営とアートQA（品質管理）の２つに集中していました。

出来る限り避けようとは思っていたのですが、結局マイクロマネージメントをしてしまいました。*1その過程で FGT(Focus Group Test)、クローズドβテストなどのフィードバックを受け、3Dキャラクターの体型調整、カットインの品質向上など、ユーザー体験を向上させる改善を行いました。

また、個人としては空き時間でNPC制作・シナリオサポート（カットイン制作）・マーケ向け制作を行いました。

4.2 オープン後に提供する価値の検討と2nd PVへの凝縮 †

しかし、突然不安になりました。「オープン後はどうすればいいのか、その問いかけが放置されているのでは？」
そのためこの時期に、オープン後にはどのような視覚的価値を提供するのか、どのように市場での新鮮さを維持するのかを考えました。

開発者としての視点ではなく、いちユーザーとしてキャラクターゲームを楽しむ理由を考えた結果、「世界観への共感」「キャラクターへの愛情」が重要な要素であることに気づかされました。世界が直面している危機や冒険、キャラクターの信念や動機、ユーザーが注いだ愛情への敬意、これらがキャラクターゲームをするときの楽しみなのではと感じたのです。

したがって、ナラティブ（物語）に答えがあると考えました。私たちは、私たちだけが与えられる視覚的な経験と物語について議論し、その結果を凝縮した2nd PVを制作しました。

この2nd PVは、オープン後のアート制作の方向性をしめす基準として機能しました。

4.3 成果 †

そして、ついに「ブルーアーカイブ」はリリースを迎えました。

秋葉原に掲示されていても違和感がないゲームであってほしいと願っていましたが、実際に広告が掲示されるといった成果をあげることができました。

多くのユーザーに楽んでいただけていることを嬉しく思うとともに、当初のビジョンを実現できたことに達成感を感じています。

Part #5 まとめ：一緒に、同じ方向を探って進むということ †

5.1 新規プロジェクト開発における心構え †

新規プロジェクトの開発は、未知の領域への挑戦であり、一人ではなく共に歩むことです。「特定の完成形を目指す」のではなく、「どのようなものを作るのかを確認する」プロセスという気持ちで取り組むことが重要です。

「去去去中知　行行行里觉（行くことで知り、進むことで悟る）」という老子の言葉のように、運に頼らず小さな失敗をたくさん・早くすることで確認しながら進めていく、という心構えが長期プロジェクトでは重要でした。

5.2 自分の軸を確認する †

一番自分の軸が分からなくなりストレスがあったのは、戻るにも遠いし進むにも遠い、プロジェクトの中間地点にいるときでした。

特にアートは、新規IPとして差別化された魅力を求めれば求めるほど、事例がなく周囲を説得する難易度があがります。そのような時こそ、自身の軸をつかむ原動力として、最初の決断の際に抱いていた「確信」＝自身が納得したことを、自身との対話で確認していく必要があります。

5.3 ディレクターの役割：進むべき道を照らす灯火となる †

プロジェクトを成功に導くディレクターの役割は、自分自身が「進むべき道を照らす灯火」となることです。ADとして、常にその時、その環境、その場所で、自分にしかできない選択や決断が何なのかを常に考えていたと思います。

5.4 一緒に進める仲間の存在 †

共にプロジェクトを推進してくれた仲間たちがいたから、揺らぐことなく進められたとも感じています。振り返ると本当に無理な選択が多かったのですが、「狂気も一緒なら孤独ではない」という言葉通り、一緒に進められたから乗り越えられたと感じています。

5.5 最後に †

今日、このような場で私の経験を共有できたことを光栄に思います。この話が、これからゲーム開発の道を歩もうとしている方々の、少しでもお役に立てれば幸いです。

2021/06/09 [PD] [NDC21-キャリア] ゲームPDになってみて †

Nexon 主催のゲーム開発者向けカンファレンス「Nexon Developers Conference 2021」で行われた、キム・ヨンハPDの講演。

キム・ヨンハ氏の、過去から現在までのPD（Project Director）としての経験から、PDのやるべきこと・やってはいけないことを語っている。

以下、字幕をOCRしてDeepLで翻訳したものと、スライドからまとめた要約。

1. イントロダクション †

1-1. 発表内容 †

プロジェクト管理や開発方法論についての発表はよく見かけますが、PDの視点からの苦労や試行錯誤についての発表はあまりないように思います。そこで今回は、「ゲームPDになってみて」というタイトルで、PDの仕事についてのレビューをしてみたいと思います

もしかしたら個人的な体験談になるかもしれませんが、「PDってこんな風に考えていたりするんだな」と思っていただければ幸いです

1-2. 発表の背景と動機 †

私が尊敬する開発PDの方々の写真を載せてみました。

• ニール・ドラックマン（アンチャーテッドシリーズ・The Last of Us シリーズ）
• 桜井政博（星のカービィシリーズ・スマッシュブラザーズシリーズ）
• キム・ドンゴン（マビノギ・マビノギデュエル）

有名な方々なので、あえて説明はしませんがゲーム開発責任者、PD、総監督といえば、ほとんどの方がこのような方を思い浮かべるでしょう。開発者クレジットで見ると一番前に出てくる方々です

「私も将来はあんな風になりたい」という夢を持って、私もこの業界に入りました。そして時間が経ち、どうにかして私も開発PDになりました

頭の中に描いていたゲームを、皆さんが楽しそうにプレイしているのを見ると、やりがいを感じます。何かを残せたという達成感もありますし。好きな声優さんのサインをもらえたり、サプライズイベントもあります

でも！ 私が要領が悪かったのか、開発中・ライブサービス中のかなりの部分は「本当にこんな苦労をする必要があるのか...」という思い出が多いです

私はPDになってから、かなり試行錯誤を繰り返しました。なので、これからPDのキャリアを検討されている方、あるいはこれからキャリアをスタートされる方に「こういったことは知っておいたほうがいいですよ」みたいな、ちょっとオヤジみたいなセッションを用意することにしました

1-3. 自己紹介 †

私は20世紀にプログラマーとして業界に入った21年目の開発者です。近年はPDを担当し、リリースしたゲームには「魔法図書館キュラレ」「FOCUS on YOU」「ブルーアーカイブ」があります

発売までには至りませんでしたが、MMORPGやアクションといったジャンルも開発しました

1-4. セッション目次 †

このセッションは以下の流れで進みます

1. ゲーム開発PDの仕事
2. 私のPDキャリアの振り返り
3. PDがやるべきこと
4. PDがやってはいけないこと
5. PDとしてやってみて良かったこと

2. ゲーム開発PDの仕事 †

2-1. PDの定義 †

PDの定義は、2013年にイ・ウンソクディレクターがNDCで発表された資料によくまとまっています

簡単に言うと、PDはゲーム開発の責任者、意思決定権を持ち完成まで責任を持つ人だと言えると思います

韓国では、開発責任者の肩書きとしてディレクター、総括ディレクター、PD、プロデューサーが混用されており、厳密に分けることは難しいです。私もスマイルゲートやNAT GamesではPDでしたが、Nexonの公式文書基準ではディレクターとなっています

なぜ混在しているのかというと、プロジェクトの人数によって開発責任者の視点が変わるからだと思います。小規模チームの時は、直接コーディングをしたりテーブルの値を扱うレベルで実務をしますが、規模がある程度以上になると、大きな単位で作業を見るように視点を変えることになります。つまり、開発人数が30人未満の初期段階ではディレクター、それ以降、人数が増えるとどんどんプロデューサーに近づくという感じですね

個人的には、PDと書いて総括ディレクター/Project Directorと読むことを好みます。管理だけに専念するよりも、開発実務者でありたいというエゴがあるためか総監督と解釈したいです

2-2. 開発方針の提案 †

PDの仕事は、まず「どこへ向かうのか」という旗を立てることから始まります。具体的なゲームコンセプト、開発に必要な費用、段階的な達成方法を盛り込んだ提案書を作成し、プロジェクトのスタートを切ります

ゲームコンセプト

企画書で最も重要ですごく難しいのは、どんなゲームを作るのかを明確にすることです

世の中にないゲーム、あるいは既存のゲームと差別化できる要素を言葉で説明し、説得する必要があります。肝心なのは、決定的な1ページでゲームのコアをアピールできるかどうかです

• ハリウッド映画のように、ゲームのコアを1～2行の文で表す「ログライン」を設定すると、コンセプトが明確になります
  • 例：「今までこんな捜査はなかった、昼はチキン屋、夜は潜入捜査」（韓国映画「エクストリーム・ジョブ」）
• ゲームではキービジュアルを作ったり、仮想スクリーンショットを作ったりする方法もよく使われます
  • 例：「FOCUS on YOU」提案書
  • 
  • コスプレ写真を撮った経験を生かして、VRの美少女恋愛シミュレーションを作りますとして上記の写真を添えました

でも、いつもR&Dの映像などの「必殺技」を用意できるわけじゃないんですよね

現場では、コアとなる企画をプレゼンしてガツガツとOKをもらうことよりも、経営陣と継続的なミーティングをしながら、どのような方向に行くかビルドアップしていくことが多いです

経営陣がどのような視点で市場を見ているのかを把握し、先例を提示しながら説明したほうが、より説得力を持つことができる場合が多いのですが、どうでしょうか？ ◯◯のMMORPGのビジネスモデルをベースに、SFのビジュアルを被せてゲームを作ってみます。こういうふうに言えるとすごく説明しやすいんですよね

そう簡単に説明できるものでなければ、経営陣とミーティングをして、チームでR&Dをしたり、プロトタイピングをしたりして、ある程度の形を整えた上で提案したほうがいいと思います

コスト

開発費用は主に人件費とその付帯費用、その他にゲームエンジン費用や外注費で構成されます。大きいほどプロジェクトのリスクになります。そして当然、売上目標は開発費用を上回るようにしなくてはなりません

しかし、だからといってコストをタイトに設定すると、痛い目を見ます。特に、初期人数が不足しないようにしないとプロジェクトが進みません。

私は、人件費はかけられる上限まで提案書に書くことをおすすめします

マイルストーン

開発成果物を確認する単位がマイルストーンというものです。プリプロダクションとかアルファとかベータとかそういう段階に区切られます。

成果物はプレイアブルなゲームの形であるのが一番いいですし、それが難しい場合は、映像とかリソースのイメージと企画のプレゼンで代用することになります

開発の進捗状況を確認するためのマイルストーンは、PDにとっては宿題の提出日とも言えます。業界標準は3〜6ヶ月ごとですが、短いスパンで経営陣に成果物を見せる機会を設ける方が、後々、大きな手戻りを防ぐことにつながります

2-3. 開発計画の実行 †

プロジェクトが始動したら、PDは提案内容が計画通りに実現することを、会社に証明し続ける必要があります

具体的には、仲間の採用、ゲーム要素のディレクション、マイルストーンの達成、リリースなどが挙げられます

詳細は、後述する「PDがやるべきこと」で述べたいと思います

3. PDキャリアのポストモーテム †

3-1. ゲーム業界入りして当初の約10年（1999年～2011年） †

• 1999年末、Phantagram にゲームロジックプログラマーとして入社
  • RTS「Kingdom Under Fire」
  • MMORPG「シャイニング・ロア」
• 2002年、ネクソンにプログラマーとして入社
  • 「マビノギ」
  • 「マビノギ英雄伝」

合計10年以上の間に、チーム長をしたり、ディレクターとして開発したプロジェクトがいくつかありましたが、すべてリリースすることができませんでした

この期間に私が成功させたと言えるのはNDC（Nexon Developers Conference）くらいだと思います。2007年の最初のNDCから2010年のNDCまで企画して主宰しました。NDCはゲームではありませんでしたが、良い経験でした

この期間に良かったのは、様々なチームで星の数ほどの技術を経験したことです。プログラマーもやったし、企画もやったし、チーム長として入社問題も出したし、面接官もたくさんやりました。ゲームディレクションの経験も積めました

当時、企画したことや技術目標を振り返ると、かなり挑戦的なことをたくさん試しました

15年前（注：2006年）ですが、クエストを自動生成するゲームで、自動的に同期されるネットワークオブジェクトベースでサーバーが動いたり、キャラクターのスカートにジグルボーンでなく布の物理を導入したり、無理をしすぎました。動くんだけど、従来の方法より全然いい感じになってないんですよ

教訓

1つ目「ゲームに新しい試みは、コストパフォーマンスを考慮して1つだけやろう」ということです

企画をしていると、技術的にも欲が出てきて、ゲームに新しいものをどんどん入れたくなりますよね。でも、ひとつひとつ掘り下げていくと、実際のゲーム開発の進捗は停滞してしまうことが多いんです。ただもちろん、チームと人によってキャパは違うかもしれません

2つ目「私は管理が苦手なんだ」という客観的な視点が得られたことです

スケジュール管理とか、仕事の分担管理とか、チームのメンタル管理みたいなのは苦手なんです

「いや、チーム管理が苦手なのにPDができるのか」と言われるかもしれませんが、この部分は同僚を通じて補完して、その分、自分の強みを生かすことができれば可能だと思います。私の場合は、PMや管理能力に強みがある同僚が補佐してくれて、今PDができています

3-2. 「プロジェクトB6」：経営との視点すり合わせの必要性（2011年～2012年） †

PDとして本格的に開発を始めたのが、アイデンティティゲームズで開発した「プロジェクトB6」でした

当時のチームはほぼオールスター級でした。以下のメンバーがいました

• 「マビノギ英雄伝」のクリエイティブディレクターだったイ・サンギュンディレクター
• 今はNetEaseにいるキム・ドクヨン ディレクター*2
• インディーズシーンで一番売れているハン・ダフン代表*3

成果物もかなりよく、1年で異なる方向性のかなり良いプロトタイプを2つ作りました

しかし、それでもドロップされてしまいました。いつの間にか会社が考えている方向性に合わないプロジェクトになっていました

アクションプロトタイプで最後に作ったゲームの映像を持ってきました。このゲームは、アクションMMORPGで複数の敵を相手にするのですが、攻撃を防いだり、倒して捕まえて壁に投げたりするアクションをサーバークライアント環境で実装していたのが特徴でした。今見ても悪くない出来栄えだったと自画自賛しています

良い経験として、有能な仲間と相乗効果を出すと開発がどのように動くのかを経験したことがとても大きかったです。当時の同僚は、私の足りないリーダーシップを補ってくれる人たちでした

目標を明確にし、欲を抑えて、スケジュール通りに目標を達成する開発をしたこと、そしてゲームとしては良い結果を生み出したことが10年くらい経ちますが、今でも良い思い出として残っています

教訓

得られた教訓は、経営陣の投資視点に合致しているかどうか、常に確認しなければならないということです

当時、会社の経営陣が変わり、新規プロジェクトへの投資余力が減っていました。それでも私は、開発の進捗さえうまくいけばいいと思っていました。甘かったというか、安易でした

この時に生まれた持論ですが、開発チェック会議のプレゼンだけでプロジェクトドロップは決定されません。チェック会議は、すでに決めたことを確認する場だと思うようになりました

3-3. モバイルゲーム「魔法図書館キュラレ」：長期の成長基盤とプランの必要性（2012年～2017年） †

B6のあと、「拡散性ミリオンアーサー」に影響を受けて、モバイルゲームを作りたいと思いました

自分が持っているキャラクターデッキを使って、MMORPGのレイドをするように、他のプレイヤーとリアルタイムの協力バトルができるようにしたらすごく面白そうだな、と着想して始めたプロジェクトでした

2012年末に開発に入り、2014年3月にリリースして、4年間サービスしたゲームです

このプロジェクトで良かったことは、作ったゲームが実際に自分でも満足できたことです。また、最初に考えていたよりも、ちょっとマニアックなゲームプレイになってしまいましたが、リリースして4年ほどライブサービスできました。プレイヤーの方々に影響のある波乱万丈なアクシデントもありましたが、愛されながらサービスをすることができたのはとても良い経験でした

ただ、残念だったのは、ゲームをもっと長くサービスできなかったことが悔やまれます

最初に考えていたゲームとしての「エッジ」は実装してリリースしましたが、長期的にサービスできる成長基盤とプランが整っていない状態でリリースしてしまいました。原因を振り返ってみると、「エッジ」だけでなく、ゲームの全体的な機能要素をバランスよく開発できなかったことが大きかったと思います

教訓

提案書ではエッジをアピールしてマイルストーンを達成することは重要ですが、実際にリリースしてサービスをするためには、サービス長期計画を立ててリリースする必要があります

PDは、もっと早くに業務を委譲して、長期的な視野で見るべきだったと思いました

3-4. VRゲーム「FOCUS on YOU」（2017年～2018年） †

「キュラレ」の直後に、実はもう一つモバイルのプロジェクトがあったのですが、当時はどの方向性が正しいか確信が持てず、自身でドロップしました。

「明確にやりたいことをやってみよう」と考えたプロジェクトが、「FOCUS on YOU」でした

コスプレ写真を撮っていた経験を活かして、撮影するゲームプレイを中心としたVR美少女恋愛シミュレーションを作るという、マニアックな企画を許可してくれた当時のスマイルゲート経営陣に感謝します

VR開発は初めてだったので、企画書を書く前に先行R&Dをしました。そこで試行錯誤を繰り返し、作った最初のステージデモがすごく好評だったので、その後は堅実に開発することになりました

その後、発売まで見届けられず、個人的な事情で途中で退職しました。それでも最後まで残ってゲームを完成させた同僚たちに感謝します

美少女恋愛シミュレーションとしては、VRでそれなりに意味のある結果を出したと思います。もしVRでプレイできる環境がある方は、ぜひプレイしてみてください

自分の手でリリースできなかったのは、とても残念です

3-5. 「ブルーアーカイブ」（2018年～） †

現在は、「ブルーアーカイブ」というゲームのPDを担当し、ゲームをリリースしてサービスを続けています

このゲームは、「美少女XCOM」を作ったら面白そうだと具体化したゲームです。これのどこがXCOMだ、と言われるかもしれませんが、私の観念的にはXCOMから始まったゲームでしたし、意図通りにゲームができたと思います

この話はあとで、「選択と集中」編でお話ししたいと思います

4. PDがやるべきこと †

重要だと思う順に書いてみました

1. 経営陣の信頼を得ること
2. 良い仲間を得ること
3. 選択と集中

実は、これは先ほどPDがやることだと言った、ゲーム要素を監督し、仲間をタイムリーに採用し、約束したマイルストーンの結果を出す。これのちょっと違うバージョンと言えます

4-1. 経営陣の信頼を得る †

PDは、プロジェクトが会社の期待する収益を上げられることを証明し続ける必要があります。そのためには、計画通りのマイルストーン達成が不可欠です

しかし、マイルストーンを計画通りに進めるだけでは不十分です。経営者の視点や評価基準は、1,2年経てば変化する可能性があります。評価基準が変われば、当初の計画通りにマイルストーンを達成すること自体が無意味になってしまいます。PDは常にその変化に敏感に対応する必要があります。

PDは、プロジェクトの方向性が経営視点に合っているか、継続的にフィードバックを受けながら、必要に応じて既存のマイルストーン計画を修正する必要があります。定期的に直接経営陣に会って聞いてみる、確認し、アピールする場を持つことが実は一番良いです

一番難しいのは、経営陣、PDのすぐ上の本部長や代表、取締役が新しく来られる場合です。2年、3年開発していると一度は経験することがあります。この時は、提案書を新たに書くような気持ちで信頼関係を再構築しなければなりません

もちろん、PD自身が会社の代表であればこのような問題はないのですが、代わりにもっと大きな問題、開発費の調達と運用、投資家との関係を維持することに気を使わなければなりません

4-2. 良い仲間を集める †

ゲームがどの程度の品質でリリースできるかは、完全に、どれだけ良い仲間と仕事ができるかにかかっています。

特にプロジェクトの初期メンバーは重要です。一緒に開発の方向性を決め、その後のプロジェクトリードを担当することになり、ほとんどの場合、最後まで一緒に仕事をすることになります

PDはどうにかして良い仲間を確保するしかないです。会社に入ってくる履歴書だけでは、リード級のメンバーを採用できないんです。そうなると、本当にあらゆる手を尽くします

ポートフォリオが見れるサイトを巡回して回ったり、求人している職種のコミュニティに入って会員登録をして求人を投稿したり、いろいろな方に連絡したり、直接会いに行ったり。私は内向的な性格なので、このような営業活動(?)は向いていないと思っていたのですが、本当に切羽詰まればやるようになります

これさえできれば、安定的に開発パイプラインが回るようになります。実際、「FOCUS on YOU」の場合、ステージ1までの開発は私が主導しましたが、直後に私が退職したあと、残った人たちがリリースまでしっかり仕上げてくれました。結局、ゲームを埋めて完成させるのは仲間たちなのです

また、特定の職種・ポジションの人を抜擢するだけでなく、PDの弱点をカバーしてくれる仲間を近くに置く必要があります。PDの弱点は、プロジェクト全体のリスクになることもあります

私の場合、ちょっと内向的な性格なので、外向的なコミュニケーションのできる同僚が定期的に議論を起こすのがチーム全体としては良かったし、管理面を補ってくれる同僚も必要です

4-3. 選択と集中 †

PDは、ゲームのどの要素を優先し、どの要素を諦めるか、常に選択を迫られます。頭の中にあったゲームを具現化するために、何を取って何を捨てるか？ これを繰り返して、ゲームのコアとなるものが何かを決めて守っていくんです

具体的に「ブルーアーカイブ」を最初に企画するときの選択プロセスを話します

まず、次世代のキャラクター収集ゲームをどのように作ろうかと考えました

• 画面にキャラクターをどれくらい出そうか？：たくさん見せよう
  • なぜなら、キャラ収集ゲームだから
• 戦闘方式は？：銃撃戦にしよう　
  • キャラクターがたくさん出てくるのに、近接アクションまでやったら大変 リソースコストもかかりそうだし
• 戦闘操作要素は？：ある程度必要だろう
  • なぜなら、銃撃戦を全自動で行うゲームは、「ドールズフロントライン」みたいなのがすでにあるし
• 戦略要素（マップ等）は？：大きくはできない
  • 戦闘操作要素があるなら、戦略要素まで複雑にするのは難しいだろうな
  • でも戦略マップは欲しいな

銃器+様々な戦況+SRPG？= 美少女XCOM
じゃあ、美少女XCOMみたいなものを作ればいいんだ！

「萌えXCOM」だから、うちのスタジオの名前はMXだと、ある日PDは意味不明なことを言いました

どうやってXCOMになるんだ？
仲間は聞きましたよ。で、PDである私はXCOMについてあれこれと話しながら、いろいろとペーパープロトタイピングをしてみようと言いました

そうして、再び選択の苦しみが始まりました。実話です。ニーズ別に様々なプロトタイピング、仮想ゲーム画面のスクリーンショット制作、企画作業を行いました

この過程で何を優先して、何を捨てて、どのようにゲームを作るかを決めることになりました。選択には正解がなく、結果をPDが責任を負わなければなりません

他の人がやったことのない選択肢は、本当に選ぶのが難しいです。「それをやってはいけない」という反対意見の合理的な理由を、百通り以上も聞かされるんです。私は、PDなら1つや2つくらいはそういうものを差別化ポイントにすべきだと考えるほうなので、どうしても必要なら、選択をします。リスクを負っても結果を出すのがPDの役割だと思います

PDはその選択が有効であることを証明するために、本当に多くのエネルギーを注ぐ必要があります。ただし、試行錯誤をどこまでやってみるか、という線引きはしっかりしておく必要があります。幸い、その試行錯誤の中で、PDの選択肢が有効であり生かせるという結論が出れば、ゲームのコアとなる要素として取り入れることができます

そして、選択するということは、結局他のものを諦めるということです。「ブルーアーカイブ」の場合は、「戦闘でキャラクターが魅力的に見えること」を最優先しました。それに付随する要素として、「遮蔽、隠れながら移動する戦闘」を選択しました。他のものはある程度妥協することにしました（妥協された項目として、資料には「レベルデザインのギミック多様化」「視覚的な戦況のわかりやすさ」「直感的な操作」「モバイルに適したゲームテンポ」「3Dキャラクターのディテールを最高に」「潜入中心のゲームプレイ」という項目が書かれている）

最初に考えていたキャラクターがたくさん出てくる半自動銃撃戦に、この要素をプラスして「萌えXCOM」というものの最終的な概念図はこのようにまとまりました

• リアルタイムでパーティーキャラクターが、絶えず隠蔽前進しながら銃撃戦を繰り広げます
• キャラクター数と画角を考えると、6等身を諦めてSDにする必要がありました
• キャラクターのスキルは自分で使うけど、キャラクターの移動は自動的に行われるようにするしかないと選択しました

これが最善の選択だったかどうかはわかりませんが、今振り返ってみても、幸い大きく間違った選択ではなかったと思います

PDはプロジェクトを通して様々な選択をし、責任を負います。ゲームがどのように具現化されるかだけでなく、何を優先するチームを作るか、スケジュールを優先するか、メンタルケアをしながら少し休むか、ビジュアルでスタイルを追求するのか、整合性を追求するのか、ビジネスモデルを追求するか、正解はありません

しかし、なぜそのような選択をするのかというPDの主観と論理が、ある程度一貫性を保つ必要があります

そして、選択は間違えることもあります、この場合は、素早く告白して修正する過程が必要です。告白と言いましたが、なぜなら選択によって間違った道を歩んできた仲間に申し訳ないからです

5. PDがやってはいけないこと †

PDが陥りやすい落とし穴についてお話します

1. スケジュールを楽観視する
2. マイクロコントロールする
3. 「割れた窓ガラス」を放置する

ここからは少し早口で説明します。なぜなら、「これは当たり前のことじゃないか？ 私が悪かっただけなのでは？」という気もするからです

5-1. スケジュールを楽観視する †

ホフスタッターの法則というものがあります。「スケジュールより遅れることを考慮しても、それでもスケジュールより時間がかかる」（"It always takes longer than you expect, even when you take into account Hofstadter's Law."）

スケジュールが狂うと締め切りギリギリに仕事が殺到し、同僚がバーンアウトするのを見ることになります。頑張っても、当初の目標を達成できなかったら、チームの士気は下がります。バーンアウトと士気の低下は、次のスケジュールに影響を与え、悪循環が続きます

PDがゲーム要素の品質目標マイルストーンを設定した場合は、どのように調整すれば目標達成できるかはPDしか判断できないため、PD自身がプロセスを細かく管理する必要があります。また、担当者の負荷が高くなるため、ケアも必要となります

また、PDはPM（Project Manager）からの現実的なフィードバックに基づき、スケジュールの精度を高める必要があります。

5-2. マイクロコントロールする †

PDがやってはいけないこと、二つ目はマイクロコントロールです

先ほど、品質は自分で管理すべきだと言いました。言っていることが逆だと思われるかもしれません

チームが大きくなりゲーム要素が増えると、PDは品質の判断権限を委任する必要があります。なぜなら、個々の要素の品質よりも、組み立てられたゲームとしての方向性がはるかに重要になってくるからです

品質の判断権限を委任しないと、担当者自身が品質を自律的に判断できない・判断しようとしないようになることで、PDがいないと回らないチームになります。すると、ますます委任が難しくなります。

PDが手を離すのは心配になりますが、PDが考える特定ゲーム要素の品質目標は一度合わせてしまえばわかります。実際、委任をしたほうが、に良いものができました。それが普通です

PDが入る実務会議もどんどん減らすべきです。「ブルーアーカイブ」でも最初は企画会議に全部参加してたんですけど、制作の段階に入ると、企画室長さん（注：イム・ジョンギュ2代目ゲームディレクター）から「PDさん、もう会議に入るのはやめてください」と言われてしまい、残念でした

でもそうなんすよね。プロジェクトが進むたびに、PDは一歩ずつ後退しながらゲームの全体的な方向性を見なければなりません。方向性がしっかり決まっていて、委任がされていれば、開発の途中でPDが抜けてもゲームはリリースできるのです

5-3. 「割れた窓ガラス」を放置する †

PDがやってはいけないこと、3つ目は割れたガラス窓を放置することです

割れたガラス窓一つを放置しておくだけで、その地点を中心として犯罪が広がるという説があります。些細な無秩序でも、放置しておくと無秩序がどんどん広がっていくということです。反論もある理論ですが

私はこの話を開発でも肝に銘ずる必要があると思います。プロジェクトが1年以上過ぎると、チームとしての脆弱性が少しずつ生じてきますが、放置して悪化するケースを何度も経験しました

特に、人間関係のトラブルが一番難しいと思います。

チーム間の仕事の進め方や利害関係が衝突したり、お互いに不協和音が続く問題が発生することがあります。そして、メンバー間の葛藤、不和が生じるという例があります

こういう問題は、発見するのも難しいし、口に出すのも難しい。なので、とりあえずもう少し様子を見ようということになることも多いのですが、だんだん慢性的な問題になってしまい、チーム全体のリスクになりかねません。いつの間にか、仲間が次から次へと言葉もなく辞めていくのです

そうなる前に手を打たなければなりません。私が鈍感だからかもしれませんが、私が「こんなこと気にする必要あるのか」って思う頃には、もうだいぶ問題が進んでいるんですよね

早い対応が必要です。基本的には面談ですが、チーム内だけでグズグズするのではなく、人事チームと相談したほうがよりスムーズに進むことが多いですね。人事チームは、チーム内で解決が難しい場合のオプションをたくさん持っています

6. PDとしてやってみて良かったこと †

最後のパートです。PDとしてやってみて良かったことを2つ、一種のヒントと言えると思いますが、挙げたいと思います

6-1. ステージ1の制作 †

ここでいうステージ1というのは、「ゲームのコアとなる要素をプレイできる一つの完成されたステージ」のことです

ゲームのコアとなる要素をプレイ可能な状態でいち早く完成させることは、PD自身や開発チームのモチベーション向上、そして外部へのアピールという点において非常に有効です

完成度の高いステージ1は、ゲームの方向性に自信を持ち、開発をスムーズに進めるための強力なツールとなります

私はできるだけ早く選択を行い、素早くステージ1に該当する「狙いが入った成果物」を作ってみることをお勧めします

例1：「FOCUS on YOU」のステージ1

Youtuber がプレイした「FOCUS on YOU」のステージ1の内容の一部を少し流してみました

音声認識によるキャラクターとのコミュニケーション、プレイヤーに近づいてくるキャラクターの臨場感表現とか、メインのゲームプレイである写真撮影が入っています

当時、このステージ1が動作するビルドができたとき、開発チーム自身も「こうすればいいんだ」という確信を得ることができました。開発ハードル会議もすごく良い評価で越えて、その後、いろいろなところでプレイしてみたいと言ってこられるようになりました

例2：「ブルーアーカイブ」のプロトタイプ

これはブルーアーカイブのステージ1を作る前のプロトタイピングです。先ほどの想像図を実際にゲームに実装してみる過程です

視点や敵と遮蔽物をどう配置するか、そして、そこに隠蔽をさせるテストをいろいろと行いました。このテスト結果を磨いて、ビジュアル的な狙いを入れて、2018年の年末にステージ1が完成しました

ビジュアルは短い期間にもかかわらず、それなりに良い感じに仕上がりました。リアルタイムでパーティーキャラクターが隠蔽、援護しながら前進して銃撃戦をするゲームというプレイコンセプトがうまく表現されていて、とても満足のいくビルドです

実はこの映像はもっと素敵な部分がありますが、今後のネタバレになりそうなので、適当にカットしました

このビルドのおかげで、スタジオ内外にどんなゲームを作るのかというビジョンを共有することができました

6-2. チーム内への継続的なメッセージの発信 †

PDは、プロジェクトのビジョン、目標、進捗状況などを、チーム全体に明確かつ定期的に伝える必要があります。そのためには、定例ミーティングや情報共有ツールなどを活用し、積極的なコミュニケーションを心がけることが重要です

具体的な例を挙げると、私たちのスタジオでは以下の取組をしています

• 毎週月曜日午前中の全体ブリーフィング
  • 先週は何を作ったか、今週の主眼は何かを共有
    • テキストが多すぎると集中力が落ちてしまうので、画像、アート成果物中心に
    • テキストが必要な部分は、重要な共有事項を中心に要約
• 特定のトピックの共有プレゼン
  • 担当者の間で共有すべきことを資料作成・プレゼン
    • この部分は、ADさん（注：キム・イン初代アートディレクター）がとてもよくやってくれています

このタイミングでちょっと宣伝します。今回のNDCにADさんがブルーアーカイブのアートディレクションについて録画されたセッションもありますので、そちらもぜひご覧いただければと思います

私たちのチームの場合、会議内容、特に企画会議は全てOneNoteに記録して検索できるようにしています。開発履歴を検索するとき、誰がどのような過程でどのような決定を下したのかを追跡できるのがとても便利です

また、あまりに基本的な内容ですが、Slackも積極的に使っています。趣味ごとのチャンネルまで含めると、私たちのスタジオの人数より開設されたチャンネル数が多いんです

もちろん、開発スタジオによって雰囲気は違うかもしれませんが、私の場合は、常に全体ブリーフィングを行い開発内容を共有することで、チームワークを深めるのに役立っていると判断しています

7. 最後に †

7-1. セッションのまとめ †

開発PDは、ゲームコンセプトを具体化し、実現に必要なコストを見積もり、実現可能な方法を提案します。「私、ゲーム開発してみます」と言い出す人です

提案が通ったら、仲間を募って開発監督を行い、約束どおりにゲームの完成させる責任を持つ人なのです

この過程でPDが気をつけなければならないのは、以下のことです

• 経営陣の視点をよく把握すること
• 可能な限り優秀な人材を確保すること
• 諦めれば楽だということ（注：ゲーム要素の選択と集中で諦める部分を決めること）

冗談のように言いましたが、先ほど説明した内容をもう一度見てください

また、PDとしてキム・ヨンハが何度も陥った罠をお伝えしました

• （当初の）スケジュールはこだわらず、PMの判断を信頼してください
• PDが実務に執着せず、委任した方がプロジェクトにメリットがあります
• チーム内で感情的に葛藤が生じるような問題が見つかったら、即座に対処してください

最後に、2つのヒントです

• ゲームのコアを差別化できる要素を選択したら、組み立てられたゲームの形でできるだけ早く確認してください
• 毎週のブリーフィングをコツコツと進めれば、チームの方向性を揃えるのに大きく役立つと思います

7-2. 締め †

おそらくこのセッションを見ている方は、ゲームPD、もしくはディレクターを志望している方や、そのような職務を始めたばかりの方だと思います

ゲームPDになってみると、「ここまでしなければならないのか？」という瞬間をたくさん経験します

ゲーム開発プロジェクトを進行させるのに、思ったより多くのエネルギーが必要で、メンタルが時折揺さぶられ、試練を受けます

でも、そんな困難を乗り越えてゲームを出すことができれば、それ以上の達成感を味わえる仕事だと思います

ということで、皆さん頑張ってください。私の経験談が少しでも皆さんのお役に立てれば幸いです

長々とした発表を最後までご覧いただき、ありがとうございました

コメントフォーム †