はてなブックマーク

こんにちは！権限基盤ユニット所属の@bmf-sanです。今年の6月に入社してから早くも6ヶ月目を迎えました。 権限基盤ユニットは、SmartHRにおける各プロダクトの権限を集約し、労務・タレントマネジメント領域における要求に柔軟に対応できるような権限基盤の構築・運用を行うチームです。 権限基盤ユニットでは、マルチプロダクト戦略における権限の課題をスマートに解決していこうと日々奮闘しています。 私は入社して以来、権限の難しさにずっと頭を悩ませてきました。権限の難しさに頭を悩ませているのはきっと自分だけではないはずです……！ そこで、権限に関わるメンバーが権限にどのような難しさを感じているのかを次の質問を通して明らかにしてみたいと思いました。 「好きなおにぎりの具は何ですか？」 「権限基盤の難しいことは何ですか？またその理由を教えて下さい」 この記事では、権限の基盤の難しいところについて、メン

こんにちは！ 課金基盤チームです。 今回は、SmartHRのプロダクト基盤開発本部内で、課金・プランによる機能制御を担当している課金基盤チームの紹介と今取り組んでいる課題について書きます。 課金基盤チームの紹介 課金基盤チームでは、 プランによって利用可能なSmartHRの機能を制御する 企業アカウントごとの課金対象人数を決定する 支払い明細や領収書を表示する といった、SmartHRの課金の仕組みに関わることを主に受け持っています。 チームは、プロダクトエンジニア(5名)・PM1名・QAエンジニア1名で構成されています。 チームの歴史 課金基盤チームの誕生の経緯について紹介します プロダクト基盤チーム時代 プロダクトを横断する課題に取り組むべく、2023年にプロダクト基盤チームが組成されました。その後、課金に関する課題もプロダクト基盤チームで対応することになりました。当時のプロダクト基盤

こんにちは！プロダクトエンジニアの@ymtdzzzです。普段はSmartHRの各プロダクトから参照される共通データを扱うチーム（共通データ基盤ユニット）で仕事をしています。2024年7月入社で、前職ではGolangとPHPを書いていたのでRails歴はまだ4ヶ月ほどです。 みなさんは2024年10月25日(金)~10月26日(土)に開催された「Kaigi on Rails 2024」には参加しましたか？ 会場内の撮影エリア（左から登壇者の@hypermkt @asonas @ymtdzzz） 私は「モノリスでも使える！OpenTelemetryでRailsアプリのパフォーマンス分析を始めてみよう」というタイトルで登壇させていただきました（資料）。今回が初めてのオフラインイベント参加でしたが、セッションや参加者の方々との交流はとても楽しく、学びの多い時間となりました。 この記事では、初めてプ

こんにちは。今回は、SmartHRのバックエンド開発に欠かせないOSSであるRuby on Railsに初めてコントリビュートしたお話をします。 以前「OSSやっていきの集い」の立ち上げについてお伝えしましたが、それを受けて実際に行ったOSS活動の1つです。 tech.smarthr.jp はじまり とあるプロダクトで、RailsがPostgreSQLの float 型のカラムを正しくダンプできない不具合を発見しました。 t.float ..., limit: 24 で定義したカラムを rake db:schema:dump で db/schema.rb に出力すると、limit のないt.float が出力されてしまいました。 limit がなくなると精度が変わるため、これでは db/schema.rb を期待通り扱うことはできません。 期待しない挙動に思えるということで、rails/r

こんにちは！QAエンジニアのark265とgonkmです。本記事は品質保証部の連載記事第3弾です。 今回は、私たちが所属している品質保証部直下のチーム（以下、overallユニット）の業務・やりがい・今後の展望を紹介します。 品質保証部の体制図 overallユニットの業務紹介 overallユニットではSmartHRのサービス全体を横断した品質保証に関わる業務を行なっています。 今期は社内のセキュリティエンジニアと一緒にDevSecOpsの実現に絞って業務を行なっており、具体的にはSAST（Static Application Security Testing）やDAST（Dynamic Application Security Testing）ツールを用いた脆弱性検出の自動化を行ない、開発の早い段階からセキュリティリスクを検出できるよう取り組んでいます。 実際の業務内容について個別に紹

