こんにちは、SmartHR 勤怠開発部の tamurar です。
新規機能の開発と並行しながら、技術的な負債や開発プロセスの改善を進めていくことは、多くの開発チームが直面する課題であり、私達の勤怠開発部も例外なく向き合っています。
私達はまだチーム発足から 2 年足らずの歴史の浅いチームですが、この期間で 0→1 フェーズから 1→10 フェーズへの変化を遂げ、チームの人数や形も変わりました。目まぐるしい環境の変化の中で新規機能開発と改善活動の両立は特に難しいテーマであり、今も取り組み続けています。
この記事では、勤怠開発部が新規機能開発と改善活動を両立するために行ってきた施策の変遷を振り返ります。
先に正直にお伝えすると、まだ完璧な解決策は見つかっていません。何か施策をやってみても状況が変わって新たな課題が出ることの繰り返しです。
この記事が、同じような課題に向き合っている方々の参考になれば幸いです。
勤怠開発部とは
SmartHR 勤怠開発部は、2024 年 1 月に発足した比較的新しいチームです。SmartHR の勤怠管理機能を開発しており、レッドオーシャンと言われている勤怠管理市場に挑戦しています。
発足当初は 1 チーム 4 名でしたが、現在では 3 チームの総勢 12 名まで大きくなりました。開発フェーズは、2024 年 10 月に初回リリースを迎えるまでは、 0→1 の完全新規開発でしたが、それ以降は既存機能との依存関係や影響範囲を考慮しながら機能を追加していく 1→10 フェーズへと徐々に移行しています。
また、私達はレッドオーシャンに挑戦しているため、提供しなければならない新機能は多いです。期ごとに目標を設定し、スピード感を持って新規機能開発を進めています。直近では 2025 年の上期だけで 31 件の新規機能をリリースした実績があります。
一方で、このような状況で開発を進めていると、状況にそぐわない改善すべき点が次々と出てきます。コードレベルの課題から、開発プロセスの課題まで、改善点は多岐にわたります。
改善も必要ですが、ハイスピードな機能開発も必要です。この両立をどうするかが、私達の継続的な取り組みです。
改善に対する共通認識
改善活動を行うための前提として、改善はやるべきだという共通認識がチームに必要ですが、私たちはビジネスとプロダクトの双方が改善をやるべきだと考えています。改善活動の重要性について認識を揃えるのに苦労する話も聞きますが、私たちにはその課題はありませんでした。
そのため、私達が取り組むべき課題は「時間の確保」と「取り組み方」です。以降は私達が試行錯誤してきた変遷を紹介します。
自己管理期（2024 年 1 月〜2024 年 10 月）
この時期は、改善活動のための明確な仕組みを作らず、個人の裁量で改善を進めていました。
やったこと
チーム発足当初は、改善活動のための明確な仕組みがありませんでした。改善チケットを切る場所もなく、リファクタリングや UX 改善は各メンバーの裁量で、隙間時間を見つけて行うという状態でした。
0→1 フェーズの新規開発に集中する段階だったので、何よりもスピード重視で動くものを開発していきました。直さないと後続作業ができないような明らかな問題は対応していましたが、それ以外の改善に対してはあまり時間をかけずに進めていました。
課題
この時期は動くものを最速で作る方針でチームで合意していたため、大きな課題は少なかったのですが、改善時間が必要だという意見が徐々に増えていきました。2024 年 10 月頃がリリース日だったため、特にそのあたりから課題感が大きくなり始めました。
負債解消アワー期（2024 年 10 月〜2025 年 1 月）
この時期に初めて改善活動のための仕組みを作りました。固定時間を確保して、改善活動に取り組み始めました。
やったこと
レトロスペクティブで「負債解消をする時間が無いので、どこかで時間を確保したい」という意見が出たため、私達は改善活動の時間を確保する施策を初めて検討し始めました。その名も負債解消アワーです。
仕組みはシンプルに、スプリントごとに固定の時間を確保する方法を採用しました。固定の時間は 1 人あたり 4 時間としました。1 スプリント 2 週間で回しているので、2 週間の中で 4 時間を使う設計です。
もともとは固定の時間を確保するのではなく、機能開発と改善チケットの優先順位をつけてスプリントタスクとして対応するのが理想としていました。しかし、改善チケットの重要度を PO（Product Owner、プロダクトオーナー）とコミュニケーションしながら優先度をつけるのはコストがかかりそうだと判断し、固定時間を確保する方法を採用しました。
改善チケットの出どころは個人の気付きベースで、改善チケットの領域分け(フロントエンド、バックエンド、インフラなど)をしたうえで、領域ごとに優先順位をつけて着手するようにしました。
成果
初めてチームとして負債解消の時間を確保することができました。スプリント最終日の午後を負債解消アワーにあてることで、後回しにしていたけどできていなかった改善を進められるようになりました。
この期間に取り組んだ改善の具体例としては、以下のようなものがあります。
- 手順書を作成しながら PostgreSQL のバージョンを 16 から 17 にアップデート
- Next.js を 14 から 15 にアップデート
- フロントエンドのクエリパラメータの扱いを統一化
- 調査用踏み台サーバーの運用改善や staging 環境の費用削減などインフラ周りの改善
個人の裁量では着手しづらかった技術的負債やインフラ改善に、チームとして計画的に取り組めるようになりました。
課題
運用を始めて 2 ヶ月後の 2025 年 1 月頃にチーム状況が変わってきました。
2025 年の上半期に開発したい重要機能がかなり多いことがわかってきて、負債解消アワーの確保が難しくなりました。これらの機能は勤怠プロダクトにとって不可欠なものだったため、負債解消アワーの取り組みをストップするかどうかの議論になりました。議論の結果、これらの機能開発が完了するまで負債解消アワーを中止することにしました。
チームとして、中長期的に見て改善活動は重要だという認識はありましたが、それを踏まえたとしても機能開発を優先すべきだという意思決定をしました。この間に改善活動を禁止するわけではなく、各々の隙間時間で実施したり、本当に重要な改善は PO と調整してスプリントタスクに乗せる運用を進めました。
改善タイム期（2025 年 4 月〜2025 年 8 月）
この時期は、より柔軟な時間の使い方と、エンジニア以外の職種も含めた改善活動に取り組みました。
やったこと
重要機能開発が一定落ち着いてきた頃、再び改善活動を実施する機運が高まってきました。
この頃にはチームが 2 つに分かれており、それぞれのチームごとに機能開発の状況も異なってきていたため、負債解消アワー以外の改善活動のあり方を検討しました。
最終的に採用したのは、時間だけ確保してその時間を個人で好きなタイミングで使う方法です。この時間は 8 時間としました。前回の負債解消アワーと異なるポイントは柔軟度と対象者です。
この 8 時間は各チーム内で融通が効くようになっており、今のスプリントは 4 時間にして次のスプリントで 12 時間にするような調整ができるようにしました。
対象者は PdE（Product Development Engineer、プロダクト開発エンジニア）だけでなく、プロダクトデザイナー、QAE（Quality Assurance Engineer、品質保証エンジニア）、UXW（UX Writer、UX ライター）、PM（Product Manager、プロダクトマネージャー）などチームの全ての職種が対象になりました。これによって開発プロセス、ドキュメント、AI 活用など多岐にわたった改善を進められるようにしました。
成果
この期間にもさまざまな改善が進められました。
フロントエンド周りのバグ対策として、バックエンドをモックしたフロントエンド統合テストを導入しました。また、属人化していた労働時間計算の実装について、誰でも着手できるようにマニュアルを作成しました。その他にも、計算処理のロック時間の改善や Terraform の設定改善、中長期的な目線で見た課題の整理なども進めました。
負債解消アワーよりも柔軟な時間の使い方ができるようになったため、各々のタイミングでこまめに改善を進めることができるようになりました。
課題
各々が改善を進めていく中で、新たな課題が見えてきました。それは、プロダクト全体の課題解決につながっているかという点でした。個々の改善は進んでいますが、勤怠プロダクトが抱える本質的な課題に対してアプローチできているかの疑問がありました。
この時期には勤怠プロダクトの中長期課題を整理する施策が動いていました。そのため、改善活動はそこで出た課題に対してアプローチすべきではないかと考えるようになりました。ここで初めて時間ではなく改善活動の内容に対して課題を抱くようになりました。
中長期課題グループ期（2025 年 8 月〜）
この時期は、プロダクトの中長期課題に対してグループを作り、計画的に改善活動に取り組んでいます。
やったこと
2025 年 8 月、私達は中長期課題に対してアプローチするための課題対策グループを作るワークショップを開催しました。
このワークショップには PdE と QAE、総勢 13 名がオフラインで集まり、5 時間かけて実施しました。
ワークショップでは、まず勤怠プロダクトに対する課題を全員で出し合い、優先順位付けとグルーピングをしました。優先順位は、別途進めていたプロダクトの中長期課題整理施策で出た課題や緊急度をベースにしました。
グルーピングの結果、以下の３つのグループが生まれ、それぞれ担当者を決めて半期の間に対応を進める体制を作りました。
- 品質向上グループ
- リファクタリングやテスト拡充を通して、バグを減らす
- 生産性向上グループ
- AI 活用などを通して、開発生産性を向上させる
- 運用改善グループ
- インシデント対応や問い合わせ対応時のフロー整備など運用に必要な改善を進める
このワークショップのあと、各グループがそれぞれ目標を立て、各メンバーにタスクを分配しました。私達は半期毎に目標設定を行うのですが、ここで担当するタスクを個人目標に含めるようにもしました。
タスクを割り振るだけでは期末ギリギリまでタスクが進まないリスクもあります。改善活動を確実に進めていくためにも、各グループごとに進捗確認や相談の定例を開き、定期的に状況を共有できる場も作りました。
成果
主な成果は以下のとおりです。
- 勤怠プロダクトの重要な課題に対してアプローチできるようになった
- 個別最適ではなく、プロダクト全体の課題に向き合えるようになった
- チームとして合意した課題、かつ、個人の評価にもつながる業務なので改善時間を確保する際の納得感が高まった
- もともと改善タイムを取る際に少し躊躇しているメンバーもいたが、プロダクトの課題からブレイクダウンしたタスクに取り組むので納得感を持って取り組めるようになった
各グループで実際に進めている改善の例も紹介しようと思います。
品質向上グループでは、最も重要かつ複雑な労働時間計算処理のリファクタリングを完了しました。また、入力データが意図せず上書きされたり消えたりするのを防ぐための自動テスト設計にも取り組んでおり、複数の打刻やイベントの積み重ねを考慮できるテストの実装を進めています。
生産性向上グループでは、AI 活用を軸とした改善に取り組んでいます。実装に影響するドキュメントを AI が読み書きしやすいフォーマットで一元化する作業や、AI 最適化を目的としたコードのリファクタリングを進めています。また、AI 活用の知見を共有する仕組みも構築しました。
運用改善グループでは、インシデント対応フローの見直しに取り組みました。インシデント判断基準の属人化や問い合わせ担当の責務の不明確さといった課題があったため、全社のインシデントフローに準拠しつつ勤怠開発部独自の観点を組み込んで調整し、Prod と Biz の両方に共有しました。また、契約社数の増加に備えた負荷試験の計画も立てており、プロダクトの成長に耐えうる運用体制の構築を進めています。
課題
運用開始から 2 ヶ月たった今、新たな課題が出てきています。もはや毎度のことなのですが…
「時間が足りない」
半期の計画をたてる際に開発アイテムの工数の仮見積もりをしているのですが、その仮見積もりが想定より膨れてしまい、機能開発に多くの時間を取られてしまいました。機能開発が遅延することで、改善活動の優先度がどうしても下がってしまい、改善活動に割ける時間が減る事案が多く発生しました。
仮見積もりは今まで何度もやってきている作業なのですが、直近の数カ月で状況が変わっていました。ハイスピードで機能が増え続けたことで仕様の依存関係の複雑さがかなり増し、今まで通りに新規機能作成だけを考えた見積もりだと大きなズレが生じることがわかってきました。この時すでに 2 チームだったのが 3 チームになり、並行して動く機能開発も多くなっていたため、どこのチームもこの課題にぶつかりました。
今のとりくみ
直近では仮見積もりの精度向上のために要件定義を前倒しつつ、既存機能に詳しいメンバーが見積もりに参加して、以前より見積もりの精度向上に努めています。
結局機能開発を優先してしまって改善活動になかなか時間を割きづらいという声も出ているため、固定時間の確保をやめるという線も検討し始めています。執筆時点では、スプリント内で一定のポイントを改善チケットに割り当てられる運用にしたり、改善専門のチームを一時的に作るなど、各々の裁量に任せている時間配分を仕組みでカバーできないか検討しています。
完璧より試行錯誤
変遷を見ていただいたらわかるように、完璧な運用はありません。チームを取り巻く環境は都度変化します。0→1 から始めるようなプロダクトならなおさらです。
個人の裁量、負債解消アワー、改善タイム、課題グループ、どの仕組みも一定の変化と成果は生みましたが、新たな課題も生みました。今振り返れば過去のタイミングでもっと良いやり方があったかもしれませんが、どれもチームで合意して取り組んだ結果なので、これに関しては結果論かなと考えています。
それよりも大事なのは、課題 → 改善のサイクルを止めないこと、試行錯誤し続けることであると感じています。課題があるとわかっているのに何もアクションをしない状況が最悪です。何事にも言えることですが、試行錯誤し続けることに価値があります。
一方で、この試行錯誤のサイクルを回すこと自体が難しい環境も多くあるように思えます。なぜこのチームはサイクルを回すことができるのか、自分なりに考えてみました。おそらく私達のチームには以下の能力があり、これがサイクルを回す際に重要なのだと思います。
- チーム全体に対するコミット意識
- おそらくこれが最も重要。無いとそもそも課題なんて思いつかないし、改善をやろうという気持ちにもならない
- 常に課題を口に出せる雰囲気
- 自分が思う課題を素直に口にして受け止められる環境でなければ、課題は集まらない
- ボールを持って進める意識
- 実行する人がいなければ何も進まない。解決のために動く人がいて初めて変化が生まれる
- 変化を受け入れる姿勢
- 変化を嫌えば改善サイクルは止まる。自分の業務に影響がある変化だとしても受け入れる土壌が必要
最適解を追い続けることは難しいですが、変化を恐れずに改善し続ける、これが私達勤怠チームのスタイルなのではないかと考えています。
改善時間の確保は必須
様々な施策を通して改善時間を確保する仕組みを作ってきましたが、やはり改善時間を取ることはプロダクト開発において重要だと身を持って感じています。
これは自主的に行うものではなく、チームとして時間を確保して取り組むべきものです。
時間の経過とともに機能の数は増えていきますし、チームが置かれる状況も変化します。どんなプロダクトでも必ず状況にそぐわない箇所が出てくるはずです。これを放置したまま現状維持をしていると、生産性は低下の一途をたどりますし、プロダクトの品質も向上しません。
改善の対象はコードに限らず、開発プロセス全体にも当てはまります。この 2 年間で、いつの間にか AI を使って業務をすることが当たり前になりました。AI を前提にした開発プロセスに変更することで大きなメリットを享受できるかもしれないのに、改善時間が無いからできない状況は、プロダクトにとって不利益です。
今後、チームの状況がどう変化するかわかりませんが、必ず改善時間を確保してチーム全体で改善活動に取り組んでいくつもりです。
おわりに
勤怠開発部は、SmartHR の中で少し特殊なチームかもしれません。
刻一刻と状況が変わり、まだまだ開発しないといけない機能も山積みです。レッドオーシャンと言われる勤怠管理市場に挑戦している以上、競合との差別化も継続的に求められます。
だからこそ、私たちはチームをまたいで全体にコミットする機会がたくさんあります。チーム全体で課題を共有し、解決策を考え、実行する。その繰り返しの中で、プロダクトもチームも成長していきます。
変化が大きいこの環境の中で、一緒に最高の勤怠プロダクトと最高のチームを作りたいと考えている方、ぜひ私たちと一緒に働きませんか？
一緒に試行錯誤し続けられる仲間を探しています！
We Are Hiring!
SmartHR では、一緒に SmartHR を作りあげていく仲間を募集中です！
勤怠開発部に少しでも興味を持っていただけましたら、お気軽にご応募ください！
ウェブアプリケーションエンジニア（勤怠管理領域 バックエンド） / 株式会社 SmartHR
まずはカジュアル面談でざっくばらんにお話ししましょう！
元の記事を確認する
