今回は私のメイン業務についてのお話です。プロジェクト管理は私自身は仕様策定と進捗確認に専念して、開発担当の皆さんには実務に注力してもらってます。開発担当諸氏自身に管理を委託する事はまずありません。また管理の私は、開発担当諸氏から状況を細かく聞くようにして、都度開発予定の変更を行っています。
※ クライアントさま窓口業務も大切な業務ですが、それは話をするといろいろ危険が危なうわなにをすr
  • 作業見積り
プロジェクトはナマモノだと思っています。ほかっとくと、あっという間に腐ります。私は最低でも1週間毎に工程表を更新しています。私がプロジェクトを受け持ったときは、最初に必ずゴールまでの工程表を策定します。具体的には Microsoft Project で作っています。作業全てを洗い出し、WBS分解(Work Breakdown Structure)から適切と思われる作業担当割り振りを行い、開発担当諸氏から推定作業量を見積もってらいます。
Microsoft Project Standard 2021(最新 永続版)|オンラインコード版|Windows11、10|PC2台

マイクロソフト
2021-10-05
個人で買うには厳しすぎるお値段ですね…


推定作業量見積りは、甘く考える人もいれば、厳しく考える人もいます。そのため、私は各担当に作業の期間策定は以下のように3種類を提示するように依頼しています。
  1. 全てが順調にいった場合の作業日数
  2. 自分が考える標準的な作業日数
  3. ハマった場合の作業日数

この提出内容によって、この担当者の性格的な部分(慎重派か楽観的か等)もある程度は見えます。そこに自分の経験則を加味して作業日数を割り当てます。さらに、規模に応じて各作業分類毎に予備日を追加しています。少なくても2日、標準的には3-4日を追加しています。年単位のプロジェクトの場合は、トータルでは平均で開発担当1名あたり1ヶ月(20営業日)以上を予備日として追加しています。この予備日は目に見える形で全員に提示します。あと、当然ですが、土日祝日GWお盆年末年始と年中行事を作業日から外しています。冠婚葬祭も当然休んで貰います。年数回は休みもあるだろうと、その程度は盛り込んで当然と考えています。
※ 最初から休日を作業予定に入れるなどは愚の骨頂で真っ黒です。ハマった場合の作業日数で、ハマったらどうなるか分からないと答える開発担当諸氏がよくいます。これは悪いことではないです。現時点で作業内容が明確に見えていないと言うことなのです。彼はこの作業に不安を抱えているのです。このような作業が見つかったら、当該作業をなるべく早く着手できるように開発工程を策定します。そして、杞憂で終われば良いのですが、やっぱりマズいとなった場合は、即座に次の手が打てるように用意しておきます。
※ 殆どの場合は、違う担当者割り振りです。

  • プロジェクト進行管理

プロジェクト進行中は、各担当には基本的には作業工程表に従って進めてもらうにしています。そして、週の始めに聞き取りを行っています。どの作業を行い、進捗度は何パーセントか(またはあと何日で終わるか)の自己申告を聞きます。工程にない作業を行った場合も報告してもらっています。というか、この工程にない作業は、多くの場合は追加作業となるため、作業内容の把握が必要です。また、予定よりズルズルと遅れ始めた作業があれば、なぜ遅れているのかとヒアリングします。特に問題ないようであれば、現在の進捗度から想定される予想作業完了日からの逆算で、当該担当者に「あと3日追加でどうでしょう?」等とこちらから提案するようにしています。これら追加日数は、各作業項目に追加した予備日から割り当てていきます。
※ 当然予備日は減ります。
作業の順番を勝手に変える担当者もいます。それは作業の流れとか、気分とか、理由はいろいろあると思います。管理側のマイルストーン的に問題が無く、進捗度としても問題なければ、現状の作業の流れが良いのですね順番変えときますよーと気軽に声を掛けて、サクッと入れ替えてしまいます。これぐらいの臨機応変さがないと、実際に開発を行っている作業者側は息苦しく感じて作業効率が落ちます。
※ 開発担当はマシンじゃなく人間なんです

作業が遅れた事を叱る事は一切していません。そんな事をすれば、貴重な情報を得る機会損失となってしまいます。遅れた原因の多くが、着手してみたら実際は大変だった系です。多くは数日程度の誤差です。各担当もプロなので大きくズレる事は少ないですが、時々ドカンと爆弾のような抜けが見つかります。まるごと作業予定が抜け落ちることはよくある事なのです、その時こそプロジェクト管理の出番です。※ 自分がやるべき事をしていない場合は注意してます。

  • 工程の見直しと再調整

作業の見直しでは、まずゲームデザイン的に品質に直接的に関係しない仕様変更可能な場所がないかを確認します。殆どの場合は、これは予め考察してあるので、そのような変更をしても良いかクライアントさまとすぐに相談します。この時点で初期の問題発生報告にもなります。

許可が得られたら、その仕様に急遽切り替えます(記録のため文書化します)。仕様変更が出来ない場合は、担当変更を考察します。それでもダメな場合は一時的な増員も検討します。それでもダメな場合はそれを解決可能な人員を社内から探します。それでもダメな場合は、うちのボスとクライアントさまの責任者に包み隠さず相談するようにしています。

プロジェクトの最高責任者にとって、何が最悪の事態かと言えば、順調に進んでいると思ってたら直前で実は全然出来ていませんでした…という状況です。これでは何の手立ても出来ません。よく言われる事ですが、ダメな事ほど優先的に上位管理者に報告するのです。慣れないと苦しいとは思いますが、ダメな事を報告する事で、次の手が打てます。立ち止まっている時間を極力ゼロにすることが、結果としてプロジェクトを円滑に回す秘訣なのです。

ちなみにこれ、私が専門学校教師時代に講義していた内容の実践だったりもします。
※ 実際のガントチャートとかお見せ出来ると良いのでしょうけど、すいません、全て機密事項ですので…