業務分析書・要求定義書やデータベース定義書について、説明の必要はないでしょう。
データベース定義書の中には、意味や流れの理解につながる資料を含みます。
詳細な外部設計書を重要視する根拠は、顧客が理解して承認できるのは、あくまで外見(外部から見た動作結果)からであるという認識に基づきます。
もちろん、完成したプログラムを検証する際も詳細な外部仕様が基準となります。
動かしたときにどうなるかという詳細な情報をもとに、実際の動作を確認して、仕様通りかどうか承認を得るのがキモです。
内部仕様がどうこういっても、意味がありません。
外部設計書から内部設計書を書き出すときに、記述の視点の違いから発生する誤解は非常に危険です。
紙の上で複雑な伝言ゲームをしているようなものです。
あるドキュメントをよりわかりやすくしようとするあまり、多くの情報を排除してしまったり、よく根拠がわかっていないまま、(内部設計は外部設計と別の人が担当する場合が多いため)表現を変更してしまうと、次の段階ではその表現がひとり歩きしてしまい、そこからまた別の表現に変換されることもあります。
こういったことが繰り返されると、webライティング型プロジェクトに大きな影響が及びます。
まさに伝言ゲームですが、どういうわけか日ごろ携わる開発では無頓着なようです。
目の前の「理解しにくい」事柄の対処だけに注意がいってしまい、「わかりにくいよりはよい」という、一見反論しにくい理由によって少しずつ、ですが確実に本質からズレていきます。
したがって、webライティング型システム研究会は、情報が重複しそうなドキュメントは極力排除します。
ドキュメントの同期をとるなどの変更管理が仕事なのではなく、「顧客にとって利益のあるサービス」を定義し、そのサービスを提供する仕組みを「作って動かす」ことが仕事です。
この鉄則を実現できる限りは、意識的にほかの作業を排除するべきです。
後々のメンテナンスのために内部設計書が必要という考え方もあるでしょう。
ですが、具体的な実装に関する情報を、いずれにしても、メンテナンスの実作業者は何をしたいwebライティング型システムなのか頭に入れたうえでソースを読んで理解する必要があります。
その理解には、なぜそういった仕様なのか、どうしてそう作っているのか、結果として外部仕様の何を実現しているのかという情報の方が内部設計書よりはるかに重要です。
