CROOZ DEVELOPMENT 「SHOPLIST」の技術負債 長年構築されてきたレガシーシステムを 脱却することで見えてきた未来

自己紹介 経歴 ・2012年クルーズ株式会社入社 ・2015年 同社 CTO就任 ・2020年 CROOZSHOPLIST株式会社 技術統括部長兼任 鈴木 優一 クルーズ 株式会社 執行役員 CTO 兼 CROOZ SHOPLIST株式会社 技術統括部長

・SHOPLIST.com by CROOZ について ・SHOPLISTの歩み ・蓄積された技術的負債について ・技術的負債との向き合い方 ・１年間取り組んで変わったこと ・これから技術的負債に向き合う方へのへのアドバイス 本日のAgenda

１ SHOPLIST.com by CROOZ について

SHOPLIST.com by CROOZについて 「一番お得、ここにしかない商品の提供」をビジョンに、レディー ス・メンズ・キッズのファッションアイテムを中心にインテリアや コスメや雑貨に至るまで、幅広いジャンルのアイテムをまとめて購入 できる通販サイト「SHOPLIST.com by CROOZ」を運営しています。

SHOPLIST.com by CROOZについて 2012年7月のサービス開始から9年間で年間売上約300億円規模に 1年目 2年目 3年目 4年目 5年目 6年目 7年目 8年目 9年目 22億円 65億円 97億円 145億円 190億円 214億円 271億円 249億円 245億円 2012年 2013年 2014年 2015年 2016年 2017年 2018年 2019年 2020年 体制変更

SHOPLIST.com by CROOZについて ・技術スタックはサーバはLAMP ・ネイティブはJava/Kotlin/XCode/Swift併用 ・現在技術スタックの置換え中 Server Side Frontend Dev/Ops Native App Infra Structure

2 SHOPLIST.com by CROOZ のあゆみ

SHOPLISTのあゆみ SHOPLIST のあゆみ ～リリースまで 事業面の話 ・2012年7月にリリース ・当時はCROOZ blogという月間700万PVを記録する広告メディアを運営 しておりおり、ファッションECの広告案件が多くあったため自社でもEC 事業を行おうということになり、総合ECモール「CROOZMALL」を リリース。 ・モールへの集客をする中でファストファッションのPV数が高かったため ファストファッションに絞った「SHOPLIST.com by CROOZ」をリリース ・CROOZ MALLをはじめとする既存のサービスのソースコードを基に、 6カ月で開発を行った。

SHOPLISTのあゆみ SHOPLIST のあゆみ ～リリースまで 技術面の話 ・超突貫でエンジニア3名× 6カ月で突貫開発 ・ゼロベースではなく、既存のサービスのソースコードを基に開発 ・従来より自社で使用実績のある独自フレームワーク『Venus』で開発 ・インフラ環境はゲーム事業で実績のあったオンプレミス環境で構築

技術的に得たもの SHOPLISTのあゆみ SHOPLIST のあゆみ ～リリースまで ・ファッションECサイトの設計・構築ナレッジ ・全文検索エンジンの運用ナレッジ 積み残した技術的負債 ・動くけど可読性・保守性の低いソースコード ・ドキュメント未整備（特に仕様に関する部分） ・エラーログ実装（エラーコード未実装とか）

SHOPLISTのあゆみ SHOPLIST のあゆみ リリース～2015年 事業面の話 ・サービス急成長。取扱高が3年目で約100億、4年目で約150億に ・出店店舗数も60店舗から600店舗まで増加 ・メガセール取扱高月10億円突破。 ・事業成長に伴い、倉庫移転を2回行い物流のシステムのリプレイスも実施。 ・2014年11月に初のTVCM実施

SHOPLISTのあゆみ SHOPLIST のあゆみ リリース～2015年 技術面の話 ・新機能を次々とリリース。特に誰もが購入ができるように決済手段と ログイン連携機能は常に新しいものに対応していった。 ・開発人数も3名～30名規模に急増 ・このころになるとサービスの成長に伴い、アクセス数が急増していき、 特に突発的な負荷への対処がインフラの課題となってきた。 ・柔軟なスケーリング実現のため、2014年10月にインフラをクラウド移行 ・検索エンジンをGroongaからElacticSearchに移行

