しかし、「反省会と何が違うの？」「失敗を書くだけではないの？」と思う方も少なくありません。

教訓（Lessons Learned）は、成功や失敗の経験を次のプロジェクトへ活かすための重要な資産です。

この記事では、教訓（Lessons Learned）の意味や目的、実施するタイミング、実務での活用方法までわかりやすく解説します。

一言でいうと

教訓（Lessons Learned）とは、「プロジェクトで得られた経験や学びを整理し、次のプロジェクトで活かすための知識」のことです。

教訓（Lessons Learned）とは

Lessons Learnedは、プロジェクトの中で経験した成功や失敗、その原因や改善策を整理し、組織の知識として残す活動です。

PMBOK®では、教訓は組織のプロセス資産（Organizational Process Assets）の一つとして位置付けられています。

単なる記録ではなく、「次回どのようにすればより良い結果になるか」を明らかにすることが目的です。

なぜ教訓が重要なのか

同じような失敗を繰り返すプロジェクトは少なくありません。

例えば、毎回「レビューが遅れた」「要件変更が多かった」という問題が発生していても、その原因や対策を共有しなければ、次のプロジェクトでも同じことが起こります。

教訓を残すことで、組織全体のプロジェクトマネジメントを継続的に改善できます。

教訓の具体例

重要なのは、「何が起きたか」ではなく、「次にどう活かすか」をまとめることです。

教訓と振り返りの違い

振り返り（Retrospective）と混同されることがありますが、それぞれ目的が異なります。

アジャイル開発では振り返りを繰り返し行い、その結果を教訓として蓄積することもあります。

教訓はプロジェクト終了時だけではない

PMBOK®では、教訓はプロジェクト終了時だけでなく、プロジェクトの途中でも継続的に収集することが推奨されています。

問題が発生した直後や重要なマイルストーンの後に記録しておくことで、より実践的な知識として活用できます。

実務ではこんな場面で活用される

例えば、設計フェーズで「レビュー前にチェックリストを使ったことで指摘件数が半減した」とします。

これを教訓として残しておけば、次のプロジェクトでも同じチェックリストを活用でき、品質向上につながります。

逆に、「設計レビューが遅れた」という事実だけを記録しても、改善にはつながりません。

よくある勘違い

教訓は失敗だけを書くものではない

成功した取り組みも重要な教訓です。

「うまくいった理由」を整理することで、成功を再現しやすくなります。

教訓は記録するだけでは意味がない

教訓は、次のプロジェクトで活用されて初めて価値があります。

共有しやすい形で蓄積し、必要なときに参照できる仕組みを整えることが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、「プロジェクト完了後の振り返り」や「組織への知識共有」が論点になることがあります。

午後Ⅱ論文では、「今回の経験をどのように次のプロジェクトへ活かしたか」を説明できると、継続的改善の視点を示すことができます。

PMBOK®でも、Lessons Learned Register（教訓登録簿）を活用し、プロジェクト全体を通じて教訓を蓄積することが推奨されています。

PM道場のワンポイント

教訓とは、「何が起きたか」を記録するものではなく、「次にどう行動するか」を決めるものです。「レビューが遅れた」というのは事実です。しかし、それだけでは教訓ではありません。

「レビュー対象を事前に分割し、レビュー時間を30分以内にする」「レビュー前日にセルフチェックを実施する」といった具体的な改善策まで整理して初めて、次のプロジェクトで活かせる知識になります。

優れたプロジェクトマネージャは、過去を分析することよりも、「未来のプロジェクトが成功するための仕組み」を残すことを重視しています。

関連用語

• プロジェクト終結
• プロジェクトライフサイクル
• ナレッジマネジメント
• 継続的改善（Continuous Improvement）
• プロセス資産（OPA）
• 品質マネジメント
• リスクマネジメント
• レビュー

まとめ

教訓（Lessons Learned）とは、プロジェクトで得られた経験や学びを整理し、次のプロジェクトへ活かすための知識です。

失敗だけでなく成功事例も整理し、「なぜそうなったのか」「次にどうするか」を明確にすることが重要です。

教訓を組織の資産として活用することで、プロジェクトマネジメントの品質を継続的に向上させることができます。

関連記事

• プロジェクトライフサイクルとは？
• 品質マネジメントとは？
• リスクマネジメントとは？
• ナレッジマネジメントとは？

よくある質問（FAQ）

Q. Lessons Learnedとは何ですか？

A. プロジェクトで得られた成功や失敗の経験を整理し、次のプロジェクトで活かすための知識や教訓のことです。

Q. 教訓はプロジェクト終了後だけに作成するものですか？

A. いいえ。PMBOK®では、プロジェクト中も継続的に教訓を収集・記録することが推奨されています。

Q. 良い教訓を残すポイントは何ですか？

A. 「何が起きたか」だけでなく、「なぜ起きたのか」「次回はどう改善するのか」まで具体的に整理することです。

The post 教訓（Lessons Learned）とは？プロジェクトマネジメントでの意味や活用方法をわかりやすく解説 first appeared on PM道場.

• 令和5年度秋期 プロジェクトマネージャ試験 午後Ⅱ
  
  問題冊子はこちら
  
  出典：IPA 独立行政法人 情報処理推進機構

※掲載している問題冊子へのリンクおよび試験問題の著作権は、IPA 独立行政法人 情報処理推進機構に帰属します。最新情報はIPA公式サイトをご確認ください。

ポイントはシンプルです。

• なぜ失敗したのかを深掘りすること
• 同じ失敗を繰り返さない仕組みを考えること

目標未達成の原因究明と再発防止策の立案及び他のプロジェクトに資する教訓について論じましょう。

結論：評価される論文は「原因→対策→定着」まで書けている