こんにちは！プロダクトエンジニアのyanagidaです。2024年6月にリリースしたデータ連携機能の開発をしています。 support.smarthr.jp この記事では、これまで露出することがなかったデータ連携機能の裏側をご紹介できればと思います。 データ連携機能とは データ連携機能は文字通り、SmartHRと他社システムの「データ」を効率的に連携する機能です。例えば、SmartHRの従業員情報を他社システムに書き出し同期します。逆に、他社システム側の従業員情報をSmartHRに取り込むこともできます。ニーズの高さや実装工数、社内の戦略などを元に優先度を決めながら順次データ連携のバリエーションを拡充しています。 個社カスタマイズにも対応 従業員規模の大きなテナントにおいては業務アプリを独自ルールで運用していることも多く、汎用的なデータ連携では要望に答えきれないケースがしばしばです。このよ

SmartHR 品質保証部 労務ユニットAの紹介 こんにちは！QAエンジニアのkaomiです。 入社して1年3ヶ月が経ち、労務領域のプロダクトを中心にさまざまな業務に携わっています。 オーストラリアの固有種であるウォンバットが大好きで、10/20(日)に大阪府池田市で行われる「ウォンバットの日」が気になっています。 はじめに 本記事は品質保証部の連載記事第2弾です。今回のブログでは、労務ユニットAの紹介と現在取り組んでいる活動について紹介します。 労務ユニットAについて 第1弾のブログで触れたように、労務ユニットAは2024年7月の組織変更で新たに編成されたユニットです。チーフ（プレイングマネージャー）1名とメンバー3名の計4名のQAエンジニアで構成されています。 労務ユニットAでは労務領域の基本機能プロダクトと年末調整機能のプロダクトを担当しています。メンバーは開発チームに専属しておらず

2025年1月より、SmartHRの新たな VP of Engineering に齋藤 諒一さんが就任します。 現 VP of Engineering の森住 卓矢さんからバトンが渡される形です。 smarthr.co.jp 本記事では、齋藤さんについて森住さんがあれやこれやと深堀りした様子をお届けします。 齋藤さんのこれまでのキャリアや経験、そして VP of Engineering として今後どんな開発組織をつくっていきたいかなどについてお話ししています。 はじめに 森住：現 VP of Engineering の森住です。この度、2024年末に VP of Engineering を退任し、2025年にSmartHRを退職することになりました。VP of Engineering の後任として齋藤さんを推薦させていただき、社内の手続きを経て齋藤さんの就任が決定したところです。今日は、齋

こんにちは、UXライティング部のibulogです。社内では「サポートコンテンツマネージャー」というポジションでお仕事をしています。 普通は記事の最後で「We Are Hiring!」するのが相場と心得ておりますが、逸る気持ちを抑えきれませんので、もう求人情報を貼っちゃいます。 サポートコンテンツ戦略・基盤担当 / 株式会社SmartHR さて、SmartHRではヘルプセンターを自社開発しており、かつ現在はエンジニアの支援を得ながらライター上がりのサポートコンテンツマネージャーが主体となって開発・運用をしています。 ヘルプセンター｜SmartHR ヘルプセンターのトップページ 開発に関わるいずれのメンバーもエンジニアとしてキャリアを歩んだ経験はなく、エンジニアの支援や自学によってスキルを獲得しています。まさにクロスファンクショナル。 本日は、少しでも便利なヘルプセンターを提供しよう！という物

