meetup_20210608_roum - Speaker Deck

meetup_20210608_roum

Slide 1

Slide 1 text

Slide 2

Slide 2 text

#RAKUSMeetup 自己紹介経歴 ● SIerを経て2016年にラクスに入社 ● 楽楽労務開発チームには 2019年から合流主な仕事 ● 詳細設計、実装 ● メンバーの進捗管理、フォロー趣味 ● ハイキング ● 歴史SLG 岡本　直樹 (Naoki Okamoto) 2

Slide 3

Slide 3 text

#RAKUSMeetup について ● クラウド型の労務管理システム ● 開発開始：2018年8月 ● リリース：2019年8月 3

Slide 4

Slide 4 text

#RAKUSMeetup ラクスのサービスの中では、まだまだ駆け出したばかり 4

Slide 5

Slide 5 text

#RAKUSMeetup とはいえ、開発開始から3年も経つと 5

Slide 6

Slide 6 text

#RAKUSMeetup 楽楽労務の開発／運用で負債を感じたことはありますか？「2021-04 開発チーム内負債に関する意識調査」 6

Slide 7

Slide 7 text

#RAKUSMeetup ● 〇〇〇処理が独自でスケールしない ● ■■■が△△△に依存していて改修しづらい ● ✕✕✕が毎回手作業でしんどい ● 〇〇〇の処理が人依存で手がつけられない ● etc…. 感じたことがある負債の内容を教えて下さい。「2021-04 開発チーム内負債に関する意識調査」 7

Slide 8

Slide 8 text

#RAKUSMeetup 溢れ出る負債たち 8 8

Slide 9

Slide 9 text

#RAKUSMeetup というわけで 9

Slide 10

Slide 10 text

#RAKUSMeetup 楽楽労務開発チームの負債との向き合い方について ”少し”紹介してみます 10

Slide 11

Slide 11 text

#RAKUSMeetup 喋れる範囲で 11

Slide 12

Slide 12 text

#RAKUSMeetup ● 負債が発生したのはいつか ● 負債が発生した原因は何か ● 負債の解決を先送りした理由は何かまずは、現在未解決な負債の紹介 12

Slide 13

Slide 13 text

#RAKUSMeetup 負債が発生したのはいつか ➢ 開発当初から継続して発生している問題。負債が発生した原因は何か ➢ フロントエンドのノウハウがあまりない状態で開発が始まったため、開発初期においてUIのコンポーネント化が十分でなく、現在も同じようなUIで実装方法が違っている箇所がある。 UIの仕様・実装の共通化が不十分 13

Slide 14

Slide 14 text

#RAKUSMeetup 負債の解決を先送りした理由は何か ➢ リリースが優先されており、現在の機能規模であれば開発速度に対して致命的な問題になりえないため、解決が先送りされている。 UIの仕様・実装の共通化が不十分 14

Slide 15

Slide 15 text

#RAKUSMeetup 負債が発生したのはいつか ➢ 機能が追加されるとともに発生してきた問題。負債が発生した原因は何か ➢ バックエンドのコントローラークラスなど、責務が多重になりがちなクラスを適切に分割できずにいた結果、神モジュールになってしまっている。神モジュールがいくつか存在する 15

Slide 16

Slide 16 text

#RAKUSMeetup 負債の解決を先送りした理由は何か ➢ 機能追加によるドメイン理解の変化が目まぐるしく、先々までを考慮した責務分割が難しいため、敢えてそのままにして未来の仕様を考慮した判断をしないようにしている。神モジュールがいくつか存在する 16

Slide 17

Slide 17 text

#RAKUSMeetup 負債が発生したのはいつか ➢ リリース後、運用開始時点から発生している問題。負債が発生した原因は何か ➢ 定期的に行っている運用業務の一部がコード化されておらず、毎回手動で行っているため、実施に時間がかかっており、人為的ミスを誘発してしまう可能性もある。コード化されていない運用作業がある 17

