システム移行で「諦めるべきこと」と「こだわるべきこと」――15年物のレガシーシステム、カイゼン現場の成功例【デブサミ2019】

【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

　システムはやがて老朽化する。「レガシー」と呼ばれるほど古びた現行システムを、どのようにモダナイズするか。それはそれは長年運用してきたWebサービスやエンタープライズ系システム開発における、常時の関心事だ。少しずつリファクタリングするか、一度にビッグバンリリースするか。マイグレーションの意思決定はそのどちらかという極端な方向に振れがちだが、どちらでもない「ちょうどいい」選択肢による成功例があった。このセッションでは、VOYAGE GROUPが15年物の巨大なオンプレシステムをクラウド移行した事例を解説する。

発表は3名によるリレー形式で行われた。左から、株式会社VOYAGE GROUP ポイントメディア事業本部 開発本部 本部長 福田剛広氏、同 エンジニア 駒崎大輔氏、同 エンジニア 小林徹也氏

放置するほど悪化したレガシー問題で、状況は「がけっぷち」に

　VOYAGE GROUPが行っているサービスのひとつに「ECナビ」がある。ネットショッピングでのポイントがお得にたまるというサイトで、主婦層を中心に人気を集めるサービスだ。カイゼンに取り組んだ2015年当時のシステム状況について、VOYAGE GROUP 本部長の福田氏は「がけっぷち」であったと振り返る。

　「当時のシステムが抱えていた根本的な問題は、古くて大規模であったということです。1000を超える機能と900テーブルに及ぶデータベースは、10年以上のものが大半でした。また、2000年代頃からメンテナンスも放置状態。しかし、インフラがオンプレであることや管理部門が別組織であったことも足かせとなり、カイゼンに取り掛かろうにも、とにかく変更に時間がかかることがネックでした」

　問題を認識していたものの、その手の付けにくさから現状維持のまま事業を継続していると、事態はさらに悪化していった。技術がレガシーであるがゆえに若手エンジニアへの訴求力が足りず、エンジニア採用に苦戦していくようになる。それと同時並行して、在籍エンジニアのモチベーションも下がっていくのが見て取れるようにもなり、古い技術が引き起こす組織問題に悩まされた。さらに、使用していたデータセンターが撤退の予兆を見せたことも引き金となり、変化を検討せざるを得ない状況に達してしまう。多方から寄せる課題に追い詰められながらも、だからこそ「自分たちで変えてやる」という意気込みをもって動き始めたという。

当時のシステム構造。サーバーはWebと旧管理系の2種類が存在し、データベースはOracleとMySQLを使い分けているものの、どちらのサーバーも両方のデータベースにアクセスするというやや特徴的な構成をとっている

とった手段は「調査」と「葬り」、そして決して「無理をしない」こと――レガシー対策でまず取り組むべきこと

　現状を変えるためにまず取り組んだこと。それは「調査」と呼ばれる現状把握だ。4～5人のチームで、3ヶ月をかけて現状の調査と社員へのヒアリングを実施。その際に、「機能一覧」や「サービス全体図」などを始めとする多くの資料を新規に作成することで、見える化を図ったという。特に1000を超える機能を一覧化したことは効果が大きく、営業部門などシステム開発から遠い関係者を含めた議論の場で、大いに役立ったそうだ。

現状把握と見える化のため、多くの概要資料が新規に作成された。作成手法からも地道な手作業で行われたことがうかがえる

　次に取り組んだのは、「葬り」と名付けられた断捨離だ。社内用語で不要な機能を削除することを意味し、まずは当初6ヶ月の期間、集中的に実施した。このソリューションの価値は、機能そのものを削除するため「手間をかけずに“問題の分母”を減らす」ことができることだという。セッションでは、単純だが非常に強力な手段であると強調された。

　「調査」と「葬り」により、2015年の作業開始時点で1876あった機能数は、2019年時点で700と半分以下に減少、テーブル数も1200に膨れていた状況から813と3分の2近くまで減らすことができた。コードの行数も半減させることができたという。

コード行数は2015年当時と比較し半分に

　活動の中でもうひとつ意識したのが、「無理をしない」ということ。具体的には、まずがけっぷちだからといって「短期で」「フルリプレース」をしようとは考えないこと。この手のマイグレーションでは抜本的な対策を計画したくなるものだが、この規模のシステムで現状を全て調べて作り直すというのはコストがかかりすぎ、非現実的である。よって「長期で」「段階的にカイゼン」するということを当初から重視したという。

　もう一点、無理をしないためには、取り組む問題を絞ることが重要だとされた。あれもこれもと発散してもこの規模では終わりが見えない。その施策をとることの「価値」と、それを実現する際の「工数」の2つを評価軸とし、取捨することが大事であると語られた。そして、その両者について方向性がぶれないよう、具体的な方針を言語化するという方策をとった。価値については、「今、その課題に取り組むことで長期かつ段階的カイゼンがより加速していくか？」という問いを基準とする。工数は、「5人くらいのチームで、3～6ヶ月以内で完了できるか？」という定量的な工数指針が立てられた。

見えてきた「今すぐ取り組むべきもの」と「先送りすべきもの」

　「調査」と「葬り」を終え、残った機能に対し、いよいよ本格的なカイゼンを施していくことになる。しかし問題は大小含め山積みであるため、優先度付けを行う必要があった。そのために、まず問題をアプリとインフラに大きく分けた上で、インフラに関する対処を最優先としたという。インフラを優先した理由は、まず現行システムにはオンプレ環境という根本的な制約があったこと。加えて、縦割りの管轄があるために「段階的なカイゼン」がとれないという事情がこれまでも足かせであったためだ。一方で、アプリはすでに「葬り」で必要十分に絞ることができている。また、コントロールできるインフラが先にととのうことで、アプリケーションのカイゼンも迅速化することが見込まれたことも、インフラ優先とした理由に挙げられた。

　カイゼンの際のポイントは、「自由なインフラ」とすること。インフラとアプリの管轄を分けずに、開発者がコントロール可能な状態とすることで、対応の俊敏性を高める。また、そのためにもサービス全体をオンプレからAWSに移行することを計画した。