「評価制度が複雑すぎる」ADHDエンジニアのための評価基準の簡略化

結論（要約）：評価は「達成（Delivery）」「技術力・品質（Craft）」「協働・影響力（Impact）」の3軸に絞り、各軸は最大3段階の具体的な行動指標で評価することが最も実用的です。小さな目標と頻繁な短いフィードバック、書面化された期待値がADHD特性（実行機能の障害、衝動性、過集中）を補いやすくなります。

導入で感じる挫折感は多くのADHDエンジニアが共通で、私自身も評価項目が20個を超えるシートに混乱し、何を優先すべきか分からなくなった経験があります。そこから「軸を減らす」「期待を明文化する」「評価頻度を上げる」という実践で改善した実例を交えながら、現場で使える具体的手順を紹介します。

要点まとめ

以下は本記事で提案する主要方針の要点です。まず目的と期待値を明確にし、評価軸を三つに集約し、短く具体的なルーブリックを作ります。その上で頻繁なマイクロフィードバックと合理的配慮（締切の柔軟化、集中時間の保証など）を取り入れます。

• 評価軸を「Delivery」「Craft」「Impact」の3つに限定する
• 各軸は最大3段階の行動指標で定義し、数値化は最小限にする
• 月次の短い1on1で進捗と次のアクションを確認する習慣を作る
• ADHD向けの配慮（集中ブロック、明文化されたタスク、デッドラインの分割）を評価基準に組み込む

以上の方針は、複雑な評価制度のストレスを減らし、実際の成果と成長を正しく反映させるための設計です。

評価が複雑で困る具体的な問題点（経験談と例）

複雑な評価制度は次のような現場の問題を生みます。まずは問題を整理します。

私の例：あるプロジェクトで評価シートに「コード品質」「テストカバレッジ」「ドキュメント」「ナレッジ共有」「メンターリング」「スプリント貢献度」「プロダクト理解」「顧客対応」など20近い項目がありました。優先度が書かれておらず、締切と並行して複数項目を同時に満たすことを求められ、結果的に何も中途半端になってしまいました。ADHDの私には、何を先に手を付けるか判断すること自体が負荷になりました。

この問題点を整理すると、次の3つに集約できます。期待値の不明瞭さ、評価基準の多さとあいまいさ、評価タイミングの遅さ（半年に一回など）。それぞれが実行の妨げになり、生産性低下と精神的負担につながります。

提案：3軸モデルと具体的ルーブリック

ここでは評価の簡略化案を提示します。各軸に短い行動指標を設け、評価は「期待未達」「期待通り」「期待超過」の3段階に絞ります。定性的なコメントよりも具体的な行動が分かる文言にします。

まず軸の定義：

• Delivery（納期・成果物の達成）— タスク完遂、スコープ管理、期限遵守
• Craft（コード・設計・品質）— テスト、設計判断、リファクタリングの質
• Impact（協働・影響）— チームへの貢献、知見共有、顧客価値への寄与

以上の軸はエンジニアリング現場で最も直接的に成果を測れるため、ADHDの人でも何に注力すべきか判断しやすいです。

具体的ルーブリックの例（Delivery軸の一例）：
期待未達：タスクが納期に間に合わず、進捗報告も不十分でリスケが頻発する
期待通り：タスクを計画通りに完了し、障害があれば早期に報告・調整する
期待超過：スコープ変動を見越した見積もり修正や自動化で繰り返しの負荷を軽減する提案を行う

このように行動ベースで表現すると、ADHDの実行障害がどの段階で影響しているか判断しやすくなります。

実装手順（マネージャー向けとエンジニア向け）

ここでは実際に導入する際のステップを示します。導入前に期待を共有し、トライアル期間を設けることが重要です。

私が導入した手順（実例）：チームで2ヶ月間トライアルを行い、毎週の1on1で各軸について「今週の1つの小さな改善アクション」を決め、月次でルーブリックの妥当性を調整しました。結果として、評価時の主観的判断が減り、自己改善が可視化されました。

推奨手順（簡潔）：

• 評価軸とルーブリックを文面化して全員に配布
• 短期（1〜2ヶ月）トライアルを実施し、フィードバックで調整
• 月次の短い1on1で進捗と次の小目標を決定
• 半年ごとにルーブリックの運用レビューを行う

導入時の判断基準としては、チームの人数やプロジェクトの変動性を考慮してください。小規模で頻繁に変わる開発では本案が有利です。大規模組織で法的要件や報酬査定に厳格さが求められる場合は、簡略化と既存要件の折衷が必要です。

メリット

簡略化の主な利点を示します。導入メリットを明確にすることで意思決定がしやすくなります。

簡略化のメリット（実例含む）：私のチームでは評価軸を3つに減らしたことで、開発者が自分の優先度を明確にでき、スプリントの終盤での混乱が減少しました。成果が見えやすくなったため、モチベーションも上がりました。

• 期待が明確になり、判断負荷が減る
• フィードバックが具体的になり改善サイクルが速くなる
• ADHD向けの配慮が導入しやすくなる