SmartHR 品質保証部の現状の体制と目指す姿（24/09版） はじめまして！ SmartHR 品質保証部マネージャー（Acting*1）のtarappoです。 本記事はSmartHR 品質保証部について紹介する連載記事の第一回目となります。 まずは品質保証部全体の紹介をし、今後各ユニットの紹介を定期的に公開していく予定です。 はじめに 品質保証部は今年の4月に次のブログ記事でその時点における組織体制について紹介をしています。 このブログ記事の公開から約半年が過ぎました。 その間に組織体制の変化もあり、改めて「SmartHRの品質保証部の現状の体制」と新たに言語化した「目指す姿」、そして現時点での「課題」について書いていきます。 上記のブログ記事で説明していますが、SmartHRの品質保証部ではここ1年で次のような体制の変化がありました。 以前 個々のプロダクトに専属で入り開発チームと一

こんにちは！プロダクトエンジニアのshiraです。 2024年6月にリリースした採用管理機能の開発をしています。 support.smarthr.jp 採用管理機能ではNext.jsのApp Routerを採用しています。SmartHRではこれまでApp Routerを使ったプロダクトがない状態だったので、技術選定時は採用するか迷いました。 この記事ではApp Routerを採用するまでの経緯と採用してみてどうだったかについて紹介させていただきます。 Pages RouterとApp Routerについて まずはじめにPages RouterとApp Routerについて軽く説明します。ご存知の方は読み飛ばしてください。 2024年9月現在、Next.jsのルーティングシステムは2つ用意されています。それがPages RouterとApp Routerです。 Pages RouterはNe

こんにちは！プロダクトエンジニアのshinokuです。 SmartHRでは、2023年の年末から定期的に社内のLT大会を開催しています。 テックブログでも毎回の内容を紹介しており、本記事の執筆時点だと6月に開催した第6回のブログが最新です。 tech.smarthr.jp 私も記念すべき第1回で登壇をしており、そのときの体験がとても良かったためLTが好きになりました。 本記事では、このLT大会がキッカケになって外部のLT会にも月一ペースで登壇するようになった話を紹介します。 なぜ月一ペースで外部のLT会に登壇するようになったのか 社内LT大会がキッカケとなって外部のLT会にも参加するようになった理由はいくつかあります。 理由１：知識・経験の棚卸の機会になる 社内LT大会への参加を通じて、LTの準備は自分が学んだことや経験したことを振り返り、それを体系的に整理する機会になると感じました。 さ

マルチプロダクト戦略を掲げてプロダクトを急速に増やし続けている SmartHR のフロントエンド領域について、2018年から SmartHR に参加しているフロントエンドエンジニアの nabeliwo と技術顧問の koba04 が、これまでの振り返りと今後の展望を話しました。 SmartHR のフロントエンドでどんな技術が使われてきてどんな課題と向き合ってきたのか、そして今現在取り組んでいる課題や SmartHR ではどんなフロントエンドエンジニアが求められるのかなど、幅広いテーマが出てきました。 この記事ではその模様をお届けします。 目次 フロントエンドの Rails からの脱却とフロントエンド領域の確立 SmartHR UI の誕生 プロダクトの急増 複雑化する技術課題 テストの整備とロジック共通化の取り組み Next.js の導入 新たな技術的挑戦 フロントエンドミーティングの見直

昨今、大規模言語モデル（LLM）に代表されるようにAI技術が飛躍的に進化していますが、SmartHRでもAI専任チームが発足しています。 専任チームはどのように活動し、SmartHRでは今後どのようにAIを活用していくのか。CEOの芹澤とAIプロダクトマネージャーの金岡に対談してもらいました。 対談の様子。左から CEO 芹澤とAIプロダクトマネージャーの金岡 金岡：今日はよろしくお願いします。お互い自己紹介からはじめましょうか。 SmartHRでAI全般の推進をしている金岡です。入社してまもなく4年になります。これまでは一貫してタレントマネジメント領域でプロダクトマネージャーをしていました。AIについては、前職でAI特化の受託チームでプロジェクトマネジャーをしたり、AIプロダクトの立ち上げをしており、比較的勘所があります。SmartHRでもStable DiffusionやOpenAIの

