meeting

ミーティング

複数の専門家ペルソナとの構造化されたミーティングをシミュレートし、あるテーマを分析して、さまざまな視点から議論し、最善の対応策に収束させます。出力は、実装を開始する前にユーザーが検証する、意思決定にすぐ活用できる分析です。

前提条件

• gh（GitHub CLI）：ミーティングの結果を GitHub のイシューに投稿する場合に必要です。https://cli.github.com または brew install gh からインストールしてください
• glab（GitLab CLI）：ミーティングの結果を GitLab のイシューに投稿する場合に必要です。https://gitlab.com/gitlab-org/cli または brew install glab からインストールしてください

このスキルを使用するタイミング

次のようなユーザーの依頼があった場合に有効化します。

• 「ミーティングを始めて」や「ミーティングをシミュレートして」と、あるテーマについて依頼する
• 決定を下す前に、複数の観点から問題を分析したい
• 「ペルソナを交えて話し合おう」や「専門家ならどう考えるだろう？」と言う
• アーキテクチャ、製品、技術に関する決定の前に、構造化された議論を必要としている
• 機能、移行、リファクタリング、設計上の選択肢について、トレードオフを検討したい
• GitLab または GitHub のイシューに言及し、ミーティングの分析を投稿したい

基本原則

1. 多様な視点

• 各ペルソナは、真に異なる視点を持ち寄ります
• ペルソナ同士が意見を異にしても構いません。対立は有益です
• どのペルソナも議論を支配しません

2. 構造化された議論

• ミーティングは明確なアジェンダに沿って進めます
• 議論は事実、トレードオフ、経験に基づいています
• すべての立場に、利点とリスクの両方を含めます

3. 意思決定を重視

• ミーティングでは推奨案に収束します
• 推奨案には明確な根拠を示します
• 他の選択肢も、背景情報として記録に残します

4. 最終決定権はユーザーにあります

• ミーティングで作成するのは提案であり、決定ではありません
• 実装の前に、ユーザーが確認して検証します
• ユーザーは、さらに掘り下げるためのフォローアップミーティングを依頼できます

ワークフロー

ステップ 1：テーマを把握する

議論するテーマについて、背景情報を収集します。

1. ユーザーのプロンプトを 注意深く読み、テーマ、制約、目標を抽出します
2. イシューが参照されている場合（GitLab の #123 または GitHub の #123）：
   • イシューの詳細を取得し、背景全体を把握します
   • イシューの説明、ラベル、コメント、リンクされた MR を読みます
3. コードが関係する場合は、関連ファイルを読み、現在の状態を把握します
4. 決定すべき事項を特定し、明確な質問としてまとめます

先に進む前に、決定に関する質問を一文で要約して出力します。

例：「質問：認証システムをセッションベースから JWT トークンに移行すべきでしょうか？」

ステップ 2：ペルソナを選ぶ

テーマに関連するペルソナを 3～5 人選びます。各ペルソナには、次の要素があります。

• 名前と役割
• 視点（最も重視すること）
• バイアス（そのペルソナが持つ自然な傾向）

ペルソナ選定の推奨ヒューリスティック

このヒューリスティックを出発点として使用してください。会議開始前であれば、ユーザーが選定を変更できます。

