© LayerX Inc. PdM業務における使い分け バクラク事業部 プロダクト企画部 中野 真史郎 NAKANO, Shinshiro DAY01 topic ツールの選択 Speaker 

© LayerX Inc. Speaker              2016年4⽉-2018年12⽉： 株式会社DONUTS：ジョブカン労務HR/給与計算のPdM 2019年1⽉-2022年9⽉： 株式会社リクルート：Airレジ/AirインボイスのPdM 2022年10⽉-2024年4⽉： 株式会社ソラジマ：なんでも屋 2024年5⽉〜： 株式会社LayerX：バクラク勤怠のPdM 中野 真史郎 NAKANO, Shinshiro プロダクトマネージャー @u2qshinshiro 

© LayerX Inc. 要望管理：前提となる社内の運⽤ 要望管理 Slack要望 スタンプ反応 要望DB Slack投稿+スタンプで⾃動でNotionの要望DBに格納 要望DBと別でプロダクトバックログのDBもあり、 要望数や温度感など把握して、優先順位付けや課題把握に活⽤ プロダクトバックログDB 

© LayerX Inc. 要望管理の課題 要望管理 ⽇々送られてくる要望の数が多く 、紐付け作業が⼤変 プロダクトバックログも細かく全てを覚えてはいない 

© LayerX Inc. 要望管理のAI活⽤ 要望管理 Cursor×Claude Sonnet 4 どのバックログに紐づくかを確度と合わせて⾃動提案 要望のマッピング作業を⼤幅効率化 ⽇々の10件以上の要望処理が容易に 要望テキストを⼊⼒するだけで、AIが既存バックログとの類似性を分析し、最適な紐付け先を提案 

© LayerX Inc. 要望管理 

© LayerX Inc. あなたは、勤怠管理に詳しい⼀流のプロダクトマネージャーです。 @プロダクトバックログ.md というバックログがあります。 要望がどのバックログに紐づくか、以下の形式に基づいて @紐付け提案.md を更新してください。すでに何か記⼊されてい れば削除して上書き更新して。 # タスク ユーザー要望がどのプロダクトバックログに紐づくか、以下の形式に基づいて回答してください。 候補が複数ある場合は「紐づく可能性のあるバックログ」欄に確度が⾼い順ですべて列挙してください（上限5件）。 また、ユーザーからの⼀⾒シンプルな要望の中に潜む業務上の背景や真のニーズ、現場特有の前提条件を丁寧に読み解いて ください。 # 添付ファイルに関する重要指⽰ - **IDと機能名の完全⼀致**: バックログのID（例: `ATND-XXXX`）と「機能名」は、 @プロダクトバックログ.md に記載 されている組み合わせと完全に⼀致させてください。 - **実在するIDのみ使⽤**: 紐付けるバックログのIDは、必ず @プロダクトバックログ.md に存在するものを記載してくだ さい。 - **照合する情報**: 要望内容と、 @プロダクトバックログ.md の「機能名」「要求」「備考」の記載内容を照合し、意味 的に最も関連性が⾼いバックログを選定してください。 # ⼊⼒形式 -要望ID 要望企業：優先度：要望内容：背景 -要望ID 要望企業：優先度：要望内容：背景 -要望ID 要望企業：優先度：要望内容：背景 ※連続で複数渡す可能性がありますが、〜様というのが要望企業になるのでそこで区切りを確認してください。 # 出⼒形式 | 要望ID | 要望 | テナント名 | 紐づく可能性のあるバックログ (確度順‧複数可) | 確度 (%) | 想定される業務背景 | |------|------|------------|--------------------------------------------------|----------|--------------------| - 複数候補がある場合は、セル内で改⾏して「ID 機能名」の形で列挙してください。 - 候補がない場合は 🆕 から始めてユーザーストーリー形式で新規機能名を記述してください。 できる限り既存のバックログに紐づけたいので、新 規作成する前に本当に既存の候補がないかを考えて提案してください。1カラムの中で複数⾏になる場合は/を追加してください # 想定される想定される業務背景と裏のニーズについて - ユーザーの要望を受けて、その背後にある業務課題‧背景‧ニーズ‧運⽤上の前提を推測‧⾔語化してください。 - 可能であれば、類似業務や業界の慣習からも補⾜してください。 ## ⼊⼒例： 1868 株式会社LayerX様：中：法定休⽇の⾃動判定をしてほしい（主に流動的なシフトを組まれるアルバイトの⽅向け） ## 出⼒例： | 要望ID | 要望 | テナント名 | 紐づく可能性のあるバックログ (確度順‧複数可) | 確度 (%) | 想定される業務背景 | |------|------|------------|---------------------------------------------|----------|--------------------| | 1868 | 法定休⽇の⾃動判定をしてほしい | 株式会社LayerX | ATND-533 法定休⽇⾃動設定/ATND-1915 シフト制で、所定休⽇も法定休⽇も決まって ないので、実績以外全て休⽇にしたい | 90/60 | • シフトが週ごと‧⽇ごとに変動し、各従業員の休⽇が固定されていないため「週１回以上の法定休 ⽇」を⼈⼿で判断している
• 休⽇判定ミスがあると ①違法な⻑時間労働 ②法定休⽇労働の割増賃⾦計算漏れ ③36協定違反 が発⽣しやすい
• 労務担当者‧店舗（現場）マネージャー双⽅が同じ勤怠システムを使っており、締め作業の直前に休⽇設定を修正するケースが多い
• ア ルバイト⽐率が⾼く、シフト希望提出〜確定までのリードタイムが短い（週次や前⽇確定もある）
• 「⽉〇回まで休⽇出勤可」「週次で法定休 ⽇を変動させたい」など、店舗ごとに独⾃ルールが存在する | --- 要望管理 実際のCursorルール。 普段使っているフォーマットに合わせ、実際のインプット‧アウトプット例をルールに組み込むのが⼤事 