「教えて先輩！ DevRelの立ち上げ方」に続く「教えて先輩シリーズ」の第二弾としまして、JPA（Japan Perl Association）の初代代表理事、buildersconの立ち上げ、YAPC::Asia Tokyo時代のYAPC（Yet Another Perl Conference）の運営で知られるlestrratこと牧大輔さんにお話をうかがいました。インタビュアーはSmartHRのDevRelのinaoです。 前編に続く後編は、主にポストコロナの新しい技術イベントやYouTubeのノウハウについてのお話です。 tech.smarthr.jp （インタビューは2024年7月に行いました。内容は当時のものです） プログラマーからのキャリアチェンジ ポストコロナの新しい技術イベント ほしい人にだけノベルティを渡す方法 ただ飯目当て対策 オンライン、オフライン、ハイブリッド You

「教えて先輩！ DevRelの立ち上げ方」に続く「教えて先輩シリーズ」の第二弾としまして、JPA（Japan Perl Association）の初代代表理事、buildersconの立ち上げ、YAPC::Asia Tokyo時代のYAPC（Yet Another Perl Conference）の運営で知られるlestrratこと牧大輔さんにお話をうかがいました。インタビュアーはSmartHRのDevRelのinaoです。 前後編に分かれており、前編は主に牧さんご自身やYAPC、buildersconについて、後編は主にポストコロナの新しい技術イベントやYouTubeのノウハウについてのお話です。 tech.smarthr.jp tech.smarthr.jp （インタビューは2024年7月に行いました。内容は当時のものです） 生い立ち アメリカでのプログラマー時代 日本でのプログラマー

こんにちは、プログラマのkinoppydです。私の働いているプロダクト基盤チームでは、現在全プロダクト横断従業員検索システムを作成しており、旧システムとのリプレースを行っています。その際に我々が採用した、†ダークローンチ†という手法を皆さんにお伝えしますので、ぜひ参考にしてください。 ダークローンチのイメージ画像です ダークローンチとは？ ダークローンチとは、リリース手法の一つです。すでに稼働しているサービスのトラフィックをコピーして、新たにリリース予定のサービスに対してそのトラフィックを流し、レスポンスを記録しつつ破棄するという形のリリースです。すでに稼働しているサービスから見ると、トラフィックをコピーされる以外は何も変わりません。ダークローンチは、実際のサービスのトラフィックを利用することで、シナリオテストよりも遥かに実態に即したテストが可能であり、かつ既存のユーザーに一切の影響を与え

はじめに こんにちは！ 学習管理機能を開発しているプロダクトエンジニアのs.miyoshiです。 少し前に弊社で学習管理機能をリリースいたしました。 学習管理機能のリリースにあたっていくつか工夫して実装したので、今回は学習管理に求められた機能をどのような技術を使って解決していったのかを紹介させてください。 開発要件 まずはじめに学習管理機能における主な要件です。 他にも細かい要件はありますが、特に重要だった要件です。 最大4GBの動画ファイルをアップロードできること 管理者が動画などのコンテンツファイルをアップロードする場合は正しく認証されている状態であること URLを知っている人であれば誰でもアップロードできるような仕様はNG 従業員がコンテンツを受講する際は、正しく認証されている状態であること コンテンツのURLを知っている人であれば誰でも閲覧できるような仕様はNG 使用した技術 ここ

こんにちは、趣味でコーポレートエンジニアをやっていますyamashuです。 タイトルの通りかなり昔の話になるのですが、勤怠打刻の課題解決についてそういえば社外へ向かってアウトプットしていなかったなと思い、この度したためている次第です。 社外と接点が多い営業の社員が弊社での打刻の方法をたまたまお話したりして、その話を聞いた会社様から「話を聞かせてほしい」とヒアリングをいただくことも最近まで何度かありました。 そのため、もしかしたら同じ悩みに直面している方がいらっしゃるかもしれないので、1つの解決策としてやったことを書いておこうと思います。 課題 🤔 勤怠管理SaaS（弊社だとAKASHI）を使っているが、打刻（出勤、退勤）しても本人以外にはその結果が見えない、わからない。 そのため、コミュニケーションツールのSlackでも「出勤したよ〜」となにかしらの報告がチームメンバーに対して必要となる