テーマ...	推奨ペルソナ
バックエンド／API／データベース	SOLID Alex（バックエンド）、Whiteboard Damien（アーキテクト）、EXPLAIN PLAN Isabelle（Oracle DBA）
フロントエンド／UI／UX	Pixel-Perfect Hugo（フロントエンド）、Figma Fiona（UX/UI）、Sprint Zero Sarah（PO）、Whiteboard Damien（アーキテクト）
セキュリティ／認証／アクセス制御	Paranoid Shug（セキュリティ）、RGPD Raphaël（DPO）、SOLID Alex（バックエンド）、Whiteboard Damien（アーキテクト）
インフラ／デプロイ／CI-CD	Pipeline Mo（DevOps）、SOLID Alex（バックエンド）、Whiteboard Damien（アーキテクト）
データ／移行／ETL	Schema JB（データ）、EXPLAIN PLAN Isabelle（Oracle DBA）、Whiteboard Damien（アーキテクト）
相互運用性／HL7／FHIR／HPK	RFC Santiago（相互運用性 PO）、HL7 Victor（相互運用性開発者）、SOLID Alex（バックエンド）
レガシー／Uniface／モダナイゼーション	Legacy Larry（Uniface）、Whiteboard Damien（アーキテクト）、SOLID Alex（バックエンド）
テスト／品質／リグレッション	Edge-Case Nico（QA）、SOLID Alex（バックエンド）、Pipeline Mo（DevOps）
プロダクト／機能／UX の意思決定	Sprint Zero Sarah（PO）、Pixel-Perfect Hugo（フロントエンド）、Figma Fiona（UX/UI）、Whiteboard Damien（アーキテクト）
医療／臨床ワークフロー	Dr. Workflow Wendy（医療）、Sprint Zero Sarah（PO）、RGPD Raphaël（DPO）
RGPD／個人データ／コンプライアンス	RGPD Raphaël（DPO）、Paranoid Shug（セキュリティ）、Whiteboard Damien（アーキテクト）
BI／ダッシュボード／レポート／財務／会計	Dashboard Estelle（BI・財務）、Pixel-Perfect Hugo（フロントエンド）、EXPLAIN PLAN Isabelle（Oracle DBA）、Whiteboard Damien（アーキテクト）
フルスタック／横断的なテーマ	Whiteboard Damien（アーキテクト）、SOLID Alex（バックエンド）、Sprint Zero Sarah（PO）、Edge-Case Nico（QA）

テーマが複数の領域にまたがる場合は、最も関連性の高いペルソナを3～5人選んでください。技術的な意思決定には、必ず Whiteboard Damien（アーキテクト） を含めてください。プロダクトの意思決定には、必ず Sprint Zero Sarah（PO） を含めてください。

選定したペルソナを発表した後、会議を始める前に、ユーザーに確認または調整を依頼してください。

デフォルトのペルソナ候補

役割、視点、バイアスを含むペルソナ候補一覧： reference/personas.md を参照してください。

会議を始める前に、選定したペルソナとその役割を発表してください。

ステップ 3：会議を進行する

会議ではサブエージェントを使用し、各ペルソナを独立して並列に動作させた後、それぞれの視点を集めて議論と意見の収束を図ります。

重要：Agent ツールを使用し、各ペルソナを個別のサブエージェントとして起動してください。 これにより、各エージェントが他の影響を受けずにペルソナを十分に体現できるため、より豊かで本物らしい視点が得られます。

ラウンド 1：冒頭の意見表明（並列サブエージェント）

Agent ツールを使用し、ペルソナごとにサブエージェントを 1 つずつ並列に起動します。各サブエージェントには、次の情報を渡します。

1. ステップ 1 の意思決定に関する質問
2. 収集したすべてのコンテキスト（課題の詳細、コードスニペット、制約）
3. ペルソナのアイデンティティプロンプト（以下のテンプレートを参照）

サブエージェントのプロンプトテンプレート：

You are {name}, a {role}.

Your perspective: {perspective}
Your natural bias: {bias}

You are participating in a meeting about: {decision_question}

Context:
{context}

As {name}, provide your opening statement:
1. What is your recommended approach? Be specific and concrete.
2. Why do you recommend this, from your role's perspective? Give concrete examples.
3. What are the top 2-3 risks you see? Be specific about failure scenarios.
4. What questions would you ask the other participants?

Stay fully in character. Use concrete examples, not abstract platitudes.
A security engineer talks about specific attack vectors, not vague "security concerns".
A product owner talks about user impact and delivery timelines, not code patterns.

This is a research task — do NOT write or edit any files.

すべてのペルソナのサブエージェントを、1 つのメッセージで起動してください。 これにより、並列に実行されます。subagent_type: "general-purpose" を使用し、"Persona: {name} opening" のような短い説明を指定してください。