© LayerX Inc. 要件定義書作成 要件定義書 ざっくり⾃分で要件を記載 ドメインの知識と既存仕様に⼀番詳しいのはAIより⾃分であり、少なからず盛り込んで欲しい要件がある筈 なので、完全にゼロベースより書いた⽅が精度が⾼い 初期要件 Cursor 完成仕様書 Cursorで考慮漏れがないか既存の実装や仕様書も⾒ながら ⾁付けしてもらう 手直し 

© LayerX Inc. 補⾜：Cursorで「仕様書」「ヘルプページ」「ソースコード」などを 参照できるように、エンジニアの⽅が⼟台を作成してくれている 補⾜：Cursor活⽤の前提 エンジニアの⼯夫で実現する、ビジネス組織のCursor活⽤環境の構築術 

© LayerX Inc. 間違えていることもあるので、鵜呑みにせずに必ず⼀次情報を確認して検証する 競合調査 競合調査 DeepResearchを使い、⽐較したい軸で表形式でまとめてもらう        GPT ＞  Gemini ＞   Perplexity 結構複数⾛らせて取捨選択することも多いが、DeepResearchについての個⼈的な感覚は 

© LayerX Inc. デザイン（ワイヤーフレーム作成） デザイン Figma Make：以前はv0を利⽤していたが既存のデザインファイ ルを読み込ませる事ができ、再現度が⽐較的⾼いのが優秀 仕様書の要求‧要件を渡して、デザインの叩き台に活⽤ 

© LayerX Inc. デザイン デザインで違和感を覚えた時に、案出しをしてもらう。複数案出してもらうのがおすすめ デザイン（案出し‧ブラッシュアップ） 

© LayerX Inc. データ分析 SQL作成のAI活⽤  Cursor×Claude Sonnet 4を活⽤したクエリ⽣成 クエリ⽣成ルールを設定することで： やりたいことを⾃然⾔語で伝えるだけで⼀発で綺麗なクエリ⽣成体感80%以上は修正不要で即利⽤可能 ＜クエリ⽣成時のルール＞ ‧データベースのスキーマ情報を与える（どこに何があるか） ‧本番とデータウェアハウスで違いがあるので変換ルールに組み込む ‧Snowflake特有のクエリ⽣成注意点などルールに追記 

