No.56: そのドキュメントは審議に値するか？｜プロジェクトマネージメントのあるべき姿
prjmc staff
開発プロジェクトにおいては、設計ドキュメントの作成が必ずついてまわります。開発する対象となるものの品質は、当然設計の出来に依存するものであるし、設計内容を書き記したドキュメントの出来にもまた依存するものです。プロジェクトの進行過程において、こういったドキュメントは責任者による審査・承認作業が行われているはずですが、その出来は審議に値したものになっているでしょうか。
前回はレビューというプロセスにおいて、レビューを受ける側の資料が”自分の書けることや書きたいことは書くが、書かなければならないことを書いていない”ものになっているのではないかという問題について触れました。設計ドキュメントも、レビューを受ける側の資料の一つになります。また、レビューの場に持ち込まれるものでなくとも組織としてチェックし承認する対象となります。
私も、数えきれないほど設計ドキュメントのチェックや承認をしてきました。そして、その中で多数の審議以前の品質のもの、いわゆる審議に値しないものを目にしました。審議に値しないとはどういうことでしょうか。繰り返しになりますが、設計者が自分の書けること、書きたいことだけを書いたドキュメントです。ドキュメントに書かなければならないことが書かれていないので、審議しようにもできないのです。
何を書かなければならないかは、開発目標の性格や設計の対象によって異なるのでケース・バイ・ケースになりますが、共通的な例を挙げると次の様なものがあります。
それは、あらゆる作業にはインプットと結果としてのアウトプットがあるということです。ある設計ドキュメントを作成する場合、それは当たり前のこととして設計内容を表すものですが、その設計はインプットされた情報に基づいて行われます。そのインプットは何なのか。まずそれが明確に示されていることが審議の入り口です。顧客の要件が定義されているドキュメントがあればそれを、上位の設計ドキュメントがあればそれを、まず始点として示さなければなりません。次に、その始点からどの様な考えで設計したのか道筋を示し、そしてアウトプットとしての設計結果を示す必要があります。
設計結果に至る思考過程、いくつか考えられる設計パターンからなぜそれを選んだのかという検討過程については、組織の文化としてそこまで書くルールにはしていないかも知れません。設計結果の中には思考過程が自明のものもあるかも知れませんが、そうでない場合は、設計メモと言われる様な非公式の資料の準備、または口頭によりなぜそう考えたのか説明できるべきでしょう。その様な情報がなくドキュメント、つまり設計内容を審議しているとすれば、チェックが形式的なものになってしまっていないか要注意です。
そして、設計ドキュメントをチェックしているときに私が注意していることの一つに、目次に”概要”とあるセクションがあります。概要があるなら、その後に詳細に中身を記載するセクションが続いて然るべきですが、それがないケースを目にすることがあるのです。ある機能や処理内容について説明しているのが概要のセクションのみであり、その後の記載がその機能や処理内容について全て網羅しているのかどうかわからない書き方になっているのです。
私には、この様な”概要”は設計者の逃げにしか見えません。必要なこと全てを書き切れていないかも知れない、書き切っている自信がないので”概要”とタイトルを付けたのではないかと思えてしまうのです。設計ドキュメントであるからには書かれていなければならないことを書き切っていなければ意味がありません。
もし機能や処理内容の導入として説明したいことがあるなら、それは”目的”であるべきです。その機能や処理内容が何のためにあるのか、何をするものなのかを示すのです。設計ドキュメントの様に正確かつ精密に記載が求められるものにおいては、”概要”というセクションがあったら要注意です。
審議に値するドキュメントには何が記載されているべきか、それは、前回レビューについて触れたときと同様、皆さんの企業に蓄積されてきているはずです。過去の成功を納めたプロジェクトのドキュメントが参考になるでしょう。また、品質上の問題を招いてしまったドキュメントが反面教師として役立つことでしょう。それらの経験から積み上げられたドキュメントのテンプレートを是非作り上げてください。
さて、あなたの目の前にあるそのドキュメントは、審議に値するものになっていますか？審議に値するために、検討しておかなければならない項目は分かっていますか？
