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

はじめに

同人ゲーム*1制作プロジェクトが失敗する理由は様々だと思うが、理由の一つに「リーダーが適切な仕事をしていない」があるのではないかと考えて、プロジェクトマネジメントの観点から「どうすれば良いか」について簡単にまとめてみた。*2*3*4

ちなみに、ここで書かれている通りのことをやったところで、必ずゲームが完成できる訳ではないことに注意されたい（せいぜい完成する可能性が少し上がる程度だろう）。ここで書いたことが全て正しいという訳でもない（王道はない）。最終的にはメンバーの力量にかかっている。*5

参考までに書くと、プロジェクトが失敗する代表的な要因は以下の通り（他にも多数考えられる）。要因のほとんどは人にある。*6

• スコープ（成果物や作業の範囲）の問題
  • 目標が明確になってない
  • メンバー間で目標、ニーズ、期待などに隔たりがある
  • メンバー全員を満足させることを目指すなど、要件が過大
• 技術上の問題
  • 実績の乏しい技術（ソフトウェア、ハードウェア、手法など）を安易に採用する
  • メンバーが未熟で技術（ソフトウェア、ハードウェア、手法など）を使いこなせない
• 体制の問題
  • 決定権限のない体制
  • メンバー間の責任分担が曖昧
• 計画、契約の問題
  • 予算ありき納期ありきで始まり作業量が見合わない
• コントロールの問題
  • 安易に仕様変更してしまう
  • 簡潔・明確・正確なドキュメントがない、更新を疎かにする
  • 報告の遅延、または報告のチェックを疎かにする
  • 問題を先送りする

想定モデル

以下のようなモデルを前提に説明している。多くの場合、これとは違うジャンル／メンバー構成／条件になるはずで、相応のアレンジが必要となる。

• 制作するのはノベルゲーム
  • ノベルエンジンは吉里吉里2/KAG3を採用*7
• メンバーは４人。全員、仕事や学業の合間に作業
  • リーダー（プロデュース兼ディレクション兼企画兼仕様作成兼ウェブサイト管理兼その他担当）
  • シナリオライター
  • イラストレーター（原画兼彩色担当）
  • スクリプター（兼ユーザーサポート）
• コミュニケーション手段はチャット、メール、メンバー専用掲示板など。成果物の引き渡し手段はメール添付、オンラインストレージ、ファイル転送サービスなど
• 最終成果物の提供方法はサポートサイトからのダウンロード、または同人ゲームダウンロードサイトでのダウンロード販売
• 制作費０円
  • 必要なソフト、機材などはメンバーが自腹で用意したものを使用
• 背景は写真を加工したものか、フリー素材を使用
• BGM、効果音はフリー素材を使用

ちなみに、以下の言葉は

• メンバー…サークルに所属している人（リーダー含む）
• スタッフ…サークルに所属している人（リーダー除く）

のように使い分けている。

目的

「とにかく同人ゲームを完成させる」ことだけを重視している。期限通りに制作すること、予算内で制作することは重視していない。*8*9

チーム作り

コミュニケーションの密度は、どれだけ本音で話せるかで決まる。
しかし、見ず知らずの人たちが集まった直後は、どうしても遠慮気味になり、建前でのコミュニケーションが多くなる。
この状況下ではチームがうまく機能しない。
どうせプロジェクトが煮詰まればメンバーの本性が露わになる。
なら最初からぶちまけた方が余計な行き違いがなくて良い。

アイスブレイク

簡単なゲームを通してメンバーの人となりを知り、親交を深める。アイスブレイクには以下のサイトが良くまとまっている。書籍も出ている。

• 日本ファシリテーション協会
  • アイスブレイク集
• アイスブレイク.info
• レクリエーションゲーム事典

以下は一例。オンラインでも応用しやすいだろう。

• 嘘つき自己紹介
  1. 予め、各自３～４個ほど自分のエピソードを書く（面白いもの、意外なもの、驚くようなものが良い）。そのうち１個だけ嘘を書いておく
  2. メンバーの一人が書いたエピソードを公開、どれが嘘か他のメンバーに当てさせる
  3. 人数ぶん繰り返す
• 私ってこんな人
  1. 予め５～７個程度、お題（現在のマイブーム、変な癖、好きなもの、人生最大の失敗…など）を設け、メンバーに答えを書かせる
  2. メンバーが一人ひとり答えた内容を発表。必要があれば質疑応答
  3. 人数ぶん繰り返す
     • スタッフの回答をリーダーがまとめ、「この回答を書いたのは誰か」を当てさせるのも良い。

決意表明

各メンバーは「自分が果たすべき役割は何か」「このプロジェクトを通してどう成長したいか（何にチャレンジしたいかでも可）」を他のメンバーに表明する（記録にも残す）。

期待値の交換

決意表明の後、他のメンバーは本人に対して「こういう役割（仕事）を果たして欲しい」旨を伝える。それに対して、本人は不安に思っていること、どんなサポートが必要かを他のメンバーに伝える。*10

サブロールの決定

サブロール（本来の仕事ではないが誰かがやらねばならない仕事、直接付加価値を生み出さない仕事）の担当者を割り振る。以下のような仕事が考えられる。

• 宣伝用ブログの記述（持ち回り制でも良い）
• イベントの参加申し込み手続き
• 資産の管理

サブロールは出来るだけリーダーが担当する方が良いだろう。

• サブロールには主担当、副担当を割り振っておくと良い
  • 主担当が忙しければ副担当が作業したり、交代制にするなど工夫を

グラウンドルール

憲章（後述）と異なり、これはメンバーの好ましい振る舞いを促進し、好ましくない振る舞いを防ぐためのルールである。常に守るべきルール、会議など特定の状況で守るルール、楽しく作業するためのルールなどをいくつか設けると良い。*11

常に守るべきルールの例

相手を呼ぶときは「さん」付けで（逆に「タメ口で」というルールでも良い）
前向きに作業する
内容をまとめてから話を切り出す
陰口を言う、個人を攻撃するのは禁止
悩みを一人で抱え込まず、メンバーに話し相手になってもらう

会議で守るべきルールの例

人の話をさえぎらない

楽しく作業するためのルールの例

１日１回、みんなを笑わせるネタを披露する

同人サークル特有の問題

見ず知らずの人と同人サークルを結成する上でやっかいな問題は、各自がどの程度本気で取り組む気があるのか判らないことだ。
野望に燃えている人、みんなで楽しくという人、面白そうだから参加という人…これらの温度差を素早く理解し合うことが大切。

あまりに高い期待をかけられると、軽い気持ちで参加した人は気後れしてサークルを抜けてしまう（サークルの雰囲気も重くなるし）。
できれば募集の段階で、当サークルはどの程度本気で取り組むつもりなのかとか、「○○担当の人には○○を期待している」といった旨を書いておくと良いだろう。

