AIBR プレミアム
拓海先生、お時間よろしいですか。最近、うちの若い者どもが「マイクロサービスにすべきだ」と騒ぐのですが、投資に見合うのか正直よくわかりません。要するにコストと効果が知りたいのです。
素晴らしい着眼点ですね！大丈夫、一緒に整理しましょう。今回紹介する論文は、モノリシックからマイクロサービスへの移行が、コードの「技術的負債（Technical Debt、TD）」にどう影響するかを実証的に追ったものですよ。
技術的負債という言葉は聞いたことがありますが、具体的には何を指すのですか。例えばうちの現場で言えば「あとで直せばいいや」的なコードのことですか？
その感覚で合っています。技術的負債（Technical Debt、TD）とは、将来の保守や拡張を難しくする設計・実装の選択のことです。ここではコード品質やアーキテクチャの問題を定量化して、移行前後でどう変わるかを測っていますよ。
で、結論を先に教えてください。これって要するに技術的負債が減るということ？投資した分が回収できるのか、端的に教えてほしいのです。
端的に言うと、長い目で見れば減る可能性が高い、ただし短期的には増えることが多い、ということです。要点を三つにまとめると、1) 移行直後は新サービス開発で一時的にTDが増える、2) 数か月から年単位で見るとTDの増加率が緩やかになる、3) 成功には運用やリファクタリングを継続する体制が必要、ですよ。
なるほど。短期的な増加というのは、作り直す過程で手を急ぐために発生するのですか。それとも単に新しい技術の慣れの問題ですか。
両方です。論文で観察されたのは、新しいマイクロサービスを素早くリリースする過程で妥協が生まれたり、チームが新しい運用やテスト方法に慣れていなかったりして一時的にTDが増えるという点です。さらに、既存モノリスと接続するための暫定的な設計があとで負担になることもあります。
それを聞くと、現場で「先に機能、あとで直す」を続けると負債が膨らむ道筋が見えますね。運用担当の教育や、リリースルールの整備が要ると。これって要するに設計と運用のルール作りが投資回収のカギということ？
その通りです！重要なポイントは三つ、設計の分離を明確にすること、テストや監視を自動化して早期に問題を検知すること、そして継続的なリファクタリングを予算化することです。投資対効果を考えるならば、短期的コストと長期的な保守コスト低減を合算して判断する必要がありますよ。
具体的には、どの指標を使えば良いですか。コードの行数ですか、それともバグ件数でしょうか。若い奴らはSonarQubeというツールを挙げていましたが、信用していいのでしょうか。
SonarQubeはコード品質を定量化する有力なツールです。論文でもSonarQubeを用いて技術的負債を測っています。ただしツールの数値は一つの視点にすぎません。実務では自動テスト通過率やデプロイ成功率、チームの対応時間なども合わせて見ると良いです。
つまり、ツールのスコアだけで判断せず、運用指標と組み合わせるということですね。で、最後に一つ。これをうちで試す際の優先順位はどう組めば良いですか。
まずは小さな業務プロセス一つを選んで、切り出しと監視・自動テストの整備を同時に進めることです。パイロットで得た数値をもとにROIを試算し、段階的に範囲を広げましょう。大丈夫、一緒にやれば必ずできますよ。
分かりました。ではまずは一つの業務を切り出し、SonarQubeなどで技術的負債の指標を取りながら運用ルールを決め、数か月で効果を検証する。その結果で拡大判断をするということで合点がいきました。
