システムエンジニア (SE) や
プログラマー (PG) は
ソースコードの他に
さまざまな文書を書かされます。

  • 開発計画
  • どの様な機能を作るかの「機能仕様」
  • どの様な設計を行なったかの「設計仕様」
  • どの様なテストを行なうかの「テスト仕様」
  • コーディング規約などのルール

確かにほとんどのソフトウェアは
チームで作られており、
意識や知識を共有しておかないといけないケースは
多いのですが、
しかし、それを常に文書として残す事・・・
即ちドキュメントで解決しようとするのは
安直です。

なぜなら、
「ドキュメントは負債」
だからです。

ドキュメントが負債というのは、
まず、ドキュメントを書くのにコストがかかります。
そして、更に仕様等に変更があると
そのドキュメントも修正する必要が出てきます。

つまり、ドキュメントは
一度作ってしまうと
その先、何か変更がある度に
修正のコストが発生する事になってしまうのです。

それを避ける為には
極力ドキュメントは書かない事です。

では、書かない為にどの様にすれば良いか・・・

それは、まず
「自分はなぜドキュメントを書こうとしたか?」
目的を考える事です。

例えば、自分が作ったプログラムの
インタフェースについて
知って欲しいという事であれば
JavaDoc や Docbook の様な
ドキュメント自動作成ツールがあります。

設計について、
知って欲しいという事であれば、
そもそもドキュメントに残すのではなく
一目見て分かりやすい設計にするという
アプローチもあります。

もちろん、ドキュメントを
全く書かないで開発というのは
なかなかできません。

但し、ドキュメントは負債だという事を
知っておいて、極力少なくし、
何も考えずに
「ドキュメントにして残そう」といった
安易な考えには走らない様にするべきです。