サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
tech.smarthr.jp
このエントリは、SmartHR Advent Calendar 2023 シリーズ1の5日目の記事です。 こんにちは!SmartHRでプロダクトエンジニアをしている大澤(@qwyngg)です。 最近Railsの自動テストの高速化について調べていたので、その内容をまとめてみました。 主にtest_profというgemを用いた解析と、その結果を元にした改善方法について書いています。 test_profとは https://github.com/test-prof/test-prof テストのパフォーマンスを分析する様々なツールを提供するgemです。 色々機能があるのですが、今回は以下の機能を使って発見した問題とその解決方法を紹介します。 factory_botプロファイラ テストに対してstackprofを(面倒な設定無しで)実行できる 詳しい使い方はTestProf: Ruby tests
こんにちは!エンジニアリングマネージャの 吉成 です。 この記事は SmartHR Advent Calendar 2023 4日目の記事なのですが、実は ANDPAD さんの Advent Calendar 2023 1日目 とまさかのネタ被りです。 この日のために 後回しにしていた 寝かせていたネタだったので、二番煎じとなりますがこのまま出させていただくことにしました 😌 背景 さて、弊社では今年の5月から、各プロダクトチームが週ごとに持ち回りでテックブログを執筆する取り組みを開始しました。 元々は執筆のためのフローは特に整備しておらず、公開までの壁打ちやレビューといったものは有志の方にすべておまかせしておりました。 今年の8月に DevRel の1人目として inao san が入社され 1、テックブログの担当チームやレビューなど諸々の業務を引き継いでいる中で、組織でのはてなブログ
2023年夏、SmartHRでDevRel(Developer Relations)が始動しました! SmartHRのDevRelは生まれたてほやほや。会社、そして担当者自身にも経験や知見がありません。 そこで、他社で積極的に活動をされているDevRelの先輩がたをお招きして座談会を開催しました。 前編に続く後編では、社内の関係づくりや、社内イベント、DevRelとして仕事するうえで最も大切なこと、立ち上げ時にやるべきことについてお話をうかがいました。 (座談会は2023年9月に行いました。内容は当時のものです) 目次 目次 座談会メンバー 櫛井優介さん(以下、941) 杉田絵美さん 玉田大輔さん 聞き手:稲尾尚徳(以下、inao) 社内の関係づくり 社内イベント DevRelとして仕事するうえで最も大切なこと DevRel立ち上げ時にやるべきこと メンターになってくださいますか? 座談会
2023年夏、SmartHRでDevRel(Developer Relations)が始動しました! SmartHRのDevRelは生まれたてほやほや。会社、そして担当者自身にも経験や知見がありません。 そこで、他社で積極的に活動をされているDevRelの先輩がたをお招きして座談会を開催しました。 前編では、DevRelとは何かや、活動の成果とその計測方法、体制、予算についてお話をうかがいました。 (座談会は2023年9月に行いました。内容は当時のものです) 目次 目次 座談会メンバー 櫛井優介さん(以下、941) 杉田絵美さん 玉田大輔さん 聞き手:稲尾尚徳(以下、inao) 自己紹介 そもそもDevRelって? 活動の成果とその計測 DevRelの体制 DevRelの予算 座談会メンバー 櫛井優介さん(以下、941) LINE株式会社(現LINEヤフー株式会社) Developer R
こんにちは、SmartHRで一人目のDevRelのinaoです。 SmartHRにDevRelを立ち上げる際に、社内に向けて書いた文章を公開します。 次の座談会もあわせてあわせてご覧ください! 教えて先輩! DevRelの立ち上げ方(前編)活動の成果と計測、体制、予算 - SmartHR Tech Blog 教えて先輩! DevRelの立ち上げ方(後編)社内の関係づくり、社内イベント、最も大切なこと - SmartHR Tech Blog DevRelを立ち上げます DevRelとはなにか DevRel(Developer Relations)は、「開発者をつなぐこと」を目的とします。 開発者をつなぐことには、次の3つが含まれます。 SmartHRの開発者と外部の開発者をつなげる SmartHRの開発者どうしをつなげる SmartHRのプロダクトと内外の開発者をつなげる なんのためにやるの
こんにちは、SmartHR でプロダクトエンジニアをしている @nabeliwo です。 今年の9月に SmartHR のログイン後のホーム画面がリニューアルされました。 【9/21更新】新しいホーム画面を公開しました | SmartHR|シェアNo.1のクラウド人事労務ソフト この記事では、新しいホーム画面の実装の中で、開発者体験を損なうことなく多言語化対応を進められるよう、TypeScript の型定義を工夫した話をします。 まだまだ改善の余地がある状態ではあるのですが、私達のチームでの試行錯誤が読んでくれた方の参考になれば幸いです。 SmartHR の多言語化対応 SmartHR の既存のページではすでに WOVN.io というツールを使った多言語化対応が行われていました。 ただ諸々の理由があり1、新しいプロダクトでは自前で翻訳の仕組みを用意していこうとしています。 実際に、Smar
こんにちは。SmartHRで文書配付機能の開発しているプロダクトエンジニアのkekkeです。 私が所属しているチームではインフラにGoogle Cloudを採用しており、ウェブ アプリケーションをCloud Run 上に構築して外部へのアクセスはCloud NATを経由して行っています。 この記事ではCloud RunとCloud NATを組み合わせた時の「インスタンスあたりの最小ポート数」の適正値について調査した内容を紹介します。 背景 ある日Cloud NATのVMあたりの使用ポート数が増加して、このままだとCloud Runから外部にアクセスできなくなってしまうため対策を打つ必要がありました。 Google Cloudのドキュメントを確認したところ「インスタンスあたりの最小ポート数」を上げることで解決することがわかったのですが、以下のような疑問が生まれチーム内では腑に落ちない雰囲気を
こんにちは、プロダクトエンジニアのゆきです。SmartHRには2021年2月に入社しました。 入社した際は東京に住んでいましたが、現在は大阪からリモートで働いています。 私が入社した頃は、フルリモートワークは許可されておらず、東京オフィスに通勤できる場所に住んでいる必要がありました。 2021年の7月にフルリモートワークが解禁され、日本国内ならどこに住んでいても働けるようになりました。 フルリモートワークになって2年以上が経ったSmartHRですが、今回はSmartHRのプロダクトエンジニアが、どのような働き方をしているのかを紹介します! 制度について プロダクトエンジニアグループにおける2023年11月現在のSmartHRのリモートワークの制度について、概要を紹介します。 詳細はSmartHRの働き方制度(2023年7月〜2024年12月)をご覧ください。 交通費 東京近郊に居住している
SmartHRのプロダクトマネジメントグループ(以下、PMグループ)は2023年11月現在、総勢23名。うち5名が2022年入社、4名が2023年入社と順調に組織を拡大していますが、特にここ最近、CPOや事業責任者を経験したハイレイヤーの方が相次いでジョインしてくれています。 その背景を解き明かし、採用活動における再現性をつくりたい。そんな考えから今回は「今のSmartHRに経験豊富なPMが入社する意義、面白さ」の解像度を上げるべく、PMグループの松栄友希さん、武政成彦さんにお話をうかがいました。PMの統括や経営レイヤーでキャリアを培ってきたお二人ならではの鋭い視点でSmartHRを吟味してもらった座談会は、パンチライン盛りだくさん。ぜひ最後までお付き合いください! 登場人物の紹介 松栄 友希(@bae) クリエイティブ職、マーケティング職を担当後、株式会社リブセンスに入社し「転職ドラフト
こんにちは、SmartHR の人事評価機能を開発しているエンジニアの takata と nakano です。 SmartHR の人事評価機能は、評価テンプレートと評価プロジェクトを用いて、柔軟な人事評価が可能なウェブアプリケーションです。人事評価の担当者は、評価テンプレートで評価の流れと項目を設計し、評価プロジェクトで評価業務を実施します。評価対象者や評価者は、評価シートの入力や提出などができます。 先日、この人事評価機能のアクセシビリティ試験を行い、いくつかの改善点を見つけました。改善点の内容と今後の対応について共有したいと思います! アクセシビリティ試験の概要 Web Content Accessibility Guidelines(以下 WCAG) 2.1 を参考に試験しました。 WCAG 2.1 はウェブコンテンツをよりアクセシブルにするためのガイドラインです。ウェブコンテンツをア
2023年8月22日にリリースしたSmartHRの最新プロダクト「スキル管理」。 実は、リリース時チームメンバーの3分の1、数にて4名がSmartHR入社半年以内のメンバーであり、しかもそのうち3名は配属時期が6〜7月とリリースの直前! 今回は、そんなスキル管理の「入社半年〜ズ」に集まってもらい、リリース後の心境や、SmartHRについて感じていることについて語ってもらいました。 また、先日実施されたイベント「0→1をスクラムでやってみた -スキル管理機能の作り方- - connpass」では、新規プロダクトリリースに至る苦労や知見が、リリース時スクラムチームメンバーから選ばれた6名によって披露されたので、ぜひ資料をチェックしてみてください。 higashi173 大学卒業後、第三者検証の会社にQAエンジニアとして入社。1年ほど在籍したのち、ポテンシャル採用のQAエンジニアとして2023年
近年ますます重要性が高まる情報セキュリティ。 クラウド人事労務ソフトを扱うSmartHRにとって、お客さまに選ばれ続けるためにもセキュリティ体制の強化は欠かせません。SmartHRのセキュリティマネジメントの現在地や、今だからこそ感じられるやりがいについて、2022年に入社しセキュリティユニットで働く2人に聞きました。 佐々木さん(@sasakki-) MSS(Managed Security Service)からクラウドサービスの開発、小売業のセキュリティ担当を経て、2022年4月にセキュリティエンジニアとしてSmartHRに入社。 中西さん(@nakanishi_a.k.a_doc) 複数のIT企業にて、全社的なセキュリティ体制の構築、インシデント対応などのセキュリティマネジメント業務を経験。2022年8月、情報セキュリティマネージャーとしてSmartHRに入社。 会社全体のセキュリテ
こんにちは!SmartHR基本機能でプロダクトエンジニアをしているdooorです。 SmartHRでは履歴を表すデータモデルにBitemporal Data Modelを採用していて、Active Recordで扱うために ActiveRecord::Bitemporal を開発しています。 BiTemporal Data Modelとは、データを「有効時間(データが現実世界で有効である期間)」と「システム時間(データがデータベースに格納された時間)」の2つの時間軸で管理する方法です。変遷するデータの履歴を残すことができ、ある時点のデータを一覧することや過去の情報を更新することが可能になります。BiTemporal Data Modelが気になる方は 操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践 をご一読ください。 ActiveRecord::B
こんにちは!SmartHRで配置シミュレーションの開発を担当している、プロダクトエンジニアの @tommy6073 です。 今回は、最近チームで実践してきた「ホメと感謝」にまつわるお話をご紹介します。ちなみにSmartHRにおいて、ホメとは褒めることを意味しています。 ホメ祭り 2023年8月上旬に、チームで「夏のホメ祭り2023」と題して、互いのホメやチーム・プロダクトで達成したことを伝え合って自己肯定感を高め合う会を開催しました。 元々はSmartHRの別チームが行っていたものを、これは良いとメンバーの1人が私たちのチームでもやろうと企画・開催したものです。 ホメ祭りのやり方としては、事前準備として、オンラインホワイトボードツールのMiro上に、各メンバー、チーム・プロダクトの枠を用意し、各メンバーはそれぞれの枠にホメを記入した付箋を貼っておきます。 そして当日に、冒頭で、会の目的と、
こんにちは!SmartHRで人事評価機能の開発を担当している、エンジニアのkanekoです。Visual Regression Testを導入して、安心・安全にUIライブラリのアップデートやリファクタが行える環境を整備したので、その取り組みをご紹介します。 「Visual Regression Test 」とは変更前と変更後のコードで対象画面のスナップショットを比較することで、発生したUIの差分を検知して、見た目のリグレッションが発生していないかを検証するフロントエンドのテスト手法の一種です。 差分検知のイメージ Visual Regression Testを導入するに至った経緯 チームの課題感 私達のチームでは、意図しないレイアウト崩れなどの確認にかなりの手間と時間を取られる問題に悩まされていました。 外部ライブラリをRenovateを使って自動更新するようにしているのですが、リリース前
こんにちは!SmartHRの基本機能を開発しているsushi__melodyです! 今回は、スプリントゴールを策定・活用できていなかったチームが、不完全でもスプリントゴールを作り始めたことで、ステークホルダーとのコミュニケーションが改善して、しかもスクラムのプロセス自体がユーザー価値を中心に回り始めたよ、というお話です。 スプリントゴールの導入の背景 スプリントゴール導入直前のわたしたちのチームはスクラムにそれなりに慣れてきて、プロダクトの改善もプロセスの改善もリズムよく着実にすすめられている実感がもてている状態でした。 一方で、各スプリントでステークホルダーからの協力を仰いだり、チーム外に対して「実現したい価値に対してわたしたちがどこにいるのか」が伝えられないことが課題となっていました。 たとえば、スプリントレビューのタイミングで「今後の機能開発の展望」と「今スプリントで行ったこと」をス
はじめに こんにちは!プロダクトマネージャーのhajiです。2023年7月に入社したばかりです。年末調整機能の開発に携わっています。この記事は「入社してからの感想でも書いて」と言われたので書いています。っていうとイヤイヤ書いてそうですが、実は中身がない話をダラダラ書くのは好きなので、まんざらでもない気持ちで書いてます。中身がない話を書いてって言われたわけではないので、期待値調整をミスっている可能性はあります。あえてこのまま書いていきます。 さて、月曜の朝、って言われると、なんとなく憂鬱なイメージですよね(ですよね?)唐突に雑学をひけらかしておくと、英語では憂鬱な月曜日をBlue Mondayっていうらしいです。Black Fridayは大安売りの日なのにね。ブラック企業っていうくらいなんで、個人的には青より黒の方がこわい。 いきなり話が逸れましたが、表題のとおり、ぼくは最近月曜日がつらくな
SmartHRでプロダクト開発に携わっているエンジニアは104人(※2023年8月1日時点)。そのうち女性は10人しかいません。スクラムチームは15以上あるため、女性エンジニアはチームに1人いるかいないかという状況。 そこで今回、チームの垣根を越えて女性同士で語り合ってみよう!ということで、女性エンジニア座談会を開催しました。 日頃の悩み、開発組織の課題…赤裸々にトークするなかでわかったのは「みんな同じことを思っていたんだ…!」ということ。本記事ではそのトーク内容の一部を公開します。 談笑する参加メンバーたち 参加メンバー紹介 cidermitaina 2019年9月入社。SmartHRオプション機能の開発を担当。音楽と紅茶とポメラニアンが好き。 16bit_idol 2019年12月入社。SmartHR基本機能の開発を担当。SEGA好きで、特にメガドライブが大好き! 子育てのため時短勤務
こんにちは。プロダクトエンジニアのkuritaです。普段はSmartHRの届出書類機能の開発をしています。2023年の2月に入社したのですが、いつのまにか半年が経っていました。半年って体感短いですね。 今回は、RSpecをリファクタリングした際の取り組みについてまとめました。 テストコードの読みづらさに課題を感じ、まさに今リファクタリングに取り組んでいる方の参考になれば幸いです。 RSpecを読んでいくなかで感じた課題 チームに入って少し時間が経ったころにアプリケーションの仕様がとても難しいことに気づきました。また、テストコードが読みづらいことで時間が掛かってしまい、仕様の把握も大変になっていました。そこで、仕様をキャッチアップするだけでなく、テストコードをより良い状態にすることも目的として、リファクタリングを進めることにしました。 Example groupが長すぎる 私たちが開発してい
こんにちは!SmartHRで基本機能の開発を担当している、エンジニアのwakasaです。2023年の1月から半年かけて、自チームのテストフロー見直しを行い、実装時間を大幅に増やすことができました。今回はその取り組みをご紹介します。 見直し前のチームの状態 私の所属するEチームは、SmartHRの基本機能の中でも、従業員情報やマスターデータの履歴データ管理周りの機能開発を主に担当しています。2023年8月現在、エンジニアが6名、プロダクトマネージャーが1名、プロダクトデザイナーが1名所属しており、QAエンジニアは所属していません。以前はQAエンジニアがチームに所属していましたが、2022年10月にチームを離れました。QAエンジニアがチームを離れたあとはエンジニアがテスト業務を兼務しています。 今回の取り組みを始めるきっかけとなったのは、2022年の年末に実装にどのくらい時間を使えているのか計
みなさん、はじめまして!プロダクトエンジニアのkitahiraです。 2022年12月にSmartHRに入社し、基本機能の開発を担当するDチームにジョインしたんですが、いつの間にか半年以上たっていました。早いものですね。 Dチームでは、Google Apps Script(以下GAS)を使った色々なツール達がチームのために仕事をしてくれています。この記事では、それらのツールに対していくつかの改修をして、業務体験がこんな風に良くなったよ〜という話をまとめてみました! 担当表 Dチームでは、スクラムイベントのファシリ・議事録や、その他の定例的な業務を当番制で回しており、その当番表をGoogleスプレッドシート(以下スプシ)で管理してます。 ローテーション表(hogeとか書いてある部分は実際は個人名です) 当番表 ローテーション表を参照して、GASが自動的に当番表の担当者を埋めてくれるスプシです
こんにちは、プログラマーのkinoppydです。最近はSmartHR内でのプロダクトを横断して開発を行うプロダクト基盤チームというところで仕事をしています。 tech.smarthr.jp GraphQL集めるマンの概念図 分散したプロダクトの課題 SmartHRは、祖業である労務管理と従業員情報を集約している「基本機能」と呼ばれる巨大なアプリケーションと、その「基本機能」にある従業員情報を使い文書配布、年末調整、タレントマネジメントなどを行う小さなアプリケーション群によってサービスが提供されています。各アプリケーションは完全に独立したリポジトリとデータベースを持っており、「基本機能」とのデータのやり取りには公開・非公開のREST APIを利用しています。 SmartHRのプロダクト間の構成概略図 APIで繋がれた基本機能とサービスの世界観には、一つ問題点があります。それは、複数のサービス
まえがき こんにちは!SmartHR 基本機能の B チームで開発をしている@ron です。 今回は、私の所属する B チームで品質と開発効率の向上のため Jest を導入するにあたり、チームで行った議論と導入した結果をご紹介します。 Rails を使用している SmartHR では RSpec を使用してテストを実施していますが、テストが増えるにつれて CI での実行が非常に遅くなることが課題となっていました。 Jest を導入したことで、テストの網羅性が上がり、テストパターンを増やしつつ、テストの実行時間の増加を抑えることができました。 また、Jest を導入するにあたり、Jest と RSpec それぞれでどういったテストを書くべきか、どういったテストを書かないべきかを議論し、整理したので、その内容もお話しします。 SmartHR のプロダクト規模について SmartHR は、企業情
こんにちは。プロダクトエンジニアのkitazawaとqwyngです。 先日SmartHR基本機能のRubyバージョンを3.0から3.1にアップデートしました! SmartHR基本機能では開発をLeSSで行っていますが、Rubyのアップデートは開発チーム内の有志のメンバーで実施しています。 その際にいくつかあった問題とその解決方法について紹介しようと思います。 Ruby 3.1へのアップデートを開始 まずはじめにRuby 3.1でCIを実行してみました。キーワード引数の対応などが大変だった3.0のアップデートに比べると失敗しているテストは少なく、修正の時間はあまりかかりませんでした。 そのため、すべてのテストが成功するようになるまでは苦労することなくすんなりと進めることが出来ました。 最初の問題 CIは通るようになったので動作確認をするため、staging環境にデプロイしようとしました。が、
こんにちは、SmartHRでプラットフォーム事業でプロダクトエンジニアをしている @otakky です。 今回は、プラットフォーム事業でハッカソンを開催したので、その進め方や様子を紹介したいと思います! ハッカソン開催のきっかけ そもそもなぜハッカソンをやることになったのか? 答えは「楽しそうだから」です。 ウソです(3割くらいは本当です)。 目的をお話しするために、少しプラットフォーム事業について説明させてください。 「プラットフォーム」と聞くと、DevOpsやインフラ設計などに関わりそうなイメージがありますが、弊社のプラットフォーム事業は、SmartHRというサービスのプラットフォーム化を促進することを目的としています。 と言っても「何をやっているかサッパリわからん!」という方もいると思いますが、そんな方はぜひ下記の記事を読んでみてください(宣伝)。 tech.smarthr.jp 上
こんにちは。VP of Engineering の森住です 今回は、2022年1月に SmartHR の CEO に就任した芹澤さんが、なぜか最近になって SmartHR の開発チームにイチメンバーとして二週間ほど参加していたので、一体なにがあったのかとインタビューを敢行してまいりました いつの間にか CEO をクビになっていたのでしょうか? 気になりますね それでは、今回のインタビューの登場人物をご紹介します 登場人物 SmartHR 代表取締役CEO 芹澤さん 2016年2月に SmartHR に入社。VPoE、CTO を経て2022年1月に CEO に就任。CEO 業に専念していたかと思いきや、いつの間にか SmartHR の開発チームにイチメンバーとして参加していた 芹澤メンバーを受け入れるチームのマネージャー 山本さん 2020年10月に SmartHR に入社。SmartHR
こんにちは!SmartHRで文書配付機能の開発を担当している、aanzaiです。 2022年末から2023年2月にかけて、文書配付機能で使用しているPDFのレンダリングライブラリの置き換えを行ったため、具体的にどのように移行したかをご紹介します。 文書配付機能の紹介 文書配付機能(旧:雇用契約)は、SmartHRの最初のオプション機能として開発された機能で、事前に作成した書類テンプレートをもとに、SmartHRに保存された従業員情報を差し込んで書類PDFを作成し、従業員に配付したり、契約書として合意を取ったりすることができる機能です。 書類テンプレートのレイアウトは、ユーザーがWYSIWYGエディタで作成したものがHTMLとして保存されています。書類を配付する際は、このレイアウトHTMLに従業員情報を差し込み、PDFに変換します。 PDFレンダリングライブラリ移行の理由 文書配付機能では、
SmartHRでは開発にRuby on Railsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。 Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと
こんにちは! SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。 突然ですが、皆さんのチームの生産性は高いでしょうか? この議論を始めると必ず直面する壁が、そもそも生産性とは何か?です。 生産性を上げようとする際の効率化の考え方には、リソース効率とフロー効率という2種類の考え方があります。 そしてSmartHRでは、特にフロー効率の方を重視しています。 そこで本記事では リソース効率/フロー効率とは何か なぜSmartHRはフロー効率を重視しているのか について解説していきます。 リソース効率とフロー効率 リソース効率とは リソース効率とは、リソースの稼働率のことです。 リソース効率を高めるということは、リソースに空きがあればタスクを与え、全員が何かしら手持ちのタスクがある状態を作ることになります。 手が空いてる人を作らないという至って普通の考え方なの
次のページ
このページを最初にブックマークしてみませんか?
『SmartHR Tech Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く