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

2022/11/17 BtoB SaaSにおける技術課題との向き合い方での登壇資料です。

「SmartHR基本機能」は、全職種合わせ約50名が6チームにわかれて開発しています。サービスを運用する中で、非機能要件(とくにパフォーマンス系タスク)の問題を放置すると、課題が蓄積されていきます。それらの問題への対応を機能開発と並行して進めるために「運用の形を変えてきた歴史」についてお話しします。

Transcript

1. CONFIDENTIAL 2022年11月17日 「SmartHR基本機能」の溜 まっていく技術課題への取 り組み 株式会社SmartHR プロダクト開発グループ
2. CONFIDENTIAL 自己紹介 ・「SmartHR基本機能」チームのアプリケーションエンジニア ・前職は、医療系サービス・ソーシャルゲーム・映像配信サービス などのウェブサービスの開発、銀行システムの電話窓口 佐藤 元紀(@motsat)
3. CONFIDENTIAL 今回お話ししたいこと • SmartHRの「基本機能」の環境の変化 • システム上の問題が増え、特に小さな問題が溜まっ ていく課題があった • 溜まっていく問題をどんな運用で解決しようとしてきた か
4. CONFIDENTIAL SmartHRとは • SmartHRは、人事・労務の課題を解決するために生 まれたシステム • 人事情報が集まって、蓄まって、活用できるサー ビス • 2022年11月現在、50000社以上が利用
5. CONFIDENTIAL 入社手続き 年末調整 申請・承認 お知らせ掲示板 文書配付 給与明細 従業員サーベイ 組織図 社員名簿 分析レポート 赤い部分が、SmartHRの「基本機能」
6. CONFIDENTIAL 約30名 約5〜6人 x 6チーム ※クロスファンクショナル（機能横断）な チーム内のエンジニアのみ ・ ・ ・ エンジニア数 SmartHR基本機能
7. CONFIDENTIAL エンジニアは「アプリケーションエンジ ニア」のみ。 SREやインフラ専門職など職能のチー ムは無し。 チームの構成 ・ ・ ・
8. CONFIDENTIAL スクラムを拡張した「LeSS」を採 用。 (Less=1 つの製品に対し、複数 のスクラムチームで連携しながら 開発をするフレームワーク) ・ ・ ・ 開発のフレームワーク
9. CONFIDENTIAL 「SmartHR 基本機能」の環境の変化
10. CONFIDENTIAL サービス開始 現在 登録企業の数
11. CONFIDENTIAL 利用企業の規模
12. 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
13. CONFIDENTIAL 「モノリス」なので設計変更の影響が大きい ・アプリケーションが大きくてつらい・・・ってこと？ https://speakerdeck.com/sugamasao/smarthr rails statsの様子
14. CONFIDENTIAL • データ急増 • データの複雑化 • 使われ方も様々に
15. CONFIDENTIAL 起こった問題
16. CONFIDENTIAL • データの急増（特に1社あたりのデータ量） 1.サーバー負荷の急上昇
17. CONFIDENTIAL 初期のラフな実装が爆発 例) • 従業員データ（数万）をデータベースから全取得し、アプリケー ション側でソート • 1リクエストで従業員項目の表示数分の数千回のN+1 など... （現在はパフォーマンス面のレビュー、事前テストあり） 1.サーバー負荷の急上昇
18. CONFIDENTIAL • 設計変更（履歴処理やテーブル分割） • 使い方の変化（利用する会社/利用ケースの増加) 2.エラーの増加
19. CONFIDENTIAL 例) • 設計変更（履歴処理やテーブル分割） ◦ 従業員を項目Aでソートするとエラー • 使い方の変化（利用する会社/利用ケースの増加) ◦ 手続きA,Bの並行処理でBがエラー（用途が変わった） ◦ 非同期処理で使うデータ変更されているとリトライとエラーを繰 り返す • その他 ◦ 想定されるバリデーションエラー時に全てエラー管理システム に通知される（なぜか多い） など... （現在はQAチームの誕生や回帰テストの拡充が進んでいます） 2.エラーの増加
20. CONFIDENTIAL 銀の弾丸は無さそう... という事で、それぞれの問題を頑張って直していきます。 小〜大まで様々な問題
21. CONFIDENTIAL • かなりリソースが必要 • 緊急/重要度が高い ◦ 例）パフォーマンス改善で共通部 分の設計変更 問題(大) 大
22. CONFIDENTIAL • かなりリソースが必要 • 緊急/重要度が高い ◦ 例）パフォーマンス改善で共通部 分の設計変更 = 機能開発を止めて直す、 　タスクフォースチームを作る（過去に3回） 大 問題(大)
23. CONFIDENTIAL 問題(小) • 問題の割に修正が大変なケースも （古の機能） • レアケースや実害が無かったり、緊急度は 比較的低い ◦ 例）手続きを依頼した従業員データを すぐに削除すると内部的にエラー通知 が飛ぶ（ユーザー影響は無し） 小
24. CONFIDENTIAL 問題(小) 小 = 機能開発を止める...? • 問題の割に修正が大変なケースも （古の機能） • レアケースや実害が無かったり、緊急度は 比較的低い ◦ 例）手続きを依頼した従業員データを すぐに削除すると内部的にエラー通知 が飛ぶ（ユーザー影響は無し）
25. CONFIDENTIAL 小 大 小 小 小 小 小 小 小 小 扱いが難しい、問題（小） （一つずつは）優先度が低く溜まりがち...
26. CONFIDENTIAL 1つずつはレアケースでも溜まってしまうと 頻繁に問題（小）が発生することになり.. 問題(小)が溜まると...
27. CONFIDENTIAL ・サーバー負荷 　頻繁に処理が重くなるケースが増えてくる 問題(小)が溜まると...
28. CONFIDENTIAL ・エラー 　エラーが増え、ユーザー体験が悪くなる。 　ユーザー体験に関わらないケースでもエラー通知がノイ ズになり重要な通知を見逃す 問題(小)が溜まると...
29. CONFIDENTIAL 有志で定期的にAPM/エ ラー通知を確認し、 その場で修正したり個人で 持ち帰って修正する取り組 み 有志の改善活動を始めた
30. CONFIDENTIAL 様々な事情で活動が滞りが ちになり... 直面した現実
31. CONFIDENTIAL • 機能開発（スクラム開発）が忙しいと手が回しづらい • 他のサイドタスクとの時間の取り合いになる • 気力 改善活動が滞る様々な事情
32. CONFIDENTIAL • 機能開発（スクラム開発）が忙しいと手が回しづらい • 他のサイドタスクとの時間の取り合いになる • 気力 →「スキマ時間」「有志」だけの活動の厳しさ 改善活動が滞る様々な事情
33. CONFIDENTIAL とはいえ問題（負債）が溜まらないよう、無理なく改善し ていける体制にする時期が来た... → PO(プロダクトオーナー）、アジャイルコーチ、エンジ ニア(QAエンジニアも)含めて揉みへ 「スキマ時間」「有志」だけは厳しい問題
34. CONFIDENTIAL • スクラムでの欠陥の扱いは? ◦ 特に無さそう ◦ まずは最初の作り込みが必要（それはそう） • 機能開発との優先度比較は？(バックログの管理） ◦ 難しい ◦ 例. エラーノイズを継続的に減らしたいというタスクと、機能Aのオ プション追加といったタスクは目的も違うし比較も大変 開発チーム全体で議論
35. CONFIDENTIAL • 一気に直せば終わる？ ◦ 環境の変化で継続的に発生するとしたら継続的な活動になる • 負債解消をする別チームは? ◦ 機能開発チームでも学習しながら取り組みたい • 見積もりづらいものも多くてやってみたら手間がかかって、機能開発の リソースに影響は出なそう？ ◦ 改善活動に使う割合は固定にした方が良いかも ▪ スクラムに合わせ、固定割合は消化予定ポイントの「nポイン ト」を引く形が良さそう など 開発チーム全体で議論
36. CONFIDENTIAL • 機能開発を一部減らし、改善活動(負債解消)をする ◦ フリーな??%活動でなく、確実にやりたい事枠（今回だとサーバー 負荷とエラーの改善） • 改善活動の内容はバックログと別で管理、オーナーを立てる 出てきた方針
37. CONFIDENTIAL • 複数チーム中のnチーム、予定するスプリントの合計ポ イント中のnポイント分を改善活動に回す ◦ 週替わりで交代 • 改善活動のタスクは見積もりは行わず、nポイント相当 を各チームで判断して行う → 完了しなかったら次のチームへ引き継ぎ • 「n」の値は運用しつつ調整していく スクラム（LeSS）での運用を考える
38. CONFIDENTIAL タスクの管理 POが管理 エンジニアが管理 チケット （タスク） チケット （タスク） チケット （タスク） チケット （タスク） 機能開発 改善活動 日次や週次で ・Sentry ・NewRelic ・Google Cloud Console などを見て候補出し
39. CONFIDENTIAL 例) 11/2〜11/9は「A」チームが担当 チームでの運用例
40. CONFIDENTIAL 例) 翌週 11/10〜11/17は「B」チームが担当 チームでの運用例
41. CONFIDENTIAL 1年以上この形で改善活動を行ってみた メリット/デメリット
42. CONFIDENTIAL メリット/デメリット メリット • 無理なく継続できる • 機能開発への影響は（まあまあ）小さい • チーム全体で学習できる （まずい実装がわかったり、パフォーマンスへの理解が深 まったり）
43. CONFIDENTIAL メリット/デメリット デメリット • 大きめなタスクは厳しい ◦ 引き継ぎコスト（複数チームなので） • エラー、パフォーマンスのどちらかに比重がよりがち（パ フォーマンス問題が頻度高く起きる時期はエラーが疎かにな る）
44. CONFIDENTIAL メリット/デメリット デメリット • 負債の改善以上は難しい ◦ 日々の監視体制の強化や、 未来のための設計変更など更に大きな活動は別で必 要
45. CONFIDENTIAL 問題は減った？ ・エラー 　JavaScript x 特定のブラウザ問題や外部APIなど、 　アプリケーション側で制御しづらい部分以外のエラーはかな り減った。 　（QA体制が整った現状は新規のエラーは少ない）
46. CONFIDENTIAL 問題は減った？ ・サーバー負荷 　減ったとは言い切れない... 　過去やその時々の問題は改善されつつ、 　更に増えるデータやインフラ移行など環境変化による新しい 問題が発生。
47. CONFIDENTIAL まとめ ・「SmartHR基本機能」の成長でシステムの問題も急増 ・小さな問題が溜まりがちだった ・開発チーム全体で無理なく解消できる運用を目指した 　環境に合わせてまだ運用は変更中
48. CONFIDENTIAL サービスが成長する中で起こる問題を一緒に解決したい方 のご応募お待ちしています！ https://smarthr.co.jp/recruit/
49. CONFIDENTIAL ありがとうございました