プロジェクトの管理といえば、MS Projectだよねぇ、という声を聞いたり、聞かなかったり。ただ、実際には、ExcelでWBSを作って管理してしまうことも、多々あると思います。経験上、Excelのほうが「楽」と思われる原因は、次の点にあると思われます。

だれでも同じファイルを開くことができる (<=> MS Projectのライセンスは高い。たいてい、プロジェクト内の限られたひとしかインストールできない)
操作が原始的(Primitive)。直感で、スケジュールを表現することができる
好みの見た目(フォーマット、色使い)で、作成することができる (顧客によっては、提示する見本が、Excel WBSだったりする)

もっとも、Jiraとか、Scrum開発になると、そもそもWBSで管理するかというと、疑問ですが、せっかくですので、MS Projectの使い方をまとめてみます。
使い方、というよりも、How To色が強い記事になります。ここにある特徴をつかむと、Excel WBSには戻れなくなります(ハズ)。

基本操作

基本動作の設定

新しく作るタスクをデフォルトで、Autoに設定する、Manualに設定する、や、更新のたびに全体に波及させるのか、させないのか、という設定をします。

FILE->Option->Schedule

ここで、次のパラメータを必要に応じて、変更します

New tasks created: 新しいタスクを生成するとき、Autoに設定するかManualに設定するかのデフォルトを決めます
Auto scheduled tasks scheduled on: Auto Scheduleの場合は、日付が勝手に入ります。このとき、その日付を、プロジェクトの開始日にするか、今日にするかのデフォルトを決めます
Duration is entered in: 期間の単位を、日にするか、週などほかの単位にするか、デフォルトを決めます
Calculate project after each edit: 変更があるたびに、Auto Scheduleで、関連付けられているタスクの日付を変更するか、デフォルトを決めます

とくに、Calculate project after each editは、MS Projectがきらい、という人の原因を作っている設定です。「入力するたびに勝手に変わるので、わけがわからん」ということであれば、ここをOFFにして使うべきです。
見ての通り、当方も、ここはOFFにして利用しています。こうしないと、一連のタスクを変更して、最後に変化点を確認することができないからです。なお、ここをOFFにすると、F9を押すまで、更新されません。自分が確認したいタイミングでF9すれば、変化が見られます。

プロジェクト名称と開始日、報告日の設定

名称
FILE-> INFO -> Project Information --> Advanced Properties

プロジェクト名称は、Titleで設定します。

開始日・報告日
FILE-> INFO -> Start Date

日付は、Start Dateを押すと、プルダウン式のカレンダーが表示されるので、それで変更できます。
また、報告日("今日"の垂直線を引くのなら)は、Currentをプルダウンすると、変更できます。自動でずらしたくない場合は、ここで指定して、固定します。

Auto Schedule と Manual Scheduleの使い分け

使い分け、基本的考え方

それぞれの挙動に特徴があるので、なんとなくAuto、なんとなくManualという選択はしません。

Manual Schedule: 勝手に変わっては困るもの。たとえば、顧客要求日、各サブコンポーネントを結合する基準日、報告日など。
Auto Schedule: 実態を反映させるべきタスク。たとえば、コーディング期間、作業期間など。絶対日よりも、絶対機関が大事なもの。

まず、Manual Scheduleで、顧客要求日や、大事なマイルストーンを設定します。この情報は、あくまでの、ターゲットの設定に使います。実態は、Auto Scheduleのほうで見ます。Auto ScheduleとManual Scheduleに、位置関係の相違、つまり、間に合わないことがわかれば、そこは、MS Projectでエラーとして表示されます。

Manual Scheduleの勘所

基本、勝手に動かないので、入れたいパラメータを入力する。

動きがあるとすると、次のとおり

Start -> Durationで入力すると、Finishが自動で定義される
Start -> Finishで入力すると、Durationが自動で定義される

このため、Manualでも、自分のタスクのパラメータをいじると、値は変更されます。たとえば、Durationを変更すると、Finishが追従します。Finishを変更すると、Durationが変更されます。ただし、Autoと異なり、他のタスクの変更の影響は受けません。あくまでも、自分のタスク内での変化になります。

Auto Schduleの勘所

タスク単体の動きは、Manual Scheduleと同じです。Auto Scheduleの肝は、他のタスクとのつながりです。

期間(Duration)と前タスク(predecessor)を正しく定義することで、前後のタスクと、必要な期間を自動で考慮したスケジュールを作成することができます。

