IT関係のプロジェクトに限らず、プロジェクト発足からやることというのは、ある程度の定石があります。ここではプロジェクトが発足してからやるべきことを5つのステップに分けて解説します。
プロジェクト発足理由の認識合わせ
プロジェクトというのは、ある課題を解決するために期間限定の専門チームを立ち上げ、その解決に向けてチーム一丸となって取り組む活動のことを指します。
つまりプロジェクト発足には必ず理由があるはずです。1番最初にやるべきステップはプロジェクト発足の理由をメンバー全員で認識を合わせておくことです。
プロジェクト発足の理由を確認するうえで、必ず押さえておくべき3つの項目があります。それは「背景」「目的」「スコープ」の3つです。
背景というのは課題そのものです。例えば以下のような事例です。
- システムが老朽化しており、来年システムのサポート期間が終わってしまう
- 従業員が増え給与計算に多大な時間がかかっている
- 経営情報の収集にリアルタイム性がなく、意思決定が素早く出来ない
対して目的は、背景の裏返しです。よく間違えられるのが手段を目的としてしまっているケースです。
例えば、システムのサポート期限が切れると言った課題の場合は目的を「新システムの導入」にしても差し支えありませんが、経営情報のリアルタイム性が無いと言う背景で発足したプロジェクトの目的が「システムを導入し、リアルタイム性を実現する」と言うのは間違っています。
理由はシステムを導入することで本当にリアルタイム性が得られるのか（=真の目的が達成されるのか）分からないためです。
そもそもの業務のスピードが遅い場合はシステムへの登録も遅くなり、結果的にリアルタイム性も中途半端なものになる可能性があります。
リアルタイム性を実現するために何が必要かを洗い出し、その中の1つにシステム導入があると言った形が理想です。
また、目的を記載するときはより詳細に書くことも重要です。上記の例で言えば、何をもってリアルタイム性があると言えるのかをより細かく明記することで、メンバーの認識もぶれず、プロジェクトを進めやすくなります。
なぜこのようなことを言ってるかというと、プロジェクトは大なり小なり判断の連続です。この判断を正しく行うためには目的に立ち返り、達成させるためには何が最適かという基準をメンバー全員が持っておくことが大切です。
次に確認するべきはプロジェクトが対象とするスコープです。リアルタイム性と一口に言ってもあらゆる業務があるため、どこの範囲のことを言っているのかを明確にする必要があります。
このスコープも関係者全員で認識合わせをしておかないと、後々やる・やらない論争に陥り余計な工数がかかる原因になります。
また、スコープが定まっていないと、このあと説明する工程決めができず、プロジェクトが前に進みませんので、必ず最初に全員で認識を合わせておきましょう。
工程の検討
続いて行うべきは目的を達成するための工程（プロセス）の検討です。
システム導入プロジェクトは、いくつかの「段階（フェーズ）」で分けられます。さらにそのフェーズは「工程（プロセス）」に分解できます。
長期間にわたるようなシステム導入プロジェクトは、全ての工程を最初に決めることはできないため、フェーズごとに目的を設定し、その目的を達成するための工程を検討します。
工程決定の流れは以下のようなイメージです。
- プロジェクト全体をフェーズ単位に分解
- フェーズ単位の目的設定
- フェーズ単位の工程検討
- 工程の決定・合意
システム導入プロジェクトの代表的な開発手法である、ウォーターフォールモデルの各フェーズについては以下の記事で解説しています。
体制・役割の検討
工程がある程度定ったら、次は体制と役割の検討です。
そのプロジェクトには何人の人が参画できるのかを、自社の予算やプロジェクト以外の業務量などの制約条件を考慮し、決めていきます。
参画可能な人が決まったら、その人たちの役割を検討していきます。プロジェクトは常設されている部門とは異なり、期間限定の専門チームになるため、そのプロジェクト内での役割を1人1人に割り当てていきます。
スケジュールを先に決め、そのスケジュールに間に合うように要員を確保するという順番で進めていく場合がありますが、あまりお勧めしません。理由はプロジェクト全体の品質が悪くなる傾向にあるためです。
プロジェクトには必ず納期があります。この納期は、どれだけ人が集められるのか、その人たちはどんなスキルがあるのかなどを見定めてから決めるようにしないと、無理なスケジュールを設定してしまい、スキルアンマッチでも人をとにかく参画させようとします。結果、予定していた納期に間に合わない上、品質が悪く最初からやり直さざるを得ない状況になるプロジェクトも中にはあります。
とは言え納期は重要な要素ですから、体制とスケジュールは並行して検討し、両方の視点で無理のない計画を策定することが事が最も望ましい形と言えます。
マスタースケジュール・WBSの検討
目的を達成するための工程と体制・役割が決まったら次はマスタースケジュールの検討です。
マスタースケジュールとはプロジェクトの最初から最後までを見通した、スケジュールの全体像を示すものです。
マスタースケジュールは小・中規模プロジェクトと大規模プロジェクトでは作り方が若干異なりますが、基本的にはフェーズごともしくは大工程ごとに実現可能な期間を設定して策定していきます。
マスタースケジュールを策定する上で、共通的に言えるポイントは以下の通りです。
- スライド1枚でまとめる
- マイルストーンを設定する
- 関係者全員で認識合わせをする
効果的なマスタースケジュールの作り方や上記のポイントについては以下で説明しています。
マスタースケジュールの策定が終わったら続いてWBSの作成に移ります。
WBSはwork breakdown structureの略ですが、マスタースケジュールに示された大工程をさらにブレイクダウンして成果物作成の単位に落としていきます。
WBSにはそれぞれのタスクの開始予定日や終了予定日、担当者、想定成果物を記載していきます。
そして、日々の進捗管理にはこのWBSを使いメンバーのタスクを管理していきます。マスタースケジュールはあくまで全体を俯瞰するものですので、上層部への報告やプロジェクト全体に向けた共有会などで使用するようにしましょう。
これまでのステップである成果物が作成できます。それはプロジェクトの計画書です。プロジェクトの目的、スコープ、体制・役割、スケジュールはプロジェクトを実行するうえで最低限策定しなくてはならない計画書になり、その内容は関係者に説明し合意を得るようにしましょう。
工程の実行
プロジェクト計画書の策定までできたら、ようやく最後の工程の実行です。計画書に記載されているマスタースケジュールに沿って、WBSで管理しながらプロジェクトを推進していきます。
しかし、どんなに入念に検討された計画書を策定しても、計画通りに進められるプロジェクトはほとんどありません。
ほぼ間違いなく想定していなかった事象が発生し対応に追われ、当初検討した目的やスケジュールから外れます。
想定していなかった事象が発生したときに大事なのは計画との乖離を認識し、上層部に報告して必要なサポートを受けることです。
プロジェクトが炎上したときに考えられる対応方法は大きく分けると基本的に3つしかありません。
- プロジェクトのスケジュールを延伸する
- メンバーを増員する（もしくはスキルがマッチする人財にスイッチする）
- 現状のメンバーとスケジュールで対応できるようにやり方を変える
１と２はいずれもコストがかかります。上位層へのサポートを受けるときは、炎上の原因分析をきちんと行い、どこまでスケジュールを伸ばせば対応可能か、人を何人追加すれば対応可能を説明する必要があります。
まとめ
プロジェクトを成功させるための5つのステップを解説してきました。まとめると以下のようになります。
- プロジェクト発足理由の認識合わせ
- プロジェクトの目的を達成するための工程の決定
- プロジェクトに参画できるメンバーとその役割の決定
- 参画メンバーのスキルを加味した実現可能性のあるスケジュール・WBSの決定
- 計画書に従った工程の実行・管理
上記はシステム導入のプロジェクトに限らず、どのプロジェクトでも共通して考える必要のある内容です。プロジェクトマネージャーは、この5つのステップを適切にコントロールしプロジェクトを成功に導く責任があります。