技術的に得たもの SHOPLISTのあゆみ SHOPLIST のあゆみ リリース～2015年 ・AWS上での各種サービスの構築運用ナレッジレッジ ・ElasticSearch, MapReduce, Cognite, RedShiftなどPaaSの運用ナレッジ ・TVCM放映にも耐えられるアプリケーションのチューニングナレッジ 積み残した技術的負債 ・動くけど可読性・保守性の低いソースコード ←当初比較で約25倍にｗ ・ドキュメント未整備（特に仕様に関する部分） ←同じくｗ ・エラーログ実装 ←同じくｗ ＋野生のコードたち(リポジトリ管理外のコード) ＋PHP5をはじめとするサポート切れのミドルウェア ＋未対処のPHPエラーログ

SHOPLISTのあゆみ SHOPLIST のあゆみ 2016～2019年 事業面の話 ・2018年の年間取扱高が250億円から伸びず横ばいに ・売上を伸ばすために、新規施策を次々と実装＆リリース ・Virtusizeを日本初導入

SHOPLISTのあゆみ SHOPLIST のあゆみ 2016～2019年 技術面の話 ・開発人数も正社員40名＋開発パートナー20名規模 ・並行開発＆開発人員の増加に伴い、ソースの衝突が頻繁に発生するように… ・ドキュメントがない＆可読性が悪い状況化での新規参画するメンバーが増えた ことで、弊害(ベロシティの低下、開発職種の平均勤続年数の低下)が出始める。 ・エラーが出たら直すとか、使わなくなったらサービス上から消すとか 本来当たり前にすべきソースコード上の保守に手が回らなくなる。 ・サポート切れミドルウェア問題など、認知はしているが移行するための作業 時間と計画メンテナンス時間が確保できない状態に… ・一か所を直すと意図しないバグを踏む状況に… デバッグめちゃくちゃしんどい…

技術的に得たもの SHOPLISTのあゆみ SHOPLIST のあゆみ 2016～2019年 ………(；・∀・)ﾊｯ? 積み残した技術的負債 ・動くけど可読性・保守性の低いソースコード ←当初比較で約40倍にｗ ・ドキュメント未整備（特に仕様に関する部分） ←同じくｗ ・エラーログ実装 ←同じくｗ ・野生のコードたち(リポジトリ管理外のコード) ・PHP5をはじめとするサポート切れのミドルウェア ・未対処のPHPエラーログ

SHOPLISTの歩みとリファクタリングするまでの流れ SHOPLIST のあゆみ 2020年7月時点（鈴木がJOINした時点） 事業面の話 ・経営体制変更。CROOZ SHOPLIST株式会社の代表はじめとする役員に クルーズ株式会社の役員が兼務で就任

SHOPLISTの歩みとリファクタリングするまでの流れ SHOPLIST のあゆみ 2020年7月時点（鈴木がJOINした時点） 技術面の話 ・開発人数は正社員40名＋開発パートナー5名規模 ・スパゲッティコード過ぎてカオスに… 新しく機能追加するために仕様を把握しようとしてもドキュメントもないし ソースコードも現実的に終えず、古参のエンジニアのみしかわからない状況 ・データベースが1スキーマあたり1200テーブルあり、容量も1.6TBに成長 ・Warningをはじめとするエラーログが多すぎて、ログを仕込んでも見つける のが一苦労 ・PHPはセキュリティサポート切れまま5年以上経過 そして…

SHOPLISTの歩みとリファクタリングするまでの流れ SHOPLIST のあゆみ 2020年7月時点（鈴木がJOINした時点） ・エンジニアの平均勤続年数は1/3年にｗ もはやカオス 技術面の話

3 蓄積された 技術的負債

