同人ゲームグループ、
メンバー運営のトラブル






募集のトラブルはここちら

苦労してメンバーを集めてもトラブルになるケースはあります。
てなことで、例を書いてみます。

アリストテレスの「人間は社会的動物である」をしみじみ実感します。

以下の文を読んで「ここまでしないといけないのか」と思った人がいたようです。でもプロのような経験・知識・機材のないアマチュアが集まってゲームを作ります。プロ並みの金を払うでなくプロの責任感を持たせるのは無理。一緒に集まって作業をするわけではないので進捗管理も難しい。熱心な人もいれば、趣味でやっているのでおそろしく自分に甘い人までいます。その温度差をどう乗り越えるか。おまけにメンバーのハンドル名とアドレスしか知らず、本名・住所・電話番号も不明。簡単に音信不通になります。ここまでしないといけないのです。

〈追記〉
いろいろ書いて文が長くなりました。要約は無理ですが、報連相とモチベーションの維持の二種類について書いています。
  1. グループの連絡方法がメール。
  2. 仕様書がいい加減。
  3. 制作中にゲームの内容が大きく変わる。
  4. 発表予定日が延期につぐ延期。
  5. メンバーに金を払うのに金額、支払方法があいまい。
  6. 方針はリーダーの胸のうちにあり、都合でコロコロ変わる。
  7. ゲームの仕様がコロコロ変わる。
  8. リーダーが身勝手または優柔不断。
  9. メンバーに大量の仕事をさせようとする。
  10. 権利・義務があいまい。
  11. メンバーの担当があいまい。
  12. 担当が明確でもメンバーが甘え、誰かがやってくれるだろうと思いたがる。
  13. リーダーが甘える。
  14. リーダー、メンバーが実績もないのにプロレベルのことができると臭わせる。
  15. リーダー、メンバーが過去にプロだったことを臭わせる。
  16. リーダー、メンバーが説得力のない言い訳をよくする。
  17. リーダー、メンバーがテストプレーヤーを仲間扱いしない。
  18. メンバー間のトラブルがあってもリーダーが仲裁に入らない。
  19. 参加したばかりのメンバーに仕事を任せっきり。
  20. テストプレーヤーが報告を全くよこさない。よこしても批判屋。
  21. 著作権の取り決めがない。
  22. リーダーが音信不通。



グループの連絡方法がメール

メールでやりとりすると、各メンバーとリーダーとの縦の関係ばかりで、メンバー間の横のつながりが弱くなるんです。他のメンバーが今どんなことをしているのか、グループ全体の進捗はどうなっているのか知っているのはリーダーだけ。結果、メンバー同士の連絡もリーダーを通した伝言ゲームになります。そして作り直しでメンバーのモチベーションを下げることになります。
またリーダーも一部のメンバーと大切なことを決めてしまい、他のメンバーから「そんな話は聞いていない」とトラブルになることも。またそのトラブルも当事者以外のメンバーが後から知り何も手を打てず驚くだけになることも。
連絡はBBSやメーリングリストのほうがいいです。

ただBBSやメーリングリストのデメリットをあげると、メンバーが「選挙では○○党に入れてくれ」との政治活動や布教活動をする恐れも。注意しても「信仰の自由は憲法で認められてる」と怒り狂うケースもあります(無制限の宣伝、布教の自由は憲法で認められていない)。逆にリーダーが嫌いな政党や教団の悪口をいい、メンバーに支持者がいたためもめることも。政治と宗教の話はグループ内で禁止にするのが安全です。
もっとありそうなのが、他の人のやり取りに文句ばかりつけて代案をださない人が引っ掻き回すケース。自分とグループの実力を無視して商品レベルの物を作りたがるケース。楽しい夢を見ていたいだけなので、作りたがる割に努力するつもりもないし、面倒を他の人に押し付けることすらあります。規則で「文句があるなら代案、具体的な計画を出せ」としたほうがいいです。
結局メンバーをどうまとめていくかが、リーダーの腕の見せ所です。

仕様書がいい加減。

