Lessons Learnedとは、プロジェクトを実施する中で得られた知識や気づきのことです。知識や気づきには、失敗や不具合を起こした時の対処方法だけではなく、何も失敗や不具合を起こさずに対応した内容も含まれます。また、プロジェクトマネジメントの概念の一つです。
日本語では「学んだ教訓」と称することが多いのですが、とても語呂が悪い表現となっています。個人的には「得られた教訓」の方が良いとは思っています。一般には、教訓やプロジェクト教訓とすることがあります。
表現としては、Lessons learned以外にレッスンズ・ラーンドとする場合があります。
このブログに書かれているLessons Learnedは下記linkにまとめています参考にしてください。
mechanical-systems-sharing-ph.hatenablog.com
Lessons Learnedは失敗事例だけではなく、成功事例もまとめていることが大きなポイントです。
同じことを起こさないだけではなく、それぞれの工夫を記録に残すことで、実際に製品開発に携わったメンバー以外にも組織内部に情報を残すことができます。
実際のところ、On the Job Training（OJT）で伝えてきたプロジェクト進め方を記録に残すことができるという利点もあります。
[目次]
Lessons Learnedの効果
プロジェクトマネジメントやシステムエンジニアリングは、古くからNASA（米国の宇宙機関）で取り入れられていたようですが、Lessons Learnedがデータベースとして構築し始めたのは、1995年と比較的歴史は浅いです。
日本の宇宙研究機関であるJAXAでも、国際宇宙ステーション日本実験棟「きぼう」の開発にも活用され、チーフエンジニア室と呼ばれる部署の業務の中に組み込まれることとなりました。
宇宙開発に限らず、プロジェクトと称される業務は、新規製品開発や建築工事などの目標を達成するための計画を指し、多くが固有の課題を有し、基本的には次の新しいプロジェクトに全く同じ教訓が活かされないものと考えられていました。
しかし、実際にデータベース化してみると、似たような事故や不具合が発生していることが明確となり、よりデータベースの活動を推進していくことになったそうです。
実際に宇宙に打ち上る製品は、部品メーカー、機器メーカー、システムメーカーなどと複数で多種の組織文化が協力して完成させています。
メンバーが違うだけでも、多くの教訓や知見が途切れてしまい、プロジェクトが失敗につながることは度々発生しています。
プロジェクトを成功につなげるために、属人化してしまう教訓を共有し、過去に起きた気を付けるべきことと見習うべきことを蓄積し、複雑なシステムの成功率を上げる効果がLessons Learnedにはあります。
開始はいつか
Lessons Learnedはプロジェクトが開始した時点で、プロジェクトマネージャーが意識してメンバーに呼び掛け、開始していくべきです。
人間は忘れやすいため、その都度情報を残しておく必要があります。
もちろんプロジェクトが終わらないと、その知見が本当に成功につながったか、分からないのですが、Lessons Learnedの情報を完成させるのではなく、意識的に残しておいた方が、振り返った時に思考を再現するときに有利になります。
これは、プロジェクトに追加メンバーが入った時、プロジェクトマネージャーが変わった時、組織体系が変わった時にLessons Learnedをまとめる活動を続けることを再度周知・展開する必要があります。
それは追加メンバーが入ったり、プロジェクトマネージャーが新しくなることは、プロジェクト自体が長期化していたり、新しいフェーズに突入したときに起こるため、伝えるとともにLessons Learnedをまとめること認識するにはちょうど良いタイミングです。
過去のLessons Learnedはリスクマネジメント管理
Lessons Learnedは過去に実際に起きた事象をまとめており、類似のプロジェクト、類似の製品、類似の構造に対して新たな気づきを得ることが来ます。
リスクを抽出するとき、メンバーの経験や知識を元に炙りだしていきます。
炙りだされなかった事象は、リスクとして認識できず、課題として問題が発生してから対応していくことになります。
課題となってからでは、対処に対するメンバー数やコストが大きくなっていきます。
もし品質保証が組織内に存在しているのであれば、過去に起きた事象を最もまとめており、管理されているはずです。
その情報を設計や製造、組立や運用に活かすためにフィードバックするのですが、品質保証自体忙しいことが多いこと、品質保証自体がフォーマット化している情報データベースの検索性が悪いことで、有効に活用されていないのが実情ではないでしょうか。
分析してまとめる
組織文化や製品の特性により画一的なフォーマットを作ることが難しいです。
だいたいは次の事項でまとめられています。
- 概要：要約、時期
- 詳細：経緯と原因、対処と結果
- 推奨事項
- まとめ
- 検索用キーワード
ちなみに比較的多くの企業では、次の既存のシステムを利用してLessons Learned共有している企業もあるようです。
- IBM: LotusNotes
- Novell: Linux Systems, Linux Desktop, OpenOffice, iFolder
- Microsoft: Sharepoint, Word, Excel, Access
- Oracle
ただ、汎用ソフトですので扱いにくい場合がほとんどではあります。
参考サイト
「きぼう」日本実験棟開発を振り返って (26)―Lessons Learnedは手間がかかるが役立つ―
https://www.pmaj.or.jp/online/2101/message12.html
How to do lessons learned in project management
https://www.projectmanagementqualification.com/blog/2019/08/21/lessons-learned/
Lessons Learned in Project Management: Example and Template
