meetup_20210608_roum

Transcript

1. #RAKUSMeetup ©2021 RAKUS Co., Ltd. 初コミットから3年たったので、負債 について”少し”本気出して考えて みた。 株式会社 ラクス 岡本 直樹 #RAKUSMeetup 1
2. #RAKUSMeetup 自己紹介 経歴 • SIerを経て2016年にラクスに入社 • 楽楽労務開発チームには 2019年から合流 主な仕事 • 詳細設計、実装 • メンバーの進捗管理、フォロー 趣味 • ハイキング • 歴史SLG 岡本　直樹 (Naoki Okamoto) 2
3. #RAKUSMeetup について • クラウド型の労務管理システム • 開発開始：2018年8月 • リリース：2019年8月 3
4. #RAKUSMeetup ラクスのサービスの中では、 まだまだ駆け出したばかり 4
5. #RAKUSMeetup とはいえ、 開発開始から3年も経つと 5
6. #RAKUSMeetup 楽楽労務の開発／運用で負債を感じたことはあります か？ 「2021-04 開発チーム内 負債に関する意識調査」 6
7. #RAKUSMeetup • 〇〇〇処理が独自でスケールしない • ▪▪▪が△△△に依存していて改修しづらい • ✕✕✕が毎回手作業でしんどい • 〇〇〇の処理が人依存で手がつけられない • etc…. 感じたことがある負債の内容を教えて下さい。 「2021-04 開発チーム内 負債に関する意識調査」 7
8. #RAKUSMeetup 溢れ出る負債たち 8 8
9. #RAKUSMeetup というわけで 9
10. #RAKUSMeetup 楽楽労務開発チームの 負債との向き合い方について ”少し”紹介してみます 10
11. #RAKUSMeetup 喋れる範囲で 11
12. #RAKUSMeetup • 負債が発生したのはいつか • 負債が発生した原因は何か • 負債の解決を先送りした理由は何か まずは、現在未解決な負債の紹介 12
13. #RAKUSMeetup 負債が発生したのはいつか ➢ 開発当初から継続して発生している問題。 負債が発生した原因は何か ➢ フロントエンドのノウハウがあまりない状態で開発が始まったため、開発初期にお いてUIのコンポーネント化が十分でなく、現在も同じようなUIで実装方法が違ってい る箇所がある。 UIの仕様・実装の共通化が不十分 13
14. #RAKUSMeetup 負債の解決を先送りした理由は何か ➢ リリースが優先されており、現在の機能規模であれば開発速度に対して致命的な 問題になりえないため、解決が先送りされている。 UIの仕様・実装の共通化が不十分 14
15. #RAKUSMeetup 負債が発生したのはいつか ➢ 機能が追加されるとともに発生してきた問題。 負債が発生した原因は何か ➢ バックエンドのコントローラークラスなど、責務が多重になりがちなクラスを適切に 分割できずにいた結果、神モジュールになってしまっている。 神モジュールがいくつか存在する 15
16. #RAKUSMeetup 負債の解決を先送りした理由は何か ➢ 機能追加によるドメイン理解の変化が目まぐるしく、先々までを考慮した責務分割 が難しいため、敢えてそのままにして未来の仕様を考慮した判断をしないようにし ている。 神モジュールがいくつか存在する 16
17. #RAKUSMeetup 負債が発生したのはいつか ➢ リリース後、運用開始時点から発生している問題。 負債が発生した原因は何か ➢ 定期的に行っている運用業務の一部がコード化されておらず、毎回手動で行って いるため、実施に時間がかかっており、人為的ミスを誘発してしまう可能性もある。 コード化されていない運用作業がある 17
18. #RAKUSMeetup 負債の解決を先送りした理由は何か ➢ 追加機能の開発を優先しているため、運用に割けるリソースが最小限に抑えられ ている。そのため運用負債の解消も最小限となっている。 コード化されていない運用作業がある 18
19. #RAKUSMeetup 先送りされ続ける理由は... 19 19
20. #RAKUSMeetup 「開発速度優先」 というプロダクト事情 20 20
21. #RAKUSMeetup では、いつまで先送りにするのか 21
22. #RAKUSMeetup “少し”ずつでも解決していくための 取り組みを継続中 22
23. #RAKUSMeetup 単体機能開発サイクル：実装コードの見直し バージョンサイクル：UI／UXの見直し 半期サイクル：運用／開発プロセスの見直し 定期的なサイクルで負債の見直しを実施中 23
24. #RAKUSMeetup 単体機能開発サイクル バージョンサイクル 半期サイクル 単体機能開発サイクルでの取り組み 24
25. #RAKUSMeetup 実装コードの見直し 単体機能開発中に発生したコードの負債はTODO、FIXMEコメントで残しておき、随時対 応する・しないを検討している。 機能実装完了時点で解消できてないコメントについては洗い出して一覧化し、改修内容 が開発スケジュールに収まるかどうかをポイントとして見送るかどうかの最終判断をして いる。 また、対応を見送る場合は見送り理由を記載し、見直し時に判断をしやすいようにして いる。 25
26. #RAKUSMeetup 実装コードの見直し 対応事例①：共通の仕組みに対応できていなかったコードを修正 ダイアログ表示用の共通コンポーネントを実装した際、並行して開発を進めていた画面 でだけ対応が追いつかず、一部共通化できていないコンポーネントができてしまった。 ➢ 共通化できていないコンポーネントの存在は、今後の新規メンバーにとって暗黙知 になってしまい、横展開などの簡易作業でも考慮が発生してしまうので優先的に対 応した。 26
27. #RAKUSMeetup 実装コードの見直し 対応事例②：定数化された環境変数を設定ファイルに切り出す 外部システム連携時のタイムアウト値がコード中に定数化されており、柔軟に変更でき なくなっていた。 ➢ 対応工数が少なく、コード修正無しで変更できるという運用上のメリットも大きかっ たので優先して対応した。 27
28. #RAKUSMeetup バージョンサイクルでの取り組み バージョンサイクル 半期サイクル 単体機能開発サイクル 28
29. #RAKUSMeetup UI・UXの見直し UI・UXなど主にサービスの使い勝手に関わる負債解消に取り組む。 ユーザーフレンドリーではないUI・UXなど、工数の兼ね合いで対応されていない機能に 予め優先順位を付けておき、単機能開発の設計時もしくは各バージョンでリリースする 機能セット検討時に、棚卸しを行い対応が可能かを検討する。 優先順位はビジネス側の要求の強い順に並べるが、着手順は実際の工数を加味して 決めている。 29
30. #RAKUSMeetup UI・UXの見直し 対応事例①：カレンダーコンポーネントの入力方法改善 カレンダーコンポーネントで手入力ができず、カレンダーで直接日付を選択する必要が あったため、生年月日などカレンダーの初期表示（当日）から離れた値の入力が手間 だった。 ➢ 初回リリース時に工数兼ね合いで見送りになって以降見直せずにいたが、この6月 リリース予定バージョンの機能セット検討時に、優先度が高く次期バージョンへの 工数的影響も少なかったので、この見送り仕様を対応することにした。 30
31. #RAKUSMeetup UI・UXの見直し 対応事例②：ユーザーへのエラーフィードバック詳細化 初回リリース時点では、複数エラーを1つの丸めたメッセージで扱っていたためエラーの 詳細がわからずユーザーフレンドリーではない画面がいくつかあった。 ➢ 機能が増えるに連れユーザーに通知するエラーへの考察が進んできており、新規 機能の設計時にエラーメッセージが新設される場合は、既存機能も含めた見直しを 行っている。 31
32. #RAKUSMeetup 半期サイクルでの取り組み 単体機能開発サイクル 半期サイクル バージョンサイクル 32
33. #RAKUSMeetup 運用／開発プロセスの見直し 開発プロセスや運用手順など、短期的に解決できない問題に取り組む。 各期末毎に開発チーム内での課題の洗い出しを行い、重要度・難易度に応じて、主幹と なるメンバーを決めて改善施策を進めている。 33
34. #RAKUSMeetup 運用／開発プロセスの見直し 対応事例①：ログ参照方法の改善 AWSのGUIでしかログを参照することができず、毎回大量のログをAWSから手動でダウ ンロードする必要があり、目的のログを検索することが困難だった。 ➢ AWSのログを定期的にサーバーへダウンロードして当該サーバーにアクセスする だけで目的のログをすぐに検索できるようにした。 ➢ 更に、AWS上では細かく分割されていたログファイルを日時で結合して配置するこ とで、検索自体も容易に実施できるようになった。 34
35. #RAKUSMeetup 運用／開発プロセスの見直し 対応事例②：リグレッションテストの運用方法見直し（現在実施中） 手動のリグレッションテストについて、工数に比してバグ検知率が低く、かつ、機能数に 比例して工数が増加してきているので、運用の見直しが必要になった。 ➢ リグレッションテストで実施するテスト観点の再定義を行い、無駄なテストを減らし、 必要なものだけに絞ろうとしている。 ➢ また、再定義した観点のうちE2Eテスト等で自動化できるものについては、積極的 に自動化しようとしている。 35
36. #RAKUSMeetup 重要なのは 「先送り」していることを認識し続け 放置が当たり前になることを防ぐこと 36 36
37. #RAKUSMeetup そのために、定期的なサイクルで ”少し”ずつでも 負債に向き合う必要がある 37 37
38. #RAKUSMeetup まとめると 38
39. #RAKUSMeetup • 開発速度を優先しなければならない状況では、すぐに負債を解決していくことはな かなか難しく、戦略的に先送りにしなければならない負債もそれなりにある。 • とはいえ、その状態を続けていくと負債の放置が当たり前になってしまうので、定期 的なサイクルで強制的に立ち止まって、”少し”ずつでも負債を解決する取り組みを 行っている。 楽楽労務負債との向き合い方 39
40. #RAKUSMeetup 最後に 40
41. #RAKUSMeetup 振り返ってみて、今の負債の量をどう感じていますか？ 「2021-04 開発チーム内 負債に関する意識調査」 41
42. #RAKUSMeetup • ほぼ全てのメンバーが負債があると感じてはいるものの、継続的な取り組みにより 徐々に解決することはできており、負債量に関するアンケートでは半数のメンバー は最適な量だと考えている事がわかった。 • とはいえ、残り半分は「もっと少なくできた」と回答しているので、今後チームがス ケールアップしていけば、「負債について本気だして考える」必要が出てきそう。 負債について”少し”本気出して考えてわかったこと 42
43. #RAKUSMeetup 負債との戦いはこれからも続く。。。 43