Knowledgeゲーム制作に関するプログラミング等を主に書き溜めていきます。どちらかと言えば日記的な書き方が続くと思いますが、そこは温かい目で見て頂ければ。あと、ちょっとしたサンプルやツールのダウンロードも出来るようにしておきます。05:00今回は私のメイン業務についてのお話です。管理を委託する事はまずありません。管理の私は、開発担当諸氏から状況を細かく聞くようにして、都度開発予定の変更を行っています。クライアントさま窓口業務も大切な業務ですが、それは話をするといろいろ危険が危なうわなにをすr作業見積りプロジェクトはナマモノだと思っています。あっという間に腐ります。私は最低でも1週間毎に工程表を更新しています。私がプロジェクトを受け持ったときは、最初に必ずゴールまでの工程表を策定します。Structure)から適切と思われる作業担当割り振りを行い、開発担当諸氏から推定作業量を見積もってらいます。永続版)|オンラインコード版|Windows11、10|PC2台マイクロソフト2021-10-05個人で買うには厳しすぎるお値段ですね...推定作業量見積りは、甘く考える人もいれば、厳しく考える人もいます。そのため、私は各担当に作業の期間策定は以下のように3種類を提示するように依頼しています。自分が考える標準的な作業日数ハマった場合の作業日数この提出内容によって、この担当者の性格的な部分(慎重派か楽観的か等)もある程度は見えます。そこに自分の経験則を加味して作業日数を割り当てます。規模に応じて各作業分類毎に予備日を追加しています。少なくても2日、標準的には3-4日を追加しています。年単位のプロジェクトの場合は、トータルでは平均で開発担当1名あたり1ヶ月(20営業日)以上を予備日として追加しています。この予備日は目に見える形で全員に提示します。あと、当然ですが、土日祝日GWお盆年末年始と年中行事を作業日から外しています。冠婚葬祭も当然休んで貰います。年数回は休みもあるだろうと、その程度は盛り込んで当然と考えています。最初から休日を作業予定に入れるなどは愚の骨頂で真っ黒です。ハマった場合の作業日数で、ハマったらどうなるか分からないと答える開発担当諸氏がよくいます。これは悪いことではないです。現時点で作業内容が明確に見えていないと言うことなのです。彼はこの作業に不安を抱えているのです。このような作業が見つかったら、当該作業をなるべく早く着手できるように開発工程を策定します。杞憂で終われば良いのですが、やっぱりマズいとなった場合は、即座に次の手が打てるように用意しておきます。殆どの場合は、違う担当者割り振りです。プロジェクト進行管理プロジェクト進行中は、各担当には基本的には作業工程表に従って進めてもらうにしています。週の始めに聞き取りを行っています。どの作業を行い、進捗度は何パーセントか(またはあと何日で終わるか)の自己申告を聞きます。工程にない作業を行った場合も報告してもらっています。いうか、この工程にない作業は、多くの場合は追加作業となるため、作業内容の把握が必要です。予定よりズルズルと遅れ始めた作業があれば、なぜ遅れているのかとヒアリングします。問題ないようであれば、現在の進捗度から想定される予想作業完了日からの逆算で、当該担当者に「あと3日追加でどうでしょう?」等とこちらから提案するようにしています。これら追加日数は、各作業項目に追加した予備日から割り当てていきます。作業の順番を勝手に変える担当者もいます。それは作業の流れとか、気分とか、理由はいろいろあると思います。管理側のマイルストーン的に問題が無く、進捗度としても問題なければ、現状の作業の流れが良いのですね順番変えときますよーと気軽に声を掛けて、サクッと入れ替えてしまいます。これぐらいの臨機応変さがないと、実際に開発を行っている作業者側は息苦しく感じて作業効率が落ちます。開発担当はマシンじゃなく人間なんです作業が遅れた事を叱る事は一切していません。そんな事をすれば、貴重な情報を得る機会損失となってしまいます。遅れた原因の多くが、着手してみたら実際は大変だった系です。多くは数日程度の誤差です。各担当もプロなので大きくズレる事は少ないですが、時々ドカンと爆弾のような抜けが見つかります。まるごと作業予定が抜け落ちることはよくある事なのです、その時こそプロジェクト管理の出番です。自分がやるべき事をしていない場合は注意してます。作業の見直しでは、まずゲームデザイン的に品質に直接的に関係しない仕様変更可能な場所がないかを確認します。殆どの場合は、これは予め考察してあるので、そのような変更をしても良いかクライアントさまとすぐに相談します。この時点で初期の問題発生報告にもなります。許可が得られたら、その仕様に急遽切り替えます(記録のため文書化します)。仕様変更が出来ない場合は、担当変更を考察します。それでもダメな場合は一時的な増員も検討します。それでもダメな場合はそれを解決可能な人員を社内から探します。それでもダメな場合は、うちのボスとクライアントさまの責任者に包み隠さず相談するようにしています。プロジェクトの最高責任者にとって、何が最悪の事態かと言えば、順調に進んでいると思ってたら直前で実は全然出来ていませんでした...という状況です。これでは何の手立ても出来ません。言われる事ですが、ダメな事ほど優先的に上位管理者に報告するのです。慣れないと苦しいとは思いますが、ダメな事を報告する事で、次の手が打てます。立ち止まっている時間を極力ゼロにすることが、結果としてプロジェクトを円滑に回す秘訣なのです。ちなみにこれ、私が専門学校教師時代に講義していた内容の実践だったりもします。タグクラウドAILZ80ASMAndroidBASICC#C言語C言語講座DIYJsonMarkdownMZ80CNASNewシティヒーローPC6001PC8001PC8001mk2PCG8100PS2RPGVS2022VSCodeWindowsXperiaZ80お祝いお買い物ちらつきアイテムアセンブラアルゴリズムエミュレータオーダリングテーブルガスレンジガス器具ゲームゲームデザインゲーム制作ゴルフサウンドシリアライズタスクトレイツールテストデザインデバッグデータ圧縮データ構造トレーニングパソコンミニパーツフリーフリーズプログラミングプロジェクト管理プロトタイプ宣言ポインタマップエディタメモリ空間モニターアームラズパイリスト構造リフォームルーターループレトロPCレトロPC開発でカセットにデータを記録する環境を作ります。sapm防止のため手入力してください。リンで利用することは禁止いたします。各記事に直接飛んでくるのはOKです。何かございましたら、上記メアド宛にお気軽にお問い合わせください。レトロPCゲーム制作に使って頂く分には、ドンドンご自由にお使いください。