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

Slide 1

Slide 1 text

継続的リファクタリングの工数を確保できる理由ーChatDealer開発チームの場合ー RAKUS Meetup Osaka #5 2020-02-05

Slide 2

Slide 2 text

自己紹介 ● 名前：坂田晃平 ● 所属：株式会社ラクス ○ ChatDealer 開発チーム ● 経歴： ○ 2016 年入社（そろそろ4年） ○ ～ 2017年 MailDealer の開発

Slide 3

Slide 3 text

もくじ ● ChatDealer とは ● ChatDealer と技術的負債 ● リファクタリングバージョンの導入 ● リファクタリングバージョンが導入できた理由 ● まとめ

Slide 4

Slide 4 text

ChatDealer とはサイト埋め込み型 Web チャットツール画像出典：いらすとや利用者サイト利用者訪問者

Slide 5

Slide 5 text

ChatDealer とはサイト埋め込み型 Web チャットツール

Slide 6

Slide 6 text

ChatDealer とはサイト埋め込み型 Web チャットツール ● 2017/6/19 β版リリース（満 2 歳 7 か月） ● 現在 v5.5 ● 通算 29 回のメジャー・マイナーバージョンアップ ○ 毎月1回のペースで新機能リリース

Slide 7

Slide 7 text

ChatDealer と技術的負債 ● 対応保留されたままの軽微な不具合 ● 統一感のないUI ● パフォーマンスの低下 ● 冗長で複雑なコード ● etc....

Slide 8

Slide 8 text

ChatDealer と技術的負債 ● 毎月リリースで短めな納期 ● 開発初期 ○ 新しい技術要素で不慣れな実装 ● 運用開始後 ○ 機能の継ぎ足し開発

Slide 9

Slide 9 text

ChatDealer と技術的負債 ● 毎月リリースで短めな納期 ● 開発初期 ○ 新しい技術要素で不慣れな実装 ● 運用開始後 ○ 機能の継ぎ足し開発

Slide 10

Slide 10 text

ChatDealer の開発体制利用者企画・サポートチーム開発チーム FB・問合せ要望実装

Slide 11

Slide 11 text

ChatDealer の開発体制利用者開発チーム早く機能を実装させて市場に受け入れられたい企画・サポートチーム

Slide 12

Slide 12 text

ChatDealer の開発体制利用者開発チーム素早くフィードバックループを回してプロダクトの価値を高めたい企画・サポートチーム

Slide 13

Slide 13 text

ChatDealer の開発体制利用者開発チーム企画・サポートチーム毎月リリースで追いつけ追い越せ！

Slide 14

Slide 14 text

毎月リリースの功罪 ● 素早い機能提供でどんどん成長！ ○ 利用者のニーズに合わせて細かく改修 ● 技術的負債もどんどん発生… ○ 軽微不具合は後回し ○ 短納期でコードがそのまま ○ コードにコードの継ぎ足しで複雑化

Slide 15

Slide 15 text

ChatDealer と技術的負債 ● 毎月リリースで短めな納期 ● 開発初期 ○ 新しい技術要素で不慣れな実装 ● 運用開始後 ○ 機能の継ぎ足し開発

Slide 16

Slide 16 text

ChatDealer で採用した技術要素新しい技術でモダンな開発をしよう！

Slide 17

Slide 17 text

ChatDealer で採用した技術要素理解不足でコードを量産…

Slide 18

Slide 18 text

ChatDealer と技術的負債 ● 対応保留されたままの軽微な不具合 ● 統一感のないUI ● パフォーマンスの低下 ● 冗長で複雑なコード ● etc....

Slide 19

Slide 19 text

ChatDealer と技術的負債

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

250行、インデント最大30タブ ※ 画像は公開可能なように改変したもの

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

リファクタリングバージョンの導入 ● 課題の解消を主に行うバージョン ○ 軽微なバグの修正 ○ UIの改善 ○ パフォーマンス改善 ○ リファクタリング ○ 自動テスト拡充

Slide 25

Slide 25 text

リファクタリングバージョンの導入 ● 課題がたまる一方の状況をPLが憂慮 ● リファクタリングバージョンを挟むことを企画・サポートチームに提案 ● いくつかの条件を約束したうえで、リファクタリングバージョンが実現した

Slide 26

Slide 26 text

リファクタリングバージョンの約束 ● 新機能を１個以上入れること ○ 小規模なものでOK ● 開発のペースは維持すること ○ 今後も月に1回のペース ● 課題は優先度を付けて対応すること ○ 改善効果の明確でないリファクタリングはしない

Slide 27

Slide 27 text

リファクタリングバージョンが導入できた理由 ● 高速な開発によって時間的余裕が生まれていた ● 企画・サポートチームとの課題認識の共有に成功した ○ UI改善で解決できるサポート問い合わせの増加 ○ リファクタリングの効果は具体的な数値で明示（機能開発の見積もり工数がどれだけ違うか） ○ 毎月確実に期待に応えてきた信頼と実績

Slide 28

Slide 28 text

Slide 29

Slide 29 text

高速な開発をし続けたから！リファクタリングバージョンが導入できた理由

Slide 30

Slide 30 text

高速な開発をしよう ● 開発のペースを維持するためにやってきたこと ○ 設計時：不要な機能は作らない YAGNI ○ 実装時：無理に完璧を目指さない目指せない Done is better than perfect

Slide 31

Slide 31 text

高速な開発をしよう ● 開発のペースを維持するために続けていくこと ○ 設計時：不要な機能は作らない YAGNI ○ 実装時：無理に完璧を目指さない Done is better than perfect

Slide 32

Slide 32 text

リファクタリング推進サイクル高速な開発時間的余裕リファクタリング ● 不要な機能は作らない YAGNI ● 無理に完璧を目指さない Done is better than perfect

Slide 33

Slide 33 text

おまけ

Slide 34

Slide 34 text

高速な開発のために ● YAGNIの例：デザイン改修の提案 ○ チャットの表示デザインの自由度を大幅に上げる ○ 色々とバリエーションを作って提供しよう・・・

Slide 35

Slide 35 text

高速な開発のために ● YAGNIの例：デザイン改修の提案 ○ チャットの表示デザインの自由度を大幅に上げるいくつかのパターンから選択できれば充分 ○ 色々とバリエーションを作って提供しよう・・・

Slide 36

Slide 36 text

リファクタリングバージョンの効果 ● 共通化による以降の開発工数低下 ● 綺麗なコードの重要性を体感 ● 正しいソースの記述方法がチーム内に浸透 ● 不満を抱えながら作業をするストレスが軽減

Slide 37

Slide 37 text

リファクタリングバージョンの効果 ● 思い切って大規模な修正ができる ● 考慮漏れや場当たり的な改修が起きにくい ● MWの定期的な更新の良い機会 ● UI改善によるサポートコスト削減

Slide 38

Slide 38 text

リファクタリングバージョンの効果

Slide 39

Slide 39 text

チームメンバーの声 ● 開発がかなりやり易くなった ● 精神的にも一息つける気がして良い ● 気になっていた細かい挙動について見直すことができた ● わかりやすく改修しやすくなった ● ログが整理されて、運用しやすくなった

Slide 40

Slide 40 text

個人の感想 ● 実装中にイケてないコードを見つけても、機能実装に集中できるようになった ● 実装がイケてないと思っても、後で直す機会があると思えるので安心できる ● Done is better than perfect の罪悪感が軽減