HackMD片岡凪Thur, Dec 5, 2019
この記事は、デジクリ アドベントカレンダーの5日目の記事です。
デジクリについてはこちらをご参照ください。
共同ゲーム開発の記録
この記事では、私が共同ゲーム開発で学んだこと、感じたことを雑多に記録しています。
各トピックの右上をクリックorタップすることでコメントを残すことができます。 質問、助言、提案、修正案などがありましたら気軽に残していってください。勉強になります。
目次
- 共同ゲーム開発の記録
- 目次
- 1. 企画概要
- 2. やったこと
- 3. 問題と対策
- 3.1. 企画発表用のスライドは作るべき？
- 3.2. プログラミング初学者へのレクチャーが不十分だった
- 3.3. 個々のメンバーの技量を把握せずに進行していた
- 3.4. 問題に対して動いている/動こうとしていることをメンバーに伝える
- 3.5. 大まかな締切設定が不十分だった
- 3.6. ゲーム性がブレている
- 3.7. シナリオとアクションが独立している
- 3.8. 企画書の変更後に軸を見直すべきだった
- 3.9. 開発方針がブレた
- 3.10. ディレクターが仕事をしすぎている
- 3.11. 後からリーダーを設けるのは難しい
- 3.12. プランナーのタスク過多
- 3.13. プログラマ向けの設計がなかった
- 3.14. データの場所が散乱していた
- 3.15. データの命名規則がバラバラだった
- 3.16. どこまでやれば完成なのかが曖昧だった
- 3.17. 要素過多
- 3.18. ゲーム進行が直感的でない
- 3.19. 完全なウォーターフォール開発になっていた
- 3.20. なぜその仕様ができたのか、流れがわからない
- 3.21. ディレクターやプランナーにメンバーの意見がいきにくかった
- 3.22. RPGを甘く見ていた
- 4. 今後の企画進行
- 5. おまけ：アイディアリスト
- 追記欄
- コメント欄
アホほど長いな…
1. 企画概要
1.1. 企画の経緯
この企画は、私が大学の創作サークル デジクリ で2019年5月に立案したゲーム開発企画で、企画名はRGBRPG企画といいます。
幣サークルではイラスト、プログラミング、音楽などを創作しています。私は、各分野のメンバーと共同制作を楽しみたい、共同開発ならではの経験を得たいという気持ちを持っており、その用件を満たすものとしてゲーム開発を発足しました。
私たちは、開発したゲームを同年11月のデジゲー博（ゲーム頒布イベント）で頒布することをひとつの目標としていました。
しかし、一部の進捗が滞ってしまったり、開発終盤でプログラムの結合が上手くいかなかったりするなどして、デジゲー博までに完成することができず、当日は体験版のみの頒布となってしまいました。
2019年12月現在は、存続意思を確認したメンバーと反省点を絞り出し、イチから見直して作り直しています。 完成の見積もりは春ごろになるかと考えています。
1.2. ゲーム内容
1.2.1. 企画発表時の内容
企画発表時の資料はこちらです。長いので要点をまとめます。
Image Not Showing
Possible Reasons
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
当初は光の三原色(RGB)の陣営と色の三原色(CMY)の陣営が争い合う2DアクションRPGを提案していました。RGBのRGが混ざるとCMYのYに、CMYのCMが混ざるとRGBのBになったりする性質が面白いです。全部混ぜたら白や黒になったりするのも、正義と悪でストーリーが作りやすそうで良いと思っていました。
RPGにしたのは単にRGBRPGという語呂が良かったというだけで特にこだわりはなく、メンバーへは自分たちの作りたいものを作ろうと話していました。言ってしまえば良い共同開発ができれば何でもよかったので、 資料の内容は全てメンバーと改変していく気持ちでいました。
そのほか資料には、光やペイントの色を駆使した遠距離攻撃で争うというゲームシステム、マップシステムや操作システムの提案、募集人員と大まかなタスク、会議の運用方法や使用プラットフォームなどの提案を載せています。
1.2.2. 2019年12月現在の内容
下に添付した、デジゲー博で使ったPVやポスターをご覧いただくとわかりやすいです。
ゲームタイトルは『Remake -Alice in WonderMind-』となりました。不思議の国のアリスの世界観をオマージュし、不思議な国に迷い込んだ記憶喪失の少女がアリスと共に世界の出口を探す旅を始め、人間の心理に苦悩しつつ世界の真理に近づいていく。そんなストーリーが描かれています。
ストーリーの合間には、絵筆を振り回して物理的に大小の敵を倒していくアクションがあり、並行して、魔法のように遠距離攻撃のごとく色付きの図形を生成し、色とオブジェクトを利用した様々なギミックの解除や謎解きを行います。開発中盤から、ゲーム性のウェイトはシナリオ6割、その他4割としてプランニングされていました。
進行は、初代マリオのようにカメラはキャラクターの横にあり、基本は左から右へ進みます。エリアによっては上下へ移動したり扉をくぐったりもします。ライフがゼロになればゲームオーバーとなります。
Image Not Showing
Possible Reasons
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
1.3. 開発の方針
何度か繰り返しメンバーに話していた、漠然とした開発方針です。
1.3.1. 共同ゲーム開発は高難度だと常に意識する
軽い気持ちで参加してもらうのは困る、という考えもありますが、難しいがゆえに、
失敗したときに挫折せずに気楽に再トライしてほしいという願いや、高望みしすぎずに期日に間に合う現実的な手段を選んでほしいという願いがあります。
これは手を抜いて良いということでは決してなく、制限のある中で実現し得る最高のものを作りたいという考えがあります。制限の少ない大企業が作るような最高のゲームを思い描いて開発を進めると、制限の多い私たちは必ず失敗します。現実的に制限の限界を目指す過程は、一見すると手を抜いているようにも見えかねませんが、他人に誇れるような良ゲームを高い確率で実現できる良い手段の過程であると考えています。
私やご助言をくださった先輩方は、幣企画に開発メンバーが30人近くいたこともあり、大きなものが作れるとメンバーが錯覚してしまうのを恐れていました。開発者が多くとも、その大半は共同開発経験のない1～2年次の初心者であり、更には開発期間が半年と短かったので、大規模なものを作ろうとするのはかなり厳しかったといえます。
現実的に考慮してプレイ時間が1時間前後のものを作ろうと打ち合わせしていたのですが、その1時間前後にすらかなりの労力を要し、完成させることも叶いませんでした。
1.3.2. 学べて楽しい "過程" を重視したい
企業のゲームクリエイターはお金という生活がかかった報酬がありますが、学生サークルの共同開発における報酬は主に経験と楽しさしかありません。したがって、ゲームには質も大事ですが、学生から経験と楽しさを奪うとモチベが存在しなくなり、質どころか完成すら怪しくなってしまうため、経験と楽しさはかなり重要であると考えます。
楽しむには各々が主体的に動く必要があり（人によっては受動的に制作するのが好きなので判別が必要）、そのための試行錯誤を繰り返していました。
1.3.3. 厳しく進行する
完成のため、会議を頻繁に行うなどして期限に間に合うように厳しくいくとしていました。また厳しさは、期限からくるメンバーの不安をある程度除いてくれると考えていました。
開発初期段階に起きた誤解ですが、1.3.1.と1.3.2.のタイトルだけの内容が伝わり、私が悲観的もしくは楽観的に進捗を捉えていると考え、厳しくない、言っていることが矛盾している、期限に間に合わないのではないかという不安が一部のメンバーにあり、弁解に苦労しました。野心がないと言われたりもしましたが、実現可能な範囲で野心は持ち続けていました。
2. やったこと
書くにあたって、過去のアジェンダをこちらにまとめました。気になる方はご覧ください。
2.1. 事前調査
先輩方から成功談や失敗談を、参加予定メンバーからは持てる技術などを企画発表の前に調査しました。 調査により、大方以下のことがわかりました。
-
求人の前にプランナーなどの主要メンバーや強そうな人を揃えておくと人を集めやすい
- 先輩方にも心配されるほど集まりすぎましたが、RPGをやるにはこれくらい必要だったかもしれません。
-
プラットフォームはUnityが良さそう
- Unity使いが多くなりそうだったため＆先輩方のノウハウがあったため
- 求人の際に定まっていると参加する人が安心する
-
企画の流れ
- 世界観やゲームシステムの決定、1ヶ月のデバッグ期間など
弊サークルのメンバーにしか見れませんが、デジクリのSlack上に『3年最終発表.pdf』という大規模ゲーム企画の神資料があります。事前知識として最高です。（幣企画は全く同じ失敗をなぞらえてしまいましたが）
2.2. 集まりやすい日時の調査
Googleフォームを用いて夏季休暇中のスケジュール確認や授業期間中のスケジュール確認を行い、より多くの人が集まれる日時に会議を行いました。
またこれをメンバーに公開することにより、誰かが誰かに質問をしたいときに部室に呼びつけることが可能となります。
多くの人が集まれる日時を選びましたが、序盤はCG班が集まらず、進捗遅れや不安感が発生してしまいました。単に集まれないだけでなく、会議を行っていることすら把握していないメンバーが数名いて驚きました。Slackの2つ以上のワークスペースに慣れない人はこうなるようです。
どうしても定例会に集まりそうにない班は、定例会とは別日にその班だけ集めることも考えていました。
2.3. ゲームの主軸を決定
世界観やゲームシステムなどの方針を全メンバーで決めました。 プランナーの先輩が複数の世界観を迅速に用意してくださり、それをみんなでレビューしながら決めました。
主軸に後から文句が出ないように最初は全員で考えて決めようと考えていたのですが、後々少人数で方針を改変しすぎて、いつの間にか誰もが文句を言えるシステムになってしまっていました。
途中の改変で不満のあるものになってしまうのはほぼ避けられないことなので、いつでも不満に気付いて文句を言いやすい体制を早めに設けるべきだったと今になって思います。
2.4. ブレインストーミング
確定した主軸の下、メンバー全員の脳を使ってアイディアを出し合いました。
マインドマップをスクリーンに投影しながら作成すると捗ります。Xmindというソフトが速く綺麗に作成できるのでおすすめです。
2.5. 役割分担
分担は以下の通りです。
-
ディレクター（1名）
- プロジェクト全体を見通し、各班のチーフに大まかな指示を下す
-
プランナー（2名）
- シナリオ・世界観担当とゲーム性・マッピング担当
- 厳密にはシナリオライターとプランナーは別の役職
-
CG班（6→10名）
- キャラクターやフィールドをデザインする
-
DTM班（4→3→5名）
- BGMとSEをつくる
-
pg_char班（3名）
- 敵/味方/自キャラの動きを作成
-
pg_field班（3→2名）
- 機能のあるフィールドオブジェクトを作成
-
pg_paint班（3名）
- 描画機能とその応用を作成
-
pg_ui班（3→2名）
- プレイ画面UI、タイトル画面、エンド画面、会話機能、セーブ機能を作成
-
SE（0→1名）
- PG班向けの設計を担当。プランナーと争う
- デジゲー博の直前に参加してくれたピンチヒッター
-
アドバイザー（1名）
- 大先輩が監査してくださいました。
1人の人間が管理できるのは8人前後までらしいので、CG、DTM班は1人、PG班は2人のチーフリーダーを設け、私が彼らを管理する体制を取りました。班分けとリーダー決めだけでも大分時間を取られてしまった印象があります。
PG班はタスクごとに班を分け、各班に1人ずつチーフリーダーを設けました。ただし開発終盤にはタスクを消化しきったPG班員がまばらに存在していたため、班の垣根を超えたタスクを消化してもらいました。
2.6. 絵チャットの導入
先輩のご助言を受けて、絵チャットを導入しました。絵チャットがあると、会話や文章では伝えきれない情報を伝えることができ、イメージの齟齬を防ぐことができます。
先輩が使われていたのはMagicalDrawというサービスで、手振れ補正機能があるのでマウスしか扱わないPG班に重宝しました。
加えて幣企画では、Microsoft Whiteboardという絵チャットツールも導入しました。シンプルなUIと無限に広がるキャンパス、ラグのない描画が魅力的で、iPadでも使用が可能です。ペンタブを持つCG班、ディレクター、プランナーが活用しました。
2.7. Discordの導入
Discordは、通話、画面共有、チャット機能に優れるサービスです。夏休み中の通話会議や、家や別のキャンパスからでしか会議に参加できない人のための会議実況のために導入しました。
メインの連絡ツールはSlackでしたが、DiscordはSlackよりもラフに話せる場となり、気分で進捗を上げてメンバーの士気を高める場としてときたま活躍していました。ただこのとき、Discordで重要なメッセージを許してしまうと、SlackとDiscordでデータがどこにあるかわからなくなってしまうので注意が必要です。
2.8. Git/Githubの導入
Gitは主にプログラマ向けのツールで、1つのプロジェクトを複数人で開発するのを容易にします。また、ソースコードのバージョン管理、つまりはセーブしてその地点に戻るといったようなことが可能になります。
Gitは導入が大変です。幣企画ではPG班が12人中誰ひとりGitを扱えなかった状態でしたが、主に1人のチーフリーダーの功労によってほぼ全員が扱える状態になりました。書いてくれたWikiが本当にわかりやすかったです。感謝しています。
※以下、Gitをﾁｮｯﾄﾀﾞｹ知っている人向けの話をします。（本当にちょっとだけ。）
※幣企画では有料アセットを導入しているのでリポジトリは公開できません。すみません。
2.8.1. 粒度を小さく（＝細かい内容で）ブランチを切る
ブランチの粒度が小さいと、ブランチを切ってからマージされるまでのインターバルが短くなり、リーダーが進捗を把握しやすいなどのメリットがあります。逆に粒度を大きくするとブランチが長期間残留し、気付いた時にはマスターブランチと大きく異なっていてコンフリクトが起きやすくなっていたりします。
ブランチの粒度を小さくするために、チームでブランチの寿命の目安を決めておくと良いかもしれません。
2.8.2. WIP PRを活用する
ブランチを切ったらすぐにPR（プルリクエスト）をし、PR名に[WIP]（Work in Progress ）と印を付けて、作業中でマージを希望していないことを開発メンバーに伝える手法です。進捗把握に有効です。また、初心者がヤバいことを始めようとしたときに上級者が始める前にストップをかけることができるので、ダメージを最小限に抑えることができます。
2.8.3. -f オプションは使うな
Git初心者が脳死で強制プッシュを行っていると、私のように他人様の1週間分のソースコードを容易に消し飛ばすことになります。（私は偶然直せる状態にありました）
2.8.4. Issue機能の活用
Githubには、Issueというタスク管理機能があります。幣企画では後述するTrelloと区別して、些細なバグを気楽に報告する場として活用していました。
2.8.5. Slackに通知連携する
Githubの通知は多くの人が見ないので、botでSlackと連携しましょう。
2.8.6. Unityではgit ignoreをしっかり設定
Unityでは少しの編集で多くのファイルが変更されます。addやレビューがしにくくなったりするので、はじめにきちんとignoreの設定をすると良いです。
2.8.7. Unityでは1つのSceneを複数人で触らない
Unityで1つのSceneを編集すると、そのSceneに対応する.unityファイルの中身が数多変更され、コンフリクトの原因となります。やりにくいですが、細かいSceneを沢山つくるなどして複数人で同時に1つのSceneを触らないようにする必要があります。
WIP PRを活用すれば1つのSceneを2、3人で交代して扱うことが比較的楽になりますが、それでもなかなかに難しいです。
2.9. Trelloの導入
Trelloは、どんなタスクがあるのか/あったのか、どのメンバーの何のタスクがどのような進捗状況なのか等をわかりやすくするタスク管理ツールです。共同開発に限らず、個人のタスクを管理するのにもとてもおすすめできるツールです。
2.9.1. 主な機能
上の画像について、ウィンドウの大部分を占めるのがボード、縦に長い枠をリスト、その中の小さい四角をカードと呼びます。それぞれ自由に作成、命名することができます。ボードには班名を、リストには進捗状況などの名称を、カードにはタスク名を付け、カードをリスト間で移動させて進捗を管理します。
カードには、優先度などを色でタグ付けできたり、期限や担当者を付与できたり、コメントやデータファイルを残したりなどができます。
また、Power-upという拡張機能で自分好みの機能を付与できます。Trelloへ多くのユーザを招待したユーザが作ったボードには、1年間ほど3つまでの拡張機能が使えます。
共同開発の際は、Slackと通知連携するPower-upを入れると良いです。その他、期限がひと目で分かるDeadlines、触っていないカードが汚れていくカードエイジング、カレンダーなどがおすすめです。
2.9.2. 個々のメンバーがカード動かすとよいかも
メンバー全員にTrelloの扱いを徹底させるのは難しいですが、実現できればチーフリーダーやディレクターの管理の労力が緩和され、管理漏れが防げます。リーダーは空いたその手で他のタスクに手が付けられます。
また、Todoリスト上のタスクには担当者を決めすぎないようにし、手が空いた人が優先度の高いカードに自らを担当者に設定して動かすようにすると効率が良くなるかもしれません。やる気や能力のある人がどんどん活躍できます。手が遅い初心者の仕事を奪ってモチベを下げないように多少の配慮が必要です。
個々人に動かされると混乱する、一部の人が誤った動かし方をして混乱するといった可能性もあるので、組織体系によってはオススメできません。
2.9.3. カードで質問、確認、提案などをスタックする試み
プランナーは多忙なので、メンバーの質問にすぐには答えられないシチュエーションが多々あります。対策として、プランナーへの質問などをカードで貯めておき、プランナー会議などの際に一気に消化する手法を考案しました。
これはメンバーへのシステムの徹底が難しく、タスク管理の範疇を超えていて混乱を招く可能性があるので、組織体系によってはオススメできないかもしれません。
2.9.4. Trelloを仕様書にしない
Trelloはタスク管理ツールです。仕様は仕様書に書きましょう。幣企画ではあちこちに仕様が書かれている状態になり、多くのメンバーが混乱してしまいました。
2.10. ノベルゲームのアセット『宴』の導入
UnityとExcelの知識が少しあれば比較的簡単にノベルゲームが実装できるUntyアセット『宴』を導入しました。ノベルゲーム以外にも応用できそうなタイトル画面のUIやセーブ機能なども含まれています。Unityができればちょっとした拡張も可能だと聞いています。
宴では、会話ウィンドウに一度に表示される文字数を考えながらシナリオをExcelに流し込むので、シナリオライターはExcelに直接シナリオを書くと良いかもしれません。
Excelにそのまま書くと、シームレスに気持ちよく書けなかったり、Googleドキュメントの編集提案機能などの便利機能が使えなかったりと、デメリットも多い気がします。SEGAのライターさんはExcelにまとめていると聞きましたが、直接書いているかは定かではありません。
2.11. 組織図の作成
どのメンバーが何年生で、何をしていてどのタスクと関係があるのかという組織図を作成しました。組織図があれば、上級生を見つけて技術を聞いたり自分のタスクに関係のあるタスクの担当者を見つけやすくなったりするかと思いましたが、恐らくあまり使われていませんでしたし、活用してくれと繰り返し言うこともありませんでした。あると良い程度のものです。
Trelloを使う前、ディレクターである自分でもタスクを把握しきれなくなっていたので、確認の意味も込めて作成しました。
2.12. 各班の進捗を評価して全体に共有
こちらの文書のように、大きい締切日に各班の進捗のレビューを全班に伝えています。締切日に限らず定期的に共有すると良いと思います。
他班の進捗がメンバー全体にざっくりでも良いので把握できていると、期限への余計な不安が抑制でき、班を超えた連携がよりスムーズに行えます。あの班も頑張ってるし、俺も頑張らないと！ ってなります。多分。
進捗が苦しい状況であればあるほど、嘘でない範囲で希望を残してまとめるのが大事かもしれません。リーダーとしては！マークを使うような気分ではないでしょうが、使いましょう。
2.13. DLカードの導入
DVDとは異なり、BOOTHなどの販売サイトを利用したDLカードの頒布だと、時間的にも金銭的にもコストが低いのでおすすめできます。頒布直前、頒布後の修正も利いて良いです。
ただDLカードだと満足感が損なわれてしまうので、何かしら印刷した2つ折りのA4厚紙にDLカードを挟むと良いです。
2.14. 購入物の決定と交渉
有料アセット宴と頒布物の素材の費用を部費から支出できないか、サークルメンバーと交渉をしました。利益を部費に還元するかなどを企画メンバーにフォームで尋ねたりもしました。
雑務なので、ディレクターは他のメンバーに任せるべきところであったかもしれないです。
金銭関係はトラブルの元となるので、企画発表時に何にいくらかかりそうか、ある程度見積もっておけると良いです。
2.15. デジゲー博当日の準備
デジゲー博までに間に合わないと確信した当日2週間前、デジゲー博で体験版という形で頒布するべきか否かという議論が始まりました。
-
中途半端な作品を出せばサークルの評判を落としかねない
- 頒布イベント、サークルのハードルを上げて考えすぎでは
-
中途半端な作品を作るためだけにテストを犠牲にするのは賢くない
-
体験版を作る人が集まらずに少数が死にそう
- 無理せず少数でできる限りのものを作る
- それで売れなくても仕方がない
-
やり切れば再スタートを気持ちよく切れるのではないか
-
頒布するとデジゲー博の運営に言ってしまった以上、頒布するべきではないか
- 頒布イベントのハードルを上げて考えすぎでは
などと色々話しましたが、最終的に最後の意見で少しだけ総意が傾き、体験版を制作することになりました。
デジゲー博の後に存続可能なメンバーを急遽フォームで確認し、多くのメンバーが続けてくれることはわかったのですが、テスト前ということもあり少数精鋭での準備となりました。
1人は既存のプログラムをGitで戻して使えるコードを探し、2人がデジゲー博後の開発のプロトタイプを兼ねてイチからプログラムを書き、私は頒布物とスペースのデザインをなんとかし、残る3人でPV制作を頑張りました。
なんとか完成させ、クオリティを鑑みて価格を200円に落としましたが、13部と思ったより販売できまして、何とはなしに再スタートが気持ちよく切れそうな雰囲気になりました。 いい話だ。
3. 問題と対策
3.1. 企画発表用のスライドは作るべき？
企画発表の際、時間とモチベがなく、スライドを作らずに細かい企画書をSlackにドンと載せて口だけで説明をしました。良くない。
今になって思えば、発表時に用意できなくとも、スライドは作っておいた方が良い気がします。スライドはドキュメントより情報が絞られるため、ゲームの主軸がメンバーの頭に残り、またいつでも参照しやすいというメリットがあるかと思います。
私の場合、スタート時の企画書の軸は変える気満々でいたので、軸を変えた後にスライドでまとめるべきだったかもしれません。
3.2. プログラミング初学者へのレクチャーが不十分だった
初学者へのレクチャーは軽く議題に上げてはいましたが、実施が不十分だった気がします。個々人の独学に頼ってしまっていました。
会議では毎回決め事に追われていましたが、思い切って勉強だけの会を開いたり、ペアプログラミングをさせたりするべきだったのかもしれないです。
3.3. 個々のメンバーの技量を把握せずに進行していた
個々のメンバーに見合ったタスクを振るため、あるいは見合ったタスクになるようにプランニングを工夫するための、個々のメンバーの技量のヒアリングをするのが遅れてしまいました。 一部のメンバーには、不得意なタスクを無茶苦茶に振られるのではないかという不安を与えてしまっていました。
メンバーには、
- 得意分野
- 分野ごとの進捗の速度
- 何をどこまで任せられるのか（進捗の完成基準）
などを早めにヒアリングするのが大切だと思いました。
3.4. 問題に対して動いている/動こうとしていることをメンバーに伝える
開発序盤に発生したある問題に対して、私は早めにDMで対策を講じたり、次週の会議で全体に共有しようと考えていたりしていました。
しかし、私が動いている/動こうとしていることがメンバーに伝わる前に、問題を察知したメンバーからの不安感が猛スピードで全体に広がり、全体のモチベーションが下がり、私に多方面からの叱られが発生しました。
メンバーの不安は広がるのが速いので、それに負けないよう、対策をしたという情報も素早くメンバーに共有する必要があると感じました。
3.5. 大まかな締切設定が不十分だった
夏休み前の早い時点で、デジゲー博までのざっくりしたスケジュールを立てていくべきでした。その気になれば企画発表の時点でできたことである気がします。
欲を言えば、「どのタスクが終わらないとどのタスクが始められないのか」などを示す下のようなアローダイヤグラム（PERT図） を作れると最高でした。
3.6. ゲーム性がブレている
気が付いたら、一貫性のないゲームの要素を入れすぎて、ユーザが何を楽しんだら良いのか混乱するゲームになってしまっていました。
大先輩の発表資料にも似たような反省があったので、もう少し先輩にレビューを頼る機会を設けるべきだったかもしれません。
また、シナリオや世界観に携わるプランナーと区別して、ゲーム性を決める専任のプランナーが重要だと感じました。開発中盤に無理を言って1人に任せましたが、その時点ではみなゲーム性のブレに気付けていませんでしたし、既に手遅れでしたし、1人では人手も足りていなかったようにも思います。
3.7. シナリオとアクションが独立している
独立していないシナリオとアクションとは、図形は何でできていて何ができるのか、絵筆はなぜ存在するのかなどの存在意味をシナリオがアクションに持たせたものだと考えています。アクションを考えつつシナリオを微調整しなければならないので、めちゃくちゃ難しいです。
独立しないシナリオとアクションを作るために、シナリオを書き始める前にプランナーと綿密に打ち合わせをするべきだったと思うのですが、上手くいかず、（4章中の）1章のシナリオはそれらが独立してしまっていました。開発終盤では、何人かからシナリオとアクションが互いに邪魔に思えるものだとのレビューを受けました。
プランナーと相談し、当時の進捗状況ではシナリオを変更する余裕がないと判断し、それらを独立させたまま開発を続行しました。多くのメンバーとはこの決定について話せておらず、良くなかった思います。
アクションとシナリオが相乗効果を生むゲームを諦めたところで、 独立した個々のアクションとシナリオだけを見るとそれらは良い出来で、最高のゲームはできずとも良いゲームはできるとの判断はしていました。開発方針としてゲーム開発は難しいものだと強く思っており、悪くないゲームを作るだけでもかなり素晴らしいことだと思っていたので、このまま開発を続行させました。
3.8. 企画書の変更後に軸を見直すべきだった
アリスの世界観に決まり、方針が決まってなんとなく順調だと思っていました。しかし、計画通りとはいえその時点では私の企画書の内容の大半が消えていたので、ゲームシステムなどを再度見直すべきだったかと思います。
その時点でゲーム性専任のプランナーがいなかったことも問題だったかもしれません。
3.9. 開発方針がブレた
開発中盤に、開発方針であった学べて楽しい開発ができるシステムが作れているかに疑問を持ちました。主体性に着目して書いた文章 をSlackで送り、夏休み明けに会議でも話しました。（文章中の内容は記事中に反映しています）
今思えば、必要だった着眼点は主体性だけでなく、そもそも面白いゲームを作れているのかという点や、短いインターバルで達成感が得られているかという点なども考えられます。
3.10. ディレクターが仕事をしすぎている
主体性の観点からして、ディレクターが仕事をしすぎてメンバーの仕事を奪うのは良くないです。 メンバーのモチベーションが上がりません。
夏の前は私が動きすぎて全体を把握しているのが私だけになり、何をするにしても私の確認をしなければうまくいかないとメンバーが思うようになってしまっていました。良くない。
私が動きすぎたのは、他人に頼るのが申し訳なく思えたり、ちょっとのことなら自分がやった方が早いと思ってしまったり、そもそも全体把握している自分しか動けないことが多かったり、目先のタスクは与えられている人ばかりでこれ以上は頼めないと思ってしまったり、などが挙げられます。
私が重箱の隅をつつくようなタスクを思いついたときに、そんなタスクを人に押し付けられないと思って自分でやってしまったりというパターンもあります。人に頼みにくいと感じるタスクは往々にして、頼む人が重要だと感じられないようなタスクであるので、そもそも切り捨ててしまった方が良いかもしれません。時間ができて、プロジェクトも複雑化しません。
私以外も全体を把握し、より多くの指示ができるよう、チーフには議事録の熟読を徹底させるべきだったかもしれません。そうして些細なことでも口頭で頼んだり、目先のタスクがあっても依頼して主体性のある楽しさを促すべきだったかもしれません。
30名規模のディレクターは個々に指示しようとすると漏れが発生しますから、ディレクターは全体を見通し、システムをつくり、各班のリーダーに指示を出し、上がってきた内容や流れている内容に誤りがないかをチェックすることに集中するのが良いと思います。ここぞというときに力が出せるように、他は手を抜く必要があります。
夏に反省して変えようと思ったのですが、デジゲー博の後もメンバーから仕事をしすぎていると指摘されました。もう少し頑張らないことを頑張ります。
3.11. 後からリーダーを設けるのは難しい
夏に仕事を請け負いすぎたことを反省し、諸事情により存在しなかったCG班のリーダーを設け、色々と任せたのですが、私だけしか把握できていないタスクが多かったために難航しました。
把握のために努力してくれましたが、それでも私しか把握できていないことが多く、度々私が口を挟む形になってしまいました。後からリーダーを設けるのは難しいです。
メンバーが把握しておくべき事柄が全て仕様書に書いてあれば、問題なくスムーズに多くを任せられたのかもしれません。
3.12. プランナーのタスク過多
ゲームの面白さを考える人は規模によって増やすのが良いかと思います。1時間前後のゲームで2人は少なかったのかもしれません。
また、プランナーがシナリオ以外に多方面の監査を請け負っていたのも良くなかったかもしれません。チーフリーダーがシナリオなどの資料を読み込み、解釈してタスクをまとめ、それをプランナーはチェックするだけ、というシステムならばプランナーの負担が軽減できたかもしれません。
プランナーの負担が軽減できれば、シナリオに集中してきちんと完成させ、早めにメンバーのタスクを割り振ることもできたかもしれません。
3.13. プログラマ向けの設計がなかった
ゲームが完成しなかった大きな要因のひとつです。プログラマ向けの設計がないと複数人での開発はかなり難しくなるようです。
途中まで順調に見られた私たちのプログラムも、結合をしようとした途端に破綻しました。無理に結合して出来上がったゲームは、実行する度にエラーの挙動が変わる再現性のなさを含んでおり、リファクタリング（少し変えて修理）をしようにもお手上げな状態でした。
破綻した原因のひとつとして、クラス設計などでどこに何の変数データがあるかがはっきりしていなかったことが挙げられます。このため、複数人が同じデータを別々の場所で作り出して競合したり、個々人が自分の領域だけで無理な実装をして意図しない実行結果が出てしまったりしているようです。私はプログラミングには疎いので間違ったことを言っている可能性があります。ご容赦ください。
ないよりはマシだろうと、プログラミングなんもわからん私が仕様書でゲームの流れのチャートを作ったりはしていたのですが、下図左上の要件定義にすら満たない設計だったようです。とほほ。
3.14. データの場所が散乱していた
・連絡のSlack
・通話とコミュニケーションのDiscord
・データのGoogleドライブ
・タスク管理のTrello
・仕様のExcel
と、企画内で扱っているツールが多く、そのあちらこちらに仕様やデータが散見されて探しにくい状態になっていました。
かといってどれかひとつでもツールを減らそうと思うと、私はとても不便に感じます。きちんとルールを徹底して扱えば強いとは思うのですが、使いこなすのはなかなか難しいです。
最近デジクリで導入を検討している、全ての機能がひとつのツールに集約しているサイボウズOfficeのようなツールを使うのは、良いかもしれません。
Googleドライブ単体を見ても、フォルダ構造が段々と複雑になっていき、どこに何があるのかわからなくなっていきました。
仕様書のデータ置き場というシートにファイル名とリンク先をリストアップしましたが、そのリストをメンバーに普及させるのもまた難しい問題でした。またそのリストを更新していくのもかなり大変で、途中からやらなくなってしまいました。Excelでマクロが使えたら幸せになれたかもしれません。
3.15. データの命名規則がバラバラだった
データといえば、命名規則がバラバラだったのも良くなかったです。Unityでバグが発生しないよう、半角英数字やアンダースコアなどによる命名を徹底するべきでした。
数十人へのシステムの導入は骨が折れますが、地道に何度も指示するより他ないです。指示する人を増やしたり、読むように指示するだけで導入が終わるリファレンスガイドを書くなどの工夫があると良いかもしれません。
3.16. どこまでやれば完成なのかが曖昧だった
人のタスクをスイッチする際、前のタスクが完成した状態なのかが曖昧であれば、余念を残しながら次のタスクに移ることになるので達成感が生まれづらく、良くないです。プランニングの時点で明確なイメージを作り、完成の基準を明確に設けるべきだと考えます。
完成の基準を明確にするため、ゲームの要素を減らしてシンプルにするのは有効な手段だと思います。
いくつかのタスクを並行させてしまうのも、完成後の達成感を曖昧にする要因になっていたと聞いています。
3.17. 要素過多
再三お話しているゲームの要素多すぎる問題についてです。シナリオと独立したアクションがあり、アクションと並行してギミック解除/謎解きがあり、複雑化しています。
ゲームの要素が少ないと、プレイするユーザも設計するPG班もわかりやすくて助かります。
初代スーパーマリオのような出現→ギミック→旗というシンプルなフローをイメージすると良いかもしれません。こういったフローではソースコードの使い回しが利きやすく、設計しやすいです。
またこのフローでは、旗に触れるというフローの明確な終了フラグが存在します。もし終了フラグがNPCとの相対座標など曖昧性の高いものであると、バグの温床になりやすいようです。
このフローでは完成のインターバルが短く、達成感を細かく得やすいという点でも嬉しいですね。
3.18. ゲーム進行が直感的でない
1.2.ゲーム内容で述べた通り、幣企画能力ゲームでは操作キャラが上下左右へ自由に移動したり扉をくぐったりします。これだと、キャラをどの方向に進めればゲームがクリアに近づくか、ユーザにとってわかりにくいです。
会議ではオープンワールドゲームのようだと例えられていましたが、オープンワールドのゲームはプロでも面白くするのが難しそうであり、素人の私たちが面白くするのは困難です。
3.19. 完全なウォーターフォール開発になっていた
遠いひとつの目標しか立てないウォーターフォール開発（画像上）では、幣企画のようにプログラムなどに大きな問題が発生した際には即刻
終
制作・著作
━━━━━
ⓃⒽⓀ
となる可能性があります。
対して細かい目標を立てて細かくレビューしていくアジャイル開発（画像下）では、問題が発生した際のダメージが小さいです。 ただ、少数精鋭で密に会議をしていかないと実現は難しいと聞いています。
2つの開発はどちらを選ぶか二律背反になるものではなく、双方の開発をどれくらいの割合で入れ込むかという関係であるそうです。幣企画はほぼ100%ウォーターフロー開発になっていました。
実はこの2つの開発については開発初期に先輩からご助言をいただいていたのですが、私が上手くチームに導入することができませんでした。申し訳なく思います。
3.20. なぜその仕様ができたのか、流れがわからない
仕様ができた理由がわかると、実装に応用が利きそうです。もし描画図形の赤が炎から来ているならば、赤の図形で木が消えるのも赤の図形で蝋燭が明るくなるのもメンバーは納得できます。
先日プロの仕様書の一部を見る機会があったのですが、各項目の右側にプランナーとの議事録のようなものがありました。仕様ができた理由まで仕様書に残すと良いかもしれません。
メンバーは仕様を受け取る時点で、後で文句を言うことにならぬよう、想定できる質問をプランナーに根掘り葉掘り聞くのが良いです。（12/21 追記）
3.21. ディレクターやプランナーにメンバーの意見がいきにくかった
Trelloの質問カードやSlackの質問用チャンネルを設けたりはしたのですが、未だメンバーの意見が出にくい状況にあるそうです。
チーフにしっかりヒヤリングしてもらってメンバー→チーフリーダー→ディレクターという意見が出しやすい流れを作ったり、会議で教壇を使わずに円卓会議をしてみたりなど、今後も新しい試みをしてみるつもりです。
3.22. RPGを甘く見ていた
デジゲー博に応募する際に困ったのですが、幣企画のゲームは、要素が多すぎる故に一口にジャンル分けのできないものとなっていました。一番近いものと言われればアクションRPGになるかと思います。
キャラクターを成長させつつ冒険を重ねていくというロールプレイングゲームの要素と、戦闘シーンでの選択する戦術だけではなく操作のタイミングなどが考慮されるアクションゲーム的な処理と、隠された謎や仕掛けを見つけていくアドベンチャーゲームの要素が備わったものが基本型である。特にこれらのシーンがシームレスに繋がるゲームを「アクションロールプレイングゲーム」と呼ぶことが多い。
「アクションロールプレイングゲーム」(2019-11-30T21:38Zの版) より引用
昨年度、幣サークルの別のRPG企画が開発に苦労していたので、RPGの難しさは知っていたつもりです。幣サークルは人数が多く、ディレクションとプランニングに注力するメンバーが3人いたので、頒布くらいはなんとかなるかと思っていましたが、自惚れでした。RPGをやるならより多くの準備と期日あるいは知識、経験、技術が必要でした。
RPGは他のジャンルのゲームよりもキャラやシナリオの設定の量が多く、それらとゲームシステムとの関わりも考えなければいけません。企画発表の時点からはるか遠くの終わりの見通しがある程度見えていないとRPG開発は厳しいと、開発をひと段落終えて思います。
開発初期に終わりの見通しが立っていなかった今回の場合、見通しを立てる準備中にはプランナー以外のタスクがかなり振りにくいです。なんとなく決めたタスクを依頼すると、後で「こんなはずじゃなかった」となるのが怖いです。
見通しを立てる準備中にはプランナー以外は休んでもらうか、アイディア出しの手伝いをしてもらうのが良いのかもしれません。今回の開発期間でそれをやると、見通しがしっかり立ったときにはデジゲー博は目前ですね。期日がもう少し欲しかったと思います。
期日を長くすると今度は分離キャンパスの弊害が発生し、メンバーとのコミュニケーションが取りづらくなるので、なかなか難しいところなのですが…。
見通し準備期間の休息or手伝いを当然のこととしてメンバーに伝えておかないと、いつタスクが回ってくるのかとメンバーの不安や不満が募ってしまいます。タスクがないのに会議に招集されるとメンバーのモチベは下がっしまいます。
そもそも見通しが立つまで人員募集は控えるのが得策かもしれません。プロの制作フローにおいても、はじめは少数精鋭のみで構想を練るそうです。
人を集めてから見通しを立て始めるのは、求人時に聞いていた内容と見通しが変わりすぎて「こんなはずじゃなかった」となる人が出そうでこわいです。そうならないためにも、メンバーの意見が汲めるシステムは必要です。
以上の通り、RPGは完成に対する不安が集まりやすいジャンルであり、定期的にメンバー内で追加求人の願望が高まります。 人数が増えると管理がより大変になりますし、増えるたびに逐一システムの説明をするのにはかなり骨が折れました。 組織のシステムを仕様書のどこかに書いておけば話は別だったかもしれません。
なんだかんだ言いつつも、このような難易度の高いジャンルをnot badな感じで進められた気がするので、悪くなかったとは思っています。そう思うのは私だけでしょうか。
4. 今後の企画進行
ディレクターとして出しゃばりすぎないよう、企画がいい方向に向く範囲で手を抜くことばかり考えています。
円卓会議でプランナーに尋ねたところ、12/24までにはゲームシステムを完成させてくれるそうです。今すごいモチベで頑張ってくれています。プランナー以外は休憩もしくはお手伝いという形になりそうです。
私の仕事としては、まだ春の完成までの大まかな締切が確定できていないので、早いところ決めたいと考えています。
プランナーは12/24までにゲームシステムを決めて、新たなシステムに合わせてシナリオをアレンジして、制作途中のシナリオ最終章（楽しみ）を書き上げて、冬休み開始までにメンバーにタスクを振れるかどうかというところでしょうか。
PG班は春休みあたりから通話会議中心で動き始めて、春までになんとか終わるかどうかという形になりますかね。締切が延びたとはいえ、新しいシステムを取り入れると呑気に構えてはいられなさそうです。
SEからは、多少はボツになるのを覚悟で、プランニングと並行して少数精鋭でプロトタイプをアジャイル開発し、その後みんなでウォーターフロー開発をする可能性があると聞きました。プロトタイプは全班のチーフリーダーで監査します。
プロトタイプがうまくいけば、ひと月で量産ベースを作り、ひと月で細部を作りこんでいくと見積もっていました。
なお、今までのGit体制は廃止し、Unityのプロジェクトを別々で作って後でまとめるそうです。Gitが使えるメンバー/プロジェクトでは引き続きGitを使います。ひとりで触るプロジェクトがあれば学んだGitでバージョン管理をしてほしいところです。
進捗の経験的な速度をしっかり考えて、イチから作り直すべきところと、そうでないところを見極めたいです。多少はブレーキをかけてかないと春にも間に合わないかもしれないです。あまりブレーキをかけすぎると前回と変わらぬゲーム性となり、PG班がモチベを持って開発できないので調節が難しいところです。
また、努力は惜しまないつもりですが、極力低コストで良いゲームができるような特異点のようなゲーム性を模索していきたいです。それはきっとある。
早めに幣企画を終わらせて、SEの彼の企画には頑張ってもらいたいです。幣企画を踏み台に輝いてくれ…！（幣企画も輝くよ）
5. おまけ：アイディアリスト
5.1. 連絡の取り方
5.1.1. SVOCを極力省略しない
イメージの齟齬や無駄な再確認がなくなります。
5.1.2. 進捗レビューには理由を添える
「良いと思う」だけではなく、何故良いと思うのかを書くと良いです。
単純に嬉しくてモチベに繋がりますし、次のタスクに生きるかもしれないです。
5.1.3. 質問が来たら「質問ありがとう！」で始める
先輩からの受け売りですが、質問者はこの対応に安心します。次も聞きやすいなってなります。質問のしやすいチームは不満が募らず、良いものが作れると思います。
5.1.4. 指示があったら自分の言葉で復唱して確認する
イメージの齟齬を防ぐことができます。
タスクを復唱する人は信頼できますね。
5.1.5. 数字を振って漏れがないようにする
一度に複数の質問をすると相手が質問事項を欠落させた回答をしてくることがあり、手間がかかるので、自分の質問事項に番号を振ると良いです。相手は必ず全ての番号で回答をしてくれる。
5.1.6. 予防線や曖昧な言葉は避ける
「～かもしれない」「～だと思う」「～時頃」などの言葉を使ったやり取りをするとイメージの齟齬が起きやすいです。
また、お前今考えただろと相手の信頼を落としかねません。今考えたのであれば、素直にそれを謝って、考えたことを全体に周知させたり、仕様書に明記すると良いです。自分で考えた事とは違い、指摘されて気付いたことは存外記憶に残らないものです。
5.1.7. コメントを編集した際はいつどこを編集したか記す
コメントを編集してメッセージに「編集済み」と付いた場合、今の編集済みコメントと数時間前の編集済みコメントは別物かもしれないと、逐一チェックをする必要が出る場合があります。
そもそも編集済みにならないよう、送信する前はよく見返すべきです（自戒
5.1.8. コメント中、テーマがわかれるところは＃＃＃などで区切る
単純に読みやすいです。
Slackのようなスレッド機能のある連絡ツールであれば、テーマごとにメッセージ自体を変えて、異なるスレッドが伸びるようにすると良いです。
5.1.9. 自他の感情が不安定なときは、急を要しなければ会議は避ける
経験からして、自他の感情が不安定なときにはろくな会議になりません。そんなときは、5分ブレイクを取るだけでも変わると思います。
自分の感情をコントロールできるのが理想ですが、次点で自他の感情が把握できているだけ素晴らしいです。感情が不安定だと気付いたらきちんとエスケープしましょう。
深夜の通話会議も同様な理由で避けるべきです。
5.1.10. アジェンダで把握し、口頭で会議し、言語化して文章でも確認し合う
こうすることで、イメージの齟齬を避けることができます。
私は開発中、認知バイアスによるイメージの齟齬で何度も苦労したことがあります。齟齬の回避策はかなり重要です。
人は物事をとらえるとき、自分なりの解釈をしてとらえる。すべて主観的な体験になる。この解釈の仕方は 認知バイアス と呼ばれ、この解釈が極端だと精神疾患や犯罪に発展する。
「良く生き良く働くためのアドラー心理学とドラッカー
」より引用
言語化することによって、会議に参加しなかったメンバーも把握できるので良いです。
5.1.11. 締切を守ってもらえそうにないときの対応
締切日はできているところまで共有するように、予め担当者に伝えておくと良いかと思います。こまめな中間報告も大事です。
これに関しては私も悩んでいます。誰か教えてください。
5.2. プログラマのTips
5.2.1. 本アドカレの1日目と3日目の記事
幣企画のスーパーマンズです。PG班に関してのみならず、ディレクターとして何をしたらよいのかをよく相談に乗ってもらっていました。本記事の内容の多くは彼らからの受け売りで構成されています。本当に感謝しています。
5.2.2. キー入力に関わる処理は1つのプログラムに統一して書き込む
受け売りです。例外もあるかもしれません。
ソースコードのわかりやすくなり、実行速度が大きくなるのでしょうか。
5.2.3. コーディング規約を定める
幣企画では、
・変数はprivateもしくは[SerializeField]にする
・変数へのアクセスは、public関数によって行う
・関数や変数の名前は行う処理や意味を具体的に示す
の3つが定まっていました。
他に良い規約があったら教えてください。
5.3. Slackの運用
半年で6800メッセージいっていました。ひえ～
5.3.1. #agenda
いつでも誰でもアジェンダを投稿し、教室会議の話者になれます。俺たちのフィールドは俺たちに任せろ！ といった感じで主体的に開発を楽しんでほしいです。
みんなの意見が出やすくなるシステムです。
5.3.2. #pg_random
Unityとかで興味のある記事などがあったらここに共有してもらいます。情報共有は大事です。あいつも頑張ってるし、俺も頑張らないと！ ともなり得ます。
5.3.3. #pgお悩み相談室
プログラミングに関する質問をみんなで解消していくチャンネルです。
教える方も勉強になります。
5.3.4. #planner_q_and_a
メンバーがプランナーに質問しやすくなるために開設したチャンネルです。
5.3.5. #progress_info
モチベ向上のために設けた進捗共有の場です。
今はもっぱらビルドデータや仕様書の更新版がアップロードされています。
5.3.6. #懺悔
よくないことをしてしまったときに参加して、懺悔して、退出するチャンネルです。
1人だけシスターが常駐していたりいなかったりするとか。
5.3.7. #leaders
班のリーダーが集うチャンネルです。幣企画には存在しませんが、企画によっては需要があるかもしれないです。
5.3.8. DMは極力使用しない
全体の把握のため、個人間の会話だとしてもみんなが見れるチャンネルで行った方が良いです。
DMで何かが決まった後、それを全体に共有し直す手間が最初から省けたりすることもあります。
5.3.9. 必要であればチャンネルを増やす。
必要だと思ったメンバーが作りたいと進言できるよう、最初にチャンセル作成の自由度を周知しておくと良いかもしれません。
5.3.10. スタンプによるリアクションを半強制化させる
リーダーとして、連絡にリアクションがないと再説明が必要であったりしないかが不安になります。
リアクションが多いとみんなが参加してる感じがあってモチベーションが上がったりもします。
5.3.11. 会議のリマインド
メンバーが教室会議を忘れて帰ってしまわないようにリマインドすると良いかもしれません。
5.3.12. 会議後、会議未参加者へ議事録を読むように通知
リマインドです。チーフリーダーは特に全体把握が大切なので、確実に読んでほしいです。
5.3.12. 小会議を告知する
プランナー同士の会議など、開催を告知をすれば誰かが傍聴しに来るかもしれません。
5.4. Googleドキュメントの活用
5.4.1. 箇条書き機能（Ctrl+Shift+8）
ドキュメントが高速に、各段に読みやすくなります。
Tabで右にインデント、Shift+Tabで左にインデントします。
5.4.2.スタイル（Ctrl+Alt+見出しの数値）
ドキュメントが多少読みやすくなり、また目次機能が使えるようになって参照しやすくなります。
5.4.3.コメント（行末の右側をクリック）
ドキュメント内のコメントしたい行にコメントを残せるので参照がしやすく、議事録やシナリオへのコメントにとても便利です。
コメントにコメントをすることもできます。
5.4.4.編集提案モード（UI右上）
言葉での説明は難しいので、実際に触ってみると良いです。このモードで文章を削除しようとすると色付きの取り消し線になり、書いた文字は同じ色の文字となります。
これはまだ編集提案の保留状態であり、右側のチェックマークをクリックすることで編集を承認することができます。「ツール＞編集の提案を確認」から、編集提案を順に参照しにいったり、全ての編集提案を承認or拒否できたりもします。
シナリオの校閲時には欠かせなかった機能です。
追記欄
今後の開発で学んだことがあればここに追加します。
6. やったこと
6.1. アローダイヤグラム（PERT図）の作成 (12/15 追記)
割とキツめなスケジューリングです。これはまだ暫定版で、これからメンバーと話して確定させます。
6.2. サークル向け発表資料の作成 (12/15 追記)
前期中間発表の資料はこちら
後期中間発表の資料はこちら
この記事に載せた内容、あるいはいずれ載せる内容しかありません。
6.3. Googleドライブの再編成 (12/21 追記)
SEの彼がやってくれました。
不用意に分類しにくいフォルダを量産しないようにし、最小限のフォルダの最下層に参照用のスプレッドシートを配置し、そこにファイル名、説明、作成者、登録日時を各自で記録するようにしました。
ルートフォルダにはフォルダの分類説明や参照用スプレッドシートの記録方法、旧フォルダを配置しています。
今回はゲームの大部分を作り直すので、混乱防止のために旧フォルダから新フォルダへのデータ移行をドキュメントで禁止しています。
7. 問題と対策
7.1. 案が承認後に棄却されたとの誤解釈があった (12/12 追記)
一度決めたことが易々と覆されるのは良くなく、覆される側にとっての覆した側の信用は落ちます（後述の 5. 議決事項を易々と変更しない を参照してください）。案が提出されたとき、提出者は完全に承認されたと理解していたようですが、承認者としては一部を見直すという条件付きで通していたようです。提出者と承認者との意思疎通が上手く機能していなかったことが事の発端になります。
このとき、ディレクターである私が一連の流れを終えていなかったのがかなり良くなかったです。やり取りを目に見えるSlackのチャンネル上で行うように促し、メンバーの意思疎通ができているかを確認し、整理するべきでした。
承認者が条件付きで通したのは、提出された案が抽象的なものであり（抽象→具体は正しいステップ）、承認後の具体案を見ないと棄却するかの判別ができないと踏んだからだと思います。私もその抽象案を見て判別しかねました。今回は、「具体案を見ないと判別ができない」ことが承認者から提出者へ伝わっていなかったことが問題でした。
7.2. 新しいアイディアを、その応用を追究せずに棄却しようとした (12/12 追記)
現状の問題であるゲームの要素過多を解決すべく、減算形式のプランニングをしている際に起きた問題です。要素を減算していくだけだと、どうしてもつまらないゲームに感じてしまいがちです。幣企画では、一部メンバーが要素を減算していく一方、また別のメンバーはそれでは面白くならない、既存のシステムとの整合性が取れないと主張し、議論が平行線となっていました。
ここで私が感じたのは、要素を減算したらその後に、シンプルになった要素の応用を考えるべきであるということです。幣企画の場合、描画図形の色を削ったら残る形状だけでいかに面白く応用できるかを追求する必要がありましたし、敵キャラを削ってシナリオとの整合性が取れなくなったら敵キャラに代わる脅威を追求する必要がありました。
応用を考える前にアイディアを棄却していると、開発は一向に前に進めないと感じました。
単純化したゲーム性の案をすぐに棄却した
自分の意見が反映されない、自分に発言権がないかと
7.3. 発言権がないと感じるメンバーがいた (12/12 追記)
メンバーに発言権がないチームは良いアイディアが出ず、不安が募る一方なので良い開発はできません。ただ今回は、あまりに自分の意見が通用しなさ過ぎて発言権がないと感じているだけのケースでした。実際がどうであれ、メンバーがそう感じてしまっているのは大きな問題です。
原因は議論が十分に行えていなかったことでした。発言権がないと感じていたメンバーAはその他のメンバーBが納得のいく説明ができていないまま議論を放棄していましたし、メンバーBも、メンバーAの主張がなぜ駄目なのか、メンバーAが納得のいく説明ができていないまま開発を進行させていました。
両者が感じる問題点をすべて洗い出したところ、両者が納得のいく第三の意見が存在する可能性が見えてきたため、それを全員で考えることになりました。問題の中には検討違いによる問題もありました。
そもそも発言権とはアイディアを出せる権利のことであり、意見の通る通らないには依らないものであることを誤解してはいけません。棄却されることを覚悟して発言権を行使しまくり、多くのアイディアから僅かに残った最良のアイディアを積み重ねていくことが、良いゲームを作る基本であると考えます。
はじめに多数からどんなに否定され続けようと、最後に全員を納得させることができれば、それが一番のアイディアです。自分の意見の良さor悪さに納得がいくまで議論は続けてほしいです。
7.4. シナリオありきでゲームシステムを作ろうとしていた (12/21 追記)
デジゲー博後、シナリオに大きな変更のないようなゲームシステムを必死に考え求めていました。しかし聞く話によると、コンセプト→システム→ビジュアル→シナリオの順が作りやすいそうです。システムの後にシナリオです。
一般に、シナリオは他の作業よりも相対的にコストが低いそうです。
言葉は他のどの素材よりも具体性が強く、言葉の設定にかっちり合わせた素材を作ろうとすると制作難度が上がることが多いです。言葉の柔軟性を利用して素材の違いをシナリオで繋ぐ方が、シナリオの変更に合わせて他の素材を変更するよりも楽で速いです。
とはいっても素材の違いは極力ないよう、ビジュアルの前にプランナーとCGで綿密に話しておく必要はありそうです。
幣企画ではシナリオライターの多忙さゆえ、言葉のコストが低いとは言い切れません。私は今回のケースに限ってはシナリオに合わせてゲームシステムを考えるのもコストに見合っていると考えていましたが、協議の末、ゲーム性を熟考した後、それに合わせてシナリオも大幅に再編成することになりました。
シナリオが早く上がるなら作りやすくなってとても良いのですが、間に合うかが心配です。ですので、シナリオのボリュームは抑えるという話になり、またPERT図通りに進行しなかった場合は企画を中止するとの背水の陣を敷かせていただきました。頑張ってほしいです。
7.5. プランニングをプランナーとディレクターのみで行っていた (12/22 追記)
プランニングを一部だけでやるのは良くないと聞きました。CG, PG, DTMの専門的なアイディアを得るため、みんなの満足のいく作品を作るため、モチベーションを上げるため、プランナーの負担を減らすため、メンバー全員あるいは各班のチーフリーダーもプランニングに巻き込もうと思っています。
8. おまけ: アイディアリスト
8.1. 誰かが言うそのまた誰かの意見は鵜呑みにしない (12/12 追記)
要するに伝言ゲームは難しいということです。AさんがBさんへCさんの意見Dを代弁して言うとき、Aさんの認知バイアスとBさんの認知バイアスが二重でかかるので、Bさんは注意して聞かなければなりません。またこのとき、Aさんが意見Dの補足意見Eを欠落させて伝える可能性があるので、この意見Dは容易に信用してはいけないと思っています。
誰かが誰かの意見を代弁するとき、その意見を発した本人からの確認もしっかり取るべきだと考えます。
8.2. 会議不参加者の中立 (12/12 追記)
議論が平行線になり、カオスな雰囲気になってしまったときは、冷静に会議に参加していなかった第三者の中立を求めると良いかもしれません。ディレクターが会議に参加するにしろ常にその立場にあると良いもしれません。
8.3. 忙しさでマウントを取らない (12/12 追記)
他人が遊んでいる中で自分だけが忙しくしているとヒステリックになるのは間違っています。人に任せられるタスクを人に任せようとしていない、もしくは任せ方が誤っている可能性があります。もしくはモチベーションの湧くシステムを作れなかったディレクターのせいです。ごめんなさい。
人に任せられないタスクに関してヒステリックになっているのであれば、それは単なるエゴです。そのタスクと周りの人は関係ないですし、周りの人の忙しさやその波は人それぞれです。この場合はタスク量が何とかならないかディレクターに文句を言うと良いかもしれません。
そもそも働き過ぎていることは見栄を張れることではありません。働き過ぎは効率が落ちます。 働き方改革をしましょう。
8.4. 冗談の価値観には個人差がある (12/14 追記)
冗談は、発する側の調節次第で薬にも毒にもなります。丁度蛇口と受け皿のようなもので、受け取る側の許容量に配慮した調節が必要です。
受け皿が小さい、すなわち冗談の解釈が下手なのはひとつの問題ですし、冗談の解釈の得意不得意を見抜かずに人によって不快に感じる冗談を
経験則ですが、冗談の解釈が下手な人は、冗談を発するのが下手な傾向にあり、冗談を発するのが下手か否かは会話で察知しやすいので良い指標となります。
8.5. 質問する前に自分で調べる (12/14 追記)
質問をすることはとても大事ですが、調べてすぐわかるようなことを聞かれると人によっては不快に思います。 逆に、少し調べてから質問してくると、その質問者と会話すると自分の知らない知識が手に入るかもしれない、と回答者も意欲的に返してくれると思います。
単純にチーム全体の無駄な時間を極力カットする意味でも重要な意識です。
参考：質問は恥ではないし役に立つ
8.6. 議決事項を易々と変更しない (12/14 追記)
会議で決まったことを何度も覆していると、前の会議は何だったんだ、今決まったことも今後覆される可能性が高そうだと、会議の重みや議決事項の重みがなくなり、メンバーのモチベーションの低下や開発方針のブレに繋がりかねません。
少人数で議決事項を覆すのはもっての外です。メンバーの意見を踏みにじっているようなものです。そもそも覆すのも良くないですが、どうしても覆す必要のある重大なミスが発覚した場合は、少人数で相談した後、会議で再度話しましょう。
同様な理由で、言いやすいからといって会議の後に異論を唱えるのは良くないです。議論は会議で行いましょう。
8.7. 会議の最後に内容を振り返る (12/14 追記)
会議で決まった事柄は変更しにくいので、異論が出ないかを最終確認すると良いです。認知バイアスによるイメージ齟齬も防げます。
8.8. 会話で前置きを長くしない / 長く喋らない (12/14 追記)
これは自分への戒めなんですが、「これは〇〇な話なんですが、」といった前置きを文中に挟みすぎると会話の流れが分断され、その人が本当に言いたい事を理解しにくくなります。 これが理解できないとイメージの齟齬に直結するので要注意です。
これも自分への戒めなんですが、同様な理由で、前置きに限らず自分の話が長くならないように注意し、要点だけを述べるように意識すると良いです。
この文章に前置きを2回入れましたが、鬱陶しく思いませんでしたか？
8.9 メンバーにチームの責任感を無理強いしない (12/16 追記)
人にチームの責任を求めるのは自分の願望に過ぎません。他人の願望を尊重しつつ、チームに最大限の寄与をしてもらうようにマネジメントすることが大切だと思います。
参考: 無能な同僚と働くということ。- WETな備忘録 ※タイトル詐欺です
8.10 指示語に注意する (12/21 追記)
指示語は多くても少なくてもいけません。 多すぎると何を指しているのかがわからなくなり、聴者が混乱します。逆に少なすぎると、会話の流れが分断されすぎて話の本筋が見えにくくなります。後者は聴者の能力が高ければ問題ないので、指示語を極力使わないように意識すると良いと思います。
聴者は、話者が自明でない指示語を用いたときには会話を止めてでも指示語の内容を確認した方が良いと考えます。「多分このことを言っているんだろうな」程度の指示語でも、実際に聞くと見当違いの内容が返ってくることがあります。ありました。
多人数で会議している際は特に、人によって解釈力や集中力が異なるため、その人たちのためにも指示語を明るくした方が良いと思います。
話者にとっても聴者にとっても、指示語を多用している/されていると話の内容が頭に残りにくく、またそのために会議全体の話の内容に矛盾が生じる可能性が高まります。指示語には気を付けましょう。
8.11 コンセプトアーティストを設ける (12/22 追記)
コンセプトアートとは、映画、コンピュータゲーム、アニメーション、漫画などで使用するデザイン・アイデア・雰囲気などを最終製品として仕上げる前に視覚化して伝えることを主目的としたイラストレーションの一形態である。ビジュアル開発やコンセプトデザインなどとも呼ばれる
「コンセプトアート」 (2018-06-21T09:50Zの版) より引用
8.12 ダブルチェックは非有効的になりがち (12/22 追記)
ダブルチェックとは、何かしらのチェックを複数人で行うことです。同じ人が視点や方法を変えてチェックするクロスチェックというものもあるそうです。
参考: クロスチェックとダブルチェックの違いとは？意味や英語、使い方を簡単に解説
複数人でチェックを行う場合、その誰もが 「別の人が頑張ってくれるだろう」と思い、サボってしまいがちになるようです。人に依るとは思いますが。
複数人でチェックをしていることは伝えずに独立した複数人にチェックを頼むのが良いかもしれません。
参考: 医療事故調査制度についてチーム医療48/62
コメント欄
右上のボタンへコメントをお願いします。お気軽に！
