「SmartHR基本機能」の溜まっていく技術課題への取り組み

by motsat

Slide 1

Slide 1 text

CONFIDENTIAL 2022年11月17日「SmartHR基本機能」の溜まっていく技術課題への取り組み株式会社SmartHR プロダクト開発グループ

Slide 2

Slide 2 text

CONFIDENTIAL 自己紹介・「SmartHR基本機能」チームのアプリケーションエンジニア・前職は、医療系サービス・ソーシャルゲーム・映像配信サービスなどのウェブサービスの開発、銀行システムの電話窓口佐藤元紀(@motsat)

Slide 3

Slide 3 text

CONFIDENTIAL 今回お話ししたいこと ● SmartHRの「基本機能」の環境の変化 ● システム上の問題が増え、特に小さな問題が溜まっていく課題があった ● 溜まっていく問題をどんな運用で解決しようとしてきたか

Slide 4

Slide 4 text

CONFIDENTIAL SmartHRとは ● SmartHRは、人事・労務の課題を解決するために生まれたシステム ● 人事情報が集まって、蓄まって、活用できるサービス ● 2022年11月現在、50000社以上が利用

Slide 5

Slide 5 text

CONFIDENTIAL 入社手続き年末調整申請・承認お知らせ掲示板文書配付給与明細従業員サーベイ組織図社員名簿分析レポート赤い部分が、SmartHRの「基本機能」

Slide 6

Slide 6 text

CONFIDENTIAL 約30名約5〜6人 x 6チーム ※クロスファンクショナル（機能横断）なチーム内のエンジニアのみ・・・エンジニア数 SmartHR基本機能

Slide 7

Slide 7 text

CONFIDENTIAL エンジニアは「アプリケーションエンジニア」のみ。 SREやインフラ専門職など職能のチームは無し。チームの構成・・・

Slide 8

Slide 8 text

CONFIDENTIAL スクラムを拡張した「LeSS」を採用。 (Less=1 つの製品に対し、複数のスクラムチームで連携しながら開発をするフレームワーク) ・・・開発のフレームワーク

Slide 9

Slide 9 text

CONFIDENTIAL 「SmartHR 基本機能」の環境の変化

Slide 10

Slide 10 text

CONFIDENTIAL サービス開始現在登録企業の数

Slide 11

Slide 11 text

CONFIDENTIAL 利用企業の規模

Slide 12

Slide 12 text

CONFIDENTIAL 設計の変化・操作履歴/時点指定アクセスの実現 https://speakerdeck.com/f440/implementing-command-history-and-temporal-access ・SmartHRにおけるBiTemporal Data Modelの実践のその後 https://speakerdeck.com/wata727/after-the-practice-of-bitemporal-data-model-in-smarthr 2019/1/14 「履歴機能」リリース。　　　　　　設計の変更、またメインのテーブルを分割 before after

Slide 13

Slide 13 text

CONFIDENTIAL 「モノリス」なので設計変更の影響が大きい・アプリケーションが大きくてつらい・・・ってこと？ https://speakerdeck.com/sugamasao/smarthr rails statsの様子

Slide 14

Slide 14 text

CONFIDENTIAL ● データ急増 ● データの複雑化 ● 使われ方も様々に

Slide 15

Slide 15 text

CONFIDENTIAL 起こった問題

Slide 16

Slide 16 text

CONFIDENTIAL ● データの急増（特に1社あたりのデータ量） 1.サーバー負荷の急上昇

Slide 17

Slide 17 text

CONFIDENTIAL 初期のラフな実装が爆発例) ● 従業員データ（数万）をデータベースから全取得し、アプリケーション側でソート ● 1リクエストで従業員項目の表示数分の数千回のN+1 など... （現在はパフォーマンス面のレビュー、事前テストあり） 1.サーバー負荷の急上昇

Slide 18

Slide 18 text

CONFIDENTIAL ● 設計変更（履歴処理やテーブル分割） ● 使い方の変化（利用する会社/利用ケースの増加) 2.エラーの増加

Slide 19

Slide 19 text

