はてなブックマーク

こんにちは！エンジニアマネージャの 吉成 です。 新型コロナウイルス感染症の影響によって 2020年以来オフラインのみの開催だった RubyKaigi ですが、2022 年からオンオフ混同という形で現地あるいは自宅にいながらの参加が可能となりました。 SmartHR では以前よりスポンサーとしての協賛だけではなく、「会場で出会ったひとたちがそのまま飲みにいけるような情報を提供しよう」という思いのもと、実際に現地まで足を運びグルメマップを作成・公開してきました。 今回はオンオフ混合ということもあり「自宅にいながら、あるいは三重に足を運んだ人たちが美味しいお土産に巡り会えるように」という思いでグルメガイドを作ることにしました。 ただお土産を取り寄せて食べるだけでは面白くないということで、CEO 芹澤 と VPoE 森住、そしてエンジニアチーム三重県代表 藤井 の3名をオフィスに呼び出して「三重

こんにちは、開発者のkinoppydです。こんにちは。 SmartHRでは、去年から引き続きRubyKaigiにスケジュールアプリを提供しています。事前にRubyKaigiスケジュールから「拙者のセットリスト」を作成してもらい、SNSで他の参加者とシェアして楽しんでもらうことを目的にしています。 これが今年のワイのセトリや！https://t.co/vZ3nGrPlCt #rubykaigi— kinoppyd (@GhostBrain) 2022年9月1日 去年のソースコードを利用しつつ、今年は新しいチャレンジとしてフロントの環境をNext.jsに移行してみようと考えました。去年の時点で、フロントはほぼReactで書かれており、helperという名の実質APIも書かれていたので、そんなに大きな手間にはならないだろうと思いましたが、とはいえ色々と起こったのでその様子をお伝えしたいと思います

こんにちは！　プロダクトエンジニアのkinoppydです。 SmartHRは自社プロダクトのバックエンド全てをRubyで開発しており、Rubyこそが我々の力こそパワーであると感じ日々を過ごしています。そして今年も、我々は「RubyKaigi2022」に協賛します！！　3年ぶりの三重県オフライン会場が楽しみですね。 ご存知の方も多いと思いますが、RubyKaigiはプログラミング言語「Ruby」に関する世界最大級の国際カンファレンスです。本イベントをもっと楽しんでいただけるといいなぁ〜と思い、SmartHRのスポンサー内容と募集事項をお知らせします！ SmartHRのスポンサー内容 今年のスポンサー内容は、以下の3点です！ （1）三重県の会場にてブースを出展し、「マスクに貼れる！　アイコンステッカー」＆オリジナルステッカー＆トートバッグを配布　※マスクは事前申込制です （2）「人労打 -JI

こんにちは！QAエンジニアのark265です。 SmartHR全体のプロダクトを横断的にQA業務を行うチームに所属してます。 QAチームで掲げているミッションの一つである「品質を技術で解決する」 を実現するために日々、より良い品質保証活動ができるよう取り組んでいます。 実施した背景 昨今、お客さまの多様性が高まっている背景と、より高いレベルの品質保証が求められるようになりました。 今回は SmartHR API を対象にした活動をお伝えしていきます。 SmartHR API は基本的に request spec により動作が担保されています。 一方でインフラなど外部要因で影響が発生したり、request spec の不足などで問題が起きることがありました。 そこで、より高いレベルでの品質を保証する手段として、外部からのリクエストによるテストを実施することにしました。 手段の選定 自前で環境

こんにちは！SmartHRのプロダクトエンジニアの@diescakeです！ 今日は「Google Apps Scriptで、社内プロダクトのnpmライブラリの利用状況をスプレッドシートに出力してみた話」を題材にしつつ、主にGoogle Apps Script（以降GAS）の開発環境周りの話をします。技術の分野としてはWebフロントエンド（以下フロントエンド）に関連した話が多くなります。 全体の構成図はこんな感じです！ ソースコード管理から、スプレッドシートに反映されるまでのデータフロー図 大まかな構成・データフローは上図のような感じで、主な技術スタックとしては、GAS + Clasp + TypeScript + esbuildを採用しました。 この図を左側から見ていくと、まずGitHubでソースコードを管理していて、昨今のフロントエンド開発と同様に、TypeScriptでコードを書き、必