蓄積された技術的負債について改めて整理すると ・動くけど可読性・保守性の低い状態で長年開発し続けた秘伝のタレ的な ソースコード ・そのコードを読むか一部の古参エンジニアの記憶に依存する文書やコメント に存在しない仕様 ・1リクエストあたり300行以上出力されるWarning/Deprecated/Noticeログ ・1DBあたり約1,200テーブルあり、1.6TBの容量を持つ巨大DBインスタンス ・500以上存在しているGit上のブランチ ・一部存在している野生のコードたち ・PHPをはじめとするセキュリティサポートの切れたミドルウェア ・二世代も三世代も前の設計思想に基づく全体アーキテクチャ＆デプロイ思想 その他、細かいもの諸々

4 技術的負債へ の向き合い方 ～全体的な話～

リニューアル (作り直す) vs リファクタリング(直す) 何も考えずにゼロベースで作り直したい！

リニューアル (作り直す) vs リファクタリング(直す) 結論：リファクタリング(直す形)で進める。 理由： ・そりゃできればゼロベースで作り直したい！ ・誰もが「作り直さなきゃダメっすね…」と言っていた ・けど、以下の視点で非現実的 １．仕様や要件が無く、リバースエンジニアリングで調べるだけで膨大な工数 がかかる。 ２．仮にゼロベースで作ったとして既存DB移行(データ移行)が限りなく困難。 ３．人員のリソース的な問題で、サービス開発を行いながら並行して リニューアルを行うのが限りなく困難。 (全員総出で1年かけりゃできるけど、並行してサービス開発を続行不可) なので、実現味が最も堅いリファクタリングベースで進める選択肢を採用。

インフラアーキテクチャに関する方針 インフラ面の課題としては、PHPをはじめとするサポート切れミドルウェアの バージョン以外にも… 今までは主にVPSとしてEC2を使っているに過ぎなかったが「クラウドサービス」 としてしっかり活用していくことが可能なようにこの機に構成を見直し ・過去にクラウド移行を行ったもの、オンプレにあったサーバをそのままEC2上に 移行しただけに過ぎず、オンプレよりは柔軟には運用できるようになったものの いうほどのスケーラビリティの担保ができていない。 ・直近のEC2のマシンイメージを複製してインスタンスを作成し＆差分について手動 の構築していたため、同じ本番インスタンスですら微妙に差異が出ていた。 ・デプロイもrsyncコマンドに依存。除外する対象ファイルも都度ファイル指定してい るので、除外漏れで稀に事故が起こることがある。また即時切り戻しができない。 ・インスタンスの世代も古い

インフラアーキテクチャに関する方針 なのでサポート切れミドルウェアのバージョンも行うが、それ以外にレガシーな 部分について、できる範囲でモダンな構成に変更していく形で進めることに 具体的には ・OSおよびミドルウェアのバージョンアップ CentOS6.4→Amazon Linux2 / Apache 2.2 → 2.4 / Maria DB 10.0 → 10.5 / PHP 5.4→7.4 ・EC2 インスタンスの世代アップ + AMD インスタンス利用によるコスト削減 ・Multi-AZ対応 ・AnsibleによるAWS EC2インスタンスの自動構築(コードによるインスタンス構築) ・Amazon EC2 Auto ScalingによるWebサーバの動的スケーリング ・Fastly Image Optimizer を利用したサムネイル作成処理のマイクロサービス化 ・Fastly Image Optimizer を利用したWebP変換対応 ・rsync→GitLab CI/CDへのデプロイ方法変更 ・CloudWatch Log Agent を利用したアプリケーションログの一括収集 ・AWS Fargateによるサーバーレスでのサービス運用（新規サブシステムから適用）

参考：旧構成図（Web関連） 連携会社etc 出店ブランド様 CS委託会社 配送会社 広告会社 etc… エンドユーザ Route 53 Web ALB Admin ELB WAF ACL Web / API 検索API Cashier用 Cart用 XXX用 XXX用 社内管理画面 社外管理画面 EC2 (Web) Main DB EC2 (mariaDB) Session 用 ElastiCache (Redis) Ranking 用 Data Cache 用 Mail Proxy ELB SHOPLIST DB LB ZETA ELB AWS Cloud 外部 検索エンジン Mail Proxy S3 bucket メール配信 エンジン