エフェクトはFFやPSOみたいになんてあいまいなのは論外。「デザインは現代的な配慮を」とどうとでも解釈できるのも論外(実際にあった)。募集時に「リテイクに応じてくれる方」という条件で仲間を集めても、あいまいな指示なのに作った物にたいし「イメージと違う」といえばトラブルになります。
具体的な指示を出し、はじめのうちはすぐに作らせずプロトタイプを作らせて、リーダーが状態を確認するほうがいいです。

似たケースで、メインプログラマの指示があいまいで、サブプログラマーが意図と違う物を作ったことも。
メインプログラマの側で関数名、関数の機能、関数に渡すパラメータの内容をすべて指定したほうがトラブルは防げ、作業効率はよくなります。

制作中にゲームの内容が大きく変わる。

例えばシミュレーションゲームからサウンドノベルに変更など、作ろうとした物が手に余るとゲームの内容が大きく変わります。もともとまともな計画性と統率力がないのでサウンドノベルに変更しても完成せず、グループ活動は終わることでしょう。

発表予定日が延期につぐ延期。

計画がいい加減なときや、リーダーが願望優先で発表予定日を決めたときにおきます。
制作期間が一年を超えると、受験・就職活動・入院などでメンバーが抜けたり、抜けなくとも制作速度は大きく落ちます。延期につぐ延期ではメンバーの士気は落ちますし、どのくらい作業が残り今どこまで進んでいるのかわからないと達成感がありません。
メンバーがただで協力してくれる場合でも払うべき報酬があります。それはメンバーの仕事ぶりへの評価と個人ではできなかった共同作業による達成感です。その二つが与えられなければ、グループは終わります。

はじめにまともな仕様書、シナリオを書き絵・効果音・曲の数とプログラムの工程数を洗い出し、ある程度作業に入り進行速度をつかめば、小学校の算数で発表予定日は計算できます。

メンバーに金を払うのに金額、支払方法があいまい。

テストプレイヤーがいるのに「売れた金額を頭割り・・・」とすると、クリエイターから「責任が低いのにテストプレイヤーも同じ金額か」と不満が出て、差をつけるとテストプレイヤーから「同じ仲間として頑張っているのに差別かよ」とトラブルになる可能性があります。
また、絵描きやプログラマが複数いると、腕のある人ない人の差が出てくるので、「あいつと同じ金額か」と不満も。

成果物の買い取りにして、はじめに絵1枚いくら、1曲いくらと額を決め、金額に納得したうえでメンバーに参加してもらえばすっきりします。

売れた金額を頭割りにするなら、テストプレイヤーをグループにはじめから入れず、1職種1人としてグループを少数にしたほうがいいです。

また金を払うどころか後から「CDのプレス代を何万円も負担しろ」といえば確実にもめます。ダウンロード販売やCDに印刷できるプリンターを買い自分で印刷するほうが無難です。

支払日、支払方法も事前に明確にしないともめます。過去、払うといいながら「サーバーの調子が悪くメールのやりとりができなかった」と誤魔化しクリエイターが催促のメールを出しても黙殺する詐欺を働いた人がいます。(この詐欺を働いた人間は確信犯で、複数のクリエイターに同じことをしていたことがわかりネットで話題になったことがあります)

あいまいにして、この手の詐欺に思われるのも馬鹿馬鹿しいです。

方針はリーダーの胸のうちにあり、都合でコロコロ変わる。

リーダーが優柔不断か無計画のときにおきます。そうでなくても方針がないとケースによって対応が微妙に変わり、メンバーが「このあいだと対応が違う」とトラブルになることも。
できれば簡単な規則を作ったほうがいいです。もちろん作って実行しなければ無意味です。

ゲームの仕様がコロコロ変わる。

プログラマーは仕様変更はすきじゃないです。機能追加、仕様変更によっては大きなコードの書き換えが必要になります。それがバグの原因にもなります。またコードがごちゃごちゃします。遊ぶ人は面白ければコードがごちゃごちゃしていようがかまいません。ところがプログラマーは簡潔なコードをすきな人種です。
プログラムをわからないリーダーが簡単に「お願いします」と丸投げしたらもめます。まずはできるかどうか相談しましょう。

