持続可能なソフトウェアとアジャイル

持続可能なソフトウェア(Sustainable software)は、変更をより短期間で顧客に提供するとともに、バグ可能性の低減、アプリケーションの総所有コストの削減、ビジネスアジリティの向上を可能にする。持続可能なソフトウェアの開発には、かんばんやスクラム、エクストリームプログラミングのプラクティスが利用できる。ソースコードの自動解析、専門家による技術的アーティファクトのレビュー、ベンチマークデータの比較を組み合わせることで、ソフトウェアの持続性を検証することが可能になる。

Software Improvement GroupでCTOを務める、“Building Maintainable Software”著者のJoost Visser氏は、Agile Consortium Belgium 2018カンファレンスで、持続可能なソフトウェアのアジャイル開発について講演し、Ventourisでの実例を紹介した。

InfoQは今回、そのJoost Visser氏と、CegekaのアジャイルソフトウェアディレクタであるJohan Lybaert氏、CegekaでVentouris開発チームのリーダを務めるTom Dufour氏に、アジャイルを使った持続可能なソフトウェアの開発と検証についてインタビューした。

InfoQ: “持続可能なソフトウェア”とは何でしょうか？

Joost Visser: ソフトウェアには、バグ修正であっても機能追加であっても、変更を施すごとにコードの構造的品質が低下するという、興味深い特性があります。特に時間的なプレッシャがある場合 - 常にそうなのですが、開発者は、構造的品質の面で妥協を迫られます。

しかし、拙速なソフトウェア変更は自滅行為です。品質の低いコードは、さらに変更が難しくなるからです。これが原因で拙速な修正の悪循環に陥ります。品質が低下することで、時間的なプレッシャがさらに高まるのです。このようなソフトウェア進化の方法が持続可能でないことは明らかです。

ソフトウェアにとっての“持続可能”とは、“進化可能(evolvable)”であるという意味に他なりません。ソフトウェア製品の品質標準であるISO 25010では、変更が容易であるというこの品質特性について、正確には“保守可能(maintainable)”という用語を用いています。

Johan Lybaert: 私にとって持続可能なソフトウェアとは、開発者が古くなったフレームワークや技術的な負債、自動テストの欠如、コードの重複、誤解を招くコメント、ToDoなどに不満を抱くことなく、アプリケーションを開発する意思を持ち続けられる、という意味です。

Tom Dufour: 私にとっては、すぐに理解できて、編集の容易なソフトウェアという意味です。

InfoQ: どのようなメリットがあるのでしょう？

Lybaert: ひとつは、アプリケーションの総所有コストの継続的な削減です。一般的な平均稼働期間が7～10年とすれば、持続可能性によってそれを10年延長することで、アプリケーションの所有者に大きな利益があります。

Visser: 総所有コスト(TCO)が低いことは間違いなく大きなメリットですが、コストだけではありません。持続可能性はビジネスのアジリティ向上にもつながります。ビジネス要件への対応が容易なソフトウェアは、市場競争において重要な差別化要因となり得るのです。

Dufour: 持続可能性のメリットは、顧客に対してより迅速に、より低いバグの可能性で変更を提供できることです。

InfoQ: 持続可能なソフトウェアの開発に対して、どのようにアジャイルを適用するのでしょうか？

Dufour: Ventourisでは、9つのベルギー社会保障基金に対して、フリーランスや企業の管理の自動化を目的としたWebベースのソフトウェアソリューションを提供しています。10年間にわたって安定して運用していますが、新たな要件は常にあります。その中には、すぐに対応が必要な法律の変更も少なくありません。

これをサポートするために、かんばんやスクラム、エクストリームプログラミングから、私たちのニーズに合ったベストプラクティスを導入しています。例えば、継続的デリバリや、テスト駆動開発、ペアプログラミングといったものを重視しています。私たちは、自らのコードを常に批判的に見ています。そのコードはどうあるべきか、それはなぜか、といったことを、ペアや同僚と適切な設計を常に議論したいと考えているのです。

Lybaert: 持続可能なソフトウェアを手に入れる上で、私たちは、アプリケーションの寿命を少なくとも8年間長くすることを保証するために、1,000人日分の改善予算の継続に合意しました。この予算には、Javaの最新バージョン、Spring、Hibernate、Wildflyのアップグレードに対応するための手段という意味がありました。

テストの所有権は独立したテストチームではなく、チーム(開発者とアナリスト)の全員にあります。結果として、まず最初にコードを書くことになるのです。

InfoQ: Ventourisのソフトウェアコードが持続可能であることを、どのように確認しましたか？

Visser: 先に述べたように、Ventourisは重要なシステムですから、将来的な開発へのコミットは極めて重要な決断です。そのためには、システムの持続可能性を徹底的に見極めなくてはなりません。実際に私たちは、保守性とセキュリティ、さらにはその将来的保証について、23の詳細な質問に答えなくてはなりませんでした。これらの質問に答えるために私たちは、ソースコードの自動解析、専門家による技術的アーティファクトのレビュー、ベンチマークデータの比較を組み合わせた、実績のある検証プロセスに従うことにしました。

例えばVentourisの品質レベルは、私たちの5つの星による評価スケールで星3つでした。これは同じ程度の年次とサイズのシステムに比べれば、かなり優れています。それと同時に、テストコードと製品コードの比率が、業界の平均値に対して約2倍であることも分かりました。

そこで私たちは、ソースコード分析とセキュリティ検査、アーキテクチャのレビュー、コスト見積を組み合わせることで、セキュリティ上の脆弱性から水平的スケーラビリティ、サードパーティや外部サービスへの依存性、そして最も重要な将来の要件に対応するための柔軟性まで、システムをあらゆる角度から評価し、判断しました。このようにして、詳細な質問に対する回答を考慮に入れることで、Ventronourisが今後10年にわたって運用可能であると結論付けることができたのです。

Dufour: 特定の領域における変更作業が増大したり、あるいはエラーが起きやすくなることのないようにしたい、と考えています。この点はすべての開発者によって、継続的に評価されています。

新機能が追加されると、そのストーリでペアモデルを実行します。開発者のひとりがコードを掘り下げて、その複雑性や依存性などを特定し、もうひとりが実装と適切なソリューションの設計を行ないます。それと同時に、実装や機能追加に先立って特定領域をリファクタリングする方が効率的ではないか、という点からの評価も実施しています。

リファクタリングに関しては、より大きなトピックが評価され、優先順位付けされ、機能上のストーリと合わせたエピックないしストーリとして取り上げられます。

Lybaert: Cegekaのアジャイルソフトウェアファクトリでは、合意された予算とタイムフレーム内で適切な開発を行なっているかを全チームが監視し、隔週で報告します。顧客やタイミング、予算、範囲、依存関係、品質に関して、それぞれのチームがPMIスタイルの進捗レポートを作成しています。作成されたレポートは、ソフトウェアファクトリの管理部門とユーザに提供されます。私たちはすべてのプロジェクト活動において、透明性と状態のオープン性を重視しているのです。レポートにはスプリントの報告や合意したSLA、障害などに関する情報が含まれています。

アプリケーションの監視は別の観点から、永続的に行っています。Ventourisチームでは継続的ビルドとデプロイの可能な環境を構築済みで、新たなコードをチェックインする毎に自動テストが実行されます。コードが壊れると、コード修正作業を最優先で行なう必要のあることを情報ラジエータが示します。テストカバレッジが100パーセントに達すれば、レグレッションを回避することが可能になります。Ventourisチームは、アプリケーション監視ツールとして“New Relic”を使用しており、トランザクションタイプ毎のSLAでパフォーマンスのフォローアップを行います。

Ventourisでは２週間のスプリントを運用していて、各スプリントの終わりに受入環境へのデプロイを実行します。当社の顧客がこの環境で検証を行ない、ACCリリースの1週間後に運用環境へリリースします。

私たちはここ数年、この安定したペースを続けてきました。これほど大規模なアプリケーションを2週間毎にレグレッションなくリリースし、週内に9件の顧客に受け入れられているという事実が、このソフトウェアがいまだ持続可能であることの何よりの証拠です。

InfoQ: 持続可能なコードを書く上で、アジャイルチームにできることは何ですか？

Lybaert: すべてのXPプラクティスを実践し、技術的負債を回避し、高いテストカバレッジ(90パーセント以上)を維持することを強く心掛けてください。チームが継続的改善活動において適切な行動を取るために、顧客と良好かつ明確な関係性を持つようにしましょう。適切なことを正しく実行(TDD、リファクタリング、DDDなど)し、チームの規律を守るためには、ペアプログラミングが重要になります。

Dufour: 適切な設計を議論し、共通知識を構築することです。大きなエピックでは、ハイレベル設計を描き上げるためにキックオフを実施する他、コードのレビュー部分に関する定期的なレビューとベストプラクティスの共有を行っています。また、定期的な教育レッスンを実施して、Ventourisの複雑な機能コンテキストや将来予想される法的変更についての情報をチームに提供しています。優れたプラクティスを探し出し、評価し、必要ならば修正する、という作業をそのサイクルで繰り返すという、反復的なプロセスです。持続可能なコードの探求に終わりはありません。

Visser: 持続可能なコードを書くために、魔法やロケット科学は必要ありません。事前条件として非常に重要なのは、規律と常識と、チームの個々が共有し集結するための明確なガイドラインです。ガイドラインに書かれるのは、15行以上のメソッドを書かない、6行以上のコードを重複しない、自動テストのカバレッジとして90パーセントを維持するといった、ごく単純なことです。そしてチーム外のすべてのステークホルダは、現在の構造的品質を犠牲にしないことが、今後長年にわたってアジャイルとハイペースな開発を続ける上で重要である、という事実を受け入れなくてはなりません。