現役PMが徹底解説|プロジェクトマネジメント成功の技術|【最終回#15】笑顔で終わるプロジェクトはここが違う!プロジェクトクロージングのTODO

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。

みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。

プロジェクトマネジメント成功の技術 連載一覧>※クリックで開きます

【第1回】プロジェクトマネジメントとは何か? [全文公開中]
【第2回】プロジェクトマネージャーの役割とは?
【第3回】ステークホルダーマネジメントの重要性と進め方
【第4回】プロジェクトの統合マネジメント、7つのプロセス
【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ
【第6回】WBSだけでスケジュールはできない!正しいスケジュールの導き方[前編]
【第7回】WBSだけでスケジュールはできない!正しいスケジュールの導き方[後編]
【第8回】コストをプロジェクトの武器にする!
【第9回】目に見えにくいプロセス管理こそ品質達成の鍵
【第10回】プロジェクトのリスクマネジメント[前編]リスクを徹底的に洗い出す
【第11回】プロジェクトのリスクマネジメント[後編]リスク分析とコンティンジェンシープラン
【第12回】人がプロジェクトの源泉!チームは育てて強くする[前編]
【第13回】人がプロジェクトの源泉!チームは育てて強くする[後編]
【第14回】コミュニケーションの本質を知り、使いこなそう!
【第15回】笑顔で終わるプロジェクトはここが違う!プロジェクトクロージングのTODO [全文公開中]

本連載もいよいよ最終回となりました。今回はプロジェクトの終了についてお話しします。

プロジェクト終了(クローズ)時の営みは【第4回】プロジェクトの統合マネジメント、7つのプロセス(7)でもお話したように、プロジェクト活動における「最後の活動」です。

<統合マネジメント:7つの活動>
(1) プロジェクト憲章の作成
(2) プロジェクトマネジメント計画書の作成
(3) プロジェクトへの指揮とマネジメント
(4) プロジェクトに関する知識のマネジメント
(5) プロジェクト実行の監視とコントロール
(6) 統合変更管理の実行
(7) プロジェクトクローズ ←こちら

ではなぜ改めてこのプロジェクトクローズをおさらいするのでしょうか?それはPMBOKには詳しく書かれていない重要なポイントがあるからです。多くの人がプロジェクトの完了(done)と終結(close)を混同したり、終結に必要な活動をどうしてもおざなり(省略)にしがちです。プロジェクトを正しくクローズすること、これまでの活動をどのように「活かす」ことができるのか。大変だったプロジェクトもそうでなかったプロジェクトも、最後には笑顔で締めくくれるよう改めて学んでいきましょう。

プロジェクトの終結

1) 終結の定義

プロジェクトって成果物が完成したり納品できたら終わりじゃないの?

PMBOKでは「プロジェクト、フェーズ、または契約上の全ての活動を完結するプロセス」と定義されています。つまり、単純に目的目標の達成や成果物の納品「だけ」では物足りないということがわかりますね。またプロジェクトが経た活動や情報が保管(蓄積)且つ完了された状態で、プロジェクトに集結させていたリソース等も適切に解放(返却)させなければなりません。

2) 実施するクローズ活動と終結基準として確認したいこと

  • 全ての文書と成果物が最新状態であることを確認する
  • 全ての課題が解決されていることを確認する(または適切に申し送り事項として管理されていることを確認する)
  • 成果物の検修完了を確認する
  • プロジェクトの会計を終えている(未払い等がない状態を指す)
  • 人的資源(人員)を返却する(プロジェクトから定常業務へ配置転換する)
  • プロジェクトで利用した各種資源の返却や再分配を行う
  • プロジェクト報告など必要なドキュメントを作成し報告を完了する
  • プロジェクトの知識や教訓を特定、整理し、将来活用できるよう情報保管する
  • ステークホルダーの満足度特定(アンケートやヒアリングの実施)

