四方山話/同人ゲームを完成させるためのヒント/基本編

同人ゲームを完成させるためのヒントの続き。ここでは基本のウォーターフォール型開発モデルをベースに説明する。*1

スケジュールを立てる

WBSを作る

ゲーム制作にどんな作業があるか、WBS（Work Breakdown Structure）を使って小さな単位・タスク*2に掘り下げてみる。*3

タスクの掘り下げ

コツとしては、最終成果物（目標で定めた成果物全て）を基点に逆算していけば良い。以下を繰り返していくと漏れが少なくて済む。*4*5

1. この前にやるべきことは何か？（必要条件を確認）
2. 本当にそれだけか？（十分条件を確認）
3. ○○○をすると×××ができるのか？（因果関係を確認）

例えば、ゲーム本体なら以下のように分解できるはずだ。

上の表で「スクリプトの作成」なら例えば以下のように分解できる。

同様に「イベント絵の作成」なら例えば以下のように分解できる。*6

実際には、２段階（あるいはそれ以上）でWBSを完成させていく。

1. 企画段階のWBSをまず完成させる（それ以降のタスクはラフなもので構わない）
2. 企画段階を終えた頃に以降のタスクを詳細化していく

WBSが完成したら、一度、WBSの末端タスクから最終成果物まで順に辿り、漏れがないか確認すること。*7*8

• 全員で不確定要素の多いタスク（何か問題が発生しそうなタスク）を探し出し、対策または予防策を打っておくこと
• 不確定要素の多いタスクは、スケジュールの前の方に移動しておくと良い（色分けするなど目立たせておくとなお良し）
  • 事前に何をしなくてはならないか、早めに検討する必要があるため

忘れやすいタスク

以下の作業（成果物ができる訳ではないがそれを効率化するような作業、中間成果物ができる作業、評価／テスト／レビューなど）は忘れやすいので、漏れないように注意したい。*9

• 企画・設定
  • テーマ
  • ストーリー概要（シノプシス）
  • 登場人物及び人物設定
    • プロフィール（略歴、性格、目的や望み、枷、長所・短所…）
    • キャラ原画、表情集（ラフ）
    • 人物相関図（友好、対立、グループ、血縁、上下関係…）
    • 呼称表（キャラＡがキャラＢをどう呼んでいるのかの一覧表）
  • 舞台設定
    • 地図
    • 年表
  • 用語集（ゲーム内固有の単語、造語などの意味をまとめたもの）
  • キャラ身長対比図
  • 全イベント絵の字コンテ一覧
  • 曲イメージ指定*10
  • 取材、ロケーションハンティング
• シナリオ
  • フローチャート、イベントチャート
  • 主要変数リスト
• 素材一覧表（曲、効果音、立ち絵、イベント絵…）
• システム外部仕様の作成
• スクリプト
  • システム画面の作成
    • 外部仕様の作成
    • タイトルメニュー画面の作成
    • セーブ画面の作成
    • ロード画面の作成
    • コンフィグ画面の作成
    • サウンドテスト画面の作成
    • （中略）
    • 単体テスト仕様の作成
    • 単体テスト
  • 結合テスト仕様の作成
  • 結合テスト
• 総合テスト仕様の作成
• 総合テスト
• 動作環境の決定
• マニュアルの作成
• 「はじめにお読みください」の作成
• 宣伝兼サポートサイト開設
• 問題解決手段の調査、学習・育成など*11
  • 検証用プロトタイプ作成

WBS作成のポイント

• 馴れていない内はできるだけ細かいタスクにまで落とし込んでみる（恐らくビックリするくらいタスクが出てくるはずだ）。後で管理しやすい単位にまとめ直すと良い
• 細分化しすぎない。例えば、原画と彩色を一人のスタッフがやるなら、「立ち絵Ａの原画」「立ち絵Ａの彩色」と分けなくても「立ち絵Ａの作成」で充分だろう。管理しやすい単位に落とすことが重要*12
• タスク名はできるだけ平易で判りやすい表現を使う。「○○を××する」などが良い
  • 専門用語だらけだと担当スタッフ以外のスタッフが理解しにくい（意見を出しにくくなる）

優先順位を付ける

WBSが完成したら、それぞれのタスクに優先順位を振っておく。高低の２段階、または高中低の３段階で充分だと思う。

