拓海さん、部署から『コードの匂い（bad code smells）を直せ』って言われてるんですが、どこまで直せば効果があるのかさっぱりでして。全部手を入れたらコストが膨らむと思うのですが、何か指針になる論文はありますか？
素晴らしい着眼点ですね！大丈夫、一緒に整理しましょう。今回話すのはXTREE（XTREE: コード再編成助言フレームワーク）の研究です。要点だけ先に言うと、全部直す必要はなく、歴史データで効果が見える変更だけに注力すべき、という考え方です。
歴史データ、ですか。それだと過去にバグが多かった部分を優先する、という理解でいいですか。投資対効果（ROI）で判断するには有益に思えますが、具体的にはどうやって見つけるのですか？
良い質問です。XTREEは過去のコード指標（code metrics）と欠陥履歴（defect-proneness）を紐付けて、どの指標を変えると欠陥が減るかを探索します。要するに、実際に効果が観測されない変更は優先度を下げる、という仕組みです。
なるほど。しかし現場は『コードの行数を減らせ』『複雑度を下げろ』とだけ言うことが多くて、実際に何を変えるか迷います。これって要するに〇〇ということ？
その通りです、田中専務。要するに、一般論だけで全て直すのではなく、あなたのプロジェクトの過去のデータに基づいて、『本当に効果があった変更』に絞るということです。具体的には三つの考え方で進められます。1) 過去データに基づく変数選択、2) 推奨する変更は最小限にする、3) 変更間の相互作用を考える、です。
三つにまとめていただけると助かります。で、実務での導入はどう進めればよいですか。うちのエンジニアはSonarQube（SonarQube）を使っているので、そのデータでできるのであれば導入しやすいのですが。
大丈夫、SonarQubeのような静的解析ツールの指標を履歴として使えます。導入手順は簡単です。まず小さなサブプロジェクトでXTREEの評価を実施し、推奨が妥当かを検証オラクルで確認します。それから、効果が明確な変更だけを段階的に本稼働環境へ展開します。
検証オラクルという語は初めて聞きました。専門用語は短く教えてください。あと、これをやると現場の工数はどう変わりますか。人をかなり割く必要がありますか。
いい質問です。検証オラクル（verification oracle）は、『この変更で実際に欠陥が減るかを確かめる仕組み』です。XTREEは推奨を出した後、別の方法で効果を検証します。工数については、最初に少し投資が要りますが、無駄な大規模リファクタを避けるための投資と考えてください。結果として長期的な工数は減ることが多いです。
要は初期の評価に人手を割くが、その後は『やっても効果が出ない仕事』をやらなくて済むと。経営判断としては説明しやすいですね。最後に、社内で説明する際のポイントを三つでまとめていただけますか。
もちろんです。要点は三つです。1) データ駆動：過去の欠陥データに基づく優先順位付けを行う、2) 最小実行：効果が確認できる最小限の変更だけを推奨する、3) 検証と段階展開：推奨を検証したうえで段階的に導入し、ROIを追跡する。これで経営にも説明しやすくなりますよ。
分かりました。自分の言葉でまとめると、『過去データで効果が確認できるものだけ優先的に直して、効果が不明な広範囲なリファクタは後回しにする。まずは小さな領域で試験して効果を数字で示す』ということですね。よし、部長会で説明してみます。ありがとうございました。
