Skip to content

同人サークルの運営

   
2858文字(約4分)

同人サークルをしばらく回した話

細々とした同人サークルを運営して得られた知見をまとめてみます。もっと良くする方法があったら教えてください。

同人サークルについて

こんな組織を運営していますという前提

  • 小人数
    • 全員本業あり
    • 知識レベルは様々
  • 遠距離のためネット会議
  • 同人ゲーム作成

なお立ち上げた動機は、働いていてうまくマネージされる方法が分からなかったのでマネージする立場になって考えてみようというものでした。
始める前よりは分かりましたが、難しいですね。

全体の流れ

こんな感じです。

alt

ゲームの骨組みを始めに決めてその後は各自作業。

だいたい1,2週間に1度進捗会議を実施し、遅延の有無を確認。
ただし遅れたところで打開策はないので確認する意味は生存報告的な用途でしかありません(生活が懸かっているわけではないことから、締め切りを過ぎても呆れられるだけなので強制力がない)。

仕様作成をしていますが、この作業の意図は厳密な仕様を確定させたいというよりは、雰囲気の共有と作成前に分かるダメポイントをあぶり出すためです。
有効に機能しているかはちょっとよくわからないので様子見状態。

概要作成

ここは場数を踏めていないためあやふやな状態です。

事前準備項目

まず次の項目をざっくりと決めます。

  • コンセプト
  • ジャンル
  • 想定製作期間

コンセプトと言ってもいろいろとありますが、
ここでは「小さくまとまったゲーム」とか「見た目麗しいゲーム」とか「システムにひたすら凝ったゲーム」のようなイメージを決めています。

ここで決める目的としては、今後の決定の際に「どちらでもよいのでは?」となる要素が出てきた際の指標とするためです。

ジャンルはまあ発散しがちなのである程度絞るためで、想定製作期間は短編ゲームと長編ゲームのプレゼンを一緒にしても比較するのが難しかったからです。

項目が決まったら次の内容を次回までに各自用意して会議当日によさそうなものを投票します。
決まらないのでは?と思いきや案外すぐに決まってしまうので、あまり考えていないか情熱を注ぐことのできる案は1人1つぐらいなのかのどちらかなのでしょう。

概要 記載内容
仮題 1行にまとめるとこんな感じ
対象 こんな感じの遊び方をしてもらうつもり
リスペクト元 完全なるオリジナリティなどもう存在しないことから、ベースイメージを共有する
イメージ フリースペース。好きなように書く←ここをもうちょっと工夫したい

概要決定の流れ

いざ各自アイディアを持ち寄ったら次のように決めます。

  1. プレゼン文章用意:5~10min
  2. 議論:10~15min
  3. 掘り下げ対象の決定:~10min
  4. 内容議論

議論をしていると一瞬で時間が流れてしまうので、ある程度でタイマーをかけて我に替えるようにしています。これはかなり大事です。

この段階では次の観点に着目して議論しています。

  • リスペクト元との差分があるのか/どうするのか
  • コンセプトに反した要素をどうするのか
  • そもそも我々の技術力で作ることができるのか

リスペクト元ですが
完全に一致しても同人だからいい気はします。ただ、やはり作るからには若干のオリジナリティを出したい。
でもオリジナリティを出しすぎると発散してしまうので、程よい差分をどのようにして設けるのかを考えます

仕様作成

次のようなものに対しては必ず作成しますが、全ての要素に対して作成するわけではありません。

  • 流れを把握するために必要な部分(状態/画面遷移系)
  • アルゴリズムがちょっと複雑そうな系のやつ

これらは具体的に何があれば良いのかがまだ分かっておらず、また確固たるテンプレートがないのがキツい。
いいテンプレートが欲しいです……

ここの文章量が少ないのが苦戦していることを物語っている。

コンテンツ作成

(実際にどのようにリリースするかはさておき内部的な話としては)ゲームはメジャーリリースとマイナーリリースの2段階に分けて開発をしています。

まずメジャーリリースに載せるべき機能を決めて(マイルストーン)、その後小刻みにマイナーリリースに対して開発を進めます(スプリント駆動)。

メジャーリリース

ここでは搭載機能を決定します。実作業としては次のマイナーリリースで実施するため、作業を決めるだけの分類となります。

段階 実施内容 実施時期
検討 こんな機能を載せたいというものを挙げる 会議までに各自検討
議論 提案機能を精査し、成り立つものを選ぶ
成り立つか不明なものは検討を目的とし、次ver以降に搭載する
会議
判断 これまで挙げた機能のうちこのメジャーリリースに含めるべきものを判断する 会議

マイナーリリース

実際の作業はこの区分で詰みます。

段階 実施内容 実施時期
搭載機能を細分化する このフェーズは仕様が確定しているかどうかでフローが分かれます 会議までに各自検討
妥当性検証 機能の細分化について妥当であるかを検証します(今はWBSとストーリーポイントで運用してみています) 会議
機能実施者の決定 だれがどの機能を作成するのかを決める 会議
実施作業 このマイナーリリースで作成するものを判断する 会議

わざわざ小さく区切る理由としては次の意図でした

  • 作業を発散させてしまう(あっちこっち手を付けて終わらない作業が多い)
  • 期間でどれだけ作業ができるのかを見える化したい(いざ締め切りができた場合に備える)

補足

作業を発散させてしまう原因ですが次のように考えました。

  1. やることが多いので作業時間に合わせてできそうなやつ(つまり忙しいと簡単な奴ばかり)を始めてしまう
  2. そもそも自分がどの作業を抱えているのか把握していない
  3. 作業内容が不透明ですぐに終わると思って始めるが、実際やるとそうでもない

ということでマイナーリリースの仕組みを導入することで次のような解決を意図しています。

  1. やることを区切ることで先に終わらせてから次やってねとなる
  2. 少ないのだから把握できるでしょう(利用ツールも少し改善はした)
  3. マイナーリリース検討時に機能の細分化を実施することでどれくらいの規模間かを見積もる

実際に有効なのかは、、、わかりませんが前よりはよくなったぞ!

comments powered by Disqus