こんにちは、UXライターの8chariです。早いものでSmartHRに入社して1年が経ちました！初めてTech Blogを書くのでドキドキしています。 SmartHRでは、フィーチャーチームでプロダクトを開発しており、開発プロセスの改善を日々行なっています。 この記事では、私が所属しているBチーム*1でヘルプページ作成のプロセスを見直し、チームのボトルネックを解消しようとしている話を紹介します。 特定の業務を担当できるメンバーが限られていて、以下のような課題を感じている方の参考になると嬉しいです。 必要なノウハウや知見がほかのメンバーに広まらない プロジェクトのボトルネックになっている 担当できるメンバーの負荷が高くなっている 前提 UXライターがいる開発現場はあまり多くないと思いますので、前提を説明します。 SmartHRのUXライターは「言葉の力でプロダクトを、もっとわかりやすく」する

こんにちは。SmartHRでプロダクトマネージャー（以下PMと記載）をしているhiroki_mです。 SmartHRのPM組織であるPMグループでは、今年の年初に方針を以下のように定めました。 PMグループ方針 今回は、このグループ方針の3つの要素「大きく考える」「小さく動く」「ともに学ぶ」のうち「ともに学ぶ」を進化させていくために行った取組みについて紹介したいと思います。 ※PMグループ方針については「2022年のプロダクトマネジメント方針を公開します」に背景や詳細が説明されているので、興味を持たれた方はそちらをご覧ください。 「ともに学ぶ」とは？ 「ともに学ぶ」がグループ方針として規定された意図として、adachiさんは次のように述べています。 PMもプロダクトも増えるなかで「横連携大事だよね」という意識は徐々に浸透してきたと思いますが、横連携という言葉は「必要なときにお互い調整しよう

こんにちは、UXライターのkunyです。3月にスケボーを始めて、最近チックタックができるようになりました。 さてSmartHRでは、textlintに独自のルールプリセットを追加して利用しています。ルールプリセットはオープンソースで公開しており、継続的にルールを追加しています。 さて、そのルール追加の際に正規表現の知識が必要なのですが、「正規表現、マジ難しい...」と感じています。「う〜ん」と唸りながらルールを追加することも多いです。 そこで自分の勉強も兼ねて、textlintへのルール追加の際に必要な「基本的な正規表現」を、実例とセットでまとめてみました。「ブログ書くぞ〜」と宣言したところ、少数ながらも「いいね」をいただき、需要あるかも？と思っています。感想やフィードバックを、Twitterでつぶやいていただけると嬉しいです。 textlintのルール作りに必要な正規表現、というタイトル

こんにちは！ SmartHRのプロダクトエンジニアのshunです。 本記事では、弊社内で実施しているアクセシビリティマスター養成講座のご紹介と、SmartHRの従業員サーベイというプロダクトで実施しているアクセシビリティ改善の取り組みについてお話しできればと思います。 SmartHRにおけるアクセシビリティの取り組み SmartHRでは、アクセシビリティの専門スキルを持つ@masuP9さんと@maverickさんを中心にアクセシビリティ改善の取り組みが行なわれています。 お二人のアクセシビリティに関する取り組みに関しては、以下の記事をご参照いただければと思います。 tech.smarthr.jp アクセシビリティマスター養成講座 2022年3月から、SmartHR社内における各プロダクトのアクセシビリティ改善の取り組みとして、アクセシビリティマスター養成講座が始まりました。 @masuP9

はじめに こんにちは！SmartHRのQAエンジニアのmachiです。 前回こちらの記事でカジュアル面談資料を大公開したQAグループですが、 今回はその続編として、カジュアル面談や選考時によくある質問とその回答をまとめてみたので公開します！ SmartHRのQAエンジニアのポジションに興味がある方、カジュアル面談を受けた人達は実際にどんなことを聞いているのか気になっている方のご参考になれば嬉しいです。 補足 本題に入る前にQAグループや開発組織について補足させてください。 SmartHRのQAグループは、 プロダクトがいつでもアクセルを踏める状況を作る 品質を技術で解決する というミッションを掲げて活動しています。 前提情報としてお伝えすると、プロダクト開発はスクラムを採用しており、QAエンジニアもその開発チームメンバーの1人です。 それぞれのプロダクト開発チームは5〜9人程度で、プロダク

