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

はじめに

仕様書を書くツールが決まったら、次はどこまでを仕様とするかを決める必要があります。今回は、同人プロジェクトに適した仕様決定の方法について書いていこうと思います。

仕様決定のタイミング

長期的な仕様の意味は薄い

なぜ巨大な仕様は壊れやすいか

まず、最も重要な点として、同人プロジェクトにおいては、最初に作った仕様書は、ほとんど最後には忘れられるということを強調しておきます。その原因としては以下のものが挙げられます。

はじめにはメンバーの力量が分かっておらず、実現性がないものが仕様に含まれる
はじめはメンバーにモチベーションがあるので、実際にはできないような量の仕様が書き込まれる
仕様書を書くのは楽しいので、ついつい高すぎる理想を書いてしまう(往々にして、あとで消せばいいや！という言い訳を伴います)
実装途中に仕様がどんどん変わっていく

「いきなり大作を目指した結果、途中でモチベーションが尽きて死ぬ」というのは典型的なパターンだと思います。

長期仕様の作り方

ポイントをいくつか並べておきます。

未来のことはあまり決めない：将来の情報を後から織り込んでいくための「余白」が大事です。「○○機能が欲しい！」以上の情報を詰めてもあんまりいいことないです。
すぐに外せる仕様に徹する：「作れなくてもいい」「コアのシステムとインターフェースが分離され着脱性が高い」「本体システムとは完全に別に作れる」などの特徴がある場合には、仕様を詰めてもいいでしょう。なぜなら、実質的に別プロジェクトなので、この仕様での失敗は、他の部分に波及しないからです。

短期的なゴールを積み重ねよう

基本的にモチベーションは、クリエイティブで夢が広がる仕様の作成時にチャージされ、実装時に消耗します。
したがって、仕様決定作業を何度か繰り返した方が、モチベーションが最後まで持続しやすいです。

仕様は最小限にする

仕様の決定自体も慣れが必要な作業です。マネージャーにとっても、一度に多くの仕様を決めようとしても難易度が高いです。
また、述べた通り、仕様の作成時には、メンバーが暴走しやすいので、スモールスタートが重要です。
さらに、プロジェクトが進むことでわかる情報もあります。例えば、「メンバーが失踪しそう」や「金で解決できそう」などです。これらの情報を織り込んで新しく仕様を作っていく方が精度が上がります。

雪だるま式に増やす

仕様は削るものではありません。仕様は増やすものです。
「あらかじめ削ってもいい仕様を決める」というやり方もありますが、あまり上手くいきません。具体例を挙げます。

当初の仕様：A→B→C(B,Cは削ってもいいよ～)
理想：A→B→Cの途中で終了
現実：Aが実装出来ず、A'になり、B'C'の仕様策定作業発生。しかし、B'も思った通りに実装出来ずB''となり、C''の仕様策定作業発生。

上のように、思った通りに実装出来ないことの方が多いので、先の仕様を考えても無駄になることが多いのです。上の例では、B,C,B',C'の仕様の作成作業は完全に無駄になってしまいました。

それよりもAを決める。A'になる。B'を決める。B''になる、C''を決める…といった仕様決めの方法の方が無駄が減ります。

骨と身を分けて、とにかく完成させる

「骨」となる仕様は、例えば「戦闘システムの存在」や「RPGのメインクエスト」などが当たります。骨がないとゲームとして一応動くものが出来ない、という状況になります。
「身」となる仕様は、例えば「戦闘における必殺技」や「RPGのサブクエスト」などが当たります。身は、あればいいけどなくてもいい仕様です。
初期の仕様では出来るだけ「骨だけ」または「骨+身が1個ずつ」になるようにしましょう。
その理由は、「最低限遊べる」という状況がモチベーションアップに非常に有効だからです。
辛い作業の中から出てきたゲームは、どれだけ仕様が小さくても、「動く」というだけで感動出来ます。
身を1個入れる理由は、後に述べる「マネージャー的に楽なタスク」を増やすのに有効だからです。
プログラマならわかると思いますが、サブクエストが1個あれば、10個作るのはそんなに難しくないですよね。
逆に0から1を作ろうとすると、結構手間がかかる改修になってしまうので、ほぼ確実に入るであろう身の仕様に限っては1つだけ入れておくことをお勧めします。

人間関係面

一度作った仕様を消すと、それに積極的に関わっていたメンバーにとっては、自分の仕事を消されたかのように思い、モチベーションが一気に減ります。将来自分の入れたい仕様を入れるかもしれないという期待で、手元の仕事をするモチベーションが生まれます。

詳しく書かない

仕様書の詳細度についても、マネージャーの段階では詳しく書かないのが適切です。
仕様自体が雑なものなので、プログラムを書こうとする段階で仕様に疑問が出るのは当然です。
また、書いてみて初めて気づくことは大量にありますから、それを全部予想するのは難しいです。

ラフに仕様書を書く
仕様書に足りない部分があれば、仕様書に疑問を書き込む
その部分に担当者が書き込む。重大なものがあれば全体グループで問題提起する

という方式をとりましょう。比較的効率が良いと思われます。

出来るだけ仕様を簡潔にするための方法

金・素材の力を活用する

UnityならAsset Storeがありますし、Mixamoでリグとかモーションとかを持ってきたり、テクスチャをtextures.comからとってきたりして、解決するようなタスクなら、解決してしまいましょう。
個人プロジェクトだと支出が嫌だというマネージャー・チームメンバーもいるかもしれませんが、時給1000円で10時間働いて得られる給料で買える素材と、自分が10時間で作れる素材を比較して考えるとよいと思います。未来の安心をお金で買うと考えれば安いと思います。限りあるモチベーションは、自分にしかできないタスクに使うと、クオリティ・独創性両方が上がっていきます。

タスクに関して適正な感覚を持った人間の意見を取り入れる

これは仕方ないことなのですが、時には開発メンバーの中に「ここはリアルさを追求して仕様を複雑にしようぜ」とか「ゲームのアート面を追求しようぜ」とか言って突っ走ってしまう人が出てきます。そういうメンバーは理想に燃えているので「序盤は猛烈に仕事をしてくれて、途中から燃え尽きる」といったパターンに陥りがちです。仕様決めは楽しいので仕方ないです。

しかしマネージャーは、心を鬼にして適正なタスクを決めなければなりません。
おすすめの作戦は、まず複数回会議を開くことを伝えておき、最初の会議でキャラクターを判別して、穏健そうな人を集めて内々で協定を結んでおくことです。複数人で仕様に燃える人を説得すれば、そのモチベーションをすでに決まった仕様の実装に費やしてくれると思います。

定期的に仕様作成会議を開く

仕様を段階的に増やして決めるという方式をとった以上、仕様作成会議を定期的に開く必要があります。
スケジュール決定の方法ですが、前回決めた仕様のうちおおよそが決まったら次の仕様を決定するという方式がおすすめです。
時間で区切らない理由としては、たとえ時間で決めたとしても、基本計画は遅れるものだからです。
何回か会議をしていくうちに、仕様決定の経験値がたまっていくと思います。

おわりに

アジャイル開発に近いような内容になりました。日々の変化に適応するための方法を考えるとアジャイル開発に収斂していくのかもしれませんね。