リーダーが身勝手または優柔不断。

趣味としてはじめたことなので口出しされたくないリーダー、自分が中心にならないと気がすまないリーダーなら身勝手だとわかりますよね。
でも、優柔不断な人も面と向かって意見をいえないため以下のようなトラブルをおこします。


嫌な提案は「みんなの意見を聞いてから」と誤魔化すくせに大切なことは勝手に決める。


これで都合が悪くなると「他の人はみんな賛成だ」「あなたの考えは私達とはちがう」と自分の意見をみんなの意見にしてしまう。


一度引っ込めた意見や要望をどさくさまぎれに押しとおそうとする、


要望・質問には「考え中」といいつつほったらかし。「考え中」とは「何も考えない」ということらしい。


波風を起こすまいと苦し紛れの約束をしてしまう。でも煩わしいので解決したような錯覚をおぼえ、約束を守らずに放り投る。結果、起こさなくてもいい波風を起こす。


自分が傷つかないことに必死で、同じトラブルを繰り返す。引っ掻き回している自覚がないので、リーダーはまわりの人間を身勝手と思うだけ。

優柔不断と身勝手は紙一重なケースってかなりあります。

はい、わたしも自戒はしています。

メンバーに大量の仕事をさせようとする。

制作中のアドベンチャーゲームの英語版を出そうとしたリーダーが翻訳者を見つけたケース。ところがその翻訳者、文庫本1冊分の量だと知ると途中からではなく初めから投げてしまい、リーダーが進捗確認のメールを何度出しても黙殺。そのくせ翻訳とは関係のないHTMLのことで訊ねたときはレスをよこしました。この翻訳者もやっていることは幼稚ですが、もともとリーダーの要望が無理なのです。

ほかにも、CG担当2人に2年近くも時間をかけ大小3百枚超のCGを描かせたケース。それもフリーソフトだから無報酬で。
2人ともセミプロで腕と責任感があるからできたものの疲れ果て、初めは「次のゲームでも協力していい」といっていたのが、しまいには「これっきりにしてくれ」となりま
した。このリーダー、金のタマゴを生むメンドリを殺すタイプですね。

権利・義務があいまい。

まずない話ですが商品化を目論むとき、リーダーが各メンバーや自身の権利をあいまいにすると、契約を交わす販売会社など外部ほうしか見なくなり、「大切なことを勝手に決めるな」とトラブルになります。リーダーの一存でどこまで決めていいか、メンバーが途中で抜けるなら著作権と出した金はどうするかはっきり決めないと、こじれたときに泥沼化します。

商品化ではプロの厳しさが伴い、納期・品質・ユーザーへの配慮のハードルが高くなります。今まで趣味として作ってきたため、リーダーですら好きなことだけしようとし面倒を押しつけるケースがあります。
アマとプロでは状況が大きく変わります。リーダーとメンバーが状況の変化に合わせて自分を変えることが成功へのポイント。「面倒なことは自分が進んでやるので協力してくれ」といわなければ、皆ついてきません。リーダーはプロのプロジェクトリーダーにならないと、おかしくなります。

メンバーの担当があいまい。

プログラマー、原画家が複数いるとき、担当を明確にしないと、みんな「他の人がやっているだろう」と思い込みます。トラブルになってもリーダーの責任です。

担当が明確でもメンバーが甘え、誰かがやってくれるだろうと思いたがる。

実績もないのに3Dゲームを作りたいと自分からいいだしてきたサブプログラマが途中から間に合うととも、間に合わないとも連絡がなし。メインプログラマが進捗確認のメールを出すと、「お役ごめんじゃなかったんですか?」(「お払い箱」と書かないところがポイント)とのレス。その後も頓珍漢なことを繰り返し音信不通。

