レガシーシステムを現代化していくために本当に守るべきたった1つのこと。

拙い記事ながら 【毎日自動更新】Qiitaのデイリーストックランキング！ウィークリーもあるよ のデイリーいいねランキング(2017/12/27更新分)に載りました。

---

株式会社ラクス の @moomooya こと、鈴木です。
この記事は ラクス Advent Calendar 2017 の25日目として、1年ほど前から社内で行っているレガシーなシステムをモダンなシステムにリアーキテクトしていくパイロットプロジェクトについて書きたいと思います。

あらすじ

事の起こり

ある程度長く同じシステムを開発していくと、どうしても避けられないのがシステムのレガシー化だと思います。

レガシーシステムの定義もいろいろ¹ありますが、現場のエンジニアとして強く実感するシチュエーションの1つとしては「要求に対する対応が無理やりな実装になってしまう」ではないでしょうか²。無理やりな実装はバグを呼び、バグの発生は改善余力を奪っていく、という負のスパイラルに陥るさまは共感できる方も多いと思います。

これではいけないということで現代的なシステムを構築するプロジェクトが立ち上がりました³。

よくある足踏み

で、プロジェクトは立ちあがったものの既存のレガシーシステムにおいて現代化できる場所なんて言うのはありとあらゆるポイントがあるわけです。インフラ周りだけ見ても

• クラウドインフラを使うのか、自前インフラ使うのか
  • クラウドインフラならAWSを使うのか、Azureを使うのか、GCPを使うのか、国内サービスを使うのか
• ベアメタル使うのか、IaaS使うのか、コンテナ使うのか
• ストレージどうするの
• データベースどうするの
• ログ監視、プロセス監視どうするの
• パブリッククラウドには置きたくないデータ⁴もあるんだけれど

とまあ今までの鬱屈を晴らすようにいろいろ出てきて、それぞれの観点でさらに製品、サービスがいろいろある、という状況。
とりあえず上層部からの要求として「クラウドインフラは試してほしい」「マイクロサービスアーキテクチャは試してほしい」というのがあったので、独断と偏見でAWSのサービスを出来るだけ利用する方針に絞り込み。

あるあるな話で「既存サービスに適用してほしいけど、障害は起こしてほしくない」という話も出てきたので、エンジニアが使っている社内向けサービスのリプレイス案件として取り組むことに決定⁵。

本格稼働

リプレイス対象の社内向けサービスの設計書と既存ソースから、機能ごとにアクセスしているDBのテーブルを書きだして、どの単位でマイクロサービス化したらよいかをゴリゴリとお絵かき。他のプロジェクトメンバーに見てもらったところ「風呂敷広げすぎなので絞り込みましょう」と絞られ⁶初期スコープが決まりました。

その時のお絵かきをすごく簡略化したのが以下の図。

実際にはこれにセッション管理サーバや、認証認可管理サーバがあったり、利用者向けWEB用BFF、モバイル用BFFと管理者向けWEB用BFFを分けていたりしました。

全体構成図や最初に実装する機能が決まってしまえば、何を使うかも絞り込まれるのであとは担当者を割り当てて、調査＆実装を進めていくだけです。ここからは適度につまづきながらも黙々と構築を進めていきました。

これが6月頃のことだったのでプロジェクト発足から6ヶ月ほどで実働し始めたという感じでした。

本題

で、「プロジェクトを進めるにあたって何が大事かなぁ」と考えて進めてきましたが、直接売り上げにつながる取り組みではない以上、廃れさせるのも簡単なわけで結局はプロジェクトに参加しているエンジニアのモチベーションをいかに衰えさせないことが一番なのかな、と思いながら進めていました。

モチベーションは**「上げにくく」「下げやすい」**ものだと思います。この手の取り組みは基本的には「自主的にやりたい」類の取り組みなので、モチベーションが下がる要素を極力減らすと順調に進むのかなと感じています。

• 制約は大方針に沿うためのものだけにして、細かい制約は付けない
• 担当者自身が選んだ興味関心のあるものに取り組む
• 関係者が取り組みに対して価値を理解する
• 必要なリソース（特に時間）を出来る限り確保する
• 評価者が取り組んでいる技術的な文脈を理解する

そして現状

現在は細々ながらも取り組みを進めていて

• 自動デプロイ
• コンテナでのオーケストレーション
• 自動プロセス復旧
• BFFによる複数サービスの整合性確保
• AWSフルスタックでのプロセス監視やログ監視

といったものを実現しようと動いています。

これらの成果については年度末に向けて各メンバーで記事を投稿していく予定になっていますので、こちらもどなたかのご参考になればと思います。

最後に

所属している株式会社ラクスは泥臭く取り組みを進めながらアーキテクチャ考えたり、使ったことない技術を検証して布教したり、というエンジニアを募集しています。

ご興味があるかたは弊社採用ページからご連絡ください。

1. 有名なところだと『レガシーコード改善ガイド』（マイケル・C・フェザーズ著）のテストがないコードはレガシーコードでしょうか ↩

2. たとえば、GET/POSTのみに絞ることで高効率化しているSAStrutsでRESTfulなインタフェースを実装するとか ↩

3. 最初は「開発速度を速くするための取り組みをしてほしい、オフショアとかで人を増やしたりして」というふわっとした要求＆ミスリード込みで降りてきたので、このあと関係メンバーが半年近く混乱していたという経緯もあったりしました。結論としては弾力性の高い設計にしておくことでシステムの複雑度を下げることが最適解、といった方向に持っていきました ↩

4. いわゆる機微情報（顧客データとか各種経理データとか） ↩

5. 「社外向けのサービスにも適用する前提の検証しますから」って10回ぐらい説明した ↩

6. 年間12人月分くらい使ってもいいんじゃない？ という話だったが、結局実稼働の担当者が3人で週5時間（＝月20時間x3人＝年間4.5人月分）で取り組むことになりました ↩