Slide 1

Slide 1 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. ©2022 RAKUS Co., Ltd. 酒井 幸教 サポートチャットサービスを ローンチしてから5年間で 発生した負債と対策

Slide 2

Slide 2 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 自己紹介 酒井 幸教(さかい ゆきのり) 2007年よりラクスのクラウドサービス 配配メール・クルメル・メールディーラーの開発を経験し 現在はチャットディーラーの開発に携わり 実装チームのサブリーダを担当している。

Slide 3

Slide 3 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 今回話す内容について サポートチャットサービス(チャットディーラー)が ローンチされてからの5年間で生じた 技術的負債について話させていただきます。 • 技術的負債が生じた経緯 • 技術的負債の解消に向けた対策

Slide 4

Slide 4 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. チャットディーラーとは チャットボットを提供するサービス お客様サイトへ簡単にチャットボットを設置可能 設置 <!-- var vgHost='xxx.xxx.xx',vgProtocol='https',vgPort='443',vgAtxt='k7Y7zq0g1T',vgSid=2; (function(){try{ var ins=document.createElement('script'),dt=new Date,tg=document.getElementsByTagName('script')[0]; ins.type='text/javascript';ins.async=!0;ins.setAttribute('charset','utf-8'); ins.src=vgProtocol+'://'+vgHost+':'+vgPort+'/chat/client.js?'+dt.getTime();tg.parentNode.insertBefor e(ins,tg); }catch(e){console.log(e);}})(); //--> 設置タグをHTMLに記載

Slide 5

Slide 5 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 目次 1.サービスのローンチ時点からの技術的負債 6 生じた負債 10 対策 13 2.アプリケーションの種類が増えた事による技術的負債 15 生じた負債 17 対策 21 3.メンバ体制の変更による技術的負債の発生 23 生じた負債 25 対策 27 4.度重なる改修によって蓄積される技術的負債 29 生じた負債 31 対策 33 まとめ 35

Slide 6

Slide 6 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点 からの技術的負債

Slide 7

Slide 7 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点からの技術的負債 開発期間が短期の開発(6ヶ月間、内実装は2ヶ月程) であったため効率重視となり、技術的負債が生じる可能性が高かった。 ※新サービスのローンチに関しては、別の発表資料があるので 詳細はこちらをご覧ください。 チャットデ ィーラーの高速開発を支えるLaravel https://speakerdeck.com/koheisakata/laraveljpcon-chatdealer-rapid-development-with-laravel

Slide 8

Slide 8 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点からの技術的負債 技術的負債の発生を防ぐために、開発着手前に次の施策を準備した。 • 施策 静的コード分析ツール( eslint, phpcs, phpmd )を使用し、コードの品質担保 - エディタ( PhpStorm )上で問題のある箇所を分析しエラーを通知 - GitへのPush後に自動チェックし、メール・Mattermostへエラーを通知

Slide 9

Slide 9 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点からの技術的負債 この様な施策を行ったものの ローンチ時点で、次の様な技術的負債が生じました。

Slide 10

Slide 10 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点からの技術的負債 ■生じた技術的負債 1. Node.jsの実装内容が古臭い Node.jsが古いJavaScriptの作りになっている。 ・原因 工数を短縮するために、他サービスの古いNode.jsで作成された 類似機能を参考に実装したため作りが古い。 また、当時のNode.jsのLTSバージョンで同期機能(async, await) が利用できなかったため、ネストが深くなっている。

Slide 11

Slide 11 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点からの技術的負債 ■生じた技術的負債 2. CSS定義の重複 共通のCSS定義が重複してスタイルシートに定義されてしまった。 ・原因 デザイナーから提供されたモックに、共通のCSSが定義されていたため 実装者毎にスタイルシートにCSSを定義してしまい 共通のCSSが一部重複して定義された。 CSS 重複

Slide 12

Slide 12 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点からの技術的負債 こちらの技術的負債ついて 次の対策を実施

Slide 13

Slide 13 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点からの技術的負債 ■対策 1. Node.jsの最新化 Node.jsのLTSバージョンが同期機能(async, await)に対応した後 共通部品を最新の書き方で使いやすい形式にリファクタリングし 今後の開発で、可読性の良い書き方が行えるよう対応した。

Slide 14

Slide 14 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 1.サービスのローンチ時点からの技術的負債 ■対策 2. リファクタリングバージョンの設定 年に2回、リファクタリングを行うためのバージョンを設けた。 リファクタリングの候補は発見された時点で、リファクタリング候補一覧へ追加し リファクタリングバージョンで、棚卸しを行い優先度が高い問題から解決して行く。 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 リファクタリングを実施

Slide 15

Slide 15 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 2.アプリケーションの 種類が増えた事による 技術的負債

Slide 16

Slide 16 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. チャットディーラー 2.アプリケーションの種類が増えた事による技術的負債 同一コード内にアプリケーションの種類が増え 種類ごとに異なる仕様や処理が増え、技術的負債が発生。 タイプA タイプB

Slide 17

Slide 17 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 2.アプリケーションの種類が増えた事による技術的負債 ■生じた技術的負債 1. 可読性の低下 処理の分岐の増加、1ファイル内のコード量の増加 xxxxxxxxxxxxxxx; switch (appType) { case アプリケーションA; xxxxxxxxxx; break; case アプリケーションB; xxxxxxxxxx; break; } ・・・ アプリケーションの種類ごとに 分岐と処理が増加

Slide 18