参考：旧構成図（バッチ・サムネ関連） 連携会社etc 出店ブランド様 CS委託会社 配送会社 広告会社 etc… Batch05-08 BQClient Main DB EC2 (mariaDB) Stock DB S3 bucket Google BigQuery S3 bucket 従業員 （分析） 店舗用 EC2 (vsftpd) その他用 S3 bucket Image Proxy ASG Nginx+ SmallLight ImageProxy ELB IDCF CDN Mail Proxy ELB SHOPLIST DB LB ZETA ELB AWS Cloud 外部 検索エンジン Mail Proxy メール配信 エンジン

参考：現行システム構成図（Web関連） 連携会社etc 出店ブランド様 CS委託会社 配送会社 広告会社 etc… エンドユーザ Route 53 Web ALB Admin ELB WAF ACL Main DB EC2 (mariaDB) Sub DB Session 用 ElastiCache (Redis) Ranking 用 Data Cache 用 Mail Proxy ELB SHOPLIST DB LB ZETA ELB AWS Cloud ZETA 検索エンジン Mail Proxy S3 bucket メール配信 エンジン Web / API ASG EC2 検索 ASG EC2 Cachier ASG EC2 Cart ASG EC2 SuperShip ASG EC2 Deqwas ASG EC2 EC2(社内管理画面) EC2(社外管理画面) Stock DB

参考：現行構成図（バッチ・サムネ関連） 連携会社etc 出店ブランド様 CS委託会社 配送会社 広告会社 etc… Batch05-08 BQClient Main DB EC2 (mariaDB) Stock DB Mail Proxy ELB SHOPLIST DB LB ZETA ELB AWS Cloud ZETA 検索エンジン Mail Proxy S3 bucket メール配信 エンジン Google BigQuery S3 bucket 従業員 （分析） 店舗用 EC2 (vsftpd) その他用 S3 bucket Fastly CDN (Image Optimizer)

5 技術的負債へ の向き合い方 ～組織的な話～

技術的負債への向き合い方 ～組織としてすべきこと～ １．技術的負債があることによる問題を経営層に理解してもらう ・ソースコードがスパゲッティ状態・クソ・化石、エンジニアの精神衛生上よくないといった 会話だけでは経営層には伝わりづらい。 ・同じく、マイクロサービス化、CI/CD導入といった解決策としての技術要素の会話も同じ。 ・大事なのは、技術的負債となりうる事柄が放置されていることで、具体的にどのような 問題が発生しているかを経営層の関心事の視点で会話できる状態とすること 例）ソースコードがスパゲッティ状態だったことによって、先日入社した人がソースコードを 読んで仕様を理解するのに40時間かかっていた。結果、ソースコードの8割がデッドコードで あることが分かり、理屈上ソースコードがきれいな状態であったら40時間×2割 = 8時間で できるはずで、32時間が無駄になっている可能性が高い。 ・技術的負債によってどんな影響が出ているのかを正しく経営層に理解してもらうことは 極めて重要。なぜなら技術的負債を返していくに経営層の理解と協力が確実に必要だから。 具体的には ・技術的負債に向き合うためにはヒト・モノ・カネの経営資源の投入が必要。 ※片手間では絶対できないし、できてれば今の状況になってない ・場合によっては、サービス停止を伴うメンテナンスや施策のリリース時期の調整など、売上減少 を伴う可能性のあることを実施する可能性があるため。

２．技術的負債に向き合うために必要なリソースを集める 例えば ・技術的負債を生まないために、日々の開発工数の10%をリファクタリングの時間に充てて 日々製造したソースコードの品質向上時間を確保する。 ・ミドルウェアのリプレイスとインフラ基盤を刷新を行うために、月に2回×2カ月間、深夜 メンテナンスを行う。 ・今後定期的に3カ月に一度深夜メンテナンスを行う時間を確保する。 ※但し、必要性が無ければ実施しない。 など、技術的負債に向き合うために必要なヒト・モノ・カネを確保する。 技術的負債への向き合い方 ～組織としてすべきこと～