Slide 18

Slide 18 text

#RAKUSMeetup 負債の解決を先送りした理由は何か ➢ 追加機能の開発を優先しているため、運用に割けるリソースが最小限に抑えられている。そのため運用負債の解消も最小限となっている。コード化されていない運用作業がある 18

Slide 19

Slide 19 text

#RAKUSMeetup 先送りされ続ける理由は... 19 19

Slide 20

Slide 20 text

#RAKUSMeetup 「開発速度優先」というプロダクト事情 20 20

Slide 21

Slide 21 text

#RAKUSMeetup では、いつまで先送りにするのか 21

Slide 22

Slide 22 text

#RAKUSMeetup “少し”ずつでも解決していくための取り組みを継続中 22

Slide 23

Slide 23 text

#RAKUSMeetup 単体機能開発サイクル：実装コードの見直しバージョンサイクル：UI／UXの見直し半期サイクル：運用／開発プロセスの見直し定期的なサイクルで負債の見直しを実施中 23

Slide 24

Slide 24 text

#RAKUSMeetup 単体機能開発サイクルバージョンサイクル半期サイクル単体機能開発サイクルでの取り組み 24

Slide 25

Slide 25 text

#RAKUSMeetup 実装コードの見直し単体機能開発中に発生したコードの負債はTODO、FIXMEコメントで残しておき、随時対応する・しないを検討している。機能実装完了時点で解消できてないコメントについては洗い出して一覧化し、改修内容が開発スケジュールに収まるかどうかをポイントとして見送るかどうかの最終判断をしている。また、対応を見送る場合は見送り理由を記載し、見直し時に判断をしやすいようにしている。 25

Slide 26

Slide 26 text

#RAKUSMeetup 実装コードの見直し対応事例①：共通の仕組みに対応できていなかったコードを修正ダイアログ表示用の共通コンポーネントを実装した際、並行して開発を進めていた画面でだけ対応が追いつかず、一部共通化できていないコンポーネントができてしまった。 ➢ 共通化できていないコンポーネントの存在は、今後の新規メンバーにとって暗黙知になってしまい、横展開などの簡易作業でも考慮が発生してしまうので優先的に対応した。 26

Slide 27

Slide 27 text

#RAKUSMeetup 実装コードの見直し対応事例②：定数化された環境変数を設定ファイルに切り出す外部システム連携時のタイムアウト値がコード中に定数化されており、柔軟に変更できなくなっていた。 ➢ 対応工数が少なく、コード修正無しで変更できるという運用上のメリットも大きかったので優先して対応した。 27

Slide 28

Slide 28 text

#RAKUSMeetup バージョンサイクルでの取り組みバージョンサイクル半期サイクル単体機能開発サイクル 28

Slide 29

Slide 29 text

#RAKUSMeetup UI・UXの見直し UI・UXなど主にサービスの使い勝手に関わる負債解消に取り組む。ユーザーフレンドリーではないUI・UXなど、工数の兼ね合いで対応されていない機能に予め優先順位を付けておき、単機能開発の設計時もしくは各バージョンでリリースする機能セット検討時に、棚卸しを行い対応が可能かを検討する。優先順位はビジネス側の要求の強い順に並べるが、着手順は実際の工数を加味して決めている。 29

Slide 30

Slide 30 text

#RAKUSMeetup UI・UXの見直し対応事例①：カレンダーコンポーネントの入力方法改善カレンダーコンポーネントで手入力ができず、カレンダーで直接日付を選択する必要があったため、生年月日などカレンダーの初期表示（当日）から離れた値の入力が手間だった。 ➢ 初回リリース時に工数兼ね合いで見送りになって以降見直せずにいたが、この6月リリース予定バージョンの機能セット検討時に、優先度が高く次期バージョンへの工数的影響も少なかったので、この見送り仕様を対応することにした。 30

