はてなブックマーク

こんにちは。テクノロジーマネジメント本部でプロダクトセキュリティエンジニアをしているsasakki-です。 2025年1月にプロダクト全体のセキュリティ向上に責任を持つPSIRT（Product Security Incident Response Team）を立ち上げてから、1年が経過しました。 立ち上げ当初のPSIRT立ち上げ時の取り組みを紹介した記事では、プロダクトセキュリティを組織的に強化するための仕組みづくりとして、To-Be / As-Is の整理やプロダクトセキュリティガイドラインの整備、横断的な支援体制の構築に取り組んでいくことをご紹介しました。 本記事では、その1年後の現在地として、進められなかったこと・進められたこと、そしてそこから得られた学びをお伝えします。 初年度の体制 PSIRTはテクノロジーマネジメント本部というプロダクト組織の一チームとして設立しました。一方で

SmartHRでプロダクトエンジニアをしている大澤と申します。この記事では、バックエンドエンジニアである自分がフロントエンドのコードをLLMに頼って実装した際の反省点について紹介します。 現在、LLMはだいぶ良い感じのコードを書いてくれるようになってきています。Claude Opus 4.6が生成したRubyのコードはあまり手直しの必要を感じません。日々驚いています。 ですが、それは自分がRubyとRuby on Railsの知識があるからです。 私はTypeScriptとReactについてあまり詳しくありません。SmartHRでは頼もしすぎるフロントエンドが強い同僚の方々に助けられてコードを書いてきました。 LLMを使えばそれっぽい.tsxを出すことはできます。しかし、フロントエンドの経験に乏しい自分が「良さそう」と思うフロントエンドのコードのレベルは低いです。プロンプトの詳細度やコンテ

こんにちは、SmartHRでアジャイルコーチをしている @wassan です。 「目標に書いた機能は全部リリースした。でも、思ったほどユーザーに使われていない。」 プロダクト開発に携わったことのある方なら、一度はこんな経験をしたことがあるのではないでしょうか。SmartHRでも、組織が急速に拡大する中で同じ壁にぶつかりました。 この記事では、その壁をどう乗り越えようとしたか——チーム目標を「To Do（やるべきこと）」から「To Be（ありたい姿）」へ転換する取り組みについて、背景と学びを紹介します。 後半では、実際にパイロットチームとしてワークショップを実践した開発チームのチーフ nomuson にバトンタッチして、現場のリアルな感想をお届けします。 「To Doリスト化」する目標への違和感 SmartHRの目標設定には、組織拡大とともにある傾向が強まっていました。目標が「やるべきことリ

SmartHRは、2026年2月6日（金）から8日（日）にかけて東京・メルカリ 六本木オフィスで行われた「Bookathon - 本を書くハッカソンイベント」におやつスポンサーとして協賛しました。 本レポートでは、その模様をお届けします。 目次 目次 Bookathon - 本を書くハッカソンイベントとは Day 1 —— キックオフ、チーム編成、環境構築 Day 2 —— 執筆、編集者アドバイス Day 3 —— 執筆、発表会、表彰式、懇親会 最後の追い込み 発表会 審査 表彰式 懇親会 アフターイベント：Technical Writing Meetup vol.48 —— 「Bookathon」ふりかえり＆運営レポート まとめ We Are Hiring! Bookathon - 本を書くハッカソンイベントとは Bookathonは、「いつかは本を書いてみたい」と思っている人たちが集ま

はじめに こんにちは。アクセシビリティエンジニアの tajiman です。 先日、プロダクトエンジニアの morisy さんが「React Hook Form と dnd-kit を使った並び替え可能なフォームの開発」という実践的な記事を公開しました。 dnd-kit は高機能で自由度が高いライブラリですが、さらにアクセシビリティの観点を取り入れることで、より「誰もが使いやすい」状態へと進化させることができます。 本記事では、先日の記事で紹介された実装をベースに、アクセシビリティの品質を向上させるための 3 つのポイントを紹介します。 また、今回紹介する dnd-kit は以下のバージョンで動作確認をしました。 "@dnd-kit/core": "^6.3.1", "@dnd-kit/sortable": "^10.0.0", "@dnd-kit/utilities": "^3.2.2",

