「開発ドキュメントを書く上で最も重要なことは、読み手を意識すること。自分が書いた文章が読み手にどう伝わるかを想像することだ」。日経SYSTEMS2012年3月号（2月26日発行）の特集で取材した多くの現場担当者は口々にこう言った。

　今回の特集のタイトルは「開発ドキュメント やってはいけない」。開発ドキュメントを作成する上でのアンチパターンを集めた。当然のようにやってしまっていること、良かれと思ってやっていたことが、実は逆効果になっている例を14個紹介する。

　一例を挙げると、「画面レイアウト図と画面遷移図を統合してはいけない」「工程でドキュメントを分けてはいけない」「議事録のフォーマットを一つにしてはいけない」などだ。詳しくは本誌をご覧いただきたいが、「なるほど」と膝を打つもの、「へぇ」と思っていただけるものなど、開発現場の知恵を集めたつもりである。

　各現場への取材では、「結局、良いドキュメントを書く上で、何がポイントだと思いますか」と聞いて回るようにした。その結果、冒頭のような意見をよく耳にしたのである。

　「読み手を意識する」のは当たり前だと思う読者も多いことだろう。しかし実際はそうでもないのである。会社で定められた標準の書式（フォーマット）を埋めているだけ、ということがよくあるのだと、多くの現場担当者は話す。

　もちろん、フォーマットに従ってドキュメントを作成することを否定しているわけではない。優れたドキュメントの書き方を定型化することで、ドキュメント作成の効率も品質も高められるのは事実だ。

　問題は、無批判にフォーマットを使うことである。読み手に何を伝えるかを考えることなく、フォーマット上の項目を埋めることが目的になってしまう。すると、そのプロジェクトでは不要な情報が載っていたり、逆に情報が不足したりすることにつながる。これが、本特集で取り上げた「やってはいけない」パターンを生み出す温床になっているのだ。

　ドキュメントを作成するときに必ず「これを読んだ人はどう考えるだろうか」と想像してみる。ほんのちょっとしたことだが、きっと良いドキュメントを書くのに役立つはずだ。特集では、読み手を意識するための簡単なトレーニング方法も紹介する。飲食店のチラシを用意してご一読いただければ幸いである。

　ちなみに、このコラムの文章は「（記者の眼の）読者が日経SYSTEMSを読んでみたくなる」ことを想像しながら書いてみたのだが、さて、うまくいっただろうか。