Slide 31

Slide 31 text

#RAKUSMeetup UI・UXの見直し対応事例②：ユーザーへのエラーフィードバック詳細化初回リリース時点では、複数エラーを1つの丸めたメッセージで扱っていたためエラーの詳細がわからずユーザーフレンドリーではない画面がいくつかあった。 ➢ 機能が増えるに連れユーザーに通知するエラーへの考察が進んできており、新規機能の設計時にエラーメッセージが新設される場合は、既存機能も含めた見直しを行っている。 31

Slide 32

Slide 32 text

#RAKUSMeetup 半期サイクルでの取り組み単体機能開発サイクル半期サイクルバージョンサイクル 32

Slide 33

Slide 33 text

#RAKUSMeetup 運用／開発プロセスの見直し開発プロセスや運用手順など、短期的に解決できない問題に取り組む。各期末毎に開発チーム内での課題の洗い出しを行い、重要度・難易度に応じて、主幹となるメンバーを決めて改善施策を進めている。 33

Slide 34

Slide 34 text

#RAKUSMeetup 運用／開発プロセスの見直し対応事例①：ログ参照方法の改善 AWSのGUIでしかログを参照することができず、毎回大量のログをAWSから手動でダウンロードする必要があり、目的のログを検索することが困難だった。 ➢ AWSのログを定期的にサーバーへダウンロードして当該サーバーにアクセスするだけで目的のログをすぐに検索できるようにした。 ➢ 更に、AWS上では細かく分割されていたログファイルを日時で結合して配置することで、検索自体も容易に実施できるようになった。 34

Slide 35

Slide 35 text

#RAKUSMeetup 運用／開発プロセスの見直し対応事例②：リグレッションテストの運用方法見直し（現在実施中）手動のリグレッションテストについて、工数に比してバグ検知率が低く、かつ、機能数に比例して工数が増加してきているので、運用の見直しが必要になった。 ➢ リグレッションテストで実施するテスト観点の再定義を行い、無駄なテストを減らし、必要なものだけに絞ろうとしている。 ➢ また、再定義した観点のうちE2Eテスト等で自動化できるものについては、積極的に自動化しようとしている。 35

Slide 36

Slide 36 text

#RAKUSMeetup 重要なのは「先送り」していることを認識し続け放置が当たり前になることを防ぐこと 36 36

Slide 37

Slide 37 text

#RAKUSMeetup そのために、定期的なサイクルで ”少し”ずつでも負債に向き合う必要がある 37 37

Slide 38

Slide 38 text

#RAKUSMeetup まとめると 38

Slide 39

Slide 39 text

#RAKUSMeetup ● 開発速度を優先しなければならない状況では、すぐに負債を解決していくことはなかなか難しく、戦略的に先送りにしなければならない負債もそれなりにある。 ● とはいえ、その状態を続けていくと負債の放置が当たり前になってしまうので、定期的なサイクルで強制的に立ち止まって、”少し”ずつでも負債を解決する取り組みを行っている。楽楽労務負債との向き合い方 39

Slide 40

Slide 40 text

#RAKUSMeetup 最後に 40

Slide 41

Slide 41 text

#RAKUSMeetup 振り返ってみて、今の負債の量をどう感じていますか？「2021-04 開発チーム内負債に関する意識調査」 41

Slide 42

Slide 42 text

#RAKUSMeetup ● ほぼ全てのメンバーが負債があると感じてはいるものの、継続的な取り組みにより徐々に解決することはできており、負債量に関するアンケートでは半数のメンバーは最適な量だと考えている事がわかった。 ● とはいえ、残り半分は「もっと少なくできた」と回答しているので、今後チームがスケールアップしていけば、「負債について本気だして考える」必要が出てきそう。負債について”少し”本気出して考えてわかったこと 42

Slide 43

Slide 43 text

#RAKUSMeetup 負債との戦いはこれからも続く。。。 43