CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

都市が成長していく様子を観察していると想像してみてください。毎日どれだけのレンガが積まれたかを数えることもできれば、市議会がルールに従っているかを確認することもできます。しかし、都市を見るにはもっと興味深い第三の方法があります。それは、建物が「どのように」変化しているかを観察することです。人々は新しい部屋を作るために古い壁を壊しているのでしょうか？ 本館には触れずに、横に新しい翼（ウィング）を付け足しているのでしょうか？ それとも、単に照明のスイッチを切り替えているだけでしょうか？ あるいは、単に家具を配置し直しているだけでしょうか？ ソフトウェアの世界において、研究者たちが問いかけているのは、まさにこのことです。ソフトウェアは単なるコードではありません。それは、有用であり続けるために絶えず変化しなければならない、生きているシステムなのです。もしシステムが自らの壁を壊すことによってのみ変化するならば、やがてそれは不安定で危険な塊になってしまいます。しかし、新しい翼を付け加えたり、スイッチを切り替えたりすることで変化できるのであれば、そのシステムは強固で柔軟なままです。これこそが「ソフトウェア品質」の核心です。単に今日のコードが動作するかどうかではなく、明日も崩れることなく成長し続けられるかどうか、という問いなのです。

本論文は、この問いに答えるためのCLEM（Change Localization and Externalization Measurement：変更の局在化および外部化測定）と呼ばれる新しいツールを紹介しています。CLEMは、単に変更されたコードの量を数えるのではなく、開発者がシステムを修正したり更新したりする「方法」を監視する探偵のように振る舞います。それは、あらゆる変更を以下の4つの「ペルソナ」のいずれかに分類します。

1. Modification（修正 / M）: 「壁を壊す」アプローチ。コアとなるコードを直接変更すること。高速ですが、壁に穴を開けてドアを作るようなもので、リスクを伴います。
2. Extension（拡張 / E）: 「付け足し」のアプローチ。本体には触れずに、システムにプラグインする新しい機能を作ること。家の中に新しい部屋を作るようなものです。
3. Low-code（ローコード / L）: 「フローチャート」のアプローチ。視覚的なツールやルールを使用して挙動を変更すること。コードを書くことなく、ビジネス管理者がワークフローを再配置するようなものです。
4. Configuration（設定 / C）: 「スイッチ」のアプローチ。設定やパラメータを変更するだけ。音量を調節するためにダイヤルを回すようなものです。

研究者たちは、このアイデアを3つの異なるソフトウェアプロジェクト（大規模なテック・エコシステムからの公開プロジェクト2つと、1つのプライベートなヘルスケア・アプリ）でテストしました。その結果、CLEMは、システムが「健康的」な状態（主に拡張や設定を使用している）か、「不健康」な状態（絶えずコア部分をハッキングしている）かを明確に判別できることが分かりました。しかし、彼らは驚くべき発見もしました。システムの「変化の仕方」を知ることは、必ずしも翌月のバグの発生を予測することには繋がらないということです。CLEMはシステムの「構造」を理解するための優れたツールですが、将来のエラーを予言する水晶玉ではありません。

探偵の新しいノートブック：CLEMの仕組み

ソフトウェア開発を、忙しい厨房（キッチン）のようなものだと考えてみてください。長年、シェフ（開発者）は、どれだけの料理を作ったか（活動量）や、一日の終わりに厨房がどれほど清潔であったか（静的コードチェック）によって評価されてきました。しかし、もし新しいスパイスが必要になるたびに、パントリーに辿り着くために壁をぶち壊さなければならないとしたら、その厨房は崩壊に向かっていると言えるのではないでしょうか？ これがCLEлоが解決する問題です。CLEMは単に料理の数を数えるのではなく、シェフが食材を取り出すために使う「手法」を観察するのです。

本論文は、ソフトウェアシステムが更新されるたびに、その変更はいずれか4つの方法で行われ、それらの組み合わせがシステムの健康状態をすべて物語ると提唱しています。

• **Modification（修正）**は「力技」の手法です。これは、新しい棚が必要になったために、シェフが壁を壊すためにスレッジハンマー（大槌）を掴むようなものです。仕事は早く終わりますが、これをやりすぎると建物全体が不安定になります。
• **Extension（拡張）**は「モジュール化」の手法です。これは、厨房の中に転がして入れる、取り外し可能な新しいカートを作るようなものです。シェフは壁には触れず、単に新しい道具を追加するだけです。これはより安全であり、コアの構造を維持します。
• **Low-code（ローコード）**は「設計図」の手法です。マネージャーがホワイトボードに新しいフローを描き、ロボットを再プログラミングすることなく、ロボットに何をすべきかを指示する様子を想像してください。これは、より高次のレベルでの変更方法です。
• **Configuration（設定）**は「ダイヤル」の手法です。オーブンの温度を上げたり、明かりを明るくしたりするために、ただつまみを回すだけです。建設作業は一切必要ありません。

著者らは、健康的で長く続くソフトウェアシステムは、Modificationへの依存を減らし、Extension、Low-code、およびConfigurationに頼るべきであると主張しています。もしシステムが絶えずコアを「修正（Modification）」しているならば、それは「テクニカルデット（技術的負債）」を蓄積している可能性が高い、つまり、将来の安定性を前借りしており、後で利息を付けて返済しなければならない状態にあることを意味します。

実験：3つの厨房を観察する

このアイデアが機能するかどうかを確認するため、研究者たちは3つの異なる「厨房」（ソフトウェアのリポジトリ）へのフィールドトリップを行いました。彼らは単に完成した料理を見るのではなく、数ヶ月間にわたってシェフの手元を観察しました。