メリットの判断基準：評価の透明性がチームで高まり、欠勤やバーンアウトが減るかをKPIとして3〜6ヶ月で確認してください。

デメリット

簡略化にはトレードオフがあります。公平性や詳細なスキル測定が犠牲になる可能性があります。

私の経験：一時的にスペシャリストの微妙な差異（例えばアーキテクトとしての設計力の差）を評価しにくくなり、昇進判断で補助手続きが必要になりました。

• 専門性の細かい評価が難しくなる
• 数値化指標が少ないと悪意ある自己申告に弱くなる
• 大規模組織向けの昇進要件には追加の評価が必要

選択基準：小〜中規模チームでは簡略化の恩恵が大きい一方で、報酬や昇進が厳格に管理される場合は補助的な評価手段（コーディング課題やメンター評価）を残すべきです。

向いている人 / 向いていない人

簡略化が適合する人と合わない人を示します。自身の状況に合わせて判断してください。

向いている人の特徴（例）：プロジェクト単位で仕事を完結させるエンジニア、締切が頻繁に変わるプロダクト開発チーム、ADHDなどで優先順位の明確化を必要とする人。

向いていない人の特徴（例）：非常に専門的な役割で定量的なスキル測定が昇進に直結する人、大企業で法的・評価制度上の細分化が要求される場合。

比較：複雑な評価 vs 3軸簡略化

ここでは主な比較点を提示します。選択に迷うときの判断基準を示します。

複雑な評価は「詳細なスキル把握」と「職務記述との整合」に優れる一方、運用コストが高く、ADHDのエンジニアには負荷が大きいです。3軸簡略化は「運用の軽さ」と「明快さ」で勝りますが、専門性の微差を捉えにくい点がデメリットです。

判断基準としては、組織のサイズ、昇進判断の厳しさ、チームの変化頻度を考慮してください。頻繁に要件が変わるチームでは簡略化を優先すべきです。

チェックポイント

評価運用中に確認すべき重要点を挙げます。導入後の調整に役立ててください。

以下の項目は導入後1〜3ヶ月ごとにチェックしてください。

• チームメンバーが自分の優先度を説明できるか
• 月次1on1で小さな改善アクションが出ているか
• 評価に関する不満が同じパターンで出ていないか

これらをチェックし、問題があればルーブリックの文言修正や評価頻度の増加を検討してください。

行動のポイント

短期的にできるアクションを具体的に示します。すぐ実行できる手順です。

私が薦める初動3ステップは次の通りです。まず今ある評価シートから項目を整理して3軸にマッピングします。次に各軸について最大3つの具体的行動指標を作り、チームに共有します。最後に1ヶ月のトライアルを行い、毎週の短い1on1で調整します。

• 既存評価項目を3軸へマッピングする（1日）
• 各軸で「期待未達・期待通り・期待超過」を文面化する（1週間）
• 1ヶ月トライアル＋週次1on1で微調整する（1ヶ月）

判断基準：トライアル終了時に、チームの主観的満足度と生産性（プルリク承認速度、リリース頻度）を比較して継続可否を決定してください。

結論と次の一手

評価制度の簡略化は、特にADHDのエンジニアにとって大きな効果があります。ポイントは「軸を絞る」「行動指標を具体化する」「フィードバック頻度を上げる」ことです。短期的には運用負荷の軽減と心理的負担の低下、中長期ではスキル成長の可視化につながります。

まずは現行評価の項目を3軸にマッピングすることから始めてください。1ヶ月のトライアルで実効性を検証し、必要に応じて補助的な専門評価を導入するのが現実的です。

よくある質問

Q. 評価を3軸にすると昇進や報酬決定が曖昧になりませんか？

簡潔に言うと、重要な専門性が評価基準に直結する場合は補助的な評価（技術面接、プロジェクトレビュー、同僚評価）を併用してください。基本評価は3軸で運用し、昇進時のみ詳細評価を追加するのが現実的です。

Q. ADHDの自分はどうやって自己管理すればいいですか？

短い期限でタスクを分割し、1週間単位で「必ず完了する1つ」を設定してください。マネージャーと合意した「集中ブロック」をカレンダーに入れると過集中と散漫の両方をコントロールしやすくなります。

Q. 週次の1on1が負担になりませんか？

1on1は長時間にする必要はありません。10〜20分で「今週の1つの改善アクション」と「障害の早期共有」を確認するだけで十分効果があります。短期の習慣化が重要です。

Q. 定量的な指標が少ないと不公平になるのでは？

不公平を避けるために、評価の根拠となる事実（PRマージ数ではなく「見積もり精度」「重大バグ件数の低減」「自動化で削減した時間」など）を記録する習慣を付けてください。数値は目的の補助として使います。

Q. チームに提案する際の説得ポイントは？

運用コストが減ること、評価時の主観が減ること、ADHDを含む多様な働き方が尊重される点を強調してください。トライアルで短期のKPI（レビュー時間、ブロッカー数）改善を示すと説得力が出ます。

投稿 ADHDエンジニア向け：評価基準の簡略化ガイドと実践方法 は ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ に最初に表示されました。