もし一つの作品を100人で同時に作ったら

100人になると、何が急に増えるのか

増えるのは作業量よりも、人と人の間の連絡経路です。全員がそれぞれの相手と直接やり取りする可能性を数えると、人数 n に対して n×(n−1)÷2 本になります。

• 5人なら10本です。
• 10人なら45本です。
• 100人なら4,950本です。

人数は20倍なのに、経路は約495倍になります。全員が全員と話し合って決める方式は、この時点で成り立ちません。「主人公の高さは何ピクセルか」といった小さな決めごとにも、確認が数千本の経路を通ることになるからです。

実際の大人数の制作では、全員で決めることをやめ、決める場所を絞ります。誰が何を決めてよいか、決めた結果をどこに書くかが、人数の増加に合わせて重要になります。一人で作るときは頭の中で済んでいた約束が、100人では文章として外に出ていなければ機能しません。

断片がぶつかりやすい四つの場所

100人がそれぞれ誠実に作業しても、集めた瞬間にぶつかりやすい場所があります。ここでは四つに分けて考えます。

1. 見た目の不一致：絵の担当が10人いれば、線の太さ、色数、影の向き、キャラクターの頭身が10通りになりえます。個々の絵が良くても、並べると別のゲームの素材に見えます。
2. ルールの二重定義：体力の減り方を敵の担当も罠の担当も自分の側で決めていると、同じ場面に二つの計算が走ります。どちらが正しいかを示す場所がないと、結果は読み込み順で決まります。
3. 名前の衝突：二人が同じ名前の変数や関数、ファイル名を使うと、後から読み込まれたほうが前のものを上書きします。エラーが出ずに動作だけがおかしくなることがあり、見つけにくい種類の問題です。
4. 体感の不一致：効果音の音量、画面が揺れる強さ、操作への反応の速さは、各自が自分の環境で心地よいと感じる値に調整しがちです。足し合わせると、うるさく、せわしないゲームになります。

この四つはどれも、個人の技量の問題ではありません。「共通の約束がないままに、同じ場所へ書き込んだ」ことが原因です。

まとまるのは「分け方」を先に決めたとき

では約束とは何でしょうか。コンピューターの世界でよく使われる考え方に、小さな核と差し込み口（プラグインのような仕組み）があります。核は、全員が従う最小限の決まりだけを持ちます。各担当はその決まりに沿った部品を一つずつ作り、核に登録します。

次の例は、その縮小版です。登録の関数と描画順の決まりだけが共通で、背景、自機、点数表示の三つの部品が互いのコードを知らないまま一つの画面になります。HTMLファイル一つで動きます。

<!doctype html>
<canvas id="c" width="320" height="180"></canvas>
<script>
const parts = [], keys = {};
const register = (p) => parts.push(p);
addEventListener('keydown', e => keys[e.key] = true);
addEventListener('keyup', e => keys[e.key] = false);
</script>
<script>
// 担当A：背景
register({ name: 'bg', order: 0,
  draw(g) { g.fillStyle = '#234'; g.fillRect(0, 0, 320, 180); } });
</script>
<script>
// 担当B：自機
const me = { x: 160 };
register({ name: 'player', order: 10,
  update(dt) { me.x += ((keys.ArrowRight ? 1 : 0) - (keys.ArrowLeft ? 1 : 0)) * 120 * dt; },
  draw(g) { g.fillStyle = '#fd8'; g.fillRect(me.x - 8, 150, 16, 16); } });
</script>
<script>
// 担当C：表示
register({ name: 'hud', order: 100,
  draw(g) { g.fillStyle = '#fff'; g.fillText('parts: ' + parts.length, 8, 14); } });
</script>
<script>
// 結合役：最後に読み込む
const g = c.getContext('2d');
parts.sort((a, b) => a.order - b.order);
let last = performance.now();
(function loop(t) {
  const dt = Math.min((t - last) / 1000, 0.05); last = t;
  parts.forEach(p => p.update && p.update(dt));
  parts.forEach(p => p.draw && p.draw(g));
  requestAnimationFrame(loop);
})(last);
</script>

ここで担当が守る約束は「register に、名前と描画順を持つ部品を渡す」だけです。自機の担当は、背景の中身を知る必要がありません。部品の数が3から100に増えても、約束の数は増えません。増えるのは register を呼ぶ箇所だけです。

ただし、これで四つの衝突がすべて消えるわけではありません。上の例でも、自機が me というグローバルな名前を使っているため、別の担当が me を使えば衝突します。見た目や音量は、コードの仕組みでは揃いません。そこで、仕組みとは別に次のような文章の約束が必要になります。

