ドキュメントハックス - 書かない技術 | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

ドキュメントハックス-書かない技術 ~ムダな文書を作り方からカイゼンする~ [マイコミ新書] (マイコミ新書)


この本は、誰もが億劫になりがちなドキュメント作成作業をプロセス化し、その効率化とその重要さ、そしてドキュメント作成の楽しさと言うものを発見させてくれる本です。


ドキュメントの作成と言うのは


- ユーザーに理解を促進させるため

- 知識を共有化・平準化するため

- 事の顛末を事実として記録するため


など、多くの用途で作るものですが、私も含め大体の人は「作らなくてはならないもの」と決め付け、その作業に意義を感じず淡々とこなしていくと言う人が多いのではないでしょうか。

明確な指示が出るわけでもなく、何処にゴールラインを設定されるわけでもなく(または物凄く漠然に)、ただそれをやれと言う命令だけが下され、それ故に何を書けばよいのか、誰に向けて書くものなのかが分からずに、なんとなく書き上げられていっている。


そうして作り上げられたドキュメントは、誰の役に立つわけでもなく、ただ「その項目に該当するドキュメントが存在している」と言うだけの大義名分しか与えられません。

つまりその作ったドキュメントに対して、「君はユーザーマニュアルという冠だけを頭にかざしていればいいんだよ」と言っているわけです。

それが役に立つかどうかはまったくの別問題。


ただ、これには先ほども述べた通り、ドキュメント作成を支持する側が何の目的で、誰に読ませ、何処にゴールラインを設定するかという視点と、ドキュメントを作る側の、与えられた指示の中でその対象になる人が求めているものが何なのかを考える視点が抜けているところに問題があります。


この本では、そういった作業をプロジェクトの推進と同じようにプロセスとして明確化し、各作業の意義とそのゴールライン、そしてそれによってもたらされる効果を明確化にしてくれます。
ドキュメントの作成自体にPDCAサイクルを当てはめて、それぞのフェーズで注視すべき点が述べられています。


ドキュメント作成においてそのような事を考えた事があるでしょうか?

多くは時間の制約があり、とりあえず作ってみて、そしてチェックを行ってもらうというのが一般化しているのではないかと思います。

また、チェックを行ってもらうのもそのPJをリードする人のみになっていて、チェックの仕方もあくまでのその人の視点から見た意見が反映されているだけという場合が多いのではないでしょうか。

別の人に見てもらったらまったく違う事を指摘されたり。


この本では、「ドキュメントの合格点は70点」としてドキュメントのチェッカーによる考え方の差(それほど重要では無い部分)を切り分けるように解説されています。


ドキュメントハックス-書かない技術 P.20

ドキュメントは、減点しやすいという性質を持っています。良いところを見つけて褒めるよりも、減点箇所を挙げるほうがたやすいのです。
 全ての人が満点をつけるドキュメントは、まず存在しません。

この考え方を持っている人は意外と少ないようにも思えます。

ドキュメントの中で重要なポイントは何処なのか?そこが抑えられていれば細々とした事項の漏れなどはさほど問題になりません。

しかしながら、現場においては多くはその細々としたところのみが注視されているようにも思えます。

また、この本にはドキュメント作成時に役立つツールの紹介や、ドキュメントのチェックや改善する際に、具体的にどのような作業を行えば効率化できるかが、著者の経験から紹介されています。

この本はドキュメントを作る側の人だけでなく、それを管理する人にも読んでもらいたい本ですね。