こんにちは。SmartHR プロダクトエンジニアの sasaki (@s_sasaki_0529) です。 今回は、私が開発に携わっている届出書類機能における E2E テストを、Capybara + Selenium の構成から Playwright に移行し、開発プロセスに組み込んだお話をします。 扱う話題 E2Eテスト基盤を移行する具体的な背景と理由 移行における提案から、合意形成までの流れ 移行後の開発プロセスがどう変わったか 扱わない話題 Playwright など、記事内で扱う技術要素自体の詳細説明 移行作業自体の詳細 テストコードの設計・実装に関する具体的なテクニック なお、本記事では便宜上、移行前の E2E テストを「旧テスト基盤」移行後を「新テスト基盤」と呼称します。 届出書類機能について E2Eテストに限らず、テストというのはプロダクトの特性によって最適な手法は大きく変わ

こんにちは！　UXライターの @aguringo です。今日は、エンジニアマネージャーの吉成さんに頼まれて、「SmartHRの開発者とパパママ業は両立しやすいのか」というテーマでブログを書きます。 なぜ、私がこの記事の担当になったのかと言いますと、私自身も娘を育てているママだからです。ちなみに、わが家のムスメさんはプリキュアの小さなお友達としての年齢を遥かに上回り、今では大きなお友達として毎週デパプリを楽しみにしています。 SmartHRでの働き方は、子育て中のパパママから見ると、どんな印象？ 今回、協力してくれたのは、プロダクトエンジニア、プロダクトマネージャー、プロダクトデザイナーとして働く、計17名。お子さまたちの年齢層は0〜11歳で、半数が2人のお子さんを育児中です。 ストレートに「SmartHRって子育てしやすい会社だなぁと感じたことはありますか？」という質問を投げかけてみたとこ

こんにちは、プロダクトデザイングループの@kgsiです。 SmartHRでは、書き方の誤りを検知・修正してくれるtextlintというOSS（オープンソースソフトウェア）をプロダクト開発に導入しています。textlint導入の背景については、既に公開済みの関連記事を参照してください。 shanaiho.smarthr.co.jp 今回は、textlintとその開発者を支援するために、GitHub Sponsorsを通してOSSスポンサーになったことを公式に報告します。 寄付をした背景 現状、SmartHRではtextlintと独自のルールを含むプリセット（textlint-rule-preset-smarthr）を作成し、主にプロダクトのCI環境や、ドキュメントの校正に利用しています。 また、オープン社内報や登壇で「textlintのルールプリセットを作って、プロダクト開発で利用している」

みなさん、こんにちは！SmartHRでプロダクトマネージャー（PM）をしています岸（@kissy）と稲垣（@gackey）です。 本記事では、「SmartHRのPM」連載企画の第7弾として、SmartHRのVP of Productである安達さんのインタビュー記事をお届けします。SmartHRのPMグループの目指す姿や、プロダクト作りにおいて安達さんが心がけていることなどについてお話を伺いました。 安達隆 チームラボにて受託開発やプロダクト開発に従事したのち、起業。EC領域でSaaS事業を立ち上げ、KDDIグループに売却。メルカリにてカスタマーサポート部門の業務システム開発を担当し、2019年にSmartHRへ入社。現在プロダクトマネジメントの責任者を務める。日本CPO協会理事。 What だけでなく Why を語れるPMへ 岸：今日はよろしくお願いします！まず、2021年のPMグループ方

こんにちは、フロントエンドエンジニアのモアイと申します。 SmartHR では、SmartHR UI というプロダクト間共通の React コンポーネントライブラリを運用していますが、この記事では SmartHR UI のリリース作業を GitHub Actions で自動化した話をご紹介します。 ちなみに SmartHR UI そのものについては過去の記事で詳しく紹介されていますので、ご興味があればそちらも併せて御覧ください。 tech.smarthr.jp tech.smarthr.jp 三行まとめ リリース作業が複雑化していたので GitHub Actions を使って自動化した リリース中に作業者の確認を挟むプロセスを Issue とラベル付けによって実現した 自動化最高！ これまでのリリース作業 SmartHR UI では Pull Request ベースで開発しており、様々な歴

こんにちは！ SmartHRでWebアプリケーションエンジニアをしている藤井です。 弊社では「クラウド人事労務ソフト」の名の通り、人事労務に関わるプロダクトを開発・提供しています。 そんなSmartHRでは事業を拡大させるためエンジニアを積極的に採用しています。 採用活動をしていると、カジュアル面談などの場で、「労務って入社・退社とかですよね、まったくその分野について知らないのですが…」といった声を聞くことがあります。 すべての従業員に関わってくる「労務」ですが、多くのエンジニアにとっては馴染みが薄く、イメージがつきにくいのだろうなと思います。 入社時点で労務の知識を持っていた人はほぼいません まずは、プロダクト開発のエンジニア向けにこんなアンケートをとってみました。 「SmartHR に入社する前に労務の実務経験や労務に関するプロダクトに関わった経験がありますか?」 結果は「労務に関する

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