こんにちは、プロダクトマネージャー（以下PM）の adachi です。（ToDo: ここになにか面白い文章を入れる） 先日、プロダクトの目的・目標・指標をまとめた図をTwitterに投稿したところ、わりと反響があったのでこちらで解説したいと思います。 開発メンバーから「会社の戦略とプロダクトの目標がどう紐付いてるかわからない」という声をもらって作った図。 改めて整理する中で自分のなかでも気付きがあり、もっと早くやっておけばよかったなと思いました。 pic.twitter.com/tuedZhaZG2— Takashi Adachi (@asanebo_) 2022年6月1日 この記事でお伝えしたいこと 会社のミッションや戦略とプロダクトの目的・目標・指標は、構造的に整合していることが重要である PMにとって自明に思えることでも、アウトプットしなければチームで共有できない 目的・目標・指標の

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

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

はじめに みなさんこんにちは。SmartHRのプロダクトマネージャー @ryopenguinです。 この記事では、KPIを軸にプロダクト運営をしてきた2021年の振り返りと、そこで得られた学びについて書こうと思います。 KPIの導入によって、チームの目線を揃えた上でプロダクトを改善できるようになりました。また、プロダクトのポジショニングやビジョンについて改めて考えるきっかけにもなりました。 KPIやNSM（North Star Metrics）、プロダクトビジョンの扱い方について、この記事がヒントになれば幸いです。 「従業員サーベイ」とは 今回題材となるプロダクトは、私が担当する「従業員サーベイ」です。 従業員サーベイは、従業員に対してアンケートを送付し、その結果とSmartHR内に蓄積された従業員情報を掛け合わせ、企業の状態を分析できるプロダクトです。2020年9月より提供を開始しました

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

こんにちは。エンジニアマネージャの 吉成 です。 本記事では 2022年1月に VPoE に就任された森住さんについて、同時期に CTO から CEO になった芹澤さんと一緒にアレコレ深堀りした様子をお届けしたいと思います。 森住さんの今までのキャリアやSmartHRでやってきたこと、そしてプロダクトエンジニアグループのこれからについて伺いました。 SmartHR に入るまで 吉成： 今日はよろしくお願いします。 一同： お願いします。 吉成： まず最初に、SmartHRに入るまでの簡単な経歴をお願いします。 森住： はい。キャリアのスタートはウェブ系の受託開発の会社で、当時はいわゆるLAMP環境で開発していました。最初の会社は大体3年ぐらい在籍して、ずっとウェブの開発ですね。 そのあと転職して、マーケティングオートメーションツールを作っている会社に入り、そこもほぼLAMP環境で3年間ほど

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

こんにちは、プロダクトマネージャー（以下、PM）のadachiです。 SmartHRでは、年始に各部署のリーダーがその年の方針を発表することになっています。今回は私がPMグループの方針として書いた文章を、丸ごとそのまま公開したいと思います。 本文に入る前に、少しだけ補足をさせてください。 現在PMグループには13名のPMが所属しており、それぞれ担当するプロダクトの性質もフェーズも異なります。そのようなチームに向けたメッセージということで、やや抽象的かつ焦点が絞りきれていない内容になっております。（言い訳その1） また、改めて読み返すとかなり基本的なことしか書いていないのですが、基本に立ち戻ってがんばろうぜ！という趣旨であることをご理解いただければと思います。（言い訳その2） そして、あふれる思いを詰め込んだ結果、かなりの長文になってしまいました。シンプルさを美徳とするPMとしては汗顔の至り

こんにちは！ SmartHRのQAエンジニアのtano(@nagatanuen)です。 弊社では採用活動の一環として、選考に進む前に弊社に対する理解を深めていただきたいという思いから、カジュアル面談を実施しています。 今回は、カジュアル面談で見ていただいている、QAグループ紹介資料を公開したいと思います。 ※ 2022年3月現在の資料のため、古くなっている可能性がありますがご了承ください。定期的にアップデートする予定です。 はじめに カジュアル面談とは？ 弊社のコーポレートサイトより引用します。 SmartHRのカジュアル面談は、転職活動において皆さまが聞いてみたいと思うことを、なんでも聞いていただける場としてご用意しています。 SmartHRにご興味をお持ちいただいたすべての方へ、リアルな情報をお伝えします。 事業や組織のことをはじめ、ご興味をお持ちのポジションがあれば業務内容など詳細に

こんにちは、今年1年でキーボードを3回買い替えたUXライターのkunyです。今は、NiZのATOM 66を使っています。 SmartHRでは、textlintに独自のルールプリセットを追加して利用しています。textlintは4人で運用していますが、自分もメンバーの1人です。この記事では、textlintの便利さを世の中に伝えたく、textlintの利用シーンや利用者の生の声をご紹介します。 ※この記事は、2021年SmartHRアドベントカレンダーの13日目の記事です。 textlintの利用シーン 開発現場において、各自のローカル環境・GitHubと連携したCircleCIで文言の正誤を判定しています。 ローカル環境では、エディター上でコマンドを実行すると、「エラー内容」と「正しい表現」がわかります。コマンドで「正しい表現」に置き換えることもできますが、前後の文脈を確認しながら文言を修

