「これチケットにして」が、毎回すり減る
複数案件を並走していると、ある日からこの一言を呟くようになる。
「これチケットにしておいて」
そのつもりで Slack に投げる。たいてい、相手は AI（Claude Code）だ。手元の AI で 1 行から Issue を起こせる ―― はずなのだけれど、実際にやってみると、毎回出てくる Issue の質がバラついた。
- 重複している Issue を新規で起票してしまう
- As-Is と To-Be が混ざる
- 受け入れ条件が無い
- 「ついでにあれもこれも」で、Issue 1 件に複数のスコープが入る
- 起票後、すぐに「実装どうします？」に進んでしまう
これは AI の腕の問題ではなくて、「Issue を作る仕事」と「Issue を消化する仕事」を、同じプロンプトの流れで扱おうとしているから だと、ある日気づいた。
PdM の仕事と dev の仕事のあいだに、境界が無い。
それを引き直すために、Claude Code の Skill 機能を使って 2 本のスキルを作った。
この記事は、その 2 本の設計判断を残しておく実験ログだ。
設計の核心 ―― 一方向のパイプ
2 本のスキルは、こういう一方向のパイプとして並べてある。
pdm-design-doc (アイデア → Design Doc / 仕様書)
↓
issue-intake (As-Is / To-Be → GitHub Issue)
↓
github-issue-pr-flow (Issue → ブランチ → 実装 → PR)
矢印は 一方向だけ。後ろから前に戻らない。
これは Web プロダクトの世界で言う「責任の分離」と同じ発想だ。SaaS のバックエンドで、認証・API・DB レイヤを混ぜないのと同じで、PdM の仕事 / dev の仕事は、同じ Claude Code の中でもレイヤを分けたほうが、出力の質が安定する。
「議論すべきトピックは何ですか？」 の記事で、AI 議事録の質は会議の入力で決まる、という話を書いた。ここで起きているのも、Issue の質は起票時の入力で決まる、PR の質は Issue の質で決まる、という連鎖だ。だからこそ、入力側のスキル（issue-intake）と消化側のスキル（github-issue-pr-flow）を、別々に強く作る。
issue-intake ―― ふわっとを Issue にする側
このスキルがやるのは、「ふわっとした要望を、起票できる粒度まで上げる」 こと。実装には絶対に進まない。
中心的な手順は 4 つ。
1. 入力を As-Is / To-Be に整理する
入力のパターンを 4 つに分けてある。
- A: 既に As-Is / To-Be が書かれている → そのまま使う
- B: 不具合報告風（「壊れてる」「動かない」） → As-Is = 壊れた挙動、To-Be = 正常状態
- C: 機能要望風（「○○できたら嬉しい」） → As-Is = 「現状できない」、To-Be = 要望
- D: ふわっとしすぎ（「なんか UX 微妙」） → 推定せず質問する
D が一番重要だ。AI に推定で書かせると、それっぽい Issue ができてしまう。けれど、そのそれっぽさが後の実装フェーズで毒になる。だから「ふわっとしすぎ」と判定したら、起票しない。
2. 軽く該当コードを当たる
ここで実装方針までは見ない。「この Issue を実装するかどうか、PdM が判断するための材料」までを集める。grep を 1〜2 回、関連ファイルを 1〜2 個メモ、程度。
このバランスが効くのは、起票前にだけ少しコードに触れることで、Issue の解像度が一段上がる からだ。完全に PdM 視点だけで書く Issue より、コードに 1 度だけ触れたあとの Issue のほうが、実装に渡したときのズレが小さい。
3. 重複チェック
gh issue list --search で過去 Issue を当たる。検索結果は 「強い候補 / 弱い候補 / 新規起票 / 再オープン / やめる」 の選択肢としてユーザーに渡す。重複の上に新規を積まない。
4. 受け入れ条件込みで起票
Issue 本文は以下のテンプレ。
## As-Is
## To-Be
## 受け入れ条件
- [ ] ...
## 補足
受け入れ条件は 強く推奨 にしてある。「実装側で何を作れば完了か」を起票時に固めておくことで、次フェーズの認識ズレを防ぐ。
github-issue-pr-flow ―― Issue を消化する側
このスキルは、既に起票済みの Issue を、実装して PR にする 側を担う。
設計上の重要なルールは 5 つ。
1. main への直接 commit・直接 merge は禁止
これはチームで使うときの最低限の安全装置。AI に「main で直接やっちゃおう」と判断させない。マージは 必ずオーナーが手動で実行する。
2. Issue 番号入りのブランチ
ブランチ名は <番号>-<英語ケバブケース> で統一。例: 42-fix-login-copy。
これによって、ブランチ・コミット・PR・Issue が後から辿れる。
3. スコープを広げない
Issue に書いてないことを「ついでに」やらない。スコープ拡張は 必ずユーザーに確認 する。広げたい場合は、別 Issue を issue-intake 経由で起票しに戻る。
4. E2E テスト・ドキュメントを同一 PR に強制
UI / 業務フローを変える PR には、E2E と関連ドキュメント（マニュアル / リリースノート / スクショ）の更新を 同じ PR の中に 入れる。「後追い PR」を禁止することで、テストとドキュメントが永遠に追いつかない状態を構造的に防ぐ。
5. Closes #N で Issue を自動クローズ
PR 本文に Closes #N を入れて、main マージ時に GitHub が自動で Issue を閉じる仕組みに乗せる。Claude が手動で gh issue close を打つことは 禁止。マージと Issue クローズを別タイミングにしない。
なぜ "境界を引く" ことを設計の中心に置いたか
この 2 本を分けて作って、もう一段見えてきたのは、境界線を引かないと、AI は便利すぎて越境する ということだ。
ひとつのプロンプトの中で AI に「Issue を作って、ついでに実装して、PR まで出して」と頼むと、たぶん全部やってくれる。けれど、それは
- Issue の重複チェックが甘い
- 受け入れ条件が無いまま実装が始まる
- スコープが膨らむ
- マニュアルとリリースノートが置き去り
- main に直接マージされてしまう
…というリスクを全部受け入れる、ということでもある。
「同じコンセプト、違うルール」 で書いた "共通化の高さ" の話と並べると、これは 「先に分けて、後で必要なら共通化する」 という設計判断になる。最初から 1 本のスキルで全部やろうとすると、上記の越境が起きる。分けておけば、PdM の仕事 / dev の仕事を別の責任主体（or AI モード）に割り当てやすい。
使ってみての副作用
このスキルを 2 本入れてから、副作用がいくつか見えた。
良い副作用
- Issue の数が増えた: 起票のハードルが下がったので、頭の中で温めていた要望が言語化されるようになった
- スコープが守られるようになった: 1 PR 1 Issue が守られると、レビューが圧倒的に楽
- 「ついで修正」が別 Issue 化された: dev フェーズで「ついでに気づいたあれ」が、放置されずに
issue-intakeに戻って起票される - Issue タイトルが揃った: To-Be 起点の動詞文に統一されたので、バックログを眺めたときの可読性が上がった
悪い副作用
- Issue が増えすぎて優先順位付けが追いつかない: これは別問題として、優先順位付けスキルが必要かもしれない
- 重複チェックでヒットしたあとの判断が、結局 PdM の頭脳労働: 「乗せるか / 新規にするか / 再オープンか」は AI に任せきれない
- PdM の手数が減らない: スキルが綺麗に動くほど、「中身を読んで判断する」工程が PdM に集中する
特に最後の "PdM の手数が減らない" は、思っていたのと違った発見だった。AI スキルは PdM の労働を減らさない。判断する場所を、起票や実装の途中から、起票前 / 起票後の確認ポイントに移しているだけだ。
開いている問い
このシリーズで僕がいま考えているのは、AI スキルで業務の境界を引いていくと、どこまで分割すべきか、という問いだ。
仮説としては、
- 「責任の主体が変わる場所」で分ける ―― PdM と dev、PdM と CS、dev と QA など
- 「入力と出力の粒度が変わる場所」で分ける ―― ふわっとした要望 → Issue → ブランチ → PR、と粒度が階段状に上がる場所
- 「やってはいけないことが明確に違う場所」で分ける ―― 「実装には進まない」「main に直接マージしない」のような禁則の差
…の 3 つが、スキルを分ける判断軸になりそうだと思っている。
これは PdM Playbook を地域に翻訳する シリーズと並んで、PdM Playbook を AI のワークフローに翻訳する という別シリーズになりうる気がしている。
リポジトリは公開してある。スキル本体は以下にあるので、興味があれば中身を見たり、フォークして自分の運用に合わせて手を入れてもらえると嬉しい。
- hico-mrmgn/Skills
plugins/pdm/issue-intake/skills/issue-intake/SKILL.mdplugins/dev/github-issue-pr-flow/skills/github-issue-pr-flow/SKILL.md
「これチケットにして」が、毎回すり減らない形で動くようになる ―― それがこの実験の出口だ。