システム開発プロジェクトにおいてドキュメントは重要な成果物である。もし本当にプログラムだけを納品すればいいプロジェクトがあれば、コストは半分で済む・・・とおもう技術者も多いはず。
しかし、ドキュメントは絶対に必要なのである。
何のためにドキュメントがいるか？
通常よく言われるのが「保守のため」「品質管理のため」「要件・仕様の管理のため」である。
とはいえ、多くの現場で感じることは、「標準化規定にしたがって作っているこのドキュメント・・・誰が読むんだ？」「意味無いなー」「ドキュメントを作るコストのせいで、結局プロジェクトはデスマチだなー」と思っているのではないだろうか？
つまり、ドキュメントの捕らえ方に大きな間違いがあるのではないか？ということである。
さて、何のためにドキュメントがいるのか。簡単である。ずばり「人に伝えるため」である。究極的に、一人でつくって、一人で運用して、一人で使用するシステムには、備忘録メモ以上のドキュメントは必要が無い。
なぜ、開発のあらゆるフェーズでドキュメントがいるかというと簡単「人に伝えるため」である。
逆に言えば、効率よく、正確にこの目的が達せられると関係者全員がコミットするならば「コメントの丁寧なソースコード」は立派なドキュメントであり、仕様書が不要というのもうなずけるのである。
アジェンダのない打ち合わせと同じように、資料の無い他人への伝達は困難を極める。
想像してみよう。ブレインストーミング的に「どんなシステムが欲しいか」要件だしをしてみよう。とホワイトボードに列挙する。白熱した議論の末に、結構システムの仕様が見えてきた。ここまではよい。
さて、持ち帰った検討者Aは実装者Bにそれを伝えるときに、その議論を思い出しつつ、口頭で仕様を伝えてみよう。
それが、どれだけ困難か想像がつくだろうか？その打ち合わせに出ていたAは打ち合わせの内容を90%把握しているかもしれないが、Bはその半分も把握できまい。
逆にその打ち合わせを議事録にして、その内容を整理してドキュメントにする。
それをもってBに説明した場合、Bは80%は把握できるだろう。
こうやって、「意思の伝達」のためにドキュメントは重要な役割を果たす。
よく言う、ドキュメントがないと保守が出来ない。というのも同じ話である。
当初のプロジェクトメンバーという人から保守のメンバーという人に「伝達」を行わなくてはいけないから、ドキュメントは必要なのである。「人に伝えるため」なのである。
今一度、ドキュメントに意味について考え込むマネージャーの皆さん。
「人に伝えるため」という視点でドキュメントを見直してみてください。
階層が多い巨大プロジェクトのドキュメントが多い理由もわかりますか？
「人から人に伝えること」が多くなるのでドキュメントが必要なのです。
逆に、意味ないドキュメントの見直しも重要です。「人に伝えること」という視点でドキュメントを見直してください。
「人」とは未来の自分も含みます。
「誰も読まないドキュメント」は「人に何かを伝えること」を満たしていますか？
伝えるものがないから不要なのではありませんか？
ドキュメントは「人に伝えるため」に必要なものです。逆にそれを満たす方法があれば、不要です。実装コードだけでも構いません。
プロジェクトの混乱が何が起因かわからない皆さん。「人に伝える」事ができていますか？
顧客の意思は設計者に伝わってますか？設計者の意思は実装者に伝わっていますか？
実装者の意思は設計者にフィードバックされ、設計者の意思は顧客にフィードバックされていますか？
そのためにドキュメントは必要です。逆にそのためでないドキュメントは不要です。
ここには重要なプロセスのテーラリングポイントが隠されていて、多数のロールを兼任する小規模プロジェクトは必然的に他人（他のロール）に伝えることが減るので、ドキュメントを減らすことができます。
従来の開発プロセスもそのあたりをテラーリングポイントとしておくべきでしょう。
