TL;DR
プロジェクトでの判断や意思決定は、結論に至るまでの検討の経緯がドキュメントに残らないことが多く、いざという時のリスクになる。PMO は議事録や課題管理表のフォーマットを見直し、検討資料の置き場所を決めて、経緯を残す仕組みを作るべきである。
内容
検討の経緯は残らない
プロジェクトでは多くの判断がされるが、結論に至るまでの検討の経緯はドキュメントにされないことが多い。経緯はメンバーの頭に曖昧に残るだけで、いざという時に大きなリスクになる。
プロジェクトのなかで、様々な判断や意思決定がされても、結論に至るまでの検討経緯はなぜか、ドキュメントにされていないことが多いものです。
経緯が残らない理由には、結論に至るまでの内容を口頭で済ませて議事録にしない、ドキュメントを各メンバーのパソコンに保管している、プロジェクトの文書サーバーのどこにあるか分からない、といったものがある。根本には、ドキュメント化に手間がかかることがある。
経緯がないと起きること
設計書さえあればプログラミングは進められる、という考え方もある。しかし経緯が残っていないと、次のような事態が起きる。
- 対応しないと決めた要件が、マネジメント層の一声で復活し、検討を一からやり直すことになる
- 開発会社から仕様について質問されても即答できず、ユーザーに要件を再確認しなければならない
- 前任者から仕事を引き継いでも、現状の整理に追われて作業が進まない
検討経緯を残す仕組みを作る
こうした事態を防ぐために、PMO が「検討経緯を残す仕組み」を作る。議事録や課題管理表のフォーマットを見直して経緯を書きやすくし、検討資料を格納する場所をプロジェクトの文書サーバー上に作る。
キーワード
自分の理解
今なら、検討資料を置く場所は Notion 一択だと思う。
PEP（Python） の Rejected Ideas の節も、これの一種である。議論の中で出たが採用されなかった案を、採用しなかった理由とともに記録する（ソフトウェア設計のトレードオフと誤り）。