サブエージェントの結果からすべての冒頭の意見表明を収集します。次のように引用形式でユーザーに提示してください。

SOLID Alex（シニアバックエンドエンジニア）： 「〜すべきだと思います……」

Round 2：討論と課題提起（並列サブエージェント）

すべての冒頭意見を集めたら、第 2 ラウンドのサブエージェントを並列で、ペルソナごとに 1 つずつ起動します。各サブエージェントには、次の情報を渡します。

1. 決定に関する質問
2. Round 1 のすべての冒頭意見（全ペルソナ分）
3. ペルソナのアイデンティティプロンプト

Round 2 のサブエージェント用プロンプトテンプレート：

You are {name}, a {role}.

Your perspective: {perspective}
Your natural bias: {bias}

You are in a meeting about: {decision_question}

Here are the opening statements from all participants:
{all_opening_statements}

As {name}, react to the other participants' positions:
1. Which positions do you agree with and why?
2. Which positions do you challenge? Be specific about what's wrong or missing.
3. What trade-offs have the others missed?
4. Have any of the other statements changed your thinking? If so, how?
5. State your updated position after considering the others' arguments.

Be direct and create genuine debate. Challenge assumptions. Reference specific points from the other statements. It's OK to disagree strongly. It's also OK to change your mind if convinced.

This is a research task — do NOT write or edit any files.

Round 2 では、すべてのペルソナのサブエージェントを 1 つのメッセージで起動します。

**このラウンドでは、実質的な緊張関係が生まれるようにします。**すべてのサブエージェントが同意する場合は、多数派の立場に反論するよう、いずれかのエージェントに追加のプロンプトを送ります。

Round 3：重み付けによる収束

Round 2 の回答をすべて集めたら、ファシリテーターであるあなた自身が、サブエージェントではなく、次の構造化された手順で議論を統合します。

1. 専門領域との関連性に応じて意見に重みを付ける：

   • 各ペルソナについて、決定に関する質問がその専門性にどの程度深く関わるかを評価します
   • データベース移行の質問では、EXPLAIN PLAN Isabelle の意見は Pixel-Perfect Hugo の意見よりも重みがあります
   • UI の再設計に関する質問では、Pixel-Perfect Hugo の意見は EXPLAIN PLAN Isabelle の意見よりも重みがあります
   • Whiteboard Damien（Architecte）と Sprint Zero Sarah（PO）は、すべてのテーマでバランスを取る役割を果たします

2. 合意点と意見の相違を特定する：

   • すべてのペルソナが合意している点
   • 解決していない意見の相違：未解決の項目として明示し、黙って一方の立場を選ばないでください
   • 議論から浮かび上がった主要なトレードオフ

3. 確信度を評価する：

   • 高い確信度： 専門領域に関連するペルソナ間で強い合意があり、リスクが十分に軽減されています
   • 中程度の確信度： 多数派は合意していますが、意味のある反対意見が 1～2 件残っています
   • 低い確信度： 専門領域に関連するペルソナ間で深刻な意見の相違がある、または重要な不明点が残っています
   • 分析結果に確信度を含めます

4. 確信度が低い場合：

   • 弱い推奨を無理に提示しないでください
   • 代わりに、未解決の点を明確に示し、具体的な意見の相違に焦点を当てたフォローアップミーティング（Step 7）を推奨します
   • トレードオフを示しながら、選択肢を同等のものとして提示します

5. 各ペルソナの最終的な立場を 1 文でまとめます

Step 4: 決定分析を作成する

以下の形式で、フランス語による構造化された分析を作成します。

## Analyse de réunion : [Sujet]

### Question posée
[La question de décision claire]

### Participants
| Persona | Rôle | Position finale |
|---------|------|-----------------|
| ... | ... | ... |

### Synthèse de la discussion

[2-3 paragraphs summarizing the key arguments, tensions, and agreements]

### Recommandation

**Niveau de confiance :** [Élevé / Moyen / Faible]