Slide 18 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 2.アプリケーションの種類が増えた事による技術的負債 ■生じた技術的負債 2. 開発工数の増加 アプリケーションの種類を意識した設計・実装が必要 ・○○ 項目は【タイプB】のみ表示する。 ・○○オプションは【タイプA】 のみ使用できる。 ・ 【タイプA】では、○○テーブル、 【タイプB】では□ □テーブルからデータを取得する。 ・ チャットの応答は【タイプA】は○○で応答をし、 【タイプB】では□ □で応答する。 等

Slide 19

Slide 19 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 2.アプリケーションの種類が増えた事による技術的負債 ■生じた技術的負債 3. テスト工数の増加 特定のアプリケーションのタイプに対しての修正であっても コードが共通なので、対象外のタイプについてもテストが必要になる タイプA タイプB テスト範囲は両方 タイプBのみ修正

Slide 20

Slide 20 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 2.アプリケーションの種類が増えた事による技術的負債 こちらの技術的負債ついて 次の対策を実施

Slide 21

Slide 21 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 2.アプリケーションの種類が増えた事による技術的負債 ■対策 アプリケーションの種類によって、コードを分離する予定。 これにより対象外のアプリケーションへの影響がなくなり、改修を進めやすくなる。 コード タイプA タイプB コード タイプA コード タイプB 分離

Slide 22

Slide 22 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 2.アプリケーションの種類が増えた事による技術的負債 ■対策 ただし、定期作業や共通機能の改修頻度などによって、分離は行わない方が良い場合もある。 ・共通機能の修正 改修工数の倍増 ・定期作業 MWアップデート等の定期作業で工数が倍増 ・機器コスト 分離した分だけ環境が必要になる可能性があり、機器コストが上がる。

Slide 23

Slide 23 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 3.メンバ体制の変更による 技術的負債の発生

Slide 24

Slide 24 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 3.メンバ体制の変更による技術的負債の発生 フロント/バックエンドの開発担当を分けず開発が行われており フロント/バックエンドが密結合されている。 そんな中、フロントエンドエンジニアが参入したところ タスクの分担が行いづらいという課題が発生。

Slide 25

Slide 25 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 3.メンバ体制の変更による技術的負債の発生 ■生じた技術的負債 1. フロントエンドのみでの開発が行えない状態 フロントエンド バックエンド

Slide 26

Slide 26 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 3.メンバ体制の変更による技術的負債の発生 こちらの技術的負債ついて 次の対策を実施

Slide 27

Slide 27 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 3.メンバ体制の変更による技術的負債の発生 ■対策 1. 既存画面について、先行してフロントエンド部分を分離していく。 フロントエンドとバックエンドを疎結合にすることで、分担しやすい状態へもっていく。 ※次のバージョンで改修が入る画面を優先して分離作業を実施 フロントエンド バックエンド フロントエンド バックエンド 分離

Slide 28

Slide 28 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 3.メンバ体制の変更による技術的負債の発生 ■対策 2. 新規画面については、フロントエンド・バックエンドが 疎結合された構成で作成する フロントエンド バックエンド

Slide 29

Slide 29 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 4.度重なる改修によって 蓄積される技術的負債

Slide 30

Slide 30 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 4.重なる改修によって蓄積される技術的負債 度重なる改修により、レスポンス速度が低下した。 • 機能追加による処理工程の増加 • 速度面で良くない実装箇所の増加 チャットディーラー v5.0リリース v7.Xリリース 速度劣化

Slide 31

Slide 31 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 4.重なる改修によって蓄積される技術的負債 ■生じた技術的負債 1. 速度劣化によるサービス品質の低下 速度が劣化することにより、次のような問題が引き起こされる。 • 処理速度の低下により、大量のアクセスが応答待ちとなる障害の発生 • サーバに収容できるアカウント数が下がり機器コストの増加

Slide 32

Slide 32 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 4.重なる改修によって蓄積される技術的負債 こちらの技術的負債ついて 次の対策を実施

Slide 33

Slide 33 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 4.度重なる改修によって蓄積される技術的負債 ■対策 1. リリース前に負荷テストを実施 リリース準備の流れに負荷テストを導入し、速度劣化が発生していないか検知するステップを作成 運用に影響があるような速度劣化があった場合には解消してからリリース。 開発 結合テスト 負荷テスト リリース

Slide 34

Slide 34 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. 4.度重なる改修によって蓄積される技術的負債 ■対策 2. 定期的な速度改善の実施 ① 速度改善が可能な箇所があるか調査 • プロファイラの活用 • SQL応答時間の調査 等 ② 改善点があれば、修正を実施

Slide 35

Slide 35 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. まとめ

Slide 36

Slide 36 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. まとめ 技術的負債は様々な経緯で生じるので ゼロに抑えることは難しいです。 ただ、技術的負債が蓄積されていくと サービスの品質や開発力の低下に繋がるため 定期的に予防策やリファクタリングを進めることが重要になります。

Slide 37

Slide 37 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. まとめ とはいえ、プロジェクトの状況によっては 対応が進められない事もあるかと思います。 チャットディーラーのプロジェクトでも しばらくの間は優先度の高い機能の早期リリースが優先となり リファクタリングバージョンを見送ることになりました。

Slide 38

Slide 38 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. まとめ 多くの場合、サービスの開発(売っていく)ことが目的だと思うので 状況によって、技術的負債の対応の優先度が下がることは 仕方ない事かと思います。 その様な場合も、見つかった技術的負債の情報を蓄積し 適切なタイミングで、負債の解消を進めていくことが大事だと思います。

Slide 39

Slide 39 text

#RAKUSMeetup ©2022 RAKUS Co., Ltd. ご清聴ありがとうございました