目標を明確にする

プロジェクトの目標を以下の３点で詳細化する。モチベーションが落ちたとき、迷ったときなど、ここを振り返れば少しは役に立つはずだ。目安は「全て達成できたら嬉しいかどうか」だ。*12*13

• 目的は何か？
  • ゲーム制作を通して達成したいことを書く（成果物のことを書く訳ではない）
  • 例…～の経験を積む／実力を上げる、～界で有名になる、カネを儲けるなど
• 成果物は何か？
  • 成果物は目的を達成するための手段となる
  • 成果物は形あるものと限らない。例えば組織体制や運用ルールなども成果物となり得る
  • 例…ゲーム本体＋はじめにお読みください＋サポートサイト＋無償サポート
• 成功基準は何か？*14
  • 低すぎても高すぎてもモチベーションが上がらない。がんばれば達成できるかも知れない、くらいの水準が良い
  • 基準には定量化できるものを採用することが望ましい。定量化しにくいモノは例えば「誰々が○○と言う」「誰々に××と言わせる」としても良いし、望んでいるシーンでも良い
  • 例…ダウンロード数～以上、販売数～以上、レビューサイトでの評価～点以上など
    • 同人イベントでの頒布なら、「完売しました。ありがとうございます」と参加者にお礼をし、周囲から拍手をもらう…というのが目指す最高のシーンだろう

中間成果物が形になっていく度に成功基準を満たせそうか、満たせないとしたら何をすれば良いのか全員で検討すること（特に序盤は重要な決定事項が多いので、企画、プロット、ハコ書き*15、キャラ一覧…が形になっていく度に、必ず成功基準と照らし合わせると良い）。

以下はアイデアのちからで紹介されている「成功するアイデアの６原則*16」だが、企画・販促など様々な分野に応用できるだろう。

• 単純明快である（Simple）
  • どんな作品か概要を一文で説明できる
• 意外性がある（Unexpected）
  • 驚き、興味など関心を持たせられる：「掴み」がある
• 具体的である（Concrete）
  • 理解しやすい、記憶しやすい
• 信頼性がある（Credible）
  • 検証しやすい、リアリティがある
• 感情に訴える（Emotional）
  • 共感できる
• 物語性がある（Story）

これらからおおよそのターゲット（客層）、制作費の見当までつくとベストだ。

憲章を作る

プロジェクトに関する「決まり事」「誓い」をメンバー全員で策定する*17。大体、以下のようなことが書いてあれば良いと思う。なお、憲章の内容は、メンバー全員の合意があれば途中で変更しても構わない。

• 著作権など権利の詳細な取り決め
  • 共同著作物、集合著作物、結合著作物のどれに該当するか*18
• 定例会議（必要なら）
  • 毎週～曜日～時から
    • スタッフの都合を考慮して、週２回のどちらか一方には必ず参加…など柔軟に対処したい
  • 訳あって出席できない場合は事前にリーダーに連絡のこと、など
• メンバーの離脱に関する規定
  • ～日以上、連絡が取れない場合、無条件でそのメンバーを離脱したものと見なす…など
  • メンバーが離脱した場合、そのメンバーの成果物をどう扱うか
    • 破棄する、またはそのまま使用する。使用する場合、スタッフクレジットに離脱したメンバーの名前を掲載するか否か*19
  • サークル解散に関する規定もあった方が良いかも
• 報酬について（必要なら）
  • 金額、支払い方法、支払日など
  • これはリーダーとスタッフ個人の間でだけ取り交わせば問題ないかも知れない
• その他
  • メンバーの年齢制限、性別制限（作品内容によっては設けた方が良い）
  • 「サークルの掛け持ち」を禁じるか否か*20
  • 違法行為の禁止*21
    • 違法コピーしたソフトを使っているなど、モラルの低い人は意外と多い。そう言う人は普段から危険な言動をする（ブログで違法行為を堂々と書くとか）ので、最初から閉め出した方が無難
    • 他者の絵のトレース、音楽やテキストの剽窃なども当然禁止（数は少ないがごくまれにいる）
    • 成果物の持ち逃げも禁止。現実問題として、こういうことをやっているサークルは存在する。確実な連絡手段を確保しておくべき*22

分岐

習熟度別、難易度別に３つに分けて書いておいた。*23正反対のことを書いてある場合もあるが、別に間違っているわけではない（手法によって考え方が違うというだけだ）。少なくともCCPM編までは読んでおいた方が良い。*24*25

• 基本編…難易度は低め、失敗するリスクは高め
• CCPM編…難易度は中くらい、失敗するリスクは低め
• アジャイル開発編…難易度は高め、失敗するリスクは低め

会議の進め方

意思決定型の会議では、次のルールで進めると良い：*26

• 原則として、議題に対し、提案・要望・質問だけで進める。反対や批判的な発言をしてはならない（前向きな感想であれば発言しても構わない）
• 提案・要望する場合、そう考えた理由や背景も付け加える
  • 提案・要望に対する回答は、ハイ/イイエ、OK/NG、条件付き（または交渉）でハイ/OKのいずれかとする
• 質問は内容を明確化するのに使う
  • 質問と回答ばかり行われる会議にならないよう注意（準備不足）
  • 「それって本当にできるんですか？」のような質問の形を取った反対・批判に注意
• 基本的に「わかりません」という回答はナシで
  • 「自分の意見/感想/考えでは～です」で良いから進める。問題があれば後で修正していく
• 基本的に「検討します」という回答もナシで
  • その場で結論を出すのがベター（最低でも「○日までに回答します」で返す）。問題があれば後で修正していく

最終的な意思決定はリーダーが行う（多数決はやめた方が良い）。事前に、スタッフに以下について合意をもらっておく。

• リーダーの決定が自分の考えと違っていても、リーダーの決定に協力する
• スタッフは少しでも良い結果になるよう発言を尽くす
  • リーダーは、スタッフが発言し尽くしたか確認すること*27

進捗状況の視覚化

プロジェクトの進捗状況を視覚化する手段は色々あるが、ソフトウェアカンバン（タスクボード）と月めくりカレンダーの併用がシンプルで使いやすいと思う。

ソフトウェアカンバンは未着手（正確には近日作業予定）、作業中、完了したタスクを一覧にしたもので、個々の項目にはタスク名、作業担当者、作業期間が書いてあれば良いだろう。*28

1. リーダー（メンバー全員でも良い）がTo-Do欄に近日作業予定のタスクを並べる（タスクはスケジュールから拾ってくる）
   • 定例会議などのタイミングで定期的に補充する
   • タスクの粒度によっては、そのタスクに含まれる細かい作業に分解し、この表に記述しても良い（特にCCPMの場合、タスクのの粒度が荒くなる傾向にあるので上手く活用すると良い）
