---

• リソースの順番を正しく設定する

現在は全て一直線で作業が繋がっています。このままでは作業がまともに進められません。例えば作曲ですが、データ化のためには MML の仕様とコンバーターが必要となります。そのため、作曲作業はコンバーター完成の後に開始するのが適切な配置となります。また、タイトルロゴデータがないのに、タイトルデモ作成に着手も厳しいです。仮データで作業を進めれば良いという人もいるかもですが、仮データを作る時間が余分にかかりますし、また、その後の入れ替え作業も追加されます。計画時点では製作時に必要なデータが揃っているのが好ましいのです。

MMLコンバーターの完成後に作曲作業開始とするには、まず、MMLコンバーターと■サウンドを行選択します。このため、処理を行う順番に行選択するようにしてください。逆に選択すると逆方向にリンクされます。行選択する順番が大切なのです。最初に MMLコンバーターをクリック、続いて [Ctrl] を押しながら ■サウンド をクリックします。続いてリンクボタンをクリックします。これで MMLコンバーターが完成してからの作曲作業開始になりました。 ■サウンド が 1月ではなく 3月から作業開始に延びています。

このようにこのデータがなければ作業できないであるとか、このプログラムがないと作業できないを探して全てリンクします。今回は ■プログラム とそれ以外の大項目につなぐリンクだけを注力してください。その結果、以下のようなガントチャートとなりました。

---

• プログラム順番を正しく設定する（共通）

さて、続いてプログラムの開発順番について考察します。一旦、プログラム同士のリンクは外してしまいましょうか。プログラム項目だけ全てを選択して、リンク解除ボタンを押します。

さて、プログラム同士でも順番や並列可能な部分があるのはわかりますでしょうか。まず、共通処理は最初に必要です。その後、タイトルデモ、ゲーム開始デモ、ゲームプレイは完全に独立しています。これらは少なくとも別の担当者に割り振りが可能ということです。さらに、共通部分の中も、起動システムまでは共通ですが、それ以外は完全に独立した作業が可能です。強いて言うなら表示系は同じ担当者が作りやすいということでしょうか。

上記の考察を元に、プログラマ 2名で策定してみます。まず、開発環境整備は全員が個別に行いますが、起動システムは誰か一人が作ったモノを共通利用します。そのため開発環境整備のリソースに A,B と記入します。これは Aさんと Bさんという意味ですので、具体的な名前がわかっているのなら、その名前を入れてください。起動システムは Aさんに行ってもらうとしてリソース名を A として、開発環境整備からリンクします。


結果、明らかに B さんの作業負荷が高いので、残ったコンロトーラ入力も Aさんに割り振ります。これで共通部分のAさんとBさんの作業が仮決定しました。予備日は6.5日ありますが、作業負荷の小さい Aさんに2日、作業負荷の大きい Bさんには、4.5日を予備日を設定します。

---

• タイトルデモとゲーム開始デモのリンク

タイトルデモは後から着手しても問題ないので、サウンドドライバとMMLコンバータを作成した Bさんに担当してもらいます。ゲームプレイは画面の出力とコントローラの入力部分を作った Aさんのほうが適任と考えられるのも、タイトルデモを Bさんとした理由になります。

さらにタイトルデモよりゲーム開始デモのほうが重要度が高いので、着手順序としてはゲーム開始デモを、まるごとタイトルデモの上に移動してしまいます。移動でレベルが狂うので、正しいレベルに合わせます。

ゲーム開始デモのリンク元を上記の予備日とします。さらに、タイトルデモのリンク元をゲーム開始デモの項目とします。これらのデモの作業者は Bさんにします。

ここで Microsoft Project だけかもしれない注意が。グループ項目名に担当者名を入れたら、各作業項目側には担当者名は入れないようにします。逆に各担当毎に名前を入れたら、グループ項目名には担当者名を入れてはいけません。これは、多重登録エラーとなり、その担当者の作業時間を適切に計算できなくなるためです。試しに両方ともに名前を入れるとこんな表示になります。