こんにちは！ エンジニアマネージャーの森住（@t_morizumi）です！ 今回はシリーズD調達を果たしたSmartHRのこれからをご紹介すべく、各事業領域のエンジニアリーダーにインタビューをしていきます。 それぞれの領域について、これまでどういう開発をしてきたのか、これからどういう開発をしていくのか、事業として今後どうしていくのか、といった部分を中心に各エンジニアリーダーに語っていただきます。 なお、本記事は以下の三部構成となっています。 引き続き事業の軸となる「SmartHR本体」 エンジニアマネージャー : 鈴木 睦央 新たな軸としての「人材マネジメント」 PdM兼エンジニア : 疋田 駿 働くすべての人を支える未来に向けて「プラットフォーム化構想」 CTO : 芹澤 雅人 それでは早速、SmartHR本体のエンジニアマネージャーを務める鈴木さんからお話をうかがっていきます！ 鈴木

こんにちは！SmartHR バックエンドエンジニアの yoshinarl です。 気づけばはや5年…私が入社した頃は小さなマンションの一室で社員も7名しかいませんでしたが、今では社員も400人を超えてオフィスビルのワンフロアを貸し切っています。 何やら 老害達が語るSmartHR初期 という会が開かれるほどに歴史のある会社になったわけですが、あのメンバーはほとんどが私より1年以上あとに入社してるんですね。老を越して仙ですよ、仙。仙人です。創業者を除けば最古参なんです。 さて、そんな私ですが、実はまだ経験したことのない行事があるんです。そう、新入社員オリエンです。 当時は入社前に遊びに行ったと思ったらオフィスの書類棚作りを手伝っているような状況でしたから、当然オリエンなんてあってないようなものです。 2020年の1年間で社員数がほぼ倍増しリモートにも対応した SmartHR ですが、いったい

こんにちは！ エンジニアマネージャーの森住（@t_morizumi）です。 現在 SmartHR は saiyo-tasukete プロジェクトの名の下、エンジニアの採用ブランディングと再び向き合っている真っ只中にあります。 「普段取り組んでいることをきちんとテックブログで発信する」という、ぐうの音も出ないほど当たり前のことが大切であることに CTO が気づいてしまったため、僕もこうして筆を取っている次第です。 さて、今回はエンジニアのキャリアについてということで、SmartHR がエンジニアのキャリアアップにどのように取り組んでいるのかをご紹介したいと思います。 SmartHR のエンジニア組織について まずは大前提として、SmartHR のエンジニア組織は以下のような構造になっています。 （※ 組織構造の概略をお伝えすることが目的のため簡略化しています） CTO がマネージャーを支え、

こんにちは！CTO の芹澤です。 前回投稿した「エンジニア採用が再びピンチ！ 窮地を脱すべく改善施策の企画会議をしました」という記事ですが、おかげさまで多くの反響をいただけました。 みなさまから寄せられた意見は一部 saiyo-tasukete プロジェクトにも反映させておりますので、引き続きこちらも楽しみにお待ちいただければと思います。 さて、この投稿はそんな saiyo-tasukete プロジェクトに起票された「CTO からの大切なお知らせ」というチケットを元に書いています。 荘厳なチケットタイトルではありますが、お伝えすることは採用目標の具体的な内訳とその根拠についてです。 「採用がピンチです！」とだけお伝えしても、「どれくらい採用するつもりなのか？」とか「退職が相次いでいるのか？」といった点をクリアにしないと、安心してご応募いただくことは難しいかと思います。 なので、今回はその辺

こんにちは！CTO の芹澤です。 突然ですが、SmartHR社では現在エンジニア採用の進捗が非常に悪く、本記事の執筆時点で目標達成率9.3%という状況です。いわゆる、ピンチです。 どうしてこんなことになってしまったのか...人事グループの方々とここ最近の採用関連の数値を分析したところ、採用の母集団形成がうまくいっておらず、特に「自己応募数」の減少が深刻なことがわかりました。 採用をオープンしているにも関わらず自己応募が減少している。多くの場合、これはエンジニアの採用ブランディングがうまくいっていないことが要因としてあげられます。 過去の施策とその功罪 思い返せばこのエンジニアの採用ブランディングとは、長い付き合いになります。 2018年にも約半年間エンジニア採用ができず、真剣に採用ブランディングと向き合った時期がありました。チーム一丸で認知獲得施策を捻り出し、「エンジニア歓迎会の練習会」や

こんにちは！ SmartHRのプロダクトサイドでUXライターをやっている、おおつかあぐり（@aguringo）です。開発現場では、UIテキストの作成や デザインシステムの整備 をしています。 以前、こちらでも 豊田聡さんがアジャイルコーチとしてジョインしました！ で紹介させていただいた通り、SmartHRの開発組織はアジャイルコーチの豊田さんにサポートしていただいています。 およそ半年間、豊田さんの助言を受けながら、SmartHRの開発組織はアジャイルの推進を加速させてきました。スクラム勉強会 を実施し、アジャイルやスクラムを概念として理解し、実務ではフィーチャーチーム*1にエンジニア以外のスキルセットを持つメンバーが入っていくという試みも進めています。 今回は、非エンジニアでありながら、スクラム勉強会第2期卒業生*2である私が、豊田さんに興味津々、じっくりとお話を伺いました。 tech.

