10年以上運用されているレガシーシステムをもつIT企業各社の運用事例をまとめてみました。
長期的に運用されるシステムではどんな課題が生まれるのか、その課題を各社はどうやって乗り越えているのかを知ることができる記事や本を読むことで、長期的に使われうるシステムに負債をうめこまないようにするにはどうするといいのか？を学べる。
これから長期的に使われうるプロダクトを絶賛開発中のエンジニア、長期的に運用されているシステムの開発にたずさわっているエンジニアの方の参考になればと思います。
10年以上運用されているレガシーシステムの運用事例
それでは、10年以上運用されている国内IT企業各社のレガシーシステムとの付き合い方の事例を見ていきましょう。
はてな：はてなブックマーク
2005年にベータ版としてリリースされたはてなブックマーク機能。
Perlで書かれていたコアアプリケーションをScalaでリライトしたはてな社の開発事例。
初学者にとって学習コストが比較的高めなScalaを利用する上で学習コストが上がりすぎないようにライブラリは難しいものは採用しないこと、DDD（ドメイン駆動設計）の徹底、レイヤードアーキテクチャの徹底がされているのが特徴的ですね。
これまでのコード資産も負債も捨ててフルリライトするという決断ができるのがスゴイ。学ぶべきところが多い事例。
一休：一休.comレストラン
2006年にリリースされた一休.comレストランの開発事例。
レガシーシステムの改善は、組織やソフトウェアによって固有なものであるから、「これが絶対に正しい！」という銀の弾丸はないこと。一方でデファクトスタンダードを知っておくことで、自社の事例にも活かせることがあるしアンチパターンを踏みにくくなるから知っておくべきだ。ということがわかる。
外部技術顧問としての客観的な立場から同社の改善サポートをしていた時期もあり、今は一休でCTOとして改善を推し進めているNaoya Ito（@naoya_ito）さんの視点から分析されていて目からウロコがよく落ちる。
Yahoo! JAPAN：GYAO!
2009年にUSENのGyaOとYahoo!動画が統合されて生まれたGYAO!のWeb刷新の事例。
同一のUX要素が散財、表示パフォーマンスの低さ、ビジネスロジックの局所化ができていないことによる拡張性の低さ、それによる仕様の複雑化、開発フローの複雑さなど、様々な課題を抱えていた状況からどのように段階をわけて改善していったのか学べるよい記事ですね。
リクルートテクノロジーズ：タウンワーク
リクルートテクノロジーズのタウンワークのバッチシステムの改善事例。
SQLのチューニング、問題となっている処理の特定のためにデータフローの洗い出しボトルネックの特定をし、中間テーブルがデータレスポンスが遅くなる大きな原因になっていることがわかって中間テーブルを排除していって最終的に2時間の処理が15分に短縮できたと。
パフォーマンス改善の進め方とどうやってボトルネックを特定していくか探る方法が参考になりますね。
クックパッド：情報システム部門
1998年にサービス開始されたクックパッドの情報システム部門のシステム設計の再構築の事例。
部門ごとに予算を持たせるようにしたことで部門最適化していき、最終的に会社全体で見ると小粒なサービスがカスタマイズされたものがひしめき合う魔窟のようなシステム構成が生まれるという話は複数事業部を持つ会社のエンジニアは知っておきたい事例ですね。
各部門に関わるシステムの改修を並列的に進め、その改修にたずさわる人員も同時に採用を進めるという驚異的なプロジェクトマネジメントをどうやって進めたのか。「自分も真似してみよう！」と安易に考えても再現性は低そうですが、参考となる部分は多そうです。
VOYAGE GROUP：ECナビ
2004年にリリースされて2019年時点で15年の歴史があるVOYAGEグループのECナビの事例。
2015年から2019年まで4年間かけて大規模サービスの改善を無理せず段階的に続けるために大事にしたこととして、不要機能の削除と不要なコードの抹消をしてコードの見通しをよくしてから、インフラのオンプレからAWSへの移行を進めたなど、具体的にどうやって大規模サービスの改善を続けていくのか参考になります。
システム基盤が古くなるまで放置されてしまった経緯の話は、みんな頭ではわかっているんだけど緊急性が求められないからできないというほんとによくある例だと思います。
エムスリー：医師・薬剤師向け管理画面
パッチ的に機能追加を続けた結果レガシーなシステムになってしまったエムスリーの管理画面を2017年ごろから改修した事例。
Javaの独自フレームワークで実装されたシステムをサーバーサイドAPIをKotlin、サーバーサイドAPIの呼び出しをRailsで実装し、フロントエンドはVue.jsでフルリプレイスするというプロジェクトで、Vue.jsの経験者が社内にほとんどいない状況でVue.jsで短期間で処理を書き換えているのでVue.jsでのリプレイスを考えている方にとってはとても参考になります。
Sansan：法人向けクラウド名刺管理サービス
2019年時点で12年間の運用歴があるSansanの名刺管理クラウドサービス。
12年間の間にアーキテクチャがどのような変遷をたどってきたのかが説明されていて参考になります。
DDDに失敗した経緯も紹介されていますが、DDDの設計方針を開発組織内で共通認識として浸透させることができなかったことが原因として大きそうですね。
レガシーシステムの運用事例おまけ（運用歴10年以下）
開発されてからまだ10年はたっていないけど、レガシー化してしまわないようにシステム運用をしている各社の事例もおまけとして載せておきます。
LIFULL：HOME'S
www.slideshare.net
2011年にPCサイトリニューアルのHOME'Sを運営するLIFULLの事例。
仕様のドキュメント化、設計規約の共通認識を取ること、ピアレビューなどを通して設計規約やコード規約を実例をもとに共有することが大事なのがわかりますね。
株式会社マッチングエージェント：タップル誕生
サイバーエージェントの子会社で、恋愛マッチングアプリを運営するマッチングエージェント社の開発事例。
事業の成長にあわせて優先度の高いシステム課題を改善していくという方針で、検索システムのMongoDBからElasticsearchへの載せ替え、そもそもテストを各文化がないからコード品質が保たれないことを改善するためにTDDの講師を呼んでテスト駆動開発を推進するなど。
やめずに改善を続けていくことが何よりも大事というのも間違いないですね。
以上、「日本国内IT企業各社の10年以上運用されているレガシーシステム運用事例をまとめた」でした。
レガシーシステムの運用について学べる本
最後に、記事中で触れられていたレガシーシステムの運用方法、負債を作り込まないために読んでおきたい本もまとめておきます。
病気の治療よりも予防の方が効果的でコストもかからないのと同じで、レガシーコードも改善するよりもレガシーコードを生み出さない方が簡単でコストも安い。
では、レガシーコードを生みださないようにするには、どんな考え方で設計・実装を進めればいいのか原理原則を学ぶことができる良書です。
レガシーコードが各所にあるプロダクトコードをどのようにリファクタリングしていけばいいのか、Java言語での具体例を元に学ぶことができる良書。
原理原則とともに個別具体的な事例も学ぶことで、業務で実践できる知識が身につくのでオススメです。
記事中でも多用されていたDDD（ドメイン駆動設計）の基本的な考え方、原理原則を学ぶことができる本です。
説明が難解な部分も多くて読むのに体力がいりますが、ぜひ一度は読んでおきたい一冊ですね。
TDD（テスト駆動開発）の原理と進め方、具体的なコードの書き方を学べるTDDの教科書的な本です。
まだ読んだことがない方は、一度は読んでおきたいですね。とくに、「テストを描きたいとは思いつつも、テストを書くことができていないなぁ。」という方に読んでほしい一冊です。
データベースの設計においても、アンチパターンを知らずに設計してしまうと長期的に負債になってしまうデータ構造を生み出しかねません。
そんなDB設計におけるアンチパターンを防ぐことができる一冊。
以上5冊どれもレガシーシステムになりうるプロダクトを開発するWebエンジニアなら1度は読んでおきたい本たちだと思うので、まだ読んだことがない方はぜひ手にとってみてください。
では。
