【Ltech#8】技術的負債返済・実装改善に関する事例紹介

技術的負債返済・実装改善
に関する取り組み
LTech #8 2019/09/03
株式会社LIFULL
清水通直

© LIFULL Co.,Ltd. 本書の無断転載、複製を固く禁じます。2
アジェンダ
• 自己紹介
• はじめに
• 技術的負債返済・実装改善に関する取り組み
– Code Climate活用事例
– 効果的な負債返済計画
– Datadog APM活用事例
– Buckyを活用事例
• まとめ

自己紹介
清水通直
しみずみちなお
@shimimi
● 2018年 LIFULL中途入社
● 今年で2年目
○ Webアプリケーション開発
○ 開発効率向上に関する取り組み
○ パフォーマンス改善に対する取り組み
○ 技術的負債返済に関する取り組み
現在に至る

1. はじめに

1. はじめに
エントロピー増大則
「断熱系において不可逆変化が生じた場合、その系のエントロピーは増大す
る。」
引用元 Wikipedia
ソフトウェアも同様、問題のある実装を放置しておくと
そこからまた新たな問題が生まれ、腐敗していきます。
そのため、早期に問題のある実装を取り除いていくことは効果的ですが
既に負債を抱えてしまった大規模プロダクトの場合には
いくら取り除いても、新規開発の速度に負けてしまい
完済目処が立たない可能性があります。

1. はじめに
そのため、様々なツール・サービスを活用し
リファクタリングの精度・効率を高めることや
リファクタリング以外の改善アプローチを
行なった事例をご紹介させていただきます。

1. Code Climate活用事例

1. Code Climate改善事例
渡された値が
特定の数値間の範囲内の場合
→範囲の上限値を返す
最大値を超える場合
→最大値＋１を返す
このような冗長な実装があります。

Code Climate CLI を実行すると、認知的複雑度は12で
デフォルトの規定値5を超えていることがわかります。

POINT
JSONで出力すると
Code Climate Quality
でも見ることのできない
改善ポイントや、緊急度など
を見ることができます

認知的複雑度が5まで下がるように
実装改善をおこないました。

再度解析を行うと問題は無事解消されていました。
もう一つのissue（850,000）も同時に解消されているので
「1,650,000 remediation points 返済完了」となります。

© LIFULL Co.,Ltd. 本書の無断転載、複製を固く禁じます。
このような細かい改善を少人数でいくつか行いました。
しかし、同期間の新規開発によりそれ以上の負債が新たに増えました。
大規模プロダクトであるほど開発は活発ですので
負債が増えやすい構造を改善していかない限り
負債増加速度 > 負債返済速度となります。
効果的な負債返済計画を立てる必要があると思いました。
13
POINT

2. 効果的な負債返済計画

プロダクトの技術的負債の返済と
プロダクトのさらなる発展のバランスを
どのように保つべきでしょうか。

POINT新規開発停止（Project Inversion）
「2011年に株式公開に成功してから6か月たっても、LinkedInは、問題を起こしがちなデプ
ロイとの格闘を続けていた。その苦痛が耐えられないものになったので、LinkedInは
Operation InVersionを発足させた。コンピューティング環境、デプロイ、アーキテクチャの
テクチャのオーバーホールのために、2か月にわたって新機能の開発をすべて停止した
のである。」
「社内のトップエンジニアたちは、新機能の開発を完全にストップさせ、部門全体でサイト
のコアインフラストラクチャに修正を加えることにした。」
「Project InVersionは、10年近くにわたって蓄積されたLinkedInの技術的負債を解消する
ことにより、安全と安全性を確保するとともに、会社の成長の次の段階に備えたものにな
った。」
引用元 The DevOps ハンドブック理論・原則・実践のすべて
全員で負債返済

新規開発と共に
新規の機能開発は行うものの、直面した技術的負債に関する指摘は解消しなければなら
ないようにします。Githubのブランチ保護設定で品質に関する指摘解消の遵守を強制する
制すると、問題のある実装はマージできなくなります。技術的負債は減少方向にのみ動く
ことが約束されます。
技術的負債が減少する一方、負債量によっては開発速度も低下します。既に負債量が大
きすぎる場合には、新規開発自体よりもそれに付随する負債の返済コストで首が回らなく
なり、Project Inversionと同様の状態になる可能性があります。
新規開発チームのライフワークに沿った返済

負債返済チーム
新規開発チームとは別に、負債返済を目的とする専任チームを発足します。負
債返済チームは、改善ノウハウを新規開発チームにフィードバックし、今後の新
時に同様の方法での実装改善を促進します。既存の負債を解消しつつ、ノウハウ
で今後の負債も増えにくくするループを作り出します。
Githubのブランチ保護設定では、品質に関する指摘を通知するに留め、可能な限
ことを促すものの強制はしません。新規開発チームのビジネス的な優先度を優先
す。
負債返済チームによる改善と、新規開発チームが負債返済チームのノウハウを吸
ていくことにより、緩やかに負債を返済していくこととなります。
新規開発チーム負債返済チーム