© LayerX Inc. # バクラクのSnowflakeクエリ⽣成ルール ## 概要 このルールは、バクラク（⽇本のマルチテナントSaaS）のプロダクトマネージャーが⾃然⾔語を使ってSnowflakeクエリを ⽣成するためのものです。既存コードに影響を与えることなく、データ分析を効率化します。 ## 基本情報 - **対象製品**: バクラクの各プロダクト（勤怠、申請、経理など）、バクラク共通管理 - **ユーザー**: Snowflakeを利⽤するバクラクのプロダクトマネージャー - **⽬的**: ⾃然⾔語からSnowflakeクエリを⽣成する ## 関連ルールファイル プロダクト固有のSnowflakeルールについては、以下のファイルを参照してください： - **バクラク勤怠**: `.cursor/rules/shared-bakuraku-snowflake-sql-kintai.mdc` ## データベーススキーマ参照先（共通） - **バクラク共通管理**: `./code/docs/db` 配下のマークダウンファイル - **Salesforce (SF)**: `./schema/snowflake/models/default/src/salesforce` 配下にテーブルごとにディレクトリがあ り、その中の `schema.yml` ## テーブル命名規則（共通） MySQLのテーブル名からSnowflakeのテーブル名への変換: - バクラク共通管理: `bakuraku.id.{テーブル名}` - 例: `users` → `bakuraku.id.users` ## Snowflakeの関数 - `DATE_FORMAT` ではなく、 `TO_DATE` を利⽤ ``` TO_DATE( [, ] ) TO_DATE( ) TO_DATE( '' ) TO_DATE( ) ``` - タイムゾーンを変更するときは、 `CONVERT_TIMEZONE` を利⽤ ``` CONVERT_TIMEZONE( , ) ``` ## クエリ⽣成時の注意事項（共通） - enumを利⽤する場合はenumが存在するかどうかをスキーマを⾒て確かめること - Snowflakeの詳細な情報は、schema/snowflake 配下に存在する - layerone-dbt-snowflake の構成はschema/snowflake/.cursor/rules/dbt.mdc を参照して ## クエリ⽣成のガイドライン 1. **スキーマ理解**: - 指定されたパスのマークダウンファイルからスキーマ情報を参照 - コードベースを含めてテーブル間の関連性を把握してJOINを適切に構築 - 存在しないカラムで絞り込みをしないようにスキーマに存在するカラムかどうかを注意深く確認 2. **テーブル名変換**: - MySQLテーブル名に適切なプレフィックスを付与 - プロダクト固有の変換規則は関連ルールファイルを参照 3. **テナント処理**: - テナント関連のクエリでは `xxxx` テーブルを使⽤ 4. **最適化**: - パフォーマンスを考慮したクエリ設計 - 必要なカラムのみを選択 - 適切なフィルタリング条件を設定 5. **成果物のレビュー**: - 作成したクエリが存在しないカラムやenumを利⽤していないかなどチェック - 利⽤したテーブルのドキュメントを確認してチェックしてください - WHEREやJOINの条件が間違っていないかのチェック 6. **出⼒形式**: - 読みやすく整形されたコピーしてそのまま実⾏できるSQLクエリを⽣成 - ユーザーが明⽰的に指⽰しない限り、マークダウン形式ではなくSQLだけを出⼒ - 必要に応じて⽇本語でコメントを付加 ## 注意事項 - 既存コードには⼀切変更を加えない - スキーマ情報は指定されたパスのマークダウンファイルから参照する - テーブル名の変換規則を厳守する - テナント情報は必ず `xxxx` テーブルから取得する - ⽇本語で応答して - SQL中の `AS` のエイリアスは⽇本語ではなく英語で書いてください このルールに従うことで、プロダクトマネージャーは⾃然⾔語を使って効率的にSnowflakeクエリを⽣成してください。 

© LayerX Inc. Cursor上での効率的な調査 Cursor上に問い合わせ調査⽤ルールがあり、ヘルプページや仕様書含めて確認する。 実装されているコードをベースに回答してくれるので、仕様書に記載しきれていないエッジケースや問い合 わせ原因の仮説なども教えてくれる 問い合わせ調査 問い合わせ調査 

© LayerX Inc. # バクラク勤怠 お問い合わせ対応ガイド sections: - step: 0 title: "お問い合わせ内容の正確な理解" details: - "お客様が何を知りたいのか、どのような状況なのかを正確に把握する。" - "必要であれば、追加で質問し、不明点を解消する。" - "問い合わせの背景や⽬的を理解することで、より的確な回答を可能にする。" - step: 1 title: "仕様の確認（ドキュメント優先）" details: - "以下のドキュメントを参照し、該当する情報がないか確認する。" - "ドキュメントソース:" XXXX - "検索する際は、関連するキーワードを複数試す。（例：「打刻」「休暇」「残業」「設定」など）" - "ドキュメントに記載がある場合は、その内容を基に回答を作成する。" - "回答には、参照したドキュメントの箇所（ファイル名や⾒出しなど）を明記する。" - step: 2 title: "実装の確認（ドキュメントに情報がない場合）" condition: "ドキュメントに該当する情報が⾒つからない場合、またはお客様が実装レベルでの確認を希望される場合に限 る。" details: - "以下のコードを参照する。" - "コード参照先:" XXXX - "コードを確認した場合は、どのファイルのどの部分（関数名、処理内容など）を根拠としているかを具体的に記述する。" - step: 3 title: "回答の作成" details: - "確認した情報（ドキュメントまたはコード）を基に、お客様に分かりやすく回答を作成する。" - "専⾨⽤語は避け、平易な⾔葉で説明することを⼼がける。" - "必ず回答の根拠（参照したドキュメントやコードの箇所）を明記する。" - step: 4 title: "不明な場合" condition: "ドキュメントにもコードにも該当する情報が⾒つからない場合、または仕様として明確に定義されていない場合。" action: "「現時点では確認できませんでした」「仕様として明確には定められていません」のように、不明である旨を正直に伝え る。推測での回答は避ける。" important_notes: - "お客様への回答は、常に正確性と丁寧さを⼼がける。" - "回答に⾃信がない場合は、他のメンバーに相談する。" - "このガイドは、バクラク勤怠の仕様変更等に伴い、適宜更新される可能性がある。" 問い合わせ調査 実際のCursorルール 

© LayerX Inc. （ここまで使い分けの話をしておきながら元も⼦もない話ではあるが） ツールにこだわったり、プロンプトにこだわったり、完璧を求めずに まず使ってみるのが最重要。 どのツールも進化しているので、ツールの精度の差は主要どころなら誤差の範囲。 最後に 最後に