CROOZ TECH BLOG

~読んだらわかるSHOPLISTの裏側~

CROOZ TECH BLOGとはクルーズ株式会社の開発チームが技術について共有するブログです
開発の中での発見や知識を広めてオモシロカッコイイ〇〇をツクリます。

SHOPLISTの脱レガシーシステム①(何からどう進めるか問題)

こんにちは。クルーズ株式会社CTOの鈴木です。

前回の投稿「SHOPLISTのシステムをモダンなアーキテクチャに変えようとしたら予想以上に闇が深かった話」の続きです。

レガシーシステム脱却のため、まずはリファクタリングでできる限りのことをする。という話なのですが、これは方針を決めたにすぎません。

今回は、SHOPLISTにおいてレガシーシステム脱却のためにどのような計画を立てて、何からどのように進めていたかについて共有していこうと思います。

 

まずは兵站(サポートとして投下できるヒト・モノ・カネ)を確保することから

私が一番初めに考えたのは兵站でした。

レガシー脱却を行うためには、私1人や私の所属する技術統括部の人員だけでは到底進めきれません。

また、既存システム上でサービスを動かしながら改修をしていくことを考えると長期戦になることが予想されるため、①一連の活動に割けるヒト・モノ・カネがどの程度あるか ②計画メンテナンスのようにレガシー脱却のトレードオフとしてビジネスサイドのスタッフがどの程度協力が得られるか(例えば一定期間は新規開発を止めるこことが受容できるか、定期メンテナンスを行えるか) ③PHPバージョンアップを行うに際しても、サーバへ移行稼働期間がかかるので、サーバ費用としてオーバーラップできる予算がどのくらい必要か、④リファクタリングを効果的に行う上で必要な支援は何か、をまず考えました。

どんなに素晴らしい戦略、作戦をたたたところで兵站を蔑ろにすると絵に描いた餅にしかならないからです。

少し余談になりますが、日本人は兵站を疎かにする節があると私は思っています。第二次世界大戦において日本軍は奇襲をかけ、艦艇や航空機を数多く破壊することには成功ているものの一方で、ドッグの破壊は行わず、先頭不能状態であった空母ヨークタウンがそのドッグで修理されミッドウエイ海戦に参戦しているという事実があります。本来は日本は4隻の空母で2隻の空母を戦うところ、兵站を軽視した結果としてヨークタウンが参戦することを許す形となり、もし真珠湾攻撃でドッグを破壊していれば戦局は変わっていたかもしれないのです。

話を戻します。今回進め方としては

1.必要となる兵站の見積

    ↓↓

2.問題に対する緊急度、優先度付け

    ↓↓

3.解決策の進め方のステークホルダ合意

という形で進めています。

レガシーシステムの解決策としてまず行ったこと

解決策は大きく分けて長期的施策と短期的施策があるのですが、まず一番初めに行ったことは、以下2点について会社代表および各部の部長と合意形成を取ることでした。

①深夜メンテナンスを今後は3カ月に行えるようにする。また当面の間は2週間おきに深夜メンテナンスを行えるようにする。

②エンジニア職種ついては週に4時間リファクタリングをはじめとするシステム品質の維持改善に充てられる時間を確保する。

1.計画メンテナンス時間の確保

SHOPLISTは実は今まで計画メンテナンスの時間をほとんどとっていませんでした。多くても年に1~2回で、その理由についてもElastiCacheをはじめとするAWS のPaaSのメンテナンスに伴う事前停止でした。

その理由について昔からSOHPLISTにいるエンジニアにヒアリングしたところ、「メンテンナンスを行うとその間の売上が損失するのと、ブランド様への調整が大変なので実施したいけどできない」という回答が返ってきました。

要するに、メンテナンスを行うを行うと売上が減少するので、自社から見た場合にアンコントローラブルなAWSのメンテナンス以外の理由のメンテナンスがビジネスサイドから許可されていない状況が長年続いていたという状況だったということです。

そのため、本来当然行われるべきOSやミドルウェアアップデートも行えず、データメンテナンスや大規模なインデックス付加も行えない状況となり、結果として、サポート切れOSミドルウェアの問題や、肥大化したDBが生まれることとなっていたわけです。

