プロジェクトマネジメントにおける教訓：ガイドと例

プロジェクトマネジメントにおける教訓とは何ですか？

教訓 とは、プロジェクト中に得られた、何がうまくいき、何がうまくいかず、なぜそうなり、将来何を変えるべきかについての文書化された知識です。良い教訓は、そのプロジェクトにいなかった人でも行動に移せるほど具体的で、明確な推奨事項で締めくくられています。

教訓には肯定的なものも否定的なものもあり、どちらも重要です：

• ポジティブな教訓 繰り返す価値のあるプラクティスを記録します。たとえば、不具合を早期に発見した業者レビューの定例などです。
• ネガティブな教訓 問題、その根本原因、予防方法を記録します。
• 提言 各教訓を、現在のプロジェクト、将来のプロジェクト、または組織の手法に対するアクションに変えます。

教訓の 特定 と教訓の 習得には重要な違いがあります。スプレッドシートに「テストの開始が遅れた」と書くのは教訓を特定したにすぎません。それが習得されたといえるのは、後のプロジェクトがそれを理由にテストの計画を変えたときだけです。このガイドで説明する取り組みの大半は、その差を埋めるためのものです。

教訓が重要な理由

• より良い見積り： 過去のプロジェクトの実際の所要期間とコストが、将来の次の精度を高めます： コスト見積り とスケジューリング。
• 問題の繰り返しが減る： 既知のリスクを、次のプロジェクトの次に直接取り込めます： リスク登録簿.
• 成功を再現できる： 優れたプラクティスが、それを発見したチームを超えて広がります。
• オンボーディングが速くなる： 新しいプロジェクトマネージャーが、ゼロからではなく組織の歴史から学べます。
• 手法の改善： a PMO は、証拠に基づいてテンプレート、チェックリスト、標準を更新できます。
• より強いチーム文化： うまく運営されたレビューは、問題を提起することが歓迎されると示し、今後の報告をより正直なものにします。

教訓は次も支えます： プロジェクトガバナンス：決定ログとそこから引き出された教訓は、スポンサーや委員会が類似プロジェクトを承認する際の根拠となります。

教訓登録簿、リポジトリ、ログ、報告書

手法によって文書の名称は異なります。下表はそれらの関係を示しています。

なお、 PMBOKガイド 第6版では、教訓はプロジェクト全体を通じて登録簿に記録され、フェーズやプロジェクトの終結時にリポジトリに移されます。 PRINCE2 は「経験から学ぶ」を7つの原則の1つとしており、新しい教訓を記録するだけでなく、プロジェクトの開始時にも教訓を探すことを意味します。どの用語を使っても、パターンは同じです。プロジェクト中に収集し、終了時に共有し、次の開始時に再利用します。

教訓のプロセス

1. 特定： レビュー、状況確認会議、レトロスペクティブ、各フェーズの終わりで、教訓をその場で見つけます。
2. 文書化： 詳細が記憶に新しいうちに、背景、影響、証拠とともに各教訓を登録簿に記録します。
3. 分析： 症状だけでなく根本原因を見つけます。次が役立ちます： 特性要因図（フィッシュボーン図） やなぜなぜ分析（5 Whys）。
4. 推奨： 責任者付きの具体的なアクションを書き、それがこのプロジェクト、将来のプロジェクト、組織の標準のどれに適用されるかを決めます。
5. 共有と保存： 検証済みの教訓を、一貫したカテゴリーとタグを付けて組織のリポジトリに移し、検索できるようにします。
6. 適用と確認： 新しいプロジェクトを始めるときに関連する教訓を見直し、後で推奨事項が実際に実施されたかを確認します。

手順1～4はプロジェクトチームが担います。手順5と6には通常、PMOなどプロジェクト外の責任者が必要です。プロジェクトチームはその頃には別の仕事に移っているためです。

教訓を収集するタイミング

教訓会議の進め方

1. 証拠を準備する： 計画とベースライン、 状況報告書、 課題ログ、RAIDログ、変更ログを集めます。
2. 事前に意見を集める： 短いアンケートや共有文書を送り、控えめな人や出席できない人も意見を出せるようにします。
3. 適切な人を招く： コアチーム、主要なステークホルダー、関係する場合は業者、そして理想的にはスポンサー。率直に話せる規模のグループにとどめます。
4. ファシリテーターを選ぶ： プロジェクトが困難だった場合や対立があった場合は、プロジェクトマネージャーではなく中立的な人を起用します。
5. グラウンドルールを決める： 個人ではなくプロセスと意思決定に焦点を当て、全員がその時点で知っていたことに基づいて最善を尽くしたと考えます。
6. 時系列をたどる： 主な出来事、決定、転換点を順に振り返ります。
7. うまくいったことと改善すべきことを話し合い、 その後、似た指摘をテーマにまとめます。
8. 根本原因を見つける： （すべてを分析しようとせず、上位いくつかのテーマについて）。
9. 提言に合意する： （それぞれに責任者と目標日を決める）。
10. 記録・共有する： 結果を登録簿に記録し、数日以内に出席者とPMOに短い要約を送ります。

90分のアジェンダ例

活用する：当サイトの 会議アジェンダテンプレート を使って、アジェンダを事前に送りましょう。

ファシリテーションの形式

