モノリスあるいはマイクロサービスの技術的負債を占う水晶玉 - Amam Tornhill氏の考察

QCon LondonでAdam Tornhill氏は、“A Crystal Ball to Prioritise Technical Debt”と題して講演し、技術的負債のメタファがソフトウェア界に浸透したにも関わらず、いまだ大部分の組織が技術的負債の優先的な返済に苦慮している点を指摘した。講演では、“コードの複雑性とチャーン(churn)の‘ホットスポット’を特定するには”、“コンポーネントあるいはマイクロサービスの‘一時的結合’の調査などにより、現行システムのアーキテクチャの適合性を継続的に評価することのメリット”、“チーム間調整のコストは、バージョン管理システムのコードコミットに関連するソーシャルなメタデータの調査から得られる場合が多い”、といった話題が取り上げられた。

Empearの創業者でCTOのTornhill氏による講演は、技術的負債に起因する問題についてのMartin Fowler氏の言葉を紹介することから始まった。“金融上の債務と同じように、技術的負債にも利息の支払が必要です。利息は、将来実施される開発に必要な労力という形で現れます。”これに関して、3つの主張が述べられた。すなわち、技術的負債の金利はシステム開発に費やされた時間の関数であること。すべての技術的負債が同等に作られてはいないということ。そして、技術的負債の大部分が実際には“技術的”ではない – 技術的負債とコードを作成した組織との間に強い因果関係があることだ。

次にTornhil氏は、技術的負債の効果的な優先度付けに必要な質問と情報を、‘ウィッシュリスト(Wish List)’として提案した。

• 最も金利が高いのはコードベースのどの部分か？
• アーキテクチャはシステムの進化をサポートしているか？
• チーム間の調整による生産性のボトルネックが存在するか？

最も利息の高い技術的負債を持つコードは、“ホットスポット”分析で見つけることができる。これは大規模で複雑な、あるいはチャーン率の高いコードベースの領域を、視覚的に表現するために使用可能な手法だ。コードのサイズと複雑さはSonar QubeやCode Climateなど、従来のツールで判断することができる。チャーン率やその他のソーシャルな情報は、コードベースを格納するバージョン管理システム(VCS)から、Tornhill氏のCode Maatなどのようなツールを使用して取得が可能だ。ホットスポット分析の結果の調査や解析には、MooseやCodeSceneなどの視覚化ツールや分析ツールが利用できる。

George Orwellの小説“動物農場(Animal Farm)”になぞらえて“すべてのコードは同等(equal)だが、一部のコードはさらに同等である”と言うTornhill氏は、一般的ないくつかの言語のコードベース中にあった高いチャーンが、長期的にみればコードのいくつかの領域に(対応する長期にわたって)局所化されるようになったことをグラフィカルに示してみせた。オープンソースの.NETプロジェクトであるcoreclrからファイルgc.cppを引用した説明では、このようなチャーンの局所性が関数/メソッドレベルだけではなく、クラス/ファイルのレベルでも成立することが確認できる。このセクションの結論として、技術的負債の利率を下げるためにはこれら‘ホットスポット’を優先的にリファクタリングするべきであり、その結果として、このようなコードに見られる複雑化の傾向も時間の経過とともに管理されるようになる、という点が示唆された。

続いて、“アーキテクチャはシステムの進化をサポートしているか？”という疑問が検討された。システムにはそれぞれ、複雑性が管理不能なまでに増大し、コード修正が極端に難しくなる‘転換点’がある。複雑性を定常的に監視するとともに、転換点を特定して、適切な再設計やリファクタリングで防止することが必要だ。‘一時的結合’の分析は、2つ以上のコンポーネント(クラス、レイヤ、モジュール、マイクロサービス)が絶えず同時に更新されているかどうかを適切に確認する上で、極めて有効な手段となる。同時に更新されるというのは、コード自体の単純な分析からは分からないような、アーキテクチャ上の依存関係を暗示するものだからだ。‘マイクロサービスのショットガン戦略パターン’を特定し、回避しなければならない。また、アプリケーションへの機能追加や変更が、複数のサービスに対して協調的な変更を常に強いるような時には、アーキテクチャサービスの境界設定が適切でない可能性がある。

講演の最後はソフトウェア開発のソーシャルな面にスポットが当てられて、開発者全体の潜在的な生産性とコードベース上での作業により、しばしば多くの‘プロセスロス’が存在することの指摘から始まった。チーム間の調整、あるいは‘責任の分散’は、VCSを使用して、異なるチームの開発者間でコミットのオーバーラップが発生しているコード領域を調査することで測定できる。“Conwayの法則” を計測し視覚化する手段として、Tornhill氏はこれを提案している。機能別チーム制の導入はチーム間の調整が必要なコード領域の拡大につながるため、コストが必要であると同時に、標準やスタイルの一貫的な提供の妨げになることも少なくない。技術的負債の増加を抑制するためには、“アーキテクチャと組織の調整”が強く求められる。

講演の最後には、データを意識した設計、実装、リファクタリングの実施が強く推奨された。このプラクティスは開発中のシステムが複雑になるほど重要であるとTornhill氏は考えており、実践的プログラマに向けた自身の著書“Your Code As a Crime Scene”にもその考え方が反映されている。

QCon LondonでのAdam Tornhill氏の講演“A Crystal Ball To Prioritize Technical Debt”のスライド資料は、カンファレンスのWebサイトで見ることができる。会議録音の公開は、QCon Londonのウェブサイトでも確認できます。