CONFIDENTIAL 例) ● 設計変更（履歴処理やテーブル分割） ○ 従業員を項目Aでソートするとエラー ● 使い方の変化（利用する会社/利用ケースの増加) ○ 手続きA,Bの並行処理でBがエラー（用途が変わった） ○ 非同期処理で使うデータ変更されているとリトライとエラーを繰り返す ● その他 ○ 想定されるバリデーションエラー時に全てエラー管理システムに通知される（なぜか多い）など... （現在はQAチームの誕生や回帰テストの拡充が進んでいます） 2.エラーの増加

Slide 20

Slide 20 text

CONFIDENTIAL 銀の弾丸は無さそう... という事で、それぞれの問題を頑張って直していきます。小〜大まで様々な問題

Slide 21

Slide 21 text

CONFIDENTIAL ● かなりリソースが必要 ● 緊急/重要度が高い ○ 例）パフォーマンス改善で共通部分の設計変更問題(大) 大

Slide 22

Slide 22 text

CONFIDENTIAL ● かなりリソースが必要 ● 緊急/重要度が高い ○ 例）パフォーマンス改善で共通部分の設計変更 = 機能開発を止めて直す、　タスクフォースチームを作る（過去に3回）大問題(大)

Slide 23

Slide 23 text

CONFIDENTIAL 問題(小) ● 問題の割に修正が大変なケースも（古の機能） ● レアケースや実害が無かったり、緊急度は比較的低い ○ 例）手続きを依頼した従業員データをすぐに削除すると内部的にエラー通知が飛ぶ（ユーザー影響は無し）小

Slide 24

Slide 24 text

CONFIDENTIAL 問題(小) 小 = 機能開発を止める...? ● 問題の割に修正が大変なケースも（古の機能） ● レアケースや実害が無かったり、緊急度は比較的低い ○ 例）手続きを依頼した従業員データをすぐに削除すると内部的にエラー通知が飛ぶ（ユーザー影響は無し）

Slide 25

Slide 25 text

CONFIDENTIAL 小大小小小小小小小小扱いが難しい、問題（小）（一つずつは）優先度が低く溜まりがち...

Slide 26

Slide 26 text

CONFIDENTIAL 1つずつはレアケースでも溜まってしまうと頻繁に問題（小）が発生することになり.. 問題(小)が溜まると...

Slide 27

Slide 27 text

CONFIDENTIAL ・サーバー負荷　頻繁に処理が重くなるケースが増えてくる問題(小)が溜まると...

Slide 28

Slide 28 text

CONFIDENTIAL ・エラー　エラーが増え、ユーザー体験が悪くなる。　ユーザー体験に関わらないケースでもエラー通知がノイズになり重要な通知を見逃す問題(小)が溜まると...

Slide 29

Slide 29 text

CONFIDENTIAL 有志で定期的にAPM/エラー通知を確認し、その場で修正したり個人で持ち帰って修正する取り組み有志の改善活動を始めた

Slide 30

Slide 30 text

CONFIDENTIAL 様々な事情で活動が滞りがちになり... 直面した現実

Slide 31

Slide 31 text

CONFIDENTIAL ● 機能開発（スクラム開発）が忙しいと手が回しづらい ● 他のサイドタスクとの時間の取り合いになる ● 気力改善活動が滞る様々な事情

Slide 32

Slide 32 text

CONFIDENTIAL ● 機能開発（スクラム開発）が忙しいと手が回しづらい ● 他のサイドタスクとの時間の取り合いになる ● 気力 →「スキマ時間」「有志」だけの活動の厳しさ改善活動が滞る様々な事情

Slide 33

Slide 33 text