1. 「Fit」の厨房 (fit-framework): これはプラグインシステムとして設計された公開プロジェクトです。彼らは「Extension（拡張）」が多いと予想しました。
2. 「App」の厨房 (app-platform): これも公開プロジェクトですが、ローコードの視覚的デザイン用に構築されています。彼らは「Low-code（ローコード）」と「Configuration（設定）」が多いと予想しました。
3. 「Antisuger」の厨房: これは血糖値を管理するためのプライベートなヘルスケア・アプリです。異なるチームによって、異なるツールを用いて構築されました。彼らは、初期の混沌としたフェーズにあり、「Modification（修正）」が多いと予想しました。

研究者たちは、これらのプロジェクトにおける**607件の具体的な更新（コミット）**を分析しました。彼らは、変更されたファイルを特定するための透明性の高いルールを使用しました。もしファイルが「プラグイン」フォルダ内にあれば、それをExtensionとカウントしました。もしそれが「フロー」ファイルであれば、Low-codeとカウントしました。もしそれがコアコードのファイルであれば、Modificationとしました。

分かったこと：システムは異なっていた

結果は、まさに「健康な厨房」理論が予測した通りでした。

• App-platformは、確かに非常に「外部化」されていました。その変更の約69.5%がExtensionであり、コアへの直接的なハッキングはほとんどありませんでした。その「CLEM-ES」スコア（変更をコアからどれだけ遠ざけたかを測る指標）は、強力な+0.685でした。
• Fit-frameworkは、混合状態でした。多くのExtension（33.4%）がありましたが、かなりの割合のModification（29.1%）もありました。そのスコアは**+0.418**であり、純粋な混乱状態よりは健康的ですが、App platformほど「外部化」されてはいませんでした。
• Antisugerヘルスケア・アプリは正反対でした。その変更のほぼすべてが「Modification」が支配的であり、83.0%が直接的なコア編集でした。そのスコアは-0.659であり、まだ「壁をハッキングしている」脆弱なフェーズにあることを示していました。

これは、CLEMが「翼を付け足しながら成長しているシステム」と「壁を壊しながら成長しているシステム」の違いを、見事に特定できることを証明しました。研究者たちはさらに、ルールが公平であることを確認するために、2人の人間が160件のランダムな更新を検証しました。彼らは主要なカテゴリについて**100%**一致しており、これはルールが堅実で再現可能であることを示唆しています。

意外な結末：構造はバグを予測しない（まだ）

ここから、論文は非常に慎重な記述になります。皆さんはこう思うかもしれません。「もしシステムが自らの壁をハッキングしている（高いModification）なら、もっと頻繁に壊れるはずだ、そうですよね？」 研究者たちはこれをテストしました。彼らは、CLEMスコアが翌月に「バグ修正」が増えるかどうかを予測できるかどうかを調べました。

答えは、明確な関連性はなかった、です。
データにおいて、Modificationスコアは、翌月がバグ修正の月になるかどうかを信頼性高く予測することはありませんでした。CLEM-ESスコア（変更がいかに外部化されていたか）は、この特定のサンプルにおいては、将来のバグ修正との相関がほぼゼロでした。

これは極めて重要な発見です。著者らは、CLEMはバグを予測するための魔法の水晶玉ではない、とはっきりと述べています。これは、従来のバグカウントやコード・チャーン（コードの激しい変更）に取って代わるものではありません。その代わりに、CLEMは「異なる種類の洞察」を提供します。それは、システムの「構造的な姿勢」を教えてくれるのです。Modificationスコアが高いシステムは、今日バグが多く発生しているとは限りませんが、メンテナンスが困難で、時間の経過とともに脆弱になる可能性が高い構造を築いていることになります。それは、たとえ今日崩壊していなくても、設計図自体が悪い建物のようなものです。

なぜこれが重要なのか

本論文は、CLEMがソフトウェア・マネージャーにとって強力な新しいレンズであることを結論づけています。それは会話の焦点を「どれだけのコードを書いたか？」から「どのようにシステムを変化させているか？」へと移行させます。

• もしチームが絶えず**Modification（修正）**を行っているのを見たら、それは立ち止まってこう問いかけるべきシグナルです。「なぜ自分たちの壁を壊しているのですか？ プラグインを作ることはできませんか？」
• もしチームが主に**Extension（拡張）やConfiguration（設定）**を行っているのを見たら、それはシステムが成熟し、より安定してきていることを示唆しています。

著者らは、自身の研究の限界についても正直に述べています。サンプルサイズが小さかったこと（3つのプロジェクトから数ヶ月分のデータのみ）、そして「バグ予測」の部分が期待通りには機能しなかったことを認めています。彼らは、CLEMは補完的なツールとして使用するのが最適であると示唆しています。つまり、伝統的なメトリクスと並行して、システムの構造的な健康状態を監視する方法なのです。これは品質に対する最終的な判決ではなく、ソフトウェアシステムが成長することを学んでいるのか、それとも基礎を壊す習慣に囚われているのかを、非常に明確かつ監査可能な方法で見極めるためのものです。

要するに、CLEMは「変化の形」について語るための語彙を私たちに与えてくれます。それは、私たちのソフトウェアがスカイスクレイパー（超高層ビル）を建設しているのか、それとも単に不安定な積み重ねの上にレンガを積み上げているのかを見分ける助けとなります。そして、その区別こそが、あらゆるデジタルシステムの長期的な生存にとって、最も測定すべき重要なことなのです。