プロジェクトの目的を「1枚」にまとめる

プロジェクトが始まるとき、いちばん最初にやるべきことは何でしょうか。スケジュールを引くことでも、体制図を作ることでもありません。「このプロジェクトは何のためにやるのか」を1枚にまとめて、関係者全員に同じものを見てもらうことです。

PMBOKでは「プロジェクト憲章（プロジェクト・チャーター）」と呼ばれる文書にあたります。ただ、形式ばった文書を作る必要はありません。A4で1枚、8つの項目が埋まっていれば十分です。

プロジェクト概要シートの8項目（背景・目的・成功基準・スコープ・スコープ外・体制・マイルストーン・前提）の記入例

プロジェクトが混乱する原因の多くは、技術的な難しさではなく、関係者が別々のことを期待していることにあります。

それぞれが自分の期待を口に出さないまま進むと、終盤で「思っていたものと違う」という話になります。1枚にまとめて配るのは、ズレを最初に表に出すためです。

① 背景 ―― なぜ今やるのか

いま何に困っているのかを、事実で書きます。「業務効率化のため」では足りません。「繁忙期に締め処理が翌日までずれ込み、出荷が1日遅れている」のように、具体的な状態を書きます。

② 目的 ―― 何を実現したいか

システムを作ることは目的ではありません。そのシステムで業務がどう変わるかが目的です。「受注から出荷指示までを当日中に完了できる状態にする」と書けば、何のための開発かが伝わります。

③ 成功の判断基準 ―― 終わったと言える条件

ここが抜けているプロジェクトは、いつまでも終わりません。数字で測れる形にします。「締め処理が19時までに完了する」「入力ミスによる再処理が月5件以下」のように書きます。

④ スコープ ―― やること

対象となる業務・機能・部門を列挙します。この時点では粗くてかまいません。後で詳細化します。

⑤ スコープ外 ―― やらないこと

8項目のうち、実務でいちばん効くのがここです。「やらないこと」を最初に書いておくと、後から入ってくる依頼を判断できます。「請求・会計連携は今回対象外」と書いてあれば、途中でその話が出たときに「これは別プロジェクトですね」と言えます。書いていなければ、断る根拠がありません。

⑥ 体制と決裁 ―― 誰が決めるか

役職名ではなく、個人名で書きます。特に「最終的に承認するのは誰か」と「業務側の窓口は誰か」の2つは必須です。ここが曖昧なまま進むと、判断待ちで必ず止まります。

⑦ 主要マイルストーン ―― いつ何が終わるか

詳細な工程表はまだ要りません。「要件確定」「テスト開始」「稼働」など、3〜5個の節目だけを置きます。

⑧ 前提と制約 ―― 崩れたら見直す条件

計画は必ず何かを前提にしています。「業務側のレビュー要員は週8時間まで」「11月の稼働日は変更できない」。これを書いておくと、前提が崩れたときに計画を見直す根拠になります。前提が書かれていない計画は、遅れたときにPMの管理不足の話にされてしまいます。

作った1枚は、キックオフ会議で読み上げて、その場で合意をとります。黙って配るだけでは読まれません。とくに③成功の判断基準と⑤スコープ外は、声に出して確認します。

すでに走っているプロジェクトを引き継いだときにも、この1枚は有効です。既存の資料から8項目を埋めてみて、埋まらない項目があれば、それが今のプロジェクトの弱点です。

とくに「成功の判断基準」と「スコープ外」が空欄のまま進んでいるプロジェクトは、終盤で揉める可能性が高いと考えてよいでしょう。埋めに行くところから始めます。

立ち上げ期にPMがやるべき最大の仕事は、関係者の頭の中をそろえることです。詳細な計画は後から作れますが、目的がそろっていないプロジェクトは、どれだけ精密な工程表を引いても成功しません。

次に新しいプロジェクトを任されたら、まずこの8項目を書いてみてください。書けない項目が見つかったら、それが最初に確認すべきことです。

ユーザーコメント（0）