こんにちは、PdMの稲垣です。「SmartHRのPdM」連載企画の第２弾、今回はSmartHR本体のPdM兼POである塚本真紀子さんのインタビュー記事をお届けします。 PdMとして、組織の一員として、母として。様々な角度からの塚本さんの思いとともに、一緒に働くチームメンバーからの声もご紹介します。 塚本真紀子 エンジニア、経理、デザイナー、ディレクターを経てPdMとなり、2019年1月に3人目のPdMとしてSmartHRに入社。 現在はSmartHR本体のPdM兼POを担う。 どんな規模の企業にも「人事データベース」として役立つSmartHRになりたい 稲垣：まず、今担当しているプロダクトを少し紹介していただけますか？ 塚本：SmartHRは、人事データベースの役割を持つ「SmartHR本体」と、そのデータを活用するアプリケーション群である「プラスアプリ」で構成されていて、私は本体のPdM

こんにちは、SmartHR でフロントエンド開発を担当している @Tokky0425 です。 この記事では、私のプロダクトでの OpenAPI Generator を使ったフロントエンド開発の取り組みを紹介していきます。 目次 OpenAPI とは 「ラクラク分析レポート」の DX 上の課題 OpenAPI Generator とは 実際に generate してみる 生成ファイルを使ってみる 型情報を出力してみる 組み込み・運用の工夫 chokidar で監視する lint-staged に組み込む メリット・デメリット メリット デメリット まとめ OpenAPI とは OpenAPI とは、「REST API のドキュメントの記述形式を定めた仕様」のことを指しています。 簡単な例ですが、下記のような YAML ファイルがあるとします。 schema.yml paths: "/some

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

こんにちは！ フロントエンドエンジニアの @diescake です！ 1 年程前に @nabeliwo よりこんな記事を公開しています。 tech.smarthr.jp 一言で要約してしまうと、SmartHR の各種プロダクトで一貫したユーザー体験を提供するために、SmartHR UI という React コンポーネントライブラリを実装し始めたよ！ しかも OSS として公開してるよ！ という話でございました。 github.com 本記事では、それから 1 年弱たった今 SmartHR UI がどうなっているか、という話をしつつ、現在の SmartHR UI の運用・開発体制について話をしてみようと思います。 SmartHR UI は成長しているよ！ 2019/08/01 2020/05/21 バージョン v3.9.2 v8.2.0 コンポーネント数1 30 66 ソースコード規模2 3

こんにちは！ 二人しかいないアジャイル推進室のメンバーの一人、エンジニアの森住（@t_morizumi）です。 アジャイル推進室とはなにか、については @kissy による以下のブログをご参照ください。 tech.smarthr.jp （当初はアジャイル推進室（仮）でしたが、「もう（仮）いらないんじゃね？」との声を受けて現在は（仮）が外れています） 今回は表題の通り、アジャイル推進室としてリモートでのタイムライン振り返り実施をお手伝いしたので、そのときの事前準備 → 実施 → 事後について書いていきます。 一ヶ月ほど前に出た「コロナの時代の付箋ワークショップ」という CTO の芹澤によるブログで、タイムライン振り返りについて軽く触れられているのですが、今回はより踏み込んだ内容となっています。 tech.smarthr.jp 経緯 上記の芹澤によるブログに、大型機能開発がひと段落したタイミン

こんにちは、エンジニアのkinoppydです。 先日、SmartHRでのメタプログラミングRuby読書会と、その成果物というエントリを公開した直後に、毎週水曜日に開催されている社の全エンジニアが参加するテック定例というイベントの中で、CTOから「テックブログ最近更新されてないね、どうする？」という言葉を投げかけられました。POSTしたばかりの私としては「いや、更新しとるやん」と思ったのですが、客観的にここ数ヶ月の更新を見ていると、以前ほどの活発感もなく、またエンジニアリングの話よりも取り組みや入社報告が多く、テックブログと名乗って良いのか少し疑問が残ることも確かでした。そこで、今後このテックブログをどうしていくのかを、CTOと私、そしてテックブログに一家言ある社内の有志のエンジニアをその場で募り、会議室で腹を割って話してみることにしました。 会社のテックブログというものと、その宿命 比較的

こんにちは、コーポレートエンジニアの小石(@koipai)です。 この記事では、毎月10〜20人が入社してくるSmartHRにおいて、従業員PCにかかる初期セットアップを自動化して、オンボーディングをちょっと楽に、そしてリモートワークにも対応できるシステム構築をした話をしたいと思います。 なにが課題だったのか まず、前段となる話、つまり僕がSmartHRに入社してJamf Proを触り始める以前の話をすると、僕が入社した2019年11月時点、SmartHRでは既にJamf Proが導入済み、ゼロタッチデプロイっぽいことはやっていた、という感じでした。 SelfServiceによる「なんちゃってゼロタッチデプロイ」 Jamf ProにはSelfServiceという、Jamf独自のアプリ配布用アプリが存在します。 そして、SelfServiceでは管理者によって登録されたアプリを従業員が任意で