今回からは、ドキュメント構造を活用した資料作成のポイントを、出来の良くない資料をレビューして修正する具体例を使って解説する。
図1に示す例文を見てほしい。この文は、既存システムに対する追加開発の見積もりを行ったときに起きた問題について検討し、再発防止のための対策を説明したものである。
よく書けている資料なら、最初から終わりまで後戻りすることなく読んで、内容を明確に理解できる。しかし、この資料のように、一度読んだくらいではさっぱり理解できないことは多い。
ここまで出来が悪い場合、細かい指摘をしてもきりがない。よく使われるドキュメントの構造を当てはめて理解し、改善の指針を示すほうがよい。
図1のような改善提案の資料の場合、よく使われる基本の構造を覚えてほしい。問題点の明確化、原因の分析、解決策の提示、の3つの項目からなる構造だ。問題が単純な場合や繰り返さない場合には、原因の分析の項目は省略できる。
この構造を頭に入れて例文を見ると、前半で問題を2つ指摘し、後半に解決策を2つ示している図2の構造のように見える。しかし、この観点からすると不思議なのは、対応策に対応する課題1と課題2を逆順に記述しているところだ。
基本の構造で資料を組み立てるとき最初に着眼すべきは、問題点に納得感があるかどうかだ。問題が重大で誰もが対策を打つべきと考えるものでなければ、資料に納得感は出ない。この観点からは、2つの課題のいずれも十分な説明とはいえない。
課題1は「見積もり依頼をするために必要な情報がそろっているかが不明である」とある。記述を文字通り読むと、情報がそろっているかが不明なことが問題だという指摘である。しかしこれでは意地悪く、目的である見積もり依頼ができれば情報がそろっているか不明でも構わないではないかと突っ込みたくなる。
もちろん、そんなことが言いたいわけではないはずだ。おそらく必要な情報がそろっていないため見積もり依頼ができないことがある、ということを遠回しに表現しているのだろうが、明確ではない。読み手に意図をくみ取ってもらわなければいけない不明瞭な記述である。
課題2は「記述内容が整理されていない」とある。この記述はさらに曖昧である。整理されていないという表現から悪そうな印象を受けるが、実際には何のことか分からない。理解できるのは、他業務システムへの見積もり依頼をするのに十分ではないということまでだ。