2. 作業担当者はTo-Do欄のタスクに着手したら、そのタスクをDoing欄に移動する
   • 着手中のタスクを半分終えた頃から、あと何日で終わりそうか、定期的（毎日が理想だがダメなら２～３日おきでも）にDoing欄に書き込む
3. 作業担当者はDoing欄のタスクを完了したら、そのタスクをDone欄に移動する
4. リーダーがDone欄のタスク完了を承認したら完了マークを付ける
   • 定例会議などのタイミングで定期的に削除する

月めくりカレンダー（できれば来月も表示しているモノ）には主にマイルストーンを記入する。また、特定の期間でしか実施できないタスク、個人的な事情（都合で出席できないとか）などを記入しても良いだろう。

進捗状況の視覚化は、どちらかと言えば

• メンバーが何をしなくてはならないのか、メンバーが何をしているのかを明確にする
• リーダーが欠席していても作業を続行できるようにする
• メンバーにプロジェクトへの参加意識を高める

などを狙ったものであり、これのみでプロジェクトが管理できると考えてはならない（あくまでスタッフとのコミュニケーションが重要）。

振り返り

10分程度で構わないので定期的（または何かトラブルを解決した際）に「何か学んだことはないか」メンバー全員で振り返ると良い。

• 何が起きたか？
• 何を予想していたか？
• この乖離から学べることは何か？

コミュニケーション

「コミュニケーションが大切」とはどこでも言われていることだが、「具体的に何をどうすることなのか？」と訊かれたら人によって解釈はかなり違い、言語明瞭意味不明というかバズワードな側面が強い。

ここでは、コミュニケーションで最も重要なことは以下だと想定する。100%の合意を得られなくても構わないが、決まったことを100%の力で実行できる状態にすることが重要。*29

• 相手の立ち位置、意見、気持ちなどを互いに知ること（理解までは行かなくても良い）。賛成／反対する点、その理由を訊く。理由は論理的でなくても構わない。感情的・感覚的に賛成／反対でも問題ない
  • 合意内容を確認する
  • 何が対立しているのか確認する
  • 微妙な認識の違いを見つける
  • 対立している中でも何か共通点がないかを見つける
• コンセプトなど「重要な核」についてメンバー全員に「この方向で一つやってみるか」と納得してもらうこと。それ以外の細かい部分については多少の意見の違いはあっても構わない（100%納得なんて到底無理な話だ）

何よりもコミュニケーションした「つもり」になっていないか、常に気をつけた方が良い。

メールによるコミュニケーション

メール（厳密には文字情報によるコミュニケーション手段全般：チャット、Twitterなどを含む）はコミュニケーションにおける重要なツールだが、以下のような落とし穴もある。

• 簡潔に書くことを心がけるあまり、互いの立ち位置、意見、気持ちなどを充分に伝え合わない
• 情報は共有できていても、「どの程度重要か」までは共有しにくい。特に扱うメールの数が多いと顕著になる
• 「返事が来ない」が何を意味するのか判らない

つまり、メールは情報共有のツールとしては優れているが、人の価値観や気持ちを伝達するツールとしては欠点が多い。以下のような方法で補うと良い。

• できるだけ密なメールのやりとりを心がける
  • 些細なことでも返事・確認を。返答が不要なメールならサブジェクトに【返信不要】と書くなど、工夫すると良い
  • 程度問題だが顔文字やアスキーアートを活用しても良いと思う
• メールの重要度を活用する
• 可能であれば実際に会う、ボイスチャットを併用するなど、別のコミュニケーション手段も活用する

スタッフの特性、作業負荷傾向など

参考程度に（常にこうなる訳ではない）。

シナリオライター

• ゲームの完成形をもっとも明確にイメージできる人その１
  • リーダー向きだが、プロジェクトマネジメント云々は知らない場合が多いため、迂闊にリーダーに据えるとプロジェクトが混乱しやすいので注意
    • 故にリーダーに据えるなら、ゲーム開発経験者の方が良い
• プロジェクトにとって最大のボトルネックその１*30
  • 故にリーダーに据えるとマネジメント作業が増えるぶん、プロジェクトが長期化しやすい。あるいは逆にゲームの質・量で劣りやすくなる
• 作業ペースや開始時期次第だが、プロジェクト終盤になると急に手が空く傾向
  • 商業ではドラマCDとかSSとか仕事はいろいろ続くらしいが…

イラストレーター

• ゲームの完成形をもっとも明確にイメージできる人その２
  • リーダー向きだが、プロジェクトマネジメント云々は知らない場合が多いため、迂闊にリーダーに据えるとプロジェクトが混乱しやすいので注意
    • 故にリーダーに据えるなら、ゲーム開発経験者の方が良い
• プロジェクトにとって最大のボトルネックその２
  • 故にリーダーに据えるとマネジメント作業が増えるぶん、プロジェクトが長期化しやすい。あるいは逆にゲームの質・量で劣りやすくなる
• 序盤はイメージラフ、終盤はパッケージや販促イラストと、最初から最後まで仕事をしているのが普通

スクリプター

• 採用したノベルエンジン、本人のスキル、ゲームの仕様（演出の度合いやシステムの凝り具合）などで作業量の変動が激しく、一概に言えない
• シナリオライター出身か、プログラマー出身かなどでも傾向がかなり変わる
  • プログラマー出身でも、過去のキャリアや、現場でどの程度経験を積んだかで傾向がかなり変わる（現場経験がないとリスキーな判断を下しやすい）
• 終盤に重要かつクリティカルな作業が集中しやすい
  • 前工程から成果物を受け取る際、想定外の事態が起こりやすいため、自己防衛策としてフォトレタッチソフトやDAW・波形編集ソフトを所持してる人も珍しくない（別に絵が描けるわけでも作曲できるわけでもない）
    • このためノベルゲーム制作過程全体をある程度理解している人が多い。しかし、ゲームの完成形を明確にイメージできているかと訊かれたら話は別

リスクの考慮

多くの場合、ギリギリの人数でゲームを制作しているため、同人ゲーム制作プロジェクトのリスクは最初から高いと言える。リスクを如何に減らすかがポイントとなる。

スタッフの離脱

スタッフの離脱（病気怪我でも逃亡*31でも意見の食い違いでも）は、即、同人ゲーム制作プロジェクトを中止に追い込むほどのダメージがあるため、事前に軽減／回避策を打っておくことが望ましい。

すぐ思い浮かぶ回避策は「各作業担当を複数起用する」だが、人数が増えるとマネジメントが加速度的に困難になるデメリットもある。

イラストレーターの離脱

• ゲームの印象が大きく変わるため、影響が最も大きい：つまり販売数に響く（特にイニシャル）
• 原画（立ち絵、イベント絵）を優先的に仕上げさせれば、リスクはかなり軽減する。背景・システム画像素材や彩色は別の人がやっても問題になりにくい