• スケジュールが遅れた際、どのタスクを切り捨てるかの判断に使う
• ヘルプの人に、どのタスクを担当して貰うかの判断に使う

先ほどの「スクリプトの作成」を例にすれば、次のようになる。

優先順位の評価指標はいろいろ考えられるが、ノベルゲームなら「それがなければ最終成果物の価値はどれくらい落ちるか」が判りやすいと思う。

例えばシナリオなら「そのパートがなければ…」になるだろうし、立ち絵なら「その表情差分がなければ…」「そのサブキャラがなければ…」などになるだろう。

WBS番号と従属関係を付ける（必要があれば）

必要に応じて、WBS番号とタスク間の従属関係を付けておく。*13

• WBS番号（いわゆるID）の書式に特にルールはない。ユニークな値で、タスクを特定でき、タスクの親子関係を把握できれば書式は何でも良い*14
  • 例：1-2、1.2.3、A-1-2、101（100飛び）など
• 従属関係は、あるタスクより前にどのタスクが完了していなければならないか…の関係を先行タスクとしてWBS番号で示す
  • 親タスクが同じタスク同士の従属関係を示す（例えば1.1.2と1.1.3）よりも、親タスクが別のタスクとの従属関係を示す（例えば1.2.1と3.1）ことの方が重要
  • スケジュールを立てる際、タスクの配置順を考えるのに参考になる

先ほどの「ゲーム本体」を例にすれば、次のようになる。

• タスク「1. スクリプトの作成」の先行タスクは「2. 画像素材の作成」と「3. 音声素材の作成」であることを示す*15
• タスク「6. 総合テスト」の先行タスクは「1. スクリプトの作成」から「5. 総合テスト仕様作成」であることを示す

担当者、計画日数の決定*16

• タスクを誰が担当するのか決める
  • メイン担当、サブ担当とか役割が分かれるのは構わない
• 計画日数の決定
  • まずはそれぞれのタスクの担当者が計画日数を決める
    • 予め各自の作業ペース（例えばスクリプターならシナリオテキスト○○KBに対して××日かかるとか）を報告しておき、スケジュール立案の参考にする
  • 日数が妥当か全員でレビュー、必要があれば修正する
    • 大抵の場合、物凄く過大な見積もりになっている*17
    • 実際にスケジュールが走り始めると、徐々に各スタッフの作業ペースも判ってくる。何段階かに分けてスケジュールを見直し（各スタッフの作業ペースに合わせる）、スケジュールの精度を上げて行くのも手だ
• 期間の長すぎるタスクは（多少強引にでも）分割した方が良い
  • １つのタスクは長くて２週間程度に留めた方が良い
    • それより長くなると、管理する側もされる側も正確な進捗が把握できなくなる

先ほどの「スクリプトの作成」を例にすれば、次のようになる。*18

スケジュールを作成する

WBSをガントチャート化すると作業期間を視覚化できて判りやすい。

• マイルストーン（用語を参照）を置き、スケジュール作成の指標とする
  • マイルストーンの例…同人ゲームを配布するイベントがある日、インストールCDを焼き始める日、CDプレス業者にマスターCDその他データを納品する日など
• 従属関係を維持するよう、タスクを配置して行く
  • １人のスタッフが携わるタスクは常に１つだけになるよう調整すること：リソース（用語を参照）の重複をなくす
    • １人のスタッフに複数のタスクを並行させると却って作業効率が落ちる
    • スタッフＡが担当するタスクは赤、スタッフＢが担当するタスクは青などと色分けすれば、リソースの重複が一目で判る
    • タスク達成に必要なハードウェア／ソフトウェアの数が限られている場合、これも重複しないようにする
  • タスクＸ（スタッフＡ担当）とタスクＹ（スタッフＢ担当）に従属関係がなければ同時に進行させるなど、タスクを上手く配置して、スケジュール全体を少しでも短くする
  • 従属関係のあるタスクは線で結ぶなどして従属関係を示しておく
  • プロジェクトの初期段階や、プロジェクトマネジメントに不慣れな場合は、次のマイルストーンまでスケジュール、マイルストーン到達後はまた次のマイルストーンまでスケジュール…というやり方が良いだろう

この時点で、期日までに完成しないなど、マイルストーンを越えてしまうことが判明した場合、優先度の低いタスクを削ったり、ゲームの仕様そのものを変更したり、あるいは期日を延ばしたりと言った判断が必要になる。*19