また、実際にどの程度売上が逸失するかについて十分な議論がなされていない現状も見えてきました。メンテナンスを行う時間帯を考慮すればせいぜい1回あたりの逸失利益ってせいぜい数十万円いかないです。かつ、メンテナンス中に購入できなかったユーザーが別のECプラットフォームで購入する前提であり、メンテを開けて当社サイトで購入する割合が0%であるという前提で考えての場合です。

本当に冷静に考えるとメンテナンスの逸失利益とEBSのコスト削減効果って同じかもしれないし、それ以上あるかもしれない。ただ、売上が減ることが困るというだけでメンテナンスが入れれない状況に陥っていたのです。

なので、「まず3か月おきにメンテをやる。やるというよりやる予定で計画する。他社はそんなにやってないとか思うかもしれないけど、うちはうち、よそはよそ、全くアーキテクチャが違うシステムを横並びで比較しても意味がないのでメンテをやる前提でスケジュールを組ませてください。で、もしメンテやらなくても済めば売り上げ失わなくてラッキーでしょ」という話と、「現状的負債として、サポート切れOS・ミドルウェア問題とDB肥大化問題があるんで、当面のうちは2週間おきに深夜メンテやらせてください。」という2点について社内でコンセンサスを取りに行きました。

2.リファクタリングをはじめとするシステム品質改善時間の確保

これは、3Mの「15%カルチャー」、GoogleやAtlassianで「20%ルール」のシステム品質版のを行おうという取り組みです。

SHOPLISTのように事業成長のため、売り上げに直結する開発以外が後回しになってしまうのであれば、直接的に売り上げに貢献しないけど、重要度の高いソフトウェア品質の維持のための活動を行う時間を取ることを経営者と明確に握ってしまいおうと考えました。

もちろん本家のようにイノベーティブな仕事に一定時間を当てようという話ではなく、技術的負債の返済に一定時間充てようという話であり厳密には違います。

ただ、ここで時間を設ける意図としては「売上に直結しないけど、システム品質を上げる活動をエンジニアが行える時間と、システム品質を維持向上させることを文化として根付かせること」と、「システム品質を維持向上させるための一連の活動を通じて、狂った状態になっている正常性バイアスを取っ払うこと」の2点でした。

なので社内でリファクタリング枠と言われている週4時間の時間確保をまず確保しました。

ちなみに週4時間に明確な理由はないです。それは実際に4時間でどこまでシステムのリファクタリングが行えるかどうかということよりも、文化形成と正常性バイアスを取り除くことを目的としていたためです。

どう進めるか?

計画メンテナンス時間の確保と、リファクタリング時間を確保し、十分にレガシーシステム脱却に充てれる時間、リソースを確保したところで、具体的に行うべき事柄を以下の5点で整理をしました。

1.システム品質維持向上のために永続して行う内容(長期的施策)

・3カ月に一度の定期メンテナンス

・日々のリリースの中でバックログとして積んだリファクタリング作業。

2.2020年中にマストで完了させるべき内容

・インフラアーキテクチャの見直し

・インフラ構築のコード化(ansibleによる環境構築の自動化)

・ローカル開発環境の構築コストの削減(vagrant+ansibleによる構築自動化)

・OS/PHP/MariaDBのバージョンアップ

・デプロイ方法の変更(GitLab CIによるデプロイ)

・Gitリポジトリ上の不要なブランチ削除

・DB上のサービス上不要なデータの削除

・開発ルール、ガイドラインの明文化

3.2020年中にできる限りで完了させるべき内容

・ログ上に存在するNotice/Warning潰し

・デッドコードの削除

・リソースファイル管理引退するGit LFSの導入

4.2020年中にやれる余力があれ対応するべき内容

・ログ上に存在するNotice/Warning潰し

・デッドコードの削除

・リソースファイル管理引退するGit LFSの導入

・ジョブ管理ツールの導入(cronの外だし)

5.2020年中にやらない内容(課題として持ち超す内容)

iOSのネイティブ実装をSwiftにの統一すること

AndroidのネイティブKotlinに統一すること

・サーバの独自フレームワークを入れ替えること

・DBをEC2 インスタンスからRDSに入れ替えること

 

各項目で具体的に何を行っていったかについては今後公開される記事を参照下さい。