ドキュメントという資産の考察(3)

何故、逆の立場になれば困るのが分かってるのに、後々必要になるドキュメントを作らない事が起こるのか。
よく言われるのが、予算の問題で、開発に必要な最低限な人員しか揃えられない事。
そのために開発に必要な設計書は積み上げられていくが、その時には必要なドキュメントだが、後から見返す用には作られていない。
下手をすれば、エンドユーザーへのレビューに耐えられるレベルまでしか作られなくて、掘り下げられたドキュメントが残ってない時もある。
また、設計書もベンダー各社で考え抜かれたであろう、仕様の決められたフォーマットを使うが、お世辞にも使い勝手がいいとは言えない。
それは、あくまでも「設計書」なんであって、後々の運用や保守・仕様追加には対応してないから仕方がないかもしれない。
未だにシステム開発は、大規模になればなるほど、水が流れるがごとく、上から下に工程が進んで行く。
台風でも来ない限り、川上に逆流する事はない。
そのため、カットオーバーして動き出したシステムと途中の工程のドキュメントが、大抵が違っている。
実際に不思議に思うのは、上流工程で設計を任されている技術者が、プログラミングの素養がない人が幅を効かせてる事。
最初はユーザーの業務用件・要望をまとめてフロー化を進めている段階はいいが、ある時点から、そういった現実世界からシステム化の架空世界に入る事になるが、話していて怪しく感じる事がある。
そのためか、業務フローのような上流のドキュメントと、プログラマーが書いたであろうクラス図の用な細かなドキュメントは充実しているが、その間をつなぐようなドキュメントは揃っていない事が多い。
しかし、本番稼働後の不具合の対応をする事を考えたら、目に見えてる不具合は、ユーザーが業務からみた現実であって、この上流と下流を繋ぐドキュメントの無さに、怒りを通り越して呆れるしかない。
実際に怒って呆れるのユーザーの方で、こっちは頭を下げるしか出来ないんですが・・・