クリティカルパスを見つける

クリティカルパス（用語を参照）を見つけ出し、これに関わっているタスクが遅れないようマネジメントする。前述の想定モデルの場合、大抵は以下のどちらかになっていると思う。*20

• 企画・設定→プロット・ハコ書き～シナリオ→スクリプト→リリース→テスト
• 企画・設定→字コンテ→原画～彩色→スクリプト→リリース→テスト*21

初めてゲーム開発する場合

１～３ヶ月程度かけてパイロット版を作り、感覚を養うと良い。

1. 予め、マイルストーンをいくつか決める（毎月末日など切りの良い日でも良い）
2. 判っている限りで良いので「WBSを作る」～「クリティカルパスを見つける」までをやってみる
3. マイルストーンまでに何を終えていなければならないかを決める
4. 実際に開発してみる
5. マイルストーンに到達するたびに、立てたスケジュールとどの程度のギャップがあったのか比べてみる

作業の進め方に関して

アメとムチで人を動かそうとしても効果は薄い。それより仕事をしやすい環境（あるいは仕事せざるを得ない環境）を作ることに注力したほうが良い。*22具体的には、以下のような方法が考えられる。

• 具体的（成果物の完成形が明確にイメージできるという意味）な指示をする
  • 成果物が明確にイメージできないと迷いが生じるものだ
  • 例え（～のような）を活用するとイメージを共有しやすい*23
• グラウンドルールを活用する。例えば、必要以上にムダ話をしない、会議は簡潔にする（仕事に集中しやすくする）など
• 手戻りを減らす。手戻りがあっても最低限の作業量で済むようにする
  • モチベーション低下を防ぐのが目的
• リーダー（と賛同者）が率先して仕事をする
  • 皆が黙々と仕事をこなしていれば、自分もやらなくては…という無言の圧力になる

前提

メンバーは「最終決定責任（権限）はリーダーにある」ということを念頭に置いて作業する必要がある。

• スタッフは、リーダーからリテイク／修正指示が来る前提で作業をする必要がある。例えば、以下のように仕事を進めれば、手戻りが少なくて済む
  • シナリオライターなら、まずはプロットを書き、リーダーにチェックして貰ってから本来のシナリオを書く。同様に、シナリオをキリの良いところでリーダーにチェックして貰う
  • 原画ならイメージが伝わる程度のラフを描き、チェックして貰ってから仕上げに移る
    • キリの良いところで随時リーダーのチェックを受けるべし
• スタッフから他のスタッフへの成果物に対する意見具申について
  • 必ずリーダーを通すこと。リーダーが一理ありと認めたら、リーダーからそのスタッフに指示させるべき
    • 内容によってはリーダーと意見するスタッフだけの場を設け、そこで具申した方が良いこともある。この時、リーダーは他のスタッフから意見具申があったことを他のスタッフに伝える必要はない（この時点で「リーダーの指示」となる）
• リーダーからリテイク／修正を指示されたら辞めるような人はチーム作業に向いていない
  • もちろん、スタッフにも反論や意見する権利はあるが、リーダーや他のスタッフを納得させることができなければ従うべきだろう
  • リーダーに独断専行が許されるという意味ではない
  • リテイク／修正を指示されたスタッフは、個人差こそあれモチベーションを落とすので、リーダーはフォローすること

裏返せば次のような表現ができる。*24

• リーダーはゲームの完成形をかなり正確にイメージできていなければならない。また、仕様書などでそのイメージをできるだけ正確にスタッフに伝えなければならない
• リーダーは各スタッフの作業内容について、（専門とは言わないまでも）相応の知識を持っていなければならない*25
• リーダーは一度決定したことをおいそれと撤回してはならない
• リーダーの指示は、スタッフも納得できる（スタッフから合意が得られる）内容であることが重要。頭ごなしで指示するだけではモチベーションの低下を引き起こす*26

また、決定内容（やその過程）は記録に残しておくことが望ましい。チャットのログ、メール、まとめサイト（WikiとかCMSとか）など形式は何でも良い。報告書みたいに堅苦しいものである必要はない。後で「言った」「言わない」「～と決めたはず」「意見しただけ」という問題を防ぐことができれば充分だ。*27決定事項は別途箇条書きしておくなど、目立つようにしておくことが望ましい（ログからはすぐ判断できないし、人の会話は曖昧なまま進みやすいので）。