こんにちは、プロダクトエンジニアのa2cです！本記事では、日常のライブラリ更新作業の延長線上で、自然にOSS（Open Source Software）へ貢献する機会が生まれた経験について紹介します。 具体的には、テストデータ生成ライブラリである Faker の日本語 locale にデータを追加し、Pull Request を出すまでに考えていたことや判断基準を共有します。 「OSS貢献に興味はあるけれど、なかなか最初の一歩が踏み出せない」という方に少しでも参考になれば嬉しいです！ 本題に入る前に、今回扱ったFakerについて簡単に紹介します。 Faker とは Faker はテストデータ生成ライブラリで、人名や住所、会社名などのダミーデータを生成できます。70以上のlocale（言語・地域設定）に対応しており、日本語を含む各言語に適したリアルなデータを生成できます。Faker の lo

こんにちは。SmartHRでプロダクトエンジニアをしているmatsugenです。 昨今、開発におけるAI活用が随分と進み、開発速度の向上を日々実感しています。一方で、開発速度が上がると Pull Request（以下 PR）の数も増えます。そうなると、レビューの負荷も増大します。 私が所属するチームでは、レビューの負荷を可視化する目的で、スプリント終了時にメンバーごとのレビュー件数がSlackに通知されるようになっています。この記事では、その仕組みをつくるに至った背景と実装のポイントを紹介します。 次から次へとやってくるレビュー依頼 私のチームでは、1週間単位のスプリントで開発を進めています。以前は、実装者が2名のレビュアーをランダムに指定し、実装が完了するたびにレビューを依頼するフローを取っていました。 この運用は、AIコーディングツールの普及でPRの数が増えるまでは、十分回っていました

こんにちは、SmartHR プロダクトエンジニアのB6です。 「基本機能」と呼ばれるSmartHR最大のRailsアプリケーションでは、アプリケーションサーバにPumaを使用しています。 RailsでPumaデフォルトスレッド数が変更されたのをきっかけに、私たちもスレッド数の設定を見直してみたいと思うようになりました。 本記事では、調整の際に行ったこととその結果について共有いたします。 背景 2024年、RailsでPumaのデフォルトスレッド数を減らすための議論が展開されました（Issue #50450）。議論の結果、I/O比率を25~50%とする一般的なRailsアプリケーションでは、スレッド数3が適切ではないかという結論に至りました。 要点をざっくりまとめると以下のようになります。 CRubyでは、GVLが存在するため、同時に1つのスレッドしかRubyコードを実行できない Pumaの

こんにちは、SmartHR のプロダクトエンジニアの横山です！ 今日は、とあるプロダクト開発で実装した巨大な SQL において、一般的な構文（UNIONやJOINなど）の影に隠れがちですが、とても助けになった PostgreSQL の機能を紹介します。 巨大な SQL と聞くと、複雑性や可読性の観点から敬遠されることも多いです。しかし、パフォーマンス要件的に必要に迫られたり、アプリケーション層の複雑さを解消するために、あえて DB 側でロジックを解決し、1 クエリで完結させる選択が必要な場面も、稀にですが確実に存在します。 本記事では、実際のプロダクトコードで活用したテクニックの中から、痒いところに手が届いた機能をピックアップしました。ORM だけでは解決できない課題に直面したとき、あるいはパフォーマンスチューニングをするときの一助となれば幸いです。 目次 複雑なクエリを保守しやすくするた

