performance-review-writer

Performance Review Writer

自分らしい言葉で、自己評価・同僚評価・上司への フィードバック を下書きします。よくある定型文ではありません。WorkIQ を使って実際の貢献やコミュニケーションを洗い出し、正直で成果に焦点を当てた文章に構成します。

使用するタイミング

• 「今回の評価サイクル向けに自己評価を書いて」
• 「[同僚] への同僚評価を下書きして」
• 「上司への上方フィードバックを書くのを手伝って」
• 「年次評価の締め切りが近いので、記入を手伝って」
• 「半期の中間チェックインを下書きして」
• 「[名前] への 360 度評価を書いて」
• 「評価に何を書けばいいかわからない」

評価の種類

このスキルは次の 3 種類を扱います。

種類	対象者	一般的なトーン
自己評価	自分自身	自信があり、根拠に基づき、成長志向
同僚評価	同僚	具体的、建設的、バランスが取れている
上方フィードバック	上司	配慮があり、率直で、未来志向

---

ワークフロー

ステップ 1 — 背景情報の収集

ユーザーに質問します（まだ提供されていない場合は最大 3 つまで）。

1. 評価の種類 — 自己評価、同僚評価、上方フィードバックのどれですか？
2. 対象者 — 評価の対象は誰ですか？（同僚評価・上方フィードバックの場合は名前と役職）
3. 評価期間 — どの期間を対象としますか？（例：2025 年 1 月～12 月、直近 6 か月）

形式の制約や重点項目が関係する場合は、最初に尋ねるのではなく、下書きの段階で確認します。

ユーザーがこれらすべてを最初に提供している場合は、直接ステップ 2 に進みます。

ステップ 2 — 貢献の洗い出し

WorkIQ を使って、評価期間中の実際の貢献の根拠を収集します。

自己評価の場合:

• ユーザーが成果を出した、施策を主導した、問題を解決したメールやメッセージを抽出する
• パターンを探す：どのプロジェクトが繰り返し登場するか？ 誰が何を理由に評価しているか？
• 協働の幅を確認する（部署横断でどの人と仕事をしたか）
• 他者から受けた明示的なフィードバックを記録する

同僚評価の場合:

• ユーザーと対象者のやり取り（メール、会議のスレッド、共有プロジェクト）を抽出する
• 協力、支援の提供、あるいは摩擦があった具体的な場面を特定する
• 共有された成果に対する対象者の影響の証拠を探す

上方フィードバックの場合:

• 上司からユーザーへのコミュニケーション（指示、提供されたサポート、フィードバックの傾向）を抽出する
• テーマを特定する：期待の明確さ、対応可能性、評価、成長支援

WorkIQ が利用できない、または限られたデータしか返さない場合は、ユーザーに覚えている事柄を 3～5 個の箇条書きで共有してもらい、それを基に進めます。

ステップ 3 — 評価の下書き

評価の種類に応じた適切な構成を適用します（下記のスキーマを参照）。以下の共通ルールに従ってください。

成果の記述には STAR 形式を使用する:

• 状況（Situation） — 背景や課題は何だったか？
• 課題（Task） — 本人（または対象者）が担っていた責任は何か？
• 行動（Action） — 具体的に何を行ったか？
• 結果（Result） — 測定可能な、または観察可能な成果は何か？

トーンのルール:

• 具体的にする — 曖昧な形容詞ではなく、プロジェクト、成果、人物の名前を挙げる
• 正直にする — 過大にも過小にも評価しない。評価者はどちらも気づく
• 未来志向にする — 過去の実績だけでなく、各セクションの最後は成長や次のステップで締める
• 決まり文句を避ける：「期待以上の働き」「チームプレイヤー」「勤勉」などは、根拠に置き換える
• ユーザーの自然な文体に合わせる — 普段から会話調で書く人なら会話調に、そうでなければよりフォーマルに

ステップ 4 — 出力

1. 使用した根拠について簡単な説明を添えて、評価の全文を提示する。原文をそのまま引用せず、要約し、個人情報を伏せる — 生の抜粋、出席者リスト、機密性の高い個人情報は含めない
2. [NEEDS DETAIL] と記されたセクションのうち、より具体的な情報を加えると評価が強化される箇所を強調する
3. ユーザーの要望に応じて編集を繰り返す
4. 最終版の下書きを、内容が分かる名前のファイルで outputs/<year>/<month>/ に保存する（例：2025-review-self-assessment.md や 2025-peer-review-alex-chen.md）

---

出力スキーマ