これらの対応は相当の時間を要します。またクローズ時に全てを行おうとしても必要な情報が収集できなかったり、プロジェクト冒頭の事は失念してしまうこともあるでしょう。PMはプロジェクト期間を通して、プロジェクト実行や監視と並行してこれらの整理・準備少しづつ進めておきましょう。

組織と未来のプロジェクトへ、フィードバックは完璧に

1) 必ず作ろう終了報告書

プロジェクトは、上手くいったなと思う場合とそうでもない時があるはずです。反省の多いプロジェクトで終了報告を書くのは少々辛く感じるかもしれませんが、プロジェクトが失敗しても成功しても、PMの活動・イベントとして必ずその終了時には「プロジェクト終了報告書」を纏めましょう。「成果物が完成し、いつの間にかPJ体制が解消された」というケースをよく見ます。また「あれ?XXプロジェクトって終わってたんだ、どうだったの?」と周囲に確認されることがないように「正式に終わらせる」ためにも報告が大切です。

以下に簡易的なプロジェクト終了書の項目例を示してみました。項目や記載のボリュームはプロジェクト規模によって異なります。プロジェクトが終了しても残課題や申し送り事項がある場合が少なくありません。その為、終了報告書はプロジェクトの結果報告だけでなく記載した事項を漏れなく「引き継ぐ」という役割も持っています。プロジェクトが成功した場合にも、その成果物を定常業務=運用に引き継ぐ役割もあります。プロジェクト活動の成果や残課題などを適切に引き継ぐことができなければ、後にプロジェクトに関連する活動でトラブルが発生した際などにズルズルと対応に追われることになるでしょう。

2) 未来に残す手紙

繰り返しになりますが、終了報告書は実施したプロジェクトのみならず、未来の活動(定常業務・プロジェクト・組織の活動等)の為に「プロジェクトで得た経験を蓄積し伝えていく」役割があります。あまりプロジェクト活動が上手くいっていない組織によく見られるのが「何度も同じ失敗や辛い体験を繰り返す」ことです。そうするとメンバーは「また同じことの繰り返しだ…」「全く改善されない…」と疲弊しモチベーションも下がってしまいます。

プロジェクトの目的目標が達成されれば必然的にチームは解散します。その際に適切に終結活動を行わないと、折角のプロジェクト活動で得られた経験や知識、技術も残らなくなってしまいます。よく聞く「XXプロジェクトを経験したXさんなら知っている」という類のものも、経験・知識が蓄積されているように見えて属人的な情報であり、組織の知恵になっておらずとても勿体無いです。プロジェクト終了報告書は別名「教訓報告書」とも呼ばれますが<教訓=Lesson &Learn>として知識や技術を残すことがPMとしての最後の重大なお仕事です。

こうしておけばよかった、という改善点もあれば、これは次も使えるといったベストプラクティスは再現できるように継承しましょう。教訓はPMだけでなくメンバーと共に整理できるとよいです。教訓という言い方だと難しく考えてしまうかもしれませんが、未来に残す手紙・メッセージと考えると、スムーズに「伝えたい」ことが書き出せるはずです。

3) 終了報告書に必要なステップ

終了報告書が完成したら、プロジェクトオーナーや主要なステークホルダーに報告し「承認」を貰いましょう。報告に際してはできれば対面が望ましいですが、難しい場合はメールの一文でもいいので「承認した」旨の返信エビデンスを残すようにしてください。承認者であろうプロジェクトオーナーは活動期間中にさまざまな形でプロジェクトに心を傾けてくれた人物です。報告の場でプロジェクトの成果を伝えることはもちろん、PM自身が感じた想いを伝えたり、POへ感謝を伝えることも忘れずに行いましょう。

終了報告書が承認され「PJお疲れ様、終了してもいいよ!」となってはじめてプロジェクトは正式な終了を迎えます。ただしここで「なんだ、XXができていないならPJ終了は認めない」「報告書の記載が不十分」といったように<差し戻し>があることはゼロではないので(筆者も経験があります)、そのような事態にならないよう必要十分な報告と申し送り対応の説明などを行うように気をつけましょう!