シナリオライターの離脱

• よほど個性的なテキストを書くライターでなければ、別の人が続きを書いても判別しにくい。ただし、馴れているプレイヤーは容易く見抜いてしまう
• 全体プロット／部分プロット・ハコ書きを優先的に作成させれば、引き継ぐライターがどんな話を書けば良いか判るため、リスクはかなり軽減する

スクリプターの離脱

• マクロやサブルーチンなどのライブラリは、その使用方法・仕様を（スクリプト中のコメントで充分）まとめておけば、別のスクリプターに引き継ぎやすい
• スキルの乏しいスクリプターが書いたスクリプトは、往々にして危険な（バグを誘発しやすい）スクリプトである可能性が高く、最悪、全て書き直した方が早いときもある

リーダーの離脱*32

• 基本的に解散するしかないと思う
• 代理のリーダーはまず見つからない。多くの場合、「自分が作ってみたいゲーム」とは異なるため
• 残りのスタッフからリーダーを立てる場合、スケジュールの大幅変更が必要になる
  • スタッフの成果物をチェックしたり進捗管理するだけでも手間がかかる*33し、自分の作業が中断されると元のペースに戻るには時間がかかるものだ
  • まして引き継ぎが不十分だと、しばらく混乱が続き作業どころではない

「表現の自由」に関する問題

「表現の自由」は創作を支える重要な概念だが、時に他の権利を侵害したり、法律に抵触することもある。ボーダーラインがハッキリしないという点でやっかいなリスクだろう。

• 性、暴力、犯罪に関する創作表現は「表現の自由」か「犯罪」か
  • 公開する場に倫理規定があるなら、その基準に従う
    • ないならリーダーが責任を負うことになるだろう
  • 感情的で無知・無理解な「敵」は存外多い*34
    • かと言って万事に消極的になったら創作は終わりだ
    • 理性的で理解ある「味方」もまた多い。味方は増やしておくに越したことはない
• 二次創作の場合、著作権者が許諾または黙認しているか
  • 許諾している場合、その許諾範囲に従う
  • 黙認している場合、著作権者がいつ態度を変えるかは判らない
• その他、物議を醸しやすい表現は色々ある。心の片隅くらいには留めておきたい
  • その他の反社会的表現
  • 宗教の違い
  • 歴史認識の違い
  • 主義、イデオロギーの違い

表現の自由は尊重されるべきだが、その自由には責任が伴う。そして権利を乱用していると見なされれば、反感を持つ者が増え却って規制は強化される。肝に銘じておきたいものだ。

モチベーションの維持

恐らく永遠かつ最大の課題だと思うが、ここでは大して言及していない。*35

• 可能な限りすぐ応対すること
  • どうしても出来ない場合は事前に一言断りを入れておく
• 目標やタスクをノルマと感じさせず、チャレンジの対象、栄光への道と思わせること
  • 始まって２～３ヶ月目くらいまでに最初の「目覚ましい結果」*36が出るとベター
• 価値がないと思った作業はやめるか修正する（惰性で続けているとモチベーションの低下に繋がる）
  • どんなやり方が自分たちに合っているか見極める意味でも、定期的にいろんなやり方を試してみると良い

プロジェクトはいったん休止したら最後、モチベーションを取り戻し、再開するのは困難になる。プロジェクトの進行スピードは緩めない方が良い（一気呵成が理想）。*37

プロジェクトには大きく３つの段階がある。*38

1. 最初は希望に満ち満ちている
2. プロジェクトが進むにつれ、困難・苦労・ミスが待ち受けている
3. これらを一つ一つクリアしていくにつれ、自信に満ちてくる

重要なのは「困難・苦労・ミスで落ち込むことを覚悟する」、「だが進みさえすれば次第に状況は良くなり、最後には成功する」と考えることだろう。

一部を除いて、同人ゲームのほとんどは赤字だ（はっきり言って割に合わない）。にも関わらず、同人ゲームを制作する理由は何か、それがどんな意味を持つのか、何が自分達をそこまで駆り立てるのか、この道を選んだルーツは何か、一度振り返ってみると良いだろう。これを思い出せれば、困難に直面しても乗り越えようという意欲に結びつくはずだ。

リズムを保つ

• 毎週～曜日～時に必ずチャットに集合など
  • 事情で出られない場合は事前に報告してもらう
• ～週間おきに何らかの成果物を仕上げる、または完成せずとも～まで進める
  • １～２週間おきに「○○日までに××まで作業する」など
• 定期的にスクリプターがゲームのドラフト版をリリース*39
  • スクリプターに負担がかかる
  • 元もと面白くないゲームだと、却ってモチベーションが低下することも…

仮説、理論など

モチベーション理論は多数提唱されているが、ここではデイビット・Ｃ・マクレランドが指摘する「達成動機が喚起されやすい状況の特徴」だけ紹介しておく（太字は筆者の判断で引いたもの）。*40

1. 成功裡に達成できるかどうかは、（運ではなく）努力と能力しだいである状況
2. 課題の困難度、あるいはリスクが中程度（つまり成功・失敗の主観的確率が五分五分ぐらい）の状況
3. 努力の結果、うまく目標が達成できたかについて、曖昧さがなく明瞭なフィードバックがある状況
4. 革新的で新規の解決が要求されそうな状況
5. 未来志向で、将来の可能性を予想して先を見越した計画を立てることが要請されるような状況

過剰なマネジメントは逆効果

マネジメントは確かに必要だが、逆にマネジメントし過ぎてもいけない。さじ加減は難しいのだが、「スタッフは与えられた役割を果たすだけ」というチームになってしまうと、スタッフから創造性が失われてしまうので注意したい。

• メンバー全員の感性が影響し合うことで、個人では到達できない作品を制作できることが集団制作の醍醐味だ*41

ゲームのような集団での創作の場合、予期しない出来事が次々と起こる。このため、メンバーにはどうしても自分の役割を超えた仕事を求められることが多い。これを乗り越えるにはかなりの意欲が必要だ。如何にしてスタッフから意欲を引き出すかが決め手になる。*42

TIPS

採用するかどうかは各自の判断で。

「やらないこと」も決める

後になって「どうしてこう決まったんだっけ？」と悩むことが意外と多いので、企画段階で「やること」だけでなく「やらないこと」*43も一緒に決めておく。また、なぜそう決定したのか理由・経緯も簡単に記録しておくと良い。

イエローフラッグ／レッドフラッグ

これらはメンバーにタスクの進捗状況を知らせるもので、イエローフラッグは「まだ挽回可能だが困った状態になった」ことを、レッドフラッグは「どうやっても目標が達成できない状態になった」ことを意味する。

進捗管理では（レッドフラッグが挙がらないよう）、イエローフラッグになった段階で即報告して貰うことが重要になる。スタッフに以下の認識を浸透させると良い。

