2021年11月24日（水）に開催されたTECHHILLS（テックヒルズ）で発表した資料になります。
SHOPLISTがリリースされてから今日に至るまでの情報を載せています。
CROOZDEVELOPMENT「SHOPLIST」の技術負債長年構築されてきたレガシーシステムを脱却することで見えてきた未来
View Slide
自己紹介経歴・2012年クルーズ株式会社入社・2015年 同社 CTO就任・2020年 CROOZSHOPLIST株式会社 技術統括部長兼任鈴木 優一クルーズ 株式会社 執行役員 CTO 兼CROOZ SHOPLIST株式会社 技術統括部長
・SHOPLIST.com by CROOZ について・SHOPLISTの歩み・蓄積された技術的負債について・技術的負債との向き合い方・１年間取り組んで変わったこと・これから技術的負債に向き合う方へのへのアドバイス本日のAgenda
１ SHOPLIST.comby 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 SideFrontendDev/OpsNative AppInfra Structure
2 SHOPLIST.comby 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 53Web ALBAdmin ELBWAF ACLWeb / API検索APICashier用Cart用XXX用XXX用社内管理画面社外管理画面EC2 (Web)Main DBEC2 (mariaDB)Session 用ElastiCache (Redis)Ranking 用Data Cache 用Mail Proxy ELBSHOPLIST DB LBZETA ELBAWS Cloud外部検索エンジンMail ProxyS3 bucketメール配信エンジン
参考：旧構成図（バッチ・サムネ関連）連携会社etc出店ブランド様CS委託会社配送会社広告会社etc…Batch05-08BQClientMain DBEC2 (mariaDB)Stock DBS3 bucketGoogleBigQueryS3 bucket従業員（分析）店舗用EC2 (vsftpd)その他用 S3 bucketImage Proxy ASGNginx+SmallLightImageProxy ELBIDCF CDNMail Proxy ELBSHOPLIST DB LBZETA ELBAWS Cloud外部検索エンジンMail Proxyメール配信エンジン
参考：現行システム構成図（Web関連）連携会社etc出店ブランド様CS委託会社配送会社広告会社etc…エンドユーザRoute 53Web ALBAdmin ELBWAF ACLMain DBEC2 (mariaDB)Sub DBSession 用ElastiCache (Redis)Ranking 用Data Cache 用Mail Proxy ELBSHOPLIST DB LBZETA ELBAWS CloudZETA検索エンジンMail ProxyS3 bucketメール配信エンジンWeb / API ASGEC2検索 ASGEC2Cachier ASGEC2Cart ASGEC2SuperShip ASGEC2Deqwas ASGEC2EC2(社内管理画面)EC2(社外管理画面)Stock DB
参考：現行構成図（バッチ・サムネ関連）連携会社etc出店ブランド様CS委託会社配送会社広告会社etc…Batch05-08BQClientMain DBEC2 (mariaDB)Stock DBMail Proxy ELBSHOPLIST DB LBZETA ELBAWS CloudZETA検索エンジンMail ProxyS3 bucketメール配信エンジンGoogleBigQueryS3 bucket従業員（分析）店舗用EC2 (vsftpd)その他用 S3 bucketFastly 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として整備し、運用まで落とし込むまず、品質メトリクス集計など、デプロイ都度もしくは日次で回せるものは自動で回せる仕組みを作る。会議体などで、品質メトリクスをエンジニア全員に見る場を設け、正常なのか異常なのかを確認する習慣をつけさせる。
８ 技術的負債への向き合い方～インフラ的な話～
１．開発環境を既存のと新規で平行して稼働させ、出たエラーをつぶす技術的負債への向き合い方 ～インフラ移行の話～開発者 pushEC2 instanceWeb / BatchCentOS 6.4PHP5.4EC2 instanceDBMariaDB10.0既存環境EC2 instanceWeb / BatchAmazon Linux2PHP7.4EC2 instanceDBMariaDB10.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切替)開発環境検証 本番検証 本番検証MEGASale中本番切替完了第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分遠回りをすれば局所的に作り直せるものもある。・時間がないからという理由で安易に先伸ばしにしても、時間なんてこの先確保できる？・技術的な負債を溜めないこと（増やさないこと）が重要！！
ご清聴ありがとうございました。テックブログはこちら⇒イベント開催情報はこちら⇒
crooz
yayoi_dd
tarao
nasa9084
hirokiotsuka
tsubakimoto_s
kenichirokimura
harukasakihara
blue_goheimochi
mizunohiroaki
aramaki
takahashikazutaro
ybrliiu
kastner
paigeccino
rocio
reverentgeek
notwaldorf
chriscoyier
brettharned
paulrobertlloyd
searls
stephaniewalter
bryan
bkeepers