相手は学校や仕事の合間に好意で協力してくれる経験、技術、開発機器の乏しいアマチュアで、こちらもプロ並の金を払うわけでもないので、少々作業が遅れても文句はいえないのです。でもうんと遅らせて何の報告もしない人は周りに不満や悪影響を与えかねないので、そのときは嫌われ役になろうが注意しなければなりません。

週に1度は各メンバーが進捗報告をおこなえば、もっとましになります。これでも逃げる人は逃げますが、早いうちに危険信号がわかるので手を打ちやすいです。

またリーダーは士気を保つため毎日全メンバーに連絡。孤独な作業にさせないようメンバーはメーリングリストやBBSで毎週そして必要に応じていつでも報告。「ほかの人はここまで進んでいるのか」と刺激を与えます。そして毎月オフ会。こうして共同作業の楽しさと責任を感覚的に理解させるのが理想です。

ただオフ会に未成年のメンバーを呼ぶなら保護者の許可がいります。ですがその保護者からすれば、あなたは子供がネットで知り合っただけの得体の知れない人間なので警戒されるでしょう。万一許可があっても未成年のメンバーが行き帰りに交通事故を起こし保護者の同伴がなければ、あなたの責任問題になります。
未成年はオフ会に呼ばないのが安全です。

リーダーが甘える。

協力は今のゲームだけで、次回作には協力しないとメンバーが予め伝えてあるのに、メンバーが次回作にも参加する前提でリーダーが話を進める。グループに参加希望する人が参加にあたっての質問しても、答えず勝手に参加した前提で資料を送りつける。

これでもめてもリーダーは「自分だけすべての責任を取りたくないという人とはつきあえません」と高みにたったいいかたをしがちです。それまでメンバーの権利にはふれなかったのに責任だけ口にすれば、他のメンバーにも不信感を与えます。
「責任」という言葉を使いたければ、メンバーの参加にあたり権利・義務の内容を明文化してください。それでももめるときはもめますが。

リーダー、メンバーが実績もないのにプロレベルのことができると臭わせる。

リーダーが理想に酔って行動するので、計画遂行について尋ねられても「なんとかなるんじゃないですか」でおしまい。こうなるとグループは終わり。なるにはなりますが、悪い結果になるだけ。楽天家のふりをした現実逃避をポリアンナ症候群といいます。

妄想をいだくのがメンバーの場合でも高い確率で担当の仕事に失敗したり、遅れに遅れることになります。楽しい夢をみていたいので何度も同じ失敗をしますし、シナリオやゲームデザインなど中心的な仕事を担当したがります。中心的な仕事を任せると、周りをけなすことで自分の優秀さを示そうとしたり、失敗しても周りのせいにしたり、トラブル必至です。

リーダー、メンバーが過去にプロだったことを臭わせる。

以前、プロとして音楽関係の仕事をしたという人に1曲作ってもらいました。「あと1週間でできる」とメールを出しながら、3週間過ぎても連絡なし。そろそろ曲が必要になり「何%できてますか」と尋ねると「%で答えるのは難しいですね」とのこと。元プロになるのはそれだけの理由があるのです。

もちろん、元プロすべてが問題ありではありません。ゲームプログラマは高い技術が求められる割に、会社の売上は1作、1作の売上に左右されるため給料が安く、業務系ソフトに転職するケースがかなりありますから。でも腕のある元プロがそこらの同人ソフト制作に参加してくれるわけがありません。

リーダー、メンバーが説得力のない言い訳をよくする。

趣味としてはじめたことなので口出しされたくない、好きなことだけやりたい場合あきれる言い訳や逆ギレをすることがあります。メンバーがするならグループから辞めさせればいいだけ。でもリーダーがやればグループは終わります。

シナリオ担当には容量の都合や、プロとは違い合間の時間に作るアマの原画家、プログラマへの負担がかからないよう、いいシナリオを書いても削ってもらうことがあると予め説明しておいたほうがいいでしょう。

リーダー、メンバーがテストプレーヤーを仲間扱いしない。

