はじめに
「設計書を書く時間がない」
「UMLの表記法を覚える学習コストがもったいない」
開発現場でよく聞く言葉です。
しかし、その一方で私たちは何千行・何万行にも及ぶコードを解析するために、何日もコミット履歴を遡り、影響範囲を調査し、仕様を推測しています。
ここで一つの疑問があります。
なぜ私たちは、UMLという共通言語を学ぶコストには敏感なのに、その何倍もの時間をコード解析に費やすことには慣れてしまっているのでしょうか。
コード解析に要するコストは単発で終わらず累積的に拡大します。
これはコードが単体で完結せず、依存関係と変更によって理解対象そのものが変化・拡大し続けるためです。
私は近年のシステム刷新案件やレガシーシステムの保守を見ていて、この点に強い違和感を覚えています。
本記事では、レガシーシステムの保守で発生する「設計意図の喪失」という問題を題材に、UMLやオブジェクト指向モデリングの価値について考えてみます。
1.意図を捨て、詳細に埋もれる
多くの現場では、
「設計書は実態と乖離している」
という理由で設計資料が更新されなくなります。
結果として、
コードが唯一の情報源になる
設計意図が失われる
システム刷新時に大規模な解析が必要になる
という状況が発生します。
設計モデルが存在する場合、構造や責務は比較的短時間で把握できます。
一方、設計意図が失われたシステムでは、
「なぜその実装になったのか」
をコードから推測しなければなりません。
コードは「どう動くか」を表現するには優れています。
しかし、
「なぜそう設計したか」
を伝える手段としては必ずしも十分ではありません。
2. 西洋の「哲学思考」：アジャイルでも、なぜ彼らは「意図」が伝わるのか
「それは古いレガシーシステムの話で、モダンな言語でアジャイル開発をやっている我々には関係ない」と思うなら、それこそが罠です。設計モデル(構造)のアップデートを怠り、ただ目の前のタスクを消化するためだけにコードを重ねれば、システムは滑らかに「つぎはぎ開発」へと変貌し、限界を迎えます。
しかし、ここで一つの疑問が浮かびます。なぜ西洋の現場では、アジャイルでコードをつぎはぎにしても、彼らはUMLを「うざい・いちいち書かない」と軽視していられるのか？
理由は、彼らの歴史的・文化的なバックボーンにあります。彼らの根底には、古代ギリシャ哲学から続く「世界にはあらかじめ、目に見えない完璧な『絶対的構造(イデア・メタモデル)』が存在する」という哲学思考が、暗黙の了解(OS)として脳内に共通インストールされているからです。
彼らは「クラス図のクラス図(構造のルール)」が脳内で完全に共有されているため、コードがどれだけアジャイルでつぎはぎになろうとも、お互いの間で設計の「意図」が自然と伝わってしまいます。ドキュメントとしてのUMLがなくても、脳内の共通言語で会話が成立しているのです。
こうした状況では、設計意図や背景の共有が十分でないまま、アジャイルの進め方だけが先行してしまうこともあります。
その場合、短期的には開発が進んでいるように見えても、時間とともにコードの理解コストが増えていくことがあるように感じています。
これはアジャイルそのものというより、意図を共有するための仕組みの有無に依存する問題かもしれません。
3. 東洋人考えなかった指向、だからこそ「意図としてのクラス図を残す」という価値――東洋の私たちが向かうべき真の道
ひるがえって、私たち東洋・日本の思考基盤は「関係性」や「流動性」を重視します。あらかじめ完璧なメタ構造を無から規定し、それを暗黙の了解(OS)として全員で共有することは、文化的に少し苦手な領域でした。
だからこそ、「UMLやオブジェクト指向の哲学基盤を、あえて真摯に『勉強』して、その重要性を知る」ことに、計り知れない価値があります。
西洋人が脳内の暗黙知で「意図」を伝えているのであれば、私たちはそれを可視化し、「意図としてのクラス図を残す」という実践で対抗するのです。
【西洋：脳内の暗黙知】
[つぎはぎコード] ──(脳内の共通哲学OS)──> 互いに「意図」は伝わる。
【日本：意図としてのクラス図を残す】
[つぎはぎの現実] ──(UMLで可視化)──> [意図としてのクラス図を残す] ──> [洗練された型を「カイゼン」する]
コードは仕様を表現する「具象(末端)」に過ぎず、「詳細」を語るのには最適ですが、「構造」や「設計の意図」を伝えるのには絶望的に不向きです。西洋の真似をしてドキュメントを捨ててはいけません。私たちは、彼らが脳内に隠し持っている哲学を「クラス図」という形で明確に遺し、チームの共通言語にする必要があります。
東洋の私たちがこの普遍的な「構造の哲学」を目に見える形(モデル)として手に入れたとき、日本のエンジニアの真の強みが覚醒します。日本のものづくりの真骨頂は、「すでに存在する型(モデル)を徹底的にリファインし、磨き上げ、誰も到達できない品質へと昇華させる『カイゼン(改良)』」にあるからです。
西洋人が残したつぎはぎのコードであっても、「意図としてのクラス図」というメスを使って美しく解剖し、その歪みを検知して、構造そのものを美しくリファクタリング(改良)していく。それこそが、日本のエンジニアが世界に対して示すべき、最も知的で強力なカウンターになります。
結論：
コードはシステムの振る舞いを正確に表現できる一方で、その背後にある設計意図や構造的な考え方までは必ずしも十分に伝えられません。
そのため、一定規模以上のシステムでは、意図や構造を補助的に表現する手段として、クラス図や設計モデルのような可視化が有効になる場面があります。
ただしそれらは「正解の設計図」というよりも、あくまで共有と議論のための道具であり、運用の中で更新され続ける前提のものです。
一方で、設計意図が十分に整理・共有されないままシステムが肥大化すると、結果としてコードのみが唯一の情報源となり、変更時の調査コストが増大することがあります。
そのような状態が長期間放置されると、システム全体の理解可能性が著しく低下し、保守や刷新に大きな負荷がかかるケースも見られます。
このような問題は特定の組織や文化に限られるものではなく、設計と運用のバランスを欠いた場合に共通して起こりうる構造的な課題だと考えています。
特に大規模な基幹システムでは、初期設計の意図が失われたまま運用が継続されることで、後からの変更が困難になる例も報告されています（いわゆるレガシー化の問題）。
したがって重要なのは、設計図そのものの有無ではなく、設計意図を継続的に更新・共有できる仕組みを持ち続けることだと考えます。
執筆協力：Gemini, ChatGPT
参考文献
リチャード・E・ニスベット『木を見る西洋人、森を見る東洋人』鈴木主税訳, ダイヤモンド社, 2004年