この文書では、趣味の同人ノベルゲームを作るために、最低限必要なプロジェクト 管理の方法について述べる。
同人ノベルゲームの製作は、正に一つのプロジェクトだ。発案・企画・ 求人・製作・仕上げ・リリースなど、一つの作品を作り上げるために必要な作業は、 規模の大小こそあれ、実際に会社などのプロジェクトで求められるそれと なんら変わりがない。以降、この文書の中では同人ノベルゲーム製作 のことを単に「プロジェクト」と呼称する。
この文書を書くきっかけになったのは、我輩が関わったいくつかのプロジェクトが 空中分解したことだ。実際に社会でさまざまなプロジェクトに関わってきた 身としては、実に歯がゆい思いをしてそれを眺めていた。何故もっと 上手にハンドルできないのか。何故そこで感情論に走ってしまうのか。 何故メンバーは離れていってしまうのか。何故フェードアウトしてしまうのか。 そういった様々な注意点を、ここで纏めておこう、と思った。ここで述べた 知識は、必ずプロジェクトの運営に役立つ、と信じる。是非活用して頂きたい。
…と壮大に前フリしたけれど、実際ここで述べることが100%正しいなんてわけでは 毛頭無い。間違っていることもあるだろうし、もっといい方法があるかもしれない。 そのようなご意見があれば、是非 メールなりでお知らせして欲しい。 返信は確約できないけれど、 参考にさせて頂き、このページに反映していく所存である。
だが、待て。まずは深呼吸、そして落ち着こう。いきなりプロジェクトを立ち 上げても、一体なにをすればいいのかさっぱりだし、そもそもその気持ちが ずっと続くかどうかは危うい。少なくとも、一ヶ月は心に秘めたまま、誰にも何も 語らず悶々としよう。そして一ヵ月後、作りたい、というその気持ちに 幾許かの変化もないか、あるいはもっとその気持ちが強くなっているのであれば、 君は合格だ。プロジェクトを立ち上げる資格は十分にあると考えてよい。 逆に、一ヶ月経って、少しでも決意に陰りが見えるなら、 潔く風呂敷を畳もう。そんな意識では一本の作品を作り上げることは難しいし、 うっかり巻き込まれた人々はいい迷惑だ。プロジェクトは一人で進めるものでは ない。人を巻き込む以上、最後まで責任を持つために最も大事なのは、 ヤル気、というヤツだ。カッコよく言えばモチベーション。これを決して 失わないこと。
要点はこんなカンジ。
ちなみに、現実問題として、我輩が関わったものだけでも、 同人ノベルソフト制作プロジェクトの失敗率は、軽く６割を超える。 即ち、成功して同人ノベルゲームを世に送り出すことができる割合は、たったの 三割強しかない。プロジェクトが如何に困難であるかが想像できる。君が進もうと している道が、そういう茨道なのは自覚しておいてほしい。
コラム：お手伝いのススメもしも君が一度も同人ゲームを作ったことが無いのであれば、是非一度、どこかの サークルのお手伝いをさせてもらうことを強くお勧めする。というか、 こういう経験は必須だと思う。お手伝いさせてもらうことで、同人ゲーム 作りがどんなものであるかが判るし、どのような管理が必要で、参加者が どれだけわがままで、強力なリーダーが居ないと瓦解しがちであることも 実体験で理解できる。できれば、最後まで完遂するプロジェクトと、 途中で瓦解するプロジェクトを、それぞれ一度づつ以上体験して欲しい。 そして、その間の相違点を徹底的に学んで欲しい。それらの経験は、 間違いなく君のプロジェクトの強力な武器となる。以下のようなサイトで、色々なサークルが求人広告を出している。こういったところに 申し込んで、体験させて頂くのも一つの手だ。
ただし、体験させて頂くのであるからまずは無償でお手伝いすること、 自分が与えられた仕事を(どんなにつまんなくても)完遂する覚悟と決意があること、 先方が音信不通になったりプロジェクトが失敗・雲散霧消したりしても 笑って許せる度胸があること、そして当然、 自ら逃げ出さないことが最低限のハードルとなる。 |
通常、リーダーには企画・発案者(≒シナリオ担当)が収まることが多い。 当然対象ゲームに対する思い入れは人一倍強いはずだ。ある意味適任なのだ。
ただし、リーダーにはHRM(Human Resource Management...人材管理)能力も 必要だ。ついてこないメンバーを早々に切るのではなく、粘り強く説得したり、 目標についてアツく語ったり、締め切りを守らないメンバーを相手を傷つけぬよう 催促したり、時には叱責したり下手に出たり、そういう泥臭い作業を続けて、 なんとかプロジェクトを進めるのがリーダーの役目。君は本当にリーダーたりえるか、 もう一度よく考えてみよう。しかし、君がリーダーに向かないからといって、 他の人に任せるのが困難なのもこの役目の難しいところである。とはいえ、 世に言うリーダーシップ論では、 「リーダーの資質は学習で得ることができるもの」という考え方が主流らしい。 これを機会に、リーダーシップ論について学んでみるのも一興かもしれない。
もう少し具体的には、コミュニケーション。以下のような手段でメンバー間で 情報の周知徹底を図ることが必要である。
併用して問題ないが、我輩は 2.または 3.を主に活用することをお勧めする。 チャットやSkypeは相手が在席していなければ成立しない上に、 相手の作業を中断させてしまう可能性が高いし、 多対多通信では自分の意志を示すにも時間がかかってしまって勿体無い。 集中議論が必要な時は 1.を、緊急性が必要でない場合は 2.または 3.を使い、 結果を 4.に保存するなどして、 極力情報を共有するようにしよう。各担当者毎のトピックを作って、 そこで各員が一週間に一回必ず報告を入れる、という方法でもよい。 とにかく、全員が各員の情報を責任持って提出し、それを全員が相互に 確認できる状況を作れるように心がけよう。
そして、最も大事なのは「気軽に質問・回答できる雰囲気を作っておく」こと。 常日頃からバカ話を垂れ流して開襟しておくのも手だし、全ての質問や投稿には 必ず最善を尽くして応答する、などを心がけておくのも有効だ。とにかく、 質問や話題には必ず反応すること。高等テクニックとしては、ある人が 振った話題について、「○×さんはどう思いますか？」と名指しで回答を促す、 なんて手段もある。これで○×さんはなんとなく回答せざるをえない 雰囲気になる(これで回答がないと、 やや気まずくなってしまうので、それはそれで注意が必要だが)。
こういった相互方向のコミュニケーションがあるだけで、メンバーの モチベーション低下はかなり防げる。人間最もキツいのは「無反応」なのだ。
これがどこまで具体的に指示できるかが、思ったとおりに人に動いてもらえるか どうかの鍵となる。もちろん、担当者の裁量に任せてもよいのだが、それだと いつまでたっても完成してこなかったり、思った通りのものが上がってこなかったり する。具体的に指定していなければ、本当にそうなる。ウソだと思うなら 一度やってみるといい。「全部お任せします！」。それで思い通りのものが 上がってきたら、その人は異様に優秀だ。絶対手放すようなことはしないように。 そんなことは稀有の稀有稀有なのであるが。
そして、作業状況は逐一確認することを強くお勧めする。掲示板などで、担当者の 進捗を、絵なら画面サムネイルなりでも貼ってもらって、文なら出来たところ までをファイル共有してもらって確認する。こうすれば、 たとえヘンな方向に走り始めていても、早期に間違いを指摘できて、方向修正が 可能だ。完成した後になって「いやー実はソレ間違ってるんだよね」と告げることは、 言う方も言われる方も両方辛い上にやり直し作業(手戻りという)量も 膨大になってしまう。問題は早期に炙りだすこと、これもプロジェクトを 進める上でとても大事。
日程決めには、極力計算を使おう。例えば立ち絵なら、一枚描くのにどの程度の 時間が必要か？表情差分はどの程度かかるか？など。例を挙げると、 原画マンが立ち絵一枚に５時間、表情差分は一枚１時間で作成でき、 グラフィッカーが立ち絵一枚１０時間、表情差分は一枚一時間で塗れると すると、立ち絵２個、表情差分各１０個(計２０個)のキャラクタの完成までにかかる 時間は、以下のように計算できる(※ここでは作業の並列化は考慮していない)。
これができない人、あるいはやる必要が無いと思っている人には、リーダーは 勤まらない。そのプロジェクトは全員によほどアツい思いが無い限り 失敗するに相違ないので、関係者は早々に撤退することをお勧めする。
ちなみに、大まかな仕事の割り振りの例をExcelシートにまとめたものを こちらに用意した。 「メンバー仕事割振表」タブを参照。 『少なくともオマエの仕事の責任範囲はここだ！』と示すための材料に使ってほしい。
この段階では、プロジェクトに関わる人間は、まだ自分だけか、 あるいは非常に近しい少人数に限ること。 もちろん大人数でわいわい練ってもいいが、大人数だと舟が山に登ってしまったり、 舟が分解してしまう可能性が高まる。ある程度方向性が決まってからオープンに した方がいい。それに、周囲の人を巻き込むと、いざポシャった時の引き際の 処理も煩雑になる上、人間関係に深刻なダメージを残す可能性がある。
練りがカンペキに終ったら、やっと次へ。
具体的に書けば、我輩は殆どのプロジェクトで、目的と優先順位を以下のように定めている。
場合によってはこれに「売れること」などが追加されるだろうし、 優先順位もプロジェクトによって大きく変わるだろう。 それはプロジェクト毎に定義してもらいたい。 大事なのは、目的と優先順位を定義し、メンバーに徹底することだ。 そして、意思決定に迷った時はここに立ち返ることだ。 「こうした方がいいよ」「でもそうすると作業が桁違いに多くなっちゃうよぅ」 という時は、上の優先順位から、 『その作業が完成を遠のかせるものであれば不採用』と明確に判断できるようになる。 逆に、『その作業は完成までに完遂の見込みがある』のであれば採用すればよい。 もしも、上のリストの 1.と 2.が逆だったら、より良くなると思しい変更は、 完成までの日数を気にせずどんどん入れていけばいい。 そういう判断基準になりうるものを作っておくこと。
ちなみに、我輩が上のリストに「売れること」を追加していないのは、 そもそも我輩主催のプロジェクトは無償頒布を最終目標としているから。 小金儲けしたいなら商業でやればいいじゃん、というのが我輩の個人的な考え方だ。
原案の後に企画書を書くのは、原案を練る上で足かせになることがあるから。 原案の前に企画書を書くと、企画書に書いたことを実現しようとして、 しなくてもいい努力をしてしまったり、結局面白いものができなくなったりする。 これを避けるために、まずは「自由に」原案を練ることをお勧めする。 同人ならではの進め方だ(商業ベースでは、まず間違いなく企画書が最初に来る)。
企画書の例はこんな感じ。同人ならこの程度で十分(…と思う…んだけど…)。
|
以下のようなことを決めておこう。
この時点ではがっちり決めないこと。あまりがっちり決めてしまうと、シナリオを 書いている最中にそれが原因で実現できない(と思い込んでしまう)ことがある かもしれない。まだ自由に、柔らかくて構わない。
システム概要の例を、Excelシートにまとめたものが こちら。「システム要件定義」タブを参照。
最後のは作業を進める上であまり意味は無いが、作ったものがおおっぴらになる、 という事実は、メンバーのモチベーションを向上させる役割を大いに持つので、 用意した方がいい。
コラム：ファイル共有ストレージについてファイル共有ストレージは、メンバー間でデータを共有する際に非常に有効だ。 WindowsのExplorerから透過的に扱えるため、WebDAVが使えるものが 望ましい(ただし、 WindowsのWebDAVは時々コピー完了したつもりでファイルサイズを 0にしてしまうことがあるので注意。Microsoftを爆破したくなるほどの大バグだ)。個人的には、 kikyou.infoで提供しているファイル共有サービスがお勧め。こんな 素晴らしいサービスを提供してくれているW.Deeさんには足を向けて寝れない。 ちなみに、kikyou.infoでは 作成し終えた作品を公開するためのストレージも貸し出している。もうなんか 御礼100回でも足りないくらい。 ファイル共有ストレージのディレクトリ構成の例を以下に示す。 各サブディレクトリ以下は担当者に管理してもらって構わない。 ただ、バージョン管理が必要な場合は、ディレクトリ名に20090403などの 年月日をあらわす数値を付属して管理することをお勧めする。
|
なお、本書では、シナリオライターは既にメンバーに居るものとしている。 そもそも、書きたいことが既に明確にあるのに シナリオライターが居ないなんてことは、 実際の同人ノベルゲーム制作現場ではあまりない。 もし万一シナリオライターが居ないなら、まずシナリオライターだけを募集すべきだ。
まず、シナリオを最後まで書き上げよう。当たり前だが、これはこれで非常に大事だ。 そして、シナリオが最後まで書きあがらないうちに、プロジェクトを 進めてはならない。これを肝に銘じよう。シナリオが書きあがらないうちに 先に進めると、間違いなく竜頭蛇尾になる。シナリオライターが本職の人なら そんなことはないが、素人である以上、これは防げない。 プロジェクト中断時にメンバーへのダメージを最小限に食い止めるためでもある。 とにもかくにも、シナリオがカンペキに完成するまでは、 この先の工程に進んではならない。 可能なら体験版も作らない方がいいくらいだ。
ところで、シナリオの完成、とはどういうことか、皆様は考えたことは あるだろうか。こんなテキストファイルを最初から最後まで用意することで、 完成だと思ってはいないだろうか。
【瑤子】「おはよう、マコト」 【明人】「よう、元気してた？」 久しぶりに会うはずの二人の顔を見てると…げっぷが出そう。 なんで二学期一日目でこんなに元気なんだ…。 |
残念ながら、これは完成シナリオではない。 これではまだ半分も完成していない。 こんなテキストを持ってシナリオ完成と言い張るシナリオライターは、よっぽど 恵まれた人材に囲まれているか、モノスゴ無責任か、モノスゴ無知なのか、 あるいは長編ノベルゲームを作り上げたことがないかのどれかだろう。
では、完成形のシナリオテキストとはどのようなものかというと、 こういう形のものだ。
;;♪BGM 学校のテーマ ループ ;;□背景 学校校門 フェード=100ms 【瑤子 制服 困惑笑顔 汗 登場=画面右 立位置=右】 「おはよう、マコト」 【明人 制服 笑顔 登場=画面左 立位置=左】 「よう、元気してた？」 ;;♪SE 肩殴り x2 ;;★画面効果 白フラッシュ=50ms→背景=300ms x2 SEにシンクロ 久しぶりに会うはずの二人の顔を見てると…げっぷが出そう。 なんで二学期一日目でこんなに元気なんだ…。 ;;□背景 学校教室 フェード=500ms |
違いは一目瞭然。ゲーム画面をイメージしたコメントが入っているかどうか、 である。しかし、これはただのコメントではない。これだけだと判りづらいが、 予め決めておいた定型書式に従って書かれている。これは、 後でテキスト→スクリプト変換を容易にするための工夫だ。 即ち、シナリオ執筆とは、基本演出まで含んで、 定型書式で指定したテキストファイルを作成することなのだ。これが、 小説家などと、ノベルゲームシナリオライターとの決定的な違いである。
こうすることにより、以下の三つがメリットとなる。
どれも重要だが、特に 3.が最重要だ。これが出来ないと、全体の規模が 明確にならない。全体的なデータ量・数を可能な限り初期の段階で把握することは、 プロジェクトの成否を大きく左右する。今後の分業のための下準備にもなる。
それに、本来、シナリオが完成した時点で、用意すべきデータの数や 規模ははっきり(あるいは概要なりとも)把握できるはずだ。 後から必要になった時にその都度追加していくという手法では、 シナリオが大きいほど破綻の可能性が増し、 最後にはゴールが見えないデスマーチになってしまう。だから、初期の段階で、 どんなデータをいくつ用意すればいいかを、明確に定めておく必要がある。 「シナリオ作成」とは、そのための作業を兼ねている。
シナリオライターは常に完成画面をイメージしながらシナリオを書くべきだ。 逆に、それができないなら、残念ながらノベルゲームのシナリオライターとしては 失格ということになる。大きく印象的な演出は演出家に任せるとして、 シナリオライターは、標準的な演出(立ち位置や表情嵌め、背景指定、BGM指定、 SE指定など)を、可能な限り自分で書いておかねばならないことを、 絶対に忘れてはならない。 ここでサボると、プロジェクトはこの後容易に破綻する。 ここが踏ん張りどころである。 もちろん、シナリオライター一人に重責を負わせる必要はない。 他の人、たとえば演出屋が補助をしたり、 代わりにこのようなコメントを全部書き込む作業したりしても全く構わない (その場合は特殊演出についてもコメントが入れられるのでなお好ましい)。 最終的なアウトプットが、上記で示したような、 「完成形を意識し、定型で細かい指定があること」という部分さえ守れば、 どんな手段を講じてもO.K.である。
コメントを書く上で、シナリオライターはスクリプトに対する 知識を持っている必要はない。画面でどのようなことを実現したいかということと、 スクリプタがそれをどう実現するかは、全く別次元の話だ。シナリオライターは、 画面で実現したいことを、定型コメントに残せばよい。
以下に、我輩が使用している定型書式の例を示す。基本的には行頭が;;で始まる行が、 演出指定行だというのが大前提だ。 定型書式であれば、どんな書式を独自に決めても構わない。 後でスクリプタが見た時に、「…これ…定型じゃないっスよ」と 指摘されなければよい。
ただし、細かい書式については、 シナリオライターが責任を持って表を作ってスクリプタに渡すこと。 好き勝手に書き込まれた「定型と思い込まれたコメント」は、 混乱以外の何も招かない。例えば「学校校門」と「校門」が区別無く 併用されているとか、同じ曲を示すのに「公園のテーマ」と「公園の曲」が 両方使用されているとか。定型とはユニークである(唯一性がある)ことを お忘れなく。
| 指定項目 | 書式 | 説明 | 書式例 |
|---|---|---|---|
| 改行 | (改行) |
画面上での改行(キー入力待ち)を指定する。指定するというか、単純に シナリオ上も改行しておくだけ。 | 改行するよ。 (←スクリプトはここで改行) 改行したよ。 |
| 改ページ | (空行) |
画面上での改ページを指定する。空行で一行空けるだけ。 | 改行するよ。 改ページするよ。 (←スクリプトはここで改ページ) 改ページしたよ。 |
| キャラ表示 | 【キャラ名 立ち絵 表情 漫符 効果=xx...】 |
キャラクタを表示し、以降のセリフ一つをキャラクタが喋るものとする。 以前と同じ立ち絵・表情の場合は = と書いてもよい。不要な指定は省略してよい。 キャラクタを表示しない場合は、立ち絵以降を指定しない。 同時に、キャラクタに動作や変化などの効果を与える。ジャンプする、 お辞儀する、左側から登場するなど。 |
【瑤子 制服 通常】 【順司】 【ナカムラ = = 汗 登場=画面右 立位置=右】 【陽一 = 困惑 赤面 動作=小ジャンプ】 |
| 背景指定 | ;;□背景 背景名 効果... |
背景を表示する |
;;□背景 学校校庭 フェード=500ms ;;□背景 黒 フェード=1000ms 中央から広がるように |
| イベント画指定 | ;;□イベント イベント画名 効果... |
イベント画を表示する |
;;□イベント 瑤子１ 左からフェード=2000ms |
| BGM指定 | ;;♪BGM BGM名 効果... |
BGMを再生する。音量は 今回音量/最大音量 で指定する。通常ループ再生、 ループしない場合はその旨書いておく |
;;♪BGM 学校通常 フェード=2000ms 音量=50/100 ;;♪BGM なし フェード=1000ms |
| SE(効果音)指定 | ;;♪SE SE名 効果... | SEを鳴らす |
;;♪SE 殴打 音量=50/100 ;;♪SE 蝉時雨 ループ |
| 画面効果指定 | ;;★画面効果 効果名 コメント... |
画面効果背景を表示する |
;;★画面効果 縦に揺する=500ms ;;★画面効果 色相反転=0ms |
コラム：体験版についていろんなサークルが、完成前に体験版を世に送り出す。しかし、それがどんなに 魅力的であったとしても、実際に本編が完成したというウワサを聞くことは、 実はかなり稀だ。体験版を出した時点で満足してしまい、 あるいは本編の作業量を見積もり損なっていたことが発覚し、 そこでプロジェクトが頓挫してしまうからだ。我輩は、本編が完成しないうちから体験版を作るのはやめた方がよいと思う。 確かに、体験版を出すことで、メンバーのモチベーションが上がったり、 世間に周知することができ、本編への期待を煽る効果があることは認める。 しかし、本来、体験版とは、ユーザが本編を手に取るかどうかを判断するための ものであり、サークルの自己満足のためのものではない。 「本編が存在しない(結局出なかった)ゲームの体験版」なんて、ユーザは 生殺しもいいところだ。そんなものはプレイしたくもない。それに、 即売会で「間違って」体験版を入手してしまい、捨てるに捨てられず、かといって 保存するには何かが足りず、ということになると、ユーザを収納スペースでも 苦しめることにもなりかねない。 体験版は、本編が完成してから、あるいは少なくとも本編完成の道筋が立ってから 作るべきだ。本編完成が夢想もできない状態での体験版なら、 出さない方が百倍マシだと思う。たとえそれが「何でもあり」の同人であっても、だ。 |
# grep ";;□背景" シナリオ.txt | awk '{ print $2; }' | sort | uniq
学校下駄箱
学校教室
学校校門
学校体育倉庫内
学校廊下
自宅自室
自宅リビング
自宅玄関
(以下略)
|
同様にして、誰の立ち絵が何種類、どの立ち絵にどの表情が何種類、 BGMが何曲、SEが何種類必要かが、コマンド一発で抽出できる。前項で シナリオライターに頑張れ頑張れとハッパかけたのは、正にこれがその理由である。 シナリオライターが苦労してくれたおかげで、各担当者がどのようなデータを 何種類用意しないといけないかが、容易に理解できる。そのデータが実際に ゲーム中のどこで使われるのかも、シナリオを読めば容易にわかる。 データを抽出して表に纏めてしまえば、それがそのまま作業表になる。 全体作業量が明確になるので、計画も至極立てやすい。 この時点で、恐らくスケジュールの再考が必要になるが、 それも極めて論理的にできるだろう。
繰り返す。同人ノベルゲーム製作において、 シナリオライターは、後の作業を明瞭にし、プロジェクトの見通しを 格段に上げ、ゴールを引き寄せる義務を負っている。彼が頑張るか頑張らないか、 細かい仕事をするかしないかで、プロジェクトの成否は大きく左右される。 シナリオライターの責任は極めて重大である。
スタッフにはこんなものがあるだろう。一般的には一人一役だが、掛け持ちしても 構わないし、一役を複数人が担当しても構わない。しかし、齟齬を避けるために 可能な限りの少人数が望ましい。
また、せっかく応募して頂く人々には、最大の敬意を払おう。募集する時にはまだ
海のものとも山のものともわからん上にポシャるかもしれないプロジェクトに、
わざわざ参加の意思を表明してくれる奇特な親切な人なのだ。
決して失礼の無いように、最大限の礼儀を持って接すること。
募集には、可能な限りの情報を開示する必要がある。開示しておいた方が応募者の 不安も和らぐし、「ボクタチ一生懸命やってます」感もにじみ出る。このとき、 最初に作った企画書(登場人物どうこうは不要だけど)も付けて出すと良い。 これで、応募者がイメージを掴みやすくなる。また、作業内容と作業量を 明示することも忘れないこと。募集例は例えばこんなカンジ。
サークル ○× の △□ と申します。 此度、当サークルで作成中の「ＸＸＸＸ」について、製作を手伝って 頂けるメンバーを募集しています。募集メンバーは、スクリプタと 背景、音楽(BGM/SE)です。既にシナリオは完成しており、必要な データも全てリストアップ済みです。 今回の募集は、本作品に対するスポット募集です。 タイトル：「ＸＸＸＸ」 ジャンル：片田舎現代伝奇 対象年齢：全年例 作品規模：長編(シナリオテキストで約2.0MB、総プレイ時間20時間程度) WebURL： http://yyy.zzz.co.jp/xxxx/ 概要： 優しすぎる人々が、優しいが故にすれ違い、お互いを傷つけあう泣きゲー。 古き良き山村の日本の夏を、画面上でいかに美しく表現できるかに挑戦。 舞台： 昭和の終わり、1980年代の、広島県○×市△□町の盛夏をイメージとする。 △□町はまだ茅葺屋根が残る程の田舎町で、山と、谷間を流れる川に 開かれた狭い田んぼ、川に沿って南北に走る簡易舗装の県道があるだけの 人家まばらな山あいの街。竜神伝説が残っている。 かつて村を追い出された主人公が、８年ぶりにふらりと村に戻ってくる ところから物語は始まる。 完成予定：2008/12/25。2008冬コミを目標にしています。 募集人員： スクリプタ(1名) 吉里吉里/KAGのスクリプタを募集しています。既に完成している シナリオテキスト(2.0MB)を、スクリプトに変換して頂く他、 システム周りの画面作成もお願いします(各種システム画面の イメージは既に完成していますので、それを実現して頂きます)。 ・テキスト→スクリプト変換(主要項目は既にコメントで指定してあります) ・システム画面作成 - ゲーム画面 - セーブ・ロード画面 - サークルロゴ - タイトル画面 - おまけ画面 - エンディング・スタッフロール 報酬は相談させて下さい。 背景(若干名)： 背景画面を作成して頂きます。最終的な納品物は、1024x768ドットの フルカラーpng画像です。主に片田舎の20種類のユニーク背景と、全 背景の時間差分を２つづつ、計60枚を作成して頂きます。 絵調は、写実的、というよりも、水彩的であることが望ましいと 考えています。応募頂く時に、サンプルを数枚付けて頂ければ 助かります。 報酬は、一枚4000円以下で考えています。詳細は相談させて下さい。 音楽BGM(1名)： BGMを作成して頂きます。納品物は、ogg形式での音楽ファイルです。 ループする場合はループ用にkrkrlt.exeでデータを添付して頂きます。 作成曲数は12曲、大半は田舎をイメージしたのんびりとしたポップス またはジャズ曲をイメージしていますが、画面に合えばジャンルは 問いません。 応募頂く時に、サンプルを数曲お知らせ頂ければ幸いです。 報酬は、一曲2000円以下で考えています。詳細は相談させて下さい。 音楽SE(1名)： SEを作成、あるいはフリーの音源サイトから収集して頂きます。 音源サイトから収集する場合は、そのサイト管理者との使用許諾の 折衝もお願いします。SE数は157、足音・水音・打撃音・蝉の声など、 自然音がメインです。 納品物は、ogg形式での音楽ファイルです。ループする場合は ループ用にkrkrlt.exeでデータを添付して頂きます。 報酬は、自作の場合一音500円、他作の場合一音100円以下で考えています。 詳細は相談させて下さい。 募集方法：abc@cde.efg.comまでメールにてお知らせ下さい。 募集締切：2008/09/30までに応募頂いた方の中から、審査させて頂きます。 2008/10/07までに、応募頂いた方全員に当方から採用不採用を 連絡させて頂きます。 権利関係：メンバーが本ゲーム用に製作した素材は、サークル○×の著作物となり、 サークル○Ｘが本ゲーム用の素材として自由に使用できるものとします。 素材を製作したスタッフであっても、その素材を他へ流用する場合、 事前にサークル○×にご確認下さい。 以上、宜しくお願い致します。 |
可能なら、募集要項にはキャラ絵を添付したい。絵があるかないかで、 応募やマッチングの可能性はグィっと上がる。その意味では、 原画マンの募集は、シナリオライターの次に早期に実施すべきかもしれない。
応募頂いた場合、提出頂いたサンプルを慎重に吟味して、採否を決定する。 一度採用してしまうと、後から「ごめんやっぱりチェンジ」とはなかなか言えない。 ここでの人選は、慎重に慎重を期すること。また、メールを投げてみて、 その反応速度や応答内容の丁寧さなども、採否の材料にすべきだ。 どんなに素晴らしいアウトプットを出す人でも、突然音信不通になったり、 コミュニケーション能力が著しく低かったり、責任感のかけらも無いような 人であれば、よほど「たずな回し」に自信がなければ避けた方がよい。
「権利関係」の項目を追加した。ここ最近、「仕事を受けたけど辛くなって 途中で逃げ出す」人が増えたため。逃げ出された時に、権利関係をちゃんと定義 しておかないと、その人が作ってきた素材をそのまま使うことができなくなって しまう。ゲーム製作が後半に入っていれば、そのダメージは計り知れない。 先に手を打っておこう。
注意点は、外注する場合、「可能な限り細かく指定すること」だ。例えば イベント画であれば、以下のように指定する。
ファイル名：day01_瑤子_海辺にて.png 画面サイズ：1024x600 画像format：フルカラーpng形式 画面概要： 一日目、海辺の公園で、最初に瑤子に会うシーンです。 岩壁の上の手すりに手をかけて、海風に長髪をなびかせて 立っています。その様子を瑤子から見て左斜め下前方から やや見上げる形の構図です。腰から上がフレームに入っています。 周囲はほんのり夕日がかかってオレンジ色です。 差分： 表情差分 = 閉じ目微笑、開き目微笑、閉じ目歌を歌う ラフ： 別途共有ストレージの 画像/イベントCG/ラフ/day01_瑤子_海辺にて_ラフ.png で提供しています。 |
進捗確認は、遅れている人のケツを叩くのが目的ではない。 遅れているなら、なぜそれが遅れているのか、原因があるのか、 原因は取り除けるのか、対策はあるか、 そういったことについて当人やメンバーと話し合い、 対策を採るのが目的だ。以下のようなことを念頭に置いて担当者と会話すること。
ここで、悪いニュースでも率直に話せて議論できる雰囲気作りが奏功する。 遅れる、ということは悪いことではあるが、だからといって隠されてしまうと 全く把握できないまま、最後に大きなしわ寄せが来てしまう。絶対に進捗遅延の 隠蔽は避けなければならず、そのための土壌作りを、この時までに しっかりしておくのも、リーダーの役目だ。
万一進捗が遅れていたとしても、担当者を叱責してはならない。それは、 担当者を深く傷つけ、モチベーションを下げること以外には何の役にも立たない。 それよりも、 どうしたら現状を回復できるかを、一緒になって考えよう。人を増やす、というのも 選択肢として採りうるオプションであることを常に頭の片隅においておくこと。 目的をもう一度考えよう。君の目的は、「満足できるレベルの同人ノベルゲームを 完成させること」。締め切りに間に合わせる(そのことで品質を落とすかもしれない) ことではないはずだ。締め切りにシャカリキにならなくてよいのは、同人の 強みである(同時に弱みでもあるが閑話休題)。
しかし、どうしてもダメな人は居る。その人には毅然とした態度でクビを宣告しよう。
「あなたにはＸ月Ｙ日までに背景をＺ枚提出頂くことになっていましたが、 現在のところＮ枚しか提出頂いておらず、これは進捗からして80%以上の遅れと なっています。この状態では背景の進捗未達が原因で、全体スケジュールを 遅らせざるを得ません。あなたが一生懸命にやって頂いていることは理解して いますが、ここまでスケジュールを守って頂けないのであれば、残念ながら 他の方を探さざるをえません。ご理解下さい」
…のように、論理的かつやんわりと。誰も好き好んで遅らせているわけじゃ ないことは、リーダーとして理解しておこう。
このときリーダーが取りうる行動は、以下の四つ。
全てが正解。とりうる手段は全て採る、これがこの時のリーダーの模範的行動だ。 サークルの目的は、可能な限り時間通り、可能な限り高品質なゲームを、 自分たちの満足いく形で作り上げること。どこに優先順位をおいて、何が 削れるのか、何が削れないのかを計り、残された時間をいかに有効活用するかに 腐心できるのがよいリーダー。もちろん、削ったら、それによる時間的効果を ちゃんと計算しなおして、間に合うことを確認してからゴーサインを出そう。
まずは、大雑把でよいからデバッグ計画を立てよう。誰が、どの部分を担当するか、 シナリオの切れ目で分割して割り振るのが簡単だろう。シナリオの一日目は誰、 二日目は誰、のように。
デバッグの基本方針を、メンバーに周知することも忘れてはならない。 基本方針とはずばり、『少しでも「おかしい」「違和感がある」と感じた 部分は、須らく報告すること』。それを修正するかしないかは製作者側の判断であり、 デバッガが判断すべきではないためだ。
デバッグ報告表・修正表は例えばこのような形のものを用意する。 この表は、数サークルで実際に使われた。
| 報告者記入欄 | 修正者記入欄 | 発見日時 | 報告者名 | 場面名 | バグ・不具合内容 | 再現手順 | 再現率 | 添付資料 | あるべき姿・修正方針 | 修正日時 | 修正者名 | 修正状況 | 修正内容または修正拒否理由 | 影響ファイル |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 08/12/01 | さき | 二日目 | 例外発生、ゲーム停止 | 一日目選択肢Ｂで「明日」を選択 | 100% | スタックトレースを別途添付 | 例外が出ないこと | 08/12/10 | KAIC | 修正済 | 左方針に従い修正 | day_01.ks |
| 08/12/02 | mikey | CGモード | 誠CG1とCG2の表示位置が逆 | - | 100% | - | 誠CG1とCG2の表示位置交換 | 08/12/02 | KAIC | 修正済 | 左方針に従い修正 | cgmode.ks |
| : | : | : | : | : | : | : | : | : | : | : | : | : |
スケジュール計算前に、この表を提示して、各担当者に確認してもらおう。 「これならできる」「もっと短くできる」「これだと無理だ、xx時間にして」 などなど、色々意見が出るだろうから、それにあわせて適宜修正すればよい。 大事なのは、各担当者が自分の単位時間あたりの仕事量を知り、 それにあわせて作業するようになる、という効果部分だ。
| 作業項目 | 所要時間 |
|---|---|
| 一人が同人ソフトのために確保できる一日の作業時間 | 5h/日 |
| シナリオテキストのスクリプト化 | 5KB/h。1MBなら200時間 |
| 立ち絵(表情無し)の原画作成 | 5h/枚 |
| 立ち絵の表情差分の原画作成 | 1h/枚 |
| 立ち絵(表情無し)の塗り | 7h/枚 |
| 立ち絵の表情差分の塗り | 1h/枚 |
| 背景(時間差分なし) | 15h/枚 |
| 背景の時間差分 | 3h/枚 |
| イベントCGの原画作成(差分なし) | 8h/枚 |
| イベントCGの原画作成(差分) | 1h/枚 |
| イベントCGの塗り(差分なし) | 10h/枚 |
| イベントCGの塗り(差分) | 1h/枚 |
| BGM作成 | 10h/曲 |
| SE作成 | 0.5h/SE |
よくIT業界では「人日(にんにち)」という単位を使う。人が一日にこなす 作業量のことだ。例えば、上の例では、背景は3人日/枚、立ち絵塗りは 1.4人日/枚、と計算できる。作業の人日計算をして、それを担当者人数で 割れば、その作業に必要な日数が割り出せる。便利なので、プロジェクト管理の 折には使ってみるとよい。 ただ、この方法には人間味や突出した人間の存在を否定している気がして、 我輩は正直あまり好きではない。代替法が無いのも事実だが。
なお、実際のスケジュール時には、各作業がオーバーラップできることを 念頭に置くこと。例えば、(担当者が別なら)、Ｂ画像の原画作成と 既に原画終了したＡ画像の塗りは同時進行可能だ。こういうことも考慮して スケジュールを立てる。ガントチャートと聞いてピンと来るようになれば 一人前かも。
| 作業項目 | 相場？ |
|---|---|
| システムデザイン | 外注したことないので不明 |
| システム作成(スクリプト) | 全体で3万円程度 |
| 原画：立ち絵、表情なし | 2000円/枚 |
| 原画：表情差分 | 500円/枚(計算でむりやり算出) |
| 原画：イベント画 | 2500円/枚 |
| 塗り：キャラ立ち絵、表情差分なし | 2000円/枚 |
| 塗り：キャラ表情差分 | 500円/枚 |
| 塗り：イベント画 | 2500円/枚 |
| 背景 | 4000円/枚 |
| BGM作成 | 2000円/曲 |
| SE作成(加工代含む) | 新規：500円/SE 流用：100円/SE |
| ボイス録音 | 80円/フレーズ |
立ち絵５種類、表情差分それぞれ８種類、背景10種類、BGM8曲、SE20個、 イベント画10枚を必要とするゲームの場合、全部有償で外注すると、
程度かかることになる。まぁまぁ、そんなもんかな、という気がする。 いずれにしても、後でモメないように、お金の話は最初にきっちりと決めておく ことをお勧めする。
この表中に「シナリオ作成」が無いのは、今まで我輩が関わったゲームでは 既にシナリオは完成していて、外注の例を知らないから。 また、キャラデザインは原画と同じ人がやることが殆どなので、 それ単体では報酬が無いことが殆どのようだ。 最も冷遇されているのがスクリプタで、作業量に関わらず、報酬が かっきり決まっていることが多い。まぁ…普通は作業量なんて読めんからなぁ、 とは思うが、もう少し評価して欲しい気もしないでもない。あ、我輩は ポリシー的な問題で、無償で引き受けてますけどな。
お金の話といえば、作成にかかる費用と売り上げ・利益の分配についても 考慮しておくべきだろう。たとえば、以下のようなことは、プロジェクト開始前に 決めておいて、メンバーに周知徹底しておくこと。
このあたりでモメると、人間関係がかなり容易に壊れてしまうので注意。
1.は、よくある。とてもよくある。なので、募集の時に、必ず「製作物の著作は このサークルに属しており云々」を書いておくことをお勧めする。逃げられた時に 影響が大きいのは、ヒューマンリソースの問題ではなくて、それまでに作ってきた モノが使えるかどうかわかんなくなることなのだ。
2.は十分ありうるし、指摘されたら逃げようが無いお話で、明確に著作権を 犯していることは間違いない。ので、我輩は、創作以外ではゲーム作りに 関わらないようにしている。それが最も簡単確実な回避方法だと思う。 もちろん、どうしても二次創作に邁進したいなら、事前に許諾を取ればよい。 一次創作者によっては、二次創作に寛容なところもある(特に最近は多い)し、 ガイドラインを出しているところもある。 聞いてみる価値は十分にあると思う。その上で断られたら考えればいいしね。
もうひとつ、フリーの背景や効果音などを使う場合も、その背景の使用許諾をちゃんと 守ること。連絡が必要な場合があったり、 加工してはダメな場合があったりもするので、一つ一つ入念にチェックしよう。 後で無断使用が発覚して指摘されると、どちらも辛い思いをする。
3.は、かなりやっかいだ。めったにあることではないが、例えば、作成した 同人ゲームが大ヒットしてバカ売れした時など、メンバーや他人がその二次創作を 作成して、あろうことか商業ベースに乗せてしまう、なんてこともありうる。 それでもいいよ、という剛毅な方であれば問題ないが、そうでない場合は 対策を練らねばならない。また、大ヒットを見て、当時の外注さんが権利を主張 しだすこともある。こうなると泥沼だ。
だから、最初の最初に、著作物が誰に属するか、くらいを一言書いておくことを お勧めする。いや本当に。1.の延長ね。
コラム：習作のススメもしも、一度も同人ノベルゲームを作ったことがなければ、自分のプロジェクトを 発足する前に、どんな形でも、たとえ５分で終るものでも構わないので、 短編を一作作り上げてみて欲しい。その時は、その時用の小プロジェクトで 構わないし、自分一人で作り上げてしまってもいい。一作作ることによって、 何を用意すればよいのかが把握できる。加えて、「一作作り上げた」という 自信にもなる。だからこそ、一作でいい、習作を一つ完成させてみよう。 もしも習作すら完成できないようなら、それはそれで答えになる。 「君には同人ノベルゲームを作り上げる能力はない」、という。 悲しいけれども、それが現実だ。現実を早期に、少なくとも誰かを巻き込む前に 把握することは、とても重要なことなのだ。 |
こんな方法じゃ作ってて楽しくないんじゃないか？と思うかもしれない。 そう、楽しくはない。楽しく作ることが目的(=完成しなくてもいいや)なら、 こんな手法に従う必要はまるでない。是非楽しく作り続けてほしい。 しかし、「完成させたい」なら、楽しくない作業も必要になる。 それはどんなモノにでも言えることだ。ここで述べた方法は、 楽しくはないけれど、完成への指標ではある、ということは理解してほしい。
ここまで書いてきたことを纏めると、以下の三つに集約される。
これだけ。これだけが守れれば、プロジェクトの成功確率は飛躍的に向上する。
我輩は、関わったプロジェクトが空中分解したり、フェードアウトしたり、 激しく瓦解していくのを、何度も何度も目の当たりにしてきた。それは、
のような理由による。本書で述べたことを守れば、これら三つについては 対処できる…はずだ…と信じたい…気がする…といいなぁ。
是非皆様には、皆様の自信のプロジェクトを完遂し、素晴らしい同人ノベルゲームを 世に送り出して欲しいと、切に願っている。その暁には、我輩は一ユーザとして それを心行くまで楽しみたい、と思う。
コラム：リリースの前にやるべきこと最後の最後、忘れがちだが、これだけはやっておこう。
世界にウィルスをばら撒いたりすれば、どんなにそのゲームが素晴らしい ものだったとしても、未来永劫不名誉に語り継がれてしまう。 サークルとしては解散せざるをえないし、次回作を出すなんてもってのほか。 こんなつまんないことでいろんなものを棒に振りたくはないだろう。 必ず、複数種類のウィルスチェックソフトで、ウィルスチェックを実施すること。 これが終らない限り、絶対にリリースしてはならない。 |
コラム：どのくらい命をかけるか？プロジェクトを完遂するために、ホンキになって取り組むのはすばらしいことだ。 しかし、軽々しく人生を賭けてはいけない。このプロジェクトが成功すれば…と いう前提は、失敗すると全てを失うという可能性を秘めている。「このゲームを完成させるため、大学を中退しました！」 「このゲー(中略)会社を退職しました！」。その意気は 本当に素晴らしいと思う。その決断力、行動力には見習うべきところも多い。 しかし、その行動が、 本当に君の人生にとって良いのか？というのは、常に考えて欲しい。 大学中退だと、大卒という条件がクリアできず、仕事はおろか、アルバイトの 選択肢も減ってしまう。もちろん、仕事やアルバイトは日銭を稼ぐ術だと 割り切って頂いて結構だが、その日銭を稼ぐことすら満足にできなくなる可能性を 秘めているのだ。その理解や覚悟が、君にあるだろうか。 一か八かは本当に必要なときに賭ければいい。 どんなに素晴らしい内容だったとしても、 同人ノベルゲームを作るためだけに人生を賭けるべきではない。 別の観点から言う。他に主たる業を持った上でも、同人ゲームは製作できる。 釘を刺すと、「本職があるとゲーム製作に十分時間が取れない」というのは 詭弁でしかない。世の多くの同人ゲームの製作者は本職を別途持った上で 製作しているし、我輩自身も(コンピュータ関係ではあるものの)全くゲームとは 関わらない本職を持っている。しかも、月残業時間が160時間という状態で 同人ゲームのお手伝いをしていた。さすがに残業時間200時間を超えると 無理だとは思うが、そこまで酷くなければ、覚悟さえあれば、 ゲーム製作の時間は取れる、ということだ。そして極めつけは 「かけた時間と製作物の素晴らしさは比例しない」という創作分野の常識。 とまぁここまで聞いた上で、それでも俺は人生を賭けて背水の陣で臨む、 という人には、素直にエールを送りたい。ただし、「失敗しても誰も恨まないこと」 という条件付きで。君のプロジェクトが失敗したのは、あるいは作った ゲームが世間に受け入れられなかったとしたら、それは世界が悪いからではない。 君の能力が足りなかったからだ、そのゲームが魅力的でなかったからだ。 捻くれて世間に背を向けることのないよう、是非前向きに次回作に 取り組んで頂きたい。 |
コラム：ゲームはウォーターフォールモデルで作れるか？結論から言えば、ノベルゲームはウォーターフォールモデルで作ることができる。 なぜか。以下の理由による。
二番目。「ゲーム作りはクリエイティブな活動だから云々」というのは、 特にノベルゲームに対しては当てはまらない。発想以外の、制作に必要な 素材の部分までクリエイティブなノベルゲームは、知る限り見たことがない。 これは即ち、制作のほとんどはクリエイティブではないということだ。 しかし、それは決して悪いことではない。「本」の形態がほぼ一つであるのと同様、 ノベルゲームも形態がさまざまである必要はない。中身で勝負すればいいのだ。 …誰か「クリエイティブなノベルゲーム」を見せてくれんだろうか。 さすればクリエイティブがどんなものか知ることができるのであるが。いや本気で。 三番目、これは二番目とも絡むが、つまりはそういうことだ。シナリオを 上げた時点で、どう描画すればいいか分からないもの、があるか。もちろん 指定にもよるが、その時点では大体こうすればいいということがわかっているはずだ。 シナリオ書いたけど画面上でどのように表現(※実現ではない)するかは知らんし、 というのは、ノベルゲームのシナリオライター失格級の言葉。 技術的にどう実現するかは知らなくてよいが、実際画面上でどう表現されるかは 説明できないとダメだ。説明できない人に限って「とにかくすごい演出を！」とか、 理解も実現も不能なことを平気でのたまう。 ウォーターフォールモデルは嫌われ者だ。やってて楽しくない、というのがきっと 根底にあるんだと思う。そして、世の中にはいろんな開発手法があって、 どれが適しているかは諸説紛々。もちろん、どのモデルを使っても構わない。 好きなのを用いればいい。 だが、少なくとも、実際に一般に用いられ、成果を上げている最も普遍的な 開発モデルは、と言われたら、現在ではウォーターフォールモデル一択なのだ。 「一番失敗しないため(※成功するため、ではない)の方法は？」と問われたら、 コレを挙げるしかないのが現状なのである。反骨心あふれる皆様には、 何か別の、もっとスバらしい開発モデルを確立して是非教えて頂きたい。 そしたら、某社でウォーターフォールモデル以外を提唱した我輩を散々バカにした ヤツラを説教しちゃう材料にする所存ナリ。 |