2025年12月6日(土)に石川県立図書館で開催された「北陸Ruby会議01」に、SmartHRから@ydahと@pndcatが登壇しました！ この記事では、イベントの模様と登壇内容についてレポートします。 会場の石川県立図書館 北陸Ruby会議01とは 北陸Ruby会議01のテーマは、「みんなの Ruby の使い方」でした。 発表者・参加者のいろいろな Ruby の使い方の事例を紹介しあうことで、北陸における Ruby の活用の幅を広げ、Ruby を利活用する人口を増やしたいという思いで開催されました。 発表内容としては Ruby を使って作ったものや企業での Ruby の利用事例など、幅広い Ruby の使い方が紹介されていて、非常に興味深い内容が多かったです。 regional.rubykaigi.org 登壇 SmartHRからは社員が2名登壇しました。各登壇者からコメントをもらい

こんにちは、SmartHRのwattunです。 私は2022年1月にQAエンジニアとして入社し、2024年4月からはQAエンジニアとプロダクトオーナーを兼務してきました。そして2026年1月から、プロダクトマネジメント本部で新しいチャレンジをすることになりました。 入社時点では、「QAエンジニアの役割は品質を守ることだ」と考えていました。しかし、この4年間で、「QAエンジニアの責務」についての見え方は大きく変わりました。品質を守るという役割を超えて、「組織がどう判断し、どう進むか」を支える役割としてQAエンジニアを捉えるようになったのです。 この記事では、これまでの経験を通じてたどり着いた「QAエンジニアの責務」について整理してみます。 次のステージに進む自分自身の棚卸しであると同時に、「QAという仕事にも、いろいろな関わり方がある」と思ってもらえるきっかけになればうれしいです。 この記事

こんにちは。2025年9月にSmartHRへ入社したプロダクトエンジニアのicchanです。 現在はAIインテグレーションユニットで、生成AIを活用した社内問い合わせ対応の効率化に取り組んでいます。 本記事では、社内問い合わせBotの改善プロセスで実践した「2段階DSPy」というアプローチについて解説します。 TL;DR 本記事の要点は次の通りです。 オンライン指標（Good/Bad/Copy）は「正解」に近いが、フィードバックが遅くノイズが多いため、開発のループを回しにくい そこで、オンライン指標を教師データにして、DSPyで「オフライン評価器（Judgeプロンプト）」を学習させ、"高速に実験を回せる物差し"を作った さらに、その物差しを評価関数に組み込み、生成プロンプト自体をDSPy（GEPA）で最適化することで、ユーザーの実感に即した改善を自動化した flowchart LR sub

こんにちは、SmartHRのDPEユニットでエンジニアをしている@alpaca-tcです。 この記事では、Railsで頻発しているけれども見落とされがちな未ログインユーザーのセッションと、その削減方法について紹介します。 目次 目次 未ログインユーザーのセッションとは セッション削減の方法 なぜミドルウェアを使うのか 成果とまとめ 未ログインユーザーのセッションとは Railsではログイン情報等を管理するためにセッションを利用します。 通常はControllerで session にアクセスすることでセッション情報を取得・更新できます。 def create session[:user_id] = @user.id ... end セッションは、CSRF攻撃を防ぐためのトークンを session[:_csrf_token] に格納することにも利用されています。 実はセッションは、csrf_

こんにちは！SmartHR CREユニットチーフの a-know こと井上です。 タイトルにもある "RevOps" というキーワードを、みなさんは聞いたことはありますでしょうか？「レベニューオペレーション（Revenue Operation）」の略称なのですが、私は2025年のはじめくらいに初めてこのキーワードに出会いました。 その単語の意味するところから、なんとなく「CREユニットで働く自分たちにとっても大事そう！」と感じた私は、2026年1月現在でおそらく唯一となる、RevOps について日本語で書かれている書籍『RevOpsの教科書』を読みました。 www.shoeisha.co.jp そしてその直感通り、「RevOpsは、SmartHR の CRE のミッションにも大いに関係することだ！！」と感じることが非常に多く書かれている一冊であることがわかりました。ということで今回は、私が