こんにちは。SmartHRでRails顧問業をしています @willnetです。最近は主にリファクタリングをしています。 SmartHRのバックエンドは基本的にRubyで書かれています。しかし入社してくるバックエンドエンジニアは必ずしもRubyやRailsを長年使ってきた人だけではなく、前職では他言語を使っていてRuby(Rails)はほとんど使ったことがないという人もいます。 webアプリケーションを作る、という点ではどの言語でも抑えるべき点は同じですが、RubyやRailsに特化した考え方や書き方もありますよね。SmartHRではそれを効率よく習得してもらうために読書会を開催したり、社内のドキュメントツールに知見を書いて共有したりしています。 僕も社内のドキュメントツールにActive Recordの付き合い方ついて書いたところ、評判が良く「テックブログにしたら？」と言われたので今回一

こんにちは。プロダクトエンジニアの @sugamasao です。 SmartHRのプロダクトエンジニアは中途採用で経験者を採用していますが、必ずしもRuby/Rails経験者ばかりではありません。 今回はそういった方向けに binding.pry でデバッグする際の使い方をお伝えできればなあと筆を取っております。（昨今ではdebug.gemやbinding.irbでも代用できる気配を感じていますが、それはそれということで何卒） また、以下のコードはRuby 3.0.2とPry 0.14.1で動作確認をおこなっています。 binding.pryってなに ソースコード上に binding.pry と記載してからプログラムを実行すると、該当行で処理を中断し、ターミナルから直接プロセス内の状態をpryで参照、変更することができます。 binding.pryで止まると、こんな感じの内容がターミナルに

こんにちは、プロダクトデザイングループの@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グループ方

こんにちは、プロダクトデザイングループのkgsiです。普段はnoteでデザイナー向けの記事を書いたりしてますが、今回は開発組織の取り組み紹介なので、テックブログデビューとなりました、ドキドキしますね。 SmartHRはすでにスクラムに関連する記事が多数公開されているとおり、開発手法としてスクラムが採用されています。 スクラムはすでに開発組織内に十分浸透し、大小さまざまな取り組みが行われていますが、この記事ではSmartHRの組織・チームを活性化を狙った取り組みのひとつ「交代制スクラムマスター」制度の紹介と、実際にスクラムマスターとなって取り組んだこと、その感想を共有したいと思います。 そもそもスクラムマスターって？ 制度紹介の前に「そもそもスクラムマスターって何だっけ？」という方向けに説明しておきますと... スクラムマスターは「スクラムの促進・支援に責任を持って、スクラムチームが生み出す

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

こんにちは。SmartHRでRails顧問業をしています @willnetです。最近は主にリファクタリングをしています。 SmartHRでは毎週「Rubyist@SmartHR（仮）」という名の定例ミーティング*1が行われています。このミーティングはバックエンドエンジニアが集まり、チームをまたいだ情報共有や相談をすることを目的としています。その中では僕がTipsなどを共有する「willnetさんのありがたいお言葉」というコーナーが常設されています。 「willnetさんのありがたいお言葉」のコーナーではRailsの最新動向に関する話をすることが多いのですが、最近はRailsの各種機能がどのように動くのかをクイズ形式にして共有しています。これがなかなか好評なので今回テックブログにしてみた次第です。みんな全問正解できるかな？ ちなみにこんな感じでやってます まず問題と回答の選択肢を見せてからs

これはなに？ SmartHRのプロダクトマネージャー職にご興味をお持ちの方向けに、参考になりそうな情報をまとめております。 最終更新日：2022-2-8 SmartHRについて Mission & Values Mission Values 自律駆動 早いほうがカッコイイ 最善のプランCを見つける 一語一句に手間ひまかける ワイルドサイドを歩こう 人が欲しいと思うものをつくろう 認識のズレを自ら埋めよう 👇 Mission & Valuesの詳細 私たちについて｜株式会社SmartHR 👇 Valueを追加した背景 SmartHR社の「バリュー」を1つ増やしました Service Vision 👇 Service Visionの詳細 SmartHRの想い 会社紹介資料 SmartHR会社紹介資料 👇 いまSmartHRに入社してやることあるの？と思われた方へ 4つの数字で「いまSm