第2章 2.4 ← 2.0 プロジェクトの進み方
納品した日は、終わった日ではありません
終結は、4つのフェーズの中でいちばん軽く扱われます。納品が済めば気持ちの上では終わっていますし、次の案件はもう始まっています。それでも実際には、そこから先にいくつも残っています。そして残っているものの大半は、放っておくと次のプロジェクトのコストになります。
この記事の要点
- 納品と検収は別です。検収が通っていない仕事は、まだ終わっていません。
- 終結に残るのは5つ。検収、引き継ぎ、残課題の引き取り先、体制の解散、ふりかえりです。
- 上の4つは放っておくと誰かが困るので、いずれ片づきます。ふりかえりだけは誰も困りません。
- だからふりかえりが真っ先に飛ばされ、次のプロジェクトが同じところでつまずきます。
- 終結の作業は、計画の段階でタスクとして置いておくのがいちばん確実です。
「終わったつもりの日」から先に残っているもの
納品が済んだ時点で残っているものを並べると、だいたい次の5つになります。プロジェクトの種類が変わっても、この並びはあまり変わりません。
まず検収です
1.1でも書いたとおり、プロジェクトが終わるのは納品した日ではなく検収が通った日です。社外案件なら支払いの起点になり、社内案件なら依頼元が使い始める日です。
ここで実務的に効くのは、検収を待つのではなく、こちらから取りにいくことです。相手も忙しいので、放っておくと確認は後回しになります。「いつまでに確認いただけますか」を納品と同時に聞き、その日付をタスクとして持ってください。これをしないと、月末に「まだ検収が下りていません」と言われて経理と気まずくなります。
指摘が来たら、それが検収条件に含まれるものか、追加要望かを切り分けます。この切り分けができるのは、立ち上げで「終わったと言える条件」を書いてある場合だけです。書いていなければ、どこまでが範囲かの議論から始まり、たいてい押し切られます。
引き継ぎは、資料を渡すことではありません
運用する人への引き継ぎで、手順書を渡して終わりにするケースがよくあります。それでは引き継がれません。手順書は「書いてあることをやる方法」しか伝えないからです。
本当に渡すべきは、書いていないことです。なぜこの設定にしたのか。どこが壊れやすいのか。前任の担当者が何を嫌がっていたのか。この種の情報は手順書には載らず、あなたの頭の中にしかありません。
実務的にいちばん確実なのは、引き継ぎ相手に一度やってもらうことです。あなたが横で見ている状態で、月次の処理を一回通してもらう。そこで出てくる質問が、手順書に足りなかったものです。これを1回やるかやらないかで、半年後の問い合わせの量が変わります。
「あなたに聞けば分かる」状態は、終わっていません
半年後もあなたに問い合わせが来るなら、それは属人化が解消していないということです。忙しいときには「聞いてくれれば答える」ほうが早く感じますが、その分だけ次のプロジェクトの時間が削られます。引き継ぎが終わった合図は、資料を渡したことではなく、相手が自分で1回通せたことです。
残った課題は、必ず引き取り先を決める
どんなプロジェクトにも、終結の時点で片づいていないものが残ります。優先度が低くて後回しにした不具合、次期に回すことにした要望、様子を見ることにした挙動。
これらをそのまま消さないでください。課題管理表を閉じるときに、1件ずつ次のどれかに割り振ります。
- 運用側が持つ。誰が、どういう扱いにするかまで決めます。
- 次期の候補として記録する。置き場所を決めて、そこに移します。
- 今回で終わりにする。やらないと決めたことも、決めたと書いておきます。
割り振らずに閉じると、その不具合は誰の担当でもない状態になります。半年後に問題になったとき、経緯を知っている人はもういません。1件あたり1行なので、30分もあれば終わります。
体制の解散も、決める作業です
要員を返すことは自然に起きるように見えて、実際には曖昧なまま引きずられます。次の案件がもう始まっているのに、前の案件の問い合わせが来る。二重稼働の状態が数か月続き、どちらの工数としても計上されません。
ここは日付を決めるだけで解決します。「○月○日をもって、この案件の問い合わせは運用窓口へ」と決めて、関係者に伝える。決まっていれば、来た問い合わせを回せます。決まっていなければ、来た人に対応するしかありません。
そして、ふりかえり
5つの中で、これだけが性質が違います。やらなくても、誰も困りません。検収が滞れば経理が困り、引き継ぎがなければ運用が困り、二重稼働なら本人が困ります。ふりかえりをしなくても、今日は誰も困らない。
だから真っ先に飛ばされます。そして次のプロジェクトで、まったく同じところでつまずきます。要件定義の確認が甘くて手戻りになり、他部署の回答待ちで2週間止まり、終盤に知らない部署が現れる。前回と同じです。
ふりかえりの詳しいやり方は7.2で扱いますが、終結の段階で押さえておくべきことはひとつだけです。解散する前にやってください。人が散ってからでは集まりません。そして反省会にしないこと。人ではなく、進め方を対象にします。
終結の作業は、計画の段階で置いておく
ここまでの5つを確実にやる方法は、意志ではなく段取りです。計画をつくる段階で、終結の作業もタスクとして置いておく。これがいちばん効きます。
「検収依頼」「運用への引き継ぎ実施」「残課題の割り振り」「体制解散の連絡」「ふりかえり実施」。この5つを、納品予定日の後ろに担当者と期日つきで並べておく。それだけで、忙しさに紛れて消える確率がかなり下がります。2.2でWBSに「渡すもの」という枝を立てたのは、ここにつながっています。
ABではこう見えます
AB Projectsでは、終結の5つをそのままタスクとして計画時に登録しておけます。期日が来れば他のタスクと同じように表に出るので、「終わったつもり」で止まりません。
残課題の割り振りは、課題を閉じずに担当と扱いを書き換える形にすると記録が残ります。ふりかえりの結果はプロジェクトWikiに置き、次のプロジェクトの立ち上げ時に読み返す——これができると、経験が個人の記憶ではなく組織の資産になります。7.3で詳しく扱います。
このページで使った言葉
- 検収
- 納めたものを相手が確認し、正式に受け取ることです。社外案件では支払いの起点になります。待つのではなく、こちらから取りにいくものです。くわしく →
- 引き継ぎ
- つくったものを、日々動かす人へ渡すことです。資料を渡すことではなく、相手が自分で一度通せる状態にすることが完了条件です。くわしく →
- 運用
- つくったものを日々動かし続ける仕事です。プロジェクトが終わったあとに始まり、終わりがありません。くわしく →
- 属人化
- 特定の人しか分からない・できない状態です。引き継ぎが不十分だと、プロジェクトが終わっても解消しません。くわしく →
- ふりかえり
- 進め方そのものを見直す場です。解散する前にやること、そして反省会にしないことが条件です。くわしく →
- 要員
- プロジェクトに参加している人のことです。返却の日付を決めておかないと、次の案件と二重稼働になります。くわしく →
あわせて読みたい
7.0 プロジェクトの終わらせ方
終結の各作業を、実務の手順としてもう一段くわしく。
7.2 ふりかえり
反省会にせず、次に変える1つを決めて終わる方法。
3.0 計画の基本
終結の作業まで含めて、最初に何を決めておくか。