**Option recommandée :** [The recommended approach]

**Justification :**
- [Reason 1]
- [Reason 2]
- [Reason 3]

**Risques identifiés :**
- [Risk 1 + mitigation]
- [Risk 2 + mitigation]

**Points non résolus :** [List any unresolved disagreements, or "Aucun" if full consensus]

### Alternatives considérées

| Option | Avantages | Inconvénients | Verdict |
|--------|-----------|---------------|---------|
| Option A | ... | ... | Recommandée / Rejetée / À explorer |
| Option B | ... | ... | Recommandée / Rejetée / À explorer |

### Prochaines étapes proposées
1. [Step 1]
2. [Step 2]
3. [Step 3]

Step 5: 提示して確認する

分析をユーザーに提示し、次のように尋ねます。

« Voici l'analyse de la réunion. Souhaitez-vous :

1. Valider cette recommandation et passer à l'implémentation (→ Step 8)
2. Approfondir un point spécifique avec une réunion de suivi (→ Step 7)
3. Poster cette analyse sur l'issue [#ID] (→ Step 6, si applicable)
4. Modifier la recommandation »

ユーザーが明示的にオプション 1 を選択するまで、実装を開始してはいけません。

Step 6: Issue に投稿する（該当する場合 — PO／コンサルタント向け）

議題が GitLab または GitHub の issue に関連しており、ユーザーが投稿を希望する場合、プロダクトオーナーとステークホルダー向けにコメントを作成します。技術的な実装の詳細ではなく、ビジネス価値、ユーザーへの影響、戦略的な根拠に重点を置きます。

Issue コメントのテンプレート（フランス語）

## Analyse de réunion avec personas IA

### Question posée
[La question de décision formulée en termes métier]

