はてなブックマーク

こんにちは、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

こんにちは、セキュリティエンジニアの岩田です。今回はSmartHRで先月から導入したメールセキュリティ機能のBIMI(Brand Indicators for Message Identification)についてご紹介します。 BIMIとは? BIMIは、送信者ドメイン認証の仕組みであるDMARC(Domain-based Message Authentication, Reporting, and Conformance)により認証されたメールに対して送信元企業のロゴを表示することで、なりすましではない正規のメールであることを視覚的に判別できるようにするための仕組みです。 DMARCでは、SPF(Sender Policy Framework) または DKIM(DomainKeys Identified Mail) で認証されたメールの送信元ドメインと、メールヘッダの差出人(From

こんにちは、はじめまして。SmartHRのQAグループ所属の平澤（以下、higesawa）と申します。 本記事は、「SmartHRのQA（品質保証）」連載企画の第2弾です。 SmartHRのQAグループはソフトウェアテストを中心に、メンバーのスキルセットやプロダクトの状況によって、柔軟かつ多岐にわたるアプローチで品質保証活動を行っている組織です。今回は私higesawaが入社後、配属されたチームでどんなことをしてきたのかをチームの歩みとともに紹介していきます。 自己紹介 2020年12月入社。これまでSNS・ブラウザゲーム・スマホアプリ・IoT製品などの業界でQAとして従事。SmartHRにて初めてのアジャイル開発を経験し、かつて経験したメテオフォール型開発との違いに驚愕。現在はプロダクト開発の1チームに入り、品質保証活動を行っている。 チームの立ち上げ期 まず私の担当するチームについて簡

こんにちは。PM（プロダクトマネージャー）のhiroki_Mです。 年末調整を担当しています。趣味はお絵描きと虚無になることです。 2年前に私が公開した記事「スクラムをうまく回すために受け入れ基準をきちんと書く」が、現在も思ったより多くの方にご覧いただいていることがわかりました。 スクラムやアジャイルについては様々な記事が出ているものの、現場目線での実体験に基づく情報を得たい人は多いのかも、と思い、前回書いたものをアップデートした記事を書くことにしました。 この記事では、「早くしっかりユーザに価値を届けるための、チケットの書き方のポイント」をテーマに、スクラムをうまく回す※ために気をつけるべきチケットの書き方のポイントについて書こうと思います。 やりたいことと開発者をつなぐのがチケットです。開発プロセスをカイゼンしても、チケットがきちんとしていないと、その効果は表れづらいです。逆に、やりた

こんにちは、SmartHRでコーポレートエンジニアをやっています yamashu です。 今回は社内向け全社ヘルプデスクシステムを導入した話を書いていきます📝 会社の成長が早すぎることでヘルプデスクが抱えた課題😇 会社と事業が順調に成長していっている SmartHR では人的リソースの確保が大きな経営課題でもあり、採用に力を入れ一緒に働く仲間を増やしてきました📈 毎月10〜20人くらいの新入社員の方を受け入れるというのが日常風景になっています。 SmartHR会社紹介資料 / We are hiring - Speaker Deck 社員の増加に合わせて、情シスへの問い合わせも順調に増え続けました。 最近では月の問い合わせ件数が300件を超えそうなラインにまできています。 そんな情シスのヘルプデスクですが、Slack Workflow をベースにした trello と連携する仕組みを

こんにちは！CTO の芹澤です。 今回は SmartHR のプロダクトチームで行われているリモートワークの状況と、今後の働き方に関するお話です。 昨年度よりコロナ禍における暫定対応として採用されていたリモートワークを前提とした働き方について、そろそろ恒久的な方針を決めようということで、先日以下のような社内報が発表されました。 shanaiho.smarthr.co.jp 結論から申しますと、プロダクトチーム1としては今後もリモートワークを継続して、場所にとらわれない働き方を続けていこう、という判断となりました。これにより、通勤圏外からフルリモートで働く、というようなことも可能となっています。 上記記事にもこの結論に至った背景は書かれているのですが、ここではリモート下でのプロダクトチームの働き方の変化を紹介しつつ、もう少し踏み込んだ背景や意図の説明をさせていただければと思います。 私たちは今