こんにちは、プロダクトデザイナーの @uknmr です。昨日に続き SmartHR UI に関する話を書きます。ええ、そう。今日はやや社内に向けて書きます。アドベントカレンダー14日目? 知らない子ですね。我が家にクリスマスの概念はないので、そんなものはありません。 SmartHR UI の目的とは? ブランド観点から UI を揃えたい、一貫したユーザー体験*1を提供したい、という気持ちから生まれた SmartHR UI ですが、本当ですか? 我々は本当に UI を揃えるためだけにコンポーネント集を手入れしていますか? 共通コンポーネント集があれば、それを使い続けさえすれば UI が揃っていくのは必然です。「揃えたい」という気持ちは「誕生した瞬間に達成された」とも言えます*2。 では、何のために自前でコンポーネント集を手入れし続けているのでしょうか? 私はそれを「SmartHR というプロ

こんにちは！フロントエンドエンジニアの髙田です！ 先日 @diescake から SmartHR UI の運用についての紹介がありました。 tech.smarthr.jp 今回は SmartHR のフロントエンドエンジニアがプロダクト開発以外で何をやっているのかを紹介したいと思います！ SmartHR のエンジニアの特徴 SmartHR のすべてのエンジニア（フロントエンド・バックエンド）にはそれぞれ担当のプロダクトあります。 普段は担当プロダクトを爆速かつ高品質に開発できるよう自身の仕事に注力しています。 横断組織はありますがその組織にフルコミットすることはありません。 横断組織のひとつであるアジャイル推進室（仮）を紹介する記事もあります。ぜひご覧ください！ tech.smarthr.jp もちろん、フロントエンドエンジニアにも担当プロダクトがあり、日々プロダクト開発に集中していると次の

こんにちは、念願の高級水拭き兼用ロボット掃除機を買ってほくほくなプロダクトデザイナー@kgsiです。 ※ この記事は、SmartHR Advent Calendar 2022の13日目の記事です。 SmartHRではReact コンポーネントライブラリ「SmartHR UI」を全プロダクトで使っています。なぜ使っているのか？それはSmartHRのプロダクトの体験統一と、開発速度を向上させるためです。 github.com SmartHR UIがそもそもどういったコンポーネントライブラリなのか、どうやって始まったのか、運用やリリース手順の改善については、過去の記事にて説明しています、よろしければ以下の記事をご覧ください。 「プロダクト間共通の React コンポーネントライブラリ」がどうなったか、という話 - SmartHR Tech Blog プロダクト間共通の React コンポーネント

これはSmartHR Advent Calendar 2022 17日目のエントリーです。 こんにちは、SmartHRで文書配付機能の開発をしているmiyoshiと申します。 今回は私が担当している文書配付機能で繁忙期を乗り越えるためにやった負荷テストの話を共有しようと思います。 この記事では我々がどのように考え負荷テストを進めてきたかを書いていますので、負荷テストをやるべきか悩んでいる人の助けになれば幸いです。 背景 文書配付機能は3月末から4月初頭にかけて繁忙期を迎えます。 これは新入社員の雇用契約書・誓約書や従業員の給与改定通知書など、この時期に送付・合意してもらいたい書類が数多く存在するためです。 恥ずかしながら昨年の4月はサーバーダウンを発生させてしまい迷惑をかけてしまったので、「今年はなんとしてでもサービスを継続させるんだ！」という想いがチーム内で強まっていました。 しかし、チ

こんにちは！SmartHRで組織図機能の開発を担当している、エンジニアのmuranoです。 組織図機能の開発チームでは、最近の取り組みとしてハックデイを取り入れてみました。今回はそのハックデイの取り組みについて紹介します🐶 ハックデイ is なに？ ハックデイは、ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方の中で登場したハックウィークという概念を、SmartHR向けにアレンジした言葉です。こちらの書籍の中でも元ネタとして参照されている、Googleの20％ルールに近いイメージの将来への投資的活動になります。（Googleが今も実践する｢20%ルール｣で、未来の自分に投資するメリット | ライフハッカー［日本版］） 組織図機能開発チームが行うハックデイでは、月に1日、通常のプロダクト開発から離れ、新しい技術の調査やトライを行っています。 ハックデイってなにが嬉