３．技術的負債を返す活動を阻害する要素を取り除く 技術的負債の返済のための活動ととして以下の傾向がある ・永続的に続く長期戦 スピード重視で開発以上、どんなに気を付けていても一定数の可読性・保守性の悪いコードが 生まれる。 ・売上や営利に直結はしない 直結していないから後回しにされ、負債として蓄積されてしまっている。 なので組織内で「別の売り上げを上げる案件に人を充てるべきでは？」「やる意味あるの？」 という心もとない声が出てくることがある。 そのような際に技術的負債を返済することの重要性を理解させ、活動を阻害する要素を取り 除き継続できるようにすることが大事。 技術的負債への向き合い方 ～組織としてすべきこと～

４．開発に関するルールを再定義し、運用に落とす 例えば ・３カ月おきに、深夜にメンテナンスを行う時間を必ず設ける ・３カ月おきに、ミドルウェアのサポート情報を確認し、新たにサポート期日に アップデート発表があった場合、期日の6カ月前までに対処する。 ・6か月おきに○○テーブルについてはインデックスの再生成を行う。 ・毎週エラーログ件数を目視確認し、新規発生したもの、一定数増えた場合は調査する。 ・コーディング規約変更の提案は○○の会議体で提案し、変更はCTOが承認し、○○の 会議体で全エンジニアに周知する。 など 売上に直結しないからとか、忙しいからやらないではなく、できるように仕組み化する。 あと、大事なのはツールばかりに頼らないこと。 ツールにより検知はできても、様々な理由で優先度が下がって結果的に元の状態に戻って いることになりかねないので、会議体に落とし、報告する運用まで設計する。 技術的負債への向き合い方 ～組織としてすべきこと～

6 技術的負債へ の向き合い方 ～リファクタの話～

１．いらないものを捨てる 技術的負債への向き合い方 ～リファクタの話～ 具体的には ・機能単位で廃止された機能一式 ・呼ばれていないプロパティ、メソッド類 ・呼ばれていない定数 ・呼び出されているけど絶対にその分岐状態に入らないプログラムのブロック ・ガラケー固有処理(解像度判定・ガラケー用画面テンプレート) ・使われていないけど残っているDBのテーブル ・意味をなしていないログ など 当たり前のことだけど、できてないことが結構多い。 いらないものが雑音となって本質的にリファクタリングしなければならない部分に手を入れる 際に、手間がかかってしまうため、いらないものをまずは捨てる。 手段的にはIDEの機能、SonarQube、PHPMDなどの静的解析ツールをCI/CDに組み込んで 状況を把握し、あとは泥臭く実行。

２．公開範囲を小さくする 技術的負債への向き合い方 ～リファクタの話～ 具体的には ・継承先でしか呼ばれないのであれば public → protected に ・そのクラス内でしか呼ばれないのであれば private に ・全体で使わない定数であればクラス内定数に など公開範囲を小さくする。 ３．同じ処理、似た処理のロジックを共通化する １と２が終わったタイミングで、ソースコードとしてはある程度負える状態となってくるの で、ここから本来すべきリファクタリングの第一歩として同じ処理、似た処理の共通化を行 っていく 手段的としてはIDEの機能、SonarQube、PHPMDなどの静的解析ツールも使うが、 アナログにソースを読んで理解していくことも重要。

４．各処理ロジック中のリファクタリングを行う 技術的負債への向き合い方 ～リファクタの話～ 条件分岐に対するエラー処理、例外処理の追加や、メソッドの粒度の統一化、継承関係の 見直しなど、プログラムレベルでのリファクタリングを行う。 特にエラーログは大事。 当社で採用しているPHPなどはいろいろ緩いので、厳密なエラー処理が無くても動作として うごいてしまうので、ログを確認しながら対処していく ５．アプリケーションでやらなくてよいことはミドルウエアやPaaS/NaaSに移す 例えば、URLパターンに基づくサブシステム単位でののディスパッチ処理、Sorryページ遷移 など、当時はプログラムでしかできなくても、今ではプログラムで書かなくてもできるもの は案外ある。 アプリケーションより上位のミドルウェアやPaaS/NaaSでできるものはアプリケーション では実装しない。分岐が減る分だけソースコードがシンプルになるため。