• イエローフラッグを挙げることは良い行い
• （イエローフラッグをすっ飛ばして）レッドフラッグを挙げることは悪い行い

こうすることで少しは「問題を報告しやすい雰囲気」を作ることができる。

どういう状況ならイエローと判断するかはスタッフ個人に委ねる。プロジェクトが進んでいくうちに、「この人は心配性」「この人は危機感が薄いのでまめにチェック」といったことが判ってくるので対応もしやすくなる。*44

30分ルール

30分考えても作業が進まないようならメンバーに相談すると良い。*45

手が止まらない程度の雑談はOK

雑談（仕事に直接関わらない話、特にメンバー個人の話）は利害に絡まないぶん、互いを理解し、親密さを増すのにはうってつけの手段である。（仕事の）手が止まらない程度の雑談ならむしろ推奨してもいいだろう。

ビジョン、夢も決める

いずれも目的のさらに上位の概念だ。二作目、三作目と続けていく場合にはいずれ必要になってくる。大体、次のように考えれば良いだろう。

• 「夢」とは、将来実現させたいと、心の中に思い描いている願い
• 「ビジョン」とは、未来像、その光景
• 「目的」とは、成し遂げようと目指す事柄
• 「ゴール」とは、目的のための最終的な目印（目的や目標と同じ意味と捉える向きもある）
• 「目標」とは、目的を達成するために設けた目安や通過点

重要なのは、リーダー自らこれらを体現しようとする姿勢だ。自分ができもしないことをメンバーに強要してはならない。

至言

段取り八分

仕事の段取り（準備・下調べ・計画など）をしっかりやっておけば、その仕事は８割方完了したも同然という意味。プロジェクトに関わる者にとって永遠のテーマ

類は友を呼ぶ

自分の実力にふさわしい人間が自分の周囲に集まるものだ。実力のある人の周りには自然と実力のある人が集まるし、実力のない人の周りには実力のない人しか集まらない。常日頃から自分の実力を上げておくことが重要

前工程は神様、後工程はお客様

自分にできないことをやってくれる前工程に感謝せよ、後工程のことを考えて仕事せよという意味。元はトヨタ自動車の言葉

先ず隗より始めよ

リーダーは率先垂範であること。メンバーに要求するだけではメンバーはリーダーについてこない。「先ず自分が○○をやる、あなたは○○をやって欲しい」で初めてメンバーは納得し、チームが動き出す

トホホ集

ゲーム制作経験が乏しいスタッフにありがちなケースをいくつか列挙してみた。リーダーまたは知識のある者がフォローすること。*46

リーダー編

• サークルを結成してからゲームの内容を決める
  • メンバーはそれぞれがそれぞれの「ゲームの完成形」をイメージして参加している。多くの場合、決定した企画はそのイメージと異なるモノになるはずで、そうなってしまえばメンバーのモチベーションが落ちるのは当然
    • ２作目以降ならともかく、処女作なら概要くらい決めてからサークルを結成する方が良いと思う
  • 「ゲームを作ってみたいからサークルを結成」ではメンバーの方向性が定まらず発散する。どんなゲームにするのか（企画書などで）明確にするのは最優先
• ゲーム制作を勉強するのが目的
  • 目標が低すぎる上に曖昧
• 自分はアイディアを出すだけ、言いなり＆タダ働きしてくれる人を募集
  • 幼稚園からやり直そう
• 初心者のみ募集
  • 経験者に対して遠慮があるのかも知れないが無謀。「三人寄れば文殊の知恵」と言いたいところだが、烏合の衆は何人集まっても烏合の衆*47
• リーダーがゲーム制作未経験者
  • スタッフに対して的確な指示が出来ない。特に仕様が書けないと致命的
  • あるタスクにどの程度の時間が必要か見積もれない
  • どんなタスクを経れば最終成果物に辿り着けるか判らないため、正確なWBSも書けない（当然、スケジュールもいい加減になる）
• シナリオも絵も音楽もスクリプトも出来ないからリーダーをやる
  • ゲーム制作舐めすぎ
• スタッフ全募集
  • 理想を言えば、信用できるスタッフを一人でも多く自力で探す方が良い*48
  • インターネットは人集めを容易にしたが、同時に縁が切れるのも容易にした
• アイディアを盗まれたら困るので、（信用できる人が）正式に参加して貰えるまで企画書の類は見せられない
  • 詭弁。メンバーの中で最も信用が求められるのはリーダーだ。そのリーダーがスタッフから信用されるような行動を取らなければ、そもそもサークルなど機能しない。順番が逆
• 処女作が超大作
  • 夢を見過ぎ
• 実績が何もない段階で「商業化を目指す」
  • 寝言は寝てから言おう
  • 「スタッフの生活、果ては人生に責任を持つ」という自覚がない証拠
• ちょっと挨拶した程度で「知り合いに業界人（プロ）がいる」と自慢
  • 向こうがどう思っているか訊いてみるのも一興
  • 単なる同人ゴロという可能性も
• 一部のメンバーだけが仕事をしている
  • スケジュールを的確に立てていないか、スタッフに対して的確な指示ができていない証拠。仕事をしていないスタッフのモチベーションは落ちるし、仕事をしているスタッフは不平感を持つ
• おおよその完成予定日が決まっていない
  • 緊張感がないとモチベーションが落ちて自然消滅しやすい
• スタッフの報告だけで進捗状況を把握
  • メンバーが多いならともかく、そうでなければ自分の目で見た方が確実
    • 進捗具合の判断は人によってかなり違う。また、心情的に「良い報告」をしてしまいがち
• まだゲームを完成させていないのに、途中で２作目、３作目のゲーム制作プロジェクトを開始する
  • 「ゲームを制作している自分、スタッフを指揮している自分」に陶酔しているか、制作序盤のワイガヤでゲームを作っている雰囲気を楽しんでいるだけ（夢を語り合うのは楽しいものだ）。現実という壁を乗り越えるだけの実力も、スタッフに対する責任感もない。すでに１作目の制作がイヤになって投げ出した証拠
• 正論を振りかざしてメンバーを動かそうとする
  • 正論とは上から目線の嫌み、悪口、攻撃、誇示などと大して変わらない。正論それ自体は間違っていないので、相手は抵抗できない。だからこそ相手を傷つけ却って反感を買う。メンバーを動かしたいなら相手と同じ目線に立って、腹を割って話し合い、共感・納得してもらうしかない*49
    • 「正論は100回唱えても何も変わらない。正論で世の中は変わらないし、正論で人間は動かない。もしそうなら誰も苦労しない。正論のつまらなさは、正論でなぜ人が動かないかを理解しない無知と傲慢さにある」(上野千鶴子『おんなの運動論』)
    • 正論で人が動かないというのは、正論の中に「人がなぜいやがるのか」「動かないのか」という気持ちを構成している、「本当の理由」について目を向けていないからだ。(論理力を鍛えるトレーニングブック、渡辺パコ)