これで Bさんの作業がかなり明確化しました。

---

• ゲームプレイのリンク

まずゲーム中の作成順序を検討します。すると、フルーツの処理順番に問題があることに気が付きました。フルーツを食べるには、フルーツが表示されていないといけませんが、その表示処理はフルーツを食べる処理実装の、さらに後になっていました。

これではプログラムが組めませんので、順番を入れ替えます。

あとはゲームプレイのリソースを Aさんとして、全てを上から繋げてしまいます。ゲームプレイ自体のリンク元は、共通部分の Aさん作業の最後である「予備日」とします。

さて、何か気が付きませんでしょうか。フルーツの登場の作業終了日が 2月4日なのに、ドットを食べる処理開始が 3月7日と離れています。無駄な待ち時間が発生していますよね。これは何が原因なのでしょうか。見ると、グループ親のパックマンには 62番と31番が、ドットを食べるタスクには73番がリンクされています。31番はすぐ上なので除外して、62番と73番が何なのか確認します。すると、72番のドットを食べる音の完成待ちということがわかります。

サウンドデータ作成の着手は、サウンドドライバとMMLコンバーターの完成を待たねば出来ません。また、サウンド開発の初頭にドットエサを食べる音の開発としても、2月18日と少し待たされてしまいます。この場合は仕方がないので、音を入れる作業を別枠で工数を用意して、作業のリンクを切ってしまいましょう。音のリンクを一旦全て削除します。71番以降がゲーム内の音なので、先行タスクの項目の数字を直接消していくのが早いと思います。

これで作業時間が連続しました。最後にBGMと効果音を入れる作業を追加して、効果音作成タスクの最後、79番からリンクをつなげればOKです。目玉が飛ぶ音は作業中に繋ぐ事もできるので、この辺りはプログラマと相談ですね。

---

• 作業負荷の偏りを平坦化する

これで予定としては最初の叩き台が出来ました。次に確認するのが Aさんと Bさんの作業負荷の偏りです。Aさんは最終作業が 4月8日となっています。一方、Bさんは 3月9日となっています。1ヶ月ほど差があるので、Aさんの作業から、比較的独立している作業を Bさんに置き換えます。目標は10営業日の移動です。ざっと見渡すと、「フルーツ登場と消去」「ステージクリア点滅」「ゲームオーバー」「BGMと効果音を入れる」辺りは作業を移管できそうです。繋ぎ変えてみます。

なんとまたしてもフルーツが足を引っ張ります。Aさんにとって、フルーツの表示は 2月7日までにほしいのに、Bさんの着手は3月10日と全然遅いのです。そこで、フルーツの表示をサウンドドライバの完成直後まで優先度を変えてしまいます。リンクをサウンドドライバ→フルーツ表示→MMLコンバーターと変えるのです。すると…

このように Aさんと Bさんの作業量は10日違いに収まりました。完成最終日も3月末と比較的納得出来る期間に収まっています。

---

• 着手日の見直し

さて、これで完成ではありません。最後にデザイン担当とサウンド担当の、作業着手日をぎりぎりまで後ろに延ばす算段をします。これは作業担当がよーいドンとする事による無駄を省く意味があります。

サウンド作業はMMLコンバーター完成待ちのため、ギリギリとなっていますが、画像制作は結構余裕があります。最も最初に使用されるアルファベットが、1月17日にあれば間に合いますので、58番のアルファベット開始を。その二日前に変更します。まず、タスクを自動から手動に切り替えます。

これで開始日を自由に変更できるようになります。現在の開始日 22/01/05(水)を 22/01/15 に変えて…みたところ、最終完成日が1日遅くなりました。なんでかなと理由を探ると、22/01/15とすると土日を挟んでしまうために、完成日が 22/01/17と1日待たされる結果となったためでした。そのため、開始日を22/01/13(木)にして問題解決しました。Microsoft Project はこのように自動で土日を回避する動作を行います。