こんにちは。課金基盤チームのyurikoです。2026年もやってきました。新年を迎えて心機一転、身の回りを整理整頓・大掃除したくなりますよね？ 今回はGemfileにいつの間にか追加されていたGemを「掃除」した話をしたいと思います。 それはDependabotの作ったPRからはじまった 私の所属している課金基盤チームでは、Ruby on Rails製の社内向けアプリケーションを開発しています。このアプリのリポジトリでは、Dependabotによって定期的にGemアップデートのためのPull Request（以下、PR）が作成されるようになっています。 いつものようにGemアップデートのPRを確認していた私は、見慣れないGemのアップデートPRを目にしました。それはnet-imapというGemでした。 net-imapとは net-imap GemはIMAPのクライアントライブラリです。サ

この記事はSmartHR Advent Calendar 2025の4日目の記事です。 こんにちは、UXライターのhebikoです。SmartHRのUXライターは、「UI文言やヘルプページを作成する」ほか、「開発チームがUI文言やヘルプページを作成するための支援をする」役割を持っています。 UXライター自身が書くだけでなく、「開発チームがUI文言やコンテンツを作成できるよう支援する」という役割に疑問を持つ方もいるかもしれません。これは、各チームの人数を必要以上に増やさず、コミュニケーションコストを抑えることで、デリバリー速度を維持することが狙いです。ユーザーに価値を早く届けるために、UXライターがチームに常に参加していなくても、開発チーム自身がフィーチャーリリースに必要な文言やヘルプページを作成できる状態を目指しています。 この記事では、「開発チームがUI文言やコンテンツを作成するための支

はじめまして、ydahです。読み方が分かりづらいIDですが、「わいだー」と読みます。私は2025年11月にSmartHRに入社しました。 今はプロダクトエンジニアとして、SmartHRの外部サービス連携基盤を開発しています。 私はRubyというプログラミング言語や、Ruby周辺で育まれているコミュニティが大好きです。生まれも育ちも大阪で、Kyobashi.rbという大阪の京橋を拠点にしたRubyコミュニティの主催もしています。 2024年からは大阪Ruby会議や関西Ruby会議のチーフオーガナイザーを務めています。 趣味としてオープンソースソフトウェアの開発を行っており、Rubyコミッター、Ruby製のLRパーサージェネレーターであるLramaのコミッターとして、主にRubyの構文解析器の改善に取り組んでいます。 その他にも、rubocop-rspecやcommittee、rspec-si

こんにちは！SmartHR スキル管理チームでプロダクトエンジニアをしている @oku_yu です。 私たちは日々、ユーザーの課題解決につながるフィーチャー開発に取り組んでいます。しかし、特に不確実性の高いプロジェクトにおいて、何度も同じ壁にぶつかっていました。 本記事では、プロジェクトのスムーズな進行を阻む壁を乗り越えるべく、開発サイクルの中にDesign Docを取り入れたので、そこで得られた学びを紹介します。 プロジェクトのスムーズな進行を阻んだ壁 Design Doc導入前、私たちのチームには次のような課題があり、「プロジェクトがスムーズに進まない」状況を生み出していました。 プロジェクト中盤での「設計の巻き戻し」 開発がある程度進行し、実装の深い部分に入ってから「あれ？この仕様、どうするんだっけ？」という疑問が噴出し、根幹の設計に立ち戻ることがしばしば発生していました。これが工数

こんにちは、kinoppydです。SmartHRは、Kaigi on Rails 2025のブースで早押しクイズを提供しました。Rails/Ruby/Kaigi on Rails/SmartHRに関するクイズがランダムに出されて、2問正解で優勝、2問間違いで失格という形式での実施でした。2マル2バツと呼ばれるやつですね。 SmartHRは本日もKaigi on Railsのブースでお待ちしております😀 早押しクイズもありますよ💡 ぜひ遊びにきてください〜！！#kaigionrails #kaigionrails_booth pic.twitter.com/a0IUYTkiw1— SmartHR Developers (@smarthr_dev) September 27, 2025 今回私が作ったのは、出題するクイズと、出題用の問題を出題者間で同期するためのアプリと、早押しボタンです。

