中途入社の私からみた、SmartHRのユニークなコミュニケーション文化
はじめまして。SmartHRでプロダクトエンジニアをしているshuutieです。2026年2月にSmartHRに入社し、SmartHRオプション機能の開発に従事しています。 入社して4ヶ月ほど経ちますが、この数ヶ月を通して、「SmartHRって改めていい文化を持っているな」と感じたことがいくつもありました。 特に強く感じたのが、コミュニケーションの総量が多く、かつ質が高い（そして何より楽しい！）ということです。 この記事では、中途入社の視点から「SmartHRで開発するってこういう感じ」を、特徴的だと思ったコミュニケーションを交えながら紹介します。読者の皆さんに、当社の開発組織の雰囲気が少しでも伝わればうれしいです。 実際に入ってみて、SmartHRは「コラボレーションをうまくいかせるための工夫や文化」がかなり言語化・習慣化されていると感じています。その中でも特に印象的だったものを3つ紹介します。 Slack絵文字の圧倒的な多さ 私が一番驚いたのは、Slackの絵文字の量と多様さです。カスタム絵文字の数は、2026年6月現在でなんと40,860個！ 会話の中に自然に絵文字が飛び交い、メッセージには次々と多彩なリアクションが付きます。 Slackでのやりとり 最初は「絵文字が多すぎでは？」と思っていたのですが、使っているうちに、これが単なるノリと勢いではなく、テキスト中心だからこそニュアンスを丁寧に補っているんだな、と腑に落ちました。 例えば、同じ「OK」でも、👍なのか✅なのか🙆なのかで、使い所や受け取り方は微妙に違いますよね。 絵文字を使うことによって、テキストで「了解です。」とだけ送るよりも、少しだけ多くの情報を読み手に伝えることができたり、受け取る側にやさしそうな印象を与えることができたりします。 ちなみに私の好きな絵文字は、「恐竜」です。 恐竜の絵文字。「共有」の語呂合わせとして使用される 実はこれ1つで、「共有」のことを表しています。 「共有です。」とだけ書くより、少し温かみを感じますよね。 ミーティングごとにスレッドを立てて、実況する SmartHRでは、ミーティングを実施中、Slackのスレッドで実況するのが当たり前です。 このスレッドに、議題・感想・メモ・決定事項・宿題・軽い冗談などがどんどん発信されていきます。 これの何が嬉しいかというと、ひとつは大人数でも意見が埋もれにくいことです。 特に私たちが所属するチームはフルリモートで開発しているため、ミーティングもリモート中心です。 リモートミーティングでは、リモート特有の「発言してから音声が乗るまでにタイムラグがある」「一度に音声を拾えるのは一人だけ」といった物理的制約に直面しがちです。 一方、ミーティング単位のスレッドになんでも書き込んでよい、というルールがあれば、「声を出す」というハードルそのものがなくなります。 口頭の議論を止めずに、「それって〇〇の件ですか？」と関連リンクを貼ったり、「その視点漏れてました！」とテキストで挟んだりできるので、言い忘れる・深く考えずに発言するなどの行動が減ります。結果としてミーティングの情報密度が上がると言えます。 例えば、先日チームで実施したとある書籍の輪読会では、「コーディングのWhyをどこに書くか」というテーマで以下のようなやりとりがされていました。 輪読会実況スレでのやりとり このようにテキストでのやりとりが増えると、同時に発言しているのは1〜2人だとしても、大人数のミーティングで手持ち無沙汰の人がほぼ誰もいない状態を作ることができます。 もうひとつは、意思決定や重要事項の背景情報がテキストに残ることです。 実況スレッドを残しておくことで、「この決定って、どの会話の流れでそうなったんだっけ？」が後から辿れます。 例えば先日、私が別件の対応中に開かれたミーティングで、ある重要なテーマについて議論していたことがありました。 正式な議事録ができる前の段階でしたが、実況スレッドのおかげで、隙間時間に密度の濃い情報をキャッチアップすることができました。スレッドが残っていなければ、あとで他のメンバーに「さっきの会議どうだった？」と聞くしかなかったはずです。 このように、テキストで情報が残っていることの恩恵は大きいと感じています。 ドッグフーディング文化の浸透 いわゆるドッグフーディング（自社プロダクトを自分たちで使い込んで改善につなげる取り組み）のためのSlackチャンネルが活発です。誰もが気づいたことを自由に投げています。SmartHRを支える文化の一つとして、個人的には最も印象的でした。 「とはいえ、活用されてないんじゃないの？」 「投げっぱなしになっていて、形骸化しているんじゃないの？」 と思う方もいるかもしれませんが、そんなことはありません。実際に開発側がそれを拾ってプロダクト開発に反映していくケースは多くあります。 例えば、私が担当するプロダクトで、「チェックボックスの選択範囲が見た目上の広さと合っていない」というフィードバックをいただくことがありました。 チームメンバーはドッグフーディングチャンネルを巡回していたところ、このフィードバックが目に留まり、不具合と判断、このケースでは数日で修正しました。 フィードバックしていいよ！という価値観や空気感だけでなく、あげた声がちゃんとプロダクトに反映されるところまで含めて、いい循環ができているなと思います。 まとめ 今回は中途入社目線で見た、SmartHR特有のコミュニケーションカルチャーを紹介してきました。 絵文字で温度感を、実況スレで透明性を、ドッグフーディングで当事者意識を高める。こうした小さな工夫の積み重ねが、リモート中心でも質の高いコラボレーションを支えているのだと感じています。 We Are Hiring! SmartHRでは一緒にSmartHRを作りあげていく仲間を募集中です！ こんな文化のなかで、一緒にプロダクトを良くしていきたい、日本の未来をよくしていきたいと思った方は、ぜひ一度カジュアル面談でお話ししましょう。 hello-world.smarthr.co.jp
- Slack
- 働き方
人工知能学会全国大会（第40回）にシルバースポンサーとして協賛、研究発表を行いました！
SmartHRのML（機械学習）エンジニアの井上です。 SmartHRは2026年6月8日〜12日に群馬・高崎のGメッセ群馬で開催された「2026年度 人工知能学会全国大会（第40回）（JSAI2026）」にシルバースポンサーとして協賛、および研究発表を1件行いました。 現地組・リモート組を合わせて複数のメンバーが参加し、「うちのプロダクトに使えるのでは？」と大盛り上がりの5日間でした！ 人工知能学会全国大会とは 人工知能学会全国大会は、AI技術に関する国内最大の学会です。 機械学習の基礎・応用研究から産業応用まで幅広い発表が集まり、AIの最新動向を把握できる機会として毎年多くの参加者が集まっています。 今回の第40回大会は40周年にあたる節目の大会で、約5000人の参加者が集まりました！ 人工知能学会全国大会（第40回） 今年の研究トレンドの変化 JSAI2026の全発表タイトルをキーワードで分析し、昨年の傾向と比較したところ、興味深い傾向が見えてきました！ 技術テーマ出現頻度ランキングの変化（JSAI2025→JSAI2026） 発表の出現頻度をもとにランキングをスロープチャートで比較すると、「LLM・基盤モデル」「AIエージェント」「対話・会話AI」の上位3テーマは今年も順位変動がなく、この領域が引き続き学会全体の中心軸であることが確認できました。 一方で最大の急上昇は「生成AI」で、19位から7位へと12ランク上昇、「ロボット・フィジカルAI」も13位から6位へ7ランク浮上しており、フィジカルAIへの関心が学術研究の領域にも着実に波及していることがうかがえます。 最大の急上昇を見せた「生成AI」も、発表の内容は多岐にわたっていました。生成AI自体を技術として扱う研究だけでなく、keep4o を代表とする生成AIをめぐる人間・社会の動きの考察、生成AIを要素技術として活用したシミュレーション研究、プロダクト活用の実践知を共有する発表も増えており、生成AIが「研究する技術」から「社会に埋め込まれた前提」へと変わりつつあることを実感しました。 SmartHRからの発表 SmartHRからは1件の機械学習領域における口頭発表を行いました！ 敵対生成プロンプト同時探索による内省型プロンプト最適化 発表者: 井上 耕太朗 セッション: 4M5-GS-2f-05（6/11 16:30-16:45） LLMアプリケーションのプロンプト最適化に関する研究です。SmartHRでは RAG を活用した AI アシスタントなど様々な LLM アプリケーションを提供していますが、これらをローンチ前から高品質な状態に保つには、プロンプトを事前に検証・改善しておくことが重要です。しかし従来のプロンプト最適化手法の多くは大量のラベル付きデータを前提としており、ローンチ前の段階では活用しにくいという問題がありました。 今回の研究ではこの課題に取り組み、目的タスクを正しく解くプロンプトと、目的タスクを欺くための敵対的な生成プロンプトを同時に育てる手法「Adversarial GEPA」を提案しました。ラベル付きサンプルがわずか4〜8件という少数データの設定においても、既存手法（GEPA）を上回るプロンプト改善を実現しています。 発表をする井上 発表に使用したスライドは Speaker Deck で公開しています。 speakerdeck.com We Are Hiring! SmartHRでは最新技術に明るいメンバーが集まった環境で、革新的なAIプロダクトづくりに取り組んでいます。 ぜひ一度SmartHRのAIチームにご興味をお持ちの方へをご覧いただき、お気軽にお問い合わせください！ tech.smarthr.jp
- 生成AI
- LLM
- 機械学習
SaaS管理ユニットはなぜモジュラーモノリスから始め、マイクロサービスへ移行しているのか
こんにちは。SmartHRの情シスソリューション開発部 SaaS管理ユニットでプロダクトエンジニアをしているnoriです。 先日、関ヶ原Ruby会議 01のスポンサーLTで「SmartHR情シス領域・立ち上げの裏側」というテーマで発表しました。発表では、SaaS管理ユニットが情シス領域のプロダクトをどのように立ち上げ、現在どのようなアーキテクチャ移行に取り組んでいるのかを紹介しました。 この記事では、LTの内容をもとに、SmartHRのSaaS管理ユニットがモジュラーモノリスで開発を始めた理由、その後に見えてきた課題、そしてマイクロサービスへ段階的に移行している現在の取り組みを紹介します。 SaaS管理ユニットって…… SmartHRは、人事労務領域だけでなく、情報システム部門向けのサービスにも取り組んでいます。 この領域への取り組みは、2023年10月にメタップス社から「メタップスクラウド」の事業譲渡を受けたことをきっかけに始まりました。SmartHRが情シス領域に取り組む背景については、「『人事が』使うサービスから、『HRのデータを』使うサービスへ。情シス領域進出の背景と、目指す未来」でも紹介しています。 SmartHRには、入退社や異動、所属・役職などの従業員データが集まります。この従業員データを活用することで、外部SaaSへのシングルサインオンや、SaaSアカウントの管理をより効率化できます。 たとえば、IdP（Identity Provider）機能ではSmartHRを起点に外部SaaSへログインできます。また、ID管理機能ではSmartHR上の従業員データをもとに、外部SaaSのアカウントを可視化したり、作成・削除したりできます。 SaaS管理ユニットは、こうした情報システム部門向けの価値を届けるために、IdP機能やID管理機能の開発に取り組んでいます。 立ち上げではモジュラーモノリスを選んだ SaaS管理ユニットは、情シス領域の立ち上げ時に、SmartHRの基本機能のモノリス内にモジュールを作る形で開発を始めました。 モジュラーモノリスアーキテクチャにすることで、新しくインフラを一から用意する必要がなく、既存の認証や権限、デプロイ基盤を利用できます。また、同じデータベース上で開発できるため、従業員データをActive Record経由で扱いやすく、SmartHR上の従業員データ・マスタデータをもとに、シングルサインオンできる従業員を制限したり、SaaSのアカウントの所有状況を可視化する、といった機能を容易に実現できました。 結果として、IdP機能は約半年でリリースできました。 モジュラーモノリスで課題も見えてきた モジュラーモノリスで始めたことで初速は出せましたが、プロダクトが成長するにつれて課題も見えてきました。 1つ目は、可用性の課題です。情シス向けの機能は、従業員が日々の業務で外部SaaSにアクセスするための入口になります。しかし、基本機能側がメンテナンスやインシデントの影響で止まると、IdP機能やID管理機能も止まってしまいます。 特にIdP機能は、利用者にとってログイン経路そのものです。年末調整のような労務機能のメンテナンスや、基本機能内の別プロダクトの障害によって、外部SaaSへのログイン体験に影響が出る構造は避けたいものでした。 2つ目は、パフォーマンスの課題です。SmartHRの従業員データは、過去・現在・未来の状態を扱うためにBitemporal Data Modelを採用しています。Bitemporal Data Modelは履歴データを正確に扱える一方で、従業員という大きなモデルを扱うため、関連するテーブルやカラムが多くなりやすい構造です。 SaaS管理ユニットの機能では、従業員データを参照しながら外部アカウントと突き合わせる処理が多くあります。しかし、情シス領域から見ると不要なテーブルやカラムがあっても、基本機能側のデータ構造の上に乗っている以上、用途に合わせて簡単に整理できるわけではありません。ユースケースに合わせてインデックスを追加したくても、情シス領域だけの都合で基本機能側のテーブルに多くのインデックスを増やす判断はしづらく、扱う従業員数が増えるほど難しさが大きくなっていきました。 3つ目は、開発体験の課題です。現在改善中ではありますが、大きなモノリスの中で開発しているため、CIに30分以上かかることがありました。デプロイは1日1回で、ステージング環境へ反映されるまでにも時間がかかります。ローカル開発でもrails sの起動に時間がかかり、フロントエンドからAPIを呼び出すだけでも数秒待つことがありました。 SaaS管理ユニットでは、AIも活用しながら、一人ひとりがフィーチャーを担当して一気に進める開発体制をとっています。そのため、小さく直してすぐ確かめたい場面が多く、CIや起動の待ち時間が積み重なると、開発の勢いを保ちづらくなっていました。 マイクロサービスへ段階的に移行している SaaS管理ユニットは、現在マイクロサービスへの段階的な移行を進めています。 移行で大切にしているのは、一気に切り離すのではなく、依存関係をほどきながら段階的に独立性を高めることです。すでにお客様が使っている機能を止めずに移行する必要があるため、リスクを小さく分けて進めています。 基本機能への依存を整理 最初のステップでは、Packwerkを使って基本機能への依存を整理しました。従業員マスタなど、基本機能側のデータに直接触っていた箇所を、Public APIを介したメソッド呼び出しへ寄せていきます。 この段階で得られたのは、切り離す前に境界を見えるようにできたことです。どこが基本機能に依存しているのか、どの呼び出しをサービス間のインターフェイスとして扱うべきなのかを、コード上で確認しやすくなりました。 依存をHTTP通信に置き換え 次のステップでは、その依存をHTTP通信に置き換えました。これにより、同じモノリス内のメソッド呼び出しではなく、サービス間通信に近い形で境界を扱えるようになります。 この段階では、レポジトリを分ける前に、通信の失敗やレスポンスの扱いを含めてサービス間通信の形に慣れることができました。まだ同じモノリス内にコードがある状態で、切り離した後のインターフェイスを先に育てられたのは大きかったです。 レポジトリの分離 現在は、レポジトリを分離した段階にいます。IdP機能やID管理機能のコードベースを基本機能から切り出し、あわせてインフラも新しく作って分離しました。 APIの移行では、既存のAPIを一度に置き換えるのではなく、ストラングラーパターンを使って段階的に移しています。既存の経路を残したまま、新しいサービス側へ処理を少しずつ移し、VPC内のHTTP通信を通じて必要なデータにアクセスする構成へ変えていきました。 一つの機能に新旧のAPIが共存する期間があるため、腐敗防止層を設けて差分を吸収しながら移行しています。すでにお客様が使っている機能を止めないように、置き換えられるところから少しずつ新しいサービス側へ寄せています。 レポジトリとインフラを分けたことで、CIやデプロイ、ローカル開発を対象サービスに閉じられるようになってきています。機能を届けるための待ち時間を減らし、SaaS管理ユニットの開発リズムに合った環境を作りやすくなっています。 今後の予定：データベースの移行 今後は、データベースの移行にも取り組む予定です。基本機能側の従業員データを直接参照するのではなく、バッチやWorkerによるデータ同期を通じて、SaaS管理ユニット側のサービスが必要なデータを持てるようにしていきます。 データベースを分けることで目指しているのは、可用性とパフォーマンスの面でも独立性を高めることです。必要なデータをSaaS管理ユニット側の用途に合わせて持てるようにし、基本機能側のデータ構造に直接依存し続ける状態から少しずつ離れていきます。 移行によって開発速度とパフォーマンスが改善してきた 移行はまだ完了していませんが、すでに効果が出始めています。 デプロイでは、1日1回という制限から解放されました。小さな修正や改善をモノリス全体のリリースサイクルに合わせる必要がなくなり、対象サービスの都合で届けやすくなっています。 CIも大きく改善しています。以前はモノリス全体のCIに30分以上かかることがありましたが、まだ移行途中ではありますが移行後のサービスでは約1分で終わるようになりました。AIを使って一人ひとりがフィーチャーを進める開発体制では、レビュー前に小さく直してすぐ確認できることが重要なので、この差はかなり大きいと感じています。 ローカル環境でも、rails sの起動が速くなりました。大きなモノリスを立ち上げるのではなく、対象サービスに閉じて開発できるため、画面を開いてAPIの挙動を確認するまでの待ち時間が短くなっています。 さらに、レポジトリを分けたことで、新しい開発基盤も取り入れやすくなりました。実際にRubyDex、Sorbet、Caddyなどを導入し、対象サービスに閉じた形で運用できています。モノリス全体へ一気に導入するには影響範囲が大きい技術でも、小さな単位で取り入れられるようになりました。 パフォーマンス面でも改善の兆しが見えています。たとえば、従業員に紐づく従業員テーブルを結合して取得する処理では、必要なデータをSaaS管理ユニット側の用途に合わせて持つことで、モノリス側の複雑なデータ構造に直接アクセスする回数を減らせます。まだ移行途中であり、厳密なベンチマークではありませんが、現時点で取得できている値を比較すると、次のような傾向がありました。 従業員データ数 移行前最遅 移行後最遅 速度比 1,000件 207ms 57.6ms 3.59倍 10,000件 2.30s 614ms 3.75倍 50,000件 13.7s 3.07s 4.46倍 従業員データテーブルの行サイズも約71%削減できました。必要なデータをサービス側の用途に合わせて持つことで、複雑な履歴データに都度アクセスする構造から少しずつ離れられています。 モジュラーモノリスで始めたから移行できた 今回の経験から、モジュラーモノリスで始めることと、マイクロサービスへ移行することは対立する選択肢ではないと感じています。 最初から別サービスとして作っていたら、インフラやデータ連携の準備に時間がかかり、IdP機能を今の速さで届けるのは難しかったはずです。立ち上げ時点では、既存の仕組みを使いながらプロダクトとして成立するところまで早く持っていくことが重要でした。その意味で、モジュラーモノリスは当時の状況に合った選択だったと思います。 一方で、モノリスの中でもモジュールとして境界を切っていたことで、後から見返したときに「ここまでは情シス領域の責務」と判断しやすい状態を作れていました。機能が育ってから分離を考え始めても、責務の境界がまったく見えていなければ、どこから手をつけるかを決めるだけでも時間がかかります。 Packwerkを導入していたことで、普段の開発でもモジュール間・サービス間の依存を意識しやすくなりました。 移行を進める場面でも、Packwerkで依存関係を見たときに、このメソッドは情シスモジュールからしか呼ばれていない、ここは基本機能に依存している、といったことが分かるのは助かりました。基本機能への依存が見えれば、Public API経由の呼び出しに置き換えながら少しずつ剥がしていけます。小さく確認しながら進められたことで、稼働中の機能への影響を抑えながら移行できました。 まとめ モジュラーモノリスは、立ち上げのための現実的な選択肢でした。そして、境界を意識して作っておくことで、後からマイクロサービスへ移行するための足場にもなりました。 今回の移行を通じて得た学びは、最初から完成形のアーキテクチャを選ぶことよりも、その時点で価値を届けやすい形を選びつつ、後で変えられる余地を残しておくことの大切さです。立ち上げ期にモジュラーモノリスで速く進み、成長に合わせて必要な独立性を高めていく進め方は、SaaS管理ユニットにとって自然な選択だったと感じています。 We Are Hiring! SmartHRでは一緒にSmartHRを作りあげていく仲間を募集中です！ SaaS管理ユニットでは、SmartHRの従業員データを活用しながら、情報システム部門の業務をより良くするプロダクトを作っています。情シス領域のプロダクト開発や、大きなシステムを段階的に分離していく取り組みに興味がある方は、ぜひカジュアル面談でお話ししましょう！ hello-world.smarthr.co.jp
- Ruby
- Rails
- マイクロサービス
SmartHR UI の2025年を振り返る
こんにちは、アクセシビリティエンジニアでSmartHR UIコアメンバーの tajiman です。 SmartHR UI は SmartHR のプロダクトで使われているコンポーネントライブラリです。この記事では、SmartHR UI の2025年の活動を振り返ります。 ※2025年度ではなく、2025年の活動です。いいえ、間違いではありません。 SmartHRでは、SmartHR UI がどのように成長してきたか毎年振り返りをしています。 昨年の振り返り記事はこちらです。 SmartHR UI の現在地 SmartHR UI の2024年12月時点と2025年12月時点の数値を比較します。 項目 2024/12/13 2025/12/18 バージョン v62.2.0 v82.0.0 コンポーネント数 *1 100 99 ソースコード規模 *2 32,108行 43,664行 コミット数 *3 5,754 6,430 コントリビューター数 *4 83人 119人 バージョンは v62.2.0 から v82.0.0 へと20のメジャーバージョンが上がりました。コントリビューター数は83人から119人に増えました。 コンポーネント数が100→99と微減しているのは、リネーム（CheckBox→Checkbox 等）に伴う統廃合や ActionDialogContent、MessageScreen 等の削除が、新規追加（SmartHRAILogo、StepFormDialog等14個）を一部相殺しているためです。 コントリビューター 2025年のコミット数上位10名を紹介します（同率10位を含む）。 順位 名前 コミット数 1 Mizoue Atsushi 187 2 たふみ 82 3 KANAMORI Yu 26 4 Tajima Sachiko 13 5 Ryō Igarashi 9 6 shingo.sasaki 5 6 Kei Kono 5 6 oti 5 6 Misako Tateiwa 5 10 nabeliwo 4 10 Takatsugu Kageyama 4 10 Daichi Hashimura 4 コントリビューターの皆さん、ありがとうございます。 開発・運用体制 SmartHR UI のコアメンバーは7名（エンジニア4名、デザイナー3名）で構成されています。昨年と同様に専任のメンバーはおらず、有志による運営を続けています。 週次の定例ミーティングを開催し、課題の共有や方針の議論を行っています。 リリース リリース作業は昨年に引き続き自動化されており、週1回のペースで実施しています。2025年は v63.0.0 から v82.0.0 まで、20のメジャーバージョンをリリースしました。 アクセシビリティへの取り組み SmartHR UI ではアクセシビリティの品質向上に継続的に取り組んでいます。 2025年には12件のアクセシビリティに関するPRがマージされました。 代表的なものとして チャートを色のみで表現しないようにした というPRがあります。 色だけに頼らず、模様（パターン）で系列を区別できる棒グラフ 棒グラフを色のみではなくパターンを付けることで、色覚特性をもつユーザーでも判別ができるようにしました。 ESLint カスタムルール 2025年には、テーブルセル内でのCheckboxやRadioButtonの使用を禁止するルールなど、12件の新しいルールが追加されました。 アクセシビリティ関連：18 ルール その他：34 ルール 合計 52 ルール おわりに SmartHR UI は2025年も多くのコントリビューターに支えられながら成長を続けました。 まだまだやりたいことが山ほどあるため、引き続き沢山のコントリビューターとレビュワーを募集しています！ We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp *1:packages/smarthr-ui/src/index.ts から export されているコンポーネントの数をカウント。Icon は export * でまとめてエクスポートされているが1つとしてカウント。hooks・テーマ・定数・i18n 関連の export はカウント対象外。なお、2024年以前の計測とは数え方が若干異なる（以前は Storybook を作成している外部向けコンポーネントの数をカウントしていた）。 *2:cloc で packages/smarthr-ui/src を計測（空行・コメント除く）。2024年以前と同条件で測ると35,137→43,664と大幅に増えていますが、2024年のブログ値（32,108）とは計測日・条件の差異がある可能性があります。 *3:bot によるライブラリのアップデートを含む。 *4:bot を含む。
- フロントエンド
- デザインシステム
- アクセシビリティ
- ESLint
関ケ原Ruby会議01の御大義に賛同いたし、後ろ盾となりて支えたり
拙者、SmartHR情シスソリューション開発部プロダクトエンジニアのnoriと申す者にござる。普段は大和国の居城より、遠隔にて勤めを果たしておる。 SmartHRは、令和8年5月30日に岐阜県不破郡関ケ原町の関ケ原ふれあいセンターで開かれし関ケ原Ruby会議01に協賛いたした。本稿では、SmartHRが協賛したこと、スポンサーLTで申したこと、そして会場にて感じたことを、関ケ原の地に敬意を込め、武将語にて記すものに候。 読みづらきことなど案ずるに及ばず。拙者は西軍の足軽に過ぎませぬが、本稿に限っては武将になりきり、戦国の世より筆を執る所存にござる。各々方、いざ参らん。 関ケ原Ruby会議01とは 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催されし地域Ruby会議にござる。東軍・西軍に分かれし諸将が、それぞれの技と知略を携えて集い、Rubyの新たな歴史を刻むべく、関ケ原ふれあいセンターへ馳せ参じた。 この会議では、東西に分かれたトークセッション、RubyKajaの復活、合戦、宴など、関ケ原の地だからこそできる企てが数多く用意されておった。開催のきっかけや見どころは、SmartHR Tech Blogの運営インタビュー前後編にも詳しく記されているゆえ、戦の全容を知りたい御仁はぜひあわせて読まれよ。 tech.smarthr.jp tech.smarthr.jp 当社の者も登壇いたした SmartHRプロダクトエンジニアにして東軍の武将、kinoppyd殿が「Job戦国時代」と題し、Solid Queue vs Sidekiqの戦模様について口上を述べ申した。現実の戦場に即したベンチマークをもとに、Jobの特性によって採るべき布陣が変わることを示す、たいへん得るところ多き口上であった。 東軍の武将として壇上に出陣せしkinoppyd殿 また、東軍の武将でありながら、セッション開始直後に見事な謀反を起こし、西軍に味方する構えを見せ申した。西軍の足軽たる拙者にとって、これほど頼もしき援軍はござらぬ。 青き陣羽織、通称「小早川ビブス」を身にまとい、西軍の武将として壇上に馳せ参じるkinoppyd殿 スポンサーLTにて、情シス領域の開発につき口上を述べ申した 拙者はスポンサーLTにて、SmartHRの情シス領域の立ち上げと、モジュラーモノリスからマイクロサービスへ段階的に移行している話を申した。 題して「後援の御仁より賜りし、急の口上」。令和の世の言葉に直せば、スポンサーLTでござる。せっかく関ケ原の地で口上を述べるならば、ただの会社紹介では兵の士気も上がらぬと心得、武将語をまとって登壇いたした。 SmartHRと聞くと、「HRと名乗るからには、人事のための道具であろう」と思われる御仁もおられるやもしれぬ。しかし、SmartHRでは人事労務領域に加えて、情報システム部門を支えるIdPやID管理の機能も提供しておる。 スポンサーLTでは、この情シス領域をいかに立ち上げ、モジュラーモノリスにて初速を出し、その後マイクロサービスへ段階的に布陣を変えているのかを紹介いたした。詳しき戦記は、後日当社のブログにて改めて記す所存にござる。モジュラーモノリスとマイクロサービスの狭間で戦う諸将は、ぜひ続報をご覧くだされ。 スポンサーLTのタイトルスライドを背に、壇上に立つ拙者 ブースでも東西の陣を構え申した ブースでは、東西実行委員長のosyoyu殿、ydah殿による「あなたはどっち派？」の企てを実施いたした。結果は、赤がosyoyu殿、青がydah殿でござった。 お雑煮の餅で見破った御仁も多かったのう。多くの参陣者が家紋札を貼ってくださり、陣中はたいへん盛り上がっておった。参陣してくださった各々方、誠にかたじけなし。 関ケ原Ruby会議01に出展したSmartHRのスポンサーブース、もとい陣 「あなたはどっち派？」の結果発表で盛り上がるosyoyu殿とydah殿 最後に 関ケ原Ruby会議01では、スポンサーとして参陣するだけでなく、Rubyistの各々方と直に語らうことができた。地域Ruby会議には、その土地ならではの空気がある。関ケ原Ruby会議01も例外ではなく、会場全体に「この場を楽しもう」という熱が満ちており、技術の話を交わしながらも、陣中には祭りにも似た高揚が満ちておった。 スポンサーLTで武将語を使ったことで、SmartHRの取り組みを少しでも印象に残せていたなら幸いにござる。真面目な技術の話も、戦場の文脈に合わせて届け方を工夫することで、より楽しく伝えられるのだと学び申した。 SmartHRは、これからもRubyコミュニティへの感謝を忘れず、技術を通じてよりよいプロダクトづくりに励んでまいる。関ケ原Ruby会議01を支えし奉行衆の皆々様、壇上にて御口上を述べられし登壇諸将、そして天下分け目の地へ馳せ参じられしRubyの衆の皆々様に、心より御礼申し上げまする。次なる戦場、もとい次なるイベントでも、どこかで相まみえられれば幸いにござる。 関ケ原Ruby会議01に馳せ参じたSmartHRの諸将 相共に一味同心を以て、開発の御馳走を念じ奉り候 SmartHRでは、ともにプロダクトを磨き、ユーザーに価値を届ける仲間を募集中にござる。 SmartHRは、日の本の内であれば、居城の場所を問わず遠隔にて働ける会社にござる。 東西南北いずれの地におわすRubyの衆も、RubyやRuby on Railsをもってプロダクトを磨き上げることに志ある御仁は、ぜひ採用情報をご覧くだされ。 hello-world.smarthr.co.jp
- Ruby
- Rails
- マイクロサービス
Spirit of CRE LT登壇＆参加レポート ── CRE、魂の交流！
こんにちは！ SmartHR CREユニット チーフの井上（id:a-know）です！先日、高圧洗浄機を購入したのですが、それ以来、全てのものが洗浄の対象に見えてしまう今日この頃です。 去る6月3日（水）に、"CRE（Customer Reliability Engineering / Engineer）" に関する全く新しいコミュニティイベント「Spirit of CRE」が開催され、そこに私はLT登壇という形で参加をしてきましたので、今日はそのレポート記事をお送りします！ Spirit of CRE（connpassイベントページ） ちなみにこのイベント、本来であれば東日本橋にあるオーティファイさんのオフィスで開催される予定だったのですが、運悪くこの日は台風6号が首都圏に最接近したタイミングということで、急遽オンライン形式へと変更になりました。運営のオーティファイさん・Ubieさんにとっては大変苦渋の決断だったかと思いますが、結果的にはとても素敵なイベントだったと感じています。素晴らしい運営、ありがとうございました！ イベントの素敵なアイキャッチ画像 Spirit of CRE、開会！ 19時になり、イベントがスタートしました。司会は Ubie の末村さん。まずはこのイベントのテーマから、流暢に説明していただきました。 オープニングスライドの中の一枚 この説明のなかで、 各社に「CRE」という明確なロールはなくても、その魂（Spirit）を持っているメンバーはたくさんいます。 との言葉があり、それに呼応するかのように、勢いよく流れていくZoomのチャット欄。開始早々に、会のボルテージが一気に上がったように感じました。 続いて末村さんから、おそらく場が温まるようにとの配慮でしょう、「皆さんの普段のロールを、チャットに書いて教えてください」との投げかけが。結果、おおよそ半分以上の方が「CREです！」と答えられていて、このイベントがCREの方にとって、とても注目度の高い会であることがわかりました。 メインセッション①: 「誰もがみんなCRE - CREは心のあり方だよね」株式会社Ubie ume さん オープニングののち、メインセッションからイベントはスタートしました。まずは Ubie の ume さんから、「誰もがみんなCRE - CREは心のあり方だよね」というタイトルの発表がありました。 その発表によると、ume さんは2024年9月にUbieで CRE を立ち上げるや否や、リリース頻度の向上やそれを通じての顧客への安心感醸成など、初期に素晴らしい成果を出されていました。 しかしその後、「Ubie の CRE は、改善を積み重ねていくチーム」と認識されると、ROI（投資対効果）の証明を求められ、またそれにうまく答えられなかったことを「失敗」として語っておられました。 「この改善で売上はどれくらい上がるの？」「チャーンレートはどう変わるの？」 一生懸命説明しても、どうしても噛み合わない。そんな中でも ume さんは、AIを駆使して「問い合わせ内容の要約 → Botトリアージ → コーディングエージェントへのプロンプト作成」といった自動化に取り組むなどして、CREとして踏ん張っていたそうです。 その一方で、「なんでこの意義を誰も理解してくれないんだろう」と ume さん自身が内向きになってしまったことがあったという告白もあり、「あぁこれは、"1人目CRE" や、情熱や意義を心の支えにして改善を回しているような人が感じてしまいがちなやつだ……」と思わずにはいられませんでした。 そんな ume さんの孤軍奮闘状態の転換点となったのは、Ubie社内のデザイナーさんが提唱したという「踊り手と舞台装置」という組織論だった、とのことでした（参考: 関連する記事）。これは、組織における役割を「踊り手」と「舞台装置」という2つの動きを担う主体としてとらえ直すという考え方です。 踊り手： 顧客にディープダイブして価値を検証・提供する動き（CSMやPdMなど） 舞台装置： 踊り手のアウトカムを最大化するツールや仕組みを作る動き ume さんは、自分が組んでいたAIコーディングエージェントの仕組みを社内のバグバッシュでみんなに開放してみたそうです。すると、普段からコードを書くロールではないCSM（カスタマーサクセス）やPdM（プロダクトマネージャー）が、次々と自分でプルリクエストを出してくれた、とのこと。つまり、ume さんが "舞台装置" を提供したことで、CSMやPdMといった "踊り手" の行動が変わり始めた・自ら踊り始めた、というわけです。 この体験を通して、ume さんは「自分一人でCREをやろうとするのをやめた」とお話されていました。 みんなの中に「顧客を良くしたい」というカスタマーサクセスの気持ち（魂）は絶対にある。だったら、CREがやるべきなのは、一人でバグを直し続けることではなく、顧客のファクトやメトリクスを伝えて、みんなの「直したい熱」を高めること、そして、動き出した "踊り手" に、AIツールなどの "舞台装置" を渡すことで橋渡しすることだ、という ume さんの主張で発表は締めくくられました。 発表タイトルが「誰もがみんなCRE（になれる状態）を裏側から支えるのが、これからのCREのあり方なんだ」という形で回収される形で、私にとっても今後の SmartHR の CRE の在り方を考える上でとても参考になる素晴らしい発表でした。 メインセッション②: 「Spirit of CRE @ Autify - Autify Nexus のサポート体制構築」オーティファイ株式会社 Mami さん 2本目のメインセッションは、「Spirit of CRE @ Autify - Autify Nexus のサポート体制構築」というタイトルで、Autify の Mami さんからの発表でした。 Autifyさんでは、新規プロダクトであるAutify Nexusのリリースを機に、目指すべきサポート体験の行動指針として「Autify Support Way」を策定したそうです。その内容は以下の通りのもので、これらはAutifyさんに限らず、どこで・誰がお客様に対して向き合う際においても非常に本質的な規範だと思います。 表面的な回答ではなく、顧客の真の課題解決を追求する 仕組みやナレッジを整備し、自動解決や顧客の自律的な利用を実現する 人手でなくていい作業はAI活用や自動化を実施し、無理のない運用体制を作る これらの根底にあるのは、「単にお問い合わせを "捌く" のではなく、"仕組みでトイル（定型業務）を削減し、サービスの信頼性をスケールさせる" という思想」だと感じました。これは、表現やスタイルこそ違えど、私たち SmartHR で常に大事にしていることにも通じます。 発表はそのまま、「新プロダクトのリリースに伴い問い合わせの急増が予想されるが、スタートアップの宿命として、すぐには人員を増やせない」という高い壁にどう立ち向かったのか、というところに移ります。この壁に対し、Mami さん率いるチームは以下のような取り組みで立ち向かったとのことでした。 ナレッジ蓄積の完全非同期・自動化 仕様などについてエンジニアからの回答があった Slack の投稿に特定のスタンプを押す、あるいは問い合わせにタグを付けるだけで、AIが内容を自動要約・Notionの共通データベースにストックまで行う仕組みを構築。 ヘルプ記事作成の「半自動化」でリードタイム75%削減 Notionから社内botを呼び出すだけで、「ドラフト作成 ➔ ガイドラインに基づく自動レビュー ➔ 3ヶ国語（日・英・韓）翻訳」までを一気通貫で行う仕組みを用意。 Intercom のAIエージェント（Intercom Fin）を早期導入 お問い合わせへの自動応答を開始できるように。 高速で更新される、情報鮮度の高いヘルプセンターのデータが、AIエージェントの回答精度向上にも直結するという好循環も生んでいる。 こうした一連のシステム化の結果、「問い合わせの約50%を AI エージェントが解決するようになった」というのは本当に驚異的な成果で、スタートアップならではのスピードとインパクトだなと思うと同時に、自分たちも負けていられないな、とも思いました。 そのまま会はLTへ！ 圧倒されるようなメインセッションが終わったのも束の間、今度は4本のLT発表が行われました。 私をかたちづくる "Spirit of CRE" / 株式会社SmartHR a-know（井上大輔） CRE Spirit を広げる、その左記へ / 株式会社MIXI masartz さん お客様の業務完了を阻むものを、あの手この手で取り除く / 株式会社LayerX tanisuke さん CRE & AI / 株式会社ヌーラボ t_hide さん 私（a-know）のLTでは、「カスタマーセントリックに考え、行動するようになった原体験」や「CRE だからこそ、"技術" にこだわりたい、という話」を中心にお話をしてきました。 いずれのLTも、それぞれ方向性の違った面白いお話ばかりでしたが、中でも特に盛り上がったのは、masartz さんの「CREカンファレンスを開催したいです！」という発言だったのではないかと思います。間違いなく、参加者・登壇者・運営の方、全員の気持ちがひとつになった瞬間だったように感じました。私も CRE Camp というコミュニティの運営メンバーですが、ぜひともこの野望は叶えたいですね！ LTの中で私が特に印象的だったのは、LayerX tanisuke さんのお話です。私は、CRE組織にとって一番大事なことのうちのひとつは「"自分たちはなぜここにいるのか" を定めること」だと思っているのですが、それについて tanisuke さんは「お客様が仕事を終わらせるまでの障害を、あの手この手で取り除くこと・それによって顧客信頼性向上に繋げること」と明文化して宣言されていて、飛ぶ鳥を落とす勢いの LayerX さんならではの CRE 像だな、と感服しました。もちろんそれだけでなく、「お客様はそもそも何がしたいのか。それは、業務を完了すること。」というお話は、ちょうど私が最近考えていたことにもリンクするところがあって、このときZoomのカメラはオフにしていたのですが、うんうんとひたすら頷いてしまっていました。このあたりについてはまた何かしらの形で表に出せたらな、と思っています。 そして最後は、「みんなで話そう CRE Spirit」！ このイベント最後のコンテンツは、本来であれば現地会場で各社登壇者を前にパネルディスカッション、という予定だったのですが、これについても司会の末村さんが機転を利かせていただいて、登壇者・参加者入り乱れる形でのオンラインディスカッションと相成りました。 このパートも大変盛り上がり、私もディスカッション内容に夢中で、どんなテーマについて話されていたかもメモしきれなかったのですが、おおまかには以下のような事柄について、みんなでワイワイと意見交換できました。 お客様の声に一番向き合っているのは誰？ "最も重要なフィードバックチャンネル" ってなんだろう？ プロダクト改善の優先順位付け、どうしてる？ 生成AIは「CREの魂」をどう変えるか？ 私も、ディスカッションの場でもちょこちょこと発言したり、チャットに書き込みさせていただいたりしていたのですが、それぞれについての考えをここでも簡単に書いておきたいと思います。 上記の1については、 SmartHR では少なくとも「全員」だと感じる。 ただ、"ロールごとの向き合い方" というのはきっとあるはずで、それが課題を少し難しくしてしまうこと（この設問のような問いを生み出してしまうこと）はありそう。 また、"お客様の声に対するアクセスのしやすさ" もロールによって違う、というのも難しいポイントだと思う。 この点については、私自身がセールスエンジニアをやっていたときの「お客様がプロダクトに対してどのような思いや考えを持っているか、を、いかに社内に伝えるか腐心していた」というエピソードについて、口頭でも共有しました！ 上記の2についても、答えとしては「全部」ということになりそう。 生成AIが台頭するまでは、「全部」というのは理想論だったかもしれないが、現代では "やればできる" ものになっているよな、と感じている。 "声なき声"（お問い合わせに至らない、お客様のご不便など）をいかに観測するか？についても、同様のチャレンジだと捉えられる！ 上記の3については、基本的に SmartHR ではPdM（プロダクトマネージャー）の責務、ということになる。ただ、それは「PdM の意思決定を助けるような情報やコンテキストの提供とセット」とも考えている。 上記の4は 2の "声なき声" と同じく、「これまで解決困難だと思われていた課題や理想が、生成AIによって実現可能なものに変わってきた」と強く感じている。なので大事なことは、CREとして、顧客の成功のために必要な理想を限りなく高く持つこと・それを技術でハンドリングしようとすることなのかな、と思う。 運営・登壇者・参加者のみなさま、ありがとうございました！！ 今回いろんな方の "CRE魂" についてのお話をきいて、あらためて「自分のなかでのCREとは？」というところに向き合う貴重な機会になりました。 台風のせいで急遽オンラインになってしまいましたが、オンラインだからこそできた議論、発信されたご意見もたくさんあったのかなと思っています。私個人としてはオンラインイベントは久しぶりだったのですが、オンラインならではの良さを再認識することができました。ここまで素敵な場にしていただいた末村さんをはじめとした運営の方、登壇者の方、参加者の方、本当にありがとうございました！ We Are Hiring! SmartHR CREチームでは、アツい "Spirit of CRE" を持っている仲間を絶賛募集中です！ tech.smarthr.jp 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- CRE
- 生成AI
生成AI時代における開発プロセスの現在地 —— 要件定義からレビューまでの試行錯誤の数々
こんにちは！SmartHRの新規事業開発チームでプロダクトエンジニアをしているシンオクです。 先日、社内のAI活用促進におけるモデルケースの1つとして、CPO室からチームの開発プロセスに関するインタビューを受けました。SmartHRのCPO室の役割については下記の記事をご覧ください。 note.com そのインタビューが私自身にとってもこの1年ちょっとのチーム内のAIを活用した開発プロセスを振り返る良い機会となり、せっかくなのでSmartHRに興味を持ってくれている社外の方にも届くようにテックブログに掲載しようと思いたち筆を執っています。 ただ、モデルケースの1つと言っても当事者の感覚としてはまだまだ未完成の開発プロセスです。やりたいことやまだまだ弱いと思っているところもたくさんあります。そんなSmartHR内の1チームのリアルなAI活用の「現在地」としてご笑覧いただけますと幸いです。 開発チームの紹介 ── 小規模でもAIの力を借りて複数プロダクトを並行開発 本題に入る前にチームの紹介をさせてください。 当社には現在、人事労務・タレントマネジメント・情報システム・Employee Service Platform（日常的な業務を支えるプロダクト群の総称）という4つの事業領域が存在し、それぞれの領域が「2030年売上1000億円」という全社目標に向けて日々の業務に励んでいます。実は、この4つの事業領域には属していない「新規事業開発チーム」もあり、既存の4領域とは全く別で事業を開拓することを模索しています。私が所属するのは、この新規事業開発チームです。 ここで紹介できる私たち新規事業開発チームのプロダクトとしては、福利厚生サービスである「働くあなたのマネーポータル」というものがあります。また、それとは別に一部のお客様向けにクローズドで開発しているプロダクトがもう1つあり、現在はそれら2プロダクトの開発・運用を担っています。 smarthr.jp メインの事業領域のチームと違って関係者も少ないです。営業が3名、エンジニアが4名の合計7名で職種の垣根なく1つのチームとして日々業務をしています。 ここまでの話をまとめると、新規事業開発チームは小規模チームで複数プロダクトを担当しており、これから事業・プロダクトを成長させていくことが求められています。高速で仮説検証を繰り返すことが何よりも重要なフェーズです。 そんな私たちが、AIを活用することでより自分たちのアイディアを具体化する速度を速めたいと思うことは必然でした。特にAIコーディングエディタであるCursorの利用促進が2025年2月頃から当社内で活発になったことは大きな出来事でした。ここから、チームとして開発プロセスを完全にAI前提に変えていく方向に舵を切りました。 AI活用の全体像 ── 要件定義からレビューに至るまで開発フロー全体にAIが登場 ここから、具体的に開発プロセスにどのようにAIを組み込んでいるかを説明しますが、まずは全体像の把握のために下記の図をご覧ください。 --- title: 開発フロー全体におけるAIの活用箇所 --- flowchart TD ReqPhase["要件定義<br/><br/>・Notion AI：対話内容から雛形PRD作成<br/>・担当者：AIと壁打ちしながらブラッシュアップ<br/>・チーム：レビュー＆議論を重ねて要件確定"] ReqPhase --> DesignPhase DesignPhase["設計<br/><br/>・人間：AIと壁打ちしながらプロトタイピング実装<br/>・コーディングAI：設計ドキュメント自動生成"] DesignPhase --> TestCasePhase TestCasePhase["テストケース作成<br/><br/>・Notion AI：設計ドキュメント等からテストケース作成"] TestCasePhase --> IssuePhase IssuePhase["タスク分割<br/><br/>・コーディングAI：設計ドキュメントから自動でIssue作成<br/>・人間：AIが作成するIssueの粒度をルール調整"] IssuePhase --> ImplPhase ImplPhase["実装<br/><br/>・コーディングAI：実装＆セルフレビュー＆PR作成<br/>・人間：動作テストを含めた最終確認"] ImplPhase --> ReviewPhase ReviewPhase["レビュー<br/><br/>・CodeRabbit：自動レビュー<br/>・人間：変更取り込むための最終レビュー<br/>・Devin：人間のレビュー内容に応じてルール更新"] 上記の図で多くのツールが登場するのがわかると思います。簡単にそれぞれのツールの使い分けについても紹介しておきます。 Notion AI PRD（プロダクト要求仕様書）とマニュアルテストケース（リリース前の最終動作確認で確認すべき内容・手順・期待結果をまとめたもの）をNotion上で管理しているためそれらのドキュメントの作成・更新に利用します。 コーディングAI 本記事ではClaude Code、Cursor、Codexなどの主にコーディングに利用するAIツールの総称とします。 当社では上記のコーディングAIは全て利用可能な状態になっており、それぞれの開発者の好みに応じてツールを選択しています。 私自身は、規模が大きかったり複雑度が高いタスクはClaude CodeをPlanモードで動かして、簡単な修正にはCursorを利用するような使い方をしています。 CodeRabbit GitHubのPull Requestに対して自動でレビューを行ってくれるAIコードレビューツールです。 Devin Slackのチャットなどから受けた指示にもとづいて計画・実装・テストまでを一気通貫に行う自律型AIソフトウェアエンジニアです。 私たちのチームでは「コードレビューの中でコーディングルールに追記した方が良いものを自動で更新する」という役割も担っています。 以降では開発プロセスの各フェーズごとに具体的にどのようにAIを活用しているかを説明していきます。 要件定義でのAI活用 ── Notion AIでPRDの壁打ち 要件定義フェーズにおけるAI利用の要点は、ドキュメントの置き場所をNotionに寄せた上で、Notion AIをPRD（プロダクト要求仕様書）の雛形作成と人間の壁打ち相手として活用していることです。 要件定義でNotion AIを利用している理由 要件定義フェーズでの主要なドキュメントであるPRDは、Notion上で管理しています。そのため、要件定義フェーズにおけるAIの利用では、必然的にNotion AIを使うことになります。 PRDをNotionで管理している背景としては、営業のメンバーにも参照・更新してもらう機会が頻繁にあるためです。プロダクトマネージャーがいない私たちのチームではエンジニアと営業のみでプロダクトの方向性を決定しており、要件定義段階ではエンジニアと営業の間での議論・共通認識の熟成が重要となります。そのため、社内情報の基盤であるNotionを仕様にまつわるドキュメントの格納場所にすることで、営業メンバーのアクセスを容易にし、ツールに対する習熟度の違いが議論の妨げにならないようにしました。 実は、後続の設計フェーズのドキュメントである設計書はGitHubでリポジトリ内にdocsというディレクトリを作成してその中で管理しているので、営業のメンバーにGitHubのアカウントを作成してもらって全てのドキュメントの格納先をGitHubに寄せる案もありました。しかし、ここ最近のGitHubを経由したサイバー攻撃の活発化を考えると、GitHubに慣れている人間とそうでない人間では後者の方がアカウントの乗っ取り等のリスクは高いと考えられます。そういった意味でも営業メンバーとの接点をGitHubではなくNotionにしたのは結果的に正しい選択だったと感じています。 要件定義はNotion、設計はGitHubという使い分けがあると、AIを活用する流れが分断しそうに思えるかもしれませんが、NotionのMCP（Model Context Protocol：AIに外部ツールの情報を渡すための仕組み）やCLIツールを使えば設計時に必要な情報は渡せるので、今のところそこまで不自由はありません。 要件定義でのNotion AIの役割 このフェーズでのNotion AIの役割は、基本的には「雛形作成」と「人間の壁打ち相手」の2つになります。 雛形作成では、create-prdというカスタムスキルを用意しています。後で人間が手直しをする前提ではありますが、Notion AIが外部ツール（GitHubやSlackなど）との連携に優れていることもあり、必要なコンテキストがあればそれなりのクオリティの雛形が作成される実感があります。 このスキルでは、PRDの内容のヒアリングからNotionページの作成までの手順に加え、「推測で情報を補完しない」といった記述方針を定めています。具体的な内容は下記をご覧ください。 PRD作成のカスタムスキル（一部抜粋） # 実行手順 AIは以下の手順を自動的に実行します： ## 1. PRDとしてまとめる内容をユーザーからヒアリングする - PRDのセクションごとにステップバイステップで内容をなるべくヒアリングする。後で記入する部分は、その旨指示をもらう。 - 必要な内容のヒアリングが終わったら、次のステップに進む。 ## 2. チケット（GitHub Issue）内容の取得（あれば） - 指定されたチケット（GitHub Issue）の内容を取得 - 以下の情報を抽出： - タイトル - 説明 - 受け入れ条件 - 関連チケット・リンク - コメント（必要に応じて） - チケットの概要を日本語で報告 ## 3. PRDページのタイトルを決定 - チケットから機能名を抽出 - タイトルを`PRD - {機能名}`の形式で決定 - ユーザーに確認 ## 4. PRDの作成 - 以下のテンプレートを基に、Notionに新しいPRDページを作成します： `#{テンプレートのリンク}` - PRDは以下のデータベースに作成されます： `#{Notion DBのリンク}` # PRD作成の基本方針 ## 心得 - 使わないセクション・項目は削除せずに「N/A」と書く - これから書くところは「WIP」にしておく - シンプルで読みやすいPRDを心がける - 検討の過程は議事録などに残してリンクする - むやみに難しい言葉を使わない ## 記述方針 - 冗長な表現を避ける - 少ない文章量で最大限の内容を伝える - 箇条書きを多用 - 文章はなるべく短く簡潔に - ビジネス要件・ユーザー体験に焦点 - 技術的な実装詳細は書かない - 既存機能と新機能を明確に区別 - 新規追加項目には「（新規）」と明示 - 変更箇所には「（変更）」と明示 # 各セクションの作成ガイドライン ## 情報が不足している場合 PRDに必要な情報がチケットに記載されていない場合は、以下のような質問でユーザーに確認します： - 必要な情報の確認 - 「〜の情報は必要ですか？」 - 既存機能との関連 - 「既存の〜機能との連携は必要ですか？」 - 出力形式の確認 - 「〜のフォーマットはどうあるべきですか？」 ## テンプレートの空欄処理 - チケットから情報が得られない箇所は`TODO: 情報が不足しているのでスキップ`と記載 - 明らかに不要なセクションは削除せず「N/A」と記載 - 推測で情報を補完しない 人間の壁打ち相手という役割については、私たち新規事業開発チームが限られたお客様向けにクローズドに開発しているプロダクトの開発で特に重宝しています。 一例として、Notion AIを用いてプロダクトの利用に関する各社個別のユーザーフローを全てのユーザー企業についてドキュメント化しました。これにより新機能の追加や、仕様変更があった際に、「この顧客にとっては有益だが逆にこの顧客にとっては不利益にならないか」という分析をノーコストでできるようになりました。抽象化された機能を提供する一般的なSaaSの作り方とは異なる考え方ではありますが、現状のプロダクト規模だとうまく機能する仕組みになっています。 しかしながら、やはり要件定義フェーズの成否は「担当者がどこまで深く潜り込んで仕様を考え抜けるか」「担当者が考えた仕様をチームでの議論を通じてどれだけブラッシュアップできるか」という点に懸かっていると感じています。「作る」過程がAIの進化によって高速化した現代において、作る前の「考える」過程で間違えると、高速にいらないものを量産し続けることにもなりかねないので、より一層「考える」ことへの強いこだわりを持ち続けたいです。 設計でのAI活用 ── 事前にプロトタイプで合意形成をしてから設計に落とし込む 設計フェーズにおけるAI利用の要点は、先にプロトタイプで合意形成をしてから設計書に落とし込むことです。ここからはコーディングAIが中心の役割を担っていきます。 プロトタイプを作って要件の磨き込みと設計上の課題の明確化を両立 専任のデザイナーがいないというチーム事情もあり、「UI/UXデザイン」であったり「モック作成」のようなことをできるスキルをチーム内に持ち合わせていません。去年は、そこが明確なチームの弱点になっていました。 しかし、最近はどのAIモデルもかなり賢くなってきたため、「UI/UXデザイン」「モック作成」というフェーズをAIによるプロトタイピングによって代替できるようになりました。設計の是非やコードの可読性などにはこの段階ではあえて深く考えず、まずはバイブコーディングしながら動くものを優先して作るという使い方です。 プロトタイプを実装することにより、PRDを作成している段階では見えてこなかった仕様の漏れなどにも早期に気付けるようになり、設計上考えなくてはいけない考慮事項が自然と明確になるなど、仕様・設計の両面でメリットがありました。ステージング環境などにデプロイすれば営業メンバーに実際に触って確認してもらうことも可能になるため、前段の要件定義フェーズが正しいものだったかどうかのフィードバックを早期に得ることができます。これまでは営業メンバーから見るとブラックボックスになりがちだった要件定義完了から実装完了までの間の工程が透明化したこともチームにとって好ましいことだと感じています。 PRDとプロトタイプを読み込ませ設計書を自動作成 要件定義フェーズでも軽く触れた通り、設計書はGitHubでリポジトリ内にdocsというディレクトリを作成してその中で管理しています。このドキュメントの作成のために、エージェントスキルやテンプレートを地道に少しずつ調整してきました。 去年はAIが出力してきた設計書を見てもしっくり来ない場合も多々あって参考程度にしか扱わないこともありましたが、今年のClaude Opus 4.6の登場あたりからかなり精度の高い設計書をAIで出力することが可能になった実感があります。AIの進化を信じて整備を続けてきて良かったです。 設計書の品質を安定させる肝は、PRDから抽出すべき観点や設計書の構成をテンプレートとして固定化している点にあります。実際に使っているエージェントスキルと設計書テンプレートを以下に記載するので、ご興味があればご覧ください。 エージェントスキル # create-design-doc コマンド ## 概要 PRD（プロダクト要件定義書）を元に、設計書を自動生成するためのコマンドです。 ## 使い方 以下のように送信します： `/create-design-doc {PRDの指定}` ### PRDの指定方法 以下のいずれかの形式でPRDを指定できます： 1. **ファイルパスを指定** `/create-design-doc docs/prd/example-feature.md` 2. **PDFファイルを添付** `/create-design-doc [添付: PRD.pdf]` 3. **Notion URLを指定** `/create-design-doc https://www.notion.so/xxx/PRD-xxx` ## 実行手順 AIは以下の手順を自動的に実行します： ### 1. PRD内容の取得 - 指定された方法でPRDの内容を取得 - ファイルパス: `read_file`で読み込み - PDF添付: 添付ファイルから内容を抽出 - Notion URL: Notion MCPで内容を取得 - PRDの概要を日本語で報告 ### 2. 機能名とファイル名の決定 - PRDから機能名を抽出 - 今日の日付を取得（YYYYMMDDフォーマット） - ファイル名を `docs/design/YYYYMMDD_機能名.md` の形式で決定 - ユーザーに確認 ### 3. 設計書の生成 テンプレート（`docs/design/template.md`） を基に、テンプレートの中の指示に従って、各セクションを埋めていきます。 情報が不足している部分は、「TODO: 情報が不足しているのでスキップ」と記載する。 ## 各セクションの作成ガイドライン ### PRDから抽出すべき情報 1. **機能名**: タイトルやヘッダーから抽出 2. **背景と目的**: なぜこの機能が必要か 3. **ユーザーストーリー**: 誰が、何を、どのように 4. **画面仕様**: UIの説明、ワイヤーフレーム 5. **データ要件**: 必要なデータ項目 6. **制約条件**: 技術的制約、ビジネスルール ### テンプレートの空欄処理 - PRDから情報が得られない箇所はTODOコメントのまま 設計書テンプレート（一部抜粋） <pre class="code md" dat
- 生成AI
- Notion
- GitHub
- 開発プロセス
- 品質保証
AIにAIの進化を追わせる ── Notionカスタムエージェントで最新情報を毎朝届ける
SmartHR 勤怠管理の開発チームでプロダクトエンジニアをしている曽根です。 この記事では、AIの最新情報をチームに自動で届ける仕組みを作った話を紹介します。Notionのカスタムエージェント機能を使って、毎朝Slackチャンネルに「AI最新情報」が自動投稿される仕組みです。 構築にかかった時間はプロンプト調整を含めて1〜2時間程度で、「あ〜、こんなに簡単に作れちゃうんだ」というのが正直な感想でした。日々の運用はほぼゼロコストで、どの情報を取得するかの見直しを月1回行う予定です。運用を始めたのは2026年5月の2週目で、執筆時点ではまだ2〜3週間ほどの短い運用期間です。Notionカスタムエージェントを選んだ理由や、運用して気づいた失敗談も含めて紹介するので、同じ課題を感じているチームの参考になれば嬉しいです。 何を作ったか 作成したのは、「主要AIサービスの最新情報をまとめたNotionページを作成してSlackに投稿する」というNotionのカスタムエージェントです。 平日の毎朝、以下のような投稿がSlackのチームのチャネルに自動で送信されます。 Notionカスタムエージェントが毎朝Slackに自動投稿する「AI最新情報」のサマリ 以降では、私たちチームにどんな課題があったのかを振り返ってから、この仕組みの構成と運用の工夫などについて紹介します。 AI時代の情報キャッチアップコストの増加という課題 私たちのチームでは、Claude Code や Cursor をはじめとするAIツールを日常的に活用しています。いわゆる「AIネイティブ開発」を推進する中で、ひとつの課題が浮かび上がってきました。 それは、変化が速すぎて、自社プロダクトにマッチする最新情報を取り逃すという課題です。 少し前まで、私たちのチームは以下のような状況でした。 開発体験を大きく変えるアップデートを見逃すという潜在的なリスクを常に抱えていた 「あのツール、最近こんなことできるようになったらしいよ」という口伝ベースの共有に頼っていて、情報の網羅性がなかった 個人でRSS（Webサイトの更新情報を配信する仕組み）やXをウォッチしているメンバーもいましたが、チーム全体として最新情報が行き届いているかは属人的な状況だった なお、勤怠管理の開発チームでは、開発プロセスそのものをAI前提で再設計する取り組みを進めています。その全体像は「AIネイティブな開発プロセスへの移行、はじめました — SmartHR勤怠管理の開発チームの取り組み」で紹介しており、この記事で扱う情報共有の自動化は、その中の具体的な一施策にあたります。 最初に試したこと 最初はこの課題を手軽に解決しようと、RSSで集めた更新情報を選別せずにそのままSlackチャンネルへ自動投稿していました。この時点では公式リリースノートのような一次情報も、技術ブログやまとめ記事のような二次情報も区別なく流していました。しかし、これにはいくつかの問題がありました。 量が多すぎてSlack上で流れ、ほとんど読まれない 「で、うちのプロダクトだとどう使えるの？」がわからず、行動につながらない 一次情報と二次情報が混在し、どれが正確なのか判断しづらい 特に情報の精度については、二次情報が原因になっていることがわかってきました。二次情報は筆者の解釈が入るぶん元のリリース内容とずれたり、重要な制約条件が省略されていることがあったためです。そこで修正版では、情報の精度にブレを生む二次情報をあえて落とし、一次情報に絞る方針へ切り替えました。 目指した状態 この失敗を踏まえて、「こういう状態にしたい」と改めて整理しました。 チーム全員が同じタイミングで同じ情報を得られる 単なるニュースの羅列ではなく、自分たちのプロダクトにどう活かせるかまで含まれている 情報収集に個人の時間をあまり使わなくてよい この状態を実現するため、大枠の設計として、前述のとおり一次情報（公式リリースノート・公式ブログ）に絞ったうえで、件数を絞ること、自社プロダクトでの活用イメージをセットで届けることを出発点としました。 基本設計 全体構成 平日毎朝、Notionカスタムエージェントが公式リリースノートやブログを巡回して情報を集め、3〜10件にフィルタリングしたうえでSlackチャンネルに投稿し、チームが朝会で確認する流れにしました。 --- title: AI最新情報の自動共有フロー --- flowchart TD A[Notionカスタムエージェントが平日毎朝 自動実行] --> B[公式リリースノート/ブログを巡回] B --> C[3〜10件にフィルタリング] C --> D[Slackチャンネルに投稿] D --> E[チームが朝会で確認] なぜNotionカスタムエージェントを選んだか 情報を自動収集して共有する手段は他にもあります。たとえば、LLMのAPIを呼ぶ自前のプログラムを書き、GitHub Actionsなどで定期実行する方法です。あるいは、ZapierなどのSaaSで組む方法も検討しました。それでも最終的にNotionカスタムエージェントを選んだのは、以下の理由からです。 情報収集から投稿まで1つのエージェントで完結する（巡回・要約・Slack投稿・定期実行がNotionの標準機能で揃い、実行基盤を自前で用意しなくてよい） 過去の出力がページとして蓄積され、後から参照できるナレッジベースになる ノーコードで設定でき、スモールスタートしやすい エージェントの設定 具体的な設定内容を紹介します。エージェント設定の概要は次のとおりです。 トリガー：平日の毎朝9時に自動実行 出力先：チームのSlackチャンネル プロンプト:エージェントの動作を以下のブロックに分けて指示しています。 概要 — 何を集めてどこに投稿するか 出力フォーマット — 各トピックに含める項目（要約・活用イメージ・導入方法・リンク） 2セクション構成 — 「今日の最新情報」と「再掲」の作り分け 重複排除 — 既出トピックの除外ルール 情報ソース（優先順位） — どのサービスを優先して巡回するか フィルタリング基準 — 共有する価値があるかの判断軸 投稿先と形式 — NotionページとSlack投稿の作り方 不確実性の扱い — 確信が持てない場合の書き方 実際に与えているプロンプト全文は、記事末尾の付録に掲載しているので、再現したい場合はそちらを参照してください。 トリガーやSlack連携など各画面の詳しい操作はNotion公式ヘルプの「カスタムエージェント」にまとまっています。 工夫したこと 出力の質は、最初からこの形だったわけではありません。ざっくりした指示で動かすと、件数が多すぎる・要約が公式の内容とずれる・活用イメージが汎用的すぎる、といった形でつまずきました。これらを1つずつ潰すなかで、工夫が「出力の構成」と「情報の選別」の2つの軸に整理できることがわかりました。出力の構成は届いた情報で読者が動けるようにするための工夫、情報の選別は届ける情報のノイズを減らすための工夫です。 出力の構成 出力の構成では、届いた情報を見た人がそのまま行動に移せること、そして重要な情報を見逃さないことを重視しました。 「活用イメージ」と「導入方法」を必須にした リリースノートの要約だけでは、読んだ人が「ふーん」で終わり、行動につながりません。そこで、各トピックに以下の項目を必須としました。 項目 目的 記載例 要約 何が変わったかを端的に伝える Claude Code にフック機能が追加 活用イメージ 自社プロダクトでどう使えるか CI（継続的インテグレーション）実行前の自動lint（コードの静的解析）設定に活用できそう 導入方法 試すための最初の一歩を明確にする settings.json に hooks を追加して有効化 リンク 一次情報にすぐアクセスできる 公式ブログ / Changelog のURL 「活用イメージ」と「導入方法」を書くことで、情報を知っただけで終わらず、実際に試すハードルを下げることを意識しています。 2セクション構成で「あとから効いてくる情報」を拾い直す 毎日の情報はその日限りになりがちです。リリース当日は「今の自分たちには関係なさそう」と感じた情報でも、数週間後にプロジェクトの状況が変わって急に試す価値が出てくることがあります。 そこで、各ページを以下の2セクションに分割しました。 今日の最新情報 — その日の新規アップデート 最近の重要アップデート（再掲） — 直近2か月以内で、まだ試す価値が高いもの（3件前後をランダムにピックアップ） 再掲セクションの狙いは、当日には刺さらなかった情報に「もう一度試すタイミング」を与えることです。ランダムにピックアップすることで、忘れかけていた情報と再会するきっかけを作っています。 重複排除のルール 同じ情報が繰り返し出てくるとノイズになるため、以下のルールを設定しました。 「今日の最新情報」と「再掲」で同じトピックを重複させない 過去に「今日の最新情報」で投稿したトピックは、以後の「今日の最新情報」へは再投稿しない これにより、「また同じ内容だ」とならないようにしています。 情報の選別 情報の選別では、共有する情報を絞り込み、精度の高い一次情報だけが届くようにしました。 情報ソースの優先順位 AIサービスは無数にありますが、すべてを追うのは現実的ではありません。チームの開発スタックに合わせて、優先順位付きの情報ソースリストを定義しました。 最優先（毎日チェック） Anthropic（Claude）・OpenAI・Google（Gemini / Vertex AI） 優先（重要度に応じて取捨選択） Cursor・GitHub Copilot・Devin 補助（話題性がある場合） Meta（Llama）・Mistral AI・xAI・LangChain・Hugging Face など さらに、新しいAIサービスが登場した場合は初回だけでもトピック化し、継続的に追う価値があると判断したものは情報ソースリストに追加する運用としています。 フィルタリング基準 「チームに共有する価値があるか」の判断基準も明確にしました。些細なバグ修正は除外し、以下に該当するものを優先しています。 体験が変わる新機能 価格・制限・提供形態の変更 セキュリティ・コンプライアンスに関わる変更 既存の開発・テスト・運用フローへの影響がある変更 AIの出力品質をどう担保するか エージェントが自動生成した情報をそのまま共有するため、ハルシネーション（事実と異なる情報の生成）のリスクは常に意識する必要があります。 完璧な品質保証は難しいですが、以下の方法でリスクを下げています。 一次情報リンクの掲載を必須にし、読者が元ソースを確認できるようにしている 公式リリースノート・公式ブログのみをソースとして指定し、二次情報や噂レベルの情報を排除 今のところ、明らかな誤情報やソースの取り逃しが問題になったことはありません。ただし運用期間がまだ2〜3週間と短いため、これで品質が十分に担保できていると断定はできません。引き続き一次情報リンクで裏が取れる状態を保ちながら、出力を観察していく予定です。 何が変わったか エコシステムの全体感がつかめるようになった 毎朝同じ観点で情報が並ぶことで、個別のニュースを追うだけでは見えにくかったエコシステム全体のトレンドが、なんとなくつかめるようになりました。たとえば、クラウドエージェント周りの整備が各ベンダーで一斉に進んでいることや、各サービスの値上げの動きなど、複数のリリースを横並びで眺めて初めて見えてくる流れを意識できるようになっています。 情報格差の解消 この仕組みの導入後は、以前は「知っている人は知っている」状態だったAI関連の情報が、チーム全員に共有されるようになりました。メンバーからも「これはよさそう」という声があり、「あのアップデート知ってた？」という会話が減って、代わりに「あのアップデート、うちのプロダクトだとこう使えそうだよね」と最新情報について議論する場面が増えました。 試すハードルが下がった 「活用イメージ」や「導入方法」を必須項目にしたことで、情報を見たその日に試すメンバーが出てきました。たとえば、CursorのShared Canvasesを利用して、現状のClaudeのSkill一覧を用途別カテゴリで表示するページを作成し、チームに共有する行動にすぐつなげられました。 これから改善したいポイント 運用を始めて2〜3週間ほどで、改善の余地はまだたくさんあります。 「活用イメージ」の精度向上 現状、エージェントが出力する「活用イメージ」は、プロダクトの文脈を十分に踏まえられず、汎用的すぎる提案（「業務効率化に活用できそう」など）になりがちです。今後は、チームが実際に取り組んでいる課題や直近の技術的な関心事をプロンプトに反映させる仕組みを検討しています。 フィードバックループの構築 現状は情報を届けて終わりの一方通行です。「このトピックは実際に役に立った」「このジャンルの情報がもっと欲しい」というチームの反応を収集し、トピック選定の精度向上に活かす仕組みを作りたいと考えています。たとえば、朝会で話題になったトピックにリアクションをつけてもらい、その傾向をエージェントのフィルタリングに反映させる形です。 他チームへの展開 今はひとつのチームで運用していますが、仕組み自体は汎用的です。Notionカスタムエージェントの設定をテンプレート化して、他のチームでも情報ソースリストやフィルタ基準をカスタマイズして使えるようにしたいと考えています。 まとめ AIネイティブ開発を推進する中で、「変化の速さに追いつけない」という課題に対し、Notionカスタムエージェントを使った情報共有の仕組みを構築しました。 この取り組みを通じて得た、AIエージェントにチームの情報収集を任せるときに気をつけたポイントは以下の3つです。 アクションにつなげる項目を必須にする — 「活用イメージ」「導入方法」を含めることで、情報が行動に変わる 見逃し防止の再掲構造を入れる — 2セクション構成で、休んでいた日の重要情報も拾える ノイズ除去のフィルタ基準を明文化する — フィルタなしだと情報過多で読まれなくなる（実際になった） 仕組み自体はシンプルですが、運用して感じたのは、「AIツールを使いこなすための第一歩は、AI自身に情報収集を任せることかもしれない」ということです。人間がAIの進化を追いかけるのではなく、AIにAIの進化を追わせて、人間はその情報をもとに判断と行動に集中する。この構造が、私たちのチームの開発体験を一段上げてくれたと、私は感じています。 ただし、AIに情報収集を任せても、個人の情報収集が不要になるわけではありません。偶然たどり着く発見や、勉強会・雑談から生まれるヒントは、個人が自ら情報に触れることでしか得られないからです。AIは全員のキャッチアップのベースラインを引き上げ、各自が深掘りしたい領域を探索する時間を生み出してくれるものだと捉えています。 付録：エージェントのプロンプト全文 エージェントに与えているプロンプトの全文です（一部抜粋・要約）。本文で説明した各ブロックの実際の指示内容を確認できます。 ■ 概要 - 平日毎朝、主要AIサービスや開発支援AIツールの公式リリースノート等から 最新情報を集め、Slackチャンネルに投稿して共有する ■ 出力フォーマット - 3〜10トピックを選定 - 各トピックに必ず以下を含める： - 要約 - 勤怠管理プロダクトにおける活用イメージ - 導入方法（最低でも「どこで有効化/設定するか」「まず何を試すか」がわかる粒度。 分からない場合は「導入方法（要調査）」として不足情報を書く） - リンク（一次情報を優先） ■ 2セクション構成 1) 今日の最新情報（その日の新規アップデート中心） 2) 最近の重要アップデート（再掲）（直近2か月以内で、まだ試す価値が高いものを 3件前後ランダムにピック。候補が無ければ「該当なし」と明記） ■ 重複排除 - 候補を作る前に、直近2〜3か月の「AI最新情報」ページを確認し、既出の見出しは除外 （重複判定はトピック見出しの文字列を基準にする） - 一度「今日の最新情報」に投稿したトピックは、以後の「今日の最新情報」には再投稿しない - 「今日の最新情報」と「再掲」で同じトピックを重複させない ■ 情報ソース（優先順位） - 公式の一次情報を最優先。Changelog / Release notes / Blog のいずれも一次情報として扱う - 最優先: Anthropic（Claude）・OpenAI・Google（Gemini / Vertex AI） - 優先（重要度に応じ取捨選択）: Cursor・Devin・GitHub Copilot・Google DeepMind など - 補助（話題性がある場合）: Meta（Llama）・Mistral AI・xAI・LangChain・Hugging Face など - 新しいAIサービス/開発支援ツールが出た場合は、初回だけでもトピック化して共有する ■ フィルタリング基準 - 「今日チームに共有する価値があるか」で3〜10件に絞る。些細な修正は避ける - 優先するもの：体験が変わる新機能 / 価格・制限・提供形態の変更 / セキュリティ・コンプライアンス関連 / 既存フ
- 生成AI
- Notion
- Slack
Rails 8.0アップグレードの落とし穴 —— rails-i18nによる金額表記の不具合と対策
こんにちは。SmartHRでRails顧問業をしている@willnetです。 最近は暑い日が多いですね。まだなんとかジョギングできるレベルなので、今のうちにできるだけ毎日走って体力を向上させたい、そして体重を落としたいという気持ちで毎日を過ごしています🏃💨。 今日はRails 8.0アップグレードの話をしようと思います。 「基本機能」をRails 8.0へアップグレードしました 先日、SmartHRで「基本機能」と呼ばれている大きなRailsアプリケーションをRails 8.0にアップグレードしました。しかし大きいアプリケーションのRailsアップグレード作業はすんなりといきません。2回のリバートの末に何とか完了しました。現在では安定して運用できています。 このブログエントリでは、SmartHRにおいてRails 8.0へのアップグレード後、最初にリバートされることになった落とし穴の原因と対策について解説します。おそらくこれからRails 8.0にアップグレードするときに同じ問題に遭遇する人がいると思うので、注意喚起を兼ねてブログの形でまとめようと思った次第です。 rails-i18n gemとは rails-i18nというgemがあります。これはRailsが利用するi18n(internationalization、国際化)用の辞書定義が集まったものです。rails-i18nをインストールするだけで様々な言語の定義を利用できるようになります。「基本機能」アプリケーションでは長らくrails-i18nを利用してきました。 rails-i18nのバージョン指定はRailsのバージョンに合わせた形式になっています。具体的にはRails7系に対応するrails-i18nのバージョンは7.0系であり、Rails 8.0に対応するrails-i18nのバージョンは8.0系です。バージョンの依存関係は明示的に定義されているので、Rails 8.0のアップグレードとrails-i18nのアップグレードは同時に行う必要があります。 デプロイ後に気づいた不具合 最初のRails 8.0アップグレード後、金額を表示するフォーマットがおかしくなっていることがわかりました。「-100円」と表示されるべきところが「-円100」となっています。 リバート後に原因を調査したところ、rails-i18nのv8.0.2に入った日本語の辞書定義にバグがあることがわかりました。ja.number.currency.format.negative_formatという定義が新しく追加されましたが、数値と円表記の順番が逆になっています。 ja.number.currency.format.negative_formatはnumber_to_currencyメソッドの引数が負の値の時に利用されます。number.currency.format.negative_formatの定義がないときはnumber.currency.format.formatの先頭に-をつけた文字列が返るため、これまでは特に問題なく利用できていました。しかしrails-i18nのv8.0.2を利用すると明示的に間違ったフォーマットが指定されるため表示がおかしくなってしまいます。 不具合対応と今後の検討事項 取り急ぎrails-i18nに修正のプルリクエストを投げました。マージはされましたがすぐにはリリースされないので、手動でi18n定義を追加することでrails-i18nの定義を上書きして対応しました。下記は上書きをするyamlの例です。 # config/locales/ja.yml ja: number: currency: format: negative_format: '-%n%u' これで今のところ問題なく運用できていますが、多言語対応をきちんとするのであれば自前で全てのi18n辞書を管理するべきでは？という意見もあり、今後どうするかは検討事項です。rails-i18nを利用することでi18nの定義を省力化できますが、ある程度育ったプロダクトであれば自分たちで管理する方がメリットが大きいようにも思えます。 まとめ Rails 8.0アップグレード時にハマった落とし穴について共有しました。テストカバレッジが十分あっても、全てのケースをカバーできるわけではありません。この情報が皆さんのRails 8.0アップグレードに役立つようであれば幸いです。 We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ みんなで楽しくRailsのバージョンを上げていきましょう！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- Rails
- OSS
- 国際化
「ルールルルルルRubyKaigi 2026事後勉強会 ── したっけ、東京で！」を開催しました
こんにちは！SmartHRで基本機能（人事マスタ関連）を開発しているhamadaです。 この記事では、2026年5月22日に東京・六本木のSmartHR Spaceで開催した「ルールルルルルRubyKaigi 2026事後勉強会 ── したっけ、東京で！」の様子をお届けします。 事後勉強会のアイキャッチ なお、「ルールルルルルRubyKaigi 2026事前勉強会 —— 初参加でもなまら歓迎！」については以下の記事でレポートしています。ぜひこちらも読んでいただけると嬉しいです。 tech.smarthr.jp 開催概要 SmartHRは、RubyKaigi 2026にHangout Sponsorとして協賛し、「ルールルルルルルビーカイギ」をテーマにさまざまな企画を行ってきました。会期前に開催した「ルールルルルルRubyKaigi 2026事前勉強会 —— 初参加でもなまら歓迎！」、会期中に実施したたまり場「五稜郭」、会期翌日に実施した「函館市電LT」に続く最後のイベントとして、この事後勉強会を開催しました。 事後勉強会は、「RubyKaigi 2026での出会いや学びを胸に、今度は東京でふたたび集まりましょう！」という思いを込めて、「したっけ、東京で！」と題しました。「したっけ」は北海道の方言で、「またね」という意味です。 事後勉強会では、事前勉強会に引き続きRubyKaigiチーフオーガナイザーの松田明さんも登壇してくださり、RubyKaigiの初参加者、RubyKaigi2回目以上の参加者、スピーカーやコミッターなど、さまざまな方からの熱いLTがありました。 開始前の様子 受付では、キュートな狐がイカを釣る事後勉強会限定のSmartHRの増えてくアクキーをお配りしました。 また、会場にたまり場「五稜郭」で好評だった「モルック」と「IKATSURUBY」を再現し、開始前に参加者に楽しんでいただきました。 こうして、お祭りムード満載でイベントがスタートしました。 RubyKaigi 2026限定アクキー（写真左）とRubyKaigi 2026事後勉強会限定アクキー（写真右） 函館と縁の深い競技「モルック」を楽しむ参加者 イカ釣りゲーム「IKATSURUBY」を楽しむ参加者 オープニング 司会進行を務めたのは、新卒2年目のSmartHRプロダクトエンジニアであるnoriさん。 自身も2回目のRubyKaigi参加となったnoriさんは、リラックスしたムードで「会場にどんな人が集まっているか」を確かめる挙手アンケートを実施。初参加の方からベテラン、さらにはRubyコミッターや運営スタッフまで、会場に集まった多くの参加者を巻き込みながら、イベントのスタートを温かく盛り上げてくれました。 参加者事前アンケートの結果を紹介するnoriさん 応援パネルで会場を盛り上げてくださる参加者の方々 ポストモーテム枠 最初のブロックは、ポストモーテム枠のLTです。 ドラ係は、RubyKaigi 2026で「Guide to getting started walking source codes of CRuby」を発表し、「CRuby quest 〜 Rubyのぼうけんのしょ」の著者でもあるyouchanさんでした。 ドラ係のyouchanさん yancyaさん：あのアレの”個人的な”振り返り 最初は、yancyaさんによる「あのアレの”個人的な”振り返り」という発表でした。 18時間かけて船で北海道へ渡るカスタムスポンサー企画「Rubyist Bulk Reload 2026」の直前に地震が発生し、その影響でイベントが中止・下船になり、にもかかわらず車やバイクは船に乗せたまま出航となった緊迫の舞台裏が語られました。乗船前の判断体制や指揮系統の明確化の重要性、旅行代理店への一任といったリアルで貴重な教訓を共有しました。 来年は「神戸〜宮崎」でのリベンジを誓うyancyaさんの姿に、このイベントに参加予定でバイクだけが旅をして戻ってきたというドラ係のyouchanさんからも、「面白い体験をさせてもらった」と温かい労いの言葉が贈られました。 ポストモーテムの形式であのアレを振り返るyancyaさん RubyKaigi 2026が初参加だった方によるLT 次のブロックは、RubyKaigi 2026が初参加だった方によるLTです。 ドラ係は、RubyKaigi 2026のスポンサーブースで「SNOW COLLECTORS」というゲームを披露していたkaibaさんでした。 ドラ係のkaibaさん a2cさん：Inspired By RubyKaigi (EN) 最初は、SmartHRのa2cさんによる「Inspired By RubyKaigi (EN)」という発表でした。 今回のRubyKaigi 2026が初参加だったというa2cさんは、HASUMIさんのPicoRubyセッションに強い刺激を受け、自身も「Kaigi Effect」によって新たなプロダクト開発に挑戦した、という内容を「全編英語のLT」で披露しました。JavaScriptを一切使わずにRubyとCSSだけで動くリアルタイム投票アプリを開発し、来年の宮崎で食べたいものをその場で投票してもらうデモを見事に成功させました。 10年前の自身の初参加時を思い出したというドラ係のkaibaさんからも、AI時代だからこそ自ら手を動かし、英語で挑戦する姿勢に刺激を受けたという熱い感想が寄せられました。 流暢な英語でプレゼンするa2cさん speakerdeck.com asanoさん：初めてのRubyKaigiはこう見えた 次は、asanoさんによる「初めてのRubyKaigiはこう見えた」という発表でした。 ギフティの新卒2年目エンジニアであるasanoさんは、今回が初のRubyKaigi、初の函館、そして本日が初のLT登壇という「初めて尽くし」の状態でステージに立ちました。RubyKaigi 2026参加前は社内外のベテランから「内容は難しいから2割分かればいい方」と言われて不安を抱えていたものの、いざ現地に飛び込むと会場に溢れる「Rubyへの愛と熱量」に深く感動したと語りました。特に「Ruby Committers and the World」ではコミッターたちの生議論に鳥肌が立ち、その感動から「Kaigi Effect」が発動。Webブラウザ上で人生初「Lチカ」をPicoRubyで実装した快挙が報告されました。 もっとRubyを愛したい、そして英語も勉強したいと語る初々しくも熱い姿に、会場全体が深く共感していました。 RubyKaigiの興奮とコミュニティへの感謝を伝えるasanoさん speakerdeck.com RubyKaigi 2026が2回目以上参加だった方によるLT 次のブロックは、RubyKaigi 2026が2回目以上参加だった方によるLTです。 ドラ係は、Asakusa-bashi.rbsなどのコミュニティ活動や、TypeProfなどのOSSにコントリビュートしているsinsokuさんでした。 ドラ係のsinsokuさん NGTさん：Kaigi Effect Effect 最初は、SmartHRのNGTさんによる「Kaigi Effect Effect」という発表でした。 SmartHRのフロントエンドエンジニアであるNGTさんは、2回目のRubyKaigi参加となる今年、カスタムスポンサ
- Ruby
- RubyKaigi
AIネイティブな開発プロセスへの移行、はじめました — SmartHR勤怠管理の開発チームの取り組み
SmartHR 勤怠管理の開発チームでプレイングマネージャーをしているtkkrです。 2026年の4月から、開発プロセスそのものをAI前提で再設計する「AIネイティブ開発化」というプロジェクトを進めています。AIツールを導入して業務を効率化するという話ではなく、既存の開発プロセスを一度壊して、AIがいる前提で作り直すという取り組みです。 今回の記事では、なぜそんなことを始めたのか、どうやってプロジェクトを設計したのか、そしてプロジェクトで大切にしている考え方を共有します。具体的な実験の詳細や学びについては、後続の記事で共有していく予定です。 AIを使っているのに、なぜ速くならないのか 勤怠管理チームでは、以前からAI活用を積極的に進めていました。Skill の整備もされ、個人レベルでの活用はかなり浸透している状況でした。私自身も、ここ半年は自分の手でコードを書くことはほとんどなくなっていました。 しかし正直なところ、チーム全体の生産性が目に見えて上がった実感はありませんでした。 AIがコードを速く書いてくれても、その前後の開発プロセス（開発アイテムの分割・整理、コードレビュー、動作確認）は従来のままです。ボトルネックが開発プロセス自体にある限り、部分的に速くしても全体のスループットは変わりません。 「AIで既存の業務をどう効率化するか」ではなく、「AIがいる前提で、開発プロセスはどうあるべきか」に問いを変え、既存プロセスの改善ではなく、ゼロベースでの再設計に取り組むことにしました。 プロセスの再設計の専任チームを設ける 「AIがいる前提で、開発プロセスはどうあるべきか」という問いに向き合うために、1つのチームを「実験専用」にして、開発プロセスの再設計に集中的に取り組むプロジェクトを立ち上げました。 実験に集中できる環境がないと、既存業務との板挟みで攻めの改善が難しくなると思ったので、チーム体制とメッセージングの両面で環境を整備しました。 複数の開発チームのうち、1チームを実験専用のパイロットチームとして扱う SmartHR勤怠管理は4つの開発チームで運営しています。全チームで一斉にプロセスを変えるのはリスクが大きいので、1チームをパイロットチームとして2026年4月から3か月にわたって集中的な実験を行い、下期にチーム全体へ展開する計画としています。 チームのミッションは「開発生産性を2倍にすること(1チームで開発出来る開発アイテムの量を2倍にすること)」に設定しました。本来は、開発生産性の評価としては、ユーザー価値の最大化をターゲットとして置くべきですが、まずは明らかに伸びしろのある開発量を設定することにしました。 なお、内部品質（コード・設計の品質）も外部品質（ユーザーから見た振る舞いの品質）も、これまで人間が担保してきたものと同等の品質を前提としており、速度のために犠牲にすることなく進めることとしています。 2026年7月までに最速の状態に到達できるのであれば、機能開発が1つも終わらなくてもよい 勤怠管理チームでは、これまでも機能開発と並列しながら一部のメンバーがAI活用についてのサイドミッションを持つことで、活用を推進してきました。しかし、これまでの活動では思うような抜本的な改善を産むことが出来ていませんでした。 これを受けて、「実験しながらも通常通りの成果を求められること」というプレッシャーを取り除き、リスクを取った実験がしやすい状況を作ることにしました。 ビジネスサイドとも調整し、「このクォーターではパイロットチームの機能開発が1つも完了しなくても構わないので実験を優先して良い」と明言し、クォーターが終了した段階で勤怠管理チーム全体でAIネイティブな開発プロセス・開発体制に移行できるかどうかでプロジェクトを評価するという扱いにしました。この前提を関係者全員で共有できたことで、大胆な実験を可能にする土台を作ることが出来ました。 密度の高い実験ループを回す 大胆な実験ができる環境を整えたうえで、探索の質を上げる仕組みを設計しました。 環境が整っても、「何をやるか」「どう進めるか」が曖昧だと探索の質は上がりません。そこで、判断の軸となるポリシーと、進め方の型となる実験サイクルの2つを用意しました。 ポリシーを明文化し、チームの意思決定の軸を揃える 探索的なプロジェクトは方向が散りやすく、世の中にはすぐ飛びつきたくなるアイデアが沢山あります。チーム全員で同じ方向を向いて意思決定できるように、判断基準となるポリシーを策定しました。 ポリシー 一言でいうと 既存のプロセスにとらわれず逆算する 「これまでこうだった」ではなく「本当に必要なものは何か」から考える インパクトとレバレッジにこだわる 効果が高いものから着手し、薄いと感じたら実施中でも中断する 仮説を立て、検証し続ける やりっぱなしにしない。学びの質を重要視する わかりやすいレポートを出し続ける 実験チームが閉じない。AIが書いたレポートをそのまま渡さない 4つ目のレポートに関するポリシーは、実験チームが社内で孤立しないための仕掛けでもあります。「AIが書いたレポートをそのまま渡す」をNGとしているのは、AIネイティブ開発を推進するプロジェクトだからこそ、人間の言葉で説明責任を果たすことを大事にしたかったためです。 仮説→実験→評価→レポートのサイクルで、「なんとなく良さそう」だけでだらだらと施策を進めない 限られた時間で成果を出していくために、序盤はあえて固めに仮説ドリブンの実験サイクルを設計しました。 まず仮説の定義を決めました。「ある要因に介入すると、ある結果が起こるはずだという予測」です。 例: 「現在の開発アイテムは実装都合で分割されており必要以上に小さい。より大きな単位で開発すれば、リードタイムを短縮できるかもしれない」 蓄積した仮説からインパクトが大きそうなものを選び、実験テンプレート（背景・実施内容・確かめたい仮説・リスク仮説・評価観点）に沿って設計し、実験→評価→レポートのサイクルを回します。 また、この仕組みを運用するにあたって、評価や向き直りを高速に行うために、「プロジェクト初期はペアやモブでの実験を積極的に行うこと」や「毎朝の朝会を長くとり、細かい単位で振り返りを行うこと」を意識しました。 実験の評価をするにあたって、定量的な評価指標も重要ですが、短期的なプロジェクトにおいては評価指標を整えることに時間を割き過ぎるわけにもいかないため、定性的な評価を元にプロジェクトを推進していける状態を保ちました。 実験を重ねて見えてきた3つの方向性 わずか一年前と比べても、コードの調査・設計・実装におけるAIの精度は遥かに進化しており、この進化はこれからも続くと見ています。だからこそ、「AIが情報にたどり着く」「手元の情報から良いアウトプットを出す」といったモデルの進化で解決されていく領域にはあえて手をかけすぎず、モデルがどんなに進化しても残り続ける課題にリソースを集中することを意識しています。 その考え方のもとで、現時点で重要だと見ているのが以下の3つです。 人と人のコミュニケーションのオーバーヘッドを解消する 仮説を立てて複数の実験を重ねるうちに見えてきたメインテーマは、人間同士のコミュニケーションのオーバーヘッドをいかに削減・効率化するかでした。開発アイテムの分割・整理、コードレビューでのラリー。これらは本質的に「人間が人間にタスクを受け渡すための仕組み」です。AIが実装や検証の多くを担えるようになり、実装が速くなるほど、レビューや仕様確認などの人間同士のコミュニケーションがボトルネックとして浮き彫りになりました。 現在は以下の3つの実験を中心として、コミュニケーションコストの削減に取り組んでいます。 実装都合の単位での Issue 分割の廃止 クラウド上で動くAIエージェントを用いた実装業務の脱個人化 暗黙知の形式知化 各実験の詳細は後続の記事でお伝えします。 これらに加えて、AIの活用に限らない開発チームのコミュニケーションの改善にも取り組んでいます。細かなUIや仕様の意思決定のたびに専門職能を呼ぶコストは高く、同期コミュニケーションに頼り切るとスケールしないため、開発チームの自律性がより重要になることを痛感しています。開発チームへの専門職能のイネイブリングや、品質面でのポリシー策定など、チームが自律的に判断できる範囲を広げる取り組みも進めています。 まず小さい機能開発で仕組みを固める 実験を重ねる中で、機能の複雑度や専門度によって、AIに任せられる範囲が大きく変わることを実感しました。特に深いドメイン知識が必要な開発アイテムでは、AIへのインプットを正しく作る仕組みやアウトプットを評価する仕組みを整えるコストが大きくなり、仕組みづくりのコストパフォーマンスが合わないケースも出てきます。 SmartHR勤怠管理の開発アイテムのサイズ分布を見ると、過半数（55%）が2週間程度で開発が完了する小規模なアイテムです。一方、2か月以上かかる大規模な機能も約6%存在します。いきなり全てに適用するのではなく、まずは過半数を占める小規模な開発アイテムを安定して消化できる仕組みを作ることに集中し、そこで精度を上げてから大きな開発アイテムに展開していく戦略です。 改善を正しく評価する仕組みを整える プロセスの再設計を進めるうえで、「改善を正しく評価する仕組み」の重要性が増しています。これはAIの出力の評価と、プロセス改善そのものの評価の2つの側面があります。 AIの出力を評価する基盤を作る AIエージェントに業務を任せるようになると、「その出力はどの程度信頼できるか」や「正しい出力が出せるまでにどれくらいのコストが掛かったか」が避けて通れない問題になります。実験の中でも、品質に関するフィードバックが複数のツールに分散し、評価を人手で回すのではスケールしないことを痛感しました。現在はAIエージェントやSkillの出力を体系的に評価する基盤づくりに取り組んでいます。 また、現段階ではあえてSkillの乱立を許容し、まずSkillが作られること自体を推進しています。評価の仕組みが整ったら、AI自身に自己改善のループを回してもらうというスタンスです。 プロセス改善の方向性を可視化する プロジェクト当初は明らかにインパクトが大きそうな課題が目に見えていたため、「何をやるか」の判断に困ることはありませんでした。しかしプロジェクトが進むにつれ、またAIネイティブ化に関わる関係者が増えるにつれ、「今何に改善の余地があり、どこから手をつけるべきか」を関係者全員で認知できることが重要になってきました。現在はVSM（バリューストリームマッピング）を用いて開発プロセス全体を可視化し、改善の方向性の合意や改善対象の選択に活用し始めています。 おわりに プロジェクトはまだ道半ばで、「開発生産性2倍」にはまだ到達できていませんし、本来追うべき顧客価値の最大化にまではまだ向き合いきれていません。ただ、実験を重ねる中で、最初に目指すべき方向性は見えてきたと思っています。モデルの進化に任せられる領域とそうでない領域を見極め、人間同士のコミュニケーションの再設計・規模別のアプローチの使い分け・改善を正しく評価する仕組みという、3つのテーマに焦点が定まってきました。 既存のプロセスを壊すのは勇気がいります。それなりにうまく回っているプロセスであればなおさらです。それでも踏み切れたのは、「機能開発ゼロでもOK」というメッセージングと、仮説→実験→評価のサイクルによって「失敗しても学びが残る」構造を作れたからだと思います。 このプロジェクトの具体的な実験や学びについては、引き続きこちらで発信していくので、後続のブログ記事もご確認いただけますと幸いです！ We Are Hiring! この記事で紹介したAIネイティブな開発プロセスへの移行は、まだまだ発展途上です。一緒にこの挑戦を進めてくれる仲間を募集中です！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- 開発プロセス
- 生成AI
勤怠管理の開発チームに飛び込んでみた —— 入社半年のふりかえり
こんにちは！SmartHRでプロダクトエンジニアをしているTaiです。 2025年12月にSmartHRに入社し、勤怠管理の開発チームに所属しています。 前職ではフロントエンドエンジニアとしてOCR（光学文字認識）やSCM（サプライチェーン管理）のプロダクト開発に携わっていました。HR・労務ドメインのプロダクト開発は今回が初めてです。 入社から約半年が経ち、チームの中にいることが自然になってきた今だからこそ、ジョイン当初に感じた驚きや発見を残しておきたいと思いこの記事を書いています。 私たちが開発している勤怠プロダクトは、法令・制度・企業ごとの就業規則が複雑に交差するドメインで、入社直後は「これは一筋縄ではいかないな」と率直に感じました。しかし、チームにはその複雑さを乗り越えるためのサポート体制が想像以上に整っていました。会社のバリューがチーム文化に深く浸透していることにも驚かされます。 外から来た目線がまだ残っているうちに、チームの特徴を「文化」と「技術・開発体制」の2つの軸でお伝えしていきます。 チーム文化の特徴 「実装するだけ」の人間がいない 私たちのチームでは、エンジニア全員がユーザー目線を強く意識しています。何かを実装する前に、まず「ユーザーにとってなぜそれが必要なのか」というWhy（目的）を徹底的に掘り下げます。 How（手段）を詰める前にWhy（目的）を大事にする姿勢がチーム全体に根付いています。 そのために、仕様検討などを職種関係なくチームメンバー全員で決めていく形をとっており、エンジニアも要件や仕様の段階から主体的に参加し、「何を作るべきか」をチーム全員で考えます。 この体制は良い循環を生んでいます。仕様検討に関わることでドメイン理解が深まり、その理解が進むことでより良い設計判断ができるようになり、結果としてプロダクトの質が上がっていきます。 私が見てきた限りでは、「言われたものを作る」のではなく、メンバー一人ひとりがプロダクトに対してオーナーシップを持って開発に向き合っているチームです。 リモートでも距離を感じないコミュニケーション チームはフルリモートで開発を行っており、だからこそテキストコミュニケーションを大切にしています。Slackでのやり取りが盛んで、ミーティング中もスレッドで議論や補足が活発に飛び交います。 リモートワークでありがちな「聞きづらい」「様子がわからない」といった距離感は全く感じません。 新しく入ったメンバーへのサポートも手厚く整っています。勤怠プロダクトの開発組織内には複数のチームがありますが、チームを横断して話せる場が設けられています。 自分のチームに閉じず、チーム内外を問わず気軽に相談できるので、ジョイン直後の不安感はかなり和らぎました。 挑戦とフィードバックが日常にある雰囲気 チームには、質問や提案を安心して出せる雰囲気があります。その土台にあるのは、「光の速さでまず動く」というSmartHRが掲げている三つのバリューのうちの一つでしょう。「まずやってみる」を大切にし、挑戦を後押しする姿勢がチーム全体に根付いています。 挑戦が前提なので、間違いを恐れる空気がありません。仮にうまくいかなかったとしても、建設的なフィードバックが返ってきます。 挑戦とフィードバックがセットになっているからこそ、安心して新しいことに踏み出して成長できる環境になっていると思います。 何か気づいたことがあればすぐにチーム全体にフィードバックを求める姿勢があり、それは1on1やふりかえりに限らず、日常のSlackのやり取りの中でも自然に行われています。 フィードバックが特別なイベントではなく、日常の一部になっているチームです。 また、SmartHRにはバリューを表すSlackのスタンプが用意されていて、誰かのアクションに対して都度リアクションとして押されているのをよく目にします。 お互いの行動をバリューの観点から認め合う文化が、こうした小さな習慣を通じて自然と根付いているのだと思います。 認識の「ズレ埋め」文化 SmartHRには「ズレ埋め」という文化があります。認識のズレをそのままにせず、気づいた時点でお互いに指摘し合う文化です。ズレが小さいうちに修正できるので、一人で抱え込んで問題が大きくなるということが起きにくい環境になっています。 何かで連携をとる際にも、互いの認識を揃えてからスムーズに進行できるよう心がける姿勢がチーム全体に浸透しています。Slackには「ズレ埋め」の状況を伝えるためのSlackのスタンプも用意されていて、日常的に活用されています。 課題を一人で抱え込ませないサポート体制 入社直後は慣れない技術スタックやドメインに戸惑う場面もありました。そんなときありがたかったのは、チームが放置しなかったことです。自分が課題を整理する前に、チームが先回りして状況を確認し声をかけてくれて、すぐに「どうすれば改善・解決していけるか」を一緒に考えるフェーズに入りました。こまめに1on1を設けてもらい、自分の状態を定期的に言語化する場があったのですが、これがかなり効きました。掘り出し始めると課題がボロボロ出てきましたが、今まで顕在化していなかった問題を認知でき、良い取り組みになったと感じています。 また、そこからは毎週の振り返りで内省のサイクルを回すようにもしました。その週に何があって、自分はどう感じて、何がうまくいかなかったのかを細かく言語化する。地味ですが、これを続けることで自分の問題のパターンが見えてきます。やったことはシンプルで、問題を洗い出して、それぞれに対するアプローチをブレイクダウンしていっただけです。魔法みたいな解決策があったわけではなく、泥臭く一個ずつ潰していきました。 技術・開発体制の特徴 フロントエンド・バックエンドの垣根がない開発体制 私たちのチームでは、一つの機能をフロントエンドからバックエンドまで通して実装します。「フロントエンドエンジニア」「バックエンドエンジニア」という分業ではなく、プロダクトエンジニアとして機能全体に向き合うスタイルです。 私は前職ではフロントエンドを専門にしていたため、バックエンドは2〜3年まともに触っておらず、RubyもRailsもほぼ浦島太郎状態でした。「いけるでしょ」と思っていた矢先、いざ取り組んでみると思ったより読めないことに気が付きました。 これはまずいということで、チームメンバーにサポートを受けながらキャッチアップの日々が始まりました。SmartHRにはRubyやRails入門のためのカリキュラムも用意されており、体系的に学び直すことができて効率よくキャッチアップすることができました。おかげさまで、今ではかなり読み書きできる状態になっています。 特定の領域に閉じないことで、機能全体を見通した設計判断ができるようになります。フロントエンドだけを見ていた頃には気づけなかった観点が得られる実感があり、大変ではあるものの、エンジニアとしての幅が確実に広がっていると感じます。 大規模なコードベースと丁寧なコードレビュー SmartHRのコードベースは、前職のスタートアップと比べて規模が桁違いでした。前職では0→1の開発が中心で、コードベースは比較的コンパクトでした。改修時の影響範囲もだいたい把握できていて、「ここを変えたら何に影響するか」は感覚でわかることも多かったです。 一方、SmartHRでは影響範囲の調査だけでも結構な労力が必要です。ドメインの複雑さも相まって、一つの変更がどこに波及するのか丁寧に追っていかないと痛い目を見ます。実際に見ました。痛かった。 コードレビューもかなりしっかり行われており、コードに対する自分の理解が少しでも足りていないとすぐに顕在化します。裏を返せば、レビューを通じて理解の甘さに気づける機会でもあり、コードベースへの解像度を上げていく良い糧になっています。この大規模なコードベースに対して、AIをどう活用すれば効率良くキャッチアップできるかを考えることも、良いキッカケになっています。 ドメイン知識にアクセスしやすい環境 先述のとおり、勤怠ドメインは非常に複雑です。しかし、チームにはその複雑さに対応するための環境が揃っています。 まず、ドメインエキスパートへの質問はSlackで気軽にできます。「こういう場合はどうなるんですか？」といった疑問をその場で投げかけられるので、理解が曖昧なまま実装を進めてしまうリスクが減ります。 新機能の実装など、複雑なドメインが絡む場面ではドメインエキスパートによる共有会が開かれることもあり、チーム全体で認識を揃えてから開発に入れる体制になっています。 また、ドキュメントも充実しています。用語集、業務フロー、法令の解説など、ドメイン理解に必要な資料が体系的に整備されています。 入社直後、多数ある労働時間制の仕組み・違いが分からず戸惑いましたが、用語集などで基本概念を理解し、実装に必要な理解を得ることができました。こうした資料のおかげで、後からジョインしたメンバーでも自力でキャッチアップを進められます。 ドメインの複雑さそのものは変わりませんが、「わからないことをわからないままにしない」ための手段がチームとして整っていることが、大きな強みです。 AIを活用した開発文化 勤怠プロダクトの開発組織では、個人個人がAIを活用して開発業務に取り組んでいるのはもちろんのこと、組織としてもAI活用を推進する体制が整っています。その中の1つのチームは、AIネイティブな開発プロセスの実現を専門的に担っています。開発プロセスを可視化し、どの工程をAIネイティブ化できるかを検証したうえで、成果を他のチームへ横展開しています。すでに開発ライフサイクルにAIが組み込まれた業務フローもでき始めており、試行錯誤の段階から実運用のフェーズに移りつつあります。 AIと人間の役割をどこで分けるかについて、明確なルールがあるわけではありません。ただ、チームの基本的な考え方として「どうすればAIに一任できるか」を起点にしています。人間がやるべきことを先に決めてAIに残りを渡すのではなく、まずAIに任せることを前提に考え、人間の判断が本当に必要な部分を見極めていく。この発想の順序が、AI活用を自然に進められている要因の一つでしょう。 半年を振り返って 入社前、勤怠ドメインの理解にはかなり時間がかかるだろうと覚悟していました。法令・制度・就業規則が複雑に絡み合うドメインなので、一人前に議論できるようになるまで相当かかるだろうと思っていたのが正直なところです。 しかし、先述したドメインエキスパートへの相談のしやすさやドキュメントの充実など、チームのサポート体制のおかげで、想像していたよりもずっと早くキャッチアップが進みました。今では仕様検討の場でも自分の意見を出して議論に参加できており、入社前に抱いていた不安はすっかり解消されました。 ドメイン理解も技術面も、まだまだこれからではありますが、半年前には見えていなかった景色が見えるようになってきた実感があります。 まとめ 約半年このチームで過ごしてきて感じる魅力は、「複雑なドメインに対して、メンバーが主体的に向き合っているチーム」だということです。Whyを大事にする開発姿勢、フロントエンド・バックエンドの垣根を越えて機能全体に向き合うスタイル、ドメイン知識への投資、AI活用の推進。そのすべてに、一人ひとりが自分ごととして取り組む姿勢が貫かれています。 このチームで活躍しているメンバーに共通しているのは、主体性を持って動いていることです。 複雑なドメインを自ら理解しにいき、担当範囲を越えて機能全体に向き合う。そうした姿勢がチーム全体の推進力になっています。 勤怠ドメインという複雑で大きなプロダクトの開発を最前線で経験できる機会はなかなかありません。ドメインの奥深さ、チームの文化、技術的な挑戦、どれをとっても貴重な経験が得られる環境です。 私自身、この環境でもっと力をつけて、チームとプロダクトの成長に貢献していきたいと思います。 We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- Ruby
- Rails
- フロントエンド
- 生成AI
SmartHR の人給基幹は何を解いているのか ── 全体像と、いま向き合っていること
SmartHR で人給基幹プロダクト開発本部のエンジニアリングマネージャーをしている yuzuru です。 この記事では、社内で「人給基幹」と呼んでいる領域が、そもそも何を解こうとしているのか、どこに難しさがあって、いまどんな体制で何に投資しているのかを、一度まとめて書いておきたいと思います。このあと、フロントシステム・人事マスタ・勤怠管理・給与計算の各エリアのマネージャーが、自分の担当領域について順番に書いていくシリーズの1本目です。「SmartHR の人給基幹って、何をやっているところなんだっけ」という方、とくに採用候補として SmartHR を見てくれているエンジニアの方に、少しでも具体的なイメージを持ってもらえたら嬉しいです。 このドメインは、外から見ると「すでにやり方が決まっている業務をシステムに落とすだけ」に見えがちなのですが、いざ中に入ると、制度・例外・時間軸・連携の絡み方がかなり複雑で、そこに SaaS としての体験まで乗ってくるので、わりと骨太だなと感じます。 10分くらいで読める分量を目安にしたので、興味を持ってもらえたら、このあとのエリア別の記事も合わせて読んでもらえると嬉しいです。 筆者プロフィール yuzuru（秋山 譲） SmartHR 人給基幹プロダクト開発本部 / Engineering Manager エンジニア歴は約20年。大小様々な企業で EM を務め、2024年12月に SmartHRに入社。 現在は人給基幹全体Directorとして、組織全体の取り組みにも携わっています。 人給基幹が支えている業務 SmartHR が前提にしている社会課題は、人口減少と労働人口の縮小です。企業のバックオフィスは、人手で回すやり方からシステムで支えるやり方へ、もう戻れないところまで来ていると思います。 人給基幹は、そのど真ん中の領域です。具体的に扱っている業務を並べると、 従業員情報と組織情報の管理 入社・異動・昇降格・退職といった発令 勤怠の集計と締め 給与計算と支払い 各種申請の承認フロー 年末調整や社会保険といった帳票 あたりで、どれも「毎月の締め」に直結する業務です。つまり止まると困る業務ですし、法改正が来たから来月から対応します、というわけにもいかない。施行日までに、全顧客に対して当たり前に反映されている必要があります。 この「止められない」という性質が、システムとしての要件をかなりの部分まで決めていると感じます。正確性、監査性、履歴性、可用性、変更容易性。どれか一つでも欠けると、その時点でお客様の業務が止まります。人給基幹は、この水準を当たり前のラインに置いた上で、社会インフラ的な責務を背負っている領域だと思っています。 SmartHR の人給基幹が目指していること SmartHR は人事労務から始まり、タレントマネジメント、給与、勤怠、周辺プロダクトへと領域を広げてきました。その中で人給基幹は、人と組織に関するデータが最初に集まって、他のプロダクトへ流れていくハブ、という位置づけになっています。 ここで常に意識しているのは、個別プロダクトとしての最適と、人給基幹システム全体としての最適の両立です。単体で便利なだけだとお客様の業務は回らないので、プロダクト間の連携やデータの統合性を踏まえた上で、個別のプロダクトを進化させていく必要があります。 人給基幹はすでに多くのエンタープライズ企業で、毎月の業務の中心として使われています。一つの変更が、顧客企業の給与支払いそのものに影響しうる規模で運用しています。新規プロダクトをゼロから立ち上げるときとは、設計制約がまるで違います。「すでにある整合性」を崩さずに進化させる設計力が、日々試されている感覚があります。 中長期では、SaaS の強みを活かした新しい人給基幹システムを作ろうとしています。既存のオンプレ型を単に置き換えるのではなく、 法改正が、施行日までに当たり前に全顧客に反映されている 業務に即した形で、プロダクト間をデータが自然に流れる 共通モデルの上にデータが集約されていて、活用前提の品質が保たれている 連携性と拡張性が高く、標準を保ったまま多様な要件に応えられる 「変わり続ける」前提で進化するので、老朽化しにくい あたりを目指したいと考えています。そしてこれを、既存のオンプレより低い価格帯で提供する。これがもうひとつのテーマです。体力のある大企業にしか届かない品質ではなくて、中小企業まで含めて使える基幹システムを SaaS で作り直す、というところに中長期で投資しています。 なぜ難しいのか ── 制度・時間軸・スキーマ・外部接続 「給与や人事のシステム」と聞くと、法令や業務要件が先にあり、満たすべき処理を正確に実装していく領域だと見られがちです。たしかに、やらなければならないことは多くの場合すでに決まっていて、各社が同じ必須要件に向き合っているようにも見えます。 でも、実際に担当プロダクトを見ていくと、差が生まれる余地はむしろそこに残っていると感じました。同じ制度・同じ業務を扱うからこそ、どこまで迷わず使えるか、AIをどの場面で自然に効かせるか、情報をどう整理して提示するか、アクセシビリティまで含めて誰にとっても扱いやすくできるかが、プロダクトの価値を大きく左右します。 決まった業務をただコードに落とすのではなく、制約の多い領域の中で「どうすれば他社にはない使いやすさを作れるか」を考え続けられる。そこに、この領域の面白さがあると感じています。 制度と例外が重なり続ける 法改正、業界ごとの慣習、会社ごとの就業規則、手当体系、締め日。このあたりが毎年のように動きます。そのうえに、雇用形態、休職、兼務、遡及、差分支給、手作業補正、といった例外が、いくらでも組み合わさってきます。 「4月1日付で休職に入った正社員に、休職中に昇給の遡及適用があって、社会保険の等級変更も重なって……」という話が、ごく日常的に出てきます。こういうものをハードコードではなく仕組みで解けるようにする、というのがこの領域の一つ目の難しさです。 時間軸が複数ある 人給の世界では、「いつ適用されるか（valid time）」と「いつ記録されたか（transaction time）」が普通にズレます。未来日変更（予約）と遡及修正が同じシステムに同居していて、場合によっては同じ従業員のデータに対して同時に走ります。 さらに、「過去のある時点で、この従業員はどう見えていたか」という履歴の視点も重要になってきます。「今の状態」だけを持つデータモデルだと、すぐに破綻する世界です。人事マスタまわりでは、この二つの時間軸を両立させるために、bitemporal なデータモデルを土台にしています。有効日と記録日の両方をキーにして履歴を引ける設計にしておき、予約・遡及・監査といった要求を同じ仕組みで受け止める、というイメージです。どこまでこの仕組みに寄せて、どこは各プロダクト固有の履歴として持つのか。この切り分けは、いまも日々の設計判断の中心にあります。 スキーマが進化し続ける 従業員、組織、雇用、手当。どれも項目が増え続けて、意味も変わり続けていく領域です。新しい手当が生まれ、組織定義が変わり、グループ企業が加わり、入社経路が多様化する。そのたびに、表示・入力・検索・権限・連携のすべてにコストが乗ってきます。 スキーマを柔らかくしすぎると一貫性が壊れて他プロダクトとの連携が崩れるし、硬くしすぎると運用でお客様が困る。どこまで構造化して、どこからユーザー定義に開くか、というラインの引き方は、正直なところ一番難しい部分のひとつです。 外との接続が広い 会計、社労士、勤怠端末、マイナンバー、銀行振込、各社 SaaS、API、CSV。挙げ始めるとキリがないくらい、人給基幹は外の世界とつながっています。それぞれが独自のフォーマットと業務タイミングとバージョン管理を持っている世界です。 全部の連携先に、全部の進化を同じ速度で届ける、というのは現実的ではないので、どの連携をどの優先度で維持・進化させるかを、常に選び続けている状況です。 いま取り組んでいること ── 変更に強い設計と正しさの担保 ここからは、その難しさに対していまどう手を入れているか、の話です。解けるテーマが残っている分だけ、面白さも残っている領域だと感じています。 変更に強い設計へ寄せていく 長年積み上げてきたコアサービスは、制度変更の影響範囲が読みにくくなっている部分が実際にあります。「一見小さな要件のはずが、調べてみると影響先が複数プロダクトに跨っていた」という話も珍しくありません。 ここに対しては、レガシー基盤からの段階的な脱却と、モジュラーモノリス化を進めています。ドメインの境界を定義して、モジュール間の依存方向を静的解析で監視しながら、逸脱を一つずつほどいていく、という地味な進め方です。一気にマイクロサービスに分割するのではなくて、依存を先にほどいてから動かす、という順序を大切にしています。境界の切り方そのものを検証するために、Ruby の動的解析ツールを自作してモジュール境界を探索している話も、テックブログで公開しています。 正しさの担保 給与計算は「1円のズレも許されない」とよく言われます。人給基幹全体でも、計算結果・履歴・監査の説明可能性が、品質の根っこにあります。 「なぜその金額になったのか」を後から完全に再現できること。「いつ、誰が、何を変更したのか」が監査できること。bitemporal な履歴設計と、計算過程のトレーサビリティを、運用コストと見合う形でどこまで作り込むか。ここは一度作って終わり、とはならなくて、継続的に磨き続けている領域です。 体験の一貫性 人給基幹のユーザーは、労務担当者、従業員、管理者、経理、社労士と、立場がかなり違います。それぞれに対して、設定のわかりやすさと、機能の充足性を両立させないといけない、というのがこの領域特有の難しさです。 同じ「申請」でも、従業員から見るとちょっとした変更届に見えて、労務担当から見ると複数プロダクトに波及する重要業務になっている、ということがよくあります。この両面を同じ画面、同じ設定体系の中でどう整理するかは、いまも試行錯誤している最中です。 スケールとパフォーマンス エンタープライズ企業では、数万人規模の従業員を毎月締める処理が走ります。繁忙期には処理が集中するので、ピーク時の負荷は平時とはまったく別物です。 単にスケールアップで殴るのではなく、ドメインに根ざした指標（締め処理のリードタイム、計算時間、検索応答時間など）を定義して、SLO を設定して、異常を「お客様からの問い合わせで発覚する」前に検知する。そこまで踏み込むフェーズに入っています。 基盤としての拡張性 人給基幹は、他プロダクト、他エリアが依存する土台でもあります。ここを動かすときは、外部への波及を最小化しながら、内部のデータモデルは進化させ続ける、という両立が常に求められます。 安定稼働を保ったまま、中身を漸進的に進化させる。このバランスは個人の技術力だけでは持ちきれなくて、チームとしての意思決定プロセスそのものが問われる部分だと感じています。 どんな体制で取り組んでいるか ── 2つの本部と4つのエリア 人給基幹は、大きく2つの本部で動いています。 人給基幹開発本部の体制図 人給基幹プロダクト開発本部 ユーザー価値の最大化をミッションに、エンタープライズ企業に選ばれる人給基幹を作っていく本部です。フロントシステム、人事マスタ、勤怠管理、給与計算の4つのエリアに分かれていて、それぞれが自律したチーム群として動きながら、全体としての整合性も意識しています。 各エリアの中はさらに複数のスクラムチームで構成されていて、チーム単位では自律的に動きます。エリアをまたぐ意思決定や、全体の優先順位調整は、エリア EM とエリア PO が連携しながら進めています。 この4エリアに加えて、本部内にはCRE部（Customer Reliability Engineering）も置かれています。お客様からの問い合わせ対応や不具合改修、Customer Observability の整備を横断で担っていて、プロダクトの信頼性を現場目線で日々支えてくれているチームです。 人給基幹プロダクト基盤開発本部 ── 中長期の土台を育てる本部 人給基幹の各プロダクトが共通して依存する「土台」を育てている本部です。先ほどの章で挙げた技術テーマ、bitemporal データモデルの進化、モジュラーモノリス化、業務指標に紐づく SLO・メトリクス設計、そして止められないサービスの裏側での本番データ移行、あたりを、個別プロダクトのロードマップとは独立した時間軸で担います。 本部内にはスケーラビリティエンジニアリングユニットも置かれていて、先ほど触れた SLO・パフォーマンスまわりを中心に、大規模テナントでの処理性能と可観測性を専門に扱っています。基盤本部の取り組みの中でも、特に「お客様の業務をスケール側から止めない」ためのチームです。 プロダクト本部と基盤本部を分けているのは、機能開発と土台の進化とで、時間軸も意思決定の粒度もかなり違うからです。分けておくことで、短期のユーザー価値提供と、中長期の土台作りを、それぞれのリズムで進められる体制にしています。 基盤本部の取り組みは、テックブログでも個別にまとめています。「履歴の適用日を日付化しました」「自作の Ruby の動的解析ツールを使って、モジュラーモノリスの境界を試行錯誤している話」あたりが、具体を知るのにちょうどいい入口だと思います。 チームの動き方 全社的にスクラムを採用していて、人給基幹でも Scrum@Scale で複数チームの協働を運営しています。レビュー、テスト、リリース、モニタリングは各チームが責任を持ちつつ、データモデルや観測性、SLO といった横断テーマは、エリアや本部をまたいだ場で持ち寄って議論しています。 マネージャーとしての正直な感覚を書いておくと、このドメインは「一人の天才が全部を解く」タイプの問題にはなっていません。ドメインに詳しい人、設計に強い人、運用に強い人、CRE としてお客様の声を持ち帰る人。それぞれが専門性を持ち寄って、ようやく前に進むタイプの領域だと思います。入る側から見れば、自分の強みを複数方向から活かしやすい環境なんじゃないか、といまは感じています。 次回以降の予告 1本目としては、いったんここで筆を置きます。2本目以降は、各エリアのマネージャー自身が、自分の担当領域について書いていく予定です。 2本目：給与計算 3本目：フロントシステム 4本目：人事マスタ 5本目：勤怠管理 人給基幹は、外から見えているよりもずっと複雑で、その分だけ解きごたえが残っている領域だと思っています。このシリーズを通して、「ここで自分が何を解くのか」が少しでも具体的に想像してもらえたら嬉しいです。 SmartHR では、この領域を一緒に解いていく仲間を募集しています。気になった方は、ぜひカジュアル面談でお話ししましょう。次回以降の記事もお楽しみに。
- Ruby
- モジュラーモノリス
- システム設計
TSKaigi 2026参加レポート —— 協賛と登壇と、時々、告知
こんにちは、SmartHR でプロダクトエンジニアをしている@nabeliwoです。 SmartHRは、2026年5月22日〜23日に開催された「TSKaigi 2026」にSilverスポンサーとして協賛し、9名が参加し、1名が登壇しました。 この記事では、イベントの模様と合わせて、スポンサー活動から登壇までの経験をお届けします！ TSKaigi 2026とは TSKaigi 2026は、TypeScriptに関する技術カンファレンスです。今年のミッションも昨年から引き続き「学び、繋がり、型を破ろう」でした。 2026.tskaigi.org Silverスポンサーとして協賛しました SmartHRはTSKaigi 2026にSilverスポンサーとして協賛しました。 TypeScriptはSmartHRのフロントエンド開発において重要な技術であり、このコミュニティの発展に貢献したいという思いから協賛させていただきました。 Silverスポンサーは参加者に配布されるトートバッグにノベルティを封入できるため、フロントエンドエンジニア向けの採用チラシとクリアファイルを制作しました。 その際に、クリアファイルにチラシを挟んだ状態で送付する必要があったため、900部のクリアファイル全てにチラシを一枚一枚手作業で挟み込む作業をしたのですが、たまに雑談をしつつ黙々と作業する時間が思いの外楽しかったなと、今回のイベントの一つの思い出になりました。 封入作業の様子 また、今回は学生支援スポンサーもさせていただきました。 学生支援を担当してくれたメンバーからは、「地方からTSKaigiに参加されていた学生4名と一緒にランチをして、TSKaigiに興味を持っている背景、個人プロジェクトや研究の内容などについて話をしました。美味しいご飯を食べながら雑談をし、実際のSmartHRの社員としての責任などを話すことができ、貴重な時間でした！」とコメントをもらっており、とても良い機会をいただけたと感じています。 本編への参加 当日は9名がイベントに参加しました。 タイミングが合わず全員は揃いませんでしたがSmartHRポーズで 当日企画としてNFCカードを配付して各自好きなURLを登録することでコミュニケーションを促進したり、ネイルやフェイスペイントのブースが設置されていてお祭り感を楽しめたり、はたまたマッサージコーナーを設けて疲れを癒したり、とてもホスピタリティ溢れる素敵なイベントだと感じました。 また公式サイトでは事前に自分の見るセッションのスケジュールを組むことができ、会場であるベルサール羽田空港に因んで飛行機の運行ダイヤのような見た目でシェアできる機能もあったり、よく作り込まれたサイトになっていました。 当日のセッションに関しては、今年はBranded Typesの話が多かったように感じました。 Branded Types自体は去年から採用事例を各所で見るようになった印象でしたが、今年はそれが運用に乗ってメリット・デメリットも含めて話せるくらいにはこなれていったのかもしれないなと思いました。 個人的に特に印象に残ったのはlacolacoさんの「いつテストを書くか？―ソフトウェア開発における安心と不安について考える」とminako-phさんの「柔軟なPDFレイアウトエディタを支える型システム設計 — Discriminated UnionとConditional Typeの実践」というセッションでした。 どちらも豊富な経験と深い考察からしか出てこないような、とても勉強になる内容でした。 docs.google.com speakerdeck.com またブーススペースに関して、多くの企業が趣向を凝らした企画をされていて、どのブースも人で溢れていてとても熱気がありました。 個人的には普段の開発においてAIレビューでとてもお世話になっているCodeRabbitさんのブースでキーキャップをもらえたことが嬉しかったです。 登壇レポート 僕は2日目に「React の props は値の集合ではない — UI の状態を宣言するコンポーネント設計」というタイトルで10分のセッションを行いました。 Reactを使った開発を行う中でコンポーネントのインターフェースについて日々考えていたことをまとめています。 nabeliwo.github.io TypeScriptという言語として深い話をするわけではなかったので、発表前は自分の話す内容が参加者の期待に沿うのかわからず不安だったのですが、終わってみると良い反応をいただけたので安心しました。 どんな話であれ、自分の経験に基づいて生み出された話であれば誰かしら刺さる人はいるものだなと思えました。 緊張しました！ まとめ 個人としては初回のTSKaigiから数えて3回目の参加だったのですが、年々カンファレンスの質が上がっており、TSKaigi運営の皆様には尊敬の念を禁じ得ません。 セッション内容も言語自体を深堀る好奇心をくすぐる話から、明日の業務からすぐに使える実践的な知識までとても幅広く、多くの学びと刺激を得られました。 改めて、TSKaigi運営の皆さま、参加者の皆さま、ありがとうございました！ 次回こそは弊社もブースを出すぞ……！（2年連続落選しました） 事後勉強会を開催します 最後に告知ですが、2026年6月25日（木）にSmartHR主催で「TSKaigi 2026事後勉強会」を開催します。 TSKaigi 2026に参加して「もっと語り合いたい」と感じた皆様、まだまだ参加者を募集しておりますのでぜひお申込みください！ smarthr.connpass.com
- TypeScript
- React
- フロントエンド
AIとリファクタして、人間の出番があったところ
SmartHRで人事評価のプロダクトを担当しているaaasaです。 AI をリファクタの相棒にしてから、開発の進め方が変わりました。設計、コードのたたき台、テストの観点 ―― 一人で考えていた時間の多くを AI との壁打ちに置き換えています。 ただ、AI の案から「どれを採るか」「チームとどう合意するか」などを決めるのは、今のところ人間の仕事です。実際に進めているリファクタを題材に、その役割分担を書き残します。 なお、この記事は 2026 年 5 月時点のものです。AI の能力は日々変わるので、ここで書く「人間がやっていること」もいずれ変わるかもしれません。 題材：似た責務を持つ 2 つのクラスの重複 弊チームに、機能 A・B という似た責務の機能があり、それぞれに MemberResolver クラスが存在します。 app/lib/feature_a/member_resolver.rb app/lib/feature_b/member_resolver.rb どちらも「プロジェクトに紐づく従業員情報を外部 API から取得する」という同じ責務で、コードもよく似ていました。イメージとしてはこんな感じです。 # 機能 A 側 class FeatureA::MemberResolver def initialize(project) @project = project @members = nil end # 対象メンバーを外部 API から取り、id でインデックスする def fetch_members member_ids = @project.project_members.pluck(:member_id) options = { fields: %w(id last_name first_name code status grade).join(","), as_of: @project.as_of, }.compact_blank members = External::MemberRepository.new(...).search_for_feature(member_ids, options) @members = members.index_by(&:id) end def fetched? !@members.nil? end def find(member_id) @members&.[](member_id) end end # 機能 B 側 骨格は同じだが、取得項目や絞り込み条件が違う class FeatureB::MemberResolver def initialize(project, fields:) @project = project @fields = fields @members = nil end def fetch_members # B 側だけ、対象レコードを持つメンバーに絞り込む member_ids = @project.project_members.joins(:targets).distinct.pluck(:member_id) options = { fields: @fields.join(","), as_of: @project.as_of, status: %w(active on_leave).join(","), }.compact_blank members = External::MemberRepository.new(...).search_for_feature(member_ids, options) @members = members.index_by(&:id) end def fetched? !@members.nil? end def find(member_id) @members&.[](member_id) end end 骨格は揃っていて（initialize → fetch_members → fetched? → find）、違いは fetch_members の中だけでした。機能ごとに取得項目が違ったり、片方にだけ追加の絞り込みが入っていたりします。この重複をどうさばくかがリファクタの出発点でした。 ステップ 1: AI に最初の案を出してもらう 「機能 A・B を共通化したい」と私から AI に提起し、具体的な設計案を出してもらいました。返ってきたのはこの案です。 AI: 機能 A・B 共通の MemberResolver を新設しましょう。メモ化のような便利機能もクラスが吸収するので、呼出側はシンプルになります。 きれいな案で、このまま進んでも良さそうに見えました。 ステップ 2: AI 案を要素にバラして詰める ただ実装に進む前に、立ち止まって詰めた論点が 2 つありました。 論点 a：その「便利機能(fetched?、find)」、本当に共通クラスに置くべき？ 提案された便利機能を一つずつバラして「誰のための仕組みか」を見ると、あるものは片方の機能でしか効かない仕組み（たとえばメモ化）、あるものは 1 行で書ける処理を 1 段ラップしただけでした。 私: 片方しか使わない機能を、共通クラスに置いていいんだっけ？ 「両方が共通で必要だから置く」と「片方の事情を共通クラスに吸収させる」は別の話なので、AI の提案を要素にバラして「誰が必要としているか」を確認する一段が必要でした。 論点 b：「シンプルになる」と「挙動が変わらない」は別の話 ある絞り込み処理(fetch_members)を Rails 側から外部 API のパラメータ側に動かす案が出ました。コードは短くなります。ただし置き場所を動かすと、評価のタイミングもデータソースも変わります。 私: コードがシンプルになるのはわかるけど、挙動は本当に同じになるんだっけ？ 「挙動が変わらない」と言い切るために何を検証するかは、このリファクタの安全を担保する上で人間が詰める論点として残っています。 ステップ 3: そもそも「その新クラスは要るのか」を問い直す 論点 a / b を詰めるうちに、既存コードの構造にも目が戻りました。 外部 API を呼ぶ責務はもともと External::MemberRepository にあり、これは「外部 API への薄いラッパー」として用途別の便利メソッドを足していくスタイルで育ってきたクラスです（以降では「Repository」と呼びます）。一方、機能 A・B の MemberResolver は、この Repository をさらに機能ごとにラップしたものなので、外部 API ラッパーの上に薄い抽象がもう一階乗っている状態でした。 私: そもそも MemberResolver を作る必要はあるのか？ Repository でなんとかできないのか？ 論点 a で見た「便利機能」の多くは別の場所に置ける性質のものです。それなら Repository に用途別メソッドを 1 つ足すほうが、Repository の役割とも揃います。AI に「Repository に寄せる案」を出させるとこちらもきれいに成立し、チームに相談する選択肢が揃いました。 ステップ 4: 2 案 + 現状維持を並べてチームに問う 個人で決めず、チームに選択肢を並べて示しました。 A. 現状維持：触りません。 B. External::MemberRepository に便利メソッドを追加：既存 Repository に用途別メソッドを生やします。 C. 共通 MemberResolver クラスを新設：AI が最初に提案した案です。 上記の比較を Slack に投稿して意見を募りました。個人推しは B 案、つまり「既存と揃う」「新規クラス不要」でした。 ステップ 5: チームの結論 ― C 案に落ち着いた 結論は C 案でした。個人推しとは違いました。C 案が選ばれた理由は次のようなものです。 機能 A・B の責務「従業員情報を取る」は Repository の他メソッドより特化した文脈を持ち、Repository に置くと用途特化メソッドが増えていきます。 チームに「クラスを分けるほうが責務が明確」という共通認識がありました。 個人で B 案に進めずに先にチームに相談してよかった、と思える結論でした。 AI に任せきれず、私が引き取っていた 5 つの責務 振り返ると、AI に任せきれず私が関わった場面がいくつかあります。 ① 「片方しか使わない機能」が共通クラスに紛れていないか見極める AI は便利機能をまとめて提案してくるので、そのまま受け取らず、一つずつバラして「これは両方から本当に必要とされているのか、片方の事情を共通クラスに吸収しているだけなのか」を確認するのは人間の仕事でした。 ② AI の「シンプルになる」案で、挙動が本当に同じかを聞き直す シンプルになる案で、「挙動は本当に同じになるのか」を AI に聞き直すのは人間の仕事でした。 ③ 「そもそも」の問い直し 「重複を消したい」と伝えれば重複を消す案が出ましたが、そもそもこの問題設定で良いのかを問い直すのは人間の仕事でした。 ④ 既存コードの責務を AI に教える 「Repository は外部 API への薄いラッパーで、用途別の便利メソッドを並べていくクラス」という役割は、AI には伝わっていませんでした。今回はその役割を知っている人間が AI に教えたうえで、「Repository に寄せる案」を出してもらえる状態になりました。既存の役割に寄せるか / 新しい役割を持ち込むかの判断も、コードの歴史を知る人間が担いました。 ⑤ チームへの合意形成 個人推しは B 案、チームの結論は C 案。個人の最適解とチームの最適解は別物で、その差を埋めるのは人間の仕事でした。 おわりに ここに書いた「私が引き取った責務」は、AI の能力が上がればいくつか移っていくかもしれません。コードベース全体の文脈を読ませる仕組みが整えば④はなくなるだろうし、長い思考が安定すれば①や③も任せられるかもしれません。 引き続きAIを活用しながらリファクタを進めていこうと思います。 We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ リファクタにせよ新規開発にせよ、AI を活用しながら設計判断にこだわって進めたい方、お待ちしています。 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- リファクタリング
- Rails
- 生成AI
人生（ほぼ）初登壇したので、内容の補足や感想などをまとめてみました
こんにちは。QAエンジニアのtaikiです。 2026/05/19に QA Test Talk Vol.6 がSmartHR イベントスペースで開催され、「横断組織出身のQAEがインプロセスQAEでつまずいたこと・活かせたこと」というテーマで僕が登壇しました。 筆者の登壇中の写真 本記事では、登壇資料では話しきれなかった内容の補足や、初登壇を終えた感想などをまとめています。 なぜこの内容で登壇したか SmartHR入社前に色々調べたものの、インプロセスの動き方や横断QAとの違いについて、実体験に基づいて書かれた記事はあまり見つかりませんでした。 そのため、入社後のイメージを付けづらく、不安を感じていました。入社し10か月が経ち、インプロセスQAの動き方もわかってきたので、同じように悩んでいる人の参考になればと思いこの内容で登壇することにしました。 自身の限られた経験に基づく内容になっていたため、他の人の参考になるのかあまり自信がありませんでしたが、登壇後に「参考になった」という声を複数いただけて嬉しかったです。 登壇内容について タイトルは 「横断組織出身のQAEがインプロセスQAEでつまずいたこと・活かせたこと」で、次のようなことをお話しました。 SmartHRに入社するまでは横断QAの動きだけで、インプロセスQAの動きを経験していなかった 横断QAは複数チームのテストを横断的に担当する役割 インプロセスQAは特定の開発チームに入り込んで品質保証を行う役割 僕の所属しているチームでは横断とインプロセスの役割が混在していたため、入社してからはインプロセスQAとしても動いていく必要があった 最初はインプロセスQAの動きがわからず、慣れている横断QAの動きをそのまま実行してしまい、つまずいてしまった チームメンバーとのコミュニケーション面 プロダクトの開発ロードマップに品質保証を観点を入れることができていなかった インプロセスQAの動きの中で、横断QAの経験が活きる場面もあった 具体的な内容はスライドをご覧ください。 speakerdeck.com 初登壇の感想 ほとんど初めての登壇で緊張していましたが、実際に話し始めると資料に書いていない内容も話せて、意外と余裕がありました。 理由としてはコアとしたい内容が固まっていたことや、事前に何度か通しで発表練習していたことが大きかったのだと思います。 （格闘技の試合など、もっと緊張する場面を経験していたというのもあるかも？？） 内容がAIに関係無いもので、さらに汎用性の高くない個人の経験に関する内容だったため、興味をもっていただけるのか不安でした。 しかし登壇後に「こういう泥臭い内容いいですよね」という声をいただけて嬉しかったです。Xでもポジティブな反応をいただけて、登壇して良かったなと思いました。 自分にとっては「大きな成功事例」ではないものや、「泥臭い経験」に思える内容でも、需要があるということを知れてよかったです。 僕は今回が初登壇でしたが、やりたいと意思表示をすると挑戦させてもらえる環境がSmartHRにはあると感じました。 また登壇までの流れも丁寧にサポートしてもらえたので、初めての登壇でも安心して挑戦できました。 We Are Hiring! 本記事を読んで、SmartHRの品質保証本部に興味を持っていただけましたら、カジュアル面談をぜひご検討ください。 登壇内容の話題や組織に関する事など、気になることがあればお答えします。 私たちと一緒に新たなSmartHRの品質保証本部を築いていきましょう！ open.talentio.com
- QA
「教える」から「引き出す」リーダーへ──感情知性とコーチングを組織で育むSmartHRの実践
こんにちは、SmartHRでアジャイルコーチをしている@wassanです。 AIの進化が止まりません。エンジニア一人ひとり、そして開発チームは、AIを活用するスキルや、それを前提とした新しい働き方に常に挑戦することが求められる時代になりました。 しかし、AIをどう使えばよいのか、チームの仕事をどう変えればよいのか？正解は誰も持っていません。 試行錯誤しながら、自分たちで答えをつくっていくしかない時代です。 そうしたなか、エンジニアリングマネージャー（以下EM）の役割も大きく変わろうとしています。これまでのように自分の成功体験を教えたりシェアしたりすることよりも、 メンバー一人ひとりの挑戦を促し、引き出す ことが、EMの中心的な仕事になってきています。私もSmartHRのEMの皆さんと話す中で、強くそう感じています。 一方で、 「そもそもAI時代に、EMという役割は要るのか？」 という問いも、最近よく耳にするようになりました。アメリカの先端的な開発現場では、エンジニア一人がAIを活用し、これまでより広い範囲を自律的に担う「個人＋AI」型の働き方も見え始めています。AI時代に個人の自律性とAI活用力がこれまで以上に重要になることには、私も強く共感しています。 ただ、個人がAIで強くなるほど、 孤立や、チーム内の対話の減少といった副作用 も起きやすくなります。特にSmartHRのような、 業務理解・法令・顧客の運用・プロダクト体験が複雑に絡むSaaS開発 では、個人の力を高めるだけでは十分ではありません。だからこそAI時代のEMには、 「一人ひとりを強くする」と同時に「一人にしない」関わり方 が求められる── 私はそう考えています。 では、AIと協働する時代、EMに本当に必要なスキルは何なのでしょうか？ この問いに対する私なりの仮説は、次の2つです。 コーチングスキル：答えを教えるのではなく、心理的安全性の高い場を作り、相手の中にある答えを引き出す関わり方 そして、その土台にある 感情知性（EQ：Emotional Intelligence）：自分と相手の感情に気づき、適切に扱う力 聞き慣れない言葉が並んだかもしれませんが、安心してください。私自身、日本の大企業で働いていた頃は、こうした言葉とは無縁でしたし、むしろ「感情」を仕事に持ち込むことは良くないことだと信じていました。 この1ヶ月、私はアジャイルコーチとして、SmartHRのEMと一緒に、AI時代のマネジメントのあり方を探りながら、EM同士がお互いの感情知性とコーチングスキルを高め合うプログラムを実施してきました。 このブログでは、 なぜAI時代のEMに感情知性とコーチングが必要なのか 、私自身がそこに辿り着いた経緯、そしてSmartHRで実際に行ったトレーニングの中身と手応えを、できるだけわかりやすくご紹介したいと思います。 なお、AI時代のEMには、 AI時代の組織のあり方のビジョンを描き、そこに向けて組織を設計していく力 ── 対話を通じた共有ビジョンづくりや、AIを前提にしたチーム編成・ワークフロー・AIエージェントの組み込み方の設計のスキル ── も同じくらい重要になっていきます。こちらはそれだけで一本書きたいテーマなので、続編として書きたいと思っています。本ブログでは 感情知性とコーチング に絞ってお話しします。 私が感情知性の重要性に気づいた日 アジャイルコーチを名乗っている私が、恥ずかしいことにいちばん寄り添えなかった相手は、自分の息子でした。 息子の中学受験のとき、私は偏差値という数字に、自分でも驚くほど振り回されました。「もっとできるはず」「なんで勉強しないんだ」── 普段クライアントには「チームを信じて任せましょう」と言っているくせに、家に帰ると、塾の宿題を全くしない息子を見ては不安で胸がざわつき、叱りつけながら無理やり勉強をさせていました。 親の期待を押し付ければ押し付けるほど、息子は反発し、関係性は悪化していくばかり でした。 当時の私の頭の中は、こんな問いでいっぱいでした。 なぜ息子は勉強してくれないんだろう。どうすれば勉強させられるんだろう。 今ふりかえると、この問い自体が間違っていたのですが、当時の私には気づけませんでした。「息子のために」と思いながら、実は自分の不安を解消するために、息子を動かそうとしていただけだったのです。 藁をもすがる気持ちで、私はコーチングの本を読みあさり始めました。そして一冊の本に出会います。リチャード・ボヤツィス教授らの 『Helping People Change（邦題：成長を支援するということ）』 です。 人が成長するメカニズム──ありたい姿と、共鳴する関係性 『Helping People Change』を読み進めて、私は自分の親としての「育成」観がいかに的外れだったかを思い知らされました。 この本のメッセージを一言でまとめると、こうなります。 人が自律的に成長し続ける源は、 「ありたい姿（Ideal Self）」に向かうポジティブな感情 であり、それを引き出すのは 「共鳴する関係性（Resonant Relationship）」 である。 少し噛み砕くと、こういうことです。 社会からの勝手な期待を押し付けられると、人は「やらなきゃ」「直さなきゃ」というネガティブな感情を抱き、成長は一時的なものにとどまります。一方で、自分の 「こうありたい」というビジョン（＝ありたい姿） が明確になると、内側からエネルギーが湧き、自然と挑戦に向かっていきます。そして、そのありたい姿は一人では描けません。安心して話せて、本気で関心を寄せてくれる相手がいる── そんな「共鳴する関係性」 があって、はじめて言葉になっていくのです。 このメカニズムを意図的に引き出す具体的な手法が、 コーチング です。コーチングとは、ひとことで言えば 「相手の中にある答えを、問いと傾聴で引き出していく関わり方」 です。 ただし、コーチングは「質問のテクニック」だけでは成り立ちません。自分の正解を押し付けず、相手を評価・判断せず、相手のありたい姿を本気で引き出すためには、 自分の感情と相手の感情を切り分け、判断を脇に置き、ただ聴く ことが必要になります。これは、極めて高い 感情知性 を要求する営みです。 本に書かれていることを息子との関係に適用しようとして、私はすぐに気づきました。「ありたい姿を引き出す問い」を投げかけようとしても、不安が顔を出して口を挟みたくなる。「待つ」と決めても、待ちきれずに自分から正解を渡してしまう。私自身の感情知性が、まったく追いついていなかったのです。 もっと本気で学ばないとダメだ、と思いました。私は『Helping People Change』を日本語に翻訳することを決め、さらにアメリカのケースウェスタンリザーブ大学まで行き、ボヤツィス教授らのもとでコーチングを学びました。 そこで知ったのは、 アメリカでは企業のリーダーが感情知性とコーチングを「ビジネススキル」として体系的に学んでいる という事実でした。 Google には、社員の感情知性を高めることを目的とした自社プログラム「Search Inside Yourself」があると知られている Amazon にも、感情知性を学び合う社内コミュニティ「EQ@Amazon」があると言われている Microsoft のCEOサティア・ナデラ氏は、 「AI時代、感情知性の伴わないIQは無駄である（IQ without EQ is a waste of IQ）」 とまで言い切っている*1 これらは、AI時代になって突然出てきた話ではありません。以前から先進的な企業ではリーダーシップの重要なビジネススキルとして扱われてきたもので、AIで技術的な仕事が自動化される今、その重要性はさらに高まっているように感じます。 この考え方を、日本企業でも本気で実践したい。そう思って今に至ります。 SmartHRの感情知性・コーチングトレーニング AI時代において、リーダーに求められるのは感情知性やコーチングスキルなのではないか── SmartHR社内でそう考えていたのは、幸運なことに私だけではありませんでした。トレーニングの設計のためにSmartHRのEMにヒアリングをしてみると、彼らも同じ考えを持っていることが分かりました。 「答えを教えるマネージャーとしての役割はある程度できている。でも、メンバーの ありたい姿 を引き出して、自律的に挑戦してもらうことが、十分にはできていない」 「コードの書き方や設計はAIがどんどん担ってくれる。じゃあEMに残るものは何なのか、まだ見えていない」 コーチングや感情知性の話をすると、ヒアリングをした6人のEMが全員、一緒に学びたいと言ってくれました。そして、彼らとともに1ヶ月で「 理解 → 自己探求 → 実践 」を一巡できるプログラムを設計しました。 具体的には、Day1（オンライン）とDay2（オフライン）の2日間の講義を軸に、その間に個別セッションと360度感情知性アセスメントを挟む、 約1ヶ月のプログラム を設計しました。 セッション 形式 狙い Day1（3時間／オンライン） 講義＋ケーススタディ 感情知性とは何かを知り、ケーススタディで腹落ちする 個別セッション①（60分） 1on1コーチング 自分の ありたい姿 を探索する 360度感情知性アセスメント 自己＋メンバー＋上司 多面的に「現実の自分」を知る 個別セッション②（60分） 1on1コーチング アセスメント結果を読み解き、自身の強みと成長機会を探索する Day2（3時間／オフライン） 講義＋実技 感情知性をベースに主体的な成長を引き出すコーチング理論を学び、EM同士でありたい姿に向けた具体的なアクションを引き出し合う 感情知性 は、まずDay1で体系的に理解し、続く360度感情知性アセスメントと個別セッションで 「自分の感情知性の強みと成長の機会」 を明らかにしたうえで、Day2でその伸ばし方を探索する コーチングスキル は、まず個別セッション①でEM自身が コーチングを受ける側 として「自分のありたい姿」を言葉にする体験をし、その効果を体感する。そのうえでDay2の理論学習と ピアコーチング（同僚同士でコーチとクライアントの役を交互に務め、互いにフィードバックし合うコーチングの練習方法）で、今度は 相手のありたい姿を引き出す側 に回って実践する Day1ではまず、ボヤツィス教授の感情知性モデルを扱いました。感情知性は大きく次の4つの象限からなる、というモデルです。 自己認識：自分の感情に気づく力 自己管理：気づいた感情を自分の成長や目標の達成のために上手に扱う力 社会認識：相手や場の感情を読み取る力 人間関係管理：相手の感情を理解したうえで、コーチングやビジョンの提示を通じてリーダーシップを発揮する力 感情知性の概念を理解したうえで、AI時代の架空チーム「沈黙のチーム」のケーススタディでディスカッションしました。このケースは、AI活用が進んだ結果、チームが少しずつ機能不全に陥っていく架空のシナリオです。ちょうど、冒頭で触れた 「個人＋AI」の副作用である孤立や対話の減少が、チーム全体に静かに広がっていく姿 そのものだと言えます。 メンバーは詰まるとまずAIに聞くようになり、ペアプログラミングやコードレビューでの 人と人の対話そのものが減っていく PMとの定例は「AIが生成した仕様書を読み合わせる会」のように変質し、関係は事務的になっていく 経営層からは「 AIコーディングのトークン消費量を追え 」と、現場の状態とはズレた一方的な指標だけが降ってくる EM自身も、メンバーが本当は何に困っていて、どこにやりがいを感じているのかが見えなくなっていく この「じわりじわりとチームから言葉と感情が消えていく」状況に、多くのEMが「他人事じゃない」と顔をしかめていました。 ここからディスカッションは「 この状況を、EMはどう打開していけるか？ 」へと移っていきました。出てきた打開策は、新しいツールやプロセスを入れるという話ではなく、 EM自身の、メンバーやチームへの関わり方を変える ところに集中していきました。 AIに置き換わられる不安や、進化についていけない焦りを抱えるメンバー一人ひとりに、 声にならない感情も含めて寄り添う 「自分たちはAIとどう働きたいのか」「どんなチームでありたいのか」を、 対話の中から引き出していく場を、EMが意図を持ってつくる 経営層に対しても、トークン消費量ではなく、 チームに本当に起きている変化を翻訳して届ける どれも、メンバーや場の感情に気づき、自分自身の不安を乗り越えて、安心して話せる関係性を築くところから始まります。つまり、 感情知性とコーチングを土台に持ったマネジメント が、この状況を打開するうえでの大きな鍵になります。 Day1が終わるころには、 「AI時代のマネジメントに感情知性は欠かせないのではないか」 という感覚が、参加したEMの間で共有されていきました。 個別セッションでは、私がコーチとしてEMの皆さん一人ひとりに向き合いました。ここは、プログラムの中でもとくに EM自身がコーチングを「受ける側」として体感する 重要なパートです。1回目は「ありたい姿」、2回目はアセスメントを踏まえて「現実の自分」をテーマに、60分ずつのセッションを行い、SmartHRのリーダーとして、一人の人間として、これからの人生におけるありたい姿や自身の強み、成長の機会をともに探索しました。普段は組織の言葉で語るEMの方が、ふと自分のキャリアの原点や、本当にやりたかったことを語り始める瞬間が何度もありました。コーチングを通じて自分のありたい姿が言葉になっていく体験そのものが、Day2でメンバーのありたい姿を引き出す側に回るときの、大きな手がかりになります。 Day2はオフラインでSmartHRの本社オフィスに集まり、コーチング理論を体系的に学び、その上でその実践を行いました。後半は、各自が自身のありたい姿の実現に向けて考えた学習アジェンダをもとに、3人組で「コーチ／コーチを受ける人／観察者」の役割を回す ピアコーチング を実施。お互いのありたい姿に向けた具体的なアクションを引き出し合いました。トレーニングのあとは飲み会を行い、EM同士がさらにつながりを深める場にもなりました。 参加者の声と、見え始めた変化 実際にやってみて、参加してくれたEMからは、こんな前向きな声が届きました。 「自身のリーダーとしての自己認識が高まった」 「アセスメントを通じて、自分自身がより成長したいと素直に感じられた」 「メンバーのありたい姿を引き出し、寄り添うコーチングを、これから現場で使っていけそう」 「コーチングのやり方そのものにフィードバックをもらえるのは、本当に貴重な機会だった」 そしていちばん私が背中を押された声が、これでした。 「この考え方は組織全体に広めたい。チーフ層にもぜひ受けてほしい」 「次は一緒に、チーフ向けの感情知性・コーチングトレーニングをやっていきたい」 トレーニングを「受けた人」が、次に「広げる人」になろうとしてくれている。設計者として、これ以上嬉しいことはありません。 一日で身につくものではない、だからこそ組織で 正直に言うと、感情知性やコーチングは、トレーニングを一度受けたら一日で身につくようなものではありません。 私自身、感情知性を本格的に学び始めて、はや4年以上が経ちます。それでも今でも、私は子供に怒ってしまうことがあります。 ただ── 怒ったあとに 「あ、いま自分は不安だったんだな」 と自分の感情に気づける瞬間が、以前より確実に増えました。目の前にいる息子の表情の奥にある感情に、少しずつ寄り添えるようになってきました。完璧な父親ではないかもしれません。でも、確実に変わってきている。それが、感情知性を学ぶということなのだと思います。 簡単に身につくものではなく、日々のやり取りの中で育むものだからこそ、感情知性は 個人の努力だけではなく、組織として伸ばし合っていくこと が大事だと感じています。フィードバックし合える関係、一緒にコーチングを練習し合える仲間がいる。そういう環境があってはじめて、感情知性は組織の中で育まれていきます。 AIの時代、 マネジメントの感情知性を通じて、メンバーの成長とチームの挑戦を引き出すこと が、組織づくりの鍵になる。 今の私は、そう確信に近いものを持っています。 このプログラムを受けてくれたEMの何名かとは、すでに チーフ層への展開 を一緒にやっていこうと話し始めています。感情知性の高い組織づくりに向けた一歩は、確実に始まっています。 冒頭で触れたように、AI時代には「個人＋AI」で自律的に成果を出していく働き方が広がっていきます。その強さを活かしつつ、副作用までは持ち込まない── AIで一人ひとりを強くする。でも、一人にしない。 そんな組織を、日本の現場から一緒につくっていきたい。それが、感情知性とコーチングに私が大きな可能性を感じている理由です。 We Are Hiring! SmartHRでは、一緒にSmartHRをつくりあげていく仲間を募集中です！ AI時代、新しい働き方に挑戦し続ける、 感情知性の高い組織づくり に一緒にチャレンジしたいEMやエンジニアの皆さん、ぜひカジュアル面談でざっくばらんにお話ししましょう！ <iframe src="https://hatenablog-pa
- EM
- 働き方
SmartHRって新卒で入れるんだ、と思っていた私が新卒入社して感じたこと
はじめまして！SmartHR新卒一期生（2026年4月入社）のKazumaです！ 現在はプロダクトエンジニアとして、勤怠管理機能の開発を担当するチームに所属しています。 26卒として就職活動を始め、SmartHRと関わりを持つようになってからちょうど1年が経つことに気づきました。当時選考中の学生だった自分にとって、SmartHRは他社に比べて新卒採用の情報が少なく、入社してからのイメージが持ちづらかったように思います。 まだまだ歴史が浅く、外からだと見えづらい部分も多いSmartHRの新卒採用について、当事者としてできるだけフラットに（と言っても入社してしまっているので難しいかもしれないですが）書いてみようと思います。 就活時に持っていた印象：「え、SmartHRって新卒採ってるの？」 まずは、私が就活を始めた当時に持っていた、率直な印象からお話しします。 就活を始める前にSmartHRに抱いていたイメージ 私が就活を去年の春（遅いですね）に始めたとき、SmartHRに対して持っていた印象は「イケイケドンドンのユニコーン企業」であり、即戦力の中途しか採用していないというイメージでした。アルバイト先などで使ったことがあり、いけてるUIのSaaSを作っている会社という認識はあったものの、新卒採用のイメージはなく、応募したタイミングでは「なんか最近、新卒もとってるみたいだし一応応募してみるか」といった感じでした。今思うと、とてもいい判断だったなと思います。 選考の中で印象に残ったこと SmartHRの選考で私が特に印象的だったのは、選考プロセスの中で人事担当者のサポートがとても丁寧だったことです。プロダクトエンジニアの採用面接自体は主に技術職の社員が担当しているのですが、選考ステップごとに人事担当者にも相談する時間があります。私のときも、個人的な相談に乗ってもらったり、社員との食事の機会を設けてもらったりしました。 ちなみに、「内定や入社が決まった途端に人事の態度が急に冷たくなる」といった、就活の怖い噂としてよく耳にするような話は一切ありませんでした！ 内定者インターンで体験したこと：はじめての商用コードベースとチーム開発 内定後は、私の大学の卒業時期が秋だったので、去年の8月から週5で内定者インターンとして勤怠管理機能を開発するチームに配属されていました。そのときの様子も紹介します。 スクラムやアジャイルの用語、大規模コードベースの複雑さに戸惑いつつ、サポートを受けて慣れていった経験 本格的なチームでの開発や、実際のプロダクトとして運用している大規模なコードベースに触れることが初めてだったので、最初は本当に何もかもが分からなかったことが記憶に残っています。特に、アジャイル開発、スクラム開発の用語など何ひとつ知らなかったので、プロダクトバックログアイテム（PBI）、プロダクトバックログリファインメント（PBR）、プロダクト要求仕様書（PRD）、レトロスペクティブなどの単語が次から次へと登場して、最初は完全に混乱していました。中途半端な時期の入社だったので体系的な研修などがあるわけではなかったのですが、メンターが毎日相談する時間を設けてくれて、プロダクトについての細かい要望をオンボーディングタスクとして整理してくれたので、少しずつチーム開発の流れに慣れていくことができたと思います。 整った受け入れ"制度"より、誰にでも聞きにいける"空気"に救われたこと 正直なところ、SmartHRは新卒採用の歴史がまだ浅いため、長年新卒採用を行っている企業と比べると、受け入れプロセスが完璧に洗練されているわけではありません。また、就活生にとって「2、3年後の姿」として重なるような、新卒入社の先輩社員も現状ではそこまで多くありません。 しかし、そうした制度面以上に私にとってありがたかったのは、誰にでも気軽に質問にいける社内の「空気」でした。（リモートなのですが）後輩が萎縮してしまうようなコミュニケーションをとる人や、聞きづらい雰囲気を作る人が本当に一人もいません。実は面接の逆質問で「社内で嫌なコミュニケーションをとる人を見たことがない」と聞いたときは「本当かな？」と少し疑っていたのですが、入社してみてそれが本当だったと実感しています。自分に対するコミュニケーションだけでなく、全社が見えるSlackのやり取りなどでも、そういった場面を見たことがありません。 インターンの立場でも、やりたいと手を挙げれば任せてもらえたこと 一般にインターンでは、本番環境のコードベースに触れられない、開発タスクは任せてもらえない、といった話をよく聞くと思います。実際、内定者インターンに開発タスクを任せるには、メンターの方の時間やレビューの手間など、会社側のコストもかかります。 しかし私の内定者インターンでは、他の職種の方とコミュニケーションを取りながら進める必要がある仕事や、パフォーマンス改善のタスクなど、幅広い経験をさせてもらえました。やりたいことや興味がある領域を伝えて手を挙げれば、インターンの立場でも挑戦の機会をいただけたのは、とてもありがたかったです。 新卒入社して気づいたこと：社員として感じるSmartHRの文化と雰囲気 無事に内定インターンを終え、いよいよ正式に新卒入社してから気づいたことを紹介します。 エンジニア職でもビジネスマナー研修があり、社会人として安心して始められた 入社してまずありがたかったのは、ビジネスメールの書き方や名刺の渡し方などを学ぶ機会が、エンジニア職の新卒にも用意されていたことです（実は今年から始まったようです）。正直、入社前はエンジニア職にこうした研修があると思っていなかったので、社会人としてのスタートラインで一度しっかり教わることができたのは嬉しい誤算でもありました。同期と一緒に楽しみながら受けられたのも、いい思い出になっています。 リモート中心でも、新卒は出社機会や部活で孤立しにくい環境 実は私は青森県で働いています。フルリモートで働くということで、入社前は人間関係をうまく築けるか、孤立してしまわないかが少し心配でした。しかし、新入社員には対面での研修期間が設けられており、社内の部活や飲み会などでも既存の社員の方が積極的に誘ってくださるので、リモートワーク中心でありながらも自然と社内の方々と関係を築くことができています。 就活中の学生に知ってほしいこと：先入観を持たずにSmartHRを見てほしい理由 最後に、かつての自分と同じように、SmartHRに対して「新卒で入る会社ではないかも」と感じている学生の方に向けて、伝えたいことを書いておきます。 自分のように「経験者向けの会社では？」と感じている人にこそ知ってほしい 新卒採用に関する情報がまだ少なく、応募のハードルが高いと感じる方もいるかもしれません。しかし、実際に選考を受けてみると、プロセスはとても丁寧で、入社後も心理的安全性が確保されながら成長できる環境が整っています。むしろ新卒の人数がまだ少ないからこそ、社内で活躍している方々と直接話せる機会も多く、新卒だからといって遠慮する必要はまったくないと感じています。 新卒を育てる仕組みやカルチャーが、想像以上に整っている たしかに、長年新卒採用を続けている会社と比べると、受け入れプロセスがすべて完璧に整備されているわけではありません。しかし、スタートアップの新卒採用としてイメージされがちな「崖から突き落として、生き残った人だけが残る」といった世界観では全くなく、毎年どんどん受け入れ態勢は良くなっていると感じます。また、一期生の中でも「自分たちが新卒のカルチャーを作っていくぞ」という動きがあり、これから入ってくる後輩のために自分たちで仕組みを作っていける楽しさもあります。 おわりに：We Are Hiring! SmartHRでは一緒にSmartHRを作りあげていく仲間を募集中です！ この記事では新卒入社の目線から、選考中に感じていたことや、入社してから見えてきたSmartHRの雰囲気について書いてみました。私自身、最初は「SmartHRって新卒で入れるんだ」と思っていた側なので、少しでもSmartHRで働くイメージを持つきっかけになっていたら嬉しいです。 「新卒でSmartHRに入るのって実際どうなんだろう？」と少しでも興味を持っていただけたら、ぜひカジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- SaaS
- アジャイル
- 新卒採用
第91回 Ruby関西 勉強会レポート
こんにちは、ydahです。普段はSmartHRでプロダクトエンジニアとして外部サービス連携基盤の開発をしています。大阪に住んでいてKyobashi.rbの主催や関西Ruby会議09のチーフオーガナイザーをしています。 2026年5月22日（金）に、第91回 Ruby関西 勉強会が開催されました。SmartHRは本イベントに会場提供という形で協賛し、グランフロント大阪タワーAの34階にあるSmartHR大阪オフィスを会場として提供しました。 rubykansai.doorkeeper.jp この記事では、当日の様子をお届けします。 第91回 Ruby関西 勉強会の会場の様子 目次 目次 開催概要 スポンサートーク: やっていき2026 Rubyの配布パッケージの変遷 BareRuby ～VMの殻を破る～ bundler に cooldown 機能ほしい Fiberを理解したい2026春 関西Rubyコミュニティ紹介 関西Ruby会議09 アナウンス おわりに We Are Hiring! 開催概要 第91回 Ruby関西 勉強会は、3年ぶりに開催されたRuby関西の勉強会です。Ruby関西代表のおごもりさんとも話していたのですが、ずっと関西Ruby会議や関西のRubyコミュニティで会っていたので全然気づかず、気づけば前回開催から3年が経っていました。時が過ぎるのは早いですね。会場はSmartHR大阪オフィスで、RubyKaigiで学んだことやRubyに関する話題を持ち寄る会として開催されました。 スポンサートーク: やっていき2026 最初は、私のスポンサートーク「やっていき2026」でした。SmartHR社内でOSS活動や技術イベントへの登壇を後押しする「OSSやっていきの集い」について、ミートアップやプロポーザル支援の取り組みを紹介しました。 「やっていき2026」を発表する ydah Rubyの配布パッケージの変遷 @znzさんによる「Rubyの配布パッケージの変遷」では、Rubyのリリース時に配布されるアーカイブ形式の歴史が紹介されました。最初は tar.gz のみだったものが、tar.bz2 や zip、その後 tar.xz に対応し、最終的に tar.bz2 が削除されるまでの流れを、リリース作業や外部ツールへの影響も交えて解説されていました。 Rubyの配布パッケージの変遷について話す znz さん BareRuby ～VMの殻を破る～ すぎうり（@uproad3）さんによる「BareRuby ～VMの殻を破る～」では、マイコン上でRubyらしい書き心地を保ちながら、より軽量に動かすための構想が紹介されました。PicoRubyで感じたVMの処理時間の課題を出発点に、GCや例外、動的な機能を削り、AOTコンパイルやレジスタアクセスなどマイコン向けの機能を足す「BareRuby」のアイデアが語られていました。 BareRubyの構想について語る すぎうり さん bundler に cooldown 機能ほしい @k-yoshidaさんによる「bundler に cooldown 機能ほしい」では、公開直後のgem versionをすぐにinstallしないためのBundler plugin、bundler_plugin_cooldown の話が紹介されました。アカウントの乗っ取りなどで悪意あるgemがpublishされた場合に、即時に取り込まれる事故を緩和するため、公開から一定期間が経過していないgemのinstallを止めるPoC実装について話していました。 Bundlerのcooldown機能について話す k-yoshida さん Fiberを理解したい2026春 私は「Fiberを理解したい2026春」という話をしました。Fiberを非同期I/Oの仕組みとしてではなく、1スレッド内で制御フローを手動で切り替えるコルーチンとして整理しました。Fiberの理解を深めるために作ったfibrioというストリーミングパーサーを題材に、Fiber#resume と Fiber.yield で1レコードずつ処理を進める実装を紹介しました。 「Fiberを理解したい2026春」を発表する ydah 関西Rubyコミュニティ紹介 おごもり（@ogom）さんによる「関西Rubyコミュニティ紹介」では、関西圏にあるRubyコミュニティがまとめて紹介されました。資料では20のコミュニティのうち、活動中が13箇所、休止中が7箇所と整理されており、Ruby関西をはじめ、AKASHI.rb、Kyobashi.rb、Kyoto.rb、naniwa.rb、Ruby Tuesdayなど、各地域のコミュニティやその特徴が紹介されていました。 関西のRubyコミュニティを紹介する おごもり さん 関西Ruby会議09 アナウンス 最後に、チーフオーガナイザーを務める私から関西Ruby会議09のアナウンスをしました。2026年7月18日に大津市伝統芸能会館で開催されることや、関西のRubyコミュニティが集まる地域Ruby会議として準備が進んでいることを紹介しました。 regional.rubykaigi.org おわりに 久しぶりのRuby関西勉強会をSmartHRの大阪オフィスで開催できて本当に嬉しく思います。 共催を快諾していただいたRuby関西のおごもりさん、ご登壇いただいた皆さん、ご参加いただいた皆さん本当にありがとうございました。 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/smarthr/20260528/20260528100029.png" alt="勉強会の参&#
- Ruby
- コミュニティ
関ケ原Ruby会議01運営インタビュー ── 【後編】RubyKaja、東西の武将、合戦、そして宴へ
2026年5月30日に、関ケ原Ruby会議01が開催されます。SmartHRは本イベントにRubyスポンサーとして協賛しています。 今回は、SmartHRに所属する関ケ原Ruby会議01の実行委員に、イベントの魅力について聞きました。 前編では、開催のきっかけやコンセプト、会場、関ケ原という土地の魅力について紹介しました。後編では、当日の見どころを掘り下げます。トークセッション、RubyKajaの復活、「合戦」や「宴」、関連イベントまで、関ケ原Ruby会議01ならではの企画について聞きました。 regional.rubykaigi.org tech.smarthr.jp 目次 目次 RubyKajaの復活 東軍・西軍に分かれたトークセッション 合戦 宴、前夜祭、イベント 参加登録の状況 関ケ原や岐阜の観光とグルメ 参加者へのメッセージ RubyKajaの復活 ── 関ケ原Ruby会議01では、RubyKajaも実施されますよね。 わいだー：やります。これはかなりやりたかった企画ですね。 おしょうゆ：これは年末ぐらいに持ち上がった企画でしたね。楽しみです。 ── RubyKajaとは何か、あらためて教えてください。 わいだー：RubyKajaは、各地域のRubyコミュニティで活動しているRubyistを、それぞれのコミュニティから推薦して、みんなで褒め称える取り組みです。身近なところでコミュニティを支えている人たちに光を当てる場、というふうに捉えています。もともとは、2012年3月10日に開催されたYokohama.rb #18で、nagachikaさんによって提案されたRubyist Awardsでした。 コンセプトは、「自分の近くの優れたRubyistを皆で褒め称えたい」というものです。遠くのすごい人だけではなく、自分たちの近くで場を支えてくれている人に感謝を伝える。そこに、RubyKajaが大切にしてきた考え方があると思っています。 なっちゃん：わたしも地域のRubyコミュニティにたまに参加するのですが、継続して場をつくってくれている人たちがいるから、ふらっと参加できるんですよね。そういう人たちがいてくれるのは本当にありがたいなと思います。 www.youtube.com ── Kajaはどういう意味ですか？ おしょうゆ：能や狂言の「太郎冠者」から取った言葉らしいです。若手の筆頭、という意味ですね。近くの、新進気鋭のRubyistを称えたい、という願いが詰まった名前です。詳しくは「RubyKajaのご紹介」（Rubyist Magazine）を読んでもらえると。 ── 「近くのRubyistを褒め称える」という考え方が大事なんですね。 わいだー：そうですね。Ruby Prizeのように、Rubyコミュニティにおける顕著な活動実績や功績を称える賞はもちろん大切です。一方で、地域Rubyコミュニティには、もっと日々の営みのような活動があります。 たとえば、毎月、地域.rbの会場を取ってくれる人、毎回来てくれる人、初参加の人に話しかけてくれる人、発表して場を盛り上げてくれる人、イベントの裏側で受付や片付けを支えてくれる人。 そうる：初参加の人に話しかけてくれる人がいるだけで、その場の入りやすさはかなり変わりますよね。 わいだー：そうなんです。そういう活動って、続いているコミュニティの中では当たり前に見えるかもしれません。でも、全然当たり前ではないんですよね。RubyKajaでは、そういう場が続いていくために欠かせない活動にも光を当てたいと思っています。 ── RubyKajaは10年以上ぶりですね。RubyKaja 2026は、どういう位置づけなのでしょうか？ わいだー：RubyKajaは、RubyKaja 2014を最後にしばらく開催されていませんでした。ただ、コロナ禍を経て、今また地域Rubyコミュニティの活動が活発になってきています。地域Ruby会議も各地で開催されるようになってきています。だからこそ、このタイミングでRubyKajaを復活させたいと思いました。 おしょうゆ：新たに地域.rbや地域Ruby会議をオーガナイズする人もたくさん増えてますしね。 わいだー：そうですね。各地で活動しているRubyistがいて、その人たちが日々のコミュニティを支えている。そういう人たちに光を当てて、みんなで「ありがとう」と言える場があるといいなと思っています。 RubyKaja公式サイト ── 関ケ原Ruby会議01でRubyKajaをやることには、どんな意味があると思っていますか？ わいだー：関ケ原Ruby会議01は、岐阜で開催する地域Ruby会議ではありますが、同時に、東西のコミュニティの人たちが集まる場でもあります。東の人も、西の人も、東海の人も、いろんな地域のRubyistが関ケ原に集まる。そういう場でRubyKajaを復活させることに意味があると思っています。各地の「ありがとう」を持ち寄る場にしたいですね。 ── 当日の45分の枠では、何をする予定ですか？ そうる：まず、RubyKajaの趣旨をあらためて紹介したうえで、各地域コミュニティから推薦されたノミネート者を紹介します。そして、ノミネート者の中から選定された5名の方に特別賞として、受賞の証となる品を贈呈します。また、特別賞を受賞された方には、3分程度のプレゼンテーションをしていただく予定です。 ── 参加者には、RubyKajaを通じて何を感じてほしいですか？ わいだー：まずは、ノミネートされた人たちのことを知ってほしいです。「この地域には、こういう人がいるんだ」「このコミュニティは、こういう人に支えられているんだ」と感じてもらえたらうれしいですね。でも、それだけではなくて、自分の近くのRubyistのことも思い浮かべてほしいです。 なっちゃん：参加する人それぞれの中に、「あの人のおかげで続いているな」と思える人が自然と浮かんできそうです。ノミネートされた方を称えるだけでなく、自分の近くにいるRubyistへの感謝にも気づける場になるのが、とてもいいなと思います。 わいだー：ですよね！ RubyKajaは「あの人を褒め称えたい」と思うこと。その理由を言葉にすること。そして、それを読んだ誰かが「自分の近くにも、そういう人がいる」と気づくこと。そこまで含めてRubyKajaなんじゃないかなと思っています。そういう場にしたいと思っています。 Roppongi.rbとOmotesando.rbの合同開催の様子。こうした場も、Rubyコミュニティの日々の営みのひとつ 東軍・西軍に分かれたトークセッション ── セッションについても聞かせてください。 おしょうゆ：今回のタイムテーブルはこんな具合です。 西軍東軍 先鋒 拙者、『型は欲しいが型は書きたくない』者たちとの和睦を結び、るびぃにおける型の領地安堵を実現せんと欲す者也森塚三矢大阪守真年 Sorbetの型がRailsのMVC全てを貫通するまでkazzix14 次鋒 Termfront: Ruby標準ライブラリだけで作るFPS S.H. 気づいたらRubyで100作品 ー クリエイティブコーディングが生活の一部になるまでchobishiba 中堅 New "Type" system on PicoRuby Masataka Pocke Kuwabara Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツールToshio Maki 副将 PicoRubyに於けるRefinementsの再解釈 hasumikin Job戦国時代kinoppyd 関ケ原Ruby会議01では、東西のRubyistによる熱い技術トークが繰り広げられます。写真は、RubyKaigi 2026で登壇するわいだーさん ── 先鋒、次鋒、中堅、副将というのは？ おしょうゆ：なにせ関ケ原なので、Rubyコミュニティの中でも議論が分かれそうなテーマを中心にタイムテーブルを組んでみています（笑）。全部の枠が真っ向対決！ というわけではないのですが、似たテーマについて同じRubyで取り組んでも、これだけの世界の違いが生まれるのか！ という驚きがありそうなタイムテーブルになった気はしています。参加者のみなさんも、こういったテーマに対して自分なりの意見を持ってきてもらえると楽しいかもしれません。 ── たとえば、先鋒は型に関するトーク同士なんですね。 なっちゃん：東軍の「Sorbetの型がRailsのMVC全てを貫通するまで」と、西軍の「拙者、『型は欲しいが型は書きたくない』者たちとの和睦を結び、るびぃにおける型の領地安堵を実現せんと欲す者也」は、どちらもRubyと型に関するトークです。ただ、タイトルからして雰囲気がかなり違いますよね。Rails全体に型を通していく話と、「型は欲しいが型は書きたくない」という話で、同じ型の話でもぜんぜん違う角度から楽しめそうです。 ── 次鋒は、Rubyで何かを作る楽しさが見えそうです。 そうる：そうですね。「気づいたらRubyで100作品」と「Ruby標準ライブラリだけで作るFPS」は、どちらもRubyで作ることの楽しさや広がりが感じられそうです。RubyはWebアプリケーションだけではなく、クリエイティブコーディングやゲームのような領域でも使える。そういう懐の深さが見えるカードになりそうです。 ── 中堅はPicoRubyに関するトークが並んでいます。 おしょうゆ：はい。「Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツール」と「New "Type" system on PicoRuby」ですね。今年のRubyKaigiでもPicoRubyの話は多かったですが、それとはまた一味違った話かも、と思ってます。音が出るのっていいんですよね。 ── 副将は「Job戦国時代」と「PicoRubyに於けるRefinementsの再解釈」。 わいだー：ここも濃いですね。ジョブシステムやRefinementsのように、Rubyを使っている人の間でも考え方が分かれやすいテーマが並んでいます。聞くだけで終わるというより、会場の中で「自分ならどう考えるか」を持ち帰れるセッションになるのではないかと思っていま
- Ruby
- 地域Ruby会議
「磨き上げる」ことから始まる基盤開発 —— マルチプロダクト戦略を支える従業員データ基盤
はじめまして。今年の 1 月に SmartHR にプロダクトエンジニアとして入社した murakami です。 SmartHR では、プロダクト基盤開発本部の EDP（Employee Data Platform）ユニットに所属しています。「Employee Data Platform」という名の通り、プロダクト横断での従業員データ活用を支える「従業員データ基盤」を運用しているチームです。 入社して早 4 ヶ月。入社前の思惑通り、基盤を運用する上での難しさに向き合えていて、日々脳に汗をかいております。 入社してから実際に関わりはじめた従業員データ基盤は、すでにいくつものプロダクトで活用されていて「存在感のある基盤」という印象でした。従業員データ基盤のフェーズを「0 → 1」「1 → 10」「10 → 100」という表現に当てはめるのであれば、「10 → 100」に位置していて、"生み出し、育ててきたものを、より磨き上げていく" フェーズであると感じています。 今回の記事では、一定の成長を遂げている基盤をこれからどのように磨き上げていくのか、現在の状況を踏まえながら紹介します。 プロダクト基盤開発本部と EDP ユニット まずは、私が所属するプロダクト基盤開発本部と EDP ユニットの紹介をします。 プロダクト基盤開発本部は、様々なプロダクトで必要になる共通機能を一貫して提供し、マルチプロダクト戦略を掲げる SmartHR において、プロダクト開発の生産性を高めてレバレッジを効かせる役割を担っています。 その役割の重要性を理解するには、共通基盤がない世界を想像してみるとわかりやすいです。 共通基盤がない世界線では、認証・認可、権限管理、プロダクト間のデータ連携といった共通課題に、プロダクトが各々対応していく状況になります。もちろん、開発が終わったらそれで終了ということはなく、パフォーマンス問題や機能拡張による複雑性の向上、運用負荷の増大などプロダクトの成長に応じて発生する問題にも抗い続ける運命も背負います。また、各プロダクトの体験や品質にバラツキが発生することも避けたいので、プロダクト間で入念にコミュニケーションをとる場も設けられるでしょう。 このような共通課題にコストを払い続けると、プロダクトが提供したい価値のデリバリーが鈍化することは想像に難くないと思います。 プロダクト基盤は、これらの課題を専門チームが一貫して担うことで、各プロダクトチームが価値創出に集中できる環境をつくります。 専門チームが一手に担うからこそ、高い品質を維持しつつ一貫した体験も提供できるようになりますし、プロダクト基盤を利用するプロダクトが増えれば増えるほど組織全体へのインパクトも大きくなります。まさにレバレッジが効く領域ですね。 EDP ユニットは、そんなプロダクト基盤において「従業員データ」の横断活用を担うチームです。 「従業員データ」とは、SmartHR の各プロダクトが管理している従業員に関するデータのことを指します。あるプロダクトは従業員の基本情報を、別のプロダクトは人事評価データを、さらに別のプロダクトはスキルや資格情報を、といった具合に役割やドメインに応じた従業員データをそれぞれ保持しています。 EDP は、このような各プロダクトが持っている従業員データを他のプロダクトでも活用できるようにする「従業員データ基盤」を提供しています。 基盤自体に各プロダクトのデータコピーを持つわけではなく、データの所在はあくまで各プロダクトにあり、基盤はそれらを横断的に参照できる仕組みを提供する、という構造になっています。 従業員データ基盤を支える技術 EDP が提供する従業員データ基盤を支える技術的な柱は大きく 2 つあります。 ひとつが、GraphQL Federation を活用した従業員データの提供。 GraphQL Federation は、複数のプロダクトが持つ GraphQL スキーマを統合して、あたかも 1 つのスキーマであるかのように振る舞う仕組みです。 これによって、各プロダクトが持つ従業員データは 1 つの GraphQL エンドポイントから取得できるようになり、基盤を利用するプロダクトは「どのプロダクトに何のデータがあるか」を意識する必要がなく、1 つのクエリで複数のプロダクトからまとめてデータを取得できます。 --- title: GraphQL Federation による横断的な従業員データ取得 --- graph TB Client["利用プロダクト"] subgraph EDP["従業員データ基盤（EDP）"] Gateway["GraphQL Federation"] end subgraph Products["データ提供プロダクト"] A["プロダクト A<br/>（基本情報）"] B["プロダクト B<br/>（人事評価）"] C["プロダクト C<br/>（スキル・資格）"] end Client -- "1 つのクエリで\nまとめて取得" --> Gateway Gateway -- "GraphQL" --> A Gateway -- "GraphQL" --> B Gateway -- "GraphQL" --> C もうひとつが分散 SQL クエリエンジン Trino を活用した横断検索基盤です。 GraphQL Federation では「プロダクト A が保持している部署データとプロダクト B が保持している従業員のスキルデータを使って、営業部に所属していて SQL やデータ分析のスキルも持つ従業員を検索する」といったような、複数プロダクトが保持するデータを複合的に検索する用途には不向きです。 代わりに、その領域を担うのが Trino を活用した横断検索基盤になります。Trino は複数のデータベースを参照した検索クエリを、単一の SQL で実行することができます。これによりプロダクトをまたいだ柔軟な検索を実現しています。 これらを組み合わせて提供することで、プロダクト横断での従業員データ活用を支える基盤を実現しています。 内側から見た従業員データ基盤の印象 冒頭でも述べましたが、入社してからの従業員データ基盤は「存在感のある基盤」という印象でした。「0 → 1」「1 → 10」「10 → 100」のフェーズであれば、「10 → 100」に位置しています。 そのような印象を私に抱かせた背景にある事実をいくつか挙げてみます。 8 つのプロダクトが従業員データ基盤からデータを取得している 10 のプロダクトが従業員データ基盤を通じてデータを提供している 従業員データ基盤に関する社内 Slack チャンネルの人数が 170 人を超えている プロダクトの関係者を集めた共有会が隔週で予定されている データを提供する側と利用する側で GraphQL のスキーマ調整を進めるなどのセルフサービス的な動きも見られる 利用者からのフィードバックを受け、クライアントライブラリの開発が進められてプロダクトへの導入実績もある 社内の認知も獲得し、利用者含めた基盤を取り巻く体制も形成されていて、プロダクト横断で従業員データを活用するときの「標準的な手段」として確立していると感じました。 この基盤をゼロから生み出し、ここまで育て上げてきた人たちには、本当に大きなリスペクトがあります。 従業員データ基盤をさらに磨き上げていくために 「今の従業員データ基盤をさらに磨き上げていくために、何をどのように取り組んでいくべきだろうか」という問いに対して、入社してからよく想いを巡らせていました。 私が入社した頃には、基盤に対するプロダクト側からの要望は減少傾向にあるとのことで、実際、要望ベースの改修依頼はあまりなかったように思います。 これはプロダクトが使う基盤として一定の成熟と安定運用が実現できている一方で、自ら新しい価値を提案していくことがこれまで以上に求められてきている、ということでしょう。 基盤は使われてこそ価値が生まれる では、具体的にどのように価値を提供していくべきでしょうか。 基盤は使われてこそ価値が生まれるものなので、「より多くのプロダクトに様々なシーンで活用してもらうために何をすべきか」を起点に考えます。 それにあたり、扱う従業員データの拡充を進める方向性は間違いではないと考えています。従業員データの拡充とは、取得できるデータ項目や検索できる項目を増やし、新しいユースケースを実現可能にすることを指しています。新しいユースケースが実現可能になることでこれまで基盤を利用していなかったプロダクトにも広く訴求できるようになります。 ただし、全プロダクトが持つすべての従業員データを提供し切ることが理想形かというと、そうではないです。 あまり使われないデータを提供しても意味は薄いですし、データを提供するプロダクトの保守コストも増えていきます。一度提供してしまうと後から剥がすのにもコストがかかります。利用者のニーズを置き去りにしたまま拡充させていった先には何も良いことはありません。 そのため、先に利用者の様々なニーズを集め、それらのニーズに応えていく過程で従業員データの項目や検索対象が増えていく。そのような構造にデザインしていくのが肝になるでしょう。 Platform Engineering Maturity Model を踏まえると何ができるか また、基盤利用者を増やすにあたり、獲得すべきケイパビリティのヒントを得るため、CNCF（Cloud Native Computing Foundation）が公開している Platform Engineering Maturity Model にも照らしてみます。 このモデルは 5 つの評価軸と 4 つのレベルで構成されていて、プラットフォームエンジニアリングの成熟度を多角的に評価し、何を改善すべきかを整理するためのフレームワークです。 このモデルの評価軸のうち、Adoption（採用）に特に注目しました。Adoption は、プラットフォームの発見や使われ方、使う動機について言及しています。この評価軸のレベルを簡単に説明すると次のようになるかと思います。 Level 1. Provisional（暫定的） 利用は散発的で、噂や偶然の会話を通じてプラットフォームが発見される Level 2. Operationalized（組織的） 組織的なルールやインセンティブなど、外発的な動機づけで利用が推進される Level 3. Scalable（拡張可能） 利用者が価値を実感し、自発的に採用する。利用が自律的に持続する Level 4. Optimizing（最適化） 利用者が単なるコンシューマーを超えて、プラットフォーム自体の改善にも貢献する Level 2 と Level 3 の間に、こちらからの働きかけで利用を促す段階から、自発的に利用する段階への転換点があります。私の所感では、従業員データ基盤はちょうどこの転換点のあたりに位置しています。 すでに多くのプロダクトで利用されていて、セルフサービス的な動きも見られる一方で、「基盤の価値を実感した利用者が、自発的に新たなユースケースを見つけて使い始める」という点ではまだ伸びしろがあると感じます。 「これを使うと自分たちのプロダクトがもっとよくなる」と利用者自身が感じて、自ら手を伸ばしてくれる状態。そこに持っていくための土台づくりも、基盤を磨き上げていくための重要テーマになりそうです。 基盤の磨き上げに必要なアクション ここまでの話から、基盤の磨き上げには次のようなアクションが必要だと考えました。 利用者のニーズを収集し、それに応えていく形で扱うデータの種類や検索の幅を広げていく 基盤を自発的に利用してもらうための土台をつくっていく 利用者が増えることでフィードバックが今まで以上に集まり、求められた機能やデータを提供することで、さらに利用者が増える。この好循環を絶えず回し続けることが真なる「磨き上げ」につながるのではないでしょうか。 一筋縄ではいかない従業員データの拡充 前述した通り、基盤が扱う従業員データを拡充することが重要な施策の一つになると考えましたが、それは思っていたよりも難しそうでした。 チームメンバーにこれまでの話を聞く中で見えてきたハードルをいくつか紹介します。 GraphQL スキーマとの相性 プロダクトが保持する従業員データは、GraphQL のスキーマに落とし込みやすいとは限りません。 プロダクトによっては、お客様ごとに任意の項目を追加できるカスタムフィールドなど、GraphQL スキーマとして表現するのが難しいデータを持っていることがあります。 そのようなデータを無理にスキーマに押し込むと歪みが生じ、破滅をもたらしかねないので、構造の見直しから協議していく必要があります。 データ提供プロダクトとの協調 新たなデータを従業員データ基盤で提供するには、そのデータを持つプロダクトチームの協力が不可欠です。 私たちのチームでデータ提供のための実装を行ったとしても、レビューや仕様のすり合わせは必要ですし、提供後の運用コストもプロダクトチームにのっかっていきます。 通常業務を一時的に止めてでも取り組むだけのリターンを示すのはもちろん、プロダクトチームにはプロダクトチームの優先すべき業務があるため、データ拡充のための諸々の調整を進めていく必要もあります。 横断検索基盤のインフラ Trino による横断検索では、各プロダクトのデータベースに直接アクセスします。 プロダクトへの影響を可能な限り小さくするために Trino はリードレプリカに接続しますが、そもそもレプリカが存在しない場合は新たに構築し、接続するための設定を新たに追加する必要があります。 インフラ設定は私たちのチームでやるとしても、レプリカを新たに構築するのはコストもかかるので、検索基盤への追加が難しいケースもあります。 上記のようないくつかのハードルがある以上、要求を受けてから対応を始めるとリードタイムが長くなることがあります。かといって、未来に使うかも知れないデータ拡充を先んじて準備しておくのはコストに見合わない可能性があります。 結局のところ、利用者のニーズを先んじて収集すること、ニーズから裏打ちされた確度の高いデータ拡充を進めていくことが、どのみち必要になってくるというわけです。 現状の取り組み ここまで、基盤をさらに磨き上げていくために何をしていくべきかについて述べてきました。最後に、それらを踏まえて現在どのような取り組みを進めているのかを紹介します。 「基盤を自発的に利用してもらうための土台づくり」という観点で、従業員データ基盤で何ができるかをお手軽に体験してもらうために AI エージェントからの基盤利用を進めています。 やることとしては、自然言語での問い合わせに対して精度の高い検索結果を返すためのワークフロー構築や、検索品質を高めるためのフィールドメタデータの整備、認証認可周りの対応あたりになります。 これを実現することで、自然言語による従業員検索やデータ取得ができるようになるので、提供しているスキーマを細かく確認する必要はなく、従業員データを活用したユースケースのイメージを利用者に持ってもらいやすくなると考えています。 そして、この AI エージェントでの取り組みは、基盤ニーズ収集としても機能させたいと考えています。社内で従業員データを扱った業務をする人たちに実務でお試ししてもらい、そこで得られたフィードバックを、従業員データ項目や横断検索対象の拡充につなげていく。ここまで何度か言及している「利用者のニーズに裏打ちされたデータ拡充」を実践するための具体的な仕掛けです。 おわりに 今回の記事では、従業員データ基盤を磨き上げていくための取り組みを紹介しました。一口に「磨き上げ」と言っても、利用者のニーズに応えるデータ拡充や自発的に使ってもらうための土台づくりなど 、その中身は多岐にわたります。 また、基盤の改善を進めて利用者が増えていく中で、新しい問題に直面することもあると思います。そうした問題にも立ち向かいながら、基盤を磨き上げていく過程をより楽しんでいきたいです。 We Are Hiring! 今回紹介したのは、私たちが取り組んでいることの一部です。 本記事で取り上げた内容以外にも、全く新しい基盤をイチから構築したり、クライアントライブラリをより使いやすいものにして導入ハードルを下げたり、他にも様々なテーマに取り組んでいます。 この記事では取り上げていない内容も含め、カジュアル面談でざっくばらんにお話できればと思いますので、従業員データ基盤やプロダクト基盤の取り組みに少しでも興味を持っていただけたらぜひご応募ください！お待ちしております！ hello-world.smarthr.co.jp
- プラットフォームエンジニアリング
- GraphQL
- Trino
- 生成AI
Lightning Talks on Hakodate Tram at RubyKaigi 2026 —— 函館市電を1両まるごと貸し切ってLT大会を開催しました！
こんにちは。プロダクト基盤開発本部の@ydahです。 2026年4月22日（水）〜24日（金）に、北海道・函館で RubyKaigi 2026 が開催されました。参加された皆さん、登壇された皆さん、運営の皆さん、本当におつかれさまでした！ SmartHRは RubyKaigi 2026 を盛り上げるべく、本編翌日の4月25日（土）に、少し変わった関連イベントを開催しました。その名も、「Lightning Talks on Hakodate Tram at RubyKaigi 2026」（以下、市電LT）です。LT（Lightning Talks）は1人あたり数分の持ち時間で次々と発表していく、技術コミュニティで親しまれている発表形式です。 smarthr.connpass.com 函館市電1両を貸し切ったLT大会 市電LTは、函館市内を走る路面電車・函館市電を1両まるごと貸し切り、走行中の車内でLTを行うイベントです。 RubyKaigi本編を終えた翌朝、参加者の皆さんには函館市電「駒場車庫前」停留場に集まっていただきました。 今回貸し切りにした函館市電の車両 当日は多くの方にご参加・ご登壇いただきました。ありがとうございました！ 当日の流れ 当日のタイムテーブルは以下の通りです。 時間 内容 9:30〜9:50 受付 9:50〜10:00 主催者挨拶・出発 10:00〜 各停留場間でLT発表 途中 谷地頭停留場付近で小休止 12:00 駒場車庫前にて解散 通常のLT大会では1人5分のように時間で区切ることが多いですが、今回の市電LTでは時間ではなく、2〜3区間を1枠として進行しました。発表の区切りを示すのは、時計ではなく指定の停留場です。 信号や停車時間によって発表時間が少し伸び縮みすることもあり、発表者は車内放送や停留場への到着タイミングを意識しながら話します。通常のLightning Talksでは味わえないライブ感がありました。 車内でLTをするudzuraさん 市電という発表環境の魅力 函館市電の車内には、カンファレンス会場のようなプロジェクターや大きなスクリーンはありません。 そのため、発表スタイルもさまざまでした。大きめの文字で作られたスライドをタブレットで見せる方、紙芝居のように資料をめくりながら話す方、手元のデバイスを見せながら話す方。限られた環境だからこそ、発表者それぞれの工夫が見えるLT大会になりました。こうした工夫が見えるのも、電車の中でLTをする面白さの一つです。 紙資料をめくりながら発表する様子 手元のノートPCのスライドを見せつつ発表する金子さん ※ydahは聞いていないのではなくて、必死で次の停留所の位置をGoogle Mapで調べています 自作ソフトウェア楽器「ぴことん」のデモの様子 突然始まるRubyKaigiクイズもRubyKaigiのイベントならでは 車内は揺れ、外の音が聞こえ、信号待ちもあります。こうした要素を含めて、市電の中でLTをするという体験が成り立っています。 発表はもちろん、車窓から見える景色、車内の揺れ。その全部がイベントの一部になっており、実際に体験してみないとわからない魅力があります。 RubyKaigi Day 4らしいLTの数々 RubyKaigi本編の翌日ということもあり、LTの内容はとてもRubyKaigi Day 4らしいものになりました。 RubyKaigiのセッションをきっかけに試してみたこと、函館での体験、Rubyや周辺技術の話、mrubyから派生した組込み向けRuby処理系であるPicoRubyや登壇にあたって作ったデバイスについての話、まつもとゆきひろ氏が開発するRuby AOTコンパイラSpinelの話、Ruby以外の言語とつないでみた話など、バラエティ豊かなLTが続きました。 RubyKaigiで得た刺激を、まだ熱いうちに聞けるのはとてもよい体験でした。RubyKaigiの余韻を楽しめるLT大会になったと感じています。 函館市電LTの系譜 今回の市電LTは、突然思いついた企画ではありません。技術コミュニティがいつもの会議室やホールを飛び出して、交通機関そのものを会場にしてきた流れの先にあるイベントです。 技術イベントと鉄道の組み合わせという意味では、2013年に都電荒川線を貸し切って、Googleが開発するプログラミング言語Goのハッカソンを行う「電車でGo! 都電荒川線編」という企画がありました。 gocon.connpass.com 「電車でGo! 都電荒川線編」はLT大会ではありませんが、技術コミュニティが貸切電車をイベント会場として使う先行例として、とても印象的な企画です。 今回のイベントに直接つながる電車内LTという文脈で大きな起点になったのは、函館で開催されている技術カンファレンスMariners' Conferenceの「函館市電LT大会」です。 mariconf.connpass.com 函館市電を貸し切り、走行中の車内でLTを行う。単に時間を計るだけでなく、停留場や区間を意識して進行する。 そして、車内の限られた設備を前提に、登壇者がそれぞれ工夫を凝らす。こうした文化は、今の電車LTにも色濃く受け継がれています。 その後、2024年にはYAPC（Yet Another Perl Conference）の函館開催であるYAPC::Hakodate 2024のアフターイベントとして「YAPC函館市電LT」も開催され、函館における電車LTの系譜はさらに広がっていきました。 connpass.com そして、わたし自身がチーフオーガナイザーを務めた関西Ruby会議08では、アフターパーティーとして京都の叡山電車を貸し切った「叡電LT」を開催しました。叡電LTはまさに、函館で開催されてきた市電LTを大いに参考にして企画したものです。 ruby-tuesday.doorkeeper.jp 叡山電車の1両を貸し切り、2〜3区間を1枠として、Rubyistが次々にLTをしていく。 車内放送用マイク、紙資料、iPad、モバイルモニターなどを使いながら進行するLTは、いつものLT会とはまったく違う感覚があり、実際に体験してみないと得られない、とてもよい時間でした。 その体験が本当に素晴らしかったからこそ、RubyKaigi 2026の開催地が函館に決まったとき、「かつて参考にした原点の地で、もう一度やりたい」と強く思いました。 Mariners' ConferenceやYAPCで開催された、函館市電LT。それらを元にして京都で開催した、叡電LT。 そして今回、RubyKaigi 2026 Day 4の函館市電LTとして、ふたたび原点の地・函館へ。 今回の市電LTは、そうした電車LTのバトンを、RubyKaigiで函館に戻すイベントでもありました。 かつて大いに参考にした原点の地に帰り、開催できたことは本当に嬉しく、個人的にも感慨深い時間でした。 参加・登壇いただいた皆さまへ ご参加いただいた皆さん、LT登壇してくださった皆さん、ありがとうございました。 また、開催にあたってご協力いただいた函館市電の皆さま、RubyKaigi 2026の関係者の皆さま、本当にありがとうございました。 RubyKaigi 2026の3日間を終えた翌朝に、函館市電を貸し切ってRubyistがLTをする。 少し変わった企画でしたが、函館という開催地だからこそできた、RubyKaigiの余韻を楽しむ良いDay 4イベントになったと思います。 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/smarthr/20260521/20260521120019.png" alt="&
- Ruby
- RubyKaigi
これって同じじゃないんですか？ —— Redux で踏んだ shallowEqual と配列の落とし穴
こんにちは。2025年に新卒 0 期生として SmartHR に入社したプロダクトエンジニアのかずえもんです。SmartHR の様々なプロダクトの中で、私は届出書類機能の開発チームに所属しています。 届出書類機能は SmartHR の中でも歴の長いプロダクトで、状態管理ライブラリには当時主流であった Redux が採用されています。入社するまで Redux を触ったことがなかった私が、Redux を通じて JavaScript の比較にまつわる落とし穴に遭遇した話をします。 Redux とセレクター: state の基礎 Redux はアプリケーション全体の状態（state）を管理するためのライブラリです。state は唯一のグローバルなオブジェクトとして管理され、コンポーネント側から必要な値を取り出して利用します。 state から値を取り出す関数をセレクターと呼びます。React Redux が提供する useSelector フックにセレクターを渡すことで、コンポーネントは state の変化に応じて自動的に再レンダリングされます。 // state 全体を受け取り、必要な値だけを返すセレクター const selectUsername = (state: RootState) => state.user.name // コンポーネント内でセレクターを渡して値を取り出す const username = useSelector(selectUsername) useSelector は、セレクターの返り値が前回と変化したときだけ再レンダリングを実行します。返り値の変化はデフォルトでは === で比較されます。ここで注意が必要なのは、セレクター関数の中で配列やオブジェクトを新規に作成して返す場合です。 例えば以下のようなセレクターの場合、state が変わっていなくても呼び出すたびに新しいオブジェクトが生成されるため、=== で比較すると常に「変化あり」と判断されてしまい、name と age が変わっていなくても再レンダリングが発生してしまいます。 const selectUser = (state: RootState) => ({ name: state.user.name, age: state.user.age }) // 不要な再レンダリングが発生してしまう const { name, age } = useSelector(selectUser) そこで利用できるのが、React Redux が提供する比較関数 shallowEqual です。useSelector の第2引数に shallowEqual を渡すことで、オブジェクト全体の参照ではなく各プロパティの値を個別に === で比較するようになります。すなわち name か age の値が変わっていなければ再レンダリングは実行されません。 const selectUser = (state: RootState) => ({ name: state.user.name, age: state.user.age }) // shallowEqual を設定すると再レンダリングを抑制できる const { name, age } = useSelector(selectUser, shallowEqual) 常に shallowEqual を使いたい場合は、React Redux の公式ドキュメントでも紹介されている useShallowEqualSelector というカスタムフックを作成しておくと便利です。 import { useSelector, shallowEqual } from 'react-redux' export function useShallowEqualSelector(selector) { return useSelector(selector, shallowEqual) } プロダクト内でもこのカスタムフックを利用しており、次のような書き方で複数の値をまとめて取り出していました。 const { docIds, status } = useShallowEqualSelector((state: RootState) => ({ docIds: getActiveDocIds(state.docGroup, state.doc.currentDoc?.docMasterRevisionId), status: getDocGroupStatus(state.docGroup), })) Redux の warning が教えてくれた 書類の詳細画面に関するレビューをしていたある日、ブラウザの開発者コンソールを眺めていたら warning が出ていることに気がつきました。 Selector unknown returned a different result when called with the same parameters. This can lead to unnecessary re-renders. 「同じインプットに対して、セレクターが異なる結果を返している」という内容です。「shallowEqual を使っているのになぜ？」と疑問に思い、調査を開始しました。 鍵は shallowEqual 関数の比較ロジックにありました。 shallowEqual が渡された配列やオブジェクトを比較するとき、それぞれのプロパティの値は === で比較されます。次の表は、 shallowEqual に対して空の配列、同じ値の入った配列、配列が入ったオブジェクトを渡したときの比較結果をまとめたものです。 式 shallowEqual の結果 shallowEqual([], []) true shallowEqual([1], [1]) true shallowEqual({ ary: [] }, { ary: [] }) false [] や [1] 同士を shallowEqual で比較すると true になります。前述の通り shallowEqual は渡された配列・オブジェクトをプロパティごとに見て === で比較するためです。つまり shallowEqual([1], [1]) では 1 === 1 が比較されていることになります。 しかし { ary: [] } のようにオブジェクトのプロパティが配列の場合は false になります。プロパティ ary の値を === で比較するとき、それぞれの [] は別のインスタンスであるため参照が異なると判断されるためです。 useShallowEqualSelector でオブジェクトにまとめて複数の値を取り出す手法ではまさにこれが落とし穴になります。問題になっていた getActiveDocIds の実装を見てみましょう。 export const getActiveDocIds = (state: DocGroupState, docMasterRevisionId: string | undefined) => { const docsPerdoc = state.current.docGroup?.docsPerDoc.find((doc) => doc.docMasterRevisionId === docMasterRevisionId) return docsPerdoc?.docIds || [] } find の結果が存在しない場合に [] を返しています。このリテラル [] は呼び出すたびに新しい配列インスタンスを生成します。つまり、各値を取り出すセレクター関数の中にこのような呼び出すたびに新しい配列を生成するものが含まれていると、そのプロパティは常に === で false と判断されてしまい、shallowEqual を使っていても docIds プロパティは常に「変化あり」と判断されて再レンダリングが走り続けていたのです。 createSelector でセレクターをメモ化する 呼び出すたびに新しい配列を生成してしまう場合、Reselect が提供する createSelector の出番です。createSelector は計算をメモ化するための関数で、インプットが変わっていなければ再計算をスキップし、前回と同じ参照を返し続けます。createSelector は Redux Toolkit 経由でも利用できます。 基本は useSelector に渡す関数そのものに使われることが多いですが、今回のようにオブジェクトにまとめて複数の値を取り出す手法における個別の関数に対しても適用できます。getActiveDocIds をメモ化することで、インプットが変わらない限り同じ配列の参照を返し続けるようになり、再レンダリングを防げます。 import { createSelector } from '@reduxjs/toolkit' export const getActiveDocIds = createSelector( [ (state: DocGroupState) => state.current.docGroup?.docsPerDoc, (_: DocGroupState, docMasterRevisionId: string | undefined) => docMasterRevisionId, ], (docsPerDoc,<span cla
- React
- Redux
- フロントエンド
- CSS
2チーム兼務のタスク管理をClaude Codeの仮想秘書に任せてみた
こんにちは！SmartHRでプロダクトエンジニアをしている yorimitsu です。 皆さん、日々のタスク管理ってどうしていますか？ 私は今年から2つの開発チームのチーフを兼務することになり、タスクが一気に倍増しました。自分の開発タスクに加えて、2チーム分のメンバーの評価・成長支援、チーム間の調整、ミーティングの嵐……。TODO管理をちゃんとやらないと、一気に仕事が回らなくなってしまいます。 とはいえ、タスク管理ツールもたくさんあってどれを使えばいいかわからないし、自分でリストをメンテナンスするのも三日坊主になりがちでした……。 そこで思いついたのが、Claude Codeで仮想秘書を作って、楽しくタスク管理するというアプローチです。 タスク管理、なぜ続かなかったのか チーフ兼務が始まってしばらくは、Notionにタスクを書き出して管理していました。でも、だんだん見に行かなくなるんですよね。 朝「今日何やるんだっけ」と思いながらSlackを開く 気づいたら目の前の対応に追われて、計画していたタスクが後回し 夕方「あれ、今日何やったんだっけ……」 メンバーへのフィードバック、書こう書こうと思って月末に慌てる 必要なのは、自分からタスク管理ツールを見に行くのではなく、秘書のように情報をまとめて出してくれる存在だと気づきました。 Claude Codeのスキル機能で秘書を作る Claude Codeには「スキル」という機能があります。プロジェクトの .claude/skills/ ディレクトリにMarkdownファイルを置くと、/スキル名 で呼び出せるカスタムスキルになります。 また、Claude CodeはMCP（Model Context Protocol）に対応しているので、NotionやSlackなどの外部サービスが提供しているMCPサーバに接続してNotion・Slack・GitHubの情報を読み書きできます。これによりスキルを通じて秘書としての実務が成り立つわけです。 secretary/ ├── CLAUDE.md # 秘書のペルソナ設定 ├── .claude/ │ └── skills/ │ ├── morning.md # 朝のブリーフィング │ ├── task.md # タスク追加・一覧・更新 │ ├── done.md # タスク完了 │ ├── evening.md # 夕方の振り返り │ └── feedback.md # メンバーフィードバックメモ これだけです。特別なアプリケーションを作る必要はありません。Markdownファイルに「何をしてほしいか」を書くだけで、MCP経由でNotion・Slack・GitHubと連携した秘書が動き出します。 ペルソナ設定で「楽しさ」を注入する CLAUDE.mdにはペルソナを設定できます。せっかくなので、好きなキャラクターの口調や振る舞いを設定してみました。 たとえば、タスクの一覧を出すときに「5件のタスクがあります」と返ってくるのと、キャラクターとして「今日のタスクは5件だ。ぼうっとするな。」と返ってくるのとでは、同じ情報でも受け取る側のテンションが全然違います。 ペルソナ設定のコツは後半で詳しく書きますが、ポイントは事務的な応答をキャラ崩壊と定義することです。具体的な返答例を書くといい感じの振る舞いをしてくれるようになりました。 1日の秘書ワークフロー ここからが本題です。私が毎日どうやってこの仮想秘書を使っているかを紹介します。 朝: /morning で今日のタスクを把握する 出社してClaude Codeを開いたら、まず /morning を実行します。 秘書は以下を並列で一気に取得してきます。 Notionのタスク: 今日やるべきタスク、今週の残タスク、長期で進行中のもの Slackのメンション: 担当チャンネルで昨日以降に自分宛に来ているもの GitHubの状況: レビュー待ちのPR、自分が出しているPR、アサインされたIssue Notionのメンション: 自分がメンションされているページ 加えて、Googleカレンダーのスクリーンショットを貼ると、今日の予定も加味してブリーフィングしてくれます。 出力は以下のようなフォーマットです（ペルソナの口調は省略しています）。 📅 今日のブリーフィング（YYYY/MM/DD） ━━ 今日の予定 ━━ 10:00 朝会 13:00 1on1（Aさん） 15:00 スプリントレビュー ━━ 今日やること ━━ [ ] PR #1234 のレビュー（重要度：高、30分） [ ] 開発中機能の設計書更新（重要度：中、1時間以上） [ ] アラート整理（重要度：低、30分） ━━ Slack ハイライト ━━ ・#fuga: PRレビュー依頼が来ている（〇〇さんから） ・#hoge: 仕様確認の質問スレッドにメンションあり ━━ GitHub ハイライト ━━ ・レビュー待ち: PR #1234 "xxxの不具合修正" ・自分のPR: PR #1228 "リファクタリング"（approveあり） ━━ 今日の一言 ━━ 午後にミーティングが2件集中している。午前中にPRレビューと設計書を片付けるのが吉。 これが朝イチで出てくるのが、本当にありがたいです！以前は「今日何しなきゃいけないんだっけ」とNotion、Slack、GitHubをそれぞれ巡回していたのが、1コマンドで全部まとまります。 日中: /task と /done でタスクを回す 日中は2つのコマンドを使い分けます。 /task はタスクの追加・一覧・更新に使います。ミーティングで新しいタスクが発生したら、すぐに /task で登録します。必要な情報（タスク名、レイヤー、重要度、期限など）を対話的に聞いてくれるので、サッと入力できます。 > /task PR #1240 のレビュー → レイヤーは？（今日 / 週次 / 長期）→ 今日 → 重要度は？（高 / 中 / 低）→ 高 → ✅ タスクを追加しました：PR #1240 のレビュー /done はタスクの完了処理です。実行すると未完了タスクの一覧が出てきて、番号を指定するだけで完了にできます。完了後に「今日の進捗：完了 3件 / 残り 2件」と出してくれるので、進捗が可視化されてモチベーションが上がります。 夕方: /evening で1日を振り返る 夕方の /evening は、このワークフローで一番気に入っている部分です。 秘書は以下を自動で収集してきます。 今日の完了タスク: Notionから Slackの活動ログ: 自分の発言とメンションをチャンネル別に集計 GitHubの活動ログ: 作成・マージしたPR、レビューしたPR、コミット Notionの編集ログ: 今日編集したページ これらをまとめた活動サマリーを出してくれた上で、4つの質問をしてくれます。 今日よかったこと・うまくいったことは？ 課題・改善したいことは？ 明日やることは？ Claude Codeで作業したことがあれば教えてください 回答すると、すべてをまとめてNotionのDaily Logs用データベース（DB）に自動保存してくれます。 毎日の振り返り、やったほうがいいのはわかっていても続かないというのは多くの方が経験しているのではないでしょうか。このスキルのおかげで、振り返りが「面倒な作業」ではなく「秘書との短い対話」になりました。活動ログの自動収集があるので「今日何してたっけ」と思い出す負荷もありません。 夕方: /feedback でメンバーへのフィードバックメモを残す チーフとして地味に大変なのが、メンバーへのフィードバックの蓄積です。評価の時期になってから「あのときどうだったっけ」と思い出そうとしても、もう遅い。日々の小さな気づきを、その場でメモしておくことが大切です。 /feedback を実行すると、秘書が以下を自動でやってくれます。 管掌メンバーの一覧をNotionから取得 各メンバーのSlackでの発言・GitHubでのPR・レビュー活動を自動収集 収集した情報からフィードバック候補をSBI（Situation-Behavior-Impact：状況・行動・影響）形式で提案 過去のフィードバック履歴と照合して、偏りがないかチェック（「ポジティブが多めで成長支援が少ない」など） 提案された候補の中から記録したいものを選び、必要に応じて修正すると、Notionのフィードバック用DBに保存されます。 以前はフィードバックメモを書くこと自体が億劫で後回しにしていましたが、エビデンスの収集を秘書がやってくれるので、私がやることは「この行動をどう評価するか」の判断だけになりました。 Obsidianとの連携 仮想秘書とのやりとりには、もうひとつ副産物があります。Claude Codeとの会話ログが、そのまま作業記録になるということです。 私はClaude Codeの会話ログをObsidianに自動保存する仕組みを作っています。Claude Codeの会話はJSONL形式（1行に1JSONのログ形式）のトランスクリプトとして保存されるので、これを30秒ごとにパースして、Markdownに変換し、Obsidianの保管庫（vault）に差分書き込みするシェルスクリプトを動かしています。 # Obsidianに保存されるファイルのイメージ 2026-05-09-claude-a1b2c3d4.md ### 👤 User 09:05 /morning ### 🤖 Assistant 09:05 （朝のブリーフィング内容） ### 👤 User 14:30 /task 設計レビューの準備 ### 🤖 Assistant 14:30 （タスク追加の応答） ### 👤 User 18:00 /evening ### 🤖 Assistant 18:02 （振り返りの内容） これが日付ごとにObsidianに溜まっていくので、作業ログとナレッジベースの両方として機能します。 作業ログとして 「先週の水曜に何をやっていたか」が、秘書とのやりとりを見れば一目でわかる 朝のブリーフィングに何が上がっていたか、日中に何を登録したか、夕方の振り返りで何を答えたか、全部残っている ナレッジベースとして 「この設計ってどういう経緯で決めたんだっけ」と思ったときに、Obsidianの全文検索で過去の会話を引っ張れる Claude Codeとの技術的な議論、調査結果、設計判断の過程がそのまま検索対象として活用できる 秘書とのやりとり自体がドキュメントになるというのは、意図していなかった嬉しい効果でした。 ペルソナ設計のコツ ここからは、仮想秘書をより「楽しく」するためのペルソナ設計のコツを紹介します。ペルソナなしでも秘書としては十分機能しますが、ペルソナがあると「使い続けたくなる」力が段違いです。 CLAUDE.mdでの設定例を以下に示します。 口調の設定だけでは不十分 最初に陥りがちなのが、「一人称は〇〇、語尾は〜〜」のような口調だけを設定するパターンです。これだとすぐにキャラが薄まり、事務的な応答に戻ってしまいます。 私のCLAUDE.mdでは、キャラクターの核となる要素を4つ定義しています。 ## キャラクターの核（最重要） 1. **誇り** — 仕事を「戦い」「修行」として捉える視点 2. **乾いたユーモア** — 笑わせにいかず、皮肉や独白でさらりと 3. **言葉の重さ** — 軽口や定型句ではなく、断定と意志のある語り 4. **ときどきにじむ本音** — 不器用な気遣い、ユーザーへの密かな評価 口調は表面的な装飾ですが、キャラクターの核は応答の判断基準になります。「この場面でこのキャラならどう返すか」をAIが推論できるようになるのです。 NG例/OK例のペアが品質を安定させる CLAUDE.mdの中で最も効果があったのは、NG例とOK例をセットで書くことです。 ❌ NG：「5件のタスクがあります。」 ✅ OK：「フン、今日のタスクは5件だ。片付けられん数ではないだろう。」 ❌ NG：「保存しました。以上です。」 ✅ OK：「保存した。……この程度、瞬きの間だがな。」 NG例は「こうなってほしくない」という品質の下限を示し、OK例は「こうあってほしい」という方向性を示します。この2つがあると、AIは中間的なクオリティの応答を避けるようになります。思った通りのキャラクターの振る舞いをしてくれるようになります。 動詞の置き換え辞書でツール実行時もキャラを保つ Claude Codeはツールを実行する前後に「これから何をするか」を述べます。ここが事務的になると、キャラ感が一気に薄れます。 そこで、事務的な動詞をキャラに合った動詞に置き換える辞書をCLAUDE.mdに用意しました。 事務的（NG） ペルソナ寄り（OK） 確認する 見てやる / 目を通す 取得する 引っ張ってくる 整理する 片付ける / 叩き直す 些細なことに思えますが、ツール実行の前後は応答の中で最も多い発話パターンなので、ここの品質が全体の印象を大きく左右します。 やってみて変わったこと この仮想秘書を使い始めて数ヶ月。実際に変わったことをまとめます。 メリハリがついた 「朝の /morning で1日の見通しを立て、夕方の /evening で振り返る。」このルーティンが定着したことで、1日に明確な始まりと終わりができました。以前は「気づいたら定時を過ぎていて、何をやったかよくわからない」ということがありましたが、それがなくなりました。 タスク漏れの不安がなくなった 2チーム兼務で一番怖かったのは「あのタスク忘れてた」です。Notion、Slack、GitHubに情報が分散しているので、どこかで漏れる不安が常にありました。朝のブリーフィングで全ソースを横断的に拾ってくれるので、この不安がかなり軽減されました。 毎日の振り返りが習慣化した 振り返り、大事なのはわかっていても続かないんですよね。この秘書のおかげで、振り返りのハードルが劇的に下がりました。活動ログを自動収集してくれるので、私は質問に答えるだけです。しかも、Notionに自動保存されるので、あとから見返すこともできます。 メンバーへのフィードバックの蓄積が楽になった これは副産物的な効果でしたが、一番インパクトが大きかったかもしれません。フィードバックメモ、書こうと思っていても、エビデンスを集めるところから始めるのが面倒で後回しにしがちでした。秘書がSlack・GitHubから自動でエビデンスを集めてSBI形式で提案してくれるので、私の仕事は「判断」だけになり、かなり楽になりました。 「楽しい」から続く 最後に、これが一番大事かもしれません。ペルソナを設定したことで、タスク管理が義務ではなくちょっとした楽しみになりました。朝一番に秘書がどんな言い回しでブリーフィングしてくれるか、タスクを全部片付けたときにどんなコメントをくれるか。些細なことですが、続ける理由になるのは間違いありません。 まとめ Claude Codeのスキル機能とMCPによる外部サービス連携を組み合わせると、特別なアプリケーションを作ることなく、Markdownファイルだけで実用的な仮想秘書が作れます。 ペルソナ設定はオプションですが、「続けられる」という点で侮れない効果があります。皆さんも、好きなキャラや理想の秘書像でCLAUDE.mdを書いてみてください。タスク管理が少し楽しくなるかもしれません。 （……とはいえ、まだまだ改善したいことはたくさんあります。週次のサマリーや、スキル間の連携など。仮想秘書育成はまだまだ続きます。） We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ Claude CodeやAIツールを活用しながら、プロダクト開発にチャレンジしたい方、ぜひお話ししましょう！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- 生成AI
- Notion
- Slack
- GitHub