負債返済チーム＋負債発生原因解消チーム
前案の技術的負債返済チームに加えて、既存の技術的負債が積み立てられてきた背
景・経緯を分析し解消する専任チームを発足します。
このチームは、技術的負債それ自体に目を向けるのではなく、それらが積立てられてき
た経緯・背景、より原始的な問題を探り、アーキテクチャの再設計・開発リードタイムの可
視化・開発サイクルやフロー効率の改善などを行っていき、技術的負債が生まれにくい
にくい状態に変革していきます。
弊社は現在、このようなフォーメーションで、
プロダクトの発展を止めることなく、技術的負債と向き合っています。
19
POINT
新規開発チーム負債返済チーム負債原因解消チーム

3. Datadog APM活用事例

最初に示したCode Climate CLI / Qualityは
具体的な実装改善にとても便利なのですが
以下を考慮しないため、複数の指摘の中からより効果的なものを選定しづ
らいです。
・実行順序による影響度
・実行速度へのインパクト
・システムメトリクスへの影響度
Datadog APMを併用すると、これらが分析可能になりました。

分散トレーシングの技術により、異なる言語で作られた複数コンポーネント
間の実行順序や、ボトルネックがわかります。

マルチスレッドの処理は、可視化することで、一番遅いスレッドの処理の
み改善する等、効果的な実装改善が可能になりました。

Datadog APMで実際に改善した事例
1. 特定の画面のBackend TTFBが遅い原因を調査
2. 呼ばれているAPIをAPMで掘り下げていく
3. Ruby製APIの1つのエンドポイントの中で、JSONのencode/decode処理
が頻繁に使われており、それぞれは微小でも、1リクエスト間の合計では
120msを費やしていることが明らかになった
4. 実装改善によりその大部分を削減し、数十MBのメモリリソースとのトレ
ードオフで100 ms改善できることがわかった
5. 実施・改善

4. Bucky活用事例

最後に、安心して様々な改善を行っていくために
各INPUTパターン（HTTP Request）から
最終的にユーザーにどう表示されるかまでを含めた
E2Eテストが手軽に行える状態になると
安心した改善が行え、捗ると思います。

弊社のOSS「Bucky」では、このようなE2Eテストが
簡単なYAMLファイルを書いていくだけで
作っていくことができます。

Buckyで実際に防げた問題の事例
1. ある機能開発が完了
2. Buckyの実施結果も正常
3. developブランチを取り込み、再度Buckyを実行
4. 問題発生（影響範囲と認識していない部分でのエラー画面）
5. 原因調査
6. featureブランチ単体でも、developブランチ単体でも問題はないが、
両者が合わさると問題となる既存の複合バグであり、いつ起こって
もおかしくない潜在的なバグであることがわかった
もし事前にBuckyを回していなければ、マージされdevelopブランチで問
題が初めて発生し、混乱を招いていたことになります。

5. まとめ

5. まとめ
使用ツール・サービス長所短所
1 Code Climate Quality
• 技術的負債がわかりやすい
• 対症療法的な負債返済が可能
• 開発サイクルに言及しない
• 実行順序等を考慮しない
2 Code Climate CLI
• 無料でローカルでQuality同等の機能が使える
• JSONで解析ローデータを出力し解析できる
• 上記同様
3 Code Climate Velocity
• Github上で表現される開発サイクルを可視化・
分析できる
• Github上で表現されない部分は含まれな
い
4 Datadog APM
• 分析より可視化
• 実行順序を考慮した改善ができる
• 実行速度を意識した実装改善が可能
• 何が良くないかは示してはくれない
• クライアントサイドのスクリプトには対
応できない
5 Bucky
• E2Eテスト仕様をYAMLで蓄積
• 改善の過程での、予期せぬ他への影響を検知
• 安心して改善を進めていくためのパートナー

5. まとめ
大規模の場合、効果的な負債返済計画を立てる必要がある。
（１）Project InVersion
（２）新規開発と共に
（３）負債返済チーム
（４）負債返済チーム＋発生原因解消チーム
全員で負債返済
新規開発チームのライフワークに沿った返済
新規開発チーム負債返済チーム
新規開発チーム負債返済チーム負債原因解消チーム

5. まとめ
戦いは続く

【Ltech#8】技術的負債返済・実装改善に関する事例紹介

Recommandé

Contenu connexe

Similaire à 【Ltech#8】技術的負債返済・実装改善に関する事例紹介

Similaire à 【Ltech#8】技術的負債返済・実装改善に関する事例紹介 (20)

Plus de LIFULL Co., Ltd.

Plus de LIFULL Co., Ltd. (20)

Dernier

Dernier (7)

【Ltech#8】技術的負債返済・実装改善に関する事例紹介