会話と要件をMCP で読み、Skill で文案を整える — 起票前の整理と要件理解の話
中川侑大私はエンジニアとして案件に関わっています。その中で、使用確認に関するやりとりや Backlog の課題を読み、 Jira に載せる前の文案を整える 作業をよく担います。
必要な事実は、最初から一箇所にありません。
| 情報源 | よくある置き場 |
|---|---|
| 背景・現状 | Backlog 課題本文 |
| 期限・方針の変更 | Backlog コメント |
| スコープの合意 | Slack やメモの会話 |
| まだ決まっていないこと | どこにも書かれていない |
この記事では、その作業でどのように要件理解や情報整理を進めてきたかを、順を追って書きます。
① 自分の力でまとめた情報が、当てにならない
この整理を、しばらくは自分だけでやっていました。ブラウザで Backlog を開き、コメントを追い、会話を見返し、頭の中で「いまの最新合意」を合成するやり方です。
ただ、自分は要件の抜けや思い込みに気づきにくいタイプです。自分でまとめた文案も、あとから見返すと「あのコメント反映したっけ？」となりやすい。 自分の力でまとめた情報が、あまり当てにならない 、というのが出発点でした。
要件を理解したいのに、その材料そのものが信用しきれない。ここにまず、しんどさがありました。
② AI を入れたが、別の問題が出た
そこで AI を導入しました。会話や Backlog を渡して「Jira 用に整理して」と頼む使い方です。意図は 要件理解の補助 —— 散らばった情報を一度並べてもらって、自分の見落としに気づくこと —— でした。
ところが、別の問題が出ました。
プロンプトで「推測で要件を足すな」と書いても、 見出しはきれいなのに根拠のない内容が混ざる ことがあります。受け入れ条件まで勝手に書かれることもある。きれいな文案ほど疑って中身を潰す確認が増え、往復のたびに時間が伸びました。
文案を読むたびに、二重の作業が発生していました。
- 会話・Backlog と文案が一致しているか を確認する
- 自分の理解が合っているか を確認する
1 のせいで 2 に辿り着く前に疲れる。理解の補助のはずが、 AI の出力を疑う作業 になっていました。推測が混ざると、確認対象が1つ増えるだけです。
③ 今回入れたもの — MCP で読んで、Skill で整える
その状態を変えるために入れたのが、 MCP と 今回作った Skill です。Skills 機能そのものの説明は、UHD ブログに譲ります。
- Skills 機能 について → Claude Code Skills を使おう
- MCP について → 自社ブログに MCP サーバーを実装した話
いまの流れは次のとおりです。
| 段階 | 使うもの | 内容 |
|---|---|---|
| 1. 元情報 | MCP（Backlog） | 課題本文・コメントを取得 |
| 2. 補足 | 人 | Slack やメモの会話を渡す |
| 3. 整理 | 今回作った Skill | テンプレートとルールで文案を作成 |
| 4. 反映 | 人 | 文案を確認して Jira に載せる |
MCP でつないでいるのは Backlog のみ です。Slack などは MCP ではつないでおらず、会話は必要に応じてチャットに貼るか、口頭で補足します。以前はブラウザで課題を開いてコピーし、会話ログも別途貼る、という 人間のコピペ が毎回入っていました。MCP が担うのは、その Backlog からの取得 です。
今回作った Skill に書いたのは、Jira 用の 文案テンプレート と 作成ルール です。
- description の見出し構成 （背景、現状、補足…など）
- 根拠のないセクションは書かない （空なら見出しごと省略）
- 推測で要件や受け入れ条件を足さない
- 不足は埋めず、ネクストアクション（確認）に落とす
「どこまで書けば起票できる形か」の目安は、きれいさではなく切り分けです。
- 合意済み → 書く
- 未確定 → 書かないか、「確認する」と書く
- 推測 → 書かない
短い指示は、だいたいこんな感じです。
この Backlog 課題を Jira 用に整理して
（会話で決まった追記があればその内容）
今回作った Skill がテンプレートとルールを適用し、 起票前の文案 を出します。Jira への反映は、その文案を人が確認してから行います。
難しい要件でも理解しやすくなったのは、「きれいに書け」ではなく 「書けないなら、次に確認すべきことを書け」 と説明させているからです。未完成が文案上に残るので、自分の思い込みで埋めずに済みます。
④ 入れてみて、どう変わったか
MCP で Backlog を読めるようにしたあと、 今回作った Skill を足したタイミング で、文案まわりがはっきり変わりました。
Skill で型を固定したら
- 根拠のないセクションは 最初から出てこない
- 見出し構成が毎回同じ → 「何が書かれていないか」 が見えやすい
- 未完成な部分は無理に埋めない → 「ここはまだ合意されていない」 が文案上に残る
AI の出力を疑う時間が減り、 会話の事実と自分の理解を突き合わせる時間 に戻せるようになりました。見落としが起きやすい人ほど、AI に「賢く書かせる」より 「勝手に書かせない」 方が効く、というのがいまの実感です。
数字で見る変化
| 項目 | 今回の Skill 導入前 | 今回の Skill 導入後 |
|---|---|---|
| 文案作成の所要時間 | 約10分 | 約5分 |
| 確認の往復 | 3〜4回 | 2〜3回 |
| 見出し構成 | 毎回バラバラ | 毎回同じ |
| 要件の追加 | 推測が混ざりやすい | 勝手な要件を足さなくなった |
所要時間が半分になった のは、書く速さというより、 「これどこから来た？」の確認が減った からだと感じています。導入前は、きれいにまとまった文案ほど疑って中身を潰す作業が入っていたので、1本あたり10分かかっていました。
確認の往復 も、導入前は「AI が足した要件を削る」→「別の推測が入る」→「また削る」というループに入ることがありました。導入後は、最初から推測が入りにくいので、 会話の解釈合わせ に集中できる往復に近づきます。
見出し構成 が毎回同じになったのも効いています。読む側も書く側も「いつもこの順番で見ればいい」とわかるので、 抜けているセクションに気づきやすくなった からです。
要件の追加 については、いちばん体感が大きい変化です。以前は「受け入れ条件」まで勝手に書かれることがあり、それが確認コストの中心でした。「根拠がなければ書かない」を今回の Skill に固定してからは、 会話にないことを文案が代わりに決めてくれなくなった ので、ここが楽になりました。
MCP で材料集めが楽になったのはそのままに、 品質面の変化は今回作った Skill を入れたことで一気に出た 、というのが正直なところです。Skills 機能の汎用的な便利さというより、この業務で起きがちな誤読の型を、先に禁止できたことが効いていると思います。
まとめ
要件理解や情報整理の出発点は、「自分のまとめが当てにならない」でした。AI に頼んでも、推測が混ざると確認コストが増える。そのときに効いたのが、 勝手に書かせないルールを今回の Skill に固定すること でした。
- 今回作った Skill を入れただけで 、見出しが固定され、推測で要件を足さなくなり、確認の往復も減った（10分→5分、3〜4回→2〜3回）
- 見落としが起きやすい人ほど AI のまとめは効くが、推測が混ざると 理解の補助ではなく確認コストが増える — 今回の Skill はその確認コストを下げる
うまくハマるかは人それぞれだと思いますが、同じ悩みがあるなら一度試してみてほしい、という話でした。
