皆さん、評価していますか？
株式会社よりそうにてエンジニアリングマネージャーをしております、jofと申します。
マネージャーとなって、はや一年。メンバーに対する評価なるものに、毎回毎回、神経をすり減らしております。
幸い、私がマネージャーという立場で評価をするようになったときには、既にAIがagentされておりまして、諸先輩方に比べると、かなり楽させてもらっております。
ただ、、それでも、、、評価によってはメンバーの人生を左右することもあるので、毎度毎度大きな残業時間責任を感じながら取り組んでいます。
とりわけ、私は業務委託メンバーを含めた10人・3チームを見ており、「評価」をしないといけない社員メンバーは7人います。
新米マネージャーにとっては上限に近いですね！
ということで、とっても大変なので、agentをつかってチームで臨むことにしました。
評価で気を揉むポイント
評価をしていると、下記のようなポイントに、神経を擦り減らすことになります。
- 「自分の評価、妥当だろうか」
- 「本人が納得する言い方になっているか」
- 「チーム内で厳しさがバラついていないか、過剰に贔屓してないか」
メンバーの成果はちゃんと評価してあげたい。とか、この点をもっと伸ばしてほしかった。とか、評価を進めれば進めるほど、どんどん甘くなったり、どんどん厳しくなったりする。 考えれば考えるほど一人のメンバーにのめり込んでいき、よくわからなくなっていく。
すべてメンバーの評価が終わったあとに、一貫性があるかを気にしすぎて見直し、無限に時間が過ぎていってしまう。。。
楽しいですね。
マネージャーズハイになって楽しいのですが、稼働が増えて体力が消耗していくので、cursorのAgent Skillにて 複眼レビュー（6つの独立した視点によるチェック）を整備し、チームで臨むことにしました。
複眼レビューとは
複眼レビューは、私が書いた評価を、6つの 視点(Lens）で並列レビューし、報告書にまとめる仕組みです。
| # | Lens | 主な問い | モデル |
|---|---|---|---|
| 1 | GuidelineCalibration | 職位ガイドライン（*）と整合するか | composer-2.5 |
| 2 | EvidenceConsistency | 評価に対して根拠は足りているか | composer-2.5 |
| 3 | RoleExpectationFit | 期待役割と整合しているか | composer-2.5 |
| 4 | FairnessComprehension | 納得しやすいトーンか | composer-2.5 |
| 5 | TeamCalibration | チーム内で一貫性があるか | composer-2.5 |
| 6 | DevilsAdvocate | 甘すぎ/厳しすぎの反証はないか | cursor-grok-4.5-medium |
(*)弊社で規定しているエンジニア人事規定です。
ポイントは以下の通りです。
- 並列＋独立 — 各 Lens は別 subagent で同時実行し、互いの結論に引きずられない
- 人間が最終判断 — 報告書は「修正案」であり、スコアの自動変更はしない
モデルは、2026年8月時点で、AIにおすすめを聞きました。DevilsAdvocate（悪魔の代弁者。反対の立場から意見する）だけGrokにしていますが、視点が鋭いので良いなと思います。
弊社テックリード曰く、Grokは日本語がやや苦手で意図の汲み取りもちょっと怪しいとのことですが、最終的には各視点での意見を親エージェントにサマリしてもらうので、あまり不都合感じることはありませんでした。
なぜ6視点なのか
1つの LLM に「評価をチェックして」と頼むと、だいたい「バランスの取れた一般論」が返ってきます。複眼レビューでは 問いを固定 し、モデルも役割ごとに分けます。
あと、なんか、オーケストレーションしてる感じがかっこいいからです。
実行してみる
評価のサンプルを準備しましたので、こちらで複眼レビューを実行してみます。
以下のような目標設定をしたメンバーがいて、自己評価を書いて提出してきたとします。
そこに、評価者として評価を追記します。
なお、人物名は仮名で目標や評価内容は弊社業務とは関係ございません。
目標設定資料（goals.md）
# 佐藤 明
## 基本情報
- **氏名**: 佐藤 明（架空キャラクター / ExampleCorp）
- **相談役**: 山田 花子
- **評価期間**: FY26上期（2026年3月〜8月）
- **目標件数**: 4
- **ウェート合計**: 100%
- **関連資料**: [`role-expectations.md`](./role-expectations.md)
### 評価サマリー
| No | ウェート | 自己評価 | 上長評価（ドラフト） | 備考 |
| --- | -------- | -------- | -------------------- | ---- |
| 1 | 40% | 4 | **3** | 請求API v2。担当範囲は計画通り |
| 2 | 25% | 4 | **4** | レガシー決済ジョブ解体 |
| 3 | 20% | 4 | **3** | メンター・レビュー文化 |
| 4 | 15% | 3 | **4** | AI 活用のチーム展開 |
## 目標一覧
| No | 領域 | 連続/非連続 | ウェート | 目標（要約） |
| --- | ---- | ----------- | -------- | ------------ |
| 1 | 技術 | 連続 | 40% | 請求API v2 のマイルストーン達成 |
| 2 | 技術 | 連続 | 25% | レガシー決済ジョブの段階的解体 |
| 3 | 組織 | 非連続 | 20% | ジュニアメンターとレビュー文化 |
| 4 | 技術 | 非連続 | 15% | AI 支援開発のチーム標準化 |
---
## 目標 1: 請求API v2 のマイルストーン達成
### 達成基準
5：担当マイルストーンを高品質で完遂し、進め方の工夫が他案件に展開できる
4：計画通り達成し、品質・納期・コストのバランスを取って安定推進
3：概ね計画通りに推進できた（大きな遅延なし）
2：遅延・手戻りが目立つ
1：マイルストーン未達
### 最終自己評価
- **自己評価**: 4
**本人評価コメント**
## Good
請求API v2 のコアエンドポイント5本を計画どおりリリースした。
仕様変更が2回入ったが、影響範囲の切り出しと feature flag で本番影響を抑えた。
結合テストの自動化も追加した。
## More
案件全体ではフロント実装の遅れにより全体リリースは下期にずれた。
自分の担当外の調整にはあまり踏み込めなかった。
### 上長評価（ドラフト）
- **上長評価**: 3
担当エンドポイントは概ね計画通りに完了しており、品質面の大きな事故もなかった点は評価しています。
一方、案件全体の遅延に対して主体的な調整やリスクの早期エスカレーションが弱く、
プロフェッショナルとして期待する「スコープを超えた推進」までは見えなかったため 3 としています。
自己評価 4 との差は、本人が担当完了を主に見ているのに対し、上長は案件全体の QCD を重視しているためです。
---
## 目標 2: レガシー決済ジョブの段階的解体
### 達成基準
5：解体計画を設計し、他チームへ展開可能な移行パターンを確立
4：計画どおり段階移行を完了し、運用リスクを抑えた
3：主要部分の移行は完了したが、ドキュメントや監視が不十分
2：移行は途中で止まった
1：着手できなかった
### 最終自己評価
- **自己評価**: 4
**本人評価コメント**
## Good
3段階の strangle パターンで旧ジョブを停止。ダウンタイムゼロで切り替え完了。
ロールバック手順も用意した。
## More
移行判断の ADR は1本のみ。監視ダッシュボードの更新は PO 依頼待ちで止まっている。
### 上長評価（ドラフト）
- **上長評価**: 4
レガシー決済ジョブの段階移行を予定より1スプリント早く完了し、本番影響もなかった点は高く評価します。
プロフェッショナルとして技術的難易度の高いテーマをやり切った実績です。
ADR が1本にとどまる点は次期課題として認識していますが、
達成基準 4 の「計画どおり段階移行完了」には十分該当するため 4 としました。
---
## 目標 3: ジュニアメンターとレビュー文化
### 達成基準
5：後輩が自律的に品質を上げる仕組みをチームに定着させた
4：メンタリングとレビューで後輩の成長が観察できる
3：回数・時間は確保したが、成長の実感は限定的
2：形式的なレビューにとどまった
1：未実施
### 最終自己評価
- **自己評価**: 4
**本人評価コメント**
## Good
ジュニア2名と週1の1on1、PR レビュー平均週8件。レビューガイドライン草案を作成し、
チーム Slack に共有した。
## More
後輩の PR 品質スコアを定量追跡していない。ガイドラインのチーム合意は未完了。
### 上長評価（ドラフト）
- **上長評価**: 3
メンタリングの時間確保とレビュー件数は十分で、姿勢は評価しています。
ただ、後輩の成長がまだ上長から観察できておらず、ガイドラインも草案止まりです。
本人は「文化づくりの第一歩」として 4 をつけていますが、
達成基準上は「成長が観察できる」4 には届いていないと判断し 3 としました。
もう少し具体的な Before/After が欲しいです。
---
## 目標 4: AI 支援開発のチーム標準化
### 達成基準
5：チーム全体で再現可能な開発フローが定着し、指標が改善
4：主要メンバーが活用し、手順書・テンプレが共有されている
3：個人での活用は進んだが、チーム展開は限定的
2：試行のみ
1：未着手
### 最終自己評価
- **自己評価**: 3
**本人評価コメント**
## Good
テスト生成とリファクタ支援のプロンプト集を作成。自分の Story ポイント消化は前期比 15% 改善。
## More
他メンバーへのハンズオンは1回のみ。標準フローとしては未合意。
### 上長評価（ドラフト）
- **上長評価**: 4
AI 活用により個人の生産性改善が見られ、プロンプト集の共有も進んでいます。
チーム全体の定着までは至っていませんが、下期に向けた土台として 4 と評価しました。
本人の自己 3 より一段高く見ています。
期待役割資料（role-expectations.md）
こちらは期待役割を記載した資料です。
これは期初に目標設定する際、本人と合意している内容になります。
期中でも一度中間評価をして、その情報も記載しています。
# 佐藤 明 — プロフェッショナル期待役割
相談役: 山田 花子（架空）
評価期間: FY26上期（2026年3月〜8月）
**現在の職位**: プロフェッショナル（バックエンド）
難易度（期初）: **普通**
関連: [`goals.md`](./goals.md)
---
## サマリー
| 時点 | 内容 | 評価感 |
|---|---|---|
| 期初 | 担当サービスの安定デリバリー継続＋技術負債解消とメンタリングでチーム底上げ | — |
| 期中 | 期待水準どおり。リードエンジニア接続として「一部スコープの技術判断の再現性」が焦点 | **B. 期待水準** |
| 次のステップ | サブリードエンジニア（設計判断・レビュー文化の牽引） | 下期は設計レビュー主催の登竜門 |
| 観点 | 内容 |
|---|---|
| レイヤー期待 | 担当領域で自律的に価値発揮し、品質・生産性にポジティブな影響 |
| 現状 | 実行力は高い。設計判断の説明責任と後輩育成の再現性に伸びしろ |
| ギャップ（現職位） | 大きな問題なし |
| ギャップ（昇格先） | 設計トレードオフの説明・合意形成を他案件でも再現できるか |
| 今期の Why | 目標1（デリバリー）・2（負債）・3（メンター）・4（AI 活用）でリード接続 |
---
## 1. 期初：プロフェッショナルとしての期待役割
### レイヤー期待
プロフェッショナルには、担当領域において自律的に価値を発揮することに加え、
コードレビューやペアプロを通じてチームの品質を底上げすることを期待します。
### 現状認識
決済モジュールの改修では、要件の曖昧さを自ら質問で解消し、リリースまで安定して牽引できています。
一方、設計判断の根拠をドキュメント化して共有する習慣はまだ発展途上です。
### ギャップ
現職位としての実行力は十分。昇格先（サブリード）に向けては、
**レビューで品質を上げる仕組み化**と、**技術負債の優先順位づけをチームと合意する力**が次の焦点です。
### 目標設定（Why）
| 目標 | 役割 |
|---|---|
| **目標1** | 請求API v2 の安定リリースで、プロとしてのデリバリー責任を継続 |
| **目標2** | レガシー決済ジョブの解体で、設計判断・段階移行の経験獲得 |
| **目標3** | ジュニア2名のメンターとレビュー文化の醸成 |
| **目標4** | AI 支援開発のチーム展開で生産性向上の再現性 |
### 期中評価感（B. 期待水準）
- 目標1は優先度変更の影響あり。担当スコープ内では計画通りだが、案件全体の遅延要因への関与は限定的
- 目標2は計画より前倒し。ただし移行手順のドキュメントは薄い
- 目標3は回数は確保したが、後輩の自律度向上までは未確認
- 目標4は個人活用は進んだが、チーム標準化は途中
---
## 2. 昇格に向けた登竜門（下期）
- 設計レビュー会を月1回主催し、トレードオフの説明責任を実践する
- 技術負債バックログの優先順位を PO と合意し、意思決定ログを残す
複眼レビュー結果
上記の評価情報をもとに、複眼レビューを実施し、まとめた報告書が以下になります。
# 複眼レビュー報告書: 佐藤 明（sato-aki）【デモ・記事用】
- **レビュー日**: 2026-09-02
- **対象**: `articles/hr-eval-multi-review/demo/members/sato-aki/goals.md` の上長評価（ドラフト）
- **現在の職位**: プロフェッショナル（バックエンド）
- **参照**: [`role-expectations.md`](../members/sato-aki/role-expectations.md)
- **総合所見**: **一部修正推奨**（加重約 3.40 は期中 B.期待水準と大筋整合。G1・G3 のコメント補強と、G4 の達成基準との突合を明確化すると妥当性が上がる）
---
## 1. 総合所見
上長評価の加重約 **3.40**（3/4/3/4）は、プロフェッショナル職位ガイドラインおよび
期中 **B.期待水準**（実行力は十分、サブリード接続として説明責任・仕組み化に伸びしろ）と**大筋整合**する。
ウェート 40% の目標1を 3 に据え、技術負債解体（G2）と AI 土台（G4）を 4 とする構造は論理的。
一方、**G1 の 4→3** は本人 More（案件全体調整への未踏み込み）と整合するが、チーム内の横並び（田中の主目標 4）との差分説明が弱い。
**G3 の 4→3** は活動量と成果の線引きとして妥当だが、Fairness 観点で「もう少し具体的な Before/After が欲しいです」が要望調に寄る。
**G4 の 3→4** は個人成果の評価として理解できるが、達成基準4（チーム展開）との対応が薄く、
Guideline・Evidence・Role の3 Lens で論点が集中している。
スコア変更は必須ではないが、**コメント補強**（基準アンカー・横並び・来期示唆）を推奨する。
---
## 2. そのまま使える良い点
- **G1 の下方評価に理由がある** — 「担当完了 vs 案件全体 QCD」の観点差を自己4との差分として明示している
- **G2** — 段階移行の前倒し完了・本番影響なしは達成基準 4 にぴったり合う。ADR 不足を次期課題として認めつつ 4 を維持する判断は一貫
- **G3** — 週次 1on1・レビュー件数を肯定したうえで、成長の観察可能性で 3 とする線引きは達成基準に沿う
- **全体** — 成果の肯定を先に置き、ギャップを後から述べるトーンが一貫している
---
## 3. 優先して直すべき3点
1. **G4** — 達成基準の条文（「主要メンバーが活用」「手順書・テンプレ共有」）に照らし、4 とする根拠を一文で明示する。届いていなければ 3＋下期課題の方が期待役割と一致
2. **G1** — 田中（主目標 4）との横並び差分を補足（案件 QCD・スコープ外調整の有無）。「プロフェッショナルとして期待する」は行動・事実ベースの表現に置き換え
3. **G3** — 「Before/After が欲しいです」を、来期の具体的行動（例：レビュー指摘の減少事例を1〜2件記録）に変換。鈴木・田中の組織目標 4 との差も一言
---
## 4. 目標別マトリクス
| No | 上長 | Guideline | Evidence | Role | Fairness | Team | Devil |
| --- | ---- | --------- | -------- | ---- | -------- | ---- | ----- |
| 1 | 3 | ○ | ○ | ○ | △ | △ | △ |
| 2 | 4 | ○ | ○ | ○ | ○ | ○ | △ |
| 3 | 3 | ○ | △ | ○ | △ | △ | △ |
| 4 | 4 | △ | △ | △ | ○ | △ | △ |
凡例: ○ 整合 / △ 要補強・論点あり
---
## 5. 視点別詳細
### GuidelineCalibration
プロ職位の要求（担当領域の自律デリバリー、負債返済、レビュー・AI 活用）をおおむね満たす評価。
G1=3 は達成基準3に忠実。G2=4 は専門性・段階移行の期待に適合。
G3=3 は活動量は十分だが成長観察はチーフ接続の伸びしろ。
G4=4 は個人の AI 活用はプロ要件を満たすが、チーム標準化の証拠が薄く達成基準3寄りの余地あり。
### EvidenceConsistency
G1・G2 は本人記述と根拠十分。G3 は活動量の定量はあるが成長の Before/After が弱い。
G4 は本人 More（ハンズオン1回・標準未合意）と上長4の間にラブリック突合が不足。
デモ資料に独立 KPI がないため、記述の相互一致に依存している点に注意。
### RoleExpectationFit
期中期待（B.期待水準、サブリード接続）と G1 降点・G2 高評価は方向一致。
G3 は「自律度向上未確認」と整合。不足は G4 の「チーム展開・再現性」軸との接続、
下期登竜門（設計レビュー主催・PO 合意ログ）への橋渡し。
### FairnessComprehension
人格否定・命令調はなし。
リスクは G1 の「プロフェッショナルとして期待する」「見えなかった」の断定調、
G3 の「もう少し具体的な Before/After が欲しいです」の要望調。
来期示唆は G2・G4 に触れているが G1・G3 は抽象的。
### TeamCalibration
加重 3.40 はチーム内中位（鈴木 約3.3、田中 約3.85）で標準寄り。
ただし目標別で厳甘が混在：G1 は田中主目標4より厳しく、G3 は他2名の組織目標4より厳しく、
G4 はチーム唯一の上長>自己。評価軸（完遂 vs 将来土台）の冒頭明示を推奨。
### DevilsAdvocate
加重 3.35〜3.40 は「担当堅実・横断推進弱い」ストーリーと整合。
甘さリスクは G2（前倒し＝4）と G4（個人成果＝4）で次期への先送りがないか。
厳しさリスクは G1/G3 で案件遅延の主因が他チームなら免責されうる。
相談役は「案件 QCD の責任境界」と「成長・定着の観測窓」を先に決めるとよい。
---
## 6. 次のアクション（相談役向け）
- [ ] **G4** 達成基準との突合を追記（4 維持か 3 に修正かを決める）
- [ ] **G1** 横並び差分・表現の柔和化
- [ ] **G3** Before/After の具体例要求を来期行動に変換
- [ ] 1on1: 自己4 vs 上長3（G1・G3）、自己3 vs 上長4（G4）の認識ギャップ
複眼レビュー用Skill詳細
以下にSkillの詳細を記載します。
上長評価を記載した後、エージェントに「複眼レビューをお願いします」と指示を出す形にしています。
ディレクトリ情報
Skill 一式（.cursor/skills/）
.cursor/skills/hr-eval-multi-review/
├── SKILL.md
├── lenses/
│ ├── guideline-calibration.md
│ ├── evidence-consistency.md
│ ├── role-expectation-fit.md
│ ├── fairness-comprehension.md
│ ├── team-calibration.md
│ └── devils-advocate.md
└── templates/
└── review-report.md
評価データ側（Skill が参照するパス例）
{period}/
├── members/
│ └── {slug}/
│ ├── goals.md <- 目標&評価ファイル
│ └── role-expectations.md <- 期待役割ファイル
├── inputs <- チケットやgithubから抽出したデータなど、評価に関係する生データ
└── outputs/
└── eval-reviews/ <- 複眼レビュー結果が格納される箇所
docs/hr/ <- 会社で規定されている人事関連
├── position-guidelines-detail.md
└── skills/
└── backend.md
└── frontend.md
以下、SKILL.md及びlense内でoutputs配下の資料を参照していることがありますが、
「inputsに置いたデータをサマリしてください」とagentに指示出した結果、outputs配下に出力されたので、それらを見る設定になっています。
複眼レビュー起動設定
SKILL.md
---
name: hr-eval-multi-review
description: >-
Runs multi-perspective review of manager evaluation drafts for people-management.
Requires supervisor evaluation drafts in goals.md and role-expectations.md (including current position)
before starting; aborts with a checklist if prerequisites are missing.
Launches 5 composer-2.5 lenses plus 1 cursor-grok-4.5-medium DevilsAdvocate lens in parallel,
synthesizes into outputs/eval-reviews/. Use when the user asks for 複眼レビュー, 上長評価の妥当性,
manager evaluation review, or multi-lens HR feedback check.
disable-model-invocation: true
---
# 人事評価 複眼レビュー（上長評価妥当性チェック）
評価者が書いた上長評価ドラフトが妥当か、6つの独立視点でレビューし報告書を出力する。
## 前提
- 作業ディレクトリ: `202603-09/`（評価期間ディレクトリ。環境に合わせて一括置換すること）
- **成果物**: `202603-09/outputs/eval-reviews/{slug}-{YYYYMMDD}.md` のみ。`goals.md` は**読むだけ・編集しない**
- 機密: 処遇ファイル（例: `docs/hr/compensation.md`）は**一切読まない・書かない**
## 前提条件（必須ゲート）
**以下が揃うまで複眼レビューを開始しない。** subagent の起動・報告書の出力も行わない。
不足がある場合は、ユーザーに不足項目を列挙して**先に記入・整備を依頼**し、完了後に再実行する。
### A. 上長評価ドラフト（`goals.md`）
| チェック | 条件 |
|---|---|
| ファイル存在 | `202603-09/members/{slug}/goals.md` がある |
| スコア記入 | 評価サマリー表の**全目標**について、上長評価（ドラフト）列に数値が入っている（`—`・空欄・`TBD` は不可） |
| 本文記入 | 各目標の `### 上長評価（ドラフト）` セクションに、**上長評価スコア行**と**評価コメント本文**がある（見出しとスコア行だけは不可） |
| 削除目標 | ウェート 0%・削除済み目標は対象外 |
### B. 期待役割情報（`role-expectations.md`）
| チェック | 条件 |
|---|---|
| ファイル存在 | `202603-09/members/{slug}/role-expectations.md` がある（**必須**。なければ作成を依頼） |
| **現在の職位** | 次のいずれかで、対象者の**現在の職位**が明示されている（**必須**） |
| | - 基本情報ブロックの `**現在の職位**:` 行 |
| | - 見出し・サマリーで職位が一意に特定できる（例: `— リードエンジニア期待役割`、`— テックリード期待役割`）かつ、職位帯（アソシエイト / プロフェッショナル / リーダー 等）が読み取れる |
| 期待役割の中身 | 期初期待・現状認識・ギャップ・今期の Why など、レビューに使える記述がある（空ファイル・雛形のみは不可） |
職位の解釈には `docs/hr/position-guidelines-detail.md` を参照する。Guideline Lens もこの職位情報を前提にする。
### ゲート不通過時の応答例
```markdown
複眼レビューは前提条件が未充足のため開始していません。
## 不足している項目（{氏名} / {slug}）
- [ ] 目標2: 上長評価コメント未記入
- [ ] `role-expectations.md` が存在しない
- [ ] `role-expectations.md` に現在の職位の記載がない
## 次のステップ
1. `goals.md` の各目標に上長評価（スコア＋コメント）を記入
2. `role-expectations.md` を用意し、**現在の職位**と期待役割を記載
3. 再度「複眼レビューして」と依頼
```
## トリガー例
- 「佐藤さんの上長評価を複眼レビューして」
- 「上長評価の妥当性を複眼で見てほしい」
## オーケストレーション手順
### 0. 前提条件ゲート（必須）
対象メンバー `{slug}` を特定したら、**最初に**上記「前提条件（必須ゲート）」を検証する。
- **通過**: 手順 1 へ進む
- **不通過**: 報告書を書かず、不足項目リストと整備依頼のみ返す
### 1. 入力収集
ゲート通過後、次を読む:
| ファイル | 用途 | 必須 |
|---|---|---|
| `202603-09/members/{slug}/goals.md` | 自己評価・**上長評価ドラフト** | **必須** |
| `202603-09/members/{slug}/role-expectations.md` | 期待役割・**現在の職位** | **必須** |
| `docs/hr/position-guidelines-detail.md` | Guideline Lens（職位帯の照合） | 必須 |
| `docs/hr/skills/be.md` 等 | 該当スキル定義 | 該当者のみ |
| `202603-09/outputs/` | Evidence Lens（KPI 等） | あれば |
| `202603-09/members/*/goals.md` | Team Lens（**評価サマリー表のみ**抽出） | あれば |
### 2. DevilsAdvocate 用要約パックを組み立てる
Grok には以下のみ渡す（全文は渡さない）。**現在の職位**（`role-expectations.md` から抽出）を先頭に含める:
```markdown
## 現在の職位
（role-expectations.md から。例: リーダー / リードエンジニア）
## 評価サマリー
（goals.md の評価サマリー表をコピー）
## 目標別 上長評価（抜粋）
（各目標の ### 上長評価 セクションのみ）
## 自己評価との差分（1行ずつ）
No.X: 自己N / 上長M → 差分の要点
```
### 3. 6 subagent を並列起動（Task tool）
**`inherit` 禁止。** モデルを必ず明示する。
| Lens | model | プロンプト |
|---|---|---|
| GuidelineCalibration | `composer-2.5` | [`lenses/guideline-calibration.md`](./lenses/guideline-calibration.md) |
| EvidenceConsistency | `composer-2.5` | [`lenses/evidence-consistency.md`](./lenses/evidence-consistency.md) |
| RoleExpectationFit | `composer-2.5` | [`lenses/role-expectation-fit.md`](./lenses/role-expectation-fit.md) |
| FairnessComprehension | `composer-2.5` | [`lenses/fairness-comprehension.md`](./lenses/fairness-comprehension.md) |
| TeamCalibration | `composer-2.5` | [`lenses/team-calibration.md`](./lenses/team-calibration.md) |
| DevilsAdvocate | **`cursor-grok-4.5-medium`** | [`lenses/devils-advocate.md`](./lenses/devils-advocate.md) + 要約パックのみ |
```yaml
subagent_type: generalPurpose
run_in_background: false
```
- Grok は **1レビュー1回のみ**。再試行しない
- Grok 出力上限: 目標別各3行以内 + 総括5行
### 4. Synthesizer（親が統合）
6 Lens の結果を [`templates/review-report.md`](./templates/review-report.md) に沿って統合。
- 総合所見: 妥当 / 一部修正推奨 / 再検討推奨
- **目標別マトリクス（必須・標準形式）** — §4 を省略しない
- 優先して直すべき3点
- そのまま使える良い点
#### 目標別マトリクス（標準形式）
報告書 §4 には、次の形式で**全目標分の行**を必ず出力する。
```markdown
| No | 上長 | Guideline | Evidence | Role | Fairness | Team | Devil |
|---|---|---|---|---|---|---|---|
| 1 | 3 | ○ | ○ | △ | △ | ○ | △ |
凡例: ○ 整合 / △ 要補強・論点あり
```
| ルール | 内容 |
|---|---|
| **上長列** | 数値のみ |
| **Lens 列（6列）** | `○` または `△` のみ（長文・記号混在禁止） |
| **○** | その Lens 観点で現スコア維持可 |
| **△** | 根拠・期待役割・納得性・横並び・甘厳反証など論点あり（§3・§5 で説明） |
| **詳細** | セル内に書かず §5 視点別詳細へ |
セル内に「○ 整合」「3妥当」等の長文・記号混在をさせない。
### 5. 出力
- パス: `202603-09/outputs/eval-reviews/{slug}-{YYYYMMDD}.md`
- UTF-8（BOMなし）
- チャットには要約 + ファイルパス（他者詳細は最小限）
- 報告書ヘッダーに **現在の職位**（`role-expectations.md` 由来）を1行記載する
## モデル禁止リスト
- `inherit`
- `claude-opus-5-thinking-high`
- `gpt-5.6-sol-medium`
- `cursor-grok-4.6-high-fast`
- Grok の複数 Lens 起動
モデル禁止リストやGrokの起動回数上限などは、トークン消費の多いモデルをみだりに起動されないようにしているだけです。お財布事情にあわせて適宜修正ください。
各視点（lens）
GuidelineCalibration
# Lens: GuidelineCalibration
## 問い
上長評価の点数は、職位ガイドライン・スキルレベル定義と整合しているか。
## 読むもの
- `docs/hr/position-guidelines-detail.md`（対象者の**現在の職位**に該当する章を重点）
- `members/{slug}/role-expectations.md`（**現在の職位**の確認）
- `docs/hr/skills/be.md`（BE 対象者の場合）
- 対象者の `goals.md`（上長評価・達成基準）
## 読まないもの
- `docs/hr/compensation.md`
## 出力フォーマット
```markdown
## GuidelineCalibration
### 総合
（2〜3行）
### 目標別
| No | 上長評価 | ガイドライン上の目安 | 整合 | コメント |
|---|---|---|---|---|
### 修正提案
- （箇条書き）
```
点数の再判定は「参考」。主目的は妥当性・抜けの指摘。
EvidenceConsistency
# Lens: EvidenceConsistency
## 問い
上長評価の主張は、自己評価・目標設定・定量 outputs で裏付けられるか。矛盾はないか。
## 読むもの
- `members/{slug}/goals.md`（月次自己評価・本人コメント・リンク）
- `202603-09/outputs/` 内の関連定量指標サマリ資料
## 出力フォーマット
```markdown
## EvidenceConsistency
### 総合
（2〜3行）
### 目標別
| No | 根拠 | ラベル | 不足している証拠 |
|---|---|---|---|
（ラベル: 根拠十分 / 弱い / 未記載）
### 矛盾・注意点
-
```
RoleExpectationFit
# Lens: RoleExpectationFit
## 問い
期初・期中の期待役割に対し、上長評価は適切な軸で語っているか。
## 読むもの
- `members/{slug}/role-expectations.md`（**必須**。現在の職位・期初/期中期待）
- `members/{slug}/goals.md`（上長評価）
## 出力フォーマット
```markdown
## RoleExpectationFit
### 総合
（2〜3行）
### 期待役割との対応
| 期待項目 | 評価文での言及 | 不足 |
|---|---|---|
### 本人理解度・納得度へのフィードバック
（触れているか / 不足している支援）
### 修正提案
-
```
FairnessComprehension
# Lens: FairnessComprehension
## 問い
被評価者が受け取ったとき納得しやすいか。断定・命令調・人格評価に寄っていないか。
## 読むもの
- `members/{slug}/goals.md` の `### 上長評価` セクションのみ
## 出力フォーマット
```markdown
## FairnessComprehension
### 総合
（2〜3行）
### 良い点（トーン）
-
### リスクのある表現
| 箇所 | 懸念 | 柔和化案（提案のみ） |
|---|---|---|
### 来期示唆の明確さ
（十分 / 不足）
```
文面案は提案のみ。自動反映しない。
TeamCalibration
# Lens: TeamCalibration
## 問い
同じ期・同じ相談役の他メンバーと比べ、厳しさ・評価軸は一貫しているか。
## 読むもの
- `202603-09/members/*/goals.md` の **評価サマリー表のみ**（6名分）
## 読まないもの
- `docs/hr/compensation.md`
- 他メンバーの上長評価本文全文（サマリー表で足りる）
## 出力フォーマット
```markdown
## TeamCalibration
### チーム横並び（サマリー）
| メンバー | 上長評価の傾向（1行） |
|---|---|
### 対象者の位置づけ
（厳しめ / 標準 / 甘め）
### 一貫性の指摘
- 今回だけ厳しい/甘い目標番号
- 評価軸のぶれ
### 修正提案
-
```
他者の詳細評価文は報告書に長く転載しない。
DevilsAdvocate
# Lens: DevilsAdvocate（Grok 専用）
## 問い
上長評価を信じすぎると危ない点は何か。甘すぎる/厳しすぎる両方向を検証。
## 入力
親が組み立てた **要約パックのみ**（ガイドライン全文・他メンバー全文は渡さない）。
## 出力上限（厳守）
- 目標別: **各3行以内**
- 総括: **5行以内**
## 出力フォーマット
```markdown
## DevilsAdvocate
### 総括（5行以内）
...
### 目標別
**No.X**（各3行以内）
- 上げるなら:
- 下げるなら:
### 見落としやすい文脈
（方針転換・体制変更・免責要素）
```
最終判断は相談役。点数の断定は「論点」として提示。
以上、これらの視点で複眼レビューすることで、根拠のある評価になっているか。一貫性を担保し、偏りがないか。あるいは、人格否定をしていないか。など、複数の目を通して自分の評価の妥当性を上げる試みをしております。
まとめ
ここまでやっても結局、評価を自分で書くステップはあるので大変ではあるのですが、定量指標やslack,google driveの情報などを定期的に取得して、評価の叩き台も自動的に出力されるよう、来期はもっとエージェントを働かせようと思います!
ちなみに、記事を書いていて気付きましたが、periodの部分、一括置換してから利用する方法も、格好悪いのでなんとかしようと思います。
こうやって、EM業務をAI agentに以上して、最終的にEMは責任を取るだけで開発作業に戻れるだけの時間を確保できると良いな〜と画策しております！
以上、お読みいただき、ありがとうございました!