• リーダーシップの欠如
  • 多少、メンバーに技術力・知識があっても、リーダーシップのないリーダーの下でゲームを完成させるのはやはり困難
  • スタッフから信頼されないリーダー、率先して働かないリーダー、スタッフを引っ張らないリーダーに、リーダーの役目は果たせない
  • リーダーシップ、コーチングに関する書籍を何冊か読んでおくと得るモノは多い（実践できるかどうかはまた別の話だが）
• スタッフに相談されても「頑張れ」など精神論で返す
  • スタッフが精神的に孤立してしまう。スタッフは専任であることが多く、門外漢は力になれないことも多いが、それでも出来るだけの協力はするべき。相手の話を訊くだけでも、あるいは（素人なりに）案・ヒント・刺激になる話題を振るだけでも結構違う
    • この時、自分の考えを押しつけるのは危険。アイデア出しに協力する程度に留めるのが無難だと思う*50
• 何でも多数決で意思決定
  • （多数決が良いことも確かにあるが）無責任。プロジェクト迷走の元
  • スタッフ全員の意見を集めて、最終的にはリーダーが一人で決めること

シナリオライター編

• 文章で周囲の状況を完全に描写してしまう
  • 小説畑出身のライターにありがちなケース
  • 周囲の状況といった演出作業はスクリプターにやらせて、本来のストーリーを進めるべき
• 第三者（神）視点でシナリオを書いてしまう
  • 演劇・映画畑出身のライターにありがちなケース
    • 表現手法上、ト書き（演出指示や演技指導）で書けることにも限界がある
  • 基本的にシナリオは主人公視点で書くべき
    • ストーリー重視のRPGとかだとまた違うと思うが
  • 「地の文」と呼ばれるモノローグとも異なる状況描写がある
• 設定がやたらと膨大、または設定しか書いてこない
  • 風呂敷の広げすぎは破滅を招く。畳めないと意味がない
  • 妄想するのが好きなだけでストーリーを書ききる実力がない可能性も…
• メリハリや盛り上がりがない／話の途中でテーマを喪失、または収拾がつかなくなる／説明・描写不足／伏線が回収できていない、または逆に伏線がない／終盤で超展開
  • プロットやハコ書きを軽視するライターに多い*51
• 文学、哲学などやたらと高尚な要素を入れようとする
  • 「独りよがりなシナリオ、ユーザーのことを考えない／楽しませる気がないシナリオは最低」だと、シナリオの入門書にすら書いてあること*52
• シナリオをMicrosoft Wordなどワープロソフトのファイル形式で納品
  • （スクリプターが直ちに扱える）テキストファイル形式で納品するのが普通
  • 剛の者になるとExcel形式ファイルで納品って人もいるらしい…
• シナリオなら誰にでもできると思い込む
  • 実際にやってみると判るが、ストーリーを完結させるにはそれなりの力量が必要
  • 一定の社会経験・人生経験がないと、ツッコミどころ満載のシナリオになりがち
  • 「てにをは」が使いこなせないなど、いわゆる「日本語がおかしい」文章を書いたり、視点がコロコロ変わって読みにくい文章を書くなど
    • ここまで酷いとシナリオライターとしては使えないと思うが…

イラストレーター編

• 画像の透過方法を知らない
• レイヤーの概念を知らない
  • （リアルの）油彩・水彩などが長い人にありがちなケース。構成とか描く順番とか頭の中で綿密に組み立てているらしい（これはこれで凄いスキルなんだが）
  • 差分素材を作成するのが面倒になる

スクリプター編

• 高性能・多機能らしいが実績のほとんどない新しいノベルエンジンを採用する
  • 新しもの好きに多い
• 自分のスキルのなさを認めずノベルエンジンのせいにする
  • 他のスタッフはスクリプトのことをほとんど知らないため、このような言い訳が通じると思っている（スクリプトにある程度精通している人なら容易く見抜ける）。同様の傾向はスキルのないプログラマーにもある
• ノベルエンジンのマニュアルを読まない／読むのが面倒くさい。講座などに記載されているスクリプトをコピー＆ペーストするだけ
  • スクリプターとしての適正がない。想定外の事態が起きると自力で解決できない
• ユーザビリティやプレイアビリティを無視したスクリプトを書く。画面演出の際、スキップやキャンセルを無効にするなど
  • 頑張ったところをプレイヤーに見て欲しいって気持ちは判るが、プレイヤーからするとウザいだけ
• 費用対効果を無視したスクリプトを書く
  • 長時間かけて技術的に高度なスクリプトを書いても、得られるモノがほとんどないなら大して意味はない。短時間かつ初心者でも書けるスクリプトで似たようなモノが得られるならこっちの方がマシ
    • 何事もシンプルイズベスト
    • 変に原理原則に従う必要はない。「それらしく見える」ことは重要
  • 同様の傾向（コスト意識や大局観の欠如）はプログラマーにもある

プログラマー編*53

• ノベルエンジンをわざわざ自作しようとする
  • ちょっとプログラミングを覚えた人にありがちなケース。まず完成させられない。仮に完成させたとしても、制作／プレイしにくかったり、これが原因でバグが多発するのがオチ*54
    • 基本、ノベルエンジンはプロジェクト開始前に予め用意しておくモノで、プロジェクト中に開発するモノではない。このような発想をする人は危険。実績を充分に積み重ねたノベルエンジンと、完成したばかりのノベルエンジンのどっちを採用するか？と訊かれれば誰だって前者を選ぶものだ
    • 文字と画像を表示して音楽を再生すれば良いだけと思っている人に多い（もちろんそんな単純な話じゃない）。実際のところ、使い物になるノベルエンジン開発はかなり大変だ
  • AIR、Silverlight、Javaなどのキーワードを出してくる人（単なる新しもの好き）は遠ざけた方が無難だと思う（確固たる決意があるなら別だが）。あとスクリプト言語仕様にXML採用とかって人（スクリプターのニーズを理解していない）も
  • 国内には多数のノベルエンジンが公開されているが、使い物になる（まともに採用されている）のはごく一部に過ぎない
• インストーラ作成ツールを自作する（インストーラではなく）とか言い出す人も避けた方が良い
  • これもちょっとプログラミングを覚えた人にありがちなケース。ファイルのコピー／削除だけで済むと思っているのだろうが、もちろんそんな単純な話ではない
    • 商業ゲームでこれをやってしまい、ユーザーに多大な被害を与えた事例がいくつか存在する
    • 実際、Vectorには多数のインストーラ作成ツールが登録されているが、使い物になるのはごく一部に過ぎない
