はじめに
カイポケコネクトの開発推進チームでエンジニアをしている@_kimusonです。
チームで「リファインメント文字起こしからLLMにチケット詳細を自動でメンテナンスしてもらう」という活用を試したところ非常に感触が良かったので紹介しようと思います!
課題
まず前提としてカイポケリニューアルではLeSS*1を採用しており、スプリントを回す各チームが協業することでプロダクトを前に進めています。
われわれのチームは主にフロントエンドの開発生産性向上をミッションに置き、メンバー2人で一通りのスクラムイベントを実施しています。
その中でリファインメントを実施して、プロダクトバックログアイテムをReadyな状態(Acceptance Criteria(以降、ACと略します)が合意されており、Storypointが振られている)に持っていけるようにしています。
リファインメントで合意した内容は極力チケットに記載するようにはしてはいたんですが、気をつけていてもどうしても漏れは出てしまうのと、チケットに議論した内容をできるだけもれなく記載していくのもコストが掛かってしまっていました。特に2人チームということもあり、議論に参加していない暇な人が書くといったこともしづらいので議事録を丁寧に取っていると議論のスピードが落ちやすく、省力化して運用できると良いなーと思っていました。
結果、「どこかで会話したはずだけどチケットには残ってない」といった内容もたまに発生していました。
解決策
思いつきでリファインメントの文字起こしをそのまま食わせてMCP(Model Context Protocol)を介してJiraチケットにこういった情報を書くのを丸投げしちゃえば良いんじゃね?という話になりました。
文章をサマライズするのは、文字起こしの不安定さを考慮してもLLMにやらせるタスクとしては十分難易度が低いですし、コンテキストサイズも過度に枯渇する内容ではないので行けそうだよねとなり実施しました。
議事録(サマリー)ではなく文字起こしを使う
われわれはSlackのhuddleでリファインメントを実施しているのでhuddleを使っていますが、huddleに限らずだいたいのMTGツールの議事録機能には
- 人が読んで読みやすいように良い感じにサマライズしてまとめられる議事録
- 正確な情報を追うためにサマライズされていないプレーンな文字起こし
の2つが付いていることが多いと思います。
議事録はさっと見るには嬉しいですが
- かなり情報が削がれてしまっている
- 言ってない内容でサマライズされていることが多く信頼性に欠ける(huddle議事録に対する個人的な印象)
といった点で文字起こしの方がおすすめです。
Atlassian MCPとの連携
文字起こしはコピペして食わせるだけなので、あとはその文字起こしの内容からチケットを更新できる必要があります。
われわれはプロダクトバックログの管理にJiraを利用しているため、Atlassianから提供されている公式のRemote MCPを利用しています。
OAuthに対応しているのでAPI Keyなどの発行も不要で使いやすいです。
{ "mcpServers": { "type": "sse", "url": "https://mcp.atlassian.com/v1/sse" } }
これを繋いでOAuthの承認だけ行えばClaude CodeでJiraチケットを探したりアップデートしたりができるようになります。
コマンド化
道具は揃ったのでコマンド化して再利用できるようにします。
以下の内容を .claude/commands/update-jira-from-minutes.md として保存します。
--- description: '議事録からJiraチケットを自動検出し、内容を要約してチケット情報を更新する' allowed-tools: mcp__atlassian__searchJiraIssuesUsingJql, mcp__atlassian__getJiraIssue, mcp__atlassian__editJiraIssue, AskUserQuestion --- You will analyze meeting minutes provided by the user, automatically detect Jira tickets mentioned in the text, and update those tickets with relevant information from the minutes. ## Process ### 1. Extract Jira Ticket References Scan the meeting minutes text for <PROJECT> ticket references in the format: - `<PROJECT>-XXX` (direct mention) - URLs containing `/browse/<PROJECT>-XXX` - Any other patterns that clearly reference <PROJECT> tickets Create a comprehensive list of all unique ticket IDs found. ### 2. Retrieve Current Ticket Information For each detected ticket: - Use `mcp__atlassian__getJiraIssue` with cloudId: `https://<domain>.atlassian.net` to fetch current ticket details - Retrieve: summary, description, status, issuetype, parent (epic), and subtasks if any - If a ticket has subtasks, also retrieve their information ### 3. Analyze Meeting Minutes Content For each ticket found: - Extract all relevant information from the minutes that relates to this ticket - Identify: - Technical decisions made - Implementation approaches discussed - Concerns or blockers mentioned - Dependencies on other tickets - Timeline or priority changes - Any acceptance criteria or requirements clarified ### 4. Generate Update Proposal For each ticket, prepare: - **Updated Description**: Enhance the existing description with information from the minutes - Preserve existing content structure (Why, Acceptance Criteria, Note sections) - Add new sections if needed (Implementation Plan, Technical Background, Dependencies, etc.) - Use markdown formatting - Write in Japanese - **Epic Assignment**: If the discussion indicates this ticket should belong to an epic, identify the epic ID ### 5. Present Updates for Confirmation Use `AskUserQuestion` to present all proposed updates: - Show ticket ID and summary - Display both the current description and proposed description in full - Show epic assignment changes if any - Ask user to confirm which tickets should be updated Format the question clearly: \`\`\` 以下のチケットを更新します。内容を確認してください: [Ticket ID]-[Summary] 現在のDescription: ... 更新後のDescription: ... Epic:[現在]→[更新後] 更新を実行しますか? \`\`\` Provide options: - "すべて更新" (Update all) - "選択して更新" (Select which to update) - "キャンセル" (Cancel) ### 6. Execute Updates Based on user confirmation: - Use `mcp__atlassian__editJiraIssue` to update each approved ticket - Update the `description` field with the enhanced content - If epic assignment is needed, update the `parent` field with the epic ID - Confirm successful updates ## Important Notes - **Cloud ID**: Always use `https://<domain>.atlassian.net` as the cloudId - **Project**: Only process <PROJECT> tickets - **Language**: Write all descriptions in Japanese - **Preserve Information**: Never remove existing information; only enhance and add - **Structure**: Maintain markdown formatting and section structure - **Accuracy**: Only include information that is clearly stated in the minutes - **Parent/Epic Format**: When setting parent/epic, use the format: `{"key": "<PROJECT>-XXX"}` ## Error Handling If any ticket cannot be retrieved or updated: - Note the error - Continue processing other tickets - Report all errors at the end
一応更新前に承認を行ってから反映するようにしています。
結果
このワークフローを使い始めてから非常に運用が楽になりました。
リファインメントではACの合意は大事なのでリアルタイムに会話し記載をします。それ以外の情報は基本書いてませんが、リファインメント直後に上記のコマンドを実行して文字起こしの全文を渡します。あとは承認だけして終わりです。
Claude CodeがACだけでなく
- どういう議論をしてそういう結論になったのか
- 気をつけるべきポイントはどこか
- 実装時に考慮すべきポイントはどこか
といったリファインメントで議論された情報がちゃんと書かれています。
しかも、書かれた情報を読み返してみても議論した内容がかなり正確に整理されて記載されており、違和感のある内容や嘘が書かれていることがほぼほぼないので非常に上手くワークしていると感じます。
リファインメントを実施したら必ず実行する形で定着しているので、今後可能であれば自動で上記のワークフローが実行されるようにできると良いなと思っています。
まとめ
リファインメント議事録を元にClaude Codeを使ってコストをかけずにJiraチケットをちゃんとメンテナンスする手法を紹介しました。
特にわれわれはメンバーが2人なのでかっちりと決め切るより緩く運用している側面もあり、そこにすごく刺さりました。少人数チームだとこういった雑務に割く時間のコスパも悪いので省力化してチケットの質もあがって良いことづくめでした。
皆さんのチームでも良ければお試しください!めっちゃおすすめです。
*1:Large-Scale Scrum。スクラムを拡張したフレームワークで、単一のプロジェクトについて複数のスクラムチームが連携して協業します。