これまでの議論からちょっとずれた話かもしれないが、ドキュメント化ということについて考えてみる。

システム開発を行なうとその工程の中に必ずドキュメント化というタスクが割り当てられる。要件定義書、機能仕様書、設計標準、データ定義書、運用手順書等々多くのドキュメントを揃えて、プロジェクトは終わる。

ちょっとここで当たり前のように作っているドキュメントって本当に必要なのか立ち止まって考えてみてもいいような気がする。なぜかというと、こうして一生懸命つくったドキュメントが稼動してからあとどれだけ使われているのかをみるとどうもあやしいのではないでしょうか。

最初の頃は開発したばかりだから、ドキュメントなんか見なくてもわかる。むしろ時間が経ってあれはどうだったかなあといって見るようになる。ところがそれにはそのドキュメントをきちんと抜けがないように永続的にメンテナンスをしなくてはならない。一度、書いてあるものと実際が合わなくなったら、その時点でそのドキュメントは信用されなくなるという宿命をもっている。そして、捨て去られたドキュメントがどれだけあるのか。

完璧なドキュメントを維持するのは不可能に近くなるということなら、いっそのことドキュメントを書かないで済まないか、あるいは、システムの一部として持つというふうには発想を変えられないかということである。

いま、内部統制やISO、セキュリティなどの絡みでドキュメント化の重要性が謳われているので、それに逆行するようなことを言っているのだけれど、単に紙に書いて残すということではなく、何か別の方法で、開発をしながら自然と仕様書だとか定義書だとかができてしまうというようにはいかないものか。

もちろん全く何も書かないことは難しいので、最小限のドキュメント化を指向すべきではないでしょうか。それが“システムの一部として持つ”ということにつながる。すなわち、泥臭くヘルプに入れてもいいですが、フレームワークやテンプレートあるいはコンポーネントの括りで機能をつかめば、そこに書いてある説明でだいたい事足りるはずだ。

例えば、家庭では家電や自動車はほとんど何も見ないであつかえますよね。そして、難しい設計書なんてもらいませんよね。

システム開発もなぜそうならないのだろう。それはみんな違ったものを作るからだとぼくは思う。だから、なぜそうしたか、どうやって作ってあるか、どう動かすかについてちゃんと説明できるものが要るというわけです。

繰り返すが、どうもドキュメント化しないといけないという常識にとらわれて無駄なことをしているように思えてならない。極論すれば、ソースプログラムがドキュメントなんだからそれ以上の説明は要らないとも言える。

このドキュメントを書かない、書かなくてもユーザは理解できるというのが、望ましいと思う。これは、具体的にはプログラムを書かない、既存のフレームワークを使う、必要最小限のことはヘルプに埋め込んでおくなどになる。それでこそユーザの使い勝手のよいＩＴになると思うのだがいかがでしょうか。