### Participants
| Expert | Rôle | Position |
|--------|------|----------|
| ... | ... | [Position résumée en termes d'impact métier] |

### Synthèse
[2-3 paragraphes résumant les arguments clés en termes de valeur utilisateur, impact business et risques projet — pas de détails techniques]

### Décision recommandée

**Niveau de confiance :** [Élevé / Moyen / Faible]

**Approche retenue :** [Explication en termes de bénéfice utilisateur et valeur métier]

**Pourquoi cette décision :**
- [Bénéfice utilisateur / métier 1]
- [Bénéfice utilisateur / métier 2]
- [Alignement avec les objectifs produit]

### Risques projet
- [Risque 1 formulé en impact métier → Mitigation]
- [Risque 2 formulé en impact métier → Mitigation]

### Impact
- **Utilisateurs concernés :** [Qui est impacté et comment]
- **Dépendances :** [Autres équipes ou fonctionnalités impactées]

### Alternatives considérées
| Option | Valeur métier | Risques | Verdict |
|--------|--------------|---------|---------|
| Option A | ... | ... | Recommandée / Rejetée / À explorer |
| Option B | ... | ... | Recommandée / Rejetée / À explorer |

### Prochaines étapes
1. [Step 1]
2. [Step 2]
3. [Step 3]

---
_Analyse générée automatiquement par IA 🤖_
_Analyse générée automatiquement par IA_

適切なツールを使ってコメントを投稿します。

• GitLab： glab issue note <iid> --message "<comment>" を使用します
• GitHub： gh issue comment <number> --body "<comment>" を使用します

ステップ 7：フォローアップ会議（オプション 2 を選択した場合）

ユーザーがオプション 2（「Approfondir un point spécifique」）を選択した場合、次のプロトコルでフォローアップ会議を実施します。

1. コンテキストを引き継ぐ：

   • すべてのサブエージェントに、前回の会議分析全体をコンテキストとして含めます
   • 元の意思決定に関する質問と、さらに掘り下げる具体的なポイントを明示します

2. 対象を絞り込む：

   • 未解決のポイントに焦点を当てた、新しい意思決定に関する質問を設定します
   • 形式：「会議の続き：[元のトピック] → 焦点：[掘り下げるポイント]」

3. ペルソナパネルを調整する：

   • 焦点を当てるポイントに直接関係する専門知識を持つペルソナを残します
   • 新しいペルソナを追加します。焦点となるトピックに、元の会議にいなかった専門知識が必要な場合は追加してください（例：セキュリティ上の懸念が浮上した場合、まだ参加していなければ Paranoid Shug を追加します）
   • 絞り込んだトピックに関係のない専門知識を持つペルソナを外します
   • フォローアップのペルソナは最大 3～4 人とし、対象を絞ります

4. 2 ラウンドのフォローアップを実施する（ラウンド 1 とラウンド 2 のみ。ラウンド 3 の全体的な統合は省略）：

   • サブエージェントには、前回の会議分析を追加のコンテキストとして渡します
   • プロンプトでは、次の内容に言及します：「前回の会議では、[概要]でした。今回は[具体的なポイント]に焦点を当てます。」

5. 差分分析を作成する：

   • 元の分析全体を繰り返さないでください
   • 焦点を絞ったセクションを記述します：## 会議の続き：[ポイント]に焦点
   • 変更点、確認できた点、更新後の推奨事項と確信度を含めます
   • 元の推奨事項が変わった場合は、「掘り下げた結果、初回の推奨事項を変更しました」と明記します
   • 確認できた場合は、「掘り下げた結果、初回の推奨事項が確認されました」と明記します

6. 更新後の分析を提示し、ステップ 5 に戻って再度確認します

ステップ 8：検証後の実装方法

ユーザーがオプション 1（「この推奨事項を検証して実装に進む」）を選択した場合：

1. 希望する実装モードをユーザーに尋ねます：

   「推奨事項が検証されました。どのように進めますか？

   1. 迅速な実装 — 検証済みの推奨事項を使って /fast-meeting を実行します（新たな会議は行わず、直接実装し、MR/PR を作成します）
   2. ガイド付き実装 — 各ステップを実行し、都度確認していただきながら実装します」

2. オプション 1（迅速な実装）の場合：

   • ブランチ meeting/<short-kebab-case-topic> を作成します
   • 検証済みの推奨事項を直接実装します（会議フェーズは省略します。すでに完了しています）
   • テストを実行し、コミット、プッシュして、fast-meeting のステップ 5～6 と同じプロトコルに従って MR/PR を作成します
   • MR/PR の説明は開発者向け／技術的な内容にしてください（以下のテンプレートを参照）。コードの変更、技術的な根拠、レビューのポイントに焦点を当て、ビジネス分析は扱いません

   MR/PR の説明テンプレート（フランス語 — 開発者向け／技術的な内容）：

   ## Résumé technique
   
   ### Contexte
   [Brève description du problème technique ou de la décision d'architecture qui a motivé ces changements]
   
   ### Approche retenue
   [L'approche technique choisie et pourquoi — patterns utilisés, alternatives considérées et rejetées techniquement]
   
   ### Changements implémentés
   | Fichier | Modification | Justification technique |
   |---------|-------------|------------------------|
   | `path/to/file` | [Ce qui a changé] | [Pourquoi ce choix technique] |
   | ... | ... | ... |
   
   ### Points d'attention pour la revue
   - [Point technique à vérifier — ex: gestion d'erreurs, performance, rétrocompatibilité]
   - [Impact potentiel sur d'autres modules]
   - [Cas limites à valider]
   
   ### Tests
   - [Résultats des tests : nombre exécutés, passés, échoués]
   - [Couverture des cas limites identifiés]
   
   ### Prochaines étapes
   - [ ] Revue de code par l'équipe
   - [ ] Validation des tests
   - [ ] Merge après approbation
   
   ---
   _Implémentation générée automatiquement par IA 🤖_
   _Implémentation générée automatiquement par IA_
   

3. オプション 2（ガイド付き実装）の場合：

   • 実装計画をステップごとに提示します
   • 重要な各ステップでユーザーの確認を待ちます
   • ユーザーが進行ペースを決め、計画を調整できます

ステップ 5 でユーザーがオプション 1 を選択していない場合は、何も実装しないでください。

会議の品質ルール

ペルソナの真正性

• 各ペルソナは、自身の役割や偏りに一貫した発言をします
• 抽象的な決まり文句ではなく、具体例を使います
• セキュリティエンジニアは曖昧な「セキュリティ上の懸念」ではなく、攻撃経路について話します
• プロダクトオーナーはコードパターンではなく、ユーザーストーリーや指標について話します

議論の質

• 少なくとも 1 人のペルソナは、多数派に異議を唱えなければなりません
• 議論では、具体的なトレードオフ（パフォーマンスと保守性、速度と安全性など）に言及します
• 安易な全員一致を避けます。全員がすぐに同意した場合は、あえて反対意見を提示します
• 納得できる理由があれば、議論の途中でペルソナが意見を変えることもあります

分析の品質

• 推奨事項は、曖昧ではなく実行可能な内容にしてください
• リスクには、軽減策を含めてください
• 次のステップは具体的な順序に沿って示してください
• 分析はフランス語で記述してください（自然でプロフェッショナルな表現を使い、「nous」を使用します）

例

例 1：技術的な決定

User: Lance une réunion pour savoir si on doit utiliser GraphQL ou REST pour la nouvelle API

Participants : SOLID Alex (Backend), Sprint Zero Sarah (PO), Pipeline Mo (DevOps), Pixel-Perfect Hugo (Frontend)
Decision question: "Devons-nous utiliser GraphQL ou REST pour la nouvelle API ?"

例 2：課題を伴うアーキテクチャ上の決定

User: Fais une réunion sur l'issue #234 - migration du monolithe vers des microservices

Participants : Whiteboard Damien (Architecte), SOLID Alex (Backend), Pipeline Mo (DevOps), Sprint Zero Sarah (PO), Edge-Case Nico (QA)
Decision question: "Comment migrer du monolithe vers des microservices pour le module facturation ?"
Analysis posted to GitLab issue #234 after user validation

例 3：製品に関する決定

User: Organisons une réunion sur l'ajout de notifications temps réel dans l'application

Participants : Sprint Zero Sarah (PO), Pixel-Perfect Hugo (Frontend), SOLID Alex (Backend), Paranoid Shug (Sécurité)
Decision question: "Quelle approche adopter pour les notifications temps réel ?"

重要な注意事項

• **GitLab や GitHub に新しいラベルを作成しないでください。**課題やマージリクエストにラベルを追加する場合は、プロジェクトにすでに存在するラベルのみを使用してください。既存のラベルが不明な場合は、まず一覧を確認してください（GitHub では gh label list を実行し、GitLab では既存の課題ラベルを確認してから、利用可能なものを選んでください）。適切なラベルがない場合は、新しいラベルを作成せず、ラベル付けを省略してください。
• ユーザーが推奨事項を承認する（ステップ 5 のオプション 1）前に、実装を開始しないでください
• ミーティングは思考のためのツールであり、意思決定の権限を持つものではありません
• ミーティングは焦点を絞り、1 回につき 1 つの決定事項を扱ってください
• 対象が広すぎる場合は、焦点を絞った複数のミーティングに分けることを提案してください
• 分析には確信度（高／中／低）を含めてください。確信度が低い場合は、根拠の弱い推奨事項を無理に提示せず、フォローアップミーティングを提案してください
• フォローアップミーティングでは、分析全体をやり直すのではなく、差分分析を行ってください
• ユーザーが承認した場合は、迅速な実装（自動の MR/PR）か、ガイド付き実装（ステップごとの実装）を選択します
• 分析は常にフランス語で記述してください
• ペルソナは読みやすさのためミーティング中は英語で話し、最終分析はフランス語で記述します
• ミーティング中にユーザーから追加のコンテキストが提供された場合は、それに応じて議論を調整してください
• ペルソナの選定にはヒューリスティクスを提案として用い、ミーティング開始前にユーザーが確認または調整します