同人プロジェクトマネジメント入門の目次はこちら

はじめに

マネジメントの各工程についての注意点、解決策を書いていきますが、その章立てに対して正当性を確認するため、概要編ではマネジメントとはどのような仕事なのかについて書いていきます。

定義

マネージャー：「同人プロジェクトの進行を担当する人」ぐらいの意味。実際の同人プロジェクトでは、基本的にしっかり役割を決めることが少ないです。

ビジネスに比べた同人プロジェクトの特徴

強制力がない

給料をもらっている人間がならば、ある程度プロジェクトにコミットする義務がありますが、あくまでもサークルですから、強制力が存在しません。何らかの方法で強制力を生み出さないと、だれも仕事をしないという状況が生まれてしまいます。
同様に、プロジェクトをかき乱すようなメンバーがいたとしてもそのメンバーに対して強制力をもって追い出すなどの対処もできません。
とにかく権力構造がフラットで、トップダウン型のプロジェクトが非常に難しいことが特徴です。

教訓：強制力を生む努力が必要！

仕様・完成を自分で決められる

「クライアント」「取引先」などの概念が存在せず、何を作りたいかは各メンバーの要望によって決まります。
これは基本的にはいいことです。理不尽な仕様を押し付けられることはないですし、マネージャーからするとコントロールできるものが多いのはいいことです。
非常に自由ですが、決まったフォーマットがないがゆえに最初は仕様決定に失敗することも多いです。
この特徴によって、世の中に出回っている「プロジェクトマネジメント入門」などの情報がうまく活用出来ない場合が多いです。

教訓：仕様の決め方に工夫を凝らすべし！

コミュニティ・友情を重視する必要がある

基本的にモチベーション駆動開発なので、いくつか気にかけるべきポイントも発生します。
例えば、責任を決めないと開発が回らないくせに「責任」は禁句であることや、失踪者を出したら大抵完成までいかないなどです。
また、重要なポイントとして、ほとんどの場合モチベーションは急速に下がり、滅多に回復しないものであるという事実もあります。

教訓：同人プロジェクトは人間が最大の経営資源！気持ちよく働かせよう！

特徴まとめ

良くも悪くも柔軟性があるのが特徴です。
マネージャーは、この柔軟性を殺さないようにプロジェクトを回さないといけません。しかしまったく柔軟性のない締め切りと戦わなければなりません

マネージャーの働く場面

1. 「何を」やるのか仕様を決める

同人マネージャーの仕様の最大の特徴は、常に一番上流の工程にいるということです。すべてを決めるだけの権限を持っています。この工程はプロジェクトの最初期であり、この場面での人間関係の構成が残りの全体に影響します。
同好の士が集まってプロジェクトを作る場合「企画者=マネージャー=リーダー」になることも多い印象です。

2. 「どうやって」やるのか計画を立てる

「いつ」「いつまでに」やるのか

時間を決定するのは非常に重要な問題です。しかしながら、時間を決定したら期待通りに進行するわけでもありません。
逆に、「予定を決定しておいて予定通りに負えられない」とい状況は、うまくいかない罪悪感などを生んでモチベーションを削りかねません。同人プロジェクトマネージャーは時間に関してシビアな意思決定をする必要があります。

「誰が」やるのか

仕事の割り当ても重要なマネジメント対象です。
しかしながら、これも難しい決定です。例えば、本人の力量を知らずに仕事を割り当ててしまったとき、もしビジネスならば、マネジメントの判断で本人の仕事を変えることで対応できます。しかし、ビジネスに比べて同人プロジェクトだと「仕事を奪う」という判断が極端に難しいです。人間関係やモチベーションが重要なので、仕事を奪う判断は比較的に重くなります。

その他の計画

金で調達してくる

同人プロジェクトでは、各種素材をお金で調達することができます。コストマネジメントも仕事です。

助っ人を呼ぶ

サークルなどでは外部から助っ人を呼ぶことが出来るでしょう。「最終助っ人を呼べば何とかなる」といった状況を作っておくのもマネージャーの仕事です。

勉強させる

プロジェクトメンバのスキルが足りない場合には、一定期間勉強に費やさせることが必要です。

ツールの導入

世の中には開発を円滑にするためのツールが多くあります。実際、Githubのpull requestを使って開発を進めるプロジェクトもあるでしょう。しかしながら、これらは基本的に業務で使うことが想定されていることがメインで、かなりきっちりしているベストプラクティスの情報が多いです。同人プロジェクトでは、もう少し「雑な」運用の方が効果的なことが多いです。

3. 仕様と計画を修正し続ける

プロジェクトの変更要因を並べました。これらのイベントが発生するたびに、マネージャーは仕様と計画を修正して、プロジェクトを円滑に進めていきます。

リスク管理

メンバー同士がぎくしゃくしている
メンバーが失踪、病気、(「トラックに轢かれる」)
納品したコードの品質が悪いことが発覚

主に人間関係要因と技術的要因の2パターンがあり、単発で一気にプロジェクトの雲行きが怪しくなってくる状況。備えておくしかない。

進捗管理

「終わりませんでした！」というやつ
「この時期は試験があってやれませんね」というやつ
「あいつが仕事しないので俺が働けねぇな」というやつ

じわじわとプロジェクトを闇に包んでいくタイプ。離散的なリスクに対して、連続的に発生するため、予想・対応を早めることが大事。

変更管理

「作ってみたら、こっちの方が面白いと分かった」(ポジティブ)
「作ってみたら、ゲームにならないことが分かった」(ネガティブ)

要件定義をきっちりしておけば避けられるかもしれないが、同人プロジェクトでガチガチの要件定義書なんてあるはずがなく、また、ゲームの面白さという定量化しにくい値が重要な変数であることも相まって、避けられない変更である。

おわりに

今回は、何を変えるべきかについて解説しました。次回からは、今回挙げた工程のそれぞれについて、どのような対応策が考えられるかについて書いていきます。