こんにちは、プロダクトエンジニアのtnagatomiです。 SmartHRではこの度「OSSやっていきの集い」という活動を立ち上げました。私はその活動の運営メンバーの一人です。 このブログ記事では、この活動がどういった経緯で立ち上がり、何のために何をするのか、といったことをお伝えできればと思います。 これまでのSmartHRとOSS貢献、登壇活動 SmartHRではこれまで、OSSガイドラインを公開するなど、会社としてOSSへの貢献を後押ししようとしてきました。 テックブログでも、SmartHRのエンジニアが行ったOSS貢献を紹介してきました。 tech.smarthr.jp tech.smarthr.jp 登壇についても、RubyKaigi 2024にスポンサーとして参加したうえで、その事後勉強会でエンジニアがLT登壇するなど、積極的に取り組んできました。 tech.smarthr.jp

マルチプロダクト戦略の実現を目標として掲げ、急速にプロダクトを増やしているSmartHR。 そのような中、これまでプロダクトごとに分断されていたデータを相互に利用できるようにすることで、価値を高める試みが始まっています。この活動の中心となっているプロダクト連携ユニットに、現状と今後の展開を聞いてみました。 インタビューの様子。左：プロダクト連携ユニット　右：インタビュアー f440： それでは、プロダクト連携ユニットのインタビューを始めたいと思います。よろしくお願いいたします。 一同： よろしくお願いします。 f440： お時間を取っていただきありがとうございます。突然呼ばれてびっくりしていると思うんですけれども、個人的に一番興味あったのがプロダクト連携ユニットだったので、この度はインタビューしたいと思いまして。 最初に自己紹介から始めさせてください。まずは私から。現在プロダクト基盤開発部

普段着用している年末調整Tシャツ。マル扶Tシャツは着すぎて文字がかすれている こんにちは。SmartHR プロダクトエンジニアの宮國(@gongoZ)です。 私は去る5月に誕生日を迎え、ついに40歳となりました。おめでとうございます！ SmartHR に入社したのは2017年9月、つまり33歳でした。時が過ぎるのは早いものです。 良い節目なので、今回は SmartHR で過ごした約7年間を振り返っていきたいと思います。 社内経歴 入社から現在までの、社内で携わってきた業務経歴を一枚絵に起こしてみました。 宮國の社内経歴。これまで3プロダクトに携わってきたが、在籍期間の4分の3が年末調整機能 入社してしばらくは基本機能のタスクに着手していましたが、入社一ヶ月後に声をかけられました。 「年末調整機能、やってみない？」 そこから私と年末調整の関係が始まりました。途中、文書配付機能*1チームに配属

ネタバレ防止のため写真なしアイキャッチにしました こんにちは、SmartHRの@nansekiです。 意外と知られていないのですが、SmartHRのプロダクトサイドはフルリモートOKで、多くの社員が自宅で仕事をしています。フルリモート勤務を支える制度*1には以下のようなものがあります。 リモートワーク環境を整える手当 入社時に25,000円支給 リモートワーク手当 毎月5,000円支給 フルリモート通勤制度 遠方居住者が所属オフィスに出社する交通費は、月2回まで通勤手当ではなく経費精算OK（金額上限なし） 今回はそんなフルリモートで働くエンジニアのデスク環境に迫ります。 コロナ禍で強制的にリモートワークが始まった2020年当時の写真をなぜか奇跡的に持っていた社員がいたので、デスク環境のBefore／Afterをのぞいてみることにしました。 ちなみに私はリモートワークOKにも関わらずほぼ毎日

