プロジェクトのなかで、様々な判断や意思決定がされても、結論に至るまでの検討経緯はなぜか、ドキュメントにされていないことが多いものです。メンバーの頭に曖昧な形でしか残っておらず、いざという時、大きなリスクとなり得ます。システム開発を進めるなかで、各メンバーは様々なドキュメントを作成します。大別すると、設計書など事前に定義された成果物と、その成果物を作成するまでの検討資料になります。前者はプロジェクトの成果物なので、抜け漏れなく作成しなければなりません。
しかし、後者についてはどうでしょう。分科会での検討資料が挙げられますが、残っていないケースが目に付きます。残っていない理由は幾つかあります。判断や結論に至るまでの内容を口頭で済ませ、議事録などになっていないケースとか、ドキュメントにはしているが各メンバーのパソコンに保管している、またはプロジェクト文書サーバーのどこにあるか分からないといったケースです。
一見すると、「成果物（設計書）さえきちんと作成されていれば、プログラミングは進められるので問題ない」という論理がまかり通りそうですが、どうでしょうか。次のような事態に直面した経験がある人は多いと思います。
1.は典型的な「スコープの揺り戻し」です。マネジメント層の朝礼暮改はプロジェクトにとって必ずしも悪いとは限りませんが、無用な議論は省きたいものです。採用しないと決めた経緯やポリシー、前提条件などを、課題管理表や検討資料にきちんと残していれば、スコープの揺り戻しを防げる確率は高まります。スピーディーに論理的な検討資料を提示できれば、マネジメント層に訴求できるでしょう。
2.は開発会社からの指摘事項について、そもそも検討漏れであったか否かを判断できていないことが問題です。仕様に関連する業務や運用の背景、検討過程が記録されていれば、検討漏れかどうかを即断し、新たな検討ポイントについてユーザーとの話し合いを迅速に開始できたはずです。ユーザーに要件を再確認するという無駄な工数はなくなります。
3.は開発作業の引き継ぎ時に、よく起こる問題です。成果物の説明だけ受けて、引き継ぎを済ませてしまった場合に頻発します。成果物を作成するに至った前提や背景まで引き継がないと、成果物資料の更新もままなりませんし、後続フェーズでの手戻りや品質悪化につながる可能性が高くなります。引き継ぎ資料に、設計のポリシーやコンセプト、前提、課題の検討経緯などが記されていなければ、前任者にドキュメント化を依頼すべきです。
幾つか例を挙げましたが、いずれも検討経緯などがドキュメント化されていれば、前述したような事態が発生するリスクを減らせたはずです。
ドキュメント化の必要性は、耳にたこができるほど聞いていたり、また痛い目に遭った経験の持ち主も多いと思います。しかし、なぜか検討資料は残らないのです。
その原因の1つは、ドキュメント化に手間がかかるためです。現場のメンバーはタイトなスケジュールのなかで検討作業を進めているため、会議が終わっても、また次の会議の準備に追われています。検討結果を成果物に反映するところまではしても、検討内容を整理し、ドキュメントに残すことは後回しになりがちです。会議で使用した検討資料の更新はおろか、議事録の作成も数週間後になり、検討内容は忘れ去られているでしょう。
このような事態を防ぐために、PMOは「検討経緯を残す仕組み」を作る必要があります。議事録や課題管理表のフォーマットを見直し、検討経緯を書きやすくすべきです。また、検討資料を格納する場所をプロジェクト文書サーバー上に作成することも必要です。検討分科会ごとのフォルダや課題ごとのフォルダを作成し、関連する資料を一元管理できるようにすれば、各メンバーの検討資料の作成や保管の一助となります。
PMOは、経緯を残す（ドキュメント化する）文化の醸成に努めることも大切です。各チームの分科会スケジュールや課題管理表を基に、検討資料が格納されているかどうかをチェックしたり、プロジェクト全体レビューをファシリテートし、客観的な視点で検討経緯や前提条件をレビューしたりすることで、ドキュメント化の文化を育むのです。リアルタイムにドキュメント化（情報の蓄積）を推進し、各メンバーの暗黙知を形式知に変える活動はPMOの重要な役割です。
プロジェクトは常に変化するものです。プロジェクトの検討経緯がドキュメント化されていれば、要件変更が発生した場合でも以前の検討結果に立ち戻って根本から検討できますし、関係者の考え方や認識が統一され、無駄な工数がかからなくなります。
確かに検討経緯を残すのは手間な作業ですし、すぐに効果が出るものではありませんが、いざという時に計り知れない効果を発揮します。特に上流工程における判断が覆ると、大きなリスクとなります。リスク軽減策として判断根拠を残すことは、プロジェクト成功の鍵となるはずです。