第1章 1.1 ← 1.0 プロジェクト管理とは
プロジェクトの始まりと終わりは、日付では決まりません
プロジェクトの定義を教科書どおりに言えば「有期性」と「独自性」です。間違ってはいませんが、これを覚えても現場では何も変わりません。実務で効くのは、目の前のこの仕事はいつ始まって、何が起きたら終わりなのかを言えるかどうかです。ここが言えない仕事は、たいてい予定より長くなります。
この記事の要点
- 始まりはキックオフの日ではなく、「やる」と決まった瞬間です。日本の会社なら、多くの場合それは決裁がおりた日です。
- 終わりは納品した日ではなく、相手が受け取った日です。検収が通っていない仕事は、まだ終わっていません。
- この両端は、たいてい工数として数えられていません。予定より長くなる原因の多くがここにあります。
- 「独自性がある」とは、前例どおりにやれば済むわけではない、という意味です。だから見積りが当たりません。
- 終わりの条件を最初に文章にしておくと、それだけで揉め事の大半が消えます。
輪郭を描いてみると、思っていた形と違います
多くの人が頭に描いているプロジェクトの形は、キックオフで始まって納品で終わる一本の帯です。ところが実際に費用と労力がかかっている範囲は、その両側にはみ出しています。
始まりは、決裁がおりた日です
「いつから始まったのか」と聞かれて、キックオフの日を答える方は多いと思います。ただ、キックオフの時点ではすでに、誰かが企画書を書き、概算を出し、上長に説明し、稟議を回しています。その作業は誰の工数にも入っていないことがほとんどです。
実務上、プロジェクトが始まったと言えるのは決裁がおりた瞬間です。そこから先は、やめる判断にコストがかかるようになります。人の予定が押さえられ、相手先に話が伝わり、社内で「あの件」と呼ばれ始めます。この瞬間から、あなたは何かを管理していることになります。
ここを意識しておく実利は2つあります。ひとつは、決裁前の検討期間も含めて振り返れば、次回の見積りが現実的になること。もうひとつは、決裁の直後にやるべきこと——関係者の確認、終わりの条件の言語化——を、キックオフまで先延ばしにしなくなることです。日本の組織では決裁からキックオフまでに数週間空くことも珍しくなく、その間は誰も舵を握っていない時間になりがちです。
終わりは、検収が通った日です
終わりのほうは、もっとはっきりしています。検収です。相手が「これで受け取りました」と言った瞬間で、社外案件なら支払いが動き、社内案件なら依頼元が使い始めます。
納品と検収のあいだには、しばしば長い時間があります。相手の担当者が確認する時間、指摘への対応、再提出、そして承認。この期間、あなたのチームは動いていますが、多くの計画では「納品」で線が引かれているため、その工数はどこにも計上されていません。次の案件がもう始まっていて、二重に走ることになります。
最初に決めておくと、あとで揉めないこと
「何が揃ったら検収とするか」を、開始時に一文で書いておいてください。たとえば「移行後の3営業日、業務が止まらずに回れば完了とする」。これがないと、終盤で「まだ動作が気になる」「あの機能も入るはずだった」という会話が始まり、終わりが自然に遠ざかります。終わりの条件は、遅くなればなるほど決めにくくなります。
「独自性がある」の実務的な意味
教科書に出てくる「独自性」という言葉は抽象的ですが、実務に翻訳すると単純です。前例のとおりにやれば済むわけではない、ということです。
去年と同じ拠点移転でも、建物が違えば配線も違い、担当者が違えば決め方も違います。似た機能を作った経験があっても、つなぐ相手のシステムが違えば、出てくる問題も違います。似ているのは形式だけで、中身は初めてです。
ここから、実務でよく効く帰結が出てきます。プロジェクトの見積りは、定常業務の見積りほど当たりません。それは能力の問題ではなく、前例がないという性質そのものから来ています。だから見積りには幅を持たせ、進みながら精度を上げていくのが正しいやり方になります。この考え方は3.2 スケジュールの立て方で詳しく扱います。
これはプロジェクトか、判断する3つの問い
目の前の仕事がプロジェクトかどうか迷ったときは、次の3つで判断できます。
- 終わったと言える条件があるか。「ずっと続く」なら定常業務です。運用や保守はここに入ります。
- 手順を自分たちで決める必要があるか。手順書のとおりに回せばいいなら、管理する対象は多くありません。
- ひとりで完結しないか。複数の人・部署・会社が関わるなら、調整という仕事が発生します。
3つとも当てはまるなら、規模の大小にかかわらずプロジェクトです。逆に、どれも当てはまらない仕事に大げさな管理を持ち込むと、手間だけが増えます。「小さいからプロジェクトではない」ではなく、「性質が違うからやり方も違う」と考えてください。
ABではこう見えます
AB Projectsでプロジェクトを作るとき、いちばん最初に埋めるべきは名前ではなく、終わりの条件です。プロジェクトの説明欄やWikiの最初の記事に一文で書いておけば、途中から参加した人も、半年後に見返した人も、同じ終わり方を見ることになります。
決裁と検収を扱うなら、その2つをタスクとして置いておくのが実用的です。「稟議提出」「検収依頼」を担当者と期日つきで置くだけで、前後の見えない期間がスケジュール上に姿を現します。何もしなければ、この2つはいつまでも誰かの頭の中にあるだけです。
このページで使った言葉
- 検収
- 納めたものを相手が確認し、正式に受け取ることです。社外案件では支払いの起点になるため、契約上もっとも重い節目になります。「納品」とは別の行為です。くわしく →
- 稟議・決裁
- やるかどうかを組織として決める仕組みです。稟議書を回して関係者の承認を集め、決裁権を持つ人が最終的に判断します。ここが通るまで、その仕事は正式には存在していません。くわしく →
- 成果物
- プロジェクトが生み出す、目に見える結果のことです。システム、資料、移転後の事務所など、相手が受け取れる形になっているものを指します。くわしく →
- 工数
- 作業に必要な人の手間を、人日・人月といった単位で表したものです。見積工数と実績工数の差が、そのまま見積りの精度になります。くわしく →
- キックオフ
- 関係者が集まって、目的・体制・進め方を確認する最初の会議です。始まりの合図ではありますが、実際の開始点ではありません。くわしく →
- スコープ
- そのプロジェクトでやること・やらないことの範囲です。「対応範囲」とも言います。書かれていない範囲は、たいてい相手の頭の中では「やること」に入っています。くわしく →
あわせて読みたい
1.3 定常業務との違い
毎日の仕事とプロジェクトを、5つの観点で並べて比べます。
3.1 スコープの決め方
「やらないこと」を書くほうが、やることを書くより効きます。
2.1 立ち上げ
決裁がおりた直後の数週間で、何をしておくべきか。