そもそもアプリケーションの「肥大化サイクル」はなぜおきるのか。これをKAIモデルを使って説明したのが、ASPサービスと言うビジネスモデルの本質を読み解く（２）と言うエントリーであり、アプリケーションの「肥大化サイクル」とはすなわちカスタマイズ問題のことであると言うことであります。
このKAIモデルについては、KAIモデルをキーワードにしてサイト内検索で出てくるエントリーを最初からぜひ読んでみてください。
ここで「肥大化サイクル」の具体例を説明しますが、たまたま見つけた設計者の発言さんのエントリー販売管理システムの「会計３要素」を使わしていただきます。
卸売業向けの販売管理システムは、ソフト技術者がシステム設計を学ぶためには最良の案件である。まず卸売業の企業数が多いということがその理由のひとつだが、もっと重要なのは、骨格が共通している点だ。個々の企業の特性に合わせて販売管理システムにはさまざまな違いが生じるが、基本的な骨格は同じである。
その骨格とは、筆者が呼ぶところの「会計３要素」、すなわち「仕入」、「売上」、「受払」だ。販売管理システムはこれらの要素を周到に取り扱って、その数字を財務管理システムに渡さなければならない。それらが集計される過程で企業の特殊性は捨象されてしまう。そういうわけなので、その骨格を正しく理解しておけばシステム設計はぐっと楽になる。武道において腰や腹の安定が基本中の基本であるようなものだ。
ここにあるように、この内容は入門者向けです。入門者向けですが「基本的な骨格」と書かれているように、一般的な販売管理システムを設計するための基本中の基本の要諦です。
しかしこれを実際の業務に適用しようとした瞬間に、困難な問題にぶち当たります。
それは、「売上」も「仕入」も「支払方法」と言う決済方法の問題抜きに、どんな1取引も仕訳できないと言うことです。
上掲のエントリーでは「卸売業向け」と断り書きがあるとおり、支払方法は「掛売」を前提にしています。しかし現実の卸売業は多彩です。必ず「代引き」があります。最近は「カード」「自動振替」も増えてきました。あ、もちろん「現金」は必須です。
さすがにコンビニ払いはみかけませんが、さしてB2Cとの違いも見出せなくなっているのが現状です。
そこで支払方法が「カード」の「売上」を考えて見ましょう。支払方法が「掛売」の場合はそのまま「売上」＝（顧客の）「売掛残＋」となりますが、「カード」の場合はそうはなりません。最終的に「売上」＝（カード会社の）「売掛残＋」となるのですが、顧客の与信管理、請求管理が「掛売」のままでいいわけではないと言うのは、素人の方でも簡単に察しがつくはずです。
かようにしてカスタマイズが始まるのです。
最初は「掛売」前提のシステムが組まれます。ところがクライアントの要求（ニーズ）で支払方法を増やしていくわけです。
支払方法「カード」の為の新たな与信管理、請求管理システムがカスタマイズされます。
それもこれらは「売上」だけでなく「仕入」も、まったく同様なのです。そのため当然買掛支払管理システムもカスタマイズの連続です。
さらに続きます。正の取引はこれでいいでしょう。しかし負の取引はそうはいきません。
負の「代引き」もなければ負の「自動振替」もありません。もちろん負の「現金」などあり得ません。
ところがシステムはなんでもありです。マイナスの代引き伝票が出てきたり、マイナスの現金領収書が印刷されたり。
もういいでしょう、これをどうやって解決するのかが問題です。
成長するソフトウェアの条件は、こういった「支払方法」であるとか「会計３要素」だけでなく、一つの「業界」におけるあらゆる「業務」「業務機能」を最初から前提として設計されたシステムである必要があります。
さらにその設計概念を支えるユーザーインターフェイスである必要があります。
はじめて車を設計したときのハンドル、ブレーキ、アクセルと言うインターフェイスは、その初期段階において誰も規定できていなかったと同じように、初めての「真」のアプリケーションのユーザーインターフェイスは、いまだ誰も定義していないとKAIは考えています。
すなわち成長するソフトウェアのユーザーインターフェイスこそ、この問題の最終解であると言うわけです。 KAI