• マルチプラットフォームを目指す
  • 売り上げが増えるとか安易に考えているんだろうが、プラットフォームの数だけテスト環境を揃えなくちゃならないことを忘れている
    • 費用対効果を考えたら、大して普及していないプラットフォーム用のテスト環境を用意するより、一番普及しているプラットフォームを一つだけ絞った方がマシ
  • 最近だとスマートフォンでリリースするとか
    • 2012年3月時点のスマートフォンの国内市場は契約数ベースで端末総契約数の22.5%に過ぎない（ただし成長率は高いので無視してはいけない）

その他

• 自分が輪の中心にいないと気が済まない。人の話を聞かない
  • チーム作業に向いてない。ただ、こういう個性が強すぎる人ほど才能があったりして、リーダーの手腕が問われることも…
• 指示に従わない
  • シナリオライターなら、プロットから逸脱したシナリオを書くなど
  • イラストレーターなら、キャラ設定を無視した立ち絵、字コンテを無視したイベント絵を描くなど
    • 説得してもダメなら辞めてもらった方が良いと思う。変に妥協／受け入れると却ってチームワークが乱れる
• 商業ゲーム並のクォリティを要求
  • 身の程を知ることは大切
• 実績はあるが教えられない
  • 間違いなく詐欺。クリエーターはいろんな作品に名前がクレジットされてナンボ。自分を売り込むためにも仕事履歴には必ず関わった作品名を並べているのが普通。隠す理由がない*55
• 不誠実
  • 他のメンバー（やユーザー）から信頼されない。結果、どうなるかは言うまでもない

プロジェクトマネジメントシステム、スケジュール管理ソフト

WBSやプロジェクトマネジメントを理解してないと、プロジェクトマネジメントシステムは却って害悪と化す*56ので注意。何を採用しても微妙に使いにくい部分があると思うので、妥協や創意工夫が必要。

何よりも重要なのは「メンバー全員が同じツールを同じように使いこなせる」こと。これができないと、どんな素晴らしいツールを採用しても意味がない。裏返せば、全員が使いこなせるツールなら原始的なツールで仕事は充分できる。

Microsoft Project

定番プロジェクトマネジメントシステム（アマチュアが使うようなソフトじゃないけど）

BeingManagement

CCPM対応プロジェクトマネジメントシステム（これまたアマチュアが使うようなソフトじゃない）

Microsoft Excel

定番表計算ソフト。プロジェクトマネジメント／スケジュール管理専用ではないが、使い方次第で割と万能に。ベクターにもガントチャートマクロなどが公開されている。無償で済ませたいならOpenOfficeのCalcが良いだろう

がんすけ

シェアウェア版ではWeb上のスケジュールデータを参照できる。フリーウェア版もあり

GanttProject

要JRE。日本語にも対応している。Web上でスケジュールデータを共有できるようだが未確認

OpenProj

要JRE。日本語も扱えるが1.4は完全に日本語化されていない

以下は未評価のため詳細不明。

• Trac Lightning
• ProjectKeeper
• dotproject.jp
• 9Arrows
• みんなでガント.com

イナズマ線を引けるものなら全体の進捗が把握しやすいので便利（１つのタスクに対し予定と実績の線が引けるものでも良い）。

参考

書籍

プロジェクトマネジメント

いわゆるSIベンダー向けの本格的なプロジェクトマネジメント本は、責任を明確化するように（穿った見方をすれば責任を取らなくて済むように）、いたずらに文書化や承認手続きを面倒にしている一面があるため、アマチュア向きではない。

世界一わかりやすいプロジェクトマネジメント 第4版

一冊読むならこの本らしい。厚い本だが読みやすく苦にならない

プロジェクトを変える12の知恵

プロジェクトマネジメントと言うよりプロジェクトファシリテーション（プロジェクトの促進）の手法についてまとめた本。オーソドックスな内容ながら実践的で良くまとまっている。ガチガチに管理しないスタイルが個人的に好み。適用領域は異なるが『業務改革の教科書 成功率9割のプロが教える全ノウハウ』『反常識の業務改革ドキュメント プロジェクトファシリテーション 増補新装版』も読んでおきたい

トム・デマルコの「プロジェクト管理」がわかる本

トム・デマルコ氏の著作の要点をまとめたもの。↑の補完に。正反対の主張もあるが的を射ている指摘も多い。できれば本来の著作もチェックしておきたい

TOC/CCPM標準ハンドブック クリティカルチェーン・プロジェクトマネジメント入門

CCPMを理解するならこの本。CCPM（とTOC）の理論的根拠まで踏み込んでいる上に、ソフトウェア開発プロジェクトでの適用法についても言及されている。これの原典は『クリティカルチェーン』となる

最短で達成する 全体最適のプロジェクトマネジメント

『目標を突破する 実践プロジェクトマネジメント』の改訂版。CCPMを平易に解説したもので要点を押さえている。↑の補完に

CCPMインプリメンテーションハンドブック

CCPMを組織に定着させることに重きを置いた内容。事前にS&Tツリーなどを理解している方が良い

進む! 助け合える! WA(和)のプロジェクトマネジメント プロマネとメンバーのためのCCPM理論

従来型プロジェクトマネジメント手法に馴れた人がCCPMを適用した時の経験談に重きを置いている。ITプロジェクトが多い。事前に「CCPMインプリメンテーションハンドブック」などを読んでおいた方が理解が深まる。請負契約内容に踏み込んでいる点は興味深い

仕事は半分の時間で終わる! あなたの常識がスケジュールを遅らせる

CCPMベースの仕事術本という珍しい立ち位置の本

実務で役立つWBS入門

WBSに関して最も掘り下げた書籍

大工の棟梁に学ぶプロジェクトマネジメント

プロジェクトマネージャの心構えについて書かれている。業種は異なるが、個人的に納得できる点が多かったので掲載

アジャイル開発手法

アジャイル開発は（密なコミュニケーションというハードルはあるものの）同人ゲームに向く手法だと思うのだが、アジャイル開発の経験がないとリーダーはまず務まらないし、総じてメンバー（特にスクリプターとプログラマー）には実力が求められるしで、敷居が高いというデメリットもある。

SCRUM BOOT CAMP THE BOOK

SCRUMの入門書。陥りやすい点などもフォローされており実践的な内容

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理

ゲーム開発を題材としているが、一般のソフトウェア開発でも有用な内容

アジャイルCCPM プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす

CCPMベースのアジャイル開発手法。CCPMに慣れているなら

アジャイルプラクティス

アジャイル開発の理解を深めるには良い一冊

アジャイルサムライ 達人開発者への道

このアメリカンなノリは正直どうかと思うがアジャイル開発の理解を深めるには良い一冊

コーチング、リーダーシップ、マネジメント

誤解のないよう補足しておくと、コーチングとは、対話を通して相手のモチベーションや可能性を引き出し、ゴール達成を支援することで、相手に「○○しなさい」と指導することではない。