こんにちは、SmartHR 品質保証本部のtarappoです。 品質保証部から品質保証本部へ 2025年10月1日から品質保証部は「品質保証本部*1」となりました。 本記事では、その背景と意図について説明します。 具体的には以下の２点です。 「本部」となった理由 「本部化」に伴う労務ユニットの再編 なぜ「本部」となったのか 今回の「本部化」の目的を簡単に説明します。 「本部化」は、ボトムアップの文化を大事にしつつも、組織としてより広く・深く動けるようにするための一歩です。 これによって、短期的な改善だけでなく、中長期的な視点での品質戦略や改革が進められるようになります。 これまで品質保証部は、部としての全体の動きは進めつつも、各ユニットや各メンバーのボトムアップの取り組みを主に積み重ねながら、プロダクトごとの品質課題に取り組んできました。 しかし、組織全体がスケールしていき、開発組織全体は

こんにちは！SmartHRで基本機能の開発をしているNGT（ながた）です。 先日、第12回SmartHR LT大会が開催されましたが、年に一度の特別編「自由研究発表会」ということで大変盛り上がりました。 今回は、そのLT大会で私が発表した自作ゲーム機&自作ゲームを紹介します！ 完成した自作ゲーム機とゲーム 作成した自作ゲーム機・自作ゲームをそれぞれ紹介します。 自作ゲーム機の紹介 今回制作したのは、Raspberry Pi Zero 2 Wを元にした携帯ゲーム機「NGT2」です。 作成したゲーム機 私（NGT）自身をNGT1として、第2世代の意味を込めてNGT2と命名しました（実際にはSwitch2にあやかった形です）。 3Dプリンターで作成した筐体にバッテリーが組み込まれており、携帯ゲーム機として動作します。 自作ゲームの紹介 ゲーム機上で動作するゲームはRubyで開発しました。 Sma

こんにちは、プロダクトエンジニアのkitazawaです。 私が所属するチームは、SmartHR最大のアプリケーションである基本機能の技術的課題の解消を進めています。 本記事はその中の一つである、履歴の適用日を日付化したデータ構造の変更プロジェクトをご紹介します。 これから大規模なテーブル構造の変更を考えている方の参考になれば幸いです。 履歴の適用日とは プロジェクトの説明の前に、まずは「履歴の適用日」について説明します。 履歴の適用日は、従業員情報やマスターデータの変更が、システム上で有効になる日付を指します。部署の異動日や、役職の変更が適用される日などが該当します。 たとえば、「従業員の所属部署が部署Aから部署Bに変更された」履歴の適用日が2024/04/01であれば、2024年4月1日から部署Bに所属していることを意味します。 また、その後に「従業員の所属部署が部署Bから部署Cに変更さ

探索的テスト補助用テストケースの自動生成 ー 使用したLLMプロンプトもご紹介 勤怠管理機能チームでQAエンジニアをしているringoです。 勤怠管理機能の開発では、1つの大きな単位での機能を複数のProduct Backlog Item(以下、PBI)に分割し、リリース前に「フィーチャーテスト」という、機能全体の探索的テストを行なうフェーズを設けています。ここで言う探索的テストは、テスト実行者が機能を実際に操作しながら、事前に定義されていない観点や課題を能動的に発見していくテスト手法を指しています。 今回は、このフィーチャーテストのフェーズにおいて、Clineを用いて探索的テストの補助となるテストケースを生成する取り組みについてご紹介します。 勤怠管理機能チームの状況と開発プロセス 勤怠管理機能チームで行なっているフィーチャーテストは、1つの大きな単位での機能(フィーチャー)全体に対して

