タグ

ブックマーク / tech.smarthr.jp (46)

  • 3年前に勤怠打刻をSlackで完結できるようにしていました 🐢 - SmartHR Tech Blog

    こんにちは、趣味でコーポレートエンジニアをやっていますyamashuです。 タイトルの通りかなり昔の話になるのですが、勤怠打刻の課題解決についてそういえば社外へ向かってアウトプットしていなかったなと思い、この度したためている次第です。 社外と接点が多い営業の社員が弊社での打刻の方法をたまたまお話したりして、その話を聞いた会社様から「話を聞かせてほしい」とヒアリングをいただくことも最近まで何度かありました。 そのため、もしかしたら同じ悩みに直面している方がいらっしゃるかもしれないので、1つの解決策としてやったことを書いておこうと思います。 課題 🤔 勤怠管理SaaS(弊社だとAKASHI)を使っているが、打刻(出勤、退勤)しても人以外にはその結果が見えない、わからない。 そのため、コミュニケーションツールのSlackでも「出勤したよ〜」となにかしらの報告がチームメンバーに対して必要となる

    3年前に勤怠打刻をSlackで完結できるようにしていました 🐢 - SmartHR Tech Blog
    peketamin
    peketamin 2024/07/28
  • React 19 で変わるアクセシビリティ周りの技術 - SmartHR Tech Blog

    こんにちは。アクセシビリティ部のアクセシビリティエンジニアの五十嵐です。SmartHRでは主にアクセシビリティテスターが見つけた課題を技術的な観点から改善したり、根的な問題を解決するための仕組みづくりを担当しています。 さて、Meta が開発する UI ライブラリとして長い間人気を博している React ですが、2024年4月に最新版であるバージョン 19 のRC版が公開されており、注目を集めています。 バージョン 19 では "use client" や "use server" でも知られる Server Components を含む様々な機能が含まれる予定ですが、この記事では、そんな React バージョン 19 をアクセシビリティの観点からキャッチアップし、特に便利になりそうな点や、注意が必要になりそうな点などを見ていきます。 forwardRef が不要になった 仮想 DOM

    React 19 で変わるアクセシビリティ周りの技術 - SmartHR Tech Blog
    peketamin
    peketamin 2024/06/21
  • SmartHRにおけるフルリモートワークの生産性や満足度調査 - SmartHR Tech Blog

    こんにちは。VP of Engineering の morizumi です この記事では2024年2月にプロダクトサイド(注:プロダクト開発に直接的に関わっている各部の総称)内で実施したフルリモートワークに関するアンケート結果のサマリをご紹介します。SmartHR では2021年7月より格的にフルリモート体制に移行しており、移行から2年半ほどが経ちました。2年半を経て、従業員としてフルリモートワークをどのように受け止めているのか? というのを調べるために行ったのが今回のアンケートです なお、この記事は僕が書いた社内ドキュメントからほぼコピペして作っているため、一部わかりにくい用語や言い回しがあったり、若干の内輪ノリがあるかもしれませんがその点はご容赦いただけると幸いです それでは早速、アンケート結果のサマリをご紹介していきます (これ以降基的に社内ドキュメントのコピペです) アンケート

    SmartHRにおけるフルリモートワークの生産性や満足度調査 - SmartHR Tech Blog
    peketamin
    peketamin 2024/05/28
  • 40歳を超えてからあたらしい領域にチャレンジすることの意味 - SmartHR Tech Blog

    はじめに こんにちは。SmartHR プロダクトマネージャーの山根(@sayama)です。 この記事は 「SmartHRのプロダクトマネージャー全員でブログ書く2024」 への参加記事です。 25人が持ち回りで毎週記事を投稿します。ぜひご覧ください! 今回は自分がなぜSmartHRに入社したのか、その気持ちの変遷を振り返ってみようと思います。 自分の市場価値ってなに? SmartHRに入社するまでは、製造業での機械設計を経て、技術者向け情報管理システムの構築以降、自然言語系AIの黎明期からプロジェクトマネージャー・プロダクトマネージャーを経験してきました。業務DXのためのシステム導入や既存プロダクトへのAI機能の付加価値を考えたり、それをグローバルに展開するのも非常に刺激的で、ワクワクしながら推進してきたことをよく覚えています。 キャリアの変遷 改めて自分のキャリアを振り返ると、客観的には

    40歳を超えてからあたらしい領域にチャレンジすることの意味 - SmartHR Tech Blog
    peketamin
    peketamin 2024/04/19
  • プロダクトエンジニアにとって、SmartHRはリモートワークしやすい環境なのか? - SmartHR Tech Blog

    こんにちは、プロダクトエンジニアのゆきです。SmartHRには2021年2月に入社しました。 入社した際は東京に住んでいましたが、現在は大阪からリモートで働いています。 私が入社した頃は、フルリモートワークは許可されておらず、東京オフィスに通勤できる場所に住んでいる必要がありました。 2021年の7月にフルリモートワークが解禁され、日国内ならどこに住んでいても働けるようになりました。 フルリモートワークになって2年以上が経ったSmartHRですが、今回はSmartHRのプロダクトエンジニアが、どのような働き方をしているのかを紹介します! 制度について プロダクトエンジニアグループにおける2023年11月現在のSmartHRリモートワークの制度について、概要を紹介します。 詳細はSmartHRの働き方制度(2023年7月〜2024年12月)をご覧ください。 交通費 東京近郊に居住している

    プロダクトエンジニアにとって、SmartHRはリモートワークしやすい環境なのか? - SmartHR Tech Blog
    peketamin
    peketamin 2024/04/08
    雰囲気良さそう
  • なぜPMが25人も必要なのか - SmartHR Tech Blog

    こんにちは、CPOのadachiです。 この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿しています。 この企画にも関連するのですが、最近社外の方から「SmartHRPM多!」という感想をいただくことが増えてきました。もしPMが多い = 裁量が小さくてつまらない環境、と思われていたら心外すぎる……許せねぇ…… そこで稿では、なぜSmartHRには25人もPMがいるのか、一体なにを作っているのか、仲はいいのか、今後どういったオポチュニティがあるのか、といったことについて説明していきたいと思います。オポチュニティは言いたいだけです。 25人は多い? 結論、そんなに多くないと思っています。 先日「SmartHRがARR150億円を突破、前年比150%で成長」というプレスリリースも出ましたが、私たちは現在ARR 150

    なぜPMが25人も必要なのか - SmartHR Tech Blog
    peketamin
    peketamin 2024/03/22
  • プレースホルダーのアクセシビリティ上の課題と解決策 - SmartHR Tech Blog

    こんにちは!SmartHRプロダクトエンジニアのhimiです。 この記事ではプレースホルダーのアクセシビリティとユーザビリティについての課題と、その解決手段についての話を書きます。 プレースホルダーって何? Webアプリでよく見る、フォームコントロールに値が無いときに表示するテキストのことです。 主な用途としては、フォームの入力例や入力内容の説明テキストが設定されることが多いです。 HTML Standardでは The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief de

    プレースホルダーのアクセシビリティ上の課題と解決策 - SmartHR Tech Blog
    peketamin
    peketamin 2024/03/13
  • 型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog

    SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre

    型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
    peketamin
    peketamin 2024/01/19
  • E2Eテストを Playwright で作り直して開発プロセスに組み込む話 - SmartHR Tech Blog

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

    E2Eテストを Playwright で作り直して開発プロセスに組み込む話 - SmartHR Tech Blog
    peketamin
    peketamin 2024/01/17
  • チーム間コミュニケーションにおける「ただ話す」のすすめ - SmartHR Tech Blog

    この記事は SmartHR Advent Calendar 2023 2nd の12日目の記事です。 こんにちは、SmartHRでプロダクトエンジニアをしているytakaです。 この記事では、チーム間のコミュニケーションにおける、シンプルかつ強力な手法をご紹介します。 それが「ただ話す」です。 ただ話す 「ただ話す」は、チームの輪読会で読んだ『大規模スクラム Large-Scale Scrum(LeSS) アジャイルスクラムを大規模に実装する方法』にて紹介されていたメソッドです。書には以下のように記載されています。 大規模なグループで何年も働き、複数チームにまたがる調整テクニックを数多く観察した結果、最も上手くいきそうなテクニックを発見しました。手順は次の通りです。 (1) あなたは、チームBとの”調整が必要”なことに気づきます。 (2) 立ち上がって、 (3) チームBのところに歩い

    チーム間コミュニケーションにおける「ただ話す」のすすめ - SmartHR Tech Blog
    peketamin
    peketamin 2023/12/13
  • チームのテストフローを見直して、実装時間を2倍に増やした話 - SmartHR Tech Blog

    こんにちは!SmartHRで基機能の開発を担当している、エンジニアのwakasaです。2023年の1月から半年かけて、自チームのテストフロー見直しを行い、実装時間を大幅に増やすことができました。今回はその取り組みをご紹介します。 見直し前のチームの状態 私の所属するEチームは、SmartHRの基機能の中でも、従業員情報やマスターデータの履歴データ管理周りの機能開発を主に担当しています。2023年8月現在、エンジニアが6名、プロダクトマネージャーが1名、プロダクトデザイナーが1名所属しており、QAエンジニアは所属していません。以前はQAエンジニアがチームに所属していましたが、2022年10月にチームを離れました。QAエンジニアがチームを離れたあとはエンジニアがテスト業務を兼務しています。 今回の取り組みを始めるきっかけとなったのは、2022年の年末に実装にどのくらい時間を使えているのか計

    チームのテストフローを見直して、実装時間を2倍に増やした話 - SmartHR Tech Blog
    peketamin
    peketamin 2023/08/06
  • Railsのモデル名をすべて変更した話 - SmartHR Tech Blog

    SmartHRでは開発にRuby on Railsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。 Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと

    Railsのモデル名をすべて変更した話 - SmartHR Tech Blog
    peketamin
    peketamin 2023/06/30
  • プロダクトオーナーを兼務する技術、あるいはその反省 - SmartHR Tech Blog

    みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR機能との連携が前提であり、その基礎的な知識が必要です。さらに

    プロダクトオーナーを兼務する技術、あるいはその反省 - SmartHR Tech Blog
    peketamin
    peketamin 2023/06/13
  • SmartHRのOSSガイドラインを公開しました - SmartHR Tech Blog

    こんにちは、エンジニアのkinoppydです。日は、SmartHRが公開したOSSガイドラインに関してご紹介します。 github.com SmartHR OSS ガイドライン SmartHRでは、すべてのサービスでOSSが使用されています。RubyRuby on RailsReactTypeScriptは必ずすべてのサービスで使われていますし、その他にもたくさんのOSSがSmartHRのサービスを構成しています。これらOSSによってSmartHRのサービスは支えられているので、我々もOSSに対してなにか貢献をすることができると良いなと思っています。しかし、現在社内には業務時間中のOSS活動に関する明示的な文章が存在せず、業務としてOSSにコミットする労務/法務的なルールが不明でした。また、OSS文化に対する経験が浅い人にとっては貢献する方法などもよくわからず、ハードルが高いと感じ

    SmartHRのOSSガイドラインを公開しました - SmartHR Tech Blog
    peketamin
    peketamin 2022/12/14
  • チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog

    SmartHRの基機能と呼ばれるプロダクトでエンジニアリングマネージャーをしている @sugamasao (id:seiunsky) です。 この文章はSmartHR Advent Calendar 2022の2日目のエントリーとして書いています。 はじめに、いくつか前提となる状態をお伝えすると、私の所属している「基機能」プロダクトはScrumを拡張したLeSSというフレームワークを使っており、現在は6チームで1つのプロダクトを開発しています。 さらに、私は今はエンジニアリングマネージャーという立場にいますが、少し前まではこの6チームのうちの1チームに所属するメンバーでした。そのため、これ以降に記載している取り組みは私がチームに所属していた時にはじめたものという認識をしていただけますと幸いです。 テックな話題 #とは リモートワーク主体で仕事をしていると意識的に雑談によるコミュニケーシ

    チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog
    peketamin
    peketamin 2022/12/03
  • SmartHRのアクセシビリティ 2021年の取り組みと2022年の進め方 - SmartHR Tech Blog

    あけましておめでとうございます、SmartHRのプログレッシブデザイングループの @masuP9 です。 振り返り、ってなんか年内に出さなきゃみたいな風潮?雰囲気?あると思うんですけど、必ずしもそうではないと思うんですよね。— ますぴー (@masuP9) December 22, 2021 記事では2021年のSmartHRのアクセシビリティの取り組みを振り返り、2022年の進め方についてチラっとご紹介していきます。 SmartHRにとっての2021年はアクセシビリティの専門家が入社し、その取り組みが加速した年でした。ほとんどのプロダクトでアクセシビリティの改善が行われただけでなく、継続的にアクセシビリティの品質を担保する仕組みづくり、多言語対応、またプロダクト以外でもアクセシビリティの改善が行われました。 目次 アクセシビリティの専門スキルを持つ人の入社 プロダクトはもちろんガンガン

    SmartHRのアクセシビリティ 2021年の取り組みと2022年の進め方 - SmartHR Tech Blog
    peketamin
    peketamin 2022/07/26
  • プロダクトの目的・目標・指標をチームで考えていくために可視化した話 - SmartHR Tech Blog

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

    プロダクトの目的・目標・指標をチームで考えていくために可視化した話 - SmartHR Tech Blog
    peketamin
    peketamin 2022/06/08
  • 2022年のプロダクトマネジメント方針を公開します - SmartHR Tech Blog

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

    2022年のプロダクトマネジメント方針を公開します - SmartHR Tech Blog
    peketamin
    peketamin 2022/02/08
  • SmartHR 社内でスクラム勉強会を開催した話 - SmartHR Tech Blog

    こんにちは! 立ち上げからおよそ半年経ってもいまだ二人しかいないアジャイル推進室のメンバーの一人、エンジニアマネージャーの森住(@t_morizumi)です。 今回は表題の通り、SmartHR 社内スクラム勉強会を開催しましたよ、というお話をしていきます。 社内スクラム勉強会開催にいたる経緯 SmartHR では複数チームが関わる開発には Large Scale Scrum(LeSS)を、単一チームで行う開発ではスクラムや、スクラムの一部プラクティスを取り入れた手法を用いています。 しかし、各チームにスクラムマスターのようなコーチ役が必ずしもいる体制ではなく、チームの改善の方向性づけや問題の検知といった部分に課題を持っていました。 そこで、スクラム(とアジャイル)の理念・概念について改めて学習してもらい、その上で自分たちのチームの状況を観察し、最終的には「各チームで改善の方向性づけ、問題の

    SmartHR 社内でスクラム勉強会を開催した話 - SmartHR Tech Blog
    peketamin
    peketamin 2021/10/01
  • 早くしっかりユーザに価値を届けるためのチケットの書き方 - SmartHR Tech Blog

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

    早くしっかりユーザに価値を届けるためのチケットの書き方 - SmartHR Tech Blog
    peketamin
    peketamin 2021/08/05