1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

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

Last updated at Posted at 2021-12-08

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


はじめに

計画は、一度作れば終わりではありません。絶えず修正していく必要があります。計画編その3では、いかに計画を効率的に修正をしていくかについて解説します。

計画の修正を恐れない

計画の修正は、ウォーターフォール型のプロジェクトマネジメントでは特別なイベントですが、同人プロジェクトマネジメント入門でお勧めしている方法では毎日発生してもおかしくないものです。
なぜなら、この方法は、いつプロジェクトが終了しても、そこで完成と言えるように、出来るだけ仕様の作成と仕事の割り当て、計画の作成を先延ばしにして、必要な時に必要な分だけ行うというものだからです。真剣な設計、真剣な要件定義、真剣な計画作成を何度も繰り返していくのですから、計画の修正はよくあるイベントなのです。
したがって、マネージャーは一度計画を作ったらあとは何もしないという態度をとってはいけません。
常に進捗状況や人間関係、メンバーの実力、仕様の現状に目を配ってそれに合った計画をたてることが要求されているのです。

定期的に会議を開く

進捗報告

進捗が出たら報告する方法はあまり上手くいきません。
進捗が出たならば報告も出ますが、進捗が出ないと報告が出ないからです。すなわち、やっている途中でもまったくやっていなくても報告が来ないのです。進捗報告がなければマネージャーの仕事はありませんから、マネージャーは一時的に楽ですが、これは負担の先送りにすぎません。
そこで、基本的には「進捗が出ても出なくても報告、報告がない場合には進捗がないとみなす方式」を採用しましょう。モチベーションリスク・失踪リスクが高い同人プロジェクトでは特にこの方法をとるべきです。
そして、モチベーションの管理をして、仕事の割り当て量を調整していきましょう。

仕様変更・仕様決定

過去の実績について進捗報告をしたら、次に未来の実装について、変更内容を議論しましょう。
仕様の変更や決定が発生するのは次の3パターンです。

  1. 開発メンバーが仕様を1つ実装したとき:仕様書作成編でも書いた通り、同人プロジェクトでは仕様は必要になったら作る方がリスクが少なくて済みます。そこで、進捗が出ると同時に次の仕様を詰めていきましょう。ポイントは、常に各メンバーが持っている実装するべき仕様を1にキープすることです。
  2. 先週までの働き方で変更したい点があったとき:開発のワークフローに明らかに無駄がある、などの状況がないか、メンバーに聞き取りして、改善策をとりましょう。
  3. 仕様変更がしたくなったとき:例えば「敵の攻撃に遠距離があるとクソゲーになる」場合には、仕様を変更する必要があります。このパターンの仕様変更には、「この方が面白い!」というポジティブなものと「このままだとつまらない」というネガティブなものがあります。ポジティブなものに関しては、新しい仕様を追加することになりますから、仕様書作成編の内容などを参照しながら慎重に追加してください。ネガティブなものに関しては、どちらかというと仕様の欠陥の修正で、やらないと仕方がない仕事であることが多いので、最低限の修正は行った方がいいでしょう。

プロジェクトは絶対に遅れる

遅れた場合の割り当ては事前に考えておく

仕事の終わる速度に個人差があるのは当然なので、遅れが発生してから、会議で「遅れているので他の人はどうしようか…」といった議題を出すのではなく、先に対策を考えておきましょう。
こんな議題を出してしまえば、遅れている人のモチベーションは木端微塵になってしまいます。誰が送れるかはわかりませんが、誰かが遅れるのは確実なので、間に詰める仕事を用意することで待ちが発生しないようにして下さい。
また、遅れていること自体はメンバーに周知することが必要だとしても、なるべく感情をこめないように伝えましょう。
さらに、遅れの原因を把握して、もしもその原因が悪質な場合はタスクを巻き取らせる相手を用意して、速やかに担当者を変えましょう。悪質な遅れの原因とは、「やるやる詐欺でまったくやっていない」「根本的に実力が足りていない」「ほぼプライベートに開発時間がないのに仕事だけ受け取った」といったものです。

締め切りで開発速度を上げる

これは計画の修正のうち、「いつまでに終わらせるか」を変更するタイプの修正です。

外部の締め切りをたくさん作ろう

今まで、開発メンバーのモチベーションは、最初の仕様を考えているときに最高潮で、そこから急速に落ちて、基本的に戻ってこないと書いてきましたが、それが当てはまらないタイミングが1つだけあります。それが締め切りです。メンバーは、作品が完成しないギリギリになってようやく頑張りだします。出来るだけ先送りするのは人間の性ですね。
この締め切りを生かさない手はないです。しかし、人間は基本的に怠惰なので、破れる締め切りは守りません。出席しないと何らかのおとがめを受ける高校まではほとんど皆勤だったのに大学で自由を得てから1限に出られなくなった人、いませんか?
そこで、マネージャーはプロジェクトの遅れを取り戻すために外部のイベントに積極的に応募するなどして、破ったら迷惑がかかるような締め切りを作りましょう。(ただし、実際に迷惑をかけるのはよろしくないので、仕様書作成編などを参考に工夫をしてください)

締め切りを伸ばしてブーストをかけよう

締め切りまでの時間に比例して進捗速度は向上します。同人プロジェクトでは特に、プロジェクトの進捗の半分を締め切り直前の徹夜開発で出す、みたいなこともあるんじゃないでしょうか。
このパフォーマンスを出している時間を延長する方法があります。それは締め切り延長です。
締め切り数時間前に、「締め切りがあと3日延びた!」と伝えることです。これにより、締め切り直前モードが延長されます。もちろん、これは1,2回しか使えない技ですが、一気に進捗を生めます。
何度もやると開発メンバーはそれを見越して締め切り直前でも開発をさぼってしまいますし、メンバーの心身の負担が大きすぎるのでやめておきましょう。

おわりに

計画通りに物事は進みません。そこにいら立ち誰かを責めてしまうようでは、プロジェクトの成功はないでしょう。特に同人プロジェクトでケンカが起こってしまえば、そこでかなりの確率でメンバーが去ってしまいます。遅れる前提で、それでも何とかする柔軟で粘り強いマネージャーを目指してください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?