7 技術的負債へ の向き合い方 ～システム的な話～

１．品質メトリクスを可視化する 技術的負債への向き合い方 ～システム的に整備すること～ 具体的には ・エラーログ件数(Warning / Notice 含む) ・Lintエラー件数 ・ソースコード重複件数 ・カバレッジ ・DBのテーブル数 など できることからまずは可視化。 見えないと現状も把握できないし、目標も立てれない。 まずは可視化！

２．仕組みとしてできるものは強制する 技術的負債への向き合い方 ～システム的に整備すること～ 具体的には ・Code Formatter ・Merge Requestによるレビュー依頼など など すべてを人的な手段で行おうとはせず、ツールやシステムなどで強制できるものは強制 して無理やり統制する。 ３．CI/CDとして整備し、運用まで落とし込む まず、品質メトリクス集計など、デプロイ都度もしくは日次で回せるものは自動で回せる 仕組みを作る。 会議体などで、品質メトリクスをエンジニア全員に見る場を設け、正常なのか異常なのかを 確認する習慣をつけさせる。

８ 技術的負債へ の向き合い方 ～インフラ的な話～

１．開発環境を既存のと新規で平行して稼働させ、出たエラーをつぶす 技術的負債への向き合い方 ～インフラ移行の話～ 開発者 push EC2 instance Web / Batch CentOS 6.4 PHP5.4 EC2 instance DB MariaDB 10.0 既存環境 EC2 instance Web / Batch Amazon Linux2 PHP7.4 EC2 instance DB MariaDB 10.5 新規環境 エラー発生 ひたすらエラー修正 ・廃止関数など、文献上わかるものは検索して代替関数に置き換え。 ・あとはエラーログを見ながら地道に直す。

２．開発環境である問題が潰せたら、もう１台本番に入れちゃう 技術的負債への向き合い方 ～インフラ移行の話～ すべてのぺージ、すべてのバッチにおいてエラー発生がないことを網羅的に確認するなんて やってたらキリがない！！ 開発環境での問題が潰せた段階で1台だけ本番サービスに入れてしまい、すぐに本番環境 から外せるようにしておいてログを見るのもやり方としてはあり。 ※開発環境で潰せている時点で本番環境で問題が起こる可能性が低いため Webであればターゲットグループ中の1台、DBであればSlave中の1台といった形で投入。 ３．あとは覚悟を決めて本番投入するのみ！ どんなに計画しても予期せぬハプニングは起こるもの。 なので、やることやったら覚悟を決めて本番投入。

ちなみに… 技術的負債への向き合い方 ～インフラ移行の話～

OSおよびミドルウェアリプレイスは約3カ月という超突貫で実施しました 技術的負債への向き合い方 ～インフラ移行の話～ 2021/07 2021/08 2021/09 2021/10 2021/11 2021/12 計画作成 構築スクリプト生成 DBインスタンス切替 Web / バッチ切替 不要テーブル調査 第1回目 メンテ実施 第2回目 メンテ実施 本番検証 (1台のみ) 第3回目 メンテ実施 (DB切替) 開発環境検証 本番検証 本番検証 MEGA Sale中 本番切替完了 第4回目 メンテ実施 (Web/バッチ切替) 本番切替完了 約3カ月で実施

そして… 技術的負債への向き合い方 ～インフラ移行の話～ PHP7.4のバージョンアップメンテを行った2020年11月26日に、 なんと、PHP8.0がリリースされました！ ｷﾞｬｱｧｧｧｧ━━━━━━(ﾟДﾟ|||)━━━━━━!!!!!!

