改善投資0%からの再出発──SmartHRがプロジェクト投資分析で掴んだ、うまく伝えきれない課題を動かすファクト管理
改善投資0%からの再出発──SmartHRがプロジェクト投資分析で掴んだ、うまく伝えきれない課題を動かすファクト管理
目次
目次を読み込み中...
プロダクトの急成長を続ける株式会社SmartHR。その中で「届出書類機能」の開発を担うユニット（届出書類チーム）は、デザイナーやQAEなど多様な職種とスポットで連携しながら開発を進めています。
同チームでは、新機能開発と並行して「いかに機能改善や技術的負債解消への投資を担保するか」が大きな課題となっていました。定性的には「改善に手が回っていない」という肌感覚をチーム全員が持っていたものの、それが実際にどれほどの数字なのかが分からず、定量的なファクトがないことで課題感をうまく伝えきれない状況が続いていたといいます。
こうした中、同社はFindy Team+の「プロジェクト投資分析」機能を導入し、Jira運用の徹底した最適化を断行。感覚値を定量的なファクトへと変換することで、エンジニア・PM・ビジネスサイドが同じ目線で投資判断を行える体制を構築しました。
本記事では、人給基幹プロダクト開発本部 Directorの秋山さんと、同ユニットでChiefを務める小林さんに、可視化の障壁を乗り越えたJira運用の工夫と、データをもとにした「納得感のある改善サイクル」の回し方について詳しく伺いました。
プロフィール
秋山 譲さん
人給基幹プロダクト開発本部 Director
SmartHR人給基幹プロダクト開発本部Director。エンジニアリングマネージャーのマネジメントを担当し、労務・勤怠管理・給与計算の各プロダクトチームを管掌。新卒でSIerに入社後、様々な業界のWebプロダクトの開発を経験。2024年12月入社後、約1年間エンジニアリングマネージャーとして従事した後、2026年1月から現職に就任。
小林 優太さん
人給基幹プロダクト開発本部 届出書類ユニット Chief
SmartHR人給基幹プロダクト開発本部 届出書類ユニット Chief。届出書類ユニットの開発およびメンバーのマネジメントを担当。2015年にSIerに入社後、Webアプリケーションの開発およびマネジメントを経験。飲食業界向けのマーケットプレイスを提供するスタートアップを経て、2021年にSmartHRに入社し、届出書類機能の開発に携わる。2024年1月から現職に就任。
「改善に手が回らない」肌感を定量化。PMとエンジニアの間にあった“投資実態”の認識の乖離
小林：当時、私のチームでは新機能の開発をかなりハイペースで進めていました。プロダクトマネージャーからも「もっと機能改善の比率も増やしていきたいね」という話が出ていたのですが、実際の問題として、自分たちのリソースが具体的にどれくらい新機能開発に割り振られているのかが全く見えていなかったんです。チームに対しても、具体的な根拠がないので課題感をうまく伝えきれないもどかしさがありました。
定性的には「改善に手が回っていないよね」という肌感覚をチーム全員が持っていたものの、それが実際にはどれほどの数字なのかが分からず、定量的に見えていないことが一番のネックでした。
このまま肌感覚だけで話すのではなく、データとしてすり合わせをしないと本質的に良くしていくことはできないと感じていたタイミングで、秋山さんから「Findy Team+に新しく投資分析の機能が出るから使ってみないか」と提案をもらい、導入に踏み切りました。
秋山：労務ドメイン全体という広い視点でお話しすると、去年の6月から7月にかけてスクラムの拡張版であるScrum@Scaleという取り組みを導入し、ドメイン全体で管理できるようにするサイクルが回り始めました。
その中で、新機能開発にリソースが偏っているという課題は届出書類チームだけでなく他のチームでも起きていたんです。プロダクトマネージャーとしては技術的負債の解消に投資している感覚がある一方で、実際にはそのファクトがなく、エンジニア側はそこに全然時間が使えていないという実感がある。
こうした認識のズレを解消するためのファクトを得るために、まずは届出書類チームをパイロットとしてお願いしたという経緯です。
一気通貫で捉える。多角的な分析で見えてくるチームの真実
小林：プロジェクト投資分析機能を使ってみようと思った一番のきっかけは、やはり自分たちがやりたかった「情報の可視化」が、定量的なデータに基づいて示せる点にありました。私たちのチームにはすでにFindy Team+を活用して振り返りを行うプロセスが定着していたので、その既存のフローに無理なく組み込みやすい点も魅力に感じました。
また、単一の指標を見るのではなく「プロジェクト投資分析→スプリントパフォーマンス分析→サイクルタイム分析」という一連の流れを捉えています。
最初からこれら全てを同時に見ていたわけではありませんが、まずはサイクルタイムの分析から始まり、社内で隔週開催されている「Findy Team+の知見をためる会」を通じて他チームの活用事例を知り、スプリントパフォーマンス分析も取り入れるようになりました。
今回のプロジェクト投資分析の設定が完了し具体的な数値が見え始めてきたタイミングで、これまでの分析画面と組み合わせることでチームの状態をより深く把握できると思い、一緒に見ています。
投資カテゴリ（新機能／改善／品質保証／開発生産性）という整理軸については、もともと私たちのJira運用がそこまでかっちり決まっておらず、ふんわりと使っていた背景もあり、今回の導入に合わせて改めて作業タイプの整理を行いました。実際にFindy Team+が提供している4つの軸を使ってみると、私たちの開発実態でこれに当てはまらないケースというのはほぼなくて、非常に良い軸だなと使っていて感じています。
また弊社では、単に機能として使えるだけでなく、お客様に「魅力的だ」と感じてもらえる品質を追求しており、「魅力的品質」という言葉が経営層も含めた全社の共通言語になっています。その実現をするために、実際にどれだけ時間を投資できているのか、どこに力を寄せられているのかを定量的に注視しています。
自由度の高いJira運用をいかにデータへ変換するか。可視化の土台となる「定義の明文化」
小林：SmartHRではほぼ全社でJiraを利用していますが、必ずしも絶対に使わなければならないというルールではなく、一部でGitHub Projectsを利用しているチームもあります。
私たちのチームでは、エピックやイシューの作成はチーム内の誰が行ってもよいという運用にしています。具体的には、大きな新機能開発（フィーチャー）であればそのプロジェクトをリードする担当エンジニアが作成を一手に担うことが多いですが、不具合やバグについては見つけた人がその場で起票するような流れです。
作成したチケットについては、スクラムのプロセスに則ってプロダクトバックログリファインメントやスプリントプランニングを行い、スプリントに入れていきます。担当者をアサインすることもあれば、手が空いているメンバーが着手することもあり、最終的に本番環境にリリースされた時点でクローズするというのが一連の流れです。エピックについても、紐づく全てのイシューが完了した段階でクローズされるようになっています。
以前の運用で特に課題に感じていたのは、イシューの分類やカテゴリ分けが不十分だったことです。バグについてはしっかりと分類していましたが、それ以外のものは新機能であっても機能改善であっても、あるいは開発生産性向上に関するタスクであっても、特に区別せずに「タスク」という一つの課題タイプで扱っていました。
また、Jiraを利用する中で以前からチーム内でよく議論になっていたのが、イシューを作成する際の「タスク」と「ストーリー」という課題タイプの使い分けです。これらを使い分ける意味がどこにあるのかが明確に定義されておらず、運用がふんわりとしていた部分があり、今回のプロジェクト投資分析機能を導入するにあたって、改めてこれらの役割分担を整理し、明文化しました。
過去のチケットを全て整理し直すコストも考慮し、最終的には「どちらのタイプを使ってもOK」という結論にはなりましたが、曖昧だった定義を言語化したことで、迷わずに運用できる状態に整えました。
「運用負荷ゼロ」が継続の鍵。オートメーション活用で実現したラベル付与の自動化
小林：JiraとFindy Team+の連携においては、運用コストを最低限にしたいと思っていました。新しいツールを入れるからといって、現場のエンジニアにこれまでやっていなかった作業を強いるのは避けたかったので、既存の運用を活かしながら自動化する工夫を凝らしました。
最初に取り組んだのは、Jira内でのチケットの粒度を揃えることです。
以前は、カスタマーサポートなどのデスクからのお問い合わせが入ると自動でJiraチケットが起票される仕組みになっていたのですが、それが一つの親チケットに対する「サブタスク」として作られるワークフローになっていました。
これでは他の開発イシューと粒度が揃わず、Findy Team+で可視化した際にも実態に即した数値が出ないという課題があったんです。
そこで、デスクチケットも他のイシューと同様に「親チケット」として作成されるように運用を変更しました。この変更によって分析の精度が上がったのはもちろん、Jira内でもクローズされていないチケットの検索が容易になるなど、検索性が向上するという副次的なメリットも得られました。
また、チームとして歴史がある分、形骸化してうまく回っていなかったプロセスもこの機会に見直しました。例えば、以前は1ヶ月の間に改善だけをまとめて行う「改善スプリント」という箱を作っていたのですが、実態としてあまり機能していませんでした。これを思い切って廃止し、代わりに「改善」という作業タイプを新たに定義して、通常の開発スプリントの中にそのチケットを直接入れる運用に整理し直したんです。
こうした新しい運用を定着させるために、Jiraのオートメーションを活用しました。
具体的には、作業タイプが「改善」であれば、チケット作成時に自動でマッピング用ラベルが付与されるように設定しています。
途中で、オートメーションによって作成されたサブタスクには手動で作成をしないと処理が走らないという制約に直面しましたが、既存のオートメーションの中で直接ラベルに値が入るように処理を組み込むことで解決しました。
現在、チームメンバーが手作業でラベルを付けることは一切ありません。作業タイプを設定するだけで運用が回る仕組みを構築できたので、現場からの反発もなく、非常にスムーズに継続できています。
改善投資0%からの再出発。PMと合意した「1スプリント・1改善」への具体的な一歩
小林：プロジェクト投資分析機能を使ってみて最も効果を感じたのは、自分たちがどのような時間の使い方をしているのかを、感覚値ではなくデータを見て話せるようになった点です。
これにより、議論における納得感が格段に上がりました。
初めて数値を出してチームで話し合った際は、機能改善に割けている時間が「ほぼ0%に近い」という事実が判明しました。以前から改善ができていないという肌感はありましたが、今のチームにとっての理想の比率はどのくらいかという話をプロダクトマネージャーも交えて議論し、「まずは10〜15%程度を目指そう」という目標を立てることができました。
いきなり理想に近づくのは難しいため、アクションとしては「1つのスプリントにつき必ず1つの機能改善を入れよう」というスモールステップからトライを開始しています。
また、「プロジェクト投資分析」「スプリントパフォーマンス分析」「サイクルタイム分析」のそれぞれの数値をきっかけに、チームで何が良かったのかを話し合う習慣に繋げられています。
プロジェクト投資分析については、マンスリーで「先月はこの割合で時間を使っていた」という振り返りを行っています。品質保証に割く時間が長くなっている場合には、何が原因だったのか、逆に短く済んだ時は何が良かったのかを深掘りし、チームの学びに繋げています。
スプリントパフォーマンス分析では、私たちのチームの直近の課題であった「タスクの持ち越し」にフォーカスしています。
なぜ持ち越しが発生するのか、どうすれば解決できるのかを議論した結果、具体的なアクションとして「期限確認のタイミング」を変更しました。以前は火曜日に終了するスプリントに対し、月曜日の午後に期限を確認していましたが、それでは「あと一日早ければ間に合ったのに」という事態が防げません。
そこで、金曜日のうちに確認を行う運用に変えたことで、少しずつ状況が改善され始めています。
スプリント管理において、難しさを感じているのが「差し込みタスク」への対応です。
差し込みが発生した場合には「既存のスプリントに入っている同等分のポイントをその時点で取り下げる」という運用をチームで話し合っています。
あえてバッファは設けず、入ってきた分だけ既存のものを抜くという考え方ですが、実際には必ずしもそれが徹底できているわけではなく、難易度の高い課題として今も向き合い続けています。
サイクルタイム分析に関しては、チームの合計値は「Elite」を維持できていますが、「オープンからレビューまで」の時間が長くなりがちだという課題を常に意識するために活用しています。
毎月の数値の上下を見ながら、「今月はこれができたから良かった」「ここが課題だった」と振り返ることで、素早くレビューに取り組むという意識醸成に繋がっています。
サイクルタイムを分析・改善したことでチームの状態が良くなったという成功体験がすでにあったからこそ、新しく導入したスプリントパフォーマンス分析やプロジェクト投資分析もしっかりと見ていこうという活力に繋がっています。
歴史あるチームへの展開を見据えて。感覚値の議論を脱却し、組織全体の投資戦略をアップデートする
秋山：今後の展望としては、今回の届出書類チームでの取り組みを、労務ドメイン全体へと広げていきたいと考えています。
プロダクト開発の現場では、どうしても感覚で話をしてしまったり、その時の立場にとって都合の良い解釈をしてしまったりすることが起こり得ます。ロードマップの策定やOKRを決める際にも、定量的な数値をベースにコミュニケーションを取ることで、エンジニア、PM、そしてビジネスサイドの方々とも、よりスムーズにコンセンサスを形成しやすくなるはずだと考えています。
ただ、実際にドメイン全体へ展開していく上での難しさも感じています。労務ドメインには10年ほど開発を続けている歴史の長いチームもあり、そうしたチームに対してJiraの設定を一からチューニングしていくのは、正直なところかなりハードルが高いのが実情です。
今の届出書類チームのような新しいチームでの成功例をそのまま持ち込むのはしんどい部分もあるので、より導入しやすい方法を模索しながら、全体での投資分析を進めていきたいですね。
また、各チームのマネージャーレイヤー（EMやPM）が「このくらいの投資比率で進めよう」と戦略を握り始めています。感覚で話すとどうしても自分たちに都合の良い解釈になりがちですが、定量値をベースにすることで、その戦略が成り立っているかどうかの振り返りに利用できるといいなと思っています。
小林：チームレベルでも、引き続き振り返りの質を上げるために活用していきたいです。
例えば、現状では品質保証にかける時間が少し大きすぎるという課題が見えているので、それを具体的にどう減らしていくか、あるいは開発生産性をさらに向上させるためにチームとしてどう取り組むべきか。そうした議論を行う際に、メンバーの納得感を高めるための材料にしていきたいですね。
課題と打ち手を紐付ける上で、非常に有用なものだと感じています。
理想の状態に向けた「共通認識」を醸成する。現場に拒否感を与えない運用のコツ
今後、私たちと同様の課題を抱える他社さまやチームの方々に向けてお伝えしたいのは、このプロジェクト投資分析を活用することが、まずはチームで課題を「共通認識」とするための大きな第一歩に繋がるということです。数値という客観的なファクトがあることで、自分たちのチームにとっての理想はどのような状態なのかを建設的に話し合えるようになり、その理想の実現に向けて具体的に動き出せるようになるはずです。
また、Jiraの運用とFindy Team+を併用する際のコツとしては、分析のためのコストが高くなってしまうとチームに拒否感が出てしまう可能性があるので、できる限り手作業が不要な運用にすることをおすすめします。私たちのチームのようにオートメーションを活用するなどして運用の負荷を下げることは、継続のための重要なポイントです。同時に、これは既存の運用を改めて見直す良い機会にもなります。その運用は何のためにやっているのか、もっと良い方法は無いのかなどを改めて整理することで、チーム全体がより本質的な改善に向かっていけるのではないでしょうか。
今後一緒に働きたいエンジニア像とは？
今後私たちが作っていきたいのは、メンバー個人が感じている不安や懸念などをフラットに言い合い、自律的にどんどん改善していける組織です。
現在、私たちの組織はプロダクトの価値を上げるために他のユニットとの連携が欠かせないフェーズにあります。改善の範囲を自分のユニット内だけに留めるのではなく、ユニットを超えて他部署や他職種などに広げていく必要があります。そのためにも、行動のためのハードルを下げ、個々の行動力を幅広く活かせる組織にしていきたいと考えています。
また現在はClaude Code、Cursor、DevinといったAIエージェントを主に活用していますが、これらはトップダウンで与えられたものではなく、エンジニア側からの提案によってボトムアップで導入されたものです。
新しいAIツールを素早く利用できるように環境が整えられていますし、社内でのナレッジ共有も非常に盛んです。分からないことを気軽に聞ける文化があり、ツールの勉強会なども頻繁に行われているので、知見を深めたい方には最適な環境です。
私たちが一緒に働きたいのは、プロダクトの価値向上のために自律的に動ける人、そしてそこから更に自分の殻を破って行動できる人です。
現状に留まるのではなく、様々な人やプロダクトと密に連携を取りながら、積極的に挑戦をし続けられる方と一緒に働きたいです。
ご興味をお持ちいただけた方は、エンジニア | 株式会社SmartHR 採用サイトもぜひご覧ください。
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/
プロダクトの急成長を続ける株式会社SmartHR。その中で「届出書類機能」の開発を担うユニット（届出書類チーム）は、デザイナーやQAEなど多様な職種とスポットで連携しながら開発を進めています。
同チームでは、新機能開発と並行して「いかに機能改善や技術的負債解消への投資を担保するか」が大きな課題となっていました。定性的には「改善に手が回っていない」という肌感覚をチーム全員が持っていたものの、それが実際にどれほどの数字なのかが分からず、定量的なファクトがないことで課題感をうまく伝えきれない状況が続いていたといいます。
こうした中、同社はFindy Team+の「プロジェクト投資分析」機能を導入し、Jira運用の徹底した最適化を断行。感覚値を定量的なファクトへと変換することで、エンジニア・PM・ビジネスサイドが同じ目線で投資判断を行える体制を構築しました。
本記事では、人給基幹プロダクト開発本部 Directorの秋山さんと、同ユニットでChiefを務める小林さんに、可視化の障壁を乗り越えたJira運用の工夫と、データをもとにした「納得感のある改善サイクル」の回し方について詳しく伺いました。
プロフィール
秋山 譲さん
人給基幹プロダクト開発本部 Director
SmartHR人給基幹プロダクト開発本部Director。エンジニアリングマネージャーのマネジメントを担当し、労務・勤怠管理・給与計算の各プロダクトチームを管掌。新卒でSIerに入社後、様々な業界のWebプロダクトの開発を経験。2024年12月入社後、約1年間エンジニアリングマネージャーとして従事した後、2026年1月から現職に就任。
小林 優太さん
人給基幹プロダクト開発本部 届出書類ユニット Chief
SmartHR人給基幹プロダクト開発本部 届出書類ユニット Chief。届出書類ユニットの開発およびメンバーのマネジメントを担当。2015年にSIerに入社後、Webアプリケーションの開発およびマネジメントを経験。飲食業界向けのマーケットプレイスを提供するスタートアップを経て、2021年にSmartHRに入社し、届出書類機能の開発に携わる。2024年1月から現職に就任。
「改善に手が回らない」肌感を定量化。PMとエンジニアの間にあった“投資実態”の認識の乖離
小林：当時、私のチームでは新機能の開発をかなりハイペースで進めていました。プロダクトマネージャーからも「もっと機能改善の比率も増やしていきたいね」という話が出ていたのですが、実際の問題として、自分たちのリソースが具体的にどれくらい新機能開発に割り振られているのかが全く見えていなかったんです。チームに対しても、具体的な根拠がないので課題感をうまく伝えきれないもどかしさがありました。
定性的には「改善に手が回っていないよね」という肌感覚をチーム全員が持っていたものの、それが実際にはどれほどの数字なのかが分からず、定量的に見えていないことが一番のネックでした。
このまま肌感覚だけで話すのではなく、データとしてすり合わせをしないと本質的に良くしていくことはできないと感じていたタイミングで、秋山さんから「Findy Team+に新しく投資分析の機能が出るから使ってみないか」と提案をもらい、導入に踏み切りました。
秋山：労務ドメイン全体という広い視点でお話しすると、去年の6月から7月にかけてスクラムの拡張版であるScrum@Scaleという取り組みを導入し、ドメイン全体で管理できるようにするサイクルが回り始めました。
その中で、新機能開発にリソースが偏っているという課題は届出書類チームだけでなく他のチームでも起きていたんです。プロダクトマネージャーとしては技術的負債の解消に投資している感覚がある一方で、実際にはそのファクトがなく、エンジニア側はそこに全然時間が使えていないという実感がある。
こうした認識のズレを解消するためのファクトを得るために、まずは届出書類チームをパイロットとしてお願いしたという経緯です。
一気通貫で捉える。多角的な分析で見えてくるチームの真実
小林：プロジェクト投資分析機能を使ってみようと思った一番のきっかけは、やはり自分たちがやりたかった「情報の可視化」が、定量的なデータに基づいて示せる点にありました。私たちのチームにはすでにFindy Team+を活用して振り返りを行うプロセスが定着していたので、その既存のフローに無理なく組み込みやすい点も魅力に感じました。
また、単一の指標を見るのではなく「プロジェクト投資分析→スプリントパフォーマンス分析→サイクルタイム分析」という一連の流れを捉えています。
最初からこれら全てを同時に見ていたわけではありませんが、まずはサイクルタイムの分析から始まり、社内で隔週開催されている「Findy Team+の知見をためる会」を通じて他チームの活用事例を知り、スプリントパフォーマンス分析も取り入れるようになりました。
今回のプロジェクト投資分析の設定が完了し具体的な数値が見え始めてきたタイミングで、これまでの分析画面と組み合わせることでチームの状態をより深く把握できると思い、一緒に見ています。
投資カテゴリ（新機能／改善／品質保証／開発生産性）という整理軸については、もともと私たちのJira運用がそこまでかっちり決まっておらず、ふんわりと使っていた背景もあり、今回の導入に合わせて改めて作業タイプの整理を行いました。実際にFindy Team+が提供している4つの軸を使ってみると、私たちの開発実態でこれに当てはまらないケースというのはほぼなくて、非常に良い軸だなと使っていて感じています。
また弊社では、単に機能として使えるだけでなく、お客様に「魅力的だ」と感じてもらえる品質を追求しており、「魅力的品質」という言葉が経営層も含めた全社の共通言語になっています。その実現をするために、実際にどれだけ時間を投資できているのか、どこに力を寄せられているのかを定量的に注視しています。
自由度の高いJira運用をいかにデータへ変換するか。可視化の土台となる「定義の明文化」
小林：SmartHRではほぼ全社でJiraを利用していますが、必ずしも絶対に使わなければならないというルールではなく、一部でGitHub Projectsを利用しているチームもあります。
私たちのチームでは、エピックやイシューの作成はチーム内の誰が行ってもよいという運用にしています。具体的には、大きな新機能開発（フィーチャー）であればそのプロジェクトをリードする担当エンジニアが作成を一手に担うことが多いですが、不具合やバグについては見つけた人がその場で起票するような流れです。
作成したチケットについては、スクラムのプロセスに則ってプロダクトバックログリファインメントやスプリントプランニングを行い、スプリントに入れていきます。担当者をアサインすることもあれば、手が空いているメンバーが着手することもあり、最終的に本番環境にリリースされた時点でクローズするというのが一連の流れです。エピックについても、紐づく全てのイシューが完了した段階でクローズされるようになっています。
以前の運用で特に課題に感じていたのは、イシューの分類やカテゴリ分けが不十分だったことです。バグについてはしっかりと分類していましたが、それ以外のものは新機能であっても機能改善であっても、あるいは開発生産性向上に関するタスクであっても、特に区別せずに「タスク」という一つの課題タイプで扱っていました。
また、Jiraを利用する中で以前からチーム内でよく議論になっていたのが、イシューを作成する際の「タスク」と「ストーリー」という課題タイプの使い分けです。これらを使い分ける意味がどこにあるのかが明確に定義されておらず、運用がふんわりとしていた部分があり、今回のプロジェクト投資分析機能を導入するにあたって、改めてこれらの役割分担を整理し、明文化しました。
過去のチケットを全て整理し直すコストも考慮し、最終的には「どちらのタイプを使ってもOK」という結論にはなりましたが、曖昧だった定義を言語化したことで、迷わずに運用できる状態に整えました。
「運用負荷ゼロ」が継続の鍵。オートメーション活用で実現したラベル付与の自動化
小林：JiraとFindy Team+の連携においては、運用コストを最低限にしたいと思っていました。新しいツールを入れるからといって、現場のエンジニアにこれまでやっていなかった作業を強いるのは避けたかったので、既存の運用を活かしながら自動化する工夫を凝らしました。
最初に取り組んだのは、Jira内でのチケットの粒度を揃えることです。
以前は、カスタマーサポートなどのデスクからのお問い合わせが入ると自動でJiraチケットが起票される仕組みになっていたのですが、それが一つの親チケットに対する「サブタスク」として作られるワークフローになっていました。
これでは他の開発イシューと粒度が揃わず、Findy Team+で可視化した際にも実態に即した数値が出ないという課題があったんです。
そこで、デスクチケットも他のイシューと同様に「親チケット」として作成されるように運用を変更しました。この変更によって分析の精度が上がったのはもちろん、Jira内でもクローズされていないチケットの検索が容易になるなど、検索性が向上するという副次的なメリットも得られました。
また、チームとして歴史がある分、形骸化してうまく回っていなかったプロセスもこの機会に見直しました。例えば、以前は1ヶ月の間に改善だけをまとめて行う「改善スプリント」という箱を作っていたのですが、実態としてあまり機能していませんでした。これを思い切って廃止し、代わりに「改善」という作業タイプを新たに定義して、通常の開発スプリントの中にそのチケットを直接入れる運用に整理し直したんです。
こうした新しい運用を定着させるために、Jiraのオートメーションを活用しました。
具体的には、作業タイプが「改善」であれば、チケット作成時に自動でマッピング用ラベルが付与されるように設定しています。
途中で、オートメーションによって作成されたサブタスクには手動で作成をしないと処理が走らないという制約に直面しましたが、既存のオートメーションの中で直接ラベルに値が入るように処理を組み込むことで解決しました。
現在、チームメンバーが手作業でラベルを付けることは一切ありません。作業タイプを設定するだけで運用が回る仕組みを構築できたので、現場からの反発もなく、非常にスムーズに継続できています。
改善投資0%からの再出発。PMと合意した「1スプリント・1改善」への具体的な一歩
小林：プロジェクト投資分析機能を使ってみて最も効果を感じたのは、自分たちがどのような時間の使い方をしているのかを、感覚値ではなくデータを見て話せるようになった点です。
これにより、議論における納得感が格段に上がりました。
初めて数値を出してチームで話し合った際は、機能改善に割けている時間が「ほぼ0%に近い」という事実が判明しました。以前から改善ができていないという肌感はありましたが、今のチームにとっての理想の比率はどのくらいかという話をプロダクトマネージャーも交えて議論し、「まずは10〜15%程度を目指そう」という目標を立てることができました。
いきなり理想に近づくのは難しいため、アクションとしては「1つのスプリントにつき必ず1つの機能改善を入れよう」というスモールステップからトライを開始しています。
また、「プロジェクト投資分析」「スプリントパフォーマンス分析」「サイクルタイム分析」のそれぞれの数値をきっかけに、チームで何が良かったのかを話し合う習慣に繋げられています。
プロジェクト投資分析については、マンスリーで「先月はこの割合で時間を使っていた」という振り返りを行っています。品質保証に割く時間が長くなっている場合には、何が原因だったのか、逆に短く済んだ時は何が良かったのかを深掘りし、チームの学びに繋げています。
スプリントパフォーマンス分析では、私たちのチームの直近の課題であった「タスクの持ち越し」にフォーカスしています。
なぜ持ち越しが発生するのか、どうすれば解決できるのかを議論した結果、具体的なアクションとして「期限確認のタイミング」を変更しました。以前は火曜日に終了するスプリントに対し、月曜日の午後に期限を確認していましたが、それでは「あと一日早ければ間に合ったのに」という事態が防げません。
そこで、金曜日のうちに確認を行う運用に変えたことで、少しずつ状況が改善され始めています。
スプリント管理において、難しさを感じているのが「差し込みタスク」への対応です。
差し込みが発生した場合には「既存のスプリントに入っている同等分のポイントをその時点で取り下げる」という運用をチームで話し合っています。
あえてバッファは設けず、入ってきた分だけ既存のものを抜くという考え方ですが、実際には必ずしもそれが徹底できているわけではなく、難易度の高い課題として今も向き合い続けています。
サイクルタイム分析に関しては、チームの合計値は「Elite」を維持できていますが、「オープンからレビューまで」の時間が長くなりがちだという課題を常に意識するために活用しています。
毎月の数値の上下を見ながら、「今月はこれができたから良かった」「ここが課題だった」と振り返ることで、素早くレビューに取り組むという意識醸成に繋がっています。
サイクルタイムを分析・改善したことでチームの状態が良くなったという成功体験がすでにあったからこそ、新しく導入したスプリントパフォーマンス分析やプロジェクト投資分析もしっかりと見ていこうという活力に繋がっています。
歴史あるチームへの展開を見据えて。感覚値の議論を脱却し、組織全体の投資戦略をアップデートする
秋山：今後の展望としては、今回の届出書類チームでの取り組みを、労務ドメイン全体へと広げていきたいと考えています。
プロダクト開発の現場では、どうしても感覚で話をしてしまったり、その時の立場にとって都合の良い解釈をしてしまったりすることが起こり得ます。ロードマップの策定やOKRを決める際にも、定量的な数値をベースにコミュニケーションを取ることで、エンジニア、PM、そしてビジネスサイドの方々とも、よりスムーズにコンセンサスを形成しやすくなるはずだと考えています。
ただ、実際にドメイン全体へ展開していく上での難しさも感じています。労務ドメインには10年ほど開発を続けている歴史の長いチームもあり、そうしたチームに対してJiraの設定を一からチューニングしていくのは、正直なところかなりハードルが高いのが実情です。
今の届出書類チームのような新しいチームでの成功例をそのまま持ち込むのはしんどい部分もあるので、より導入しやすい方法を模索しながら、全体での投資分析を進めていきたいですね。
また、各チームのマネージャーレイヤー（EMやPM）が「このくらいの投資比率で進めよう」と戦略を握り始めています。感覚で話すとどうしても自分たちに都合の良い解釈になりがちですが、定量値をベースにすることで、その戦略が成り立っているかどうかの振り返りに利用できるといいなと思っています。
小林：チームレベルでも、引き続き振り返りの質を上げるために活用していきたいです。
例えば、現状では品質保証にかける時間が少し大きすぎるという課題が見えているので、それを具体的にどう減らしていくか、あるいは開発生産性をさらに向上させるためにチームとしてどう取り組むべきか。そうした議論を行う際に、メンバーの納得感を高めるための材料にしていきたいですね。
課題と打ち手を紐付ける上で、非常に有用なものだと感じています。
理想の状態に向けた「共通認識」を醸成する。現場に拒否感を与えない運用のコツ
今後、私たちと同様の課題を抱える他社さまやチームの方々に向けてお伝えしたいのは、このプロジェクト投資分析を活用することが、まずはチームで課題を「共通認識」とするための大きな第一歩に繋がるということです。数値という客観的なファクトがあることで、自分たちのチームにとっての理想はどのような状態なのかを建設的に話し合えるようになり、その理想の実現に向けて具体的に動き出せるようになるはずです。
また、Jiraの運用とFindy Team+を併用する際のコツとしては、分析のためのコストが高くなってしまうとチームに拒否感が出てしまう可能性があるので、できる限り手作業が不要な運用にすることをおすすめします。私たちのチームのようにオートメーションを活用するなどして運用の負荷を下げることは、継続のための重要なポイントです。同時に、これは既存の運用を改めて見直す良い機会にもなります。その運用は何のためにやっているのか、もっと良い方法は無いのかなどを改めて整理することで、チーム全体がより本質的な改善に向かっていけるのではないでしょうか。
今後一緒に働きたいエンジニア像とは？
今後私たちが作っていきたいのは、メンバー個人が感じている不安や懸念などをフラットに言い合い、自律的にどんどん改善していける組織です。
現在、私たちの組織はプロダクトの価値を上げるために他のユニットとの連携が欠かせないフェーズにあります。改善の範囲を自分のユニット内だけに留めるのではなく、ユニットを超えて他部署や他職種などに広げていく必要があります。そのためにも、行動のためのハードルを下げ、個々の行動力を幅広く活かせる組織にしていきたいと考えています。
また現在はClaude Code、Cursor、DevinといったAIエージェントを主に活用していますが、これらはトップダウンで与えられたものではなく、エンジニア側からの提案によってボトムアップで導入されたものです。
新しいAIツールを素早く利用できるように環境が整えられていますし、社内でのナレッジ共有も非常に盛んです。分からないことを気軽に聞ける文化があり、ツールの勉強会なども頻繁に行われているので、知見を深めたい方には最適な環境です。
私たちが一緒に働きたいのは、プロダクトの価値向上のために自律的に動ける人、そしてそこから更に自分の殻を破って行動できる人です。
現状に留まるのではなく、様々な人やプロダクトと密に連携を取りながら、積極的に挑戦をし続けられる方と一緒に働きたいです。
ご興味をお持ちいただけた方は、エンジニア | 株式会社SmartHR 採用サイトもぜひご覧ください。
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/
改善投資0%からの再出発──SmartHRがプロジェクト投資分析で掴んだ、うまく伝えきれない課題を動かすファクト管理
プロダクトの急成長を続ける株式会社SmartHR。その中で「届出書類機能」の開発を担うユニット（届出書類チーム）は、デザイナーやQAEなど多様な職種とスポットで連携しながら開発を進めています。
同チームでは、新機能開発と並行して「いかに機能改善や技術的負債解消への投資を担保するか」が大きな課題となっていました。定性的には「改善に手が回っていない」という肌感覚をチーム全員が持っていたものの、それが実際にどれほどの数字なのかが分からず、定量的なファクトがないことで課題感をうまく伝えきれない状況が続いていたといいます。
こうした中、同社はFindy Team+の「プロジェクト投資分析」機能を導入し、Jira運用の徹底した最適化を断行。感覚値を定量的なファクトへと変換することで、エンジニア・PM・ビジネスサイドが同じ目線で投資判断を行える体制を構築しました。
本記事では、人給基幹プロダクト開発本部 Directorの秋山さんと、同ユニットでChiefを務める小林さんに、可視化の障壁を乗り越えたJira運用の工夫と、データをもとにした「納得感のある改善サイクル」の回し方について詳しく伺いました。
プロフィール
秋山 譲さん
人給基幹プロダクト開発本部 Director
SmartHR人給基幹プロダクト開発本部Director。エンジニアリングマネージャーのマネジメントを担当し、労務・勤怠管理・給与計算の各プロダクトチームを管掌。新卒でSIerに入社後、様々な業界のWebプロダクトの開発を経験。2024年12月入社後、約1年間エンジニアリングマネージャーとして従事した後、2026年1月から現職に就任。
小林 優太さん
人給基幹プロダクト開発本部 届出書類ユニット Chief
SmartHR人給基幹プロダクト開発本部 届出書類ユニット Chief。届出書類ユニットの開発およびメンバーのマネジメントを担当。2015年にSIerに入社後、Webアプリケーションの開発およびマネジメントを経験。飲食業界向けのマーケットプレイスを提供するスタートアップを経て、2021年にSmartHRに入社し、届出書類機能の開発に携わる。2024年1月から現職に就任。
「改善に手が回らない」肌感を定量化。PMとエンジニアの間にあった“投資実態”の認識の乖離
小林：当時、私のチームでは新機能の開発をかなりハイペースで進めていました。プロダクトマネージャーからも「もっと機能改善の比率も増やしていきたいね」という話が出ていたのですが、実際の問題として、自分たちのリソースが具体的にどれくらい新機能開発に割り振られているのかが全く見えていなかったんです。チームに対しても、具体的な根拠がないので課題感をうまく伝えきれないもどかしさがありました。
定性的には「改善に手が回っていないよね」という肌感覚をチーム全員が持っていたものの、それが実際にはどれほどの数字なのかが分からず、定量的に見えていないことが一番のネックでした。
このまま肌感覚だけで話すのではなく、データとしてすり合わせをしないと本質的に良くしていくことはできないと感じていたタイミングで、秋山さんから「Findy Team+に新しく投資分析の機能が出るから使ってみないか」と提案をもらい、導入に踏み切りました。
秋山：労務ドメイン全体という広い視点でお話しすると、去年の6月から7月にかけてスクラムの拡張版であるScrum@Scaleという取り組みを導入し、ドメイン全体で管理できるようにするサイクルが回り始めました。
その中で、新機能開発にリソースが偏っているという課題は届出書類チームだけでなく他のチームでも起きていたんです。プロダクトマネージャーとしては技術的負債の解消に投資している感覚がある一方で、実際にはそのファクトがなく、エンジニア側はそこに全然時間が使えていないという実感がある。
こうした認識のズレを解消するためのファクトを得るために、まずは届出書類チームをパイロットとしてお願いしたという経緯です。
一気通貫で捉える。多角的な分析で見えてくるチームの真実
小林：プロジェクト投資分析機能を使ってみようと思った一番のきっかけは、やはり自分たちがやりたかった「情報の可視化」が、定量的なデータに基づいて示せる点にありました。私たちのチームにはすでにFindy Team+を活用して振り返りを行うプロセスが定着していたので、その既存のフローに無理なく組み込みやすい点も魅力に感じました。
また、単一の指標を見るのではなく「プロジェクト投資分析→スプリントパフォーマンス分析→サイクルタイム分析」という一連の流れを捉えています。
最初からこれら全てを同時に見ていたわけではありませんが、まずはサイクルタイムの分析から始まり、社内で隔週開催されている「Findy Team+の知見をためる会」を通じて他チームの活用事例を知り、スプリントパフォーマンス分析も取り入れるようになりました。
今回のプロジェクト投資分析の設定が完了し具体的な数値が見え始めてきたタイミングで、これまでの分析画面と組み合わせることでチームの状態をより深く把握できると思い、一緒に見ています。
投資カテゴリ（新機能／改善／品質保証／開発生産性）という整理軸については、もともと私たちのJira運用がそこまでかっちり決まっておらず、ふんわりと使っていた背景もあり、今回の導入に合わせて改めて作業タイプの整理を行いました。実際にFindy Team+が提供している4つの軸を使ってみると、私たちの開発実態でこれに当てはまらないケースというのはほぼなくて、非常に良い軸だなと使っていて感じています。
また弊社では、単に機能として使えるだけでなく、お客様に「魅力的だ」と感じてもらえる品質を追求しており、「魅力的品質」という言葉が経営層も含めた全社の共通言語になっています。その実現をするために、実際にどれだけ時間を投資できているのか、どこに力を寄せられているのかを定量的に注視しています。
自由度の高いJira運用をいかにデータへ変換するか。可視化の土台となる「定義の明文化」
小林：SmartHRではほぼ全社でJiraを利用していますが、必ずしも絶対に使わなければならないというルールではなく、一部でGitHub Projectsを利用しているチームもあります。
私たちのチームでは、エピックやイシューの作成はチーム内の誰が行ってもよいという運用にしています。具体的には、大きな新機能開発（フィーチャー）であればそのプロジェクトをリードする担当エンジニアが作成を一手に担うことが多いですが、不具合やバグについては見つけた人がその場で起票するような流れです。
作成したチケットについては、スクラムのプロセスに則ってプロダクトバックログリファインメントやスプリントプランニングを行い、スプリントに入れていきます。担当者をアサインすることもあれば、手が空いているメンバーが着手することもあり、最終的に本番環境にリリースされた時点でクローズするというのが一連の流れです。エピックについても、紐づく全てのイシューが完了した段階でクローズされるようになっています。
以前の運用で特に課題に感じていたのは、イシューの分類やカテゴリ分けが不十分だったことです。バグについてはしっかりと分類していましたが、それ以外のものは新機能であっても機能改善であっても、あるいは開発生産性向上に関するタスクであっても、特に区別せずに「タスク」という一つの課題タイプで扱っていました。
また、Jiraを利用する中で以前からチーム内でよく議論になっていたのが、イシューを作成する際の「タスク」と「ストーリー」という課題タイプの使い分けです。これらを使い分ける意味がどこにあるのかが明確に定義されておらず、運用がふんわりとしていた部分があり、今回のプロジェクト投資分析機能を導入するにあたって、改めてこれらの役割分担を整理し、明文化しました。
過去のチケットを全て整理し直すコストも考慮し、最終的には「どちらのタイプを使ってもOK」という結論にはなりましたが、曖昧だった定義を言語化したことで、迷わずに運用できる状態に整えました。
「運用負荷ゼロ」が継続の鍵。オートメーション活用で実現したラベル付与の自動化
小林：JiraとFindy Team+の連携においては、運用コストを最低限にしたいと思っていました。新しいツールを入れるからといって、現場のエンジニアにこれまでやっていなかった作業を強いるのは避けたかったので、既存の運用を活かしながら自動化する工夫を凝らしました。
最初に取り組んだのは、Jira内でのチケットの粒度を揃えることです。
以前は、カスタマーサポートなどのデスクからのお問い合わせが入ると自動でJiraチケットが起票される仕組みになっていたのですが、それが一つの親チケットに対する「サブタスク」として作られるワークフローになっていました。
これでは他の開発イシューと粒度が揃わず、Findy Team+で可視化した際にも実態に即した数値が出ないという課題があったんです。
そこで、デスクチケットも他のイシューと同様に「親チケット」として作成されるように運用を変更しました。この変更によって分析の精度が上がったのはもちろん、Jira内でもクローズされていないチケットの検索が容易になるなど、検索性が向上するという副次的なメリットも得られました。
また、チームとして歴史がある分、形骸化してうまく回っていなかったプロセスもこの機会に見直しました。例えば、以前は1ヶ月の間に改善だけをまとめて行う「改善スプリント」という箱を作っていたのですが、実態としてあまり機能していませんでした。これを思い切って廃止し、代わりに「改善」という作業タイプを新たに定義して、通常の開発スプリントの中にそのチケットを直接入れる運用に整理し直したんです。
こうした新しい運用を定着させるために、Jiraのオートメーションを活用しました。
具体的には、作業タイプが「改善」であれば、チケット作成時に自動でマッピング用ラベルが付与されるように設定しています。
途中で、オートメーションによって作成されたサブタスクには手動で作成をしないと処理が走らないという制約に直面しましたが、既存のオートメーションの中で直接ラベルに値が入るように処理を組み込むことで解決しました。
現在、チームメンバーが手作業でラベルを付けることは一切ありません。作業タイプを設定するだけで運用が回る仕組みを構築できたので、現場からの反発もなく、非常にスムーズに継続できています。
改善投資0%からの再出発。PMと合意した「1スプリント・1改善」への具体的な一歩
小林：プロジェクト投資分析機能を使ってみて最も効果を感じたのは、自分たちがどのような時間の使い方をしているのかを、感覚値ではなくデータを見て話せるようになった点です。
これにより、議論における納得感が格段に上がりました。
初めて数値を出してチームで話し合った際は、機能改善に割けている時間が「ほぼ0%に近い」という事実が判明しました。以前から改善ができていないという肌感はありましたが、今のチームにとっての理想の比率はどのくらいかという話をプロダクトマネージャーも交えて議論し、「まずは10〜15%程度を目指そう」という目標を立てることができました。
いきなり理想に近づくのは難しいため、アクションとしては「1つのスプリントにつき必ず1つの機能改善を入れよう」というスモールステップからトライを開始しています。
また、「プロジェクト投資分析」「スプリントパフォーマンス分析」「サイクルタイム分析」のそれぞれの数値をきっかけに、チームで何が良かったのかを話し合う習慣に繋げられています。
プロジェクト投資分析については、マンスリーで「先月はこの割合で時間を使っていた」という振り返りを行っています。品質保証に割く時間が長くなっている場合には、何が原因だったのか、逆に短く済んだ時は何が良かったのかを深掘りし、チームの学びに繋げています。
スプリントパフォーマンス分析では、私たちのチームの直近の課題であった「タスクの持ち越し」にフォーカスしています。
なぜ持ち越しが発生するのか、どうすれば解決できるのかを議論した結果、具体的なアクションとして「期限確認のタイミング」を変更しました。以前は火曜日に終了するスプリントに対し、月曜日の午後に期限を確認していましたが、それでは「あと一日早ければ間に合ったのに」という事態が防げません。
そこで、金曜日のうちに確認を行う運用に変えたことで、少しずつ状況が改善され始めています。
スプリント管理において、難しさを感じているのが「差し込みタスク」への対応です。
差し込みが発生した場合には「既存のスプリントに入っている同等分のポイントをその時点で取り下げる」という運用をチームで話し合っています。
あえてバッファは設けず、入ってきた分だけ既存のものを抜くという考え方ですが、実際には必ずしもそれが徹底できているわけではなく、難易度の高い課題として今も向き合い続けています。
サイクルタイム分析に関しては、チームの合計値は「Elite」を維持できていますが、「オープンからレビューまで」の時間が長くなりがちだという課題を常に意識するために活用しています。
毎月の数値の上下を見ながら、「今月はこれができたから良かった」「ここが課題だった」と振り返ることで、素早くレビューに取り組むという意識醸成に繋がっています。
サイクルタイムを分析・改善したことでチームの状態が良くなったという成功体験がすでにあったからこそ、新しく導入したスプリントパフォーマンス分析やプロジェクト投資分析もしっかりと見ていこうという活力に繋がっています。
歴史あるチームへの展開を見据えて。感覚値の議論を脱却し、組織全体の投資戦略をアップデートする
秋山：今後の展望としては、今回の届出書類チームでの取り組みを、労務ドメイン全体へと広げていきたいと考えています。
プロダクト開発の現場では、どうしても感覚で話をしてしまったり、その時の立場にとって都合の良い解釈をしてしまったりすることが起こり得ます。ロードマップの策定やOKRを決める際にも、定量的な数値をベースにコミュニケーションを取ることで、エンジニア、PM、そしてビジネスサイドの方々とも、よりスムーズにコンセンサスを形成しやすくなるはずだと考えています。
ただ、実際にドメイン全体へ展開していく上での難しさも感じています。労務ドメインには10年ほど開発を続けている歴史の長いチームもあり、そうしたチームに対してJiraの設定を一からチューニングしていくのは、正直なところかなりハードルが高いのが実情です。
今の届出書類チームのような新しいチームでの成功例をそのまま持ち込むのはしんどい部分もあるので、より導入しやすい方法を模索しながら、全体での投資分析を進めていきたいですね。
また、各チームのマネージャーレイヤー（EMやPM）が「このくらいの投資比率で進めよう」と戦略を握り始めています。感覚で話すとどうしても自分たちに都合の良い解釈になりがちですが、定量値をベースにすることで、その戦略が成り立っているかどうかの振り返りに利用できるといいなと思っています。
小林：チームレベルでも、引き続き振り返りの質を上げるために活用していきたいです。
例えば、現状では品質保証にかける時間が少し大きすぎるという課題が見えているので、それを具体的にどう減らしていくか、あるいは開発生産性をさらに向上させるためにチームとしてどう取り組むべきか。そうした議論を行う際に、メンバーの納得感を高めるための材料にしていきたいですね。
課題と打ち手を紐付ける上で、非常に有用なものだと感じています。
理想の状態に向けた「共通認識」を醸成する。現場に拒否感を与えない運用のコツ
今後、私たちと同様の課題を抱える他社さまやチームの方々に向けてお伝えしたいのは、このプロジェクト投資分析を活用することが、まずはチームで課題を「共通認識」とするための大きな第一歩に繋がるということです。数値という客観的なファクトがあることで、自分たちのチームにとっての理想はどのような状態なのかを建設的に話し合えるようになり、その理想の実現に向けて具体的に動き出せるようになるはずです。
また、Jiraの運用とFindy Team+を併用する際のコツとしては、分析のためのコストが高くなってしまうとチームに拒否感が出てしまう可能性があるので、できる限り手作業が不要な運用にすることをおすすめします。私たちのチームのようにオートメーションを活用するなどして運用の負荷を下げることは、継続のための重要なポイントです。同時に、これは既存の運用を改めて見直す良い機会にもなります。その運用は何のためにやっているのか、もっと良い方法は無いのかなどを改めて整理することで、チーム全体がより本質的な改善に向かっていけるのではないでしょうか。
今後一緒に働きたいエンジニア像とは？
今後私たちが作っていきたいのは、メンバー個人が感じている不安や懸念などをフラットに言い合い、自律的にどんどん改善していける組織です。
現在、私たちの組織はプロダクトの価値を上げるために他のユニットとの連携が欠かせないフェーズにあります。改善の範囲を自分のユニット内だけに留めるのではなく、ユニットを超えて他部署や他職種などに広げていく必要があります。そのためにも、行動のためのハードルを下げ、個々の行動力を幅広く活かせる組織にしていきたいと考えています。
また現在はClaude Code、Cursor、DevinといったAIエージェントを主に活用していますが、これらはトップダウンで与えられたものではなく、エンジニア側からの提案によってボトムアップで導入されたものです。
新しいAIツールを素早く利用できるように環境が整えられていますし、社内でのナレッジ共有も非常に盛んです。分からないことを気軽に聞ける文化があり、ツールの勉強会なども頻繁に行われているので、知見を深めたい方には最適な環境です。
私たちが一緒に働きたいのは、プロダクトの価値向上のために自律的に動ける人、そしてそこから更に自分の殻を破って行動できる人です。
現状に留まるのではなく、様々な人やプロダクトと密に連携を取りながら、積極的に挑戦をし続けられる方と一緒に働きたいです。
ご興味をお持ちいただけた方は、エンジニア | 株式会社SmartHR 採用サイトもぜひご覧ください。
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/
