継続的リファクタリングの工数を確保できる理由 / RAKUS Meetup Osaka 2020-02-05

【大阪】SaaSを支える開発原則/DDD、プロダクトマネジメント、カンバン、技術的負債＠RAKUS（ https://rakus.connpass.com/event/161744/ ）で発表した際の資料です。

Transcript

1. 継続的リファクタリングの工数 を確保できる理由 ーChatDealer開発チームの場合ー RAKUS Meetup Osaka #5 2020-02-05
2. 自己紹介 • 名前：坂田 晃平 • 所属：株式会社ラクス ◦ ChatDealer 開発チーム • 経歴： ◦ 2016 年 入社（そろそろ4年） ◦ ～ 2017年 MailDealer の開発
3. もくじ • ChatDealer とは • ChatDealer と技術的負債 • リファクタリングバージョンの導入 • リファクタリングバージョンが導入できた理由 • まとめ
4. ChatDealer とは サイト埋め込み型 Web チャットツール 画像出典：いらすとや 利用者 サイト 利用者 訪問者
5. ChatDealer とは サイト埋め込み型 Web チャットツール
6. ChatDealer とは サイト埋め込み型 Web チャットツール • 2017/6/19 β版リリース（満 2 歳 7 か月） • 現在 v5.5 • 通算 29 回のメジャー・マイナーバージョンアップ ◦ 毎月1回のペースで新機能リリース
7. ChatDealer と技術的負債 • 対応保留されたままの軽微な不具合 • 統一感のないUI • パフォーマンスの低下 • 冗長で複雑なコード • etc....
8. ChatDealer と技術的負債 • 毎月リリースで短めな納期 • 開発初期 ◦ 新しい技術要素で不慣れな実装 • 運用開始後 ◦ 機能の継ぎ足し開発
9. ChatDealer と技術的負債 • 毎月リリースで短めな納期 • 開発初期 ◦ 新しい技術要素で不慣れな実装 • 運用開始後 ◦ 機能の継ぎ足し開発
10. ChatDealer の開発体制 利用者 企画・サポートチーム 開発チーム FB・問合せ 要望 実装
11. ChatDealer の開発体制 利用者 開発チーム 早く機能を実装させて市場に受け入れられたい 企画・サポートチーム
12. ChatDealer の開発体制 利用者 開発チーム 素早くフィードバックループを回して プロダクトの価値を高めたい 企画・サポートチーム
13. ChatDealer の開発体制 利用者 開発チーム 企画・サポートチーム 毎月リリースで追いつけ追い越せ！
14. 毎月リリースの功罪 • 素早い機能提供でどんどん成長！ ◦ 利用者のニーズに合わせて細かく改修 • 技術的負債もどんどん発生… ◦ 軽微不具合は後回し ◦ 短納期でコードがそのまま ◦ コードにコードの継ぎ足しで複雑化
15. ChatDealer と技術的負債 • 毎月リリースで短めな納期 • 開発初期 ◦ 新しい技術要素で不慣れな実装 • 運用開始後 ◦ 機能の継ぎ足し開発
16. ChatDealer で採用した技術要素 新しい技術でモダンな開発をしよう！
17. ChatDealer で採用した技術要素 理解不足でコードを量産…
18. ChatDealer と技術的負債 • 対応保留されたままの軽微な不具合 • 統一感のないUI • パフォーマンスの低下 • 冗長で複雑なコード • etc....
19. ChatDealer と技術的負債
22. 250行、インデント最大30タブ ※ 画像は公開可能なように改変したもの
24. リファクタリングバージョンの導入 • 課題の解消を主に行うバージョン ◦ 軽微なバグの修正 ◦ UIの改善 ◦ パフォーマンス改善 ◦ リファクタリング ◦ 自動テスト拡充
25. リファクタリングバージョンの導入 • 課題がたまる一方の状況をPLが憂慮 • リファクタリングバージョンを挟むことを 企画・サポートチームに提案 • いくつかの条件を約束したうえで、 リファクタリングバージョンが実現した
26. リファクタリングバージョンの約束 • 新機能を１個以上入れること ◦ 小規模なものでOK • 開発のペースは維持すること ◦ 今後も月に1回のペース • 課題は優先度を付けて対応すること ◦ 改善効果の明確でないリファクタリングはしない
27. リファクタリングバージョンが導入できた理由 • 高速な開発によって時間的余裕が生まれていた • 企画・サポートチームとの課題認識の共有に成功した ◦ UI改善で解決できるサポート問い合わせの増加 ◦ リファクタリングの効果は具体的な数値で明示 （機能開発の見積もり工数がどれだけ違うか） ◦ 毎月確実に期待に応えてきた信頼と実績
28. リファクタリングバージョンが導入できた理由 • 高速な開発によって時間的余裕が生まれていた • 企画・サポートチームとの課題認識の共有に成功した ◦ UI改善で解決できるサポート問い合わせの増加 ◦ リファクタリングの効果は具体的な数値で明示 （機能開発の見積もり工数がどれだけ違うか） ◦ 毎月確実に期待に応えてきた信頼と実績
29. 高速な開発をし続けたから！ リファクタリングバージョンが導入できた理由
30. 高速な開発をしよう • 開発のペースを維持するためにやってきたこと ◦ 設計時：不要な機能は作らない YAGNI ◦ 実装時：無理に完璧を 目指さない 目指せない Done is better than perfect
31. 高速な開発をしよう • 開発のペースを維持するために続けていくこと ◦ 設計時：不要な機能は作らない YAGNI ◦ 実装時：無理に完璧を目指さない Done is better than perfect
32. リファクタリング推進サイクル 高速な開発 時間的余裕 リファクタリング • 不要な機能は作らない YAGNI • 無理に完璧を目指さない Done is better than perfect
33. おまけ
34. 高速な開発のために • YAGNIの例：デザイン改修の提案 ◦ チャットの表示デザインの自由度を大幅に上げる ◦ 色々とバリエーションを作って提供しよう ・・・
35. 高速な開発のために • YAGNIの例：デザイン改修の提案 ◦ チャットの表示デザインの自由度を大幅に上げる いくつかのパターンから選択できれば充分 ◦ 色々とバリエーションを作って提供しよう ・・・
36. リファクタリングバージョンの効果 • 共通化による以降の開発工数低下 • 綺麗なコードの重要性を体感 • 正しいソースの記述方法がチーム内に浸透 • 不満を抱えながら作業をするストレスが軽減
37. リファクタリングバージョンの効果 • 思い切って大規模な修正ができる • 考慮漏れや場当たり的な改修が起きにくい • MWの定期的な更新の良い機会 • UI改善によるサポートコスト削減
38. リファクタリングバージョンの効果
39. チームメンバーの声 • 開発がかなりやり易くなった • 精神的にも一息つける気がして良い • 気になっていた細かい挙動について見直すことができた • わかりやすく改修しやすくなった • ログが整理されて、運用しやすくなった
40. 個人の感想 • 実装中にイケてないコードを見つけても、 機能実装に集中できるようになった • 実装がイケてないと思っても、 後で直す機会があると思えるので安心できる • Done is better than perfect の罪悪感が軽減