ここで扱うレガシーシステムは、ソースコード的なものは含みません。主にサーバやシステムのことを指します。そのためレガシーソフトウェア改善ガイドや、レガシーコードからの脱却といった書籍の内容なども登場しません。メンテナンスが行き届かずOSやミドルウェアのEoLを迎えてしまい、泣く泣く再構築することになった体験による工夫がメインのお話です。
自分がやったレガシーシステム撤去
プロキシサーバ移転、メールサーバ移転、社内DNS管理システムの置き換え、Nagios廃止、NFSサーバマネージドサービス化など
進め方
レガシーシステム撤去と立ち向かっている途中からは、SREが二人組としてタスクに取り掛かるバディ制度が取り入れられました。後述しますが、レガシーシステム撤去をするうえで二人組で取り掛かれるのはとても心強かったです。複数のバディから構成されるSREチームに自分はいます。
- 見積もりとタスク分解
- 作業前後の図を書く
- 作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件がないか見てもらう
見積もりとタスク分解
再構築と撤去をするシステムごとに見積もりとタスク分解をしてドキュメントにまとめました。ドキュメントをもとにチームに説明しました。ボツ案もチームに共有することで、チームに対してどこまで技術的な検討をしたのかを共有できました。ボツ案という、実行可能なアイデアのうち最低のものを共有することでチームメンバーに安心感を持ってもらえる効果もあったように思います。
作業前後の図を書く
バディを組んだ相手が得意なムーブがこれでした。レガシーシステム撤去作業前後の図を書くことで、システムを構成する要素の変化が伝わりやすいです。我々は忘れやすいので、数ヶ月後の自分たちも助ける効果があります。
作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件ないか見てもらう
レガシーシステムについての知見はまとまっていてもドキュメントが古くなっていたり、ドキュメントが無かったり、ドキュメントされていない機能があったりします。コード管理されているのに、実際のサーバ上でコードが編集されていてドキュメントとの乖離があるということもありえます。
こうした背景がレガシーシステムの撤去を難しくしています。また、その前段階であるシステム考古学とでも言いたくなる先人の活動の調査や、システムの変化を追っていく作業を難しくしています。
こうした背景があるため、バディで行った見積もりとタスク分解の結果や、作業前後の図が、誤った前提知識や認識により作られた可能性を排除できません。そのために作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件がないか見てもらうというステップを設けています。
ここまでが自分や自分たちがやってきたレガシーシステム撤去の作業上の工夫でした。ここからは所感コーナーです。
レガシーシステム撤去の光と闇
光
レガシーコードの撤去は、使われるかどうかはリリースした後にしかわからない新機能開発に比べて事業貢献になりやすいと友人が言っていました。対象についてのコストやレガシーっぷりがわかっており、やればいい状況であるからということでした。自分も同意する意見でした。レガシーコードであっても、レガシーシステムであってもあてはまるように思いました。しかしアピールしやすいかどうかで言うと、単純な作業をしたと捉えられやすいためにアピール方法は工夫する必要がありそうです。(自分も良いアピールができているとは思えないので、具体的な工夫の方法については書くことができません)
闇
レガシーシステム撤去は人によっては精神的な負荷が高いと感じました。先人の活動の調査や、システムの変化を丁寧に追っていく（システム考古学と呼びたくなる）一連の作業は、記憶力の悪い人間(自分)にとっては混乱してしまうことが多くありました。精神的に負荷でした。ここに関しては特にバディ制度に助けられました。幸運なことに僕のバディはこういった作業が得意であり、社歴が長いため知っている過去の経緯も多かったからです。
レガシーシステムの撤去は、本質的には本当に捨てていいのかという声との戦いであると思います。調査に時間と労力がかかってしまうことや、必要な確認事項はすでに完了しているのに捨てるアクションを取れていないということがレガシーシステム撤去のブロッカーとなっているのだと思います。事前に合意が取れている確認事項をつぶせたらサクッとつぶす必要があるように思います。そうしないとさらに年単位で生き長らえる可能性があります。それがレガシーシステム撤去の怖いところであるように思います。
この記事に書いた内容が、誰かのレガシーシステム撤去に役立てばうれしいです。