進捗の管理

作業の進捗状況は「随時、リーダーが成果物（になる予定のモノ）を直接目で見て把握する」が基本。*28

進捗報告に関して*29

• 「現在作業中のタスクがあと何日で終わるか」で報告させること（残り期間と絶対値で報告させることがポイント）
  • 「順調に進んでいるか？」と訊いてはならない（リーダーにその気がなくとも無言の圧力になってしまう）
  • 「～%進んだ」と割合で報告させてはいけない。進捗具合の判断基準は人によってかなり違う
  • 90%進んだところで実は本当のヤマ場（日数のかかるフェーズ）だった、なんてことはザラ
  • 「あと何日で終わるか」だと管理する側もされる側も比較的同じ認識を共有できる
• リーダーが成果物（になる予定のモノ）を直接確認した方が良い
  • スタッフが何か作業し終えたら、その作業結果がすぐリーダーに伝わるようにしておくこと（作業後、ファイルをオンラインストレージにアップロードしておくなど）
  • 予定より作業が進んでいると判断したら、どんどんスタッフに作業を前倒ししてもらう
    • タスクが早期に完了したら作業の前倒しを推進するだけで、以降のタスクの日数カットはないことを事前に告知しておくことが重要
  • スタッフの人数が少なければ、それほど困難ではないはずだ

問題の報告に関して

• 「進捗を阻害する要因はないか」「何か問題が起きていないか」「何か助けられることはないか」を報告させること
  • 進捗を阻害する要因が上がってきたら、メンバー全員で対策を検討、いつでも対応できる準備を整えておくこと。予防できればなお良し
    • 技術的な課題は、どこかの専用掲示板の類で質問するくらいしか手はないと思うが…
  • 「何か問題が起きていないか」だけを報告させてはならない
    • 問題が起きて報告したときには、すでにリカバリー困難となっているケースが多い
    • リーダーに悪意はなくとも、スタッフの側からすれば「問題なんか起きてないよね？」という風に受け止められる。気の弱いスタッフだとつい「良い報告」をしてしまいがち

スケジュールの変更管理

確率的にスケジュール通り作業が進むことはほとんどない。大抵の場合、想定外の事態が起こってスケジュールは少しずつ遅れていく。これが本業の合間での作業なら、なおのことスケジュールは狂いやすい。特にクリティカルパスに含まれる作業なら、全体へ与える影響は大きい。*30

スケジュールの遅れを取り戻す／低減する手段は、昔から変わっていない。どの方法にもデメリットが存在するので、メンバー内で充分検討のこと。

• タスクの日数に余裕（保険）を持たせておき、遅れが発生しにくく（遅れを吸収）する
• スタッフに作業時間を増やしてもらい、遅れを取り戻す
• 余裕のあるスタッフがいるならヘルプに回ってもらう（専門外の作業でも手順／要領を説明すれば意外と出来ることはある）
• ヘルプのスタッフを起用し、遅れを取り戻す
• 優先順位の低いタスクを切り捨てるなどして、全体の日数を減らす・仕様を削る
• スケジュールの遅れを容認し、プロジェクト完了日を後にずらす

問題への対処

• 問題が発生したらスタッフは直ちにリーダー（メンバー全員）に報告、リーダーは可能な限り素早く（当日～翌日までが理想）対応を決定すること
  • 次の定例会議で…などとのんびり構えていると、スケジュール遅延を招く

境界の作業（成果物の引き渡し）

あるスタッフから別のスタッフへ成果物を受け渡す際、想定外の作業が発生しやすい。事前に誰が何を担当するのか決めておいた方が良い。

• シナリオに演出指示を入れる作業
  • 担当者はシナリオライターかスクリプターかリーダーか*31
• 画像素材（立ち絵とか）をゲームの画面サイズに拡大縮小し、PNG形式などノベルエンジンで扱える形式に変換する作業
  • 担当者はイラストレーターかスクリプターか
• 音楽素材をOgg Vorvis形式などノベルエンジンで扱える形式に変換する作業、マスタリングする作業
  • 担当者はスクリプターかリーダーか

また、前タスクから後タスクへと成果物がスムーズに渡せるよう、予めファイル名、書式、ファイル形式などの取り決め（受け入れ基準と言う）をしておくと良い。*32

