プロジェクトの中で，さまざまな判断，意思決定がなされるが，その結論に至るまでの検討経緯は，なぜかドキュメント化されていないことが多い。各メンバーの頭の中に「あいまいな形」でしか残っておらず，いざという時，大きなリスクとなり得る。
川上愛二
マネジメントソリューションズ マネージャー
システム開発を進める中で，各メンバーはさまざまなドキュメントを作成します。大別すると，設計書など事前に定義された成果物と，その成果物を作成するまでの検討資料になります。前者はプロジェクトの成果物であるので，抜け・漏れなく作成しなければなりません。納品物件なので当たり前ですが，“過不足”があればすぐに目に付くでしょう。
では後者についてはどうでしょうか。例えば，分科会での検討資料が挙げられますが，これが残っていないケースが目に付きます。残っていない理由はいくつかあります。判断，結論に至るまでの内容を口頭だけで済ませ，議事録などのドキュメントになっていないケースとか，ドキュメント化はしているが各メンバーのローカルPCに保管している，またはプロジェクト文書サーバー上のどこにあるか分からないといったケースです。
あのとき，検討経緯を書き残していれば…
一見すると，「成果物（設計書）さえきちんと作成されていれば，プログラミングも進められるので問題ない」という論理が通りそうですが，どうでしょうか。次のような事態に直面した経験のある方は多いと思います。
（1）「システム対応しない」と決まった要件がマネジメント層の一声で復活。検討を一からやり直すことになった…
（2）開発会社から仕様に関する質問が来たが，即答できず，ユーザーに要件を再確認しなければならなかった…
（3）前任者から仕事を引き継いだが，数週間は現状整理に追われ，作業が進まなかった…
（1）は典型的な「スコープの揺り戻し」の例です。マネジメント層の朝礼暮改はプロジェクトにとって必ずしも悪いとは言いませんが，無用な議論は省きたいものです。要件を採用しないと決めた経緯やポリシー，前提条件などを，課題管理表や検討資料にきちんと残していれば，スコープの揺り戻しを防げる確率は高まります。スピーディに論理的な検討資料を提示できれば，マネジメント層に訴求できるでしょう。
（2）は開発会社からの指摘事項について，そもそも検討漏れであったか否かを判断できていないことが問題です。仕様に関連する業務，運用の背景や検討過程が記録されていれば，検討漏れか否かを即断し，新たな検討ポイントについてユーザーとの検討を迅速に開始できたはずです。ユーザーに要件を再確認するという無駄な工数はなくなります。
（3）は開発作業の引き継ぎ時に，よく起こる問題です。成果物の説明だけ受けて引き継ぎを済ませてしまった場合に頻発しています。成果物を作成するに至った前提や背景まで引き継がないと，成果物資料の更新もままなりませんし，後続フェーズでの手戻りや品質悪化につながる可能性が高くなります。
引き継ぎ資料に，設計のポリシー，コンセプトや前提，課題の検討経緯などが記されていなければ，前任者に対してドキュメント化などを依頼すべきです。引き継ぎを100％達成することはまず無理ですが，ドキュメントを残すことで，達成率を上げることができます。また，新規メンバーの参画時にも，プロジェクトの経緯がドキュメント化されていれば立ち上がりが早いでしょう。