こんにちは、届出書類チームでエンジニアをしているkidaです。 この記事では、開発生産性の計測ツール導入をきっかけに、私たちのチームがどのようにして改善サイクルを確立していったのかをお届けします。 月イチで実践している「ふりかえり」の具体的な取り組みや、そこから生まれた数々のTryについてご紹介します。 Findy Team+導入で見えたチームの「なんとなく」な課題感 私たちのチームには現在エンジニアが6人在籍しています。 6人でも多いですが、かつては9名在籍していた時期もあり、「多数のエンジニアを抱えるチーム」として、生産性が事業の成果に直結する重要な役割を担っています。そのため、以前からチームのパフォーマンスについては関心が高かったのですが、ツール導入以前は定性的な議論が中心でした。 「しばらく残っているPull Requestがある気がする」 「バーンダウンに向けて頑張ってレビューし

こんにちは、inaoです。 今回は、みんなで協力してテックブログにイベントレポートを増やした取り組みをお伝えします。 そこで使っているイベントレポートの簡単なひな型もご紹介してはいるのですが、基本的には「私たちのがんばりを見てください！」という記事です。 目次 目次 記録がなく、年間のイベントまとめ記事を出せない…… イベントレポートを書こう！ 結果発表！ 2024年上期 2025年上期 RubyKaigi関係 2024年上期 2025年上期 社内イベント関係 2024年上期 2025年上期 レポートのひな型 まだ伸びしろもあります まとめ We Are Hiring! 記録がなく、年間のイベントまとめ記事を出せない…… はてなさんに憧れて、2024年の年末に、年間のイベント／協賛系のまとめ記事を出そうという話が挙がったのですが、「そもそも何やったっけ……？」状態になって断念しました。 R

SmartHRに最近ジョインされたプロダクトマネージャー（以下、PM）のhamamuさんにインタビューしてきました。新天地でのスタートダッシュの切り方や、hamamuさんがSmartHRにたどり着くまでの経緯など盛りだくさんです。ぜひご覧ください。 SmartHRの「データの持ち方」を再考する —— まずはかんたんな自己紹介をお願いします。 プロダクト基盤領域でPMをしているhamamuです。SmartHRには2025年4月に入社したので、いま4ヶ月と少し経ったくらいです。 大学の頃からインターネットに興味があり、職種はエンジニアからプロジェクトマネージャー、プロダクトマネージャー、経営、そしてまたプロダクトマネージャーと変遷がありつつも、一貫してIT業界で経験を積んできました。プライベートでは静岡県に住みながら、3児の父をやっています。 —— ご担当のプロダクトについても教えてもらえます

こんにちは、SmartHR プロダクトエンジニアの B6 です。 「SmartHR 最大の Rails アプリケーションで YJIT を有効化しました」の記事を投稿してから 5 ヶ月ほど経ちました。 その後、「基本機能」と呼ばれる SmartHR 最大の Rails アプリケーションでは Ruby、Rails のアップデートを行いました。 本記事では、YJIT を主題に、Rails・Ruby アップデートと YJIT によるパフォーマンス変化について共有いたします。 アップデート後の環境 アップデート後の Ruby、Rails のバージョンは以下の通りです。 Ruby 3.4 Rails 7.2 Rails アップデートによる YJIT 有効化方法の変更 Rails は、以前の記事執筆時点の 7.1 から、7.2 にアップデートしました。 Rails 7.2 では Ruby 3.3 以降を

キャリア台帳チームでエンジニアリングマネージャーをしている溝渕です。 私が所属するSmartHRでは、多くのチームでスクラム開発を採用しており、労務ドメインではScrum@Scaleの運用も開始しています。ちなみに、どの程度スクラムが採用されているかと言うと、スクラムとか色々やめましたというブログが出るぐらいには普及しています。 そんな中、キャリア台帳は2024年2月にリリースされ、2024年9月からスクラム開発をスタートさせました。 この記事では、もともとスクラムを取り入れたいと思っていたわけではないキャリア台帳チームが、どのような軌跡を辿ってスクラム開発へ移行したのかお伝えします。 キャリア台帳チームでスクラムを採用していなかった背景 最初に、SmartHRでは多くのチームでスクラム開発を採用しているにもかかわらず、キャリア台帳チームでは採用していなかった理由をご説明します。私の入社前