以下は立ち絵→スクリプトの例。

• ニーショットの場合（膝から上）
  • 立ち絵ファイルの画像サイズ…横300×縦480ピクセル
  • 立ち絵ファイルの画像形式…PNG（α付き）
  • 立ち絵ファイル名の書式…キャラ名_服装_表情.tlg
• ウェストショットの場合（腰から上）
  • （以下略）
• （制作する）立ち絵ファイル名の一覧表
• 画面演出上、例外の立ち絵があればそれもまとめておく

以下はシナリオ→スクリプトの例。

• コメントの書式…行頭を半角セミコロン ; にすると行末までコメントと見なす
• ルビの書式…青空文庫形式
• 演出指示の書式…コメント中に「●演出指示」。例えば「; ●フェードアウト」
  • 必要があれば画面効果と音声効果で書式を変更するなどしておく

（想定モデルにないが）以下はネット声優（自宅録音）→スクリプトの例。

• ファイル形式、サンプリング周波数やビットレートなどを事前に決めておく
• 音量レベルは、事前にスクリプター側から音声サンプルを声優側に提出、収録時の参考にしてもらう

例えば、後タスクの担当者がスクリプターなら、仮素材である程度まで作業を進められるし、本来の素材が完成したら、素材を置き換えるだけで今まで記述したスクリプトがそのまま使えることになる。*33

• 従属タスク担当者は、どのような形の成果物ならスムーズに作業を引き継げるか、予め先行タスク担当者と認識のすり合わせをしておくべき
• そして、成果物を引き渡す際、先行タスク担当者は従属タスク担当者がスムーズに作業できるよう配慮するべき

シナリオライターに関する補足

ノベルゲーム制作プロジェクトにおいて、最大のボトルネックはシナリオである。ゆえにシナリオライター以外のスタッフの作業が中断しないよう、シナリオライターの作業を先行させておくのも手だ。*34

スクリプターに関する補足

スクリプトは後工程に作業が集中するため、前工程のしわ寄せを受けやすい。ライブラリなどの蓄積がどの程度あるかが重要になってくる。

• 定型作業（例えばリリース、署名、インストーラ作成など）は可能な限り自動化できるようにしておく
• 多用する演出効果は予めマクロ化しておき、テキスト置換で一気に挿入できるようにしておく
  • 予め演出指示の書式を決めておくこと

品質のマネジメント

ノベルゲームの場合、大きく３つの軸で品質を考える必要がある。便宜的に以下のように呼称する。

• コード…スクリプト（主にシステム面の）。なお、想定モデルにはないがプログラムもここに含まれる
• コンテンツ…シナリオ、音声素材、画像素材。なお、想定モデルにはないが動画素材もここに含まれる
• その他（ここでは特に触れない）
  • 企画
  • セールスプロモーション
  • ユーザーサポート
  • ：

この内、コードとコンテンツに関しては以下のように管理すると良いだろう。

• コードに関しては最初から高い品質を維持し続けることが重要
  • 後から品質を上げようとすると却って手間がかかる
    • その場しのぎのスクリプトを書いていると後で泥沼にはまるのがオチ
  • しっかりした外部仕様やテスト仕様の作成、段階ごとのテストなどが重要になってくる
  • 全パステスト（全ての条件・分岐について最低１回の動作確認を行う）が基本
• コンテンツに関しては後から品質を上げる（ブラッシュアップ）ことも可能
  • 追加で済む（全体に与える影響が小さい）作業、素材ファイルを置き換えるだけの作業、その他微修正なら、まずはゲームを完成させることを最優先すべき
    • ただし、あくまで後工程に迷惑がかからない範囲で
    • 未完成品で良いという意味ではない

用語

マイルストーン

プロジェクトにおいて重大な時間軸上の出来事のこと。通常は遅延が許されない節目を指す。本来は里程標という意味

クリティカルパス

従属関係（前タスクが終わらないと次タスクに進めないなど）にあるタスク群の中で、最も長くなるタスクの繋がりを指す。プロジェクトの所要期間を決定する。厳密にはリソースの重複について考慮していない（当ページではリソースの重複についても考慮しているが）

リソース

プロジェクト達成に必要なモノ全般のことで、具体的には作業者、ハードウェア／ソフトウェア、材料、カネなどを指す*35