CONFIDENTIAL とはいえ問題（負債）が溜まらないよう、無理なく改善していける体制にする時期が来た... → PO(プロダクトオーナー）、アジャイルコーチ、エンジニア(QAエンジニアも)含めて揉みへ「スキマ時間」「有志」だけは厳しい問題

Slide 34

Slide 34 text

CONFIDENTIAL ● スクラムでの欠陥の扱いは? ○ 特に無さそう ○ まずは最初の作り込みが必要（それはそう） ● 機能開発との優先度比較は？(バックログの管理） ○ 難しい ○ 例. エラーノイズを継続的に減らしたいというタスクと、機能Aのオプション追加といったタスクは目的も違うし比較も大変開発チーム全体で議論

Slide 35

Slide 35 text

CONFIDENTIAL ● 一気に直せば終わる？ ○ 環境の変化で継続的に発生するとしたら継続的な活動になる ● 負債解消をする別チームは? ○ 機能開発チームでも学習しながら取り組みたい ● 見積もりづらいものも多くてやってみたら手間がかかって、機能開発のリソースに影響は出なそう？ ○ 改善活動に使う割合は固定にした方が良いかも ■ スクラムに合わせ、固定割合は消化予定ポイントの「nポイント」を引く形が良さそうなど開発チーム全体で議論

Slide 36

Slide 36 text

CONFIDENTIAL ● 機能開発を一部減らし、改善活動(負債解消)をする ○ フリーな??%活動でなく、確実にやりたい事枠（今回だとサーバー負荷とエラーの改善） ● 改善活動の内容はバックログと別で管理、オーナーを立てる出てきた方針

Slide 37

Slide 37 text

CONFIDENTIAL ● 複数チーム中のnチーム、予定するスプリントの合計ポイント中のnポイント分を改善活動に回す ○ 週替わりで交代 ● 改善活動のタスクは見積もりは行わず、nポイント相当を各チームで判断して行う → 完了しなかったら次のチームへ引き継ぎ ● 「n」の値は運用しつつ調整していくスクラム（LeSS）での運用を考える

Slide 38

Slide 38 text

CONFIDENTIAL タスクの管理 POが管理エンジニアが管理チケット（タスク）チケット（タスク）チケット（タスク）チケット（タスク）機能開発改善活動日次や週次で・Sentry ・NewRelic ・Google Cloud Console などを見て候補出し

Slide 39

Slide 39 text

CONFIDENTIAL 例) 11/2〜11/9は「A」チームが担当チームでの運用例

Slide 40

Slide 40 text

CONFIDENTIAL 例) 翌週 11/10〜11/17は「B」チームが担当チームでの運用例

Slide 41

Slide 41 text

CONFIDENTIAL 1年以上この形で改善活動を行ってみたメリット/デメリット

Slide 42

Slide 42 text

CONFIDENTIAL メリット/デメリットメリット ● 無理なく継続できる ● 機能開発への影響は（まあまあ）小さい ● チーム全体で学習できる（まずい実装がわかったり、パフォーマンスへの理解が深まったり）

Slide 43

Slide 43 text

CONFIDENTIAL メリット/デメリットデメリット ● 大きめなタスクは厳しい ○ 引き継ぎコスト（複数チームなので） ● エラー、パフォーマンスのどちらかに比重がよりがち（パフォーマンス問題が頻度高く起きる時期はエラーが疎かになる）

Slide 44

Slide 44 text

CONFIDENTIAL メリット/デメリットデメリット ● 負債の改善以上は難しい ○ 日々の監視体制の強化や、未来のための設計変更など更に大きな活動は別で必要

Slide 45

Slide 45 text

CONFIDENTIAL 問題は減った？・エラー　JavaScript x 特定のブラウザ問題や外部APIなど、　アプリケーション側で制御しづらい部分以外のエラーはかなり減った。　（QA体制が整った現状は新規のエラーは少ない）

Slide 46

Slide 46 text

CONFIDENTIAL 問題は減った？・サーバー負荷　減ったとは言い切れない... 　過去やその時々の問題は改善されつつ、　更に増えるデータやインフラ移行など環境変化による新しい問題が発生。

Slide 47

Slide 47 text

CONFIDENTIAL まとめ・「SmartHR基本機能」の成長でシステムの問題も急増・小さな問題が溜まりがちだった・開発チーム全体で無理なく解消できる運用を目指した　環境に合わせてまだ運用は変更中

Slide 48

Slide 48 text

CONFIDENTIAL サービスが成長する中で起こる問題を一緒に解決したい方のご応募お待ちしています！ https://smarthr.co.jp/recruit/

Slide 49

Slide 49 text

CONFIDENTIAL ありがとうございました