はじめに

計画編では、計画をどう立てるかについてだけでなく、どう実行するかまで包括的に解説をします。
今回は、計画の基本的なポイントについて列挙していきます。

仕事の割り当て方法

いつ割り当てるのか

小出しに割り当てること

計画を立てる時は長期的に考える逆算方式と、今週は何をするかなどを決める積み上げ方式の2つのやり方があると思いますが、ゴールが自由な同人プロジェクトでは、積み上げ方式をお勧めします。その理由は以下の2つです

未来の予測はできないから：同人プロジェクトでは、そもそもちゃんと工数の予測などをせずに、しかもメンバーの力もあまり分からない状況で話が進む場合が多く、未来の進捗状況を予測することが極めて難しいです。比較的確実にわかる来週再来週あたりの内容だけを決めるのが最も効率がいいです。
仕事の巻取りリスクを減らすため：計画がずれたときに一番手軽な解決方法が「進んでない奴の仕事を進んでる奴に渡す」です。しかし、基本的に人間の優秀さはばらつきます。自分の仕事がどんどん巻き取られていくのを見てうれしいメンバーは居ません。参加する意欲すら失ってしまいますし、仕事を巻き取る側も「私の仕事ばっかり増えて！」と損した気持ちになります。だれも幸せにならない手法です。この状況を回避するために小出し割り当てを使います。もともと割り当てられていないプールから仕事を割り当てたなら、心理的なダメージを回避できます。

待ちを生まないこと

「Xさんの仕事が終わらなかったのでできませんでした」という発言が出る状況を作らないことが重要です。
仕事はなくなった瞬間に新規に割り当てましょう。
このときに重要なのが、以前に解説したタスクの炎上しやすさです。
依存関係の少ない仕事を多めに用意している場合には、手が空いている人に即座に仕事を割り当てられます。また、単調な仕事であれば能力が足りないメンバーでも速度が遅いだけでマイナス進捗を生むことはありません。
もしも、Xさんの仕事が終わらないと着手できない仕事ばかりで、それでもなおXさんの仕事が遅いことが原因でプロジェクトが遅れているならば、マネージャーとしては、Xさんと話し合ってきちんと納得させた状態でXさんから仕事を巻き上げることが必要です。

失踪判定・モチベーション消滅判定はマネージャーがする

基本的にはプロジェクトメンバーは、「出来るか分からないけどやります」とは言っても「出来ませんでした」が言えません。しっかり報告できるタイプのメンバーは大体熱意があって有能な人のでさらっと熟してしまいます。
したがって、定期的にコミュニケーションをとることを徹底したうえで、一定時間返信がなければ無言で仕事を巻き取って良いです。待ってもあまりいいことはありません。もともと頑張ってくれているメンバーのモチベーションを奪うような人間関係上の行動は止めた方がいいですが、プロジェクトのボトルネックになっているメンバーのモチベーションは基本的に無いので、どれだけ下がろうがプロジェクトに影響しません。
再割り当ての判断は早い方がいいです。この判断を簡単に出来るように、あまり割り当て量を増やさないということが重要です。

誰に割り当てるのか

強いメンバーにクリティカルなタスクを割振り、弱いメンバーに単純労働を割り振る

クリティカルなタスクとは、依存関係やタスクの大きさから考えて、完成しないとプロジェクトが炎上しかねないタスクです。
プロジェクト開発初期段階でも、メンバーごとの能力は分かってくると思うので、その時点で割り当ての方針をマネージャーが決めて下さい。マネージャーが決めた割振りならあまり不満感は出ません。「しゃーなしやる」感を減らす唯一の方法は、事前に決めたルールに従って粛々と仕事を割り振ることです。
もしも、クリティカルな仕事をそれをやるだけの能力がないメンバーに割り振った場合、そのメンバーのモチベーションを犠牲にして強制的に仕事を取り上げるか、事なかれ主義を貫いてじりじりと納期を遅らせるしかなくなります。
したがって、出来るだけ早期に能力を見極めることが重要です。もしも、だれにも能力がない場合には、外部の人間を捕まえて何とかしてもらうというのもアリです。
これをうまく見極めるための方法として、プロジェクトの規模が半年以上でメンバーも4,5人以上になる場合には、最初に超小型プロジェクトを作ってみる方法もおすすめです。一度プロジェクトをやらせてみれば簡単に能力を推測できます。

