React 19 で変わるアクセシビリティ周りの技術 - SmartHR Tech Blog
こんにちは。アクセシビリティ本部のアクセシビリティエンジニアの五十嵐です。SmartHRでは主にアクセシビリティテスターが見つけた課題を技術的な観点から改善したり、根本的な問題を解決するための仕組みづくりを担当しています。 さて、Meta が開発する UI ライブラリとして長い間人気を博している React ですが、2024年4月に最新版であるバージョン 19 のRC版が公開されており、注目を集めています。 バージョン 19 では "use client" や "use server" でも知られる Server Components を含む様々な機能が含まれる予定ですが、この記事では、そんな React バージョン 19 をアクセシビリティの観点からキャッチアップし、特に便利になりそうな点や、注意が必要になりそうな点などを見ていきます。 forwardRef が不要になった 仮想 DOM
ぼくらのスクラム奮闘記 - SmartHR Tech Blog
こんにちは、プロダクトエンジニアのa2cとプロダクトマネージャーのdaisukeです。 本稿では、2024年1月に組成され、スクラムを採用した私たちのチームが最初の3ヶ月間に直面した課題とその改善策、それによってもたらされた変化を共有します。スクラムに参加するエンジニアとPMの多様な視点を取り入れ、実際の経験に基づく具体的な事例をオープンに紹介します。 なお、この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。ぜひ他の記事もご覧ください。 チームの紹介 PM1名・プロダクトエンジニア3名の計4名がコアとなり、価値提供に責任を持ちます。そのコアチームに兼任のプロダクトエンジニア(チーフ)1名・兼任のプロダクトデザイナー1名が加わりチームを構成しています。専任のスクラムマスターはいません。 担当しているプロダクトとプロジェクトは、SmartHR Plu
40歳を超えてからあたらしい領域にチャレンジすることの意味 - SmartHR Tech Blog
はじめに こんにちは。SmartHR プロダクトマネージャーの山根（@sayama）です。 この記事は 「SmartHRのプロダクトマネージャー全員でブログ書く2024」 への参加記事です。 25人が持ち回りで毎週記事を投稿します。ぜひご覧ください！ 今回は自分がなぜSmartHRに入社したのか、その気持ちの変遷を振り返ってみようと思います。 自分の市場価値ってなに？ SmartHRに入社するまでは、製造業での機械設計を経て、技術者向け情報管理システムの構築以降、自然言語系AIの黎明期からプロジェクトマネージャー・プロダクトマネージャーを経験してきました。業務DXのためのシステム導入や既存プロダクトへのAI機能の付加価値を考えたり、それをグローバルに展開するのも非常に刺激的で、ワクワクしながら推進してきたことをよく覚えています。 キャリアの変遷 改めて自分のキャリアを振り返ると、客観的には
なぜPMが25人も必要なのか - SmartHR Tech Blog
こんにちは、CPOのadachiです。 この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿しています。 この企画にも関連するのですが、最近社外の方から「SmartHR、PM多！」という感想をいただくことが増えてきました。もしPMが多い ＝ 裁量が小さくてつまらない環境、と思われていたら心外すぎる……許せねぇ…… そこで本稿では、なぜSmartHRには25人もPMがいるのか、一体なにを作っているのか、仲はいいのか、今後どういったオポチュニティがあるのか、といったことについて説明していきたいと思います。オポチュニティは言いたいだけです。 25人は多い？ 結論、そんなに多くないと思っています。 先日「SmartHRがARR150億円を突破、前年比150％で成長」というプレスリリースも出ましたが、私たちは現在ARR 150
チーム間コミュニケーションにおける「ただ話す」のすすめ - SmartHR Tech Blog
この記事は SmartHR Advent Calendar 2023 2nd の12日目の記事です。 こんにちは、SmartHRでプロダクトエンジニアをしているytakaです。 この記事では、チーム間のコミュニケーションにおける、シンプルかつ強力な手法をご紹介します。 それが「ただ話す」です。 ただ話す 「ただ話す」は、チームの輪読会で読んだ『大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法』にて紹介されていたメソッドです。本書には以下のように記載されています。 大規模なグループで何年も働き、複数チームにまたがる調整テクニックを数多く観察した結果、最も上手くいきそうなテクニックを発見しました。手順は次の通りです。 (1) あなたは、チームBとの”調整が必要”なことに気づきます。 (2) 立ち上がって、 (3) チームBのところに歩い
チームのテストフローを見直して、実装時間を2倍に増やした話 - SmartHR Tech Blog
こんにちは！SmartHRで基本機能の開発を担当している、エンジニアのwakasaです。2023年の1月から半年かけて、自チームのテストフロー見直しを行い、実装時間を大幅に増やすことができました。今回はその取り組みをご紹介します。 見直し前のチームの状態 私の所属するEチームは、SmartHRの基本機能の中でも、従業員情報やマスターデータの履歴データ管理周りの機能開発を主に担当しています。2023年8月現在、エンジニアが6名、プロダクトマネージャーが1名、プロダクトデザイナーが1名所属しており、QAエンジニアは所属していません。以前はQAエンジニアがチームに所属していましたが、2022年10月にチームを離れました。QAエンジニアがチームを離れたあとはエンジニアがテスト業務を兼務しています。 今回の取り組みを始めるきっかけとなったのは、2022年の年末に実装にどのくらい時間を使えているのか計
SmartHRのマルチアプリケーションに分散した従業員データを集約する - SmartHR Tech Blog
こんにちは、プログラマーのkinoppydです。最近はSmartHR内でのプロダクトを横断して開発を行うプロダクト基盤チームというところで仕事をしています。 tech.smarthr.jp GraphQL集めるマンの概念図 分散したプロダクトの課題 SmartHRは、祖業である労務管理と従業員情報を集約している「基本機能」と呼ばれる巨大なアプリケーションと、その「基本機能」にある従業員情報を使い文書配布、年末調整、タレントマネジメントなどを行う小さなアプリケーション群によってサービスが提供されています。各アプリケーションは完全に独立したリポジトリとデータベースを持っており、「基本機能」とのデータのやり取りには公開・非公開のREST APIを利用しています。 SmartHRのプロダクト間の構成概略図 APIで繋がれた基本機能とサービスの世界観には、一つ問題点があります。それは、複数のサービス
Railsのモデル名をすべて変更した話 - SmartHR Tech Blog
SmartHRでは開発にRuby on Railsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。 Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと
入社してわかったSmartHR本体の難しさ - SmartHR Tech Blog
どうも2022年9月にSmartHRに入社したエンジニアの大澤(@qwyng)と申します。SmartHRの本体を開発しています。 SmartHRというサービスは、従業員情報を集約したアプリケーションをコアとし、そのコアと連携する複数のアプリケーションを配置した構成になっています。 そのコアというのがSmartHR本体です。 SmartHR本体は歴史が長いプロダクトです。カジュアル面談でも「キャッチアップはどうされました？」、「SmartHRの開発って技術的に何が大変ですか？」といった質問をよく頂きます。 本記事はそういったSmartHRの開発の大変さを知りたい方に向けて自分が感じたことを言語化したいと思います。 2022年初頭に弊社の@sugamasaoさんがSaaS.techで発表した. 「アプリケーションが大きくてつらい・・・ってこと！？」*1 というスライドを見たことがある方もいると
プロダクトオーナーを兼務する技術、あるいはその反省 - SmartHR Tech Blog
みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらに
2023年、SmartHRのプロダクトマネジメントグループはこんな感じでやっていきます - SmartHR Tech Blog
こんにちは、VP of Product Management の adachi です。 写真は去年の夏、会社の登山部で登った山の様子です。 SmartHRでは、年始に各部署のリーダーがその年の方針を発表することになっています。 去年もプロダクトマネジメントグループ（以下、PMグループ）の方針をこのブログで公開したのですが、意外と多くの反響をいただき、なんと記事を読んで応募してくれた方が実際に入社されたりもしました。うれしい！ 去年の方針はこちら： tech.smarthr.jp そんなわけで、今年もPMグループの方針を公開してみることにしました。少しでもSmartHRのPM組織に興味を持ってもらえたら幸いです。 ちなみに、この文書は「組織の運営方針」であり「プロダクトの方針」ではありません。 社外の方からすると「で、結局なにを作るの？」と思われるかもしれませんが、プロダクトや事業の方向性に
RubyKaigi2022スケジュールアプリ、フロントをNext.jsに移行してみてわかったこと - SmartHR Tech Blog
こんにちは、開発者のkinoppydです。こんにちは。 SmartHRでは、去年から引き続きRubyKaigiにスケジュールアプリを提供しています。事前にRubyKaigiスケジュールから「拙者のセットリスト」を作成してもらい、SNSで他の参加者とシェアして楽しんでもらうことを目的にしています。 これが今年のワイのセトリや！https://t.co/vZ3nGrPlCt #rubykaigi— kinoppyd (@GhostBrain) 2022年9月1日 去年のソースコードを利用しつつ、今年は新しいチャレンジとしてフロントの環境をNext.jsに移行してみようと考えました。去年の時点で、フロントはほぼReactで書かれており、helperという名の実質APIも書かれていたので、そんなに大きな手間にはならないだろうと思いましたが、とはいえ色々と起こったのでその様子をお伝えしたいと思います
SmartHRが「RubyKaigi2022」に協賛します＆「マスクに貼れる！ アイコンステッカー」希望者募集などモリモリのお知らせ - SmartHR Tech Blog
こんにちは！ プロダクトエンジニアのkinoppydです。 SmartHRは自社プロダクトのバックエンド全てをRubyで開発しており、Rubyこそが我々の力こそパワーであると感じ日々を過ごしています。そして今年も、我々は「RubyKaigi2022」に協賛します！！ 3年ぶりの三重県オフライン会場が楽しみですね。 ご存知の方も多いと思いますが、RubyKaigiはプログラミング言語「Ruby」に関する世界最大級の国際カンファレンスです。本イベントをもっと楽しんでいただけるといいなぁ〜と思い、SmartHRのスポンサー内容と募集事項をお知らせします！ SmartHRのスポンサー内容 今年のスポンサー内容は、以下の3点です！ （1）三重県の会場にてブースを出展し、「マスクに貼れる！ アイコンステッカー」＆オリジナルステッカー＆トートバッグを配布 ※マスクは事前申込制です （2）「人労打 -JI
Google Apps Scriptで、社内プロダクトのnpmライブラリの利用状況をスプレッドシートに出力してみた話 - SmartHR Tech Blog
こんにちは！SmartHRのプロダクトエンジニアの@diescakeです！ 今日は「Google Apps Scriptで、社内プロダクトのnpmライブラリの利用状況をスプレッドシートに出力してみた話」を題材にしつつ、主にGoogle Apps Script（以降GAS）の開発環境周りの話をします。技術の分野としてはWebフロントエンド（以下フロントエンド）に関連した話が多くなります。 全体の構成図はこんな感じです！ ソースコード管理から、スプレッドシートに反映されるまでのデータフロー図 大まかな構成・データフローは上図のような感じで、主な技術スタックとしては、GAS + Clasp + TypeScript + esbuildを採用しました。 この図を左側から見ていくと、まずGitHubでソースコードを管理していて、昨今のフロントエンド開発と同様に、TypeScriptでコードを書き、必
ヘルプページ作成タスクの透明性を上げたら、UXライターの経験知を共有知に昇華できた話 - SmartHR Tech Blog
こんにちは、UXライターの8chariです。早いものでSmartHRに入社して1年が経ちました！初めてTech Blogを書くのでドキドキしています。 SmartHRでは、フィーチャーチームでプロダクトを開発しており、開発プロセスの改善を日々行なっています。 この記事では、私が所属しているBチーム*1でヘルプページ作成のプロセスを見直し、チームのボトルネックを解消しようとしている話を紹介します。 特定の業務を担当できるメンバーが限られていて、以下のような課題を感じている方の参考になると嬉しいです。 必要なノウハウや知見がほかのメンバーに広まらない プロジェクトのボトルネックになっている 担当できるメンバーの負荷が高くなっている 前提 UXライターがいる開発現場はあまり多くないと思いますので、前提を説明します。 SmartHRのUXライターは「言葉の力でプロダクトを、もっとわかりやすく」する
【ほっかほかになりたい】ともに学ぶ関係性を温めるために行ったSmartHR PMの上半期の取組み - SmartHR Tech Blog
こんにちは。SmartHRでプロダクトマネージャー（以下PMと記載）をしているhiroki_mです。 SmartHRのPM組織であるPMグループでは、今年の年初に方針を以下のように定めました。 PMグループ方針 今回は、このグループ方針の3つの要素「大きく考える」「小さく動く」「ともに学ぶ」のうち「ともに学ぶ」を進化させていくために行った取組みについて紹介したいと思います。 ※PMグループ方針については「2022年のプロダクトマネジメント方針を公開します」に背景や詳細が説明されているので、興味を持たれた方はそちらをご覧ください。 「ともに学ぶ」とは？ 「ともに学ぶ」がグループ方針として規定された意図として、adachiさんは次のように述べています。 PMもプロダクトも増えるなかで「横連携大事だよね」という意識は徐々に浸透してきたと思いますが、横連携という言葉は「必要なときにお互い調整しよう
プロダクトの目的・目標・指標をチームで考えていくために可視化した話 - SmartHR Tech Blog
こんにちは、プロダクトマネージャー（以下PM）の adachi です。（ToDo: ここになにか面白い文章を入れる） 先日、プロダクトの目的・目標・指標をまとめた図をTwitterに投稿したところ、わりと反響があったのでこちらで解説したいと思います。 開発メンバーから「会社の戦略とプロダクトの目標がどう紐付いてるかわからない」という声をもらって作った図。 改めて整理する中で自分のなかでも気付きがあり、もっと早くやっておけばよかったなと思いました。 pic.twitter.com/tuedZhaZG2— Takashi Adachi (@asanebo_) 2022年6月1日 この記事でお伝えしたいこと 会社のミッションや戦略とプロダクトの目的・目標・指標は、構造的に整合していることが重要である PMにとって自明に思えることでも、アウトプットしなければチームで共有できない 目的・目標・指標の
オーナーシップの持ちやすさを目指した、大規模プロダクト開発体制変更の裏側 - SmartHR Tech Blog
こんにちは。「SmartHR基本機能」でプロダクトオーナーをしている塚本です。 この記事では「SmartHR基本機能」の開発体制変更の経緯とその後の状況、開発チームからの声を紹介しています。大規模プロダクトにおいて以下のようなモヤモヤを抱えている方の参考になると幸いです。 提供機能が多岐にわたるため すべてを把握するには認知負荷が高すぎる ゴールの設定難易度が高い 開発チームの思考が担当機能に閉じやすい はじめに SmartHRには、大きく分けて2種類のプロダクトがあります。ひとつはコア機能である「基本機能」で、もうひとつは基本機能にアドオンする形で使える「オプション機能」です。 この記事では、「基本機能」の開発体制について記載しています。 SmartHR「基本機能」の開発では大規模スクラム（LeSS）を採用しており、現在は6チームで構成されています。各開発チームにはPM、エンジニア、デザ
SmartHRにおけるクロスファンクショナル実践例 - SmartHR Tech Blog
こんにちは！ SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。 SmartHRでは顧客の価値の最大化を目指し、日々開発プロセスの改善を行っています。 特に私の所属する基本機能のDチーム*1では、以前からクロスファンクショナルを強く推進しています。 本日はクロスファンクショナルとは何なのか？やってみてどんなメリットがあったのかをまとめました。 クロスファンクショナルとは スクラムガイドでは機能横断型と翻訳されています。 機能横断型というのは、エンジニアリング、デザイン、QAなど複数の職能（スキル）を持つことを表しています。 そして機能横断型という言葉は、チームに対して使われることが多いですが、個人に対しても使われます。(例: プロダクトエンジニアがデザインもできる、QAエンジニアがコードも書けるなど) SmartHRにおいてチームが機能横断型であること
フィーチャーチームについてまとめてみた - SmartHR Tech Blog
こんにちは、SmartHR本体機能の開発をしているkouryouです。 SmartHRでは毎月多くの方が入社しており、日々組織が拡大しています。 しかし一般論ですが、組織は拡大とともに分業化が進み、顧客価値を中心にチームで仕事することが難しくなっていきます。 実際SmartHRでも同じ課題感がありました。 そこで当時、組織が拡大しても顧客価値を中心にプロダクトを作るための考え方である「フィーチャーチーム」に注目し、推進しました。 今回は当時理解を促すために社内向けに書いたドキュメントを改めてまとめてみました。 フィーチャーチームとは エンドツーエンドで顧客中心の機能を実現する、安定した長期存続するチームのことです。 出典: 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 何かしらの案件を「着想」レベルで受け取り、チームメンバーだけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