こんにちは、プロダクトエンジニアの@ksaitoと@tafuです。 SmartHRには共通の趣味の方が集まるSlackチャンネルが数多く存在し、その一つに「#趣味_キーボード」チャンネルがあります。そこでは、新しいキーボードの情報共有や自作しました〜などのコミュニケーションが取られています。 今回は、仕事道具であるキーボードについて、こだわりのポイントや満足していない部分など、プロダクトエンジニアの@asonasさんにインタビューしてきました。 と、その前に我々のキーボードを軽く紹介させてください。 ksaitoのキーボード ksaitoが普段使っているキーボード TOFU60 を使っています。スイッチには、Outemuのサイレントクリームイエローというサイレントタクタイルスイッチを採用していて、ゴールデンウィークにキーキャップを新調しました。こだわりポイントを書くと文量が多くなってしまう

こんにちは! SmartHR プロダクトエンジニアの @sakata と @hypermkt です。 SmartHRではほぼすべてのチームでスクラム開発を行っています。スプリントプランニングとスプリント進行中における課題に対し、私たちのチームでは「予言の書」という取り込みを行っています。本記事では、この「予言の書」の概要とその効果についてご紹介します。 予言の書が必要な背景 スクラム開発で、チームが消化できるキャパシティからタスクを選定したにも関わらず、すべてのタスクの消化ができなかったという経験はありませんか？ 私たちはたくさん経験したことがあります。そこにはスプリントプランニングにおける計画とスプリント進行の難しさがありました。 すべてのタスクが終えられるか不安がある まだ作業タスクには何も着手していないので当たり前ではありますが、チームが消化可能なキャパシティからタスクを選定し、優先

こんにちは。アクセシビリティ本部のアクセシビリティエンジニアの五十嵐です。SmartHRでは主にアクセシビリティテスターが見つけた課題を技術的な観点から改善したり、根本的な問題を解決するための仕組みづくりを担当しています。 さて、Meta が開発する UI ライブラリとして長い間人気を博している React ですが、2024年4月に最新版であるバージョン 19 のRC版が公開されており、注目を集めています。 バージョン 19 では "use client" や "use server" でも知られる Server Components を含む様々な機能が含まれる予定ですが、この記事では、そんな React バージョン 19 をアクセシビリティの観点からキャッチアップし、特に便利になりそうな点や、注意が必要になりそうな点などを見ていきます。 forwardRef が不要になった 仮想 DOM

こんにちは、SmartHRでキャリア台帳の開発を担当しているプロダクトエンジニアのhosoyaです。 今日は、私たちがどのようにPlaywrightを使ってキャリア台帳のE2Eテストを実装しているかについてお話しします。 なぜPlaywright？ E2Eの導入・運用の検討を始めた当時、SmartHRで運用されているE2Eは、Rspec x Selenium x Capybaraが主流でした。 キャリア台帳は新規プロダクトという事もあり、新しいツールの選定をしてもよいのではないかということでチーム内での検討がはじまりました。 採用理由に関しては以前紹介された「E2Eテストを Playwright で作り直して開発プロセスに組み込む話」とほぼ被ってしまうのですが以下のような理由になります。 PlaywrightはMicrosoftから公開されているE2Eテストフレームワーク 定期的な更新と新

はじめに SmartHRで届出書類機能を開発しているqwyngと申します。 今回はSmartHRの届書書類機能において、日本語エイリアスを用いた開発を行ったので紹介します。 背景 SmartHRの届出書類機能は、書類の作成から電子申請の送信までを一括で行うことができる機能です。 ユーザーは画面上で書類に記入するような感覚で書類の作成を行うことができます。 SmartHR届出書類機能の書類確認画面 この体験の実現のために書類のどんな項目にどのような値が入力されたかを永続化する必要があります。 DBのカラム名は英語であるため、開発者は日本語の項目名を英語のカラム名に脳内で変換する必要があります。 この変換が煩わしく、プログラムの修正やレビュー時を含めて開発者の負担になっていました。 そのため、日本語の項目名をそのまま実コードに使えるようにすることを検討しました。 日本語化の是非 日本語の項目名