プロジェクトスケジュール管理に真剣に向き合おうとしているあなたへ - 実践編 -
きんたろうです。ここではスケジュール管理を実践するための具体的な方法について説明します。Excel と Microsoft Projectを念頭に、その使い分け方から、スケジュールに必要な項目、ガントチャートを書く上での基本的な考え方などです。色々とやることは多いので、途中で挫折しないためにも、はじめに心がまえ編を読んだ上で読み進めることをおすすめします。
１．どのツールを使うか
最初に使うべきツールはExcel
スケジュールの作成には多くの人からの情報提供が必要です。情報を引き出すためには、そのハードルをできるだけ低くすることが重要であり、その点でExcelは普及していて、誰でも使い慣れているため、大きなメリットがあると言えます。
（１）誰でも操作に慣れていること
Microsoft Projectを初めて使う人にとっては、その操作大きな負担です。心構え編でお伝えしたように「基本計画の作成」という大きな山を越えるには、そのような負担を極力減らすのが賢明です。
これはプロジェクトメンバーが情報提供する際にも同様です。メンバーの負担を最小限にすることが、情報を集めるコツです。もしあなたがスケジュール管理タスクを他の人に引き継ぐ際にも、後任の人が使い慣れたツールであれば、スムーズな移行が可能です。
（２）特別なソフトウェアが必要ない、誰でも閲覧・編集が可能
Excelは業務用パソコンに標準搭載されているので、導入ハードルがありません。一方でMicrosoft Projectはサブスクリプション型では月数千円、オンプレミスでは１０万円以上します。会社で購入するソフトとしては決して高くはないですが、上司や関係者から決済が必要だったりと、導入までのハードルができてしまいます。情報提供をしてもらう部門が５つあったとすると、各部門で調整から決裁までの一連の作業が発生すると思うと、それだけで負担になってしまいます。
また Excel であれば共同編集も容易なので、各メンバーに直接ステータスをアップデートしてもらう方法もやりやすいでしょう。
（３）大量のステータス管理に向いていること
ExcelがMicrosoft Projectより優れている点として、ステータス管理が容易な点です。Microsoft Project は一連のタスクを時系列で管理するためのソフトウェアで、同時並行的に発生する大量のタスクのステータス管理には向いていません。
（例）とあるエンジンを組み立てるためには100個の部品が必要です。どれか一つでも欠けていれば組み立てができません。そのうち最も納期が長い部品の調達タスクはクリティカルパス（そのプロジェクトを完了するのに必要な期間を決める一連のタスクの流れ）となります。クリティカルパスに位置するタスクは、プロジェクトの中で最も重要なタスクとして重点的に管理されます。しかし、その他99個の部品においても、その一つでも欠けるとエンジンを組み立てることはできません。そのため、各部品に対して４つの管理ポイント（製造着手、品物の完成、検査完了、出荷）を置いて、そのステータスを管理しようと思います。これを Microsoft Projectで管理しようとすると、100部品に対して４つステータス管理となるので400行必要になります。それだけでガントチャートが煩雑になり、画面も重たくなり操作が負担となります。ステータスも頻繁にアップデートされるので、更新するのがだんだん嫌になってきます。
Excel を使うと100行4列の表に対して、完了した管理ポイントのセルを塗りつぶしていくだけでことが足ります。未完了のポイントは赤色にしておき、完了したポイントを青にする、このように色分けするとどこに問題があるか一目でつかめるようになります。これをヒートマップと呼びます。
Microsoft Projectを使うのは、プロジェクトがある程度長く、タスクの前後関係が複雑に絡む時
ではどういう場合に Microsoft Projectを使うのでしょうか。このツールのメリットは、（１） クリティカルパスを自動的に抽出してくれること、（２）スケジュールの変更が後続のタスクに自動的に反映されることです。この機能が活きる状況とは、プロジェクトがある程度の期間に及び（※）、スケジュールがタスクごとに細分化され、それらの前後関係が結びついている場合です。タスクが細分化されておらず、それぞれに前後関係がない場合は、Excel 管理の方が向いています。プロジェクトによってはそうゆうケースもあるので、Microsoft Projectを使うことに固執しないでください。繰り返しになりますが、Excel は誰でも使い慣れているという点で、大きなアドバンテージがあることを忘れないでください。
※プロジェクトの長さが半年程度あればMicrosoft Project を使う意味はありそうです。それよりも短ければExcel 管理やチーム内での進捗報告で共通認識は作れるでしょう。
※他のスケジュール管理ソフトについて
海外の巨大プラント建設や、旅客機エンジンの国際共同開発など、グローバルに展開している大規模プロジェクトでは、オラクルのPRIMAVERA P6が使われます。Microsoft Projectはタスクが数千行になると徐々に動作が不安定になってきます。また複数のプロジェクトファイルを作りそれらを相互リンクさせてスケジュールを作成することができますが、重すぎて使い物になりません。
スケジュール管理で最も重要なことは、スケジュールの一元管理です。一つのデータベースで一貫性をもって管理され、上流工程の変更は即座に下流工程へ反映されなければなりません。仮にスケジュール分けて管理したとすると、それらの同期に膨大な管理コストがかかります。またプロジェクトが進むにつれ次第に同期されなくなり、どちらのスケジュールが正しいのかわからなくなります。
巨大プロジェクトのスケジュールを構成するタスクは数千行、数万行に及び、これらをどこまでも一元管理できるようにしたのがPRIMAVERです。
ただし価格が高いことと（スタンドアローンで100万円を超す）、操作のとっつきにくさが導入のハードルになっています。使いこなすにはプロジェクトマネジメントの専門用語を理解する必要があり、操作の複雑さから選任のオペレーターをおくほどです。専門性の高いソフトなので、私が専任オペレーターを雇った際には月に１００万円ほどかかりました。
２．スケジュールに必要な要素
どのツールを使うかにかかわらず、スケジュール作成に必要な基本要素は以下の６つです。
（１）期限
（２）基本計画
（３）現状のスケジュール
（４）クリティカルパス
（５）現在の日付
（６）スケジュールのアップデート日
（１）期限
そのプロジェクトがいつまでに完了する必要があるのかスケジュールに記載します。当たり前のことに聞こえますが、実際に人が作ったスケジュールを見ると期限が記載されていないことが多いです。
もしあなたがスケジュールを引く時、左側のスタート日から線を引き始めませんか。その後、工程を順番に追い線を右へ伸ばしていき、最後の工程まで引き終わったところで、そこが完了日となります。多くの人は「これでスケジュールができた」と満足します。
ここで一旦立ち止まって、本来いつまでにこのプロジェクトを終わらせないといけなかったのか、俯瞰的に見られる人は少ないです。単にスケジュールを作成する作業者の視点から、プロジェクト全体を管理するマネージャーの視点が必要になります。
（２）基本計画
自分たちがこの計画でプロジェクトを遂行するんだという、コミットメントを表した計画です。プロジェクトをスタートした時の最初の計画が大元になりますが、基本計画は見直すことが重要であることを忘れないでください。
基本計画があることで、自分たちの現在位置を知ることができます。スケジュール管理を数ヶ月も継続すると分かりますが、現状だけを示したスケジュールは、自分たちの立ち位置を客観視するための基準がなく、予定に対して自分たちが遅れているのか、前倒しで進んでいるのかわからなくなります。スケジュール管理をしている本人なら、まだなんとか分かりますが、プロジェクトの他のメンバーや、ダイレクターレベル（役員レベル）と共通認識を作ることができません。現状と基本計画の差異をしっかりと見える化することで、自分たちの立ち位置を正しく認識し、具体的な短縮案の検討に入ることができます。
（３）現状のスケジュール
現在の状況を反映したスケジュールになります。ここで重要なことは、現状をありのままにスケジュールへ反映させることです。何かトラブルが起きて、スケジュールが大幅に遅れることが予想される場合には、そのままの反映してください。
遅れたスケジュールをありのまま反映し、周知することはとても勇気がいることです。管理者としては何とか短縮案を立てスケジュールに反映したい、そのうえで展開したい気持ちがあると思いますが、それをしていると展開がどんどん遅くなります。時間をかけて頭を捻った結果、なにも短縮案が立てられないとすると、今度は遅延リスクを周知するのが遅れ、周りに迷惑をかけることになります。
怖くても怒られることを覚悟して、現状のスケジュールを周知してください。その際には「短縮案を現在検討しています」と付け加えれば、周りの反応も多少は穏やかになります。遅れたスケジュールを周知した結果、炎上すればむしろ周りや上司が積極的に動くので、結果的に短縮案が早く見つかります。正直これができるかどうかが、プロジェクトを運営するものの資質のひとつだと思います。
（４）クリティカルパス
スケジュール管理の目的の一つはタスクに優先度をつけることです。優先度が最も高いタスクがクリティカルパスになるので、必ずハイライトし分かるようにします。プロジェクト全体でたくさんのタスクがある中、限られた時間で議論を集中させるためには、クリティカルパスを明確にすることが必要です。
スケジュールを分析した結果、クリティカルパスにならないタスクは、極端に言えば管理不要です。ただそこまで割り切らないのは、プロジェクトの進捗によってクリティカルパスに変わる可能性があるためです。
クリティカルパスを特定したら、少なくとも次点とさらにその次点となる第２，第３のクリティカルパスは特定しておきます。よく見るとそれぞれが数日しか変わらないことも多いです。第1のクリティカルパスばかりをフォローしていたら、全くノーマークだったアイテムが突如クリティカルパスとなり、そちらの対応が疎かになっていたため、完了期限に間に合わないということはよくあります。
（５）現在の日付
非常に重要なのですがよく忘れられる要素です。これが無いスケジュールとは、言い換えれば現在位置のわからない地図と同じです。すべての議論のスタート地点となるので、必ずハイライトしてください。
（６）スケジュールのアップデート日
そのスケジュールが何日付の情報でアップデートされたのか記載します。一か月前の情報に基づいてアップデートされていたとしたら、あまり役に立つスケジュールとは言えないでしょう。情報収集のタイムラグの都合上、仕方ないのであれば、その一か月間の間で起こった出来事や、判明したリスクを考慮に入れた上でスケジュールを眺めます。もちろん報告日付けでスケジュールがアップデートされているのが理想的ですが、末端から情報が上がってくるまでにタイムラグが発生するため、事実上不可能です。
刻一刻と変化する状況を考慮し、関係者に正しく状況を理解してもらうため、スケジュールのアップデート日は必要です。
３．スケジュールの引き方
スケジュールは右から左に引く。
必要な要素を理解した次はスケジュールの引き方を説明します。キーワードは｢スケジュールを右から左へ引く｣ことです。右というのはガントチャートの右側、完了日が記載されている部分です。左側は現在の日付です。まず始めに完了日を設定し、そこから線を引き始め、後工程から前工程に向かって工程を遡りながら線を伸ばしていきます。するとプロジェクトを開始すべき日が、現在の日付よりも前になってしまい、スケジュールが成り立たないはずです。もちろんこれでは説明できる資料にはなっていないですし、普通にスケジュールを作ることを考えれば、前工程から積み上げるので、この方法には違和感があると思います。
なぜこのような作り方をするのかというと、もともとの納期設定が前工程から積み上げて達成できるようになっていないためです。世の中のスピードが早くなり、顧客要求や他社との競争により、納期はどんどん短くなっています。また、そのような難しいプロジェクトだからこそ、スケジュール管理が必要になるといえるでしょう。完了日ありきのスケジュール作りとして、「右から左へ引く」ことになります。
補足：実働部隊から言わせると、そもそもそんな短い納期でとったことが間違いだ、契約時点からこのプロジェクトは崩壊しているんだと、営業に対し恨み節がある人もいるでしょう。ただその短納期を提示しなければ、そもそも仕事すら取れず、会社がいずれ無くなるでしょう。もちろん物理的に無理な納期であれば納期変更をしてもらう必要がありますが、その際には顧客から詳細なスケジュールの説明と短縮案の検討をまず迫られることになり、同時に時間だけは経っていき納期にせまっていくので、かなり厳しい交渉になるでしょう。
スケジュールを短縮する
右から左に引いた結果、今日の日付は本来スタートすべきだった日から遠く過ぎているので、これからスケジュールを無理やり短縮する作業に入ります。
はじめにやるのは贅肉落とし（Compression）
各工程を細かくチェックして、余裕のあるタスクの期間を徹底的にそぎ落とします。タスクの余裕のことをバッファーと呼びます。各部門から必要期間を集めると、必ずバッファーが入った期間を出してくるので、最初からバッファーを入れないように指示しておきます。「順調にいかなかった場合に備えて」という気持ちは捨ててもらい、全て順調に進んだことを前提に必要期間を出してもらいます。これをしないとどういうことになるかと言うと、必要期間が永久に伸びはじめ、完了日に収めることが不可能になります。ただ、どんなに釘をさしたところで、それでもバッファーを積んだスケジュールは出てくるので、完全に取り除くことはできないと思ってください。
バッファー（余裕）に対する考え方
スケジュール管理をしながら各ステークホルダー（社内の各部門であったり顧客や協力会社など）と調整をしていく中で気づくのは、結局スケジュール調整とは「誰の工程にバッファーを置くか」という議論だと気が付きます。厳しいデッドラインの中で、誰でも自分の担当する作業に対してバッファーは持ちたいので、その譲り合いになります。
例えば、客先からの厳しい要求納期に対して、各部門のメンバーが集まりスケジュール短縮案を相談しているとします。各部門のスケジュールにバッファーは持っておらず、どう検討しても要求納期に間に合わせることができません。客先に納期の延長を要請しましたが、同意してもらえませんでした。この時、バッファーを移動させる考え方を持っていると、客先との相談ももう少し具体的になってきます。製品の納入後の客先での後工程について話をして、そこでのバッファーをこちら側に移動させてくれないかと、提案することができます。こうすることで客先の担当者は、彼らの後工程の関連部署に対して具体的に相談を持っていくことができます。もちろん客先との関係性によってはこのような相談が難しいこともあります。ただ、本当に納期遅延のリスクが見えているのであれば、事前にできる対策をとって関係者の共通認識にしておくことは、リスク低減につながります。
上でも述べましたがバッファを完全に取りきることはできません。誰しもが保身のために、どこかバッファーを隠し持っています。ですので、もし後からバッファーがあることが分かっても、それは当然にことなので、相手を責めるようなことはしないでください。基本計画を作っているときに厳しい調整を行い、なんとか納期に間に合うスケジュールを作った側からすると、「なぜあの時に教えてくれなかったのか！」という気持ちにもなります。より厳しいスケジュールを出した部門からしても、「我々は休日返上で計画していたのに！」と反発もあるでしょう。その気持ちは一旦おさめて、隠していたバッファーを出してくれたことに感謝しましょう。
次はリスクと前提条件をつけて、スケジュールを短縮
贅肉落として多少は短くなりましたが、まだ完了日には到底及びません。ここからは各部門から短縮案をひねり出してもらうことになりますが、ただ短縮案を出せと言うだけではまず案は出てきません。聞き方として、「短縮するためにはどのような前提条件の必要なのか」、「短縮することでどのようなリスクが発生するのか」とします。
例として家を建てるスケジュールを想像してみてください。まずはじめに基礎工事（必要期間：１か月）があり、次に柱や梁といった構造部材を組み立て（１か月）、続いて壁や屋根（１か月）、内装工事（１か月）へと移っていきます。これらのタスクの必要期間を単純に積み上げると、合計４か月かかりますが、短縮案として「基礎を４セクションに分け完了したセクションから構造部材の組立てにとりかかる」案を採用しましょう。すると必要期間が０．５か月づつオーバーラップし、基礎と構造部材で必要期間１．５か月となり、合計３．５か月で工事を完了することができます。ただし同時にリスクをかかえることになり、基礎のコンクリートが固まっていないのに柱を立てて基礎が崩れるなど、問題が発生する可能性があります。そのリスクを低減するため、基礎工事進捗の管理密度を上げる、など対策を立てる必要があるのです。また前提条件として、柱を梁が事前に組みあがった状態で建設現場に到着すれば、構造部材の組立は２週間に短縮できるなどです。
短縮案を考える際は、既定の枠にとらわれず柔軟な発想をした方がいいでしょう。元々厳しい納期であることは顧客も理解していますし、一度契約すればそれはプロジェクトを成功させるための運命共同体です。顧客にとって一番恐ろしいのは、プロジェクトの途中で発注先を変えること（転注）です。必要によっては契約の枠の外に飛び出して、顧客に対し様々なオプションを提示するのが、デキるプロジェクトマネージャーです。
リスクと前提条件対し対策をたてる
スケジュールは何とか収めることができましたが、それを達成するにはたくさんのリスクと前提条件が必要なことがわかりました。それぞれに対し対策を練った上で、その実行計画を立てて、さらにスケジュールへ反映する必要があります。
上であげた短縮案「柱を梁の事前組み立て」を例に考えると、どこか工場を見つけ柱と梁を組み立ててもらいます。図面の作成～工場の選定～発注～製造～現場までの輸送、といった一連の作業は、現場で構造工事が始まる前に完了していなければなりません。それが間に合わない場合、さらに対応策を考え（工場に特急価格で発注するなど）採用します。このようにして、元々あったスケジュールに対しリスクと対応策のスケジュールが追加され、これがさらに繰り返されることで、スケジュールはどんどん複雑化していきます。
基準計画の設定
基本計画が完成したら、MS projectの機能で「基準計画に設定」があるので、これを設定します。フォローアップの段階でスケジュールが変更になったとしても、この基準計画が残るので、いつでも自分たちの立ち位置（計画通りか遅れているのか）を把握することができます。
４．進捗のフォローアップの仕方
ほとんどのプロジェクトはスケジュール通りにいきません。遅れます。また進捗に応じて外部要因も変わったりするので、その都度スケジュールに反映しプロジェクトのメンバーとは共通認識をアップデートしてく必要があります。これを疎かにすると、せっかく苦労して作ったスケジュールは誰も見なくなりますし、自分たちが遅れているのか進んでいるのかわからず、スケジュールが無かった頃の混乱に再び戻ることになります。各部署より進捗情報を集めて、スケジュールを最新に更新することはとても大変なことですが、せっかく苦労して作った基本計画を無駄にしないためにも、ここは頑張りましょう。
スケジュールを更新する目的
スケジュールの更新し配布するのは、最新状況を関係者に周知することの他に、その変更をプロジェクトの公式なものとして織り込む意思表示の意味があります。例えば製造部門の担当者から、以下のような相談を受けたとしましょう。
「作業者が慶弔休暇に入っていしまったので、作業完了が一週間ほど遅れるかもしれない」
このような相談を受けてすぐにスケジュールへ反映しては、プロジェクトが立ち行かなくなります。まずは自部門内で後れをカバーできないか検討を依頼するなど、スケジュール管理者と担当者の間でやりとりが発生し、場合によっては製造部門内で調整する時間が必要になるでしょう。その間、この遅れはリスクとしては認識されていますが、遅れが影響する後続部門にとっては、作業計画をたてる際に製造部門の遅れを織り込んむべきかどうか迷うはずです。遅れるなら遅れるで早めに言ってほしいというのが本音でしょう。
この時に共通認識となるのがスケジュールです。製造部門での検討の結果、どうしても遅れが発生するという結論に至ったとき、はじめてスケジュールへと反映し全体へ配布します。これを受けた検査部門はもちろん、さらに後続にあたる梱包・出荷部門においても、製造部門の遅れを織り込んだ上で作業計画をしなおすトリガーとなるのです。
スケジュールを見れば誰しもがいまの最新状況を知ることができ、また複雑な状況においても各部門が共通認識を取ることができるようになります。
スケジュールのフォローアップと更新頻度
プロジェクトの長さにもよりますが、２週間か１か月に一度は、スケジュール全体の見直しを行い、関係者に配布するのが妥当だと思います。情報を集める時間を考えると、毎日更新するのはほぼ不可能で、一週間おきであっても、情報集めとスケジュールの更新作業に追われることになり徒労に感じるでしょう。頻度をあげても２週間が限度だと思います。プロジェクトの状況が大きく変わりスケジュールに影響がある場合は、臨時的に更新しすぐに関係者へ配布しましょう。
更新にあたって各メンバーへ進捗状況のフォローアップが必要になります。頻度については、各タスクのリスクレベルに合わせてメリハリをつけたフォローアップをするほうが、担当者も取りまとめる方も少ない負担で効率的な情報収集ができるでしょう。
例えばプロジェクトが設計段階にあるとしましょう。その時スケジュールのフォローアップ頻度は、設計部門のフォローアップを週に一回、製造部門のフォローアップは二週間に一回とする。さらに設計が最終段階に入り、出図日がせまっている時にはフォローアップ頻度を火曜日と木曜日の週二回にするなど、臨機応変な対応が必要です。
プロジェクトを推進する人にとって、フォローアップ頻度を柔軟に使い分けられることは必要な能力です。スケジュールが遅れており納期がせまっているなど、緊急性が高い時にはデイリーフォローアップを行うことも視野に入れます。これはフォローアップする側、される側ともに負担は大きいですが、プロジェクトを確実にかつスピーディーに進めることができます。またこのデイリーフォローアップが念頭にあると、フォローされる側はそれを逃れるために事前策を打ってハイリスクな状況を作り出さない、という動機も生まれるので、プロジェクトへの良いカンフル剤としても作用します。
目安として、月１フォロー、隔週フォロー、週１フォロー、週２フォロー、毎日フォロー、このあたりをリスクレベルに合わせて柔軟に使いこなせると良いと思います。
週１フォロー、週２フォローはどの曜日をフォロー日にするかはとても重要です。お勧めは火曜日 or 木曜日。月曜は休日明けで担当者側の情報整理が十分ではない可能性があります。金曜だとそこで発覚した問題への対応が週明け月曜日になる可能性が高く、週末を挟むと緊張感が緩んでしまい対応が遅れる可能性がある。週１フォローの場合は水曜日という選択もあるでしょうが、週２フォローの場合、水曜日をフォロー日とした時にもう一日が月曜か金曜になるので、上記理由から好ましくない。よって候補日は火曜日 or 木曜日となります。
フォローアップ頻度とタスクの期間について
各タスクの必要期間はフォローアップ頻度と重要な関係があります。フォローアップ頻度を週一とした場合、各タスクの必要期間は長くても二週間未満としましょう。それよりも長いタスクについては、もう少し細かく分割してタスク一つあたり期間を短くしてやります。
例えば、あるタスクの開始日が１０月１日、完了日が２１日の、必要期間３週間のタスクがあるとします。週一フォローアップ会議のタイミングが１０月２日、９日、１６日、２３日とあったとして、それぞれの会議での担当者からの報告内容は、よほどしっかりと状況を把握している担当者じゃないかぎりおおかた予想できます。
２日報告「作業にとりかかったところです」
９日「特に問題ありません」
１６日「特に問題ありません」
２３日「すいません、遅れておりまだ完了していません」
１０月２日のタイミングはその前日に作業着手しているはずなので、フォローする側としても「作業には着手していますか？」と聞けばよいです。担当者の答えがあやふやであれば確認依頼することで、万が一作業着手していない場合でも、その状況を把握することができます。一方で９日と１６日の報告では、フォローする側としても打ち返す言葉がありません。そして多くの場合は末端の作業者から担当者に対し報告が上がっておらず、担当者は特に報告が無いという事は問題が無いんだろう、という消極的な管理に陥っている可能性が高いです。さて２３日の会議に備え担当者もようやく作業者へヒアリングに行くと、実は問題が発生しておりまだ作業が完了していないことを知り、結果としてこのような報告となるのです。
これを避けるためには３週間のタスクの中で、観測可能なチェックポイントを設けて、そこでタスクを分割します。例えばこれが製品の寸法検査工程だとすると、寸法測定に一週間、判定作業に１週間、検査レポートのまとめに一週間といった具合に３週間の工程をバラシておきます。すると会議での報告も変わり、
９日報告「寸法計測が完了しました」
１６日報告「判定作業中に図面の定義が明確じゃない部分があり停滞しています」
例え担当者からこのように具体的な報告が無かったとしても、こちらから質問し「寸法測定は完了しましたか？」「判定作業は完了しましたか？」とガントチャートを見ながら質問することで、問題を顕在化させることができます。このように１６日の段階で遅れをキャッチすることができ、設計との打ち合わせを至急実施するよう指示することができます。２３日時点で気づいたのでは対応が一週間遅れることになりました。
しっかりと仕事をする人からすると、そんな担当者は怠慢じゃないか、と思われるかもしれません。しかしプロジェクトにかかわる人全員が優秀なわけではありません。むしろ特定の分野の専門家でありながら、マネジメント能力まで持ち合わせている人の方が稀有な存在です。そこを補完しプロジェクトをスムーズに進めるためのが我々プロジェクト屋の役割です。
スケジュール会議の設定
担当するタスクがクリティカルパス上にある関係者の間では、頻繁にスケジュール調整が必要になってきます。特にスケジュールの短縮検討や、その実行段階においては、綿密なコミュニケーションが必要になるので、定期的な対面会議をする方が効率的ですし、タイムリーにリスクを管理しながらプロジェクトを進めることができます。
この時MS projectの操作に慣れたスケジュール管理者が一緒に入って調整すると、その場で各人の意見を反映させて試行錯誤しながらスケジュールを組み立てられます。様々な短縮案を検討していくと、各担当者毎では気がつくことができなかったクリティカルパスが浮き上がってきて、より本質的な議論となりスケジュール短縮につなげることができます。
このようにその場で意見を出しながら、あーでもないこーでもないと検討する際の人数は３－４人がベストです、多くても５人です。人数が多すぎると、特定の人からしか意見が出なくなるので、この程度に人数をおさえます。
私はこの会議が一番好きです。主要なメンバーが集まり喧々囂々と意見を交換しながら、スケジュール短縮に向け前向きな議論を進めていきます。最後におさまるスケジュールになった時には充実感があります。参加者を部内調整もできるキーパーソンを参集して、その間を調整することはとても楽しいです。
基準計画の見直し
プロジェクトが進んでいくと基準計画との乖離が大きくなっていきます。何度も言ってますがスケジュールは遅れるものなので仕方がないです。迷走しないためには、自分たちの現在位置を基準計画からの距離をはかって確認する必要がありますが、その距離が遠くなるほど「この距離をはかることに意味があるのか」と疑問に思ってくるはずです。基準計画から８週間（約２か月）遅れだったものが、翌週の報告では９週間遅れになっていても、遅れの規模感としては大差がなく、議論がおざなりになりがちです。また到底短縮不可能な遅れを目の前にすると、議論が具体化しません。
それよりも８週間の遅れを一度基準計画に受け入れて新たなターゲットとして設定した方が、１週間の遅れが際立ったものとなり、一週間を縮めるための具体的な議論をすることができます。
当初立てた計画を死守することは大切ですが、短縮のための議論が意味のないものになってはスケジュールの意味がありません。そういう時には基準計画の見直しを行い、再スタートを切りましょう。
５．対外的なスケジュールの出し方
上記で述べているスケジュールはあくまで社内での管理用のスケジュールになります。それをそのまま社外に出しては取引先へ不要な混乱を招く恐れがあるので、社内用とは別に対外向けスケジュールを用意する必要があります。
例えば、社内スケジュールの調整の結果、出荷日が予定よりも一週間早めることができそうだとします。この喜ばしいニュースをそのまま取引先に伝えると、早まった出荷日を前提に取引先も社内調整を進める可能性があります。ここは社外の組織に関する部分なのでコントロールすることができません。実際に進捗してみると他のトラブルが起きて、早まった予定日を達成できない時に、取引先からクレームを受ける事態になりかねません。もちろん契約納期通りに納入した我々が、そんなクレームを言われる筋合いはないのですが、やはり取引先内での混乱の元となるので、安易に早まった計画を出すべきではないです。余裕が出たスケジュールは、何かあった時のバッファーとして社内で持っていましょう。
逆にスケジュールから遅れる場合を考えてみましょう。基本的には取引先との契約納期があるはずなので、遅れを挽回できないか、社内で対策を検討するべきでしょう。検討している間、社内では後れを考慮したスケジュールで進めますが（遅れをプロジェクトの公式な認識として織り込むため）、取引先に対しては遅れを知らせるべきかどうか熟慮が必要で、これはプロジェクトの状況や、客先との関係性によって個別に判断されるものです。合理的で理性的な判断を下せる取引先であれば、基本的には遅れがわかった段階ですぐに連絡する方が、相手との信頼関係を築くことができるので、その後のプロジェクト運営も楽になります。ガントチャートを動かすのではなく、注記によってリスクをハイライトするか、別途リスクや前提条件のリストがあれば、そこに追記し知らせる形が良いでしょう。ガントチャートに織り込むのは、取引先との間でその遅れ受け入れる合意した時です。
このように見ていくと、プロジェクトが進捗していくと、社内用と対外用の二つのスケジュールが存在することに気がつきます。さらに対外用においても、客先、協業パートナー、サプライヤーと社外関係者が多岐にわたった場合に、誰にどのスケジュールを連絡したのかがわからなくなる、という事態は避けなければなりません。このコミュニケーションを管理するためには、社内スケジュールをしっかりと管理することです。それを全ての基準として、対外的に発信したスケジュールについては、それぞれの差分を管理します。例えば、客先に対しては+２週間のバッファーを積んで連絡する、協業パートナーとは社内スケジュールそのままを連絡、サプライヤーには少し前倒しのスケジュールを要求日として連絡する、といった具合です。
一見大変なようですが、対外用スケジュールは社内用から詳細部を省いたものになるので、多少は管理負担は軽くなるはずです。
テクニックとして、取引先へ提示するスケジュールについては、エクセルのオートシェイプで作ったガントチャートを提出することをおすすめします。MS projectだと１日単位でSpecificな日程がわかってしまうので、少しでも日程がずれると客先から突っ込まれるポイントとなり、その説明に余計なリソースを割かれてしまいます。前工程で１日、２日遅れたところで、後工程で縮めればよいとあなたが考えていても、なぜ遅れたのかと執拗に聞いてくる取引先がいるものです。スケジュールの内容を理解せずに、マシンのようにドキュメントの差分をチェックすることに固執する人がいるのです。
その点エクセルのオートシェイプだと、線が多少ずれたとしてもそれに文句を言う人はいません。マウスでピクセル単位でずらせるので、実態に合わせた多少の修正をしつつも、突っ込まれないということが可能です。
６．MS Projectを使うときのテクニック
ここではMS Projectを使う上でのテクニックを紹介します。スケジュール管理には大変な労力が必要となるので、途中で挫折せず継続するためにも、いかに楽に管理できるかが一つのカギとなります。MS Projectはそのためのツールとして有効です。さらにその使い方のコツが分かれば、スケジュール管理が非常に楽になるのでその紹介をします。
機能行を追加しクリティカルパスを分析する
MS Projectにはクリティカルパスを自動的にハイライトする機能がありますが、これはそのスケジュールに記載されているタスクのうち、最も遅いタスクに紐づけられたタスクの、一連の流れのみをハイライトします。
プロジェクトが異なればMS Projectファイルを分けて管理するのが基本的な使い方ですが、複数のプロジェクトの進捗を横ならべで比較したり、プロジェクト間で共通リソースを使うなど、相互関係が生じる場合は一つのProjectファイルで管理するほうが操作が楽です。ファイルを複数に分けて行き来しながら作業することはとても煩わしいです。
（例）設計部門の３名が、それぞれ納期の異なる５つの部品について、設計作業を進めているとしましょう。出図納期の早いものから順に作業に取り掛かりましたが、そのうちの一つはシステム全体の性能設計に影響を及ぼすため、取引先のエンジニアによる技術検討が必要となりました。その間、我々の作業は手待ちとなってしまい、出図スケジュールへの影響もありそうです。取り急ぎ他の部品の設計を進めたいと思います。
そのころ製造部門では、予定されてい出図日と製品納期に基づき、製造準備を進めていました。設計部門から出図遅れの連絡を受けたことで、製造準備スケジュールの調整が必要になりました。出図が遅れる部品の代わりに、他部品の製造準備を先行して進めることで、納期への影響は最小限にできそうです。プロジェクトエンジニアが間に入り、どの部品の出図作業を優先的に進めるか調整を行いました。
部品ごとに納期が設定されスケジュールがあるものの、そのリソースを共有しながら作業を進める場合、各部品のスケジュールが同一ファイルにあると調整がやりやすいです。もしこれを別のProjectファイルに分けて管理していた場合、それぞれのファイルを開くだけでPCが重くなり、ウィンドウを切り替えて操作しているうちに、どの部品のスケジュールをいじっているのかわからなくなってしまいます。
一つのProjectファイルに記載した複数の部品のクリティカルパスを見るためには、タスクの記述方法を少し工夫します。スケジュールを構成する各タスクとは別に、「クリティカルパス抽出用タスク」を追加しておきます（私は最下行に追加します）。このタスクの期間を1,000日と設定し（なんでもいいので大きな数字）、これを各部品のスケジュールの最後のタスクに後続タスクとして接続すると、その部品のクリティカルパスがハイライトされます。このような本来のタスクとは別に追加したタスクのことを「機能行」と呼んでいます。
例えば５つの部品があるとしたら、最下行に機能行を５つ追加します。それぞれの先行タスクを、各部品のスケジュールの最後に接続しておきます。各部品のクリティカルパスを検討する際は、該当する機能行の期間を1,000日に変更すれば、部品ごとのスケジュールのクリティカルパスがハイライトされます。
複数の検討ケースに対し一律で変更を加えたい
スケジュールの短縮案を検討する場合や、シナリオ毎のケーススタディをする場合は、オリジナルのスケジュールと並べて比較しながら検討するのが便利です。オリジナルスケジュールをコピーしてタスク末尾に貼り付けて、コピースケジュールを編集しながら、オリジナルとの比較検討します。
これの良いところは複数ケースに対して一律に変更を加えたい場合、例えば輸送期間を3日から5日に変更したいとします。タスク名の「輸送」でソートをかけることで、そのタスクのみが抽出されるので、それぞれの行の期間を変更してやればOKです。
また同じファイルであれば、複数ケースの同一タスクに対し同じ変更をかける場合でも、タスク名でソートすることで編集が非常に簡単です。これが別ファイルだと、反映に漏れがでたり、同一条件でスケジュールを比較検討できないなど、混乱の元となります。
マイルストーン行を作る
タスクが多くなってくると、スケジュール上重要なマイルストーンを、一つの画面内で同時に俯瞰することが難しくなってきます。
これを解決するには、スケジュールの上部にマイルストーンをまとめる欄を作っておきます。そこにマイルストーン（期間は０）を追加しておき、詳細スケジュールのタスク行から、後続タスクでつないでおきます。
詳細スケジュールを作る際には、設計（１ヶ月）→製造（２ヶ月）→検査（２週間）→出荷（１週間）、とタスクを積み重ねて作っていくはずです。これに対して例えば「製造完了」というマイルストーンを取り出す場合、製造タスクの後続FSとしてつなげばOKです。「製造開始」を取り出すときはどうでしょうか、このときは製造タスクに対して後続タスクStart-Startがおすすめです。一つ前のタスク「設計」に対し、後続FSでとってマイルストーンを取得することも考えられますが、複数タスクとの間で接続関係がある場合この方法は取れません。
各タスクの前後に「開始」「終了」のマイルストーンタスクを追加して、それを参照するのでもよいですが、タスク行が増えることになるのでおすすめしません。
全体表示
MS projectを使っていて以外とやりにくいのが、ガントチャートの拡大縮小です。ある程度スケジュールが組み上がった状態で、タスクを行き来しながら編集する際に使います。
通常であればガントチャート部分をクリックしてマウスホイールで操作するか、ウィンドウ右下にあるスライドバーで操作するかのいずれかでしょう。いずれもマウス操作が必要になるので作業の手を止めてしまいます。
ここで紹介するのは「選択したタスクの拡大/縮小」です。これをクイックアクセスツールバーに追加しておき、注目したいタスクを選択した上で、alt + 2（ツールバーの左から二番目に入れている場合）とキーを押すと、把握したいガントチャートを一目で見ることができます。サマリータスクを選択した状態でこの操作をするのもいいです。サマリータスク以下に紐づいているタスクのガントチャートがすべて見ることができます。また、あまり細かいことは考えずにシフトとカーソルキーで適当にタスクを選択して、alt + 2と押してもほぼ希望する範囲のガントチャートを見られるはずです。スケジュール全体を見たいときは、タスクを全選択（タスクIDと列名が交差する部分をクリックですべてのタスクを選択できます）したうえで同様の操作をします。
オートシェイプの活用
MS projectにはガントチャートにオートシェイプを追加する機能があります。配置する場所を、日付やタスクを起点とすることができるので、ガントチャートへのアノテーションの追加に便利です。
スケジュールに必要な要素として挙げた「現在の日付」を示すために、赤線のオートシェイプで作成し位置情報として本日の日付を指定すると、見やすいガントチャートになります。同様にプロジェクトのデッドラインなど重要な日付も線で示すのがわかりやすいでしょう。
スケジュールの一部が作成途中ということもあるので、その場合該当部分をオートシェイプ四角で囲み、ハッチングするなどすれば、見ている人にもわかりやすいです。
「資料は見た目よりも中身が重要」と言いたいところですが、思っている以上に見た目は重要です。資料作成者（特に若い人）にしてみれば、「資料をキレイにするのは時間の無駄」、「内容は読めばわかること」、こう捉えがちです（私もそうでした）。
ここには資料の作り手には想像もつかない読み手側の都合があります。それは「資料を見せる人はそもそも資料を読む気がない、やる気がない」「若い人に比べて頭の回転が遅い」「目が悪くなっている」。このような読み手にとっては、文字を追っていくのも大変なので「見える化せよ」「簡潔にまとめろ」「要点はなにか？」となるわけです。
まわりを巻き込んで組織を動かそうと思っているプロジェクトマネージャーであれば、資料を見やすく丁寧に作ることは、長期的には自分の仕事を楽にすることができます。
ショートカット
スケジュール管理を継続していく一つのコツは、MS projectをストレスなく操作できることです。そのためには頻繁に使用する操作のショートカットを覚えておくことが重要なので、以下に紹介します。
（１）タスクの削除、キーボードのプロパティキー → D
（２）タスクの追加、Insertキー
上級ショートカットキー
キーボード操作を劇的に楽にするAutoHotkeyというプログラムがあります。アプリケーション上で設定されていないショートカットも、このプログラムにより無理やりショートカットキーを割り当てることができます。解説ページはいくつもありますので、一つ紹介しておきます。
私が設定しているショートカットは「サブタスクの表示/非表示」と「基本計画の設定」です。それぞれCtrlキーと数字（１，２，３）の組み合わせで機能するようにしています。アクティブなウィンドウ名を判別してプログラムが走るように設定できるので、ショートカットキーの競合も避けることができます。参考までコードを記載しておきます。
サブタスクの表示（Ctrl + 1）
#NoTrayIcon
SetTitleMatchMode RegEx
#IfWinActive .*Project Standard
^1:: Send !wost
#IfWinActiveサブタスクの非表示（Ctrl + 2）
#NoTrayIcon
SetTitleMatchMode RegEx
#IfWinActive .*Project Standard
^2:: Send !wosh
#IfWinActive選択しているタスクの基準計画への反映（Ctrl + 3）
#NoTrayIcon
SetTitleMatchMode RegEx
#IfWinActive .*Project Standard
^3:: Send !rbs{tab}{tab}{down}{Enter}y
#IfWinActive７．終わりに
この記事を最後まで読んでいただきありがとうございます。スケジュール管理はとても重たい仕事ですが、プロジェクトのメンバーが最も必要とする情報の一つです。プロジェクトマネジメントを任されて、何をやったらいいかわからないというときには、まずはスケジュール管理からやってみると良いかもしれません。この記事の読者の方であれば、そこから派生してもっとこういうことも必要だと、経験のなかで気がついていくはずです。そうなった時にはスケジュール管理は別の人に引き継いだ上で、他の仕事にシフトしていけばいいと思います。シフト先には、リスク管理、コミュニケーション管理、ステークホルダー管理があり、プロジェクトマネジャーの能力としてリーダーシップやコミュニケーションスキルといったソフトスキルが最も重要であることに気がつくはずです。
編集履歴：
2023/03/14 初版発行