設計書の理由と契約書の理由
情報システムの設計書には設計の結果だけでなくその理由も記載するべきである、という考え方があります。規格やガイドラインの話ではなく現場のプラクティスのようですが、理由を重要視する法の世界から見ると、なるほどと頷けるところがあります。
ここで言う「理由」というのは、「部長がそう決めたから」とか「会議でそう決まったから」といったものではなく、アプリケーション上あるいは技術上の実質的な理由（根拠）です。大半の設計にはそれがあるはずであり、それがあるからこそその特定の設計結果に落ち着いた、はずです。その記載がなければ、半年後には設計者自身にも分からなくなります。そして、無益な改良を試みて同じ結果に落ち着いたり、無謀な変更を試みて失敗に陥ったりするかも知れません。
しかし、考えてみれば設計書に理由を書かない方がむしろ不思議とも言えます。設計の労力の大半は理由の部分に費やされるというのに、最後のアウトプットの段階でその肝心のところを落としてしまうのは、いかにも効率の悪い話です。実際、企業活動で作成される文書の大半は、むしろ理由の出来不出来で評価され、それなしに決裁を通ることなど稀です。確かに、機械やプログラムは動くことが重要です。しかし、結論だけでは機械は動くかも知れませんが、その周囲の人は動きません。いや、動けません。
一方、法律界は理由が大好きです。裁判所の判決には必ず理由の記載が求められますし、その手前の様々な文書も、理由により主張し、反論し、説得しようとします。もちろん、それにも出来不出来がありますから、上手ければ説得に成功し、拙ければ失敗するばかりでなく思考の不備が露呈します。場合によっては、理屈にならない理屈、屁理屈として笑われてしまいます。
しかし、法律界にも例外的に理由の記載されない文書があります。契約書です。これもまた、（良い契約書であればあるほど）裏側に理由の網の目が張り巡らされているものですが、明示的に書かれることは極めて稀です。その「理由」は、あまりに膨大綿密であるうえ、着地点は同じでも理由（思惑）は違うから、ということでしょう。もちろん、これを補完するものはあります。それは、交渉時のやり取り文書です。これはいざというときに、解釈上の手掛かりを与える重要なものです。ただ、多くの場合は非公式の文書ともつかぬ文書にすぎません。整理と保管が欠かせません。