切替後に発覚した主な問題は… 技術的負債への向き合い方 ～インフラ移行の話～ ・リポジトリ管理外の野良コードが実はあって、移行が漏れたバッチがあった。 →リポジトリ内にソースコードを入れて再デプロイして解消。 ・MariaDBのSlave間で今まで設定パラメータが実は違っていて、移行の際に設定が漏れた。 →用途ごとパラメータを再定義した。 ・Multi-AZ化により、ゾーン跨ぎのSQL応答が遅くなり、バッチ実行速度が最大で2倍遅くなる ものがあった。 →設計時の考慮漏れ。実行元のバッチインスタンスとバッチの参照先のSlaveインスタンスの ゾーンを合わせることで解消。 ・MariaDBのバージョンアップに伴い、クエリ処理が詰まる問題。 デフォルトのトランザクション分離レベルが変更になっているなど、RDBMS内部の仕様変更 によりクエリの応答時間が遅くなり詰まる。（バッチのみで発生） →考慮漏れもあるものの、バッチ内で行っているTEMPORARY TABLEの作成方法がよろしくないので プログラム側の改修で対処。 ・実はバッチサーバ内にworkディレクトリを事前に作る必要があって、それが無かったことで バッチがコケた。 →考慮漏れ。構築スクリプトを修正。

切替後に発覚した主な問題は… 技術的負債への向き合い方 ～インフラ移行の話～ ・ほとんどがDB周りの問題でした！

9 １年間取り組ん で変わったこと

１年間取り組んで変わったこと ～定量的な話～ 技術的負債返済に関する主な指標 2020年7月時点 2021年7月時点 総エラーログ件数 約365万件/日 約160万件/日 （約55%削減） 論理LOC 約200万行 約170万行 （約15%削減） DBデータ容量/1インスタンス 約1.6TB 1.1TB (約30%削減) OSバージョン CentOS 6.4 (サポート期日：2020/11/30) Amazon Linux2 (サポート期日：2023/06/30) Apacheバージョン 2.2 (サポート期日：2017/12/31) 2.4 (サポート期日：未定) MariaDBバージョン 10.0 (サポート期日：2019/03/31) 10.5 (サポート期日：2025/06/24) PHPバージョン 5.4 (サポート期日：2015/09/14) 7.4 (サポート期日：2022/11/28)

１年間取り組んで変わったこと ～定性的な話～ １．正常性バイアスが元に戻った（異常な状態を異常だと言えるエンジニアが増えた） 例えば、今までだとエラーログが出続けていることが当たり前だったので、本来 気づくべき怪しいログが埋もれてしまっていたが、それに気づけるようになった。 ２．放置せず、その場で調べたりバックログに積む文化がつき始めた ３．秘伝のタレを作り出すコードの締め出しが行えるようになった ・Code Formatterでの強制とレビューによって、質の低いコードが新規 に混入することは一定レベルで防げるようになった。 今までだと、「あー、それ昔からなんですよ」で終わっていた会話が、「なんで 起こってるんだろう」に変わりつつある。 もちろん修正規模によってすべてをリファクタリング時間で直せるわけではないが やらなくてならないこととして認知して負債に向き合えるようになってきた。

10 これから 技術的負債に 向き合う人へ

これから技術的負債に向き合う人へのアドバイス 技術的負債を経営層に認識してもらうことは極めて重要 ・片手間でできるものではなく、ヒト・モノ・カネを投入して全社を巻き込んで いかないとうまくいかない できるものからでいいので品質メトリクスを可視化する ・まずは可視化し、各メトリクスに対してPDCAを回していく。 技術的負債に向き合える仲間を増やす ・愚痴っているだけで何もしないのでは意味がない。 技術的負債を返済していくことを楽しめる仲間を増やす。 ツールやシステムに頼りすぎない ・検知できてもソースが改修されないと意味が無いので、検知して通知する ツールを整備して終わりとせず、運用まで落とし込む。

さいごに 溜めちゃダメ！ ・設計レベルではどうしようもなくとも、実装レベルの話だったら15分遠回り をすれば局所的に作り直せるものもある。 ・時間がないからという理由で安易に先伸ばしにしても、時間なんてこの先 確保できる？ ・技術的な負債を溜めないこと（増やさないこと）が重要！！

ご清聴ありがとうございました。 テックブログはこちら⇒ イベント開催情報はこちら⇒