自己評価スキーマ

## [Review Period] Self-Assessment — [Your Name]

### Summary
1–2 sentence overview of your year and primary areas of impact.

### Key Achievements
For each major contribution (aim for 3–5):

**[Project or Initiative Name]**
- Context: what was the situation or goal?
- What I did: specific actions taken
- Impact: measurable result or observable outcome
- [NEEDS DETAIL] — flag if evidence is thin

### Collaboration & Influence
How you worked with others, supported teammates, or contributed beyond your direct role.

### Growth & Development
What you learned, skills you built, or behaviours you improved this period.

### Areas for Development
1–2 honest areas where you want to grow next cycle. Frame as goals, not failures.

### Goals for Next Period
2–3 specific, concrete goals with a rough success measure.

---

同僚評価スキーマ

## Peer Review — [Colleague Name], [Their Role]
## Submitted by: [Your Name] | Period: [Review Period]

### Overall Impression
1–2 sentences on working with this person.

### Strengths (with examples)
For each strength (aim for 2–3):

**[Strength]**
- Example: specific situation where this showed up
- Impact on you / the team / the project

### Areas for Growth
1–2 specific, constructive observations. Frame as "I think [name] would have even more impact if..." not as criticism.

### Collaboration
How easy (or not) it was to work together — responsiveness, reliability, communication.

### Would you work with this person again?
Yes/No and a brief honest reason. (Only include if the review form asks.)

---

上司へのフィードバックのスキーマ

## Feedback for [Manager Name]
## Submitted by: [Your Name] (anonymous if applicable) | Period: [Review Period]

### What's working well
2–3 specific things your manager does that help you do your best work.
Use examples where possible.

### What could be better
1–2 honest, diplomatically framed observations. Focus on behaviours and their effect, not personality.
Use: "When [X happens], I find it harder to [Y]. It would help if..."

### Support for my development
Has your manager helped you grow, given useful feedback, or created opportunities?
Be specific.

### One thing I'd ask them to do more / less / differently
A single, clear, actionable ask.

---

スタイルのルール

すること	しないこと
具体的なプロジェクト、日付、成果を挙げる	曖昧な一般論を書く（「常に質の高い仕事をする」など）
可能な場合は数値を使う（「レビュー時間を30％短縮した」など）	結果を誇張したり、捏造したりする
実際に直面した課題と、そこから学んだことを認める	苦労した点を完全に省く — レビュアーは抜けに気づきます
自己評価では一人称で書く	受動態で書く（「達成されました」など）
簡潔にまとめる — ほとんどの項目は2〜4文で十分です	冗長に書く — 長ければよいというものではありません
根拠が弱い箇所には[NEEDS DETAIL]を付ける	内容が薄い箇所に印を付けずに残す

---

プロンプトの例

• 「2025年1月から12月までの自己評価を書いてください。クラウド移行と、私が設計した新しいオンボーディングプロセスを取り上げたいです。」
• 「Sarah Chenさんへの同僚評価の草案を作ってください。モバイルアプリのプロジェクトで密接に協力したプロダクトデザイナーです。」
• 「上司のTomさんへのフィードバックを書くのを手伝ってください。方針を示すのは得意ですが、定期的な1対1の時間を取るのに苦労しています。」
• 「年次評価フォームでは、それぞれ200語で強みを3つ、成長課題を1つ書くよう求められています。記入を手伝ってください。」
• 「何を書けばよいのかまったくわかりません。忙しい一年でしたが、具体的なことが思い浮かびません。」

---

重要なルール

• レビューを提出してはいけません — ユーザーが確認して手動で提出できるよう、ファイルとして草案のみを作成してください
• 同僚や上司へのフィードバックは、性格や人格ではなく、観察可能な行動に焦点を当ててください
• ユーザーから、不誠実に否定的なレビューや個人攻撃を含むレビューの作成を求められた場合は断り、建設的な表現への言い換えを提案してください
• 機密性を守ってください — 無関係な会話やスレッドの機密情報を含めないでください
• outputs/<year>/<month>/フォルダーの規則に従って草案を保存してください

---

要件

• WorkIQ MCP ツールは、貢献やコミュニケーション（Microsoft 365／Outlook／Teams）を確認するのに推奨されます
• WorkIQ がなくてもスキルは引き続き使えます — 出発点として、主な貢献を3〜5個箇条書きでユーザーに尋ねてください
• 出力はワークスペースに Markdown ファイルとして保存されます。ユーザーはその内容を自社の評価システムにコピーできます