差別のつもりがなくてもリーダー、メンバーが「みんな」といいつつ、そのなかにテストプレーヤーを含めていないことがあるんです。これをやったらテストプレーヤーにみじめな思いをさせます。

メンバー間のトラブルがあってもリーダーが仲裁に入らない。

「ゲームつくりたい人、この指とまれ」感覚で、リーダーとしてどのように振舞うべきか考えてなかった人が、メンバー間のトラブルがおきてもオロオロするだけでなんの手もうたない、うてないってことがあります。
友達づきあいのときは上手くいっていたのに、共同作業はまるで駄目な人もいますし、リーダーが上手く統率していかなくてはならないのです。リーダーのなかには完全な友達感覚でふるまい進捗管理すらしないで失敗するケースもあります。それで反省するどころか、「努力すればできないことはない。だから努力しているのに上手く行かないのは、周りが無能かサボっているからだ」と思うだけ。努力の方向が間違ってないか、自分の力が足りないか検証をしません。

そうでなくともテストプレーヤーが半可通やケチ付けばかりでプログラマとこじれる、面倒くさくなったクリエーターが作業を怠けるといったトラブルなんてよくありますから、リーダーがまとめていかなくてはなりません。

グループをまとめるには政治が必要です。「政治」というと悪いイメージがありますが目的のため人が集まれば良くも悪くも政治が発生します。政治が煩わしいからといってリーダーがグループの連携をとらなければ無為無策の政治家になります。政治から逃げられないならリーダーは善政を布くしかありません。

「決断力のない君主は多くの場合中立の道を選ぶ」(マキアヴェリ『君主論』)

参加したばかりのメンバーに仕事を任せっきり。

責任感があるか不明の人にネットでのやり取りだけで任せるのは結構危険です。

某グループの話で、ホームページのメンバー募集を見て入ってきた2人がすぐ音信不通になったとのこと。2年後、よその同人グループのホームページに消えた1人の名前と「○○○○さん連絡くれ」との逃げたらしい書きこみが。そのグループの代表に、逃げた人の本名を持ち出し同一人物か確認したら果たして同一人物。なんでも、引越するといったまま連絡が取れなくなったそうです。

念のため書くと、このグループのメンバーの扱いが無茶なわけではありません。同人ゲームグループと縁のない人には異様かもしれませんが、メンバーの音信不通はほとんどのグループで起きてることです

初めて入ってきた人には、本人にいつまでに完成できるか見積もりを出させ、予定日までにできなければその旨連絡くれといっとくべきです。遅れるとの連絡もなく予定日をすっぽかせば、この人は逃げると見ていいです。すべては最初の1回で決まります。
ただし経験の浅い人ほど誇大妄想気味に完成予定日を早く見積もるので、期待しないこと。こちらもプロ並の金を払うわけでなし、「なんで遅れるんだ」といって、相手を萎縮させたり、やるきをそいだりしたら、音信不通の原因です。少しの遅れなら目をつぶること。大切なのは、間に合いそうになければ自主的に連絡してくれることです。
あらかじめ、「音信不通の場合、著作権をグループに譲ったとみなしていい」との取り決めをつくり、参加者に了承させたほうがいいです。音信不通のメンバーの著作物を勝手に使いつづけていると、こじれたときにこちらが不利になります。たとえ、使わなくても(音信不通になるぐらいなのだから使い物にならないのが普通ですが)、逃げた人から「人の物を勝手に使っている」と言いがかりをつけられないための安全策になります。

責任感のある人に入ってほしければ、「このグループに入りたい」と思わせるぐらいに自分達の腕を上げるしかないです。

一度逃げることを覚えた人は逃げ癖がつきます。同人ゲーム作りをする前から友人だった人が音信不通になりながら、ずいぶんたって甘えて戻ってきたのにまた音信不通になった例もあるのです。万一、逃げた人が「もう一度加わりたい」といってきたら「完成したら連絡くれ」で終わらせたほうがいいです。

テストプレーヤーが報告を全くよこさない。よこしても批判屋。