たとえば、プロジェクト初期に、初回のスケジュールを引く必要があるとしましょう。

顧客のマイルストーンがすでにあるとします。それに合わせて、社内の基準を作りますよね。その際は、一度Autoに切り替えて、顧客マイルストーンを参照させてしまうと、一発で、基準日を作ることができます。

まず、Durationと、Predecessorを設定します。

そして、F9を押し、一気に更新します。

再度、Manualとして固定したければ、Manualに直すこともできます。Predecessorは、残しても、残さなくても、お好みで。ガントチャートで、依存関係の線を引きたければ、Predecessorが必要です。

このように、基準となるタスクを起点に、predecessorとDurationを設定し、最後にF9を押すと、一気にスケジュールができます。

応用操作

複数の休日設定

ここでは、チームにより、異なる休日があるケースを考えます。たとえば、日米でプロジェクトを組むと、日本は、正月・ゴールデンウィーク・お盆、アメリカは、イースター・夏休み・クリスマス休暇が主な休みになるかと思います。

すべてのチームが、同じ拠点でしたら、デフォルトのカレンダーで、休みを登録すればよいのですが、ここの拠点で休日が違うと、どちらに寄せて管理するのは、プロジェクト管理が正確にできないので、よろしくないです。そこで、拠点にあったカレンダーの設定をしていきます。

PROJECT-->Change Working Time
ここで、カレンダー設定ができます。

マスターカレンダーの設定

Nameに、名称。Start/Finishに開始日、終了日を書きます。すると、その内容が、反映されます。

[反映前]

[反映後]

このケースでは、「俺の記念日」が2月に入ったので、全体として、1週間ずれたスケジュールへ更新されます。(Durationが優先されるので、Finishが後ろにずれます)

個別カレンダーの設定

マスターを変更すると、全部その影響を受けてしまします。これを避けるには、別途カレンダーを設定する必要があります。
先のPROJECT-->Change Working Timeから、Create New Calenderと操作します。

OKすると、新しいカレンダーが作成されます。そこへ、別の休暇を、Name/Start/Finishへ登録します。

これで、新しいカレンダーが作成されました。今回は、Module C用に作成したので、Module Cへ適用します。

タスクを選択したのち、Task->Informationで、タスクのプロパティを表示します。その後、Advancedにある、Calendarを変更します。

OKを押すと、そのタスクに新しいカレンダーが反映されます。

「俺の記念日」を1週間、「私の長期休暇」を2週間に設定したので、Module C (New calendar)は、他のタスクより、1週間長くなっています。

カレンダーのプロジェクト間連携

複数のプロジェクトを運営すると、マスターのカレンダーを作成して、それを横展したくなりますよね。その方法です。ちなみに、同じカレンダーだけでなく、いろいろな設定をマスターへ反映することができます。

File > Info > Organizer と進めていきます。

下のプルダウンに、いま開いているファイル(ここではProject1)と、マスターを保管しているGlobal.MPTが表示されています。こちらを選択することで、カレンダーの入れ替えができます。
たとえば、ここの表示内容でいえば、以下のように設定すれば、その方向でコピーできます。

Global.MPT > Project1
Project1 > Global.MPT

また、同じ名前であれば、上書きするか聞かれるので、連携させたければ、上書きを選択すればOKです。
これで、同じカレンダー属性を持つ人のプロジェクト間での管理が楽になります。

稼働割合の変更と稼働期間の変更

Resource Namesで担当者を選ぶことができます。そこに、[30%]などと稼働割合を追加することができます。これは、Task　InformationのResourcesからも設定できます。
デフォルトは、Task Type: Fixed Unitsになっているため、期間を設定したあと、稼働割合の変更した場合、稼働期間が変更されてしまいます。作業期間を絶対視したい場合は、この設定で良いです。
一方、期間を設定して、担当者をアサインしていき、その稼働状況を調整したい、という手順でプロジェクトを組み立てる場合、この動作は不適です。稼働情報を調整する([20%]など追加する)たびに、期間が変わってしまい、手動で元の期間に戻す必要があるためです。
これを避けるために、Task TypeをFixed Durationに変更する必要があります。これを行うことで、期間固定モードで動作します。なお、デフォルト設定を変更しても、すでに作られたタスクは、Fixed Unitsで作られている可能性が高いので、その場合は、タスクごとに変更していく必要があります。
(図はのちほど取得します)

[つづく]