pm-skills で要件定義から GitHub issue はどこまで「いい感じ」に切れるか検証してみた【株式会社ライトコード】

1. 動機

AI 時代になり、エンジニアとして Claude Code のような AI に開発そのものを依頼する機会が増えました。そこで強く感じるのが、AI に渡すタスクの粒度が、そのまま出力の質を左右するということです。粒度が粗すぎるまま「これ作って」と投げると期待とズレたものが返ってきて手戻りになりますし、逆に細かく切りすぎると自分でタスク分解する手間の方の本末転倒になります。人間の開発チームでも、この「作業をうまく分割して、適切な順番・粒度で割り振る」能力は PM の重要なスキルのひとつですが、AI に開発を依頼する上でも同じ能力が必要になってきていると感じていました。

だとすれば、そのタスク分解や要件の具体化自体も AI に任せられたら素敵だ、というのが今回の検証の出発点です。今回は Product Management 特化の Claude Code プラグイン集である pm-skills（phuryn/pm-skills）を実際に自分たちのリポジトリに入れて試しました。

検証は 2 人（今井・山崎）で並行して行い、同じ評価軸・別々の要件で採点しています。雰囲気の「やってみた」で終わらせず、評価軸を先に固定して採点するところまでやるのが本記事のねらいです。

2. pm-skills とは

pm-skills は Claude Code の plugin marketplace 形式で配布されている、プロダクトマネジメント業務に特化したスキル集です。pm-product-discovery / pm-product-strategy / pm-execution / pm-market-research など 9 プラグインで構成され、Discovery（顧客発見・要件定義）から Execution（開発実行）、Growth まで幅広くカバーしています。

今回の issue 分割の検証で使ったのは pm-execution プラグインの 2 コマンドだけです。

/write-prd … ラフな要件から PRD（Product Requirements Document）を生成する
/write-stories … PRD を INVEST 原則に沿ったユーザーストーリーの一覧（バックログ）に分割する

事前に押さえておきたい前提が 2 つあります。1 つは、pm-skills には GitHub issue を直接作成する機能はないこと。アウトプットはあくまで Markdown ドキュメント（PRD・ストーリー一覧）で、それを実際の issue に変換するのは別工程です。

もう 1 つは、これらのスキルにリポジトリ内のソースコードを読み込む工程がないことです。README に明記されているわけではありませんが、スキル定義（プロンプト）を確認すると、入力として想定されているのは要件の説明やユーザーが渡した文書・デザインリンクといったコンテキストのみで、コードベースを調査する指示は含まれていません。Claude Code 上で動く以上、コードファイルを明示的に渡せば読めるはずですが、通常のフローでは「既存の実装がどうなっているか」を知らないまま分割が行われます。この特性が、後半の評価結果に大きく関わってきます。

3. セットアップ

導入は Claude Code の plugin marketplace 経由で、コマンド 2 つで完了します。

/plugin marketplace add phuryn/pm-skills

/plugin install pm-execution@pm-skills

導入後、/write-prd と /write-stories がスキル一覧に出ていれば準備完了です。

なお 1 点つまずきがありました。最初、README の個別プラグイン紹介を上から律儀にひとつずつ /plugin install していたのですが、実際には marketplace add の 1 回で 9 プラグインすべてが導入対象になり、必要なものだけ install すれば済みます。2 人で突き合わせて初めて「あの手順は全部やらなくてよかった」と気づきました。

4. 検証方法

題材は、この検証のために Claude Code でぱっと作らせたテスト用の社内図書館サイト（library-site、Next.js）です。実運用しているプロダクトではなく、pm-skills を試すためだけに用意した最小構成の題材アプリです。蔵書データを TS にハードコードし、蔵書一覧・詳細・予約フォームのページを持つだけで、永続化も管理画面も存在しません。

ここに 2 人がそれぞれ別の要件を渡し、/write-prd → /write-stories → gh issue create の同じフローを流しました。

検証 A（今井）: 貸出管理まわりのラフ要件 5 行（貸出履歴 / Slack 通知 / タグ検索 / 管理者 CRUD / 予約待ち）
検証 B（山崎）: 1 行の要件「コード変更・再ビルドなしにブラウザ上で蔵書を追加・編集・削除・検索できる管理画面を作りたい」

評価は事前に固定した次の 5 軸で採点します。

粒度（1 ストーリー ≒ PR 1 本か）
依存関係（着手順・前提の明示）
受け入れ条件（Acceptance Criteria があり、テスト可能か）
網羅性（漏れ・重複がないか）
既存コード整合（既存実装を踏まえているか）

偶然ですが、どちらの検証でも生成されたストーリーは 14 件で、それぞれ issue #1〜#14 として登録しました。要件 5 行からも、要件 1 行からも、Non-Goals・Success Metrics・Phase 分割・非機能要件まで含んだ PRD が生成され、14 件まで膨らみます。この「言っていないことまで拾って膨らませてくる」傾向は、pm-skills（というか LLM）に共通する挙動のようです。