システム・イコール・規則
情報システムのビジネス・ロジックをどのように定義するのかは、システム開発の肝の一つです。紛争に至った場合、それがどこにどのような形で定義されているのかは、一つの重要な争点となります。原則論を言えば、要件定義や外部設計の中で、設計書や仕様書の形で定義しておくべきですが、現実には、しばしば不十分なままに終わります。しかし、不十分であれば、散逸しかけた設計メモや担当者の頭の中や、果ては対象業務それ自体から再構成する他なく、代償も大きくなります。
ビジネス・ロジックの最も驚くべき定義場所は、システムのコードそれ自体というものです。もちろん、これではシステムの出した答は常に正しいということになってしまって、検証のしようもありませんから、新規開発の場合にはあり得ません。あり得るのは、既に運用中のシステム、特に、開発後１０年、２０年と、文字どおり世代を超えて運用され続けてきたシステムです。
ある物販のシステムでは、リベート（もちろん、違法なものではありません）計算のロジックが長年、極めて複雑に調整されてきた結果、担当者ですらシステム無しには計算することができない状況となっていました。（少なくともアップデートされた）規則集や設計書類は存在せず、担当者も交代前の状況は分かりません。当然、利害関係者である取引先はあるわけですが、その取引先には何とシステムの計算モジュールそのものが提供されており、取引先はそのモジュールを使ってリベート額を「検証」していたのです。まさに、「システム・イコール・規則」という状況です。誰も本当の（合意された）リベート額が幾らであるのか、分からないわけです。
これで滞りなく運用されているなら、それはそれで良いとする見方もあるかも知れません。しかし、このシステムをリプレースする時には、どうするのでしょうか。途方もない労力をかけてリバース・エンジニアリングでもやる他ありません。この事例ほどではないですが、リプレース時には、これと似た話は良く聞くところです。「仕様は、現行システムに聞いてくれ」と。当然、開発のトラブルにつながるわけですが。