人工知能学会全国大会（第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
- 機械学習
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
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
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
「磨き上げる」ことから始まる基盤開発 —— マルチプロダクト戦略を支える従業員データ基盤
はじめまして。今年の 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
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
JaSST Tokyo 2026参加レポート
こんにちは。品質保証本部タレントマネジメントユニットのtoyoseaです。 2026年3月20日（金）に、東京ビッグサイトで開催されたJaSST Tokyo 2026にSmartHRのメンバーが参加および登壇しました！ 今年のJaSST Tokyoは、基調講演から事例セッションに至るまで生成AIをテーマにした発表が非常に多く、QAエンジニアの役割やテストプロセスがAIによってどう変わっていくのか、各社の試行錯誤が垣間見えるシンポジウムでした。 本記事では、その中でも特にSmartHRのQAメンバーの興味を引いたセッションを取り上げ、それぞれの概要と感想を紹介します。すべてのセッションをカバーすることはできませんが、雰囲気の一端でも伝われば幸いです。 SmartHRとしての登壇については過去のブログにてまとめてあります。 tech.smarthr.jp 印象に残ったセッションと各メンバーの感想 ここからは、SmartHRのQAメンバーが特に印象に残ったセッションについて、各セッションの概要と執筆者の所感に加え、参加した筆者以外のメンバーから寄せられた感想も紹介します。 本記事で取り上げきれなかったセッションも、それぞれ示唆に富む内容ばかりでしたので、興味を持たれた方はぜひ公式サイトで登壇資料をチェックしてみてください。 A2）曖昧な要求は仕様かバグか? ―AI時代の仕様とテストを考える freee株式会社の苅田 蓮さん・栗田 太郎さんによる企画セッションです。「要求・要件・仕様」という普段我々が当たり前に使っている言葉を、AIが仕様策定やテスト生成にも関わるようになった時代に改めて問い直す、というスタンスの発表でした。 自分たちの普段の業務でも、曖昧な要求に対してどう向き合っていくべきか悩む場面に直面することがあったので、印象に残りました。 SmartHRの他のQAメンバーの感想 要求・要件・仕様それぞれの言葉を使っているが、適切に定義して利用できていないかもしれない、という気付きがあった。 要求・仕様の厳密化を生成AIが担っていく未来において、どこまでの厳密さ（精度）のチューニングができれば任せられるようになるのだろうか。どこまでを任せるべきかの境界点についてみんなどう考えているかに興味をもった。 妥当性をどのように確認していくかが重要になっていく点については登壇者と同じ見解だった。 A3-2）AIがQAエンジニアの仕事を奪うのか？ 「チームみらい」の安野 貴博さんと、テクバンの豊田 悠太さん・長島 貴雄さんによるテクノロジーセッションです。「奪われる／奪われない」の二元論ではなく、AIインタビュアーの実例なども交えながら、QAエンジニアの役割がどう変化していくかを前向きに議論する内容でした。 QAエンジニアという職種の将来像を語るセッションは数多くありましたが、その中でも自分たちの業務に持ち帰れる示唆が多かったと感じました。 SmartHRの他のQAメンバーの感想 AIインタビュアーの取り組み面白かった。AIにインプットするための情報は、知識を言語化するところから始まるので、AIインタビュアーとの会話を通じて形式知にしていくのはやってみたい。品質保証の現場に限らず利用できそう。 ユーザー要求の理解やドメイン知識の部分の解像度をいかに上げられるか、なぜ作るか、何を作るかの情報の精度を高める重要性が高まったと感じた。 「QAエンジニアの仕事は無くなりはしないが変化していく」という点は納得感があり、特にAIの活用前提で役割や価値の出し方を再定義していく必要性を改めて感じました。 B3-1）欠陥分析（ODC分析）における生成AIの活用プロセスと実践事例 株式会社SHIFTの石井 優さん（CATエヴァンジェリスト）・山腰 直樹さん（Executive Test Specialist）・吉澤 麻由さん（Test Engineer）によるテクノロジーセッションです。ODC分析という欠陥分析手法において、最も工数を要する「分類」工程に生成AIを適用し、2週間かかっていた作業を1時間に短縮した実践事例が紹介されました。「人間の分類プロセスを仕様としてAIに渡す」というスタンスで、AIの曖昧さを許容する救済カテゴリの設計や、結果と理由をセットで出力させて自己整合チェックを行わせるといった、現場ならではの工夫が具体的に語られていた点が印象的でした。 不具合分析の課題はSmartHRのQAエンジニア間でも話題によくあがるテーマで、応用できそうな具体的な知見を持ち帰れる発表だと思いました。 SmartHRの他のQAメンバーの感想 自然言語の分析では、やはり文章の標準化が重要だと感じた。 不具合報告を分析する際、文章の質で分析の精度に差が生じる問題があった。 改善のための分析でも、コードレビューのための仕様理解でも、AIが読みにくい文章が足を引っ張る未来に危機感を覚えた。 曖昧さを許容するために救済用カテゴリを設定するのは自分の不具合分析でも取り込みたいと思った。 speakerdeck.com F3-1）あなたのシステムの壊し方 Ubie株式会社の末村 拓也さん（Software Engineer in Test）による公募セッションです。「ぶっ壊すのがテスターの本懐」という熱量で、UI操作・開発者ツール・データ・フォールトインジェクション・カオスエンジニアリングまで、システムを壊すための観点とテクニックを Knowns-Unknowns のフレームで体系的に整理した発表でした。「壊すことは何が起きるかを知ること」というメッセージを軸に、Known-Unknowns を Known-Knowns に変えていく実験としてテストを位置づける視点が印象に残りました。 AI関連のセッションが多い中で、テスト実行そのものの引き出しを増やしてくれる骨太な発表として位置づけられ、明日からの探索的テストに直接活かせるような内容だと感じました。 SmartHRの他のQAメンバーの感想 UIで壊すしかやってなかったなと思ったので、探索的テストの観点をアップデートしようと思いました。 様々な観点での壊し方が紹介されており、壊したい気持ちになりました！開発者ツールはまだ十分に使いこなせていないと感じたので、今後の改善余地があると認識しました。 壊すとは何が起きるかを知ること（名言ですね）。壊し方のTipsを聞いて、こういう観点を更新していきたいという気持ちになりました。 speakerdeck.com F3-3）バグ重篤度とテストサイズを用いたテストアプローチによるSaaS製品の信頼性とリリース速度の向上 freee株式会社の苅田 蓮さんによる事例セッションです。バグの重篤度に応じてテストケースを選定し、それをリグレッションテストとしてCIで自動実行する仕組みを構築したことで、テスト時間の効率化と品質の両立を実現したという実践報告でした。「何を守るべきかを論理的に整理する」というスタンスで、限られたリソースの中で守るべき品質を可視化していくアプローチが語られていました。 SmartHRもSaaSプロダクトを多数抱えており、いかに開発速度を落とさず品質を守るかは喫緊の課題です。重篤度・テストサイズという軸での整理はテスト戦略の策定時に参考にしたいと感じました。 SmartHRの他のQAメンバーの感想 とても良い題材で、バグの重篤度によってテストケースを選定し、選定したテストケースをリグレッションテストとしてCIで自動で実行する仕組みによってテストの時間の効率化と品質の向上に繋がったという発表でした。 バグの重篤度は現状取り入れてないので今後活用シーンを整えて取り入れてみたい。テストサイズは手動テストの最適化にも使えそう。 何を守るべきかを論理的に整理し、より少ないリソースで品質を担保していく取り組みは、AIで開発スピードが上がっている中でリリース速度を落とさないために有用な手段かと思いました。ぜひ取り入れてみたい。 感想 本記事では取り上げきれなかったセッションも含め、全体として昨今のAI開発における潮流に沿った形のセッションが多く、興味深い内容ばかりでした。革新的な発表内容というよりかはアプローチ方法を模索している最中の取り組みも多く、自社でも参考になりそうなセッションが多かったです。またAIをより使っていくにあたりコンテキストの整理が大事になってくるとは思うので、QAエンジニアとして何をしていくべきかについても考えさせられました。 特に「A3-2）AIがQAエンジニアの仕事を奪うのか？」で述べられていた「QAエンジニアの仕事は無くなりはしないが変化していく」というのはまさにその通りだと思っており、1年後のJaSST Tokyoではまた違ったQAエンジニアのAI活用のアプローチが出てくるのではないかと思っています。 We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ youtrust.jp open.talentio.com
- QA
- 生成AI
- テスト戦略
最初の30日で何ができる？ SmartHRに飛び込んだQAエンジニアのオンボーディング記録
はじめまして！ 2026年3月からSmartHRに入社したasherです。 私は品質保証本部の勤怠管理・給与計算ユニットに配属され、勤怠管理機能のQAエンジニアとして働いています。 この記事では私が入社してから30日間でQAエンジニアとして「仕事が回り始める状態」を作るためにやったことをまとめています。 Day 1–5：まず「仕事が始められる状態」を作る 入社して最初の一週間はとにかくオンボーディングタスクをこなしていました。 SmartHRのオンボーディングタスクには、「全新入社員向け」「所属するQA組織向け」「担当プロダクト向け」の3種類があり、ボリュームがそれなりにあります。最初は「全部終わるかな……」と不安もありましたが、想像以上にオンボーディングの研修とタスクリストが整っていて、いつまでに何をしておくべきかが明確だったため、環境構築や各種申請をスムーズに進められました。 最初の2〜3日はツール申請や環境構築を行い、後半は自分に関係するドキュメントを読み込んで、部署のことや開発フローの理解に努めました。 基本はフルリモートのため、コミュニケーション面で詰まらないか不安もありましたが、メンターの方が毎日1on1を設定してくださり、その場で困りごとを解消できました。結果として、問題なくあっという間に最初の1週間が過ぎていきました。 この週で気づいたこと Notionで、自分の「今日やったこと／明日やること／困っていること」をまとめるDaily logデータベースを作成し、オンボーディングチャンネルで毎日共有していました。周囲から取り組みが見えやすくなり、透明性の担保に役立ちました。 Day 6–10：チームの開発フローと関係者を把握する 入社2週間目は、残りのオンボーディングタスクを進めつつ、スクラムイベントへの参加と関係者との顔合わせを行っていました。重複しているタスクや、時間が経って不要になっているタスクもあったので、テンプレートを更新し、次回のオンボーディング時に最新の情報になるよう整備も進めました。 自分のチームはScrum@Scaleというフレームワークを採用しています。通常のスクラム開発は経験がありましたが、Scrum@Scaleは初めてでした。スクラムイベントに参加しながら全体像を掴み、関係者の方々とは顔合わせミーティングや1on1を設定して、役割分担や動き方を把握していきました。 SmartHRにおけるScrum@Scaleの取り組みについては、SmartHRのアジャイルコーチであるwassanさんによる発表スライドをご覧ください。 speakerdeck.com この週で気づいたこと Notion AIが使えるので、ミーティングで出てきた社内用語やツール申請方法はNotion AIに聞き、過去のSlack情報やNotion記事を辿ってすぐに解決していました。 期日が明記されているオンボーディングタスクは、Google Calendarのマイタスクに登録して必ずリマインドされるようにしていました。 いち早く自分を知ってもらうため、timesチャンネル（日報や雑談を投稿するSlackチャンネル）を作成し、自己紹介のタイミングで宣伝しました。興味を持ってくれた方が参加してくださり、少しずつネットワークが広がっていくのを体感できました。 Day 11–15：個人ミッションを考えつつ、AIツールの環境構築 入社して1か月以内に今期のミッションを考える必要があったため、担当プロダクトの現状を把握しつつ、課題を見極めながらミッションを検討していました。評価制度が整っているので、数カ月後に「今のチームでどんなことを成し遂げられていると良いか」をイメージしながら、ミッションのたたき台を作成しました。同時並行でツールの権限付与が進む時期でもあったので、Claude CodeやCursorを使えるよう、環境設定も進めていました。この週には品質保証本部でJaSST Tokyo 2026への参加を予定しており、多くのQAエンジニアとオフラインで顔合わせができました。 JaSST Tokyo 2026については、テックブログの登壇レポート記事もご覧ください。 tech.smarthr.jp この週で気づいたこと QAエンジニアには申請ごとにClaude Codeの権限が付与されるため、入社後すぐに申請していて良かったです。申請できるタイミングも月初の限られた期間なので、遅れていたら利用開始までにタイムロスが発生していたと思います。 Day 16–20：個人ミッションを確定させ、Scrumの改善タスクを取ってみる 4週目には個人ミッションを確定させたかったので、たたき台を作り、上長と認識をすり合わせて合意を得ました。ここまでにチームのレトロスペクティブへ参加し、品質保証本部の課題感や今後取り組みたいテーマを把握できていたため、それらと自分が伸ばしたいスキルが重なるミッションを選びました。ミッションが決まったので、さっそくチームに貢献できることはないかと考え、レトロスペクティブで起票されていたTryを1つ実行しました。内容は「非同期でPRDレビューを行うフェーズを、リファインメント前に組み込む」というものです。実施したところ、エンジニアも含めてチーム全体で進められ、プロセスが統一されて良かったという声をもらいました。 この週で気づいたこと 個人ミッションの策定にはAIツールをフル活用しました。社内ドキュメントからミッション事例を集め、自分のスキル・経験と照らし合わせながら壁打ちして決めていきました。NotebookLMでコンテキストを読み込ませ、Geminiと連携して検討すると、精度の高い回答が得られました。 レトロスペクティブの課題改善がちょうど良いタスクのボリュームで、すぐにチームに貢献できるので良いアプローチでした。 Day 21–25：個人ミッションを進める 5週目は、すでに個人ミッションが決まっていたので実行フェーズに入りました。ミッションは「ポストモーテム運用フローの改善」と「品質ダッシュボードの作成」だったため、まずは現場の課題感が強そうなポストモーテム改善から着手しました。関係するエンジニア／PMにアンケートを取り、課題を言語化しつつ、実態（何が起きているか）を探りました。その結果、「インシデントが起きてもポストモーテムが実施されないケースがある」こと、そして原因が「実施基準が曖昧で、強制力がない」ことだと分かりました。そこで、基準を揃えるドキュメントを作成し、「インシデント発生時は必ずポストモーテムを実施する」方針を、チーム全体が集まるオーバーオールデイリースクラムの場で共有して合意を得ました。 アンケートでは「ポストモーテムの実施基準が曖昧」「振り返りが属人化している」といった課題が多く挙がりました。以下はその集計結果です。 ポストモーテム運用に関するアンケート結果 この週で気づいたこと Notionのアンケートフォーム機能を使うと、アンケート結果のDBを簡単に作れて、グラフ化もすぐできるので、全体に結果を共有するときに便利でした。 Day 26–30：合意形成から運用開始まで持っていく 新しいポストモーテム運用フローについてチーム全体の合意が取れたので、運用マニュアルを更新し、この週から新フローへ切り替えました。ここ1〜2週間で小さなインシデントがいくつか発生していたため、それらを対象に新しいポストモーテムを実施してもらうよう各担当エンジニアへ声をかけ、テンプレートを使って書き始めてもらいました。 この週で気づいたこと 「アンケートで課題定義 → 他プロダクト／社内方針の調査 → 改善案の提案 → チーム全体の場で合意 → 運用開始」という流れで進めたことで、最短でプロセスをアップデートできました。 各フェーズでアンケート結果や合意形成の議事録を必ずNotionに残し、後から「どんな経緯で今の運用になったのか」を振り返れるようにしました。 おわりに 30日のオンボーディングを終えて、SmartHRでバリューを発揮するための仕事の進め方が自分なりに掴めてきました。 光の速さで行動に移す 弊社には「光:まずやってみる人がかっこいい」というバリューがあり、すぐに行動へ移すことが推奨されています。「キョカシャザ」という社内用語もありますが、これは「無責任に動く」という意味ではなく、「影響範囲が限定的で、リスクの低い改善については、都度許可を待つより、まず試して、問題があればその時に調整する」というスタンスです。もちろん、本番環境への変更や影響範囲の大きな施策は慎重に判断していますが、チーム内の小さな改善レベルでは、この「まず試す」文化がスピード感を生んでいます。 AIツールをフル活用 とにかく疑問が出たらAIに聞く。入社して間もなく右も左も分からない状態だったので、常にNotion AIとGeminiを立ち上げ、ミーティング中に分からない言葉が出たらその場でAIに聞いて理解するよう努めました。自分が取り組む課題の解決方法や過去事例をSlack／Notionから拾える点もとても参考になりました。 アウトプットドリブン 社内にはフィードバック文化があるので、やりたいことを実現するために、方針や提案のたたき台を最速で作り、上長や関係者にレビューしてもらいながらブラッシュアップしていきました。最初から完璧を目指さず、フィードバックをもらいながらチームで良いものを作っていく、という方針を理解できました。 We Are Hiring! この記事を読んでSmartHRの文化に興味を持っていただけた方へ。 SmartHRのQA組織では、プロダクト開発の変化に合わせて、品質保証のやり方そのものもアップデートし続けています。仕組みづくりや改善を前に進めながら、チームやプロダクトの成長に向き合う仲間を大募集中です！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ youtrust.jp open.talentio.com
- QA
- オンボーディング
- 生成AI
- アジャイル
Product Management Summit 登壇レポート —— 他講演との接点から見えた、AI時代のプロダクトマネジメントの論点
こんにちは。技術統括本部でアジャイルコーチをしている shooen です。AI時代の開発生産性向上をテーマに、意思決定と学習のプロセス設計に取り組んでいます。 2026年4月28日に、東京・丸の内で開催された「Product Management Summit」に登壇しました！ この記事では、登壇内容と、当日聴いた他講演との接点について書きます。 Product Management Summit とは Product Management Summit は、ファインディ株式会社主催のプロダクトマネジメント領域のカンファレンスです。「AI時代に、顧客価値を継続的に生み続けるプロダクトマネジメントとは何か」をテーマに、Marty Cagan 氏のキーノートをはじめ、海外・国内のPM／プロダクトリーダーが多数登壇しました。 product-management-summit.findy-tools.io 自身の登壇：「速く作れるかではなく、速く学べるか」 私が登壇したのは10分のLT枠で、SmartHR内で進めている「リリース後の学習ループ」を回すパイロットの「途中報告」をしました。きっかけは、リリースは順調にできるが、その後「効いたのか？」を問う仕組みがない、という社内の課題です。そこで、週次の場である「Learningレビュー」と、記録の型である「Decision Log」の2つを「軽量な型」としてプロジェクトに追加し、観測→判断更新のサイクルがチームで回るかを試しています。 パイロットがまだ続いていることを前提に、途中で見えていることと、まだ分かっていないことを正直にお話ししました。 見えてきたのは、型が最初に効いたのは狙っていた「リリース後」ではなく、「企画からリリースまでの過程」だったこと。一方で、リリース後の検証はまだこれからで、当初の仮説の検証自体は手つかずです。 speakerdeck.com 他講演との接点 登壇者として参加して何より興味深かったのは、自分の問題提起が当日の他講演とどう交わっているかでした。3つだけ紹介します。 Marty Cagan 氏「AIが"作る"を民主化する時代、PdMは何で価値を出すのか」 Cagan 氏は、生成AIで Delivery のコストが大幅に下がった結果、プロダクトづくりのボトルネックは「問題選択」と「解の発見」、つまり Strategy と Discovery へと移った、と整理しました。 私が登壇で出した「作る速さではなく、学ぶ速さがボトルネックになる」という問題提起と、重なる問題意識を感じました。ただし Cagan 氏は PdM 個人の Product Sense（顧客・データ・ビジネスへの理解）、自分はチーム単位の意思決定プロセスと、扱うレイヤーは違います。同じ問題意識を別の角度から取り扱っている話として、自分の整理を見直すきっかけになりました。 Alexander Lovell 氏「元BigQueryプロダクト責任者が語る AI時代の体験設計を事業価値に繋げるには」 Lovell 氏は、AIによってプロダクトの定義が壊れ、その中身は「機能」から「成果契約（outcome contract）」へと置き換わった、と整理しました。何を作るかではなく、どんな成果に責任を持つかを事前に定義する、という捉え方です。 この「成果契約」という整理は、自分が登壇で話した「リリース後に何を観測するかをリリース前に決める」という主張と重なる部分があり、Decision Log を「成果に対して事前に契約を結ぶ仕組み」として捉え直す視点をもらいました。 及川 卓也 氏 × 吉羽 龍太郎 氏「AI時代にプロダクトマネージャーは必要か」 最終セッションでは、AIで作れる量が増えたことで「ビルドトラップ」（作ること自体が目的化してしまう罠）が現場で深刻化している、という観察が共有されました。「何を作らないか」「アウトプットからアウトカムへ」といった現場のリアルが語られました。 これもまた、自分が登壇で出した「速く作れるかではなく、速く学べるか」という問題提起と重なる課題意識を持った議論でした。理論寄りの講演から現場の議論まで、似た方向の話が複数出ていたことは、自分の試みの位置づけを考え直す手がかりになりました。 感想 10分という短い時間で、結論の出ていない「途中報告」をすることには、難しさもありました。それでも、進行中の試行錯誤を共有することにも価値があると考え、このスタイルで臨みました。 他講演を聴いて、自分が取り組んでいる領域が、他のPMやプロダクトリーダーの関心とも重なる部分があることが分かりました。一方で、まだ自分が言語化しきれていない論点にも多く気づくことができました。パイロットの次の一手や、社内・社外への発信に活かしていきたいです。 We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ 意思決定や学習のプロセス設計、AI時代の開発組織のあり方に興味がある方とお話しできたら嬉しいです。 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- 生成AI
- プロダクトマネジメント
- アジャイル
AI エージェントをチームで導入していくまでの道のり
プロダクトエンジニアの charo です。 Cursor や Claude Code など AI エージェントブームによる開発が世間で話題になって1年ほど経ちました。 この1年間「AI ってどう使えばいいの？」から始まり、現在では AI エージェントを起点に業務を行えるようになってきた、そんな軌跡を残しておきます。 想定読者は、チームに AI エージェントを広げたいエンジニアリングマネージャーやテックリード、あるいは同じ課題感を持つチームメンバーです。完璧な導入プロセスの解説ではなく、試行錯誤の記録として読んでいただければ幸いです。 背景 AI エージェントを個人で使うだけでも、生産性は確かに上がります。しかし、私たちはチームでプロダクト開発を行っています。 チーム開発の現場では次の問題が発生します。 個人最適はスケールしない AI の活用に習熟した人だけが速く、慣れていない人は従来どおり。結果としてチームの出力は底上げされない コンテキスト投入が属人化する 同じ作業を頼んでも、誰が書いた指示かで結果がブレる ツール乱立で学習・運用コストが爆発する 個々人が別のツール・別のルールで動くと、チームで一貫性がなくなる 私たちのチームで扱っている労務領域はドメインが複雑で、品質要件もある領域です。「速く書ける」だけでは済まず、速く書きながら品質を崩さない、という状態を仕組みで担保する必要があります。 この課題感を出発点に、1年間かけてチームで試してきた施策の流れが次の図です。 --- title: AI エージェントをチームに広げた1年の施策 --- timeline 2025年前半 : AI 縛り週間 2025年後半 : AI のツラミ・知見共有会 2026年現在 : Skills 勉強会 : モブ作業 2025年前半 この時期は Cursor や Windsurf が台頭してきていました。 VS Code から AI エージェント機能が付加された IDE が注目され、Vibe Coding（AI に感覚的に指示しながらコードを書き進めるスタイル）が一気に広まったタイミングです。私たちも Cursor や Windsurf を導入し、既存のプロダクトにどこまで通用するのか検証しながら業務で利用していました。 チームで利用していくために以下の施策を行いました。 AI 縛り週間 この段階では、まだ世間でもルールの整備を行い、うまいプロンプト方法でタスクをこなしてもらう手法が主流でした。 この状態だと、メンバー間で AI への慣れや理解にバラつきが発生しました。そこで AI がどこまでできるのかをチームで体験しようと考えました。 やったこと 期間限定で「できるだけ AI 駆動で開発する」というルールで1週間運用 事前準備週 → 本番週の2段構えにして、慣らしと本番を分けた 毎日の気づき・詰まり・工夫を Slack の専用スレッドに流す運用 よかったこと 全員が一度は詰まる体験によって、議論の土台ができた その後の打ち手（ルール整備・共有会）の必然性がはっきり見えた AI で扱える作業のラインがつかめた 失敗したこと 使い方の共有はされたが、結局はプロンプトによって品質の差が生まれた 2025年後半 プロンプトによって品質の差が生まれるという AI 縛り週間の反省を受け、次の半年は個人の知見をチームに広げる取り組みへ舵を切りました。 この頃には様々なサービスが MCP（Model Context Protocol。AI エージェントに外部ツールやデータを接続する標準プロトコル）の提供を開始し、Cursor や Windsurf に限らず Devin のような自律型 AI エージェントや CLI の Claude Code が普及しはじめ、AI エージェントのあり方も多種多様になってきていました。 また Agent Skills（タスクごとに AI エージェントへ渡す再利用可能な手順書）など標準化の動きもあり、AI エージェントを期待通りに使えるようにする仕組みも揃ってきていました。 一方でチームとしては、前回の AI 縛りから比較するとルールや Commands の整備を進めているが、プロンプトを手動で書き AI に作業させる程度にとどまっていました。 まだ個人差が大きい状態が続いていたので、別の形で施策を行いました。 AI のツラミ・知見共有会 AI を使っていく上で、個人で感じていることを書きだしてもらうことを考えました。 この頃になると、ツールのアップデート頻度も上がってきていたので、キャッチアップが困難になり始めていました。 やったこと ツライと思ったこと、うまくできたことをシェアする Cursor や Claude Code などのツールのアップデート情報をシェアする よかったこと アジェンダを失敗ドリブンにしたことで、成功談より学びが溜まりやすくなった スキル格差のあるメンバー同士で、前提の擦り合わせができた 失敗したこと AI エージェント全体の仕組みについての理解度が人によってばらつきがあるため、知見だけの共有では体系立てて学べていない この時期には Skills や Hooks（AI エージェントのイベントに応じてスクリプトを差し込める仕組み）など機能がリリースされており、それらをまだチームとしてフル活用できていない状況でした。 2026年現在 知見共有だけでは体系立てて学べないという反省を踏まえ、2026年に入ってからは Skills や Hooks のように AI エージェントの仕組み自体に踏み込む取り組みへ軸を移しました。 現在の AI エージェントでは Harness Engineering（AI エージェントが安全かつ再現性高く動ける"足場"をコードベースやワークフローに組み込む考え方）という言葉がスタンダードになっています。 正直まだチームもそうですし、リポジトリに Harness の仕組みを取り入れられていないのが現状です。 いきなり仕組みを入れることも可能ですが、まずは Skills や Hooks などの機能についての理解がないと Harness を作り上げ運用するのは難しいです。 そこで取り組みやすそうな Skills の作成方法からチームで勉強会を行いました。 Skills 勉強会 Skills は一度自分で作るのが手っ取り早いので、事前にどんなことを AI エージェントにさせると良さそうか考えてきてもらった上で勉強会を開催しました。 やったこと Agent Skills をベースに Skills とはどんなものか概要を理解する Claude Code 公式プラグインにある /skill-creator（対話形式で Skill ファイルを生成してくれるコマンド）を使って実際に作るデモを行う よかったこと どのように Skills を作っていけば良さそうかのイメージをつかめた アイディアを出してもらうことで、コーディング以外の業務にも AI エージェントを使うイメージがついた 失敗したこと Skills を上手く作るためのノウハウは溜まっていない 他の Hooks や Agents については触れられなかった 実際に Skills を作ると、「ああ、AI エージェントはこういう使い方もできるのか」という気づきが次々と出てきました。体系的な理解というより、手を動かすことで輪郭が見えてくる感覚に近いです。 モブ作業での実施 Skills の作り方を学んでもノウハウが溜まらなかった反省から、次は「作るところを一緒に見る」方向に切り替えました。ここまで知見をいかに広めるかのアプローチで進めてきましたが、業務においてどんな設定でどんな指示をし、作業を進めているかは実際に見ないと分からず、個人差が埋まらないと感じていました。 別のチームでモブでの作業が良いとのことで、早速取り入れました。 やったこと 2人一組で作業を行う 1人が画面共有し、1つの Claude Code セッションに対して2人で指示して取り組む よかったこと AI エージェントに対してどのように指示をすると良いか、タスクを通じて学べる レスポンスを待っている間に、議論を深められる 失敗したこと チームの作業効率が一時的に下がる 知見のスケールが限られる 結果、チームでは AI 駆動での業務が全員できるようになってきました。また AI 疲れも、レスポンスを待っている間に雑談もしながら進めることで多少軽減できていると思います。 作業効率においては、チームの習熟度が上がっていけば特に問題ないはずです。 また、チームとして足りていない仕組みなどは別途学習していく必要はあります。 まとめ AI 縛り週間、知見共有会、Skills 勉強会、モブ作業。どれも完璧な施策ではなく、そのたびに新しい課題が見えてきました。それでも一つひとつの成功と失敗を積み重ねた結果、チーム全員が AI 駆動で業務を進められる今があります。 冒頭で挙げた3つの課題について、現時点の手応えを書き残しておきます。 個人最適はスケールしない：モブ作業で大きく改善。AI エージェントへの指示の勘所をチームで共有できるようになった コンテキスト投入の属人化：まだ道半ば。今後は Skills で指示の再利用性を高めて収束させたい ツール乱立：Claude Code を中心に据える方針で一定の収束が見えてきた AI エージェントの進化はこれからも続きます。Hooks でレビューや CI 連携の自動化を進めたり、Agents を業務フローに組み込んだり、最終的にはリポジトリを Harness Engineering の発想で組み直したり。どれもまだ手つかずの領域です。これからもチームで試行錯誤を重ね、AI 駆動を当たり前にする取り組みを続けていきます。 同じように「個人では使えるけど、チームではうまく広がらない」と感じている方の参考になれば嬉しいです。 We are Hiring! SmartHR では、一緒に働く仲間を募集しています。興味がある方は、ぜひ/hello-worldをご覧ください。 hello-world.smarthr.co.jp
- 生成AI
- プロダクトエンジニアリング
「開発組織を左右するAIの活かし方｜アウトカムを最大化する育成×仕組み化とは」に登壇しました！
こんにちは。保険事業チームの murano です。 2026年4月23日にオンラインで開催された「開発組織を左右するAIの活かし方｜アウトカムを最大化する育成×仕組み化とは」に登壇しました！ この記事では、イベントの模様と登壇内容をレポートします。 イベント概要 「開発組織を左右するAIの活かし方｜アウトカムを最大化する育成×仕組み化とは」は、活用度合いの属人化によるスキル格差や、コンテキスト不足による生成コードの品質のばらつき、そしてそれに伴うレビュー負荷の増大といった「組織・プロセス」の課題解決を目的に、AI浸透後の開発組織において、特定の個人のスキルに依存せず、組織全体で成果を出し続けるための「育成」と「仕組み化」の実践知について話すイベントです。 開発組織を左右するAIの活かし方｜アウトカムを最大化する育成×仕組み化とは 登壇内容 私は普段プロダクトエンジニアとして、保険領域プロダクトの「働くあなたのマネーポータル」を開発しています。 昨年8月にAIネイティブ開発という枠組みで、開発プロセス全体で本格的にAIを利用し始めました。そこから課題を発見し、その対応として読書会を実施し、AIルールに関する仕組み化を行いました。その一連の流れと詳細について発表しました。 当日は150人以上が参加し、コメントや質問も活発に挙がり、盛況でした。 speakerdeck.com 感想 平日の昼の時間帯にもかかわらず多くの参加者がいて、AIへの関心が高いことを感じました。 他の登壇者の発表は、具体的な事例が多く参考になりました。AI活用のノウハウがSNSやブログで溢れている今でも、実際に試行錯誤した経験とそのコンテキストには代えがたい価値があると改めて感じました。 今後も実践したことや学びをテックブログを通じて発信していきます。 We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ AIを活用した組織づくりや開発に興味がある方、私たちと一緒に新しい仕組みや価値を試行錯誤しながら作っていきませんか？ご応募お待ちしています！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- 生成AI
- 開発プロセス