AIBR プレミアム
拓海先生、最近現場から「予測だけしても意味がない。何を変えればよいか知りたい」と言われまして、ちょっと困っているんです。要するに予測ではなく、現場で使える『行動プラン』が必要だという話でしょうか。
素晴らしい着眼点ですね！その通りです。多くのソフトウェア解析（software analytics）は「これが起きる」と予測することに注力していますが、この論文は「では何を変せばいいか」を示す行動可能なプラン（actionable plans）を重視していますよ。
なるほど。ただ、それを現場に落とすと工数やコストの議論になります。投資対効果はどう見ればいいのですか。
大丈夫、一緒にやれば必ずできますよ。整理すると要点は三つです。第一に、行動プランは具体的でなければならない。第二に、プロジェクト内データがあるならそれを優先する。第三に、外部プロジェクトの良い例を使う場合は同じくらい有効かどうか検証する必要がある、という点です。
具体的というのは、例えばどんなレベルの指示ですか。現場だと「コードを直せ」だけだと現場は動けません。
いい質問です。分かりやすく言うと、単に問題を指摘するのではなく、隣接する「より良いクラスタ（より良い状態）」との差分を示すのがこの論文の手法です。たとえばコードのモジュールAの複雑度をXからYに下げるといった具体的変更点がプランになります。
これって要するに、過去の良い事例と比べて何を変えれば不具合が減るかを教えてくれるということ？
その通りです。要はクラスタリングで近いグループを見つけ、品質が高いグループとの差（コントラスト）をプランとして抽出します。それをプロジェクト内データで行うのがXTREE、外部の代表例（bellwether）から持ってくるのがBELLTREEです。
外部のデータを使う場合、ウチの製品と違う部分が多いと信用できない気がします。現場への導入はリスクが高くないですか。
不安は当然です。論文でもBELLTREEは常にXTREEに勝るわけではないと述べています。ただし一部のケースではBELLTREEが有効であり、社内に過去データがない場合は有力な代替手段になります。重要なのは検証プロセスを設けることです。
検証というと具体的にはどんな工程を入れればいいですか。小さく試して効果を見て拡大するイメージですか。
まさにその通りです。小さなリリースやA/B的な運用でまずは数件適用し、効果と現場負荷を評価します。要点を三つにまとめると、まず小さく試す、次に定量的に効果を測る、最後に現場の負担を定性的に聞く、です。
分かりました。では社内で試すときの優先順位はどう決めればよいですか。まずはコストが低く効果の見込みが高いものを狙うべきでしょうか。
その通りです。ROIを意識して決めるのが現実的です。まずは低コストで実行しやすい変更を選び、効果が確かならばより大きな変更へ拡大していくと良いでしょう。大丈夫、順を追えば必ずできますよ。
では私の理解を整理します。要するに、1) プロジェクト内のデータからクラスタ差分で具体的な変更案を作る（XTREE）、2) もし社内データがないなら代表的事例から借りる（BELLTREE）、3) どちらも小さく試して効果を確かめる、という流れで進めれば現場に無理をかけず導入できる、ということですね。
その理解で完璧です！素晴らしい整理力ですね。さあ、次は実際のデータで小さなPoC（概念実証）をやってみましょう。私が伴走しますから安心してください。
