AIBR プレミアム
拓海先生、最近部下から「将来の設計のまずさを事前に見つけられる手法がある」と聞いたのですが、正直ピンと来ません。要は何が変わるのですか。
素晴らしい着眼点ですね！要点を先に言うと、今回の研究は「まだ発生していない将来の問題（アーキテクチャ臭）」を、過去の構造を元に高確率で予測できるようにする研究です。大丈夫、一緒にやれば必ずできますよ。
なるほど。で、現場に入れると本当に手戻りや費用削減につながるのでしょうか。私は投資対効果が一番気になります。
素晴らしい着眼点ですね！投資対効果に関しては要点を三つにまとめますよ。第一に、問題が顕在化してから直すより早期に対処すれば手戻りが小さいです。第二に、予測結果をレビューすることで優先度の高い箇所に資源を集中できます。第三に、ツール化すれば継続的監視が可能で運用コストを抑えられるんです。
具体的にはどのように「未来の問題」を当てるのですか。機械学習といっても範囲が広く、何を学習させるのか想像が付きません。
素晴らしい着眼点ですね！この研究ではシステムのモジュール間の依存関係をネットワークとして扱い、過去のバージョンでのつながりの履歴から「次に生まれそうな依存」を予測します。身近な例で言えば、取引先の関係図から将来の取引連鎖を予測するようなものですよ。
これって要するに、将来問題が起きそうな依存関係を事前に予測して手を打てるということですか？
その通りです！ただし注意点もあります。予測は確率で出るため必ず当たるわけではないこと、開発者によるレビューが必要なこと、そして予測から優先的に対処するための運用ルールが要ること、の三つを忘れてはいけませんよ。
運用ルールの部分が肝ですね。現場のエンジニアに余計な作業を押し付けず、経営としてどう指示すべきか悩みます。導入は段階的な方が良さそうですか。
素晴らしい着眼点ですね！段階的導入と小さなPDCAがお勧めです。まずは一部プロジェクトで予測を試し、エンジニアと一緒にレビュー基準を作ります。次に優先度の高い箇所だけを改善し、効果が出れば範囲を広げる流れが堅実です。
現場の負担を抑えるなら、経営としてはどの指標を見れば導入判断がしやすいですか。
素晴らしい着眼点ですね！経営視点では三つの数値を見てください。予測の精度、予測に基づいて修正した箇所の不具合減少、そして保守時間の削減です。これらが改善すれば投資は妥当だと判断できるはずです。
わかりました。最後に私の理解を確認させてください。要するに、過去のモジュール依存の履歴を使って将来生じそうな依存を機械的に予測し、重要な箇所だけ先回りして手直しすることで大きなトラブルを防げる、ということですね。