学習コストの考え方

特定の技術分野においてはどうしてもプロジェクトメンバーに学習してもらうという手続きも必要です。しかしながら、学習というのは以下の理由から基本的にリスキーな選択肢です。

学習期間は学び終わるまでに分からない
慣れていない技術を使うことになる
不慣れが原因で設計がぐちゃぐちゃになった場合、後に響く

これらのリスクはできるだけ負わないことが賢明です。プロジェクトの成功だけを目指すなら、枯れた技術を愚直に使う方がいいと思います。
どうしても学習する必要がある分野がある場合には、次の項で解説する「先に金で何とかしてから置き換える」を応用した「先にライブラリで出来るだけ楽に実装してから、自作実装に徐々に置き換える」という方法をとることを検討してみてください。

なにを割り当てるか

「もう先にアセット使ってしまった方がいい」という発想

仕様書作成編では、「金を使って時間を買え！」と書きましたが、金を使わないと決めた素材にさえ金を使うことが出来ます。
具体的には、「UI画像が完成するまでレイアウトが分からんよ」とか「3Dモデルが来るまでアクションパートはきついな」とかの状況は、仮にUI画像を完成品のゲームで使わなくても、仮のUI画像を入手しておけば、待ちを減らせます。
この待ちとは要するに仕事同士の依存関係です。すなわち、タスクの炎上しやすさに直結する事項であり、きわめて重要な要素です。
「先にアセットを買って、それを使ってくみ上げて、後からアセットを自作素材で置き換える」という方法をとると、一応の完成が早くなりますから、計画を立てる上でも非常に効果的な方法です。
また、仕様変更にはなるものの、最悪仮の素材でゲームを完成と言い張ることもできます。

「細かい仕様決定」を実装者の仕事にするのもよい

同人プロジェクトでは、仕様が細かく決まり切らず「いい感じによろしく」という指示が発生したり、「全部俺の言うことを聞け」という人が発生したりします。これは仕様の認識のずれや、プロジェクトの人間関係の歪み、特定の人間への依存を生みやすくあまり良くない状況です。そこで、「大まかなやりたいことをマネージャーから伝えて、それを実装する人が細かい仕様を決める。仕様決めの結果は進捗報告会で報告する」という方法をおすすめします。実装者が実装の視点をもって細かい仕様を決定し、仕様決めの負担を分散して、進捗として報告することで認識のずれを防ぐことが出来ます。また、仕様決定は比較的楽しいので、この段階で失踪することは少ないですし、大まかな仕様が決まっているので暴走して多くの仕様を詰め込むこともできません。細かいことの予測なんてどうせつかないので、マネージャー側で全部対応しようとすること自体が間違っているでしょう。

テスト実装の罠

仕様が複雑だと、とりあえずTestXXXというシーンを作ったり、TestScriptという名前のスクリプトを作ったりしたくなります。しかし、この手のスクリプトは、同人プロジェクトでは特にですが、かなりの確率で結局流用されて本番のコードにも混ざります。つまり、全然テストじゃないということです。テストというのはテストという品質保証の全然楽しくない作業をするという意味であり、雑に設計をする言い訳ではないのです。したがって、テストは後に書かせましょう。テスト駆動開発とかの考え方もありますが、あれは最初にテストという実行可能な仕様書を用意しようという、TestXXXとかの雑さとは対極にあるものであり、テストという名前の付いたナニカを最初に書いている、という理由で同一視していいものではありません。
これを阻止するためには、仕様書時点でタスクを小さくしましょう。そして、その範囲で確実にしっかりと設計を考えさせましょう。素人の考えた設計だろうと、雑に考えたものをアドホックに拡張するよりマシです。

おわりに

計画の設定と実行は、マネージャーの基本的な作業になります。この作業をしている時間が一番長いので、計画のうまさにマネージャーの実力が現れると思います。

同人プロジェクトマネジメント入門：計画編その1