• アフターアクションレビュー： 米陸軍で生まれた、短く体系的な振り返りです。何が起こるはずだったか、実際に何が起きたか、なぜ違いが生じたか、次回どうするかを問います。
• Start, stop, continue（始める、やめる、続ける）： 短時間で実施でき、アクションを生み出すのに適しています。
• うまくいったこと／改善すべきこと／アイデア： 対面でもオンラインでも使える、シンプルな3列のボードです。
• 浮き沈みを示すタイムライン： チームが出来事をタイムライン上に並べ、そのときの気持ちを書き込みます。普段なら提起されない問題が表面化します。
• レトロスペクティブのゲーム： 帆船（Sailboat）や4Lsなどの形式はプロジェクトのレビューにも使えます。参考： スプリントレトロスペクティブのゲーム.

教訓を引き出すための質問

すべての質問を順にこなすのではなく、プロジェクトに合ったものを選びましょう。

計画とスコープ

• 目標と成功基準は最初から明確だったか？
• 作業を始める前に、要件は網羅され合意されていたか？
• スコープの変更をどの程度うまく管理できたか？

スケジュール、コスト、見積り

• 実績から最もかけ離れていた見積りはどれで、なぜか？
• 遅れはどこから始まり、報告で早い段階から見えていたか？
• コンティンジェンシーの規模は適切で、適切なことに使われたか？

リスクと課題

• どの課題を事前にリスクとして特定していたか？
• どの問題が不意打ちだったか、それは予見できたか？
• エスカレーションは十分に速く適切な人に届いたか？

チーム、ステークホルダー、コミュニケーション

• メンバーは必要なスキル、時間、権限を持っていたか？
• ステークホルダーは適切な情報を適切なタイミングで受け取っていたか？
• 意思決定は迅速に行われ、記録されていたか？

業者、品質、終結

• 業者のパフォーマンスはどうだったか、関係がうまくいった（いかなかった）理由は何か？
• 品質チェックは十分早く不具合を発見できたか？
• 運用への引き継ぎは円滑だったか、何を変えたいか？
• 明日このプロジェクトをもう一度始めるとしたら、何を変えるか？

良い教訓の書き方

役に立つ教訓はシンプルなパターンに従います： 何が起きたか、その影響、根本原因、責任者付きの具体的な推奨事項。 曖昧な記述と非難は避けましょう。

教訓登録簿テンプレート

登録簿はスプレッドシートでも、プロジェクトツールのリストでも、共有Wikiのページでも構いません。ほとんどのプロジェクトでは次の列が使えます：

当サイトの無料の 教訓テンプレート には、影響度と状況のドロップダウン付きで、これらの列がすぐに使える形で用意されています（Googleスプレッドシート、Excel、PDF）。1つの問題をより深く分析するには、次を使いましょう： 根本原因分析テンプレート.

教訓の例

以下の記載は、架空の8か月間のCRM導入と架空のオフィス移転のものです。目指すべき詳細度を示しています。

教訓報告書の構成

フェーズやプロジェクトの終わりに、登録簿をスポンサーとPMO向けの短い報告書にまとめます。

報告書は短くまとめましょう。通常は2～3ページで十分です。終結報告書に含めることもよくあります。参考：当サイトのガイド プロジェクトの終結.

教訓、レトロスペクティブ、ポストモーテムの違い

どれも学習と改善という同じ目的を持っています。実践的なアプローチとしては、レトロスペクティブをチームレベルの習慣とし、教訓を最も役立つ発見を他のチームに伝える手段として扱うことです。

教訓を定着させる方法

最もよくある失敗は、教訓を収集したまま一度も使わないことです。次の習慣がその差を埋めるのに役立ちます：

• 過去の教訓の見直しを立ち上げの手順に組み込む。 「関連する教訓を見直す」を次に加えます： プロジェクト憲章 のチェックリストまたは最初のステージゲート。
• 教訓を検索可能な1か所に保存する （一貫したカテゴリーとタグを付け、PMOまたはナレッジ担当が管理する）。
• 繰り返し現れる教訓を標準にする。 同じ教訓が3つのプロジェクトで現れたら、4回目を記録するのではなく、テンプレート、チェックリスト、見積りガイドを更新しましょう。
• 推奨事項を他のアクションと同じように追跡する。 責任者と期日を決め、どれだけ適用されたかを報告します。
• 長いスプレッドシートではなく、短いストーリーを共有する。 実践コミュニティの会議での5分間の枠の方が、誰も開かない文書よりも多くの人に届きます。
• 教訓をリスクに結び付ける。 関連する教訓を、新しいプロジェクトの次に直接取り込みます： RAIDログ.

よくある間違い

• 人々が詳細を忘れたり、別の仕事に移ったりしたプロジェクトの終わりまで待つ。
• セッションを非難の場にしてしまい、人々が率直に話さなくなる。
• 根本原因ではなく症状（「テストが遅れた」）を記録する。
• 責任者のいない曖昧な推奨事項を書く。
• 問題だけを収集し、繰り返す価値のある成功を無視する。
• 終了したプロジェクトのフォルダの中など、誰も見ない場所に教訓を保存する。
• 中止されたプロジェクトの教訓を省略する。そうしたプロジェクトこそ最も多くの学びがあることが多いものです。

次のレビューは、すぐに使える構成で始めましょう。無料の次をダウンロードしてください： 教訓テンプレート または スプリントレトロスペクティブテンプレート （アジャイルチーム向け）。

このトピックの無料テンプレート

すべてのテンプレートを見る

よくある質問