複数の同人グループで、テストプレーヤーが報告を全くよこさず、「どういうつもりで応募したんだ」と思わせる人が結構います。グループには「3回報告を出さなかった人はグループから抜けたとみなします」と規則を作っているところもあるぐらいです。

また報告してもできの悪いところを指摘するだけで、改善してもよくなったか何の反応もないケースもあります。なかには雑誌で中途半端に知った知識でプログラマーに的外れなことをいう人も。

ネット上でのゲームの感想とゲーム誌の読者欄でも評価されるのはシナリオ、原画、作曲の順。4番目にようやくプログラマーですが、バグがあるの操作性が悪いのと悪い部分でしか取り上げられません。プログラマーが数学とプログラミング技術を駆使してすごいエフェクトを作っても、その分野の知識がないテストプレイヤーではすごいことをやっているのがわからず評価がないのが普通です。
ですからテストプレーヤーにはプログラマーを評価するなら短所だけでなく長所も取り上げ、短所が改善されているならきちんと指摘するよう予め伝えたほうがいいでしょう。

またクリエーターが他の人が作ったものを批判、注意するなら代案を出すようにあらかじめ取り決めを作ればトラブルがおきにくくなります。またトラブルが起きないよう、リーダーが計画のたたき台や複数の選択肢を用意してから意見を聞く方法もあります。

著作権の取り決めがない。

著作権をあいまいにして、リーダーがゲームの著作権は勝手にグループの物(つまりリーダーの物)にしてしまうともめることがあります。実際、メンバーが「自作を提供してるけど著作権まで譲っていない」と怒り、トラブルになった例があります。

複数の人が作る同人ゲームは取り決めがなければ共同著作物集合著作物結合著作物のいずれかです。

共同著作物とは複数の人が作った著作物で、各人の作った物が融合して分離できないもの。例えば1つの曲を二人で作曲すれば共同著作物となり、著作権は共有。法律で定められた保護期間は最後に亡くなったメンバーの死後70年内です。

集合著作物は各々パート分けして書き上げたもの。共同著作物とはちがい分離できるもので、著作権は各自が各担当の部分だけを持ちます。ゲームのリメイク版で旧版の絵を差し換えるケースはあり、つまり分離できるので集合著作物です。ただ各自が著作権を持つにしても絵の著作権は原画家とシナリオライターの共有にした取り決めのほうが無難でしょう。

結合著作物は歌謡曲の曲と歌詞のよう分離できるけどセットとして作られたもの。著作権は集合著作物と同じです。

ただし複数の人が絡む著作権の法解釈は『電車男』の著作権を見ても微妙です。「ゲームは1つのEXEファイルになり分離不可能なので共同著作物だ」という法解釈も可能なのです。
実際、裁判官の判断でとんでもない判決がでることがあります。『キャンディーキャンディー』の著作権裁判では「マンガは共同著作物ではなく、著作権は原作者にあり、マンガはストーリを翻案することによって創作された二次著作物である」と判断されました。正直疑問がありますし、この判例を機械的に使うと、シナリオライターだけが得をするのでもめますしね。

逆に取り決めがありメンバーが了承したならば、各部分の著作権は作ったグループのものにできます。ただし、メンバーが著作権をグループに譲っても、著作者人格権は別です。この著作者人格権とは簡単にいえばゲームのこの部分を作ったのは自分だと公表したり、逆にグループが作者名を公表することを断る権利。ほかにも提供した作品を作者の意に反し18禁作品に流用することも、著作者人格権上許されません。

なお日本の著作権法では作詞作曲には著作権はあっても編曲にはないです。もしテストプレーヤーが「自分の意見が反映されたのだから自分も著作権を持つ」といっても、編曲の例に準じて拒否できます。

また、手間を省こうと許可も取らず他の人の作りかけの作品に手を加えようとしてトラブルになったケースもありますので注意。

リーダーが音信不通。

実際にあります。こうなればグループはおしまい。メンバーは自分の著作権を確保し、リーダーからスケープゴートにされないよう手をうちましょう。


inserted by FC2 system