自信を持ってプロジェクトを終わらせるために

1) アンケート活用で暗黙知や見えにくい意見をあつめる

プロジェクト参加者やメンバーが多い場合や、クロスファンクショナルなチームの場合などには振り返りにプロジェクトアンケートも活用してみましょう。「大勢の場では発言しにくいが、こう思っている」「他でこういう成功例があたので、取り入れてみたい」といったメンバーそれぞれの思いに気付けたりアイデアがでてくることも。2)にあるような「振り返りミーティング」は時間も限られ、またどれだけ工夫をしたとしても発言しにくいケースもあるでしょう。時折「振り返りミーティングを実施したけれど、当たり障りのない発言しかでなかった」「意見がでなかった」と耳にしますが、それらを補完するための工夫としてぜひアンケートを活用してみてください。

※アンケート実施の際は、アンケート回答がプロジェクト教訓収集等に限定して使用され、個人を特定するものではないといったアンケートポリシーを記載しましょう。

2) 振り返りはナレッジの宝庫

プロジェクト終了の承認が得られた(得られるだろう)時点で、チームでの振り返りミーティング(クローズドミーティング)を準備・実施しましょう。プロジェクトの開始にキックオフがあったように、終了時にはプロジェクトクローズがセットの活動です。終了報告書と同様に、クローズドミーティングはプロジェクトのナレッジを集約し、未来に教訓を残す為に欠かせないイベントですが、目的は経験から学ぶ事であって決してネガティブになったり結果を非難するものではないことに気をつけましょう。またプロジェクトと組織の問題が混同し散漫になりがちですので、それぞれに対する意見は個別に述べてもらうなどの工夫もしてみましょう。

例えば会の冒頭に、以下のような振り返りの目的、ルール、怒ってほしくないことなどを記載し、参加者に伝えるとよいでしょう。

<振り返る目的:例>

  • プロジェクトで得た気づきを整理、相互に共有し、多角的にプロジェクトを振り返る
  • 後続プロジェクトや定常業務に活かすことのできる教訓を得る
  • 良い点に再現性を持たせ、問題点は繰り返さないようにする
  • プロジェクト結果をレガシーとして残す

<ルール:例>

  • もう一度同じプロジェクトをするなら、または次に向けたポジティブなスタンスで振り返えろう
  • 全てにおいて、個人の称賛/批判ではなく、プロジェクトやプロダクトをより良くするという観点を持とう
  • 振り返りを「次に活かす貴重な教訓=資産を得る場」だと考えよう
  • ポジティブ&ユーザーハッピーの視点で考えよう

振り返りにはKPTフレームワークやYWTフレームワークなど使い慣れた方法で行います。その場で上手くまとめる必要はありませんので、PMがファシリテーターとなり意見活性を促しましょう。とはいえ「さあ振り返りましょう!」と言ってもなかなか意見は出にくいものです。アンケートで収集した意見を事前にKPT上に書き入れて発言を誘発させるのも方法のひとつですし、発言してくれそうな人や発言しやすい項目をまず選んで、参加者が会話しやすいと感じる雰囲気を作っていきましょう。

3) メンバーに言葉で感謝を伝える

プロジェクトクローズドミーティングにはもう一つ重要な意味があります。それはプロジェクトメンバーや関係者を労って、所属していた部門や別のプロジェクトなどに気持ちよく戻れるようにすることです。「本当にありがとう、おつかれさま、またね」と<心理的にプロジェクトを終了させる>イベントです。言葉にしてプロジェクト活動を讃えあい、感謝を述べ、できる限りモチベーションを高めて次の活動に送りだすことに集中しましょう。またできる限りひとりひとり(もれなく)具体的な労いが言えるように準備したいですね。