• 絵の色数と線の太さ、基準の大きさを一枚の見本にして共有する。
• 音量は、基準の値を一つ決め、全員がそれに対する比で書く。
• 名前の先頭に担当を示す接頭辞をつける。
• 数値で決まるルール（体力、速度など）は一か所の表にまとめ、各担当はそれを読むだけにする。

つまり「まとまる100人」とは、100人が同じ頭の中を共有している状態ではなく、共有しなくても済むように接合部を小さく保った状態です。

アソバースの上限から見える、現実的な単位

アソバースの投稿には、サイズやファイル数の上限があります。確認済みの値は次のとおりです。

• アップロードは20MiB以内です。
• ZIP展開後は合計100MiB、1,000ファイル以内です。
• 1ファイルは30MiB以内です。
• 入口は直下の index.html で、素材は相対パスで参照します。
• サーバー用コード、サービスワーカー、SharedArrayBufferを使うマルチスレッドは対象外です。

この数字を100人で割ってみます。1,000ファイルなら一人平均10ファイルです。アップロード上限の20MiBなら一人あたり約200KiBです。一人が数十枚の高解像度画像や長い音声を入れる余地はなく、各自が出せる断片はかなり小さく絞られます。そのため、素材の大きさと数を最初に配分しておかないと、結合の段階で上限を超えて、削る作業に全員が戻ってくることになります。

もう一つ、この制限は「一つのまとまった公開物にする」という性質も示しています。直下の index.html は一つしかありません。つまり100人分の断片を最後に一つの入口へ束ねる結合役が、必ず誰かに必要です。この役は、作る力よりも、約束を守らせ、衝突を見つけて返す力が求められます。

なお、複数人で一つの作品の名義を持つ仕組みや、共同編集の機能については、確認済みの案内には含まれていません。実際に複数人で制作する場合の投稿者の扱いは、現在の案内で確認してください。確認済みなのは、投稿が入力、表示の確認、公開の3段階で進み、下書き保存や公開内容の更新ができる点です。結合役が一人でまとめて投稿する形なら、この流れに沿って進められます。

自分で確かめる実験の設計書

100人を集めなくても、問いの縮小版は確かめられます。問いは「事前の約束の有無で、断片を一つの作品として動かすまでの手戻りはどれだけ変わるか」です。結果はここでは書きません。やってみて初めて分かることです。

準備するもの

• 3〜5人のグループ。一人で5役を順に演じても構いませんが、その場合は役ごとに他の部品を見ないことを守ります。
• 題材は、上のコードのような小さな一画面のゲームです。
• 制限時間の枠として、各担当30分、結合15分を目安にします。
• 記録用の表（回数、衝突の種類、直した人数、起動までの時間）。

手順

1. 約束なしの回：題材だけを伝え、担当（背景、自機、敵、音、表示）を割り振ります。決めごとの相談は禁止し、各自が自分の部分を作ります。
2. 結合役が全部品を集めて、一つのHTMLで動かします。動かない場合は、原因を担当に返して直してもらいます。起動して全部品が表示されるまで繰り返します。
3. 約束ありの回：別の題材で同じ人数と時間枠を使い、先に15分で次の約束を紙一枚に書きます。部品の登録方法、描画順、名前の接頭辞、基準の大きさ、音量の基準です。その後に同じ手順で作ります。
4. それぞれの回を、できれば担当を入れ替えて3回ずつ行います。

記録の取り方

結合を一回試みるごとに、次を記録します。

• 起動しなかった回数
• 衝突が見つかった場所を、前章の四つ（見た目、ルール、名前、体感）に分類した件数
• 直しに関わった人数
• 最初の試みから、全部品が表示されるまでの時間

結果の読み方

• 約束ありの回で、手戻りの回数や直した人数が減るなら、接合部の約束が効いている可能性があります。
• 差が小さいなら、題材が小さすぎて衝突が起きていないか、約束の内容が実際の衝突とずれていた可能性があります。衝突の分類を見て、どの種類が減らなかったかを確認します。
• 見た目と体感の衝突だけが残るなら、仕組みでは防げず、見本や基準値の共有が不足している、と読めます。

起こりやすい誤り

• 約束ありの回のほうが二回目なので慣れて速くなり、約束の効果と混ざります。題材と順番を入れ替えて、慣れの影響を分けます。
• 結合役が黙って修正してしまうと、衝突が記録に残りません。直したら必ず記録します。
• 回数が少ないと、一回の偶然で結論が変わります。数字は傾向として扱い、断定しません。

次の行動

まず3人で、上のコードに4つめの部品（敵や効果音など）を足してみてください。その部品が他の部品を一切変更せずに登録できるかどうかが、接合部の小さな確認になります。そのうえで、上の設計書を使って「約束なし」と「約束あり」の差を、自分たちの記録で確かめてみてください。複数人で制作した作品を投稿する場合の名義の扱いは、投稿前に現在の案内で確認してください。