システムエンジニア (SE) や
プログラマー (PG) は
ソースコードの他に
さまざまな文書を書かされます。
- 開発計画
- どの様な機能を作るかの「機能仕様」
- どの様な設計を行なったかの「設計仕様」
- どの様なテストを行なうかの「テスト仕様」
- コーディング規約などのルール
確かにほとんどのソフトウェアは
チームで作られており、
意識や知識を共有しておかないといけないケースは
多いのですが、
しかし、それを常に文書として残す事・・・
即ちドキュメントで解決しようとするのは
安直です。
なぜなら、
「ドキュメントは負債」
だからです。
ドキュメントが負債というのは、
まず、ドキュメントを書くのにコストがかかります。
そして、更に仕様等に変更があると
そのドキュメントも修正する必要が出てきます。
つまり、ドキュメントは
一度作ってしまうと
その先、何か変更がある度に
修正のコストが発生する事になってしまうのです。
それを避ける為には
極力ドキュメントは書かない事です。
では、書かない為にどの様にすれば良いか・・・
それは、まず
「自分はなぜドキュメントを書こうとしたか?」
目的を考える事です。
例えば、自分が作ったプログラムの
インタフェースについて
知って欲しいという事であれば
JavaDoc や Docbook の様な
ドキュメント自動作成ツールがあります。
設計について、
知って欲しいという事であれば、
そもそもドキュメントに残すのではなく
一目見て分かりやすい設計にするという
アプローチもあります。
もちろん、ドキュメントを
全く書かないで開発というのは
なかなかできません。
但し、ドキュメントは負債だという事を
知っておいて、極力少なくし、
何も考えずに
「ドキュメントにして残そう」といった
安易な考えには走らない様にするべきです。