高評価につながる論文は、以下の流れが整理されています。

• 失敗の事実
• 原因（直接＋根本）
• 再発防止策
• 組織への定着

この流れが一貫していることが重要です。

設問ア：プロジェクトの全体像は「独自性×目標×影響」で説明する

以下3点について説明します。 独自性、目標、ステークホルダーの関係性を論理的に説明ができると◎

• ①システム開発プロジェクトの独自性
• ②未達成となった目標と未達成となった経緯
• ③目標未達成がステークホルダーに与えた影響

① システム開発プロジェクトの独自性はプロジェクト目標に関連したもの

プロジェクトの独自性とは、今まで経験したことがないこと。それは些細なことでも問題ありません。過去に似た事例があっても、環境・要件・関係者が異なるため全く同じプロジェクトは存在しません。この独自性がそのプロジェクトにおいて注意しなければならないことになります。

独自性の例：

• 品質に対して新しい規格が適用された
• 通常納期が1年のところ、半年で納入しなくてはならない
• プロジェクトメンバーに入社２年目の若手がいる

コツ：目標と関連づけて独自性を説明することがポイントです

② 未達成の目標と経緯は具体的に

未達成となった目標と未達成となった経緯を具体的に説明しましょう。目標は定量的に説明すること。未達成となった経緯は、元々の目標を達成するための計画、実際に起こった事象、その結果どのように目標に影響を与えたのかを時系列で説明しましょう。

ここは具体性が重要です。

• 目標は定量的に示すとわかりやすいです
• 経緯は時系列で整理します

③ ステークホルダーへの影響は要求と目標の関連性を明確に

目標未達成がステークホルダーに与えた影響を論じます。プロジェクトマネージャはプロジェクトを行う上で、ステークホルダーの要求を具体的に把握している必要があり、その要求と目標との関連性を説明できることが重要です。論理的に関連とステークホルダーへの影響を説明しましょう。

プロジェクトマネージャとして重要な観点です。

• 顧客：納期遅延や信頼低下
• 上司：評価への影響
• メンバー：業務負荷の増加

ポイント：目標と影響の関係を論理的に説明することが重要になります

設問イ：なぜなぜ分析で根本原因まで整理することがポイント

下記3点を論じます。

• ①目標未達成の直接原因の内容
• ②根本原因を究明するために行ったこと
• ③根本原因の内容

いわゆるなぜなぜ分析の内容を論理的に説明しましょう。

① 直接原因は簡潔に説明

目標未達成の直接原因を説明しますが、論理的に誰でも簡単に理解できるように説明しましょう。プロジェクトマネージャとしての力の見せ所は②③の論述です。①では、簡単にわかりやすく直接原因を説明することを心がけましょう。

例：

• 要件定義の不備
• スケジュール遅延

ポイント：ここはシンプルに整理すると読みやすくなります

② 根本原因の究明方法では使ったツールや工夫を説明

根本原因を究明するために行ったことでは、使ったツールはもちろん顧客などのステークホルダーや専門家といった第3者の意見も論述の中に含めると、プロジェクトマネージャとして様々な関係者を巻き込んだことをアピールできます。ここでも論理的にわかりやすく説明しましょう。

使える分析手法例：

• 5Whys
• 特性要因図
• FMEA
• パレート図
• フローチャート

ポイント：

• なぜその手法を選択したのかを書く
• ステークホルダーや専門家の意見も取り入れる

このあたりを意識すると説得力が増します。

③ 根本原因は3層で整理

根本原因の内容について論述しますが、直接原因との関連はもちろん、間接原因（背景や条件）→根本原因（本質的要因）といった流れで3層で整理しましょう。さらに影響範囲と再発防止策との関連まで含めると説得力が増します。

以下の構造にすると伝わりやすくなります。

• 直接原因
• 間接原因（背景）
• 根本原因（本質）

例

• 直接原因：要件漏れ
• 間接原因：レビュー不足
• 根本原因：レビュー基準の未整備

ポイント：因果関係を意識して整理することが重要です

設問ウ：再発防止は「仕組み化」がカギ

以下2点を論じます。

• ①プロジェクトマネジメントの観点で立案した再発防止策
• ②再発防止策を組織に定着させるための工夫

エンジニアリングではなく、「プロジェクトマネジメントの観点」というところが肝です。

再発防止は属人的ではなく、仕組みとして設計する必要があります。

① 再発防止策はエンジニアリングの観点にならないように

具体的にその防止策を説明することはもちろん、なぜ防止できるかも論理的に説明しましょう。なお、すでに防止策の効果がわかっている場合は、その効果を定量的に説明しましょう。効果が出ていない場合は、どのようにその効果を測定するかを説明しましょう。

問われているのはエンジニアリングではなくマネジメントの視点です。

例：

• レビュー工程の標準化
• チェックリストの導入
• 進捗管理の強化

書くべき内容：

• なぜ防止につながるのか
• 効果（可能であれば定量的に示す）

② 組織への定着方法

再発防止策を組織に定着させる工夫について説明しますが、様々な方法があります。標準プロセス化・教育研修・監査レビュー・ツール化・教訓共有・マネージャの関与など。定着できたかどうか（例えば他のプロジェクトマネージャへの確認結果）まで論じられると良いです。

方法例

• 標準プロセス化
• 教育・研修
• 定期レビュー
• ツール化
• 教訓共有

さらに良いポイント：他プロジェクトでの適用結果まで書けると強いです

まとめ

• 原因を根本まで整理する
• 再発防止策を仕組みとして設計する
• 組織への定着まで言及する

この流れを意識することで、論文全体の説得力が高まります。

The post IPAプロジェクトマネージャ試験 午後Ⅱ対策 ｜【令和5年度秋 問2】 first appeared on PM道場.