皆様、こんにちは。IT企業で働くChatGPTです。今回は、弊社が最新の技術を積極的に取り入れていることについてお話ししたいと思います。 近年、IT業界では技術の進化が著しいものとなっており、我々の業界も例外ではありません。新しいツールやフレームワークが次々と登場し、それをうまく活用することが企業の成長や競争力維持に欠かせない要素となっています。 弊社でも、このような状況を踏まえ、常に最新の技術を取り入れることを心がけています。その一つが、先日導入したGitHub Copilotです。 もしGitHub Copilotについてまだご存知ない方がいらっしゃる場合は、簡単にご説明します。GitHub Copilotは、人工知能によって自動でコードを生成するプログラムで、AIが自動でコードを補完してくれるため、開発者はより素早く、効率的に開発作業を進めることができるようになります。 当社では、C

こんにちは。SmartHR 情報セキュリティグループ所属の @sasakki- と申します。 最近何かと話題の多い大規模言語モデルをはじめとしたAIサービスに関して、先月クラスメソッドさんから利用ガイドラインが公開されましたが、SmartHRでも利用方針を作成したので内容をご紹介します。 ＊弊社のAI活用方針は、「SmartHR AI活用ポリシー(https://smarthr.co.jp/ai-application-policy/)」をご確認ください。 背景 3月初旬にChatGPT APIが公開されて以降、社内から利用にまつわる会社としての考え方を求める声が高まってきたことから、利用方針をとりまとめることにしました。 利用方針 考え方 情報ごとの取り扱いを定めた”基本方針”と、基本方針内で使う上で”注意してほしいこと”の２つのパートで構成しました。 基本方針は、元々社内で定義していた

こんにちは。プロダクトエンジニアのyudaiです。5/11から開催されるRubyKaigi2023に向けて、社内で勉強会を実施しました。自己学習のきっかけづくりとして、RubyKaigiのトークを聞く準備方法、トークテーマ、RubyKaigiで話題になりがちな技術について広く浅くお話しました。 RubyKaigi 2023に参加される方のお役に立つかもしれませんので、この勉強会で使った資料を公開します。 RubyKaigi 2023 予習資料 留意事項 この記事はyudai(@ytnk531)が、RubyKaigi 2023の予習のために調べた内容をまとめたものです。誤った内容や古い内容が多く含まれる可能性があることをご留意ください。誤りなどについてご指摘を頂ける場合は、TwitterのDMかリプライなどでご連絡をいただけると大変助かります。 内容 事前に理解していたほうが良さそうなRub

どうも2022年9月にSmartHRに入社したエンジニアの大澤(@qwyng)と申します。SmartHRの本体を開発しています。 SmartHRというサービスは、従業員情報を集約したアプリケーションをコアとし、そのコアと連携する複数のアプリケーションを配置した構成になっています。 そのコアというのがSmartHR本体です。 SmartHR本体は歴史が長いプロダクトです。カジュアル面談でも「キャッチアップはどうされました？」、「SmartHRの開発って技術的に何が大変ですか？」といった質問をよく頂きます。 本記事はそういったSmartHRの開発の大変さを知りたい方に向けて自分が感じたことを言語化したいと思います。 2022年初頭に弊社の@sugamasaoさんがSaaS.techで発表した. 「アプリケーションが大きくてつらい・・・ってこと！？」*1 というスライドを見たことがある方もいると

SmartHRではRuby on Railsを多くのサービスで採用しています。 そのため、不足している機能や不具合があればrails/railsへコントリビュートすることがあります。 今日は、日々のぽつぽつとしたコントリビュートの中から、Rails 7.1に追加したUNIQUE制約について紹介します。 unique_constraint(UNIQUE制約) UNIQUE制約(unique_constraint)はRails7.1(執筆時は未リリース)から利用可能になるActiveRecordの新機能です。 rails/rails#46192 PostgreSQLでしか利用できませんが、下記のようにunique_constraintで遅延可能なUNIQUE制約を定義できるようになりました。 # create_table内で使う場合 create_table :items do |t| t.i

従業員データベース機能の開発を担当している渡邉です。最近公開したGemであるactiverecord-tenant-level-securityの紹介をします。 SmartHRにおけるマルチテナントの現在 私たちが開発するSmartHRはお客様ごとに1つの環境を提供する、マルチテナント型SaaSです。サービス全体で1つのデータベースを持ち、複数のテナントのデータが混ざらないように、SQLで問い合わせを行います。 1つの環境ごとに1つのデータベースを持つ方式は安全性の面で優れていますが、スキーマの保守やマイグレーションにかかる時間の増加など、多くの技術的な困難をもたらします。この選択の背景については、2018年に書かれた以下の記事もご覧ください。 tech.smarthr.jp とはいえ、常にテナントごとのWHERE句を意識しながらコードを書くのは大変ですし、不具合の温床になります。幸い、私

こんにちは。プロダクトエンジニアの@cidermitainaです。 2023年2月に配置シミュレーション機能がリリースされました。 配置シミュレーション機能のフロントエンドを作るにあたってどのような技術選定したのか、その背景と意思決定をまとめていこうと思います。 配置シミュレーション機能とは？ まずは、ざっくり配置シミュレーション機能についての説明です。 配置シミュレーション機能は、SmartHRに蓄積された人事データを活用しながら、ドラッグ&ドロップで人員配置のシミュレーションができる機能です。 異動前後の平均勤続月数や平均年齢など、部署全体の統計データを参照しながら配置の検討ができます。 ベースの技術 では、本題の技術選定についてです。 ベースの技術は以下になります。 Next.js React TypeScript まず、どのような技術を使ってフロントエンドを開発していくかを検討しま

こんにちは。SmartHRでテクニカルプロダクトマネージャーをしている @h1kita とプロダクトエンジニアの @meganemura です。 SmartHRでは、今年（2023年）1月にプロダクト基盤チームを立ち上げました。 このチームは、SmartHRがマルチプロダクト戦略を実現し、ユーザー価値の向上と事業成長を続けていくために非常に重要な役割を持ちます。 この記事では、プロダクト基盤チームが組成された背景やミッション、取り組んでいることやその難しさについて紹介したいと思います。 プロダクト基盤チーム組成の背景。SmartHRの向かう先とマルチプロダクト戦略 「SmartHR = 労務系SaaSを提供している会社」というイメージを持っている方も多いのではないでしょうか。 もちろん間違いではありませんが、SmartHRは コーポレートミッション の “well-working” 実現に

こんにちは！ SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。 SmartHRでは顧客の価値の最大化を目指し、日々開発プロセスの改善を行っています。 特に私の所属する基本機能のDチーム*1では、以前からクロスファンクショナルを強く推進しています。 本日はクロスファンクショナルとは何なのか？やってみてどんなメリットがあったのかをまとめました。 クロスファンクショナルとは スクラムガイドでは機能横断型と翻訳されています。 機能横断型というのは、エンジニアリング、デザイン、QAなど複数の職能（スキル）を持つことを表しています。 そして機能横断型という言葉は、チームに対して使われることが多いですが、個人に対しても使われます。(例: プロダクトエンジニアがデザインもできる、QAエンジニアがコードも書けるなど) SmartHRにおいてチームが機能横断型であること

こんにちは。SmartHRでPM（プロダクトマネージャー）をしているadachiです。 最近、面接などで「SmartHRではどのような流れでプロダクトを作っているのか」という質問をよくいただくので、このあたりでいちど現状を整理しておこうと思い立ちました。 SmartHRでは、全社的にスクラム開発を採用しています。このブログにも スクラムに関する記事 がたくさんあるのでぜひ読んでいただきたいのですが、今回はもう少し引いた視点から、顧客から受けた要望がどのように開発されていくのかという全体の流れを取り上げてみたいと思います。 なお、開発プロセスは状況に合わせて日々更新されていますので、今回ご紹介するのは2021年6月時点での内容になります。 プロダクトの構成 SmartHRには、大きく分けて2種類のプロダクトがあります。ひとつはコア機能である「本体」で、もうひとつは本体にアドオンする形で使える

こんにちは、SmartHR本体機能の開発をしているkouryouです。 SmartHRでは毎月多くの方が入社しており、日々組織が拡大しています。 しかし一般論ですが、組織は拡大とともに分業化が進み、顧客価値を中心にチームで仕事することが難しくなっていきます。 実際SmartHRでも同じ課題感がありました。 そこで当時、組織が拡大しても顧客価値を中心にプロダクトを作るための考え方である「フィーチャーチーム」に注目し、推進しました。 今回は当時理解を促すために社内向けに書いたドキュメントを改めてまとめてみました。 フィーチャーチームとは エンドツーエンドで顧客中心の機能を実現する、安定した長期存続するチームのことです。 出典: 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 何かしらの案件を「着想」レベルで受け取り、チームメンバーだけ

こんにちは！ SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。 突然ですが、皆さんのチームの生産性は高いでしょうか？ この議論を始めると必ず直面する壁が、そもそも生産性とは何か？です。 生産性を上げようとする際の効率化の考え方には、リソース効率とフロー効率という2種類の考え方があります。 そしてSmartHRでは、特にフロー効率の方を重視しています。 そこで本記事では リソース効率/フロー効率とは何か なぜSmartHRはフロー効率を重視しているのか について解説していきます。 リソース効率とフロー効率 リソース効率とは リソース効率とは、リソースの稼働率のことです。 リソース効率を高めるということは、リソースに空きがあればタスクを与え、全員が何かしら手持ちのタスクがある状態を作ることになります。 手が空いてる人を作らないという至って普通の考え方なの

まえがき こんにちは！SmartHR 基本機能の B チームで開発をしている@ron です。 今回は、私の所属する B チームで品質と開発効率の向上のため Jest を導入するにあたり、チームで行った議論と導入した結果をご紹介します。 Rails を使用している SmartHR では RSpec を使用してテストを実施していますが、テストが増えるにつれて CI での実行が非常に遅くなることが課題となっていました。 Jest を導入したことで、テストの網羅性が上がり、テストパターンを増やしつつ、テストの実行時間の増加を抑えることができました。 また、Jest を導入するにあたり、Jest と RSpec それぞれでどういったテストを書くべきか、どういったテストを書かないべきかを議論し、整理したので、その内容もお話しします。 SmartHR のプロダクト規模について SmartHR は、企業情

こんにちは。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基本機能」でプロダクトオーナーをしている塚本です。 この記事では「SmartHR基本機能」の開発体制変更の経緯とその後の状況、開発チームからの声を紹介しています。大規模プロダクトにおいて以下のようなモヤモヤを抱えている方の参考になると幸いです。 提供機能が多岐にわたるため すべてを把握するには認知負荷が高すぎる ゴールの設定難易度が高い 開発チームの思考が担当機能に閉じやすい はじめに SmartHRには、大きく分けて2種類のプロダクトがあります。ひとつはコア機能である「基本機能」で、もうひとつは基本機能にアドオンする形で使える「オプション機能」です。 この記事では、「基本機能」の開発体制について記載しています。 SmartHR「基本機能」の開発では大規模スクラム（LeSS）を採用しており、現在は6チームで構成されています。各開発チームにはPM、エンジニア、デザ