AIBR プレミアム
拓海さん、最近部下に「ソフトの設計が古くて直さないといけない」と言われて困っております。現場では不具合が増えているようですが、私にはどこが悪いのか検討がつきません。これって要するに設計が崩れてしまっているということでしょうか？
素晴らしい着眼点ですね！まず整理すると、ソフトウェアの「アーキテクチャ侵食（architecture erosion）」とは、設計どおりにコードや構成が保たれず、徐々に本来の構造から逸脱していく現象ですよ。現場の不具合増加や保守コストの増大は、その結果として現れます。大丈夫、一緒に要点を押さえていきましょう。
設計どおりに保たれない、ですか。では現場でよく言われる「違反症状（violation symptoms）」というのは、どういうものを指すのですか。部下は言葉を使うのですが私には見えないのです。
いい質問です。簡単に言うと違反症状は「設計ルールに反している実装の証拠」です。たとえば本来分離すべき層がぐちゃっと依存している、あるいは決めた設計パターンが守られていない、といった具体的な兆候です。ポイントは三つだけ押さえましょう。現れる兆候は構造的なもの、ルール違反そのもの、品質や変化時の影響という観点で分類できるんですよ。
なるほど。で、これをどうやって見つけるのですか。コードを全部人間が読むのは現実的でないと聞きましたが、機械に任せられるのでしょうか。
大丈夫、できますよ。ここでも要点は三つです。第一に静的なソースコード解析で見つかる構造的な兆候、第二に定義したアーキテクチャルールとの照合、第三にコードレビューや変更履歴（commits）から現れる運用上の痕跡です。機械学習やルールベースの手法を組み合わせることで、検出の自動化が現実的になります。
これって要するに、人間が全部目視して探す代わりに、ルールと履歴で機械が先に「ここ怪しいですよ」と教えてくれるということですか？
まさにその通りですよ！端的に言えば機械が一次スクリーニングを行い、人は重要な判断と修復の優先順位付けに専念できるようになるんです。過度な期待は禁物ですが、投資対効果の観点でも有望です。まずは小さなモジュールや頻繁に変更されるコンポーネントから導入して様子を見るのが現実的です。
導入コストと効果の見積もりについて具体的に教えてください。現場を止めずに診断できるのか、どれくらい腕のいい技術者が必要かも気になります。
安心してください。ここでも要点は三つです。まず現行システムに直接触らずに静的解析だけでスキャンできるので運用停止リスクは小さい。次に自動検出は完璧ではないため、レビュープロセスに人を残す必要があり、技術者は設計知識に強い人が一人いれば効果を最大化できる。最後に段階導入で投資負担を平準化できることです。
わかりました。では一度、社内の重要モジュールで試してみようと思います。要点をもう一度、私の言葉で整理してもよろしいでしょうか。
ぜひどうぞ。短くまとめると理解が深まりますよ。
自分の言葉で言うと、まず設計と実装のずれを示す「違反症状」を自動で拾ってもらい、重要度の高い箇所から人が判断して直す。全部を一度に直すのではなく、段階的にやって投資対効果を確かめる、ということですね。
