今から40年以上前の1980年、M. Lehman 氏が提唱した「リーマンの法則（Lehman's Laws of Software Evolution）」は、ソフトウェアが最初にリリースされたあと、時間の経過とともにどのように変化・劣化していくかを示した、ソフトウェア工学におけるきわめて重要な経験則です。
Programs, Life Cycles, and Laws of Software Evolution
8つの法則
1. 継続的変更の法則（Continuous Change）
システムは、現実世界で使い続けられる限り、変化し続けなければならない。さもなくば、次第に役に立たなくなる。
ビジネスの状況、ユーザーの要望、周囲の技術スタックは常に変わります。システムが今の価値を維持するだけでも、常に変更を加え続けなければ時代遅れになってしまいます。
2. 複雑さ増大の法則（Increasing Complexity）
変更を繰り返したシステムは、複雑さが増していく。それを抑えるための特別な作業（リファクタリングなど）をしない限り、変化への対応力は低下する。
いわゆる「技術的負債」や「スパゲッティコード」を予言した法則です。機能追加ばかりを優先し、コードの整理（内部構造のクリーンアップ）を怠ると、変更にかかるコストが雪だるま式に増えていきます。
3. 自己規制の法則（Self Regulation）
システムの成長速度（リリースごとの変更量や不具合数など）は、組織やプロセスの限界によって、一定の範囲に自己規制される。
無理に大量の変更を一度に詰め込もうとしても、バグの多発やレビューの遅延が発生し、結果的にプロジェクト全体の進化スピードは一定のフィードバックループ（均衡状態）に落ち着くという法則です。
4. 組織的安定の法則（Organizational Stability）
プロジェクトに投入する人員や予算を増やしても、システムが進化する実質的な効率（生産性）はほとんど上がらない。
人月を2倍にしても、コミュニケーションコストやアーキテクチャの制約があるため、成果が2倍にはならないという法則です（『人月の神話』にも通じる概念です）。
5. 習熟度保持の法則（Conservation of Familiarity）
1回のリリースの変更量（追加・削除・修正）は、統計的に常に一定の枠内に制限される。これを超えて無理な量をリリースすると、開発者全員の認知限界を超え、クオリティの崩壊を招く。
6. 継続的成長の法則（Continuing Growth）
ユーザーの満足度を維持するためには、単にバグを直すだけでなく、時代に合わせて機能や対応領域を増やし続けなければならない。
7. 品質低下の法則（Declining Quality）
変化する現実世界（環境）に追いつけないシステムは、たとえコードにバグがなくても、ユーザーから見て相対的に「品質が落ちた（使い物にならない）」と感じられるようになる。
8. フィードバックシステムの法則（Feedback System）
ソフトウェア開発プロセスは、組織、人間、コード、ビジネスが複雑に絡み合う「多角的なフィードバックループ」そのものである。この動的なサイクルを意識した管理を行わなければ、プロジェクトは制御不能になる。
プログラムの3つの分類（S, P, E型）
S型（Specification-oriented）： 正解の仕様が数学的にカチッと決まっているもの（例：最大公約数の計算、8クイーン問題など）。
P型（Problem-oriented）： チェスのようにルール（仕様）は決まっているが、現実的に全パターンを計算しきれないため、近似値や独自の解法アルゴリズムを組み込む必要があるもの。
E型（Evolutionary）： 現実世界そのものをモデル化し、ビジネスや人間と密接に関わりながら「進化し続ける（Evolutionary）」もの。（※リーマンの法則が適用される対象です）
E型プログラム（Evolutionary）の複雑性
E型プログラムは、システムが「現実世界の一部」になる
E型プログラムは、システムが導入されることによって、現実世界のビジネスや人間の行動そのものを変えてしまいます。
つまり、システム自身がモデル化対象の「世界の一部（埋め込み型）」になるため、概念として「システムが自分自身をモデル化している」ような状態になり、本質的に最も変更の圧力が強くなります。
私たちはつい「システム」と「現実世界（ビジネスやユーザー）」を切り離して、システムを現実を一歩引いたところから眺めて自動化するツールのように捉えがちです。しかしリーマン氏が指摘したのは、「システムを導入した瞬間、現実世界そのもののルールが書き換わってしまう」という現象です。
現代の「E型システム」の具体例
① メルカリやヤフオク（C2Cフリマアプリ）
導入前： 人々は不用品をリサイクルショップに売るか、捨てるだけでした。
導入後： 「あとでメルカリで売ればいいや」と考えて買い物をしたり、発送しやすいように商品の箱を綺麗にとっておいたり、梱包資材がコンビニで大量に売られるようになりました。
結果： システムの存在が、人間の消費行動や物流という「現実世界」の仕組みそのものを変えてしまいました。当然、システム側もその変わった現実（新しい詐欺の手口、梱包・配送ニーズの変化）に合わせて変わり続けなければなりません。
② Uberや出前館（マッチング・配達システム）
導入前： 飲食店は自前の出前ルートを持つか、来店客を待つだけでした。
導入後： 「ゴーストレストラン（客席のない出前専門店）」という新しい業態のビジネスが現実世界に誕生しました。また、街中に配達パートナーという新しい働き方（ギグワーカー）が溢れるようになりました。
結果： システムが新しい経済圏（現実）を生み出し、今度はその新しい現実（配達員の交通ルール問題、インセンティブの最適化など）に対応するために、アプリのアルゴリズムを常にアップデートし続ける必要に迫られています。
システムは「自分の尻尾を追いかける」
リーマン氏はこの現象を「コンセプトとして、プログラムはその内部に『自分自身（の実行結果）』をモデル化して含んでいる」という趣旨の表現で説明しています。
- システムを作る
- 現実世界に導入する
- 現実世界が変化する（システムに適応する）
- 変化した現実に合わせるため、またシステムを作り直す（1に戻る）
この「自分の作った変化の波を、自分で追いかけ続ける無限ループ」こそが、リーマンの言う「E型システムは本質的に変更から逃れられない（inherently even more change prone）」の正体です。
開発者やビジネスオーナーが「これで完成！あとは運用するだけ」と思っても絶対にそうはならない理由です。
まとめ：大きく育ったシステムに、プロペラ機の単純さを求めてはいけない
「E型プログラムは、現実世界の一部となり、そのフィードバックループによって変更圧力がかかり、複雑になる宿命である」
リーマンの法則が示すこの冷徹な現実を前にしたとき、ビジネス層もエンジニアも、まずは一つのあきらめを出発点にする必要があります。
- 長く運用すれば、システムは複雑になって当然である。
- システムが育つほど、変更要求への対応も遅くなって当然である。
この「システム固有の重力」を受け入れることこそが、本当のソフトウェア工学の始まりです。もはや「リファクタリングの時間がある・ない」という次元の対立で消耗している場合ではありません。私たちは「システムのどこを、どのように複雑度を減らすか」を、常に戦略的に考え、実施し続けなければならないのです。
実は、このあきらめの視点を持ったことで、ぼくが抱いていた「ぼんやりとした懸念」が解消しました。
たとえば、数十万行に育った密結合なMVCコードを、機能ごとの「コンテキスト構造」へリファクタリングしたと仮定します。たしかにコードは探しやすくなり、手元の修正は劇的にしやすくなるでしょう。しかし、全体として「数十万行のコードが存在する」という絶対的な複雑さは変わりません。（★懸念1）
ならばと、サブシステムとして別リポジトリに切り出してみます。しかし今度は、API連携の依存関係やネットワークの不確実性という、別の次元の複雑さがシステム全体に呼び込まれます。（★懸念2）
ここで行き着いた結論は非常にシンプルです。
「大きく育ったシステムに、小さいシステムの単純明快さを求めること自体が、そもそも間違いだった」ということです。
アメリカの映画に出てくる農薬散布のプロペラ機なら、1人のベテラン整備士が全体を見回り、常にピカピカでシンプルな状態を維持できるでしょう。しかし、大きく育ったシステムは「エアバスA350」といえるでしょう。エアバスのコックピットの裏側に詰まった膨大な配線を見て、「シンプルじゃない！」と嘆くのはお門違いというものでしょう。
エアバスに必要なのは、全体をプロペラ機のように単純にすることではなく、「主翼」「エンジン」「コックピット」と強固な隔壁（コンテキスト）で分離し、1人の人間が一度にロードすべき認知負荷を限界まで下げる「構造の秩序」です。
だからこそ、システムが大きく育ってきたチームには、目の前のコードの実装（パーツの組み立て）が得意なエンジニアだけでなく、システム全体の飛行バランスを保ち、境界線を死守する「アーキテクト視点」を持つエンジニアの存在が不可欠になるのです。
ビジネスの願望や根性論では、E型プログラムが持つ進化の重力（エントロピー）には絶対に勝てません。データと構造を味方につけ、この複雑な生き物と「大人のエンジニアリング」で安全に共存していくこと。それこそが、提唱から40年以上が経った今なお、リーマン氏が私たちに突きつけている最大の教訓ではないでしょうか。