目からウロコのコーチング なぜ、あの人には部下がついてくるのか？

コーチングの入門書。理屈っぽくなく腹落ちしやすい上に充実した内容

コーチングが人を活かす

コーチングの入門書。リファレンスとして読み返すのにも良い

コーチングのプロが教える「ほめる」技術

正確には褒めるのではなく、アクノレッジする（相手のことを認める）ことに重きを置いた本

リーダーが身につけたい25のこと

リーダーシップの入門書として必要十分な内容。名著はたくさんあるがコーチング本の著者繋がりでこれを挙げておく*57

メンタリング・マネジメント 共感と信頼の人材育成術

メンタリングによる人材育成とは何かを解説。どちらかと言えば、リーダーの「人」としての生き様を問う内容

すごいチーム 結果を出すチームマネジメント12の方程式

メンバーのチャレンジ精神を引き出す「すごい会議」をベースとするチームマネジメント手法。「すごい会議 短期間で会社が劇的に変わる！」、「秘伝すごい会議」、「たった１日でチームを大変革する会議」、「すごい考え方」も併せて読んでおきたい

任せる技術 わかっているようでわかっていないチームリーダーのきほん

仕事の任せ方のコツが判りやすくまとまっている。ただ実践するには相応の勇気が必要

リーダーのための7つのステップ 49のコツ

７つのステップを通して段階的にリーダーシップを育成していく内容。ただ、巻末のワーク＆シート編は正直微妙なものも…。なお「マンガでやさしくわかる課長の仕事」はこれの漫画版

結束力の強化書

チームの結束力を高める手法がまとまっている。これだけではピンとこないと思うので、応用編の「リーダーの言葉が届かない10の理由」も併せて読んでおくと腹落ちしやすいと思う

頭を下げない仕事術

スーパー公務員（かつ僧侶）が書いた仕事術本。「自分には無理」というものも含めて得るものは多い。事前に「ローマ法王に米を食べさせた男」を読んでおくと理解・共感が深まる。明らかに「？」な記述も見受けられるが実務家独特の感覚というものだろう

これらは所詮小手先のテクニックに過ぎないことを肝に銘じておくこと（勉強しないよりはずっと良いが）。メンバーが最も影響を受けるのは、尊敬・信頼に足るリーダーの生き様だ。こういうリーダーを前にすれば、人は誰でもやる気になるものだ。

ファシリテーション

ファシリテーションに関する書籍は多数あって、何を薦めれば良いか判らなくなってきているが、取り合えず要点を押さえている書籍だけ挙げておく。会議をやっても方向性が定まらない、結論が出ない、話題がズレる…といった場合にはファシリテーターが求められる。

世界で一番やさしい会議の教科書

実践的な入門書の決定版。小説形式で理解しやすい上に、日本の組織にファシリテーションを定着させるうまい方法についてもまとめられている

世界で一番やさしい会議の教科書 実践編

↑の続編。体系的でより実践的な内容

今すぐできる! ファシリテーション

実践的で入門書としてもそつなくまとまっている。初期の書籍だが『ファシリテーション入門』でも良いと思う（内容はかなり違うが…）

ファシリテーターの道具箱 組織の問題解決に使えるパワーツール49

ファシリテーションで良く使うツールを解説したもの。一部はオンラインでも応用できる

ワクワク会議

７つのツールをどう応用するかに絞っており、実践的な解説や注意点が多い。氏の著作の中ではフランクなノリで読みやすい

ノベルゲーム制作

類書は他にもあるが、特定のツール／ジャンルを前提としているモノが多くて、汎用的なモノは意外と少ない。

ノベルゲームのシナリオ作成奥義

シナリオライター向けだがゲーム制作の全体像を掴むには良い一冊。『ノベルゲームのシナリオ作成技法 第２版』も併せて読んでおきたい

ゲームシナリオを書こう!

複数ゲームシナリオライターによる指南書。シナリオの書き方に関して実践的で役に立つヒントが多い。↑の補完に

ウェブサイト

プロジェクトマネジメント

• ITpro
  • 開発プロセス…プロジェクトマネジメントの基本、プロジェクトマネジメントの実践スキル
    • プロジェクトの道しるべ WBSの作り方
• @IT
  • @IT情報マネジメント プロジェクト管理
• プロジェクトが成功する７つの秘訣―海外の開発者が語る
• 吉田誠一のホームページ
  • WBS（Work Breakdown Structure）によるプロジェクト管理
• オブジェクト倶楽部
  • プロジェクトファシリテーション
• コラボレーション・パターン

アジャイル開発

• アジャイルモデリングへの道
• マイクロソフトのアジャイル開発支援

その他

• IGDA日本
  • SIG-Indie : 講演スライド６つの公開を開始しました
  • SIG-Indie : 9月のSIG-Indie3「シナリオ作成技法とメイキング」講演スライド＆記事リンク
  • SIG-Indie5「ノベルゲーム制作実践テクニック-素材制作の技術と制作管理・宣伝のノウハウ-」の講演資料と記事リンク公開
  • ９割がお蔵入りする個人制作ゲーム、完成させる秘訣は―IGDA日本SIG-Indie研究会レポート
  • [IGDA日本 同人・インディーゲーム部会 第1回研究会
    「同人・インディーゲーム開発の現状と課題」をレポート|http://www.4gamer.net/games/000/G000000/20090508036/]
• やる夫ブログ
  • やる夫がVIPでエロゲ製作をするようです
• サカナ・ノベル…同人ゲーム製作講座
• すろ～ふ～ど
• スタジオぷ～か…オマケ
• ASTRO PORT…同人ゲーム制作の心理学
• 色々な墓場…同人ノベルゲームを作るために最低限必要なプロジェクト管理、もっと簡素に作りなさい
• 不機嫌亭ゲーム班ホームページ…「How to making 同人ノベルゲーム」「Why did we DeathMarch on 同人ノベルゲーム」「同人ゲーム求人マニュアル」（同人誌）
• とらふえ屋…同人屋さんのタスクとモチベの管理法（同人誌）
• 同人ゲーム制作の軋轢や問題点について
• ゲーム制作初心者がゼロから同人ゲームを作る際の制作上の課題などの議論まとめ
• Fly me to the sky!
  • ノベルゲームをつくろう！
• めがねの倉庫…０からはじめるノベルゲーム制作のススメ（Microsoft Word）

実は存在する「究極の手段」

面白い（魅力的な）ゲームなら、高いモチベーションが維持できるため、自ずと完成する可能性は上がる。しかもヒットする可能性も高いので一石二鳥である。この方法の最大の難点は、そもそも「面白い（魅力的な）ゲームにすること自体が難しい」ことだ。
そして、残念ながら、世の中でヒットした同人ゲームのほとんどは、恐らくこのケースに該当している（多分）。*58