その為にクローズドミーティングに軽食などを準備した「打ち上げ」を開催したり、打ち上げにメンバーが所属する上長を招待して「上長からメンバーを労ってもらう」といったテクニックを使うのも効果的でしょう。打ち上げをオフィシャルとしてしっかり実施することにはちゃんと目的があるというわけです。

さいごに

「プロジェクトマネジメントという共通言語としてのフレームワークや方法論の重要性はより高まります」と本連載のはじめにお話しました。それもそのはず、世の中は目まぐるしく変化し、企業組織では常に変化に対応するための多くのアクションが必要となり、現場レベル・部門レベル・全社レベル・短期的・中長期的・小規模プロジェクトから大規模プロジェクトまで、多くのプロジェクトが日々立ち上がる、まさに<プロジェクトエコノミー>の時代です。

しかし残念ながらプロジェクトマネジメントの手法を実行しただけでは、プロジェクトは上手くまわりません。プロジェクトに関与する人々のモチベーションがプロジェクトの成功や生産性にとても影響するからです。単なる指示命令・監視といったコミュニケーションではなく、相手の個別の価値観や傾向、思考などに寄り添う働きかけや工夫をすることで感情が動き、プロジェクトも動きます。プロジェクトを成功させる為に魔法のような大仕掛けはありませんが、これまでにお伝えしたようなひとつひとつの技術とコツの積み重ねが確実に効いてきます。プロジェクトやメンバーの声や動向に寄り添って、みんなが楽しく笑顔で活動できるようなプロジェクトをみなさんの手で作っていってください!

【編集後記(Sqripts編集部)】
11ヶ月に渡る西田さんの連載は今回で最終回となりました。
執筆者の西田さん、連載を支えてくださった関係者のみなさま、そして、記事を読んでくださったたくさんの読者のみなさまに心より御礼を申し上げます。
みなさまのプロジェクトが「笑顔で終われる」プロジェクトになることを願っております。
この連載の感想をぜひお聞かせください。
送信フォームはこちらです。
連載一覧

【第1回】プロジェクトマネジメントとは何か? [全文公開中]
【第2回】プロジェクトマネージャーの役割とは?
【第3回】ステークホルダーマネジメントの重要性と進め方
【第4回】プロジェクトの統合マネジメント、7つのプロセス
【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ
【第6回】WBSだけでスケジュールはできない!正しいスケジュールの導き方[前編]
【第7回】WBSだけでスケジュールはできない!正しいスケジュールの導き方[後編]
【第8回】コストをプロジェクトの武器にする!
【第9回】目に見えにくいプロセス管理こそ品質達成の鍵
【第10回】プロジェクトのリスクマネジメント[前編]リスクを徹底的に洗い出す
【第11回】プロジェクトのリスクマネジメント[後編]リスク分析とコンティンジェンシープラン
【第12回】人がプロジェクトの源泉!チームは育てて強くする[前編]
【第13回】人がプロジェクトの源泉!チームは育てて強くする[後編]
【第14回】コミュニケーションの本質を知り、使いこなそう!
【第15回】笑顔で終わるプロジェクトはここが違う!プロジェクトクロージングのTODO [全文公開中]

SHARE

  • facebook
  • twitter

SQRIPTER

西田 美香(にしだ みか)

記事一覧

フリーランスのプロジェクトマネージャー/コンサルタント
専門商社でマーケティングや海外駐在を経験した後、プロジェクト課題を抱える企業をより近くで支援したいという思いから2017年に独立。全社的な変革課題と向き合い、戦略構築から実行フェーズまでプロジェクトの全段階にハンズオンで支援を行う。より実践的なプロジェクトマネジメントスキルを伝えるべく講師活動にも力を入れている。
オフは釣り・ソロ旅・家庭菜園を好み「一人時間」を満喫する自由人。
PMP/CSM(認定スクラムマスター)/PMO★★/MBA(経営管理修士)/EMBA(経済学修士) 

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST