レガシーソフトウェアに小さな改善を積み重ね、モダンな開発体験を実現する
仕事では、20年モノのレガシーなWebアプリケーションの開発・保守を担当している。規模が大きく、多くの顧客が利用しているため、いまでも、ビジネス上の要請から、そのシステムに対する継続した機能追加は求められている。
このため、レガシーアーキテクチャ上でビジネス上の課題を解決しつつも、同時に保守や拡張が困難な部分を改善していく必要がある。
この改善活動について、エンジニアリングマネージャーの端くれとして、普段、意識していることをまとめておく。
1. レガシーコードに対するマインドセットを持つ
まず、IPA「アジャイルソフトウェア開発宣言の読みとき方」を読む。10回読む。いつでも参照できるように、印刷して手元に置いておく。
特に、原則11 「よいモノはよいチームから」の行動規範を意識する。周囲を取り巻く環境が悪いように思えても、少なくともチームの雰囲気やチームメンバーの連携は悪くない、と思えるような環境づくりに注力する。
その環境に絶望しかかったときは、レガシーコード改善ガイドの第24章を読む。何度でも読む。
レガシーコードで成功する鍵は、やりがいを見出すことです。私たちプログラマのほとんどは孤独な生き物ですが、実際には、仕事の楽しみ方を知っている尊敬できる人々と、良い環境で働くのに勝ることはそう多くありません。
第24章「もうウンザリです。何も改善できません」
そして、今まで自分たちがやってきたことを振り返り、少なくとも前よりはよくなっていることを確認する。
2. 小さな改善を積み重ねるための戦略を持つ
とはいえ、マインドセットだけではどうにもならない。現実的にそれを改善するための戦略が必要となる。
チーム全員で下記のような良質の記事を読み、それを自分たちのソフトウェアにも適用していくためにはどうすればよいのか、ディスカッションを重ねる。
既存のソフトウェアが実現している価値に敬意を払わず、単に「すべて書き直そう」としても、その複雑さ・巨大さに敗北するだけである。
3. モダンな開発体験を追求する
ソフトウェア本体のソースコードだけではなく、その開発体験に対しても、改善活動を積極的に支援していく必要がある。
CIを中心に、モダンな開発現場の開発体験と比較して「何が足りないか」を意識する。不足箇所を洗い出し、それらを整備する順番を組み立て、開発体験の向上を図る。
たとえば、ビルド・デプロイの仕組みを整える。
手動のテストケースやSeleniumなどのブラウザを通したLarge Testしか存在していない環境に対して、Pull Requestのタイミングで自動実行できるような、時間の短いTestや静的解析の実行を整備する。
テストカバレッジやデプロイ回数・成功率などのメトリクスを可視化し、改善されていることを定量的に示す。
それらにより、ソースコードの内部品質（≒保守性）を維持・向上させていく。
4. くだらない作業・手続きを捨てる
アジャイル宣言の背後にある原則10 「ムダ＝価値を生まない、を探してヤメる」を追求する。
レガシーシステムでは、これまでの歴史で積み重なったプロセス・ルールにより、変更を加えるだけでも多くの手続きが必要とされることがある。それらのうち、もはやコスト削減や生産性の向上に貢献していないものを見直し、捨て去る勇気を持つ。
もし、チームにその権限がない場合は、真っ先にそれを手に入れる。
5. ドキュメントの継続的なメンテナンス
レガシーシステムでは、仕様に関するドキュメントが残っていないことも多い。「動かしてみないとわからない」が、それを試す際にも、多くの時間や労力がかかる。
足りないドキュメントを作り、継続的にメンテナンスしていく。関係者からの問い合わせに対しては、都度回答するのではなく、ドキュメントを更新した上で、それを提示するように心がける。
6. 呼び出されていないコード、不要な機能を削除する
すでに呼び出されていないコードや不要な機能を調査し、削除する。これにより、ビルド時間の短縮、調査・保守工数の削減を図る。
現在は利用されている機能においても、将来的な価値に寄与しないものは削除できるよう、関係者に働きかけていく。
おわりに
既存のコードのレガシーさ、内部品質の低さに課題があったとしても、上記のようなことに対して取り組み、細かく改善を積み重ねることができていれば、十分に開発体験を楽しめるのではないかと思う。
もし、自分の扱うソフトウェアについて、そのような改善活動が見られないなら、そのソフトウェアには未来がない。とっとと縁を切るべきだろう。
この記事が気に入ったらサポートをしてみませんか？