人事評価にセキュリティ行動を組み込む方法

【注意】本記事は、「人事評価にセキュリティ行動を組み込む」ための一般的な考え方・設計手順を、現場エンジニアの実務に寄せて整理した情報提供です。実際の最適解は、業種（医療・介護・製造など）や委託範囲、システム構成、監査要件、既存規程、労務リスク、インシデント履歴などで大きく変わります。判断を誤ると、現場の反発や形骸化、運用コスト増、責任の押し付け合いを招き、結果的に被害最小化（ダメージコントロール）から遠ざかることがあります。具体的な案件・契約・体制で悩んだ場合は、株式会社情報工学研究所のような専門事業者に相談してください。

　

第1章：「また増えるのか…」セキュリティ施策が“現場の負債”になりがちな理由

セキュリティを「評価に入れる」と聞いた瞬間、現場が身構えるのは自然です。理由は単純で、現場がこれまで何度も“増えるだけのルール”を経験してきたからです。チェックリストが増え、承認フローが増え、監査対応が増え、そして本番障害の夜間対応は減らない。ここに評価まで足されると、「結局、責任だけ増えるのでは？」という疑念が先に立ちます。

頭の中の独り言は、だいたいこうです。

「また新しい運用？それ、誰がメンテするの？結局オレたちでしょ…」

この“モヤモヤ”を否定せず、むしろ出発点にするのが設計のコツです。評価制度は、制度だけを作っても動きません。現場が受け取るメッセージ（＝運用上の意味）まで含めて初めて「仕様」になります。つまり、評価に組み込むなら、評価項目そのものが「現場の負債」にならない設計が必要です。

---

現場の負債化が起きる典型パターンは、次の3つです。

• （1）目的が曖昧：「意識を上げる」だけで終わり、何が改善されるのかが不明確。

• （2）測り方が雑：「研修受講」「メール訓練クリック率」など、行動の表面だけが指標になる。

• （3）現場の可制御性が低い：脆弱性対応や権限管理など、個人の努力だけでは解けない問題を個人評価に押し込む。

特に（3）は危険です。セキュリティは多くが“システムの性質”で決まります。例として、脆弱性の修正が遅れる理由は「担当者の怠慢」よりも、依存関係の複雑さ、検証環境の不足、変更承認の遅さ、レガシーの密結合、停止できない業務要件など、構造要因が大半です。構造要因を放置したまま個人に責任を寄せると、現場は防衛的になり、報告が遅れ、インシデント対応の初動が鈍ります。結果として被害最小化（ダメージコントロール）から遠ざかります。

---

では、評価に入れる意味はどこにあるのか。ポイントは「個人の善意」を測るのではなく、「日々の業務の中で安全に寄せる行動」を増やすことです。セキュリティ行動とは、英雄的な行動ではなく、地味な“当たり前”の積み重ねです。たとえば、レビューで危険な設計に気づける、秘密情報をリポジトリに入れない、権限の棚卸しを回す、ログを残す、インシデント時に連絡系統を崩さない、などです。

この章の結論はシンプルです。「評価に入れる」のは、現場の負債を増やすためではなく、現場が“安全側に寄せやすいデフォルト”を作るため。この前提が共有されない限り、制度は反発され、形骸化します。

この章のまとめ

• 評価項目が増えると現場は「責任の増加」を疑うのが自然。

• 個人で制御できない構造要因を個人評価に入れると逆効果になりやすい。

• 狙うべきは「善意」ではなく「安全側に寄る日常行動」を増やすこと。

　

第2章：まずは評価対象をコード化する——セキュリティ行動を「期待仕様」に落とす

評価設計で最初にやるべきことは、精神論の排除です。「意識が高い」「慎重」「注意深い」といった形容詞は、評価者の主観に依存し、運用が崩れます。エンジニア的に言えば、評価項目は“テスト可能な仕様”に落とす必要がある、ということです。

ここでいう「コード化」とは、プログラムを書くという意味ではなく、観測可能な行動に分解し、期待値を明文化するという意味です。評価対象を「行動」「成果物」「証跡」に分けると設計が安定します。

---

たとえば、同じ「セキュリティに配慮する」でも、期待仕様は役割で変わります。開発者とSRE/情シスでは、手が届く範囲が違うからです。そこで、まずは役割ごとに“観測できる行動”を棚卸しします。

役割	評価対象にしやすい行動（例）	証跡（例）
開発（サーバサイド）	PRでの入力検証・認可の指摘、依存関係更新の提案、秘密情報を外に出さない運用	PRコメント、チケット、依存更新PR、シークレット管理設定
SRE/情シス	権限棚卸し、監査ログ整備、バックアップ・復旧訓練、インシデント連絡網の整備	権限レビュー記録、監査ログ設定、訓練レポート、手順書
PM/管理職	リスク受容の判断を明文化、セキュリティ作業に時間を割り当て、例外を放置しない	意思決定ログ、ロードマップ、承認記録、予算・工数配分

---

次に重要なのが「期待値の粒度」です。いきなり高難度の要求を置くと破綻します。そこで、期待仕様を3段階にするのが実務的です。

• 必須（Baseline）：やらないと事故確率が上がる“最低限”。

• 推奨（Standard）：通常運用で到達したい“標準”。

• 加点（Stretch）：改善活動・自動化など、組織能力を上げる“伸びしろ”。

この構造にしておくと、評価が「罰」になりにくくなります。Baselineは守るべき最低ライン、Standardは継続的に到達するライン、Stretchは挑戦できた人を称える枠、という分担ができるからです。

---

ここで、現場が安心できる一言を明文化しておくと、制度が回りやすくなります。

「セキュリティ行動は、個人の性格評価ではなく、職務上の実装・運用プロセスとして評価する」

性格評価に見えた瞬間、評価は炎上/クレーム対応になります。逆に、プロセス評価として見えれば、「仕様に沿って改善する」という納得が生まれます。

この章のまとめ

• 形容詞の評価は壊れる。観測可能な行動・成果物・証跡に落とす。

• 役割ごとに手の届く範囲が違うため、項目は分ける。

• Baseline/Standard/Stretchの3段階で、罰則型を避ける。

　

第3章：罰則型にしない——心理的安全性を壊さずに“行動”を促す前提

評価にセキュリティを入れるとき、一番やってはいけないのが「罰則型」です。罰則型とは、事故やヒヤリハットを個人の減点に直結させる設計です。短期的には緊張感が出ますが、長期的には報告が遅れます。報告が遅れれば、封じ込め（抑え込み）や被害最小化（ダメージコントロール）に必要な初動が遅れ、組織として弱くなります。

現場の本音はこうです。

「正直に言ったら、評価が下がる？じゃあ、言わない方が得だよね…」

そう感じるのは自然です。だから、制度側が“自然な行動”を悪化させる設計になっていないかを先に確認します。

---

罰則型を避けるための鉄則は、「結果（事故の有無）」ではなく「過程（行動・対応）」を評価することです。セキュリティ事故は確率事象で、個人の努力だけでゼロにはできません。一方で、事故が起きたときの検知・通報・切り分け・連携・再発防止は、行動として鍛えられます。評価すべきは後者です。

具体的には、次のように評価の対象を切り分けます。

評価しない（原則）	評価する（推奨）
インシデントが発生した事実そのもの	気づいたら早期に報告した／手順に沿って連携した
既存のレガシー制約で起きた遅延	制約を明文化し、例外管理・改善計画を提案した
他部署やベンダ要因の遅れ	依頼の証跡を残し、期限・優先度を合意形成した

---

次に、心理的安全性と相性が良いのが「学習」の扱いです。セキュリティは、正解が固定されにくい領域です。脆弱性、攻撃手法、依存関係、運用の抜け道は日々変わります。だからこそ、評価項目に「学習（アップデート）を組み込む」ことは理にかなっています。ただし、ここでも罠があります。

「資格を取れ」「研修を受けろ」を評価の中心に置くと、受講が目的化します。受講は大事ですが、受講＝安全ではありません。評価に入れるなら、学習の“出力”を確認できる形が望ましいです。

• 学んだ内容を、手順書・チェックリスト・CI設定・権限申請フローなどに反映した

• チームに共有し、運用に落とした（例：レビュー観点の更新、オンコール手順の更新）

• 例外があるなら理由と期限を明文化し、リスクを透明化した

---

最後に、制度を“燃えにくく”するための運用上のコツを1つ。評価項目は「できた／できない」の二値に寄せすぎないことです。二値化はラクですが、現場にはグレーが多い。そこで「成熟度（maturity）」として段階評価にします。段階評価なら、現場は「次に何をすれば良いか」が分かり、ブレーキ（歯止め）ではなく改善の道筋になります。

この章のまとめ

• 罰則型は報告を遅らせ、初動を鈍らせる。結果ではなく行動・対応を評価する。

• 学習は重要だが、受講の数ではなく“運用への反映”を評価対象にする。

• 二値化より成熟度の段階評価が、改善に繋がりやすい。

　

第4章：Goodhartの法則と抜け道——KPIを置いた瞬間に起きるゲーム化

セキュリティ行動を評価に入れるとき、多くの組織が「数値化」に寄せたくなります。数値は比較しやすく、報告しやすく、上層にも説明しやすいからです。ただし、ここに有名な落とし穴があります。いわゆるGoodhartの法則（指標が目標になると、指標として機能しにくくなる）です。これはセキュリティでも例外ではありません。

現場の独り言はこうなります。

「その数字を下げれば“良い”んでしょ？じゃあ、数字が出ないようにすればいいじゃん…」

この反応は悪意というより、生存戦略です。評価や報酬に紐づいた瞬間、人は指標を“最適化”します。ここを見誤ると、制度がセキュリティを強くするどころか、見かけだけ整える方向に誘導します。

---

セキュリティ評価でゲーム化が起きやすい代表例を挙げます。

• フィッシング訓練のクリック率：クリック率を下げることが目的化し、報告や教育の質が置き去りになる。極端には「怪しいメールを全部無視する」行動が強化され、業務に支障が出る可能性がある。

• 脆弱性件数（未対応数）：件数を減らすためにスキャン範囲を狭める、例外登録を増やす、深刻度の見積りを下げるなどの“数字の操作”が起きやすい。

• インシデント件数：件数が少ないほど良いとすると、報告が抑制される。結果として検知が遅れ、被害最小化（ダメージコントロール）に不利になる。

---

では、数値を使うのはダメなのか。そうではありません。ポイントは、「単一のKPIで評価しない」「数値を“行動の入口”にする」です。実務的には、以下のような設計が現場に馴染みやすいです。

悪い例（ゲーム化しやすい）	良い例（行動に接続する）
インシデント件数が少ないほど高評価	検知〜一次報告までの時間、手順の遵守、再発防止の実装（ポストモーテムの質）
未対応脆弱性件数をゼロにする	期限内に優先度付けして対応方針を決め、例外は期限とリスクを明文化して承認を取る
研修受講回数をKPIにする	学習内容を運用・設計・CI設定・手順書に反映した証跡を評価

---

さらに、評価項目の「抜け道」を減らすには、評価者と被評価者が同じ解釈を持てるように、想定される“ズル”を先に言語化して封じるのが効果的です。ここは少し嫌な作業に見えますが、制度を守るためには必要です。

• 例外登録を増やして数値を下げる → 例外は期限・理由・代替策・承認者を必須にし、期限切れを評価でマイナスにする

• スキャン範囲を狭める → 対象資産の棚卸し（範囲）を評価に含め、範囲変更はレビュー対象にする

• 報告を遅らせて件数を抑える → 報告遅延を“重大リスク”として扱い、早期報告を評価する

結局、評価制度は「人を信用しない」ためではなく、制度が人を悪い最適化に誘導しないように、温度を下げる（クールダウン）設計をすることが目的です。

この章のまとめ

• 単一KPIはゲーム化しやすい。指標は“行動の入口”として使う。

• 結果（件数）より、過程（対応・証跡・再発防止）を評価に寄せる。

• 想定される抜け道を明文化し、例外管理とレビューで歯止めをかける。

　

第5章：開発者向けの評価設計——PR・依存関係・脆弱性対応を日常業務にする

開発者のセキュリティ行動を評価に入れるなら、「セキュリティ専任がやる仕事」を丸投げする形にしてはいけません。現場が壊れます。評価に入れる価値があるのは、開発プロセスの中で自然に出る“安全側の判断”です。つまり、PR、レビュー、設計、依存関係更新、リリース手順といった日常に埋め込むのが基本です。

現場の本音はこうです。

「セキュリティ“だけ”やる時間、どこにあるの？スプリントは埋まってるんだけど…」

だから、評価設計は「追加タスクを増やす」のではなく、既存タスクの質を安全側に寄せる設計にします。

---

開発者向けの評価項目は、次の3系統に分けると運用しやすいです。

• （A）設計・レビューでの安全側判断：認可、入力検証、ログ設計、秘密情報の扱い、エラーハンドリングなど

• （B）依存関係とビルドの健全性：依存更新、SBOM/ロックファイル、署名、再現可能ビルドなど

• （C）脆弱性対応の運用：優先度付け、期限、例外管理、修正の安全なリリース

---

ここで重要なのが、「評価しやすい証跡」を前提にすることです。口頭で“頑張りました”は揉めます。逆に、日常の開発ツールに残るなら、評価は穏やかになります。代表的な証跡は以下です。

行動	証跡	評価の観点
PRレビューでの指摘	PRコメント、レビュー承認履歴	具体性（再現・根拠）、安全側判断、代替案の提示
依存関係更新	依存更新PR、CHANGELOG、検証ログ	リスク評価、影響範囲、ロールバック設計
脆弱性対応	チケット、期限、例外申請、リリースノート	優先度判断、期限遵守、例外の透明性

---

評価項目を“実装可能な仕様”にするために、例として簡易マトリクスを置きます。これは組織の状況に合わせて調整が必要ですが、考え方としては次のようになります。

• Baseline：秘密情報をコード・ログに残さない、重大な認可抜けを放置しない、修正はレビューを通す

• Standard：依存更新を定常化し、期限・例外の運用を回す、重要なログを残す

• Stretch：CIで静的解析やシークレット検知を整備、レビュー観点のテンプレ化、運用負債の削減

---

注意点として、個人評価だけで完結させないことが大切です。依存更新や脆弱性対応は、個人の努力だけでなく、リリースプロセス、検証環境、QA、プロダクト方針に依存します。そこで、評価には「個人の行動」だけでなく、チームとしての改善提案・合意形成も含めると、現場の納得感が増します。

この章のまとめ

• 開発者評価は、追加タスクではなく“日常の開発プロセス”に埋め込む。

• PR/依存更新/脆弱性対応は、証跡が残りやすく、評価設計に向く。

• 個人の可制御性を超える部分は、チーム改善や合意形成として評価に接続する。

　

第6章：SRE/情シス向けの評価設計——権限・監査ログ・訓練を回して“事故対応の温度”を下げる

SREや情シスのセキュリティ行動は、「守り」だけに見えがちですが、実際はサービス継続に直結します。ここでの評価設計の目的は、理想論で縛ることではなく、インシデント時の混乱を抑え込み、対応の温度を下げる（クールダウン）ための準備行動を、日常の運用に組み込むことです。

現場の独り言はこうです。

「事故が起きてから“なんでログないの？”って言われても、昔からの構成なんだって…」

この本音を前提に、評価項目は「いまの制約の中で前に進めたか」を測れる形にします。ゼロから理想状態にするのではなく、段階的に成熟させる設計です。

---

SRE/情シスの評価項目は、次の4系統に分けると整理しやすいです。

• （A）アクセス権と認証：最小権限、棚卸し、退職・異動対応、特権ID管理

• （B）監査ログと可観測性：ログの取得・保全、改ざん耐性、検索性、アラート

• （C）バックアップと復旧：バックアップの成功確認、復旧テスト、RTO/RPOの合意

• （D）訓練と初動：連絡網、手順書、机上演習、ポストモーテム運用

---

評価を揉めにくくするため、ここでも証跡を基準にします。

行動	証跡	注意点
権限棚卸しの実施	棚卸し台帳、レビュー記録、是正チケット	“実施した”だけでなく是正の追跡を含める
監査ログの整備	ログ設定、保存期間、保全手順、アクセス制御	個人情報・機密情報の取り扱いと最小化に配慮
復旧テスト	復旧手順書、実施レポート、改善事項	“バックアップがある”ではなく“戻せる”を確認
インシデント訓練	演習シナリオ、参加者、振り返り、改訂履歴	責める場にせず、改善点を拾う場にする

---

ここでの最大の注意点は、SRE/情シスの評価が「現場の便利屋」化しやすいことです。権限の管理やログの整備は、全社の協力が必要です。たとえば退職・異動の情報が遅れれば権限は残りますし、プロダクト側がログ出力をしなければ監査ログだけでは追えません。よって評価は「全部やれ」ではなく、合意形成と仕組み化に寄せます。

評価の言い回しとしては、次のようにすると揉めにくいです。

• 「権限棚卸しを完璧にした」ではなく「棚卸しのサイクルを回し、是正を追跡できる状態にした」

• 「監査ログを全部揃えた」ではなく「重要資産から優先度を付け、保全・検索・アクセス制御を実装した」

• 「復旧を保証した」ではなく「RTO/RPOの前提を合意し、復旧テストでギャップを明確化した」

これらは、事故対応の場を整える（場を整える）ための行動です。評価に入れる価値はここにあります。

この章のまとめ

• SRE/情シスの評価は、事故時の混乱を抑え込む準備行動を日常に組み込むことが狙い。

• 権限・ログ・復旧・訓練は、証跡が残る形にして評価を安定させる。

• 「全部やれ」ではなく、合意形成と仕組み化（サイクル化）を評価に接続する。

　

第7章：証跡の取り方を整える——ログ・チケット・レビュー記録を“自動で残す”

セキュリティ行動を評価に組み込むとき、運用が破綻しやすい原因のひとつが「証跡が残らない／集められない」です。証跡が薄いと、評価は主観に寄り、現場は納得しにくくなります。逆に、普段の開発・運用ツールに“自然に残る”形にすると、評価が静かに回ります。ここで重要なのは、現場に新しい「提出物」を増やさないことです。既存のツール（Git、チケット、CI、IAM、監視）から、必要最小限の証跡が取れるように設計します。

現場の本音はこうです。

「評価のために、また別の報告書を書くの？それが一番つらい…」

そう感じるのは自然です。だからこそ、“提出”ではなく“自動で残る”に寄せます。

---

証跡は大きく分けると、次の3種類に整理できます。

• （1）プロセス証跡：PRレビュー、承認履歴、チケットのステータス遷移、変更管理の記録

• （2）技術証跡：CI結果、静的解析結果、依存関係更新PR、設定差分（IaCの差分など）

• （3）運用証跡：監査ログ、アラート対応履歴、復旧テスト結果、訓練の振り返り

---

次の表は、評価対象になりやすい行動と、現場が無理なく残せる証跡の対応例です（組織のツール構成に合わせて調整が必要です）。

行動（評価対象）	証跡の置き場	運用上の注意点
PRで安全側の指摘をした	PRコメント、レビュー履歴	“指摘数”ではなく具体性・再現性・代替案の有無を見る
依存関係を更新し、リスクを説明した	依存更新PR、チケット、リリースノート	例外や見送りは理由・期限・影響範囲を残す
権限棚卸しと是正を回した	棚卸し台帳、是正チケット、承認記録	“棚卸し実施”だけでなく是正のクローズまで追う
監査ログの保全・検索性を改善した	ログ設定、保存期間、アクセス制御、手順書	個人情報・機密の最小化、閲覧権限の最小化をセットで

---

証跡設計で避けたいのは「ログを集めればOK」という発想です。ログは多ければ良いわけではなく、目的が曖昧だと、保管コストと運用負債が増えるだけです。たとえば監査ログは、保存期間、参照権限、改ざん耐性、検索性、そして“いざという時に使えるか”が重要で、単に出力しているだけでは不十分です。

---

また、評価にログを使う場合は、プライバシーや労務リスクにも配慮が必要です。一般論として、個人を過度に監視する設計は反発を招き、制度が炎上/クレーム対応になります。そこで現実的には、次の方針が揉めにくいです。

• 評価は「個人の監視」ではなく「プロセスの遵守・改善」を中心にする（例：手順に沿った対応、証跡の整備）

• 必要以上に個人行動を追跡しない（最小限のデータ、最小限の権限）

• 目的・保存期間・閲覧権限を明文化し、運用ルールとして合意する

証跡が整うと、評価は“言った言わない”から離れ、現場の温度を下げる（クールオフ）方向に働きます。

この章のまとめ

• 評価が揉める原因の一つは証跡不足。提出物を増やさず、既存ツールから自動で残る設計にする。

• 証跡はプロセス・技術・運用に分けると整理しやすい。

• ログは“多ければ良い”ではない。目的、権限、保存期間、使える形をセットで設計する。

　

第8章：評価シート実装例——期待行動×頻度×難易度×影響度のマトリクス

「評価に入れる」と決めても、実装が曖昧だと運用は回りません。ここでは、現場で扱いやすい“評価シートの骨格”を、一般化した形で示します。ポイントは、セキュリティを一枚岩の能力として扱わず、期待行動を分解し、重み付けの根拠を持たせることです。重み付けがないと、「同じ1件でも価値が違う」問題が起きます。

---

実務上使いやすい軸は、次の4つです。

• 期待行動：何をやるのか（観測可能な行動）

• 頻度：どれくらいの頻度で発生するか（毎週/毎月/四半期など）

• 難易度：実行に必要な専門性・調整コスト・検証コスト

• 影響度：実行できた時にリスクがどれだけ下がるか（被害最小化に効くか）

---

以下は例です（点数や区分は組織の成熟度に合わせて調整が必要です）。表頭と表側は指定どおり #eeeeee で網掛けにしています。

役割	期待行動	頻度	難易度	影響度	証跡
開発	PRで認可・入力検証の観点をレビューに含める	高	中	中	PRコメント、レビュー履歴
開発	依存関係更新を継続し、例外は期限付きで明文化	中	中	高	依存更新PR、例外チケット
SRE/情シス	権限棚卸しサイクルを回し、是正を完了させる	中	高	高	棚卸し台帳、是正チケット
SRE/情シス	復旧テストを実施し、ギャップを改善計画に落とす	低	高	高	復旧レポート、手順書改訂
PM/管理	例外（先送り）を放置せず、期限・リスクを意思決定ログに残す	中	中	中	意思決定ログ、承認記録

---

このマトリクスの狙いは、「何でもかんでもセキュリティ」として同列に扱わないことです。たとえば、頻度が低くても影響度が大きい行動（復旧テスト、訓練、権限是正など）は、評価上の重みを持たせる必要があります。一方で、頻度が高い行動（レビュー観点の徹底など）は、習慣化できれば組織全体の安全側判断を底上げします。

---

もう一つのコツは、評価を“個人の達成”だけに固定しないことです。セキュリティ行動は、他部署の協力やプロダクト判断が必要になる場合があります。そこでシートには、次のような欄を作っておくと運用が安定します。

• 阻害要因（制約）：なぜ進まないのか（例：検証環境不足、停止できない、承認待ち）

• 次の一手：何をすれば前に進むか（例：段階導入、範囲限定PoC、合意形成）

これがあると、評価は“減点”ではなく、現場の課題を可視化して前に進めるためのブレーキ（歯止め）になります。

この章のまとめ

• 評価は期待行動を分解し、頻度・難易度・影響度で重み付けする。

• 影響度が大きいが頻度が低い行動（復旧テスト等）を埋もれさせない。

• 阻害要因と次の一手をセットで書ける形にすると、制度が前向きに回る。

　

第9章：1on1で回すフィードバックループ——行動を学習に変える運用

評価制度は「年1回の査定イベント」になった瞬間に壊れやすくなります。セキュリティ行動は、日々の小さな判断の積み重ねで、四半期〜半年で積もります。だから、評価に組み込むなら、短いサイクルのフィードバックが必要です。ここで現実的に効くのが1on1です。1on1は“説教の場”ではなく、行動を学習に変える場として設計します。

現場の独り言はこうです。

「結局、評価の時だけ言われても、何を変えればいいか分からないんだよな…」

これを避けるために、1on1では「次に何を変えるか」を具体化します。

---

1on1で扱うテーマは、次の3点に絞ると運用が続きやすいです。

• （1）今月の“安全側判断”：レビューや運用で、どんな安全側の判断ができたか

• （2）詰まった点（阻害要因）：構造要因で進まない点は何か

• （3）次の一手：小さく前進できるアクションは何か（段階導入、範囲限定、テンプレ化など）

---

評価と相性が悪い1on1のやり方は、「できていない点の列挙」です。これをやると、場が荒れ、報告が萎縮します。代わりに、事実（証跡）ベースで会話します。たとえば次のような進め方が現場に馴染みます。

1. 証跡を見ながら、実際にやった行動を確認する（PR、チケット、手順書改訂など）

2. その行動が、どのリスクをどれだけ下げたかを言語化する（影響度の確認）

3. 詰まりの原因が個人要因か構造要因かを切り分ける

4. 構造要因なら、合意形成やスコープ調整など“解ける形”に落とす

---

ここで重要なのは、セキュリティを「正しさの競争」にしないことです。現場に必要なのは、正論ではなく、運用として回る“仕組み”です。1on1で「できたこと」を拾い、「詰まり」を共有し、「次の一手」を小さく決める。これを回すと、評価は心理的圧力ではなく、改善のエンジンになります。

---

また、1on1の記録は“監視”ではなく“再現性”のために残します。評価の透明性が高いほど、不信感は減ります。記録は最小限で構いません。たとえば、以下のように短く残すだけでも十分に機能します。

• 今月の行動（証跡リンク）

• 詰まり（原因仮説）

• 次の一手（期限と担当）

この運用ができると、インシデント対応の場面でも「誰が悪い」ではなく「次に同じことが起きないようにどう直すか」に議論が収束しやすくなります。

この章のまとめ

• 評価を年1回イベントにすると形骸化しやすい。短いサイクルのフィードバックが必要。

• 1on1は“説教”ではなく、証跡ベースで行動→影響→次の一手に落とす場にする。

• 記録は最小限でよい。透明性が上がるほど不信感が減り、議論が収束しやすい。

　

第10章：帰結——セキュリティは「個人の善意」ではなく「組織のデフォルト設定」にする

ここまでの話を、最後に一本の線にまとめます。人事評価にセキュリティ行動を組み込む目的は、「誰かを縛る」ことでも「ミスを責める」ことでもありません。現場が疲弊しがちな理由は、セキュリティが“追加タスク”として降ってきて、しかも結果責任だけが個人に寄るからです。だから設計の焦点は、個人の善意や根性ではなく、組織として安全側に寄りやすいデフォルトを作ることに置くべきです。

エンジニア的に言えば、これは「運用で守れる仕様」にする話です。仕様が曖昧なら、実装はブレる。テスト不能なら、品質は担保できない。評価も同じで、観測可能な行動に落ちていない評価は、運用が壊れます。

---

“デフォルト設定”に寄せるときの要点は、次の4つに集約できます。

• （1）評価対象をコード化する：形容詞ではなく、行動・成果物・証跡に落とす（第2章）。

• （2）罰則型を避ける：結果（事故の有無）ではなく、行動（早期報告・手順遵守・再発防止）を評価する（第3章）。

• （3）単一KPIで縛らない：Goodhartの法則でゲーム化する前提に立ち、指標は“行動の入口”として使う（第4章）。

• （4）証跡を自動で残す：提出物を増やさず、普段のツールに残る形で評価を安定させる（第7章）。

---

ここで一番大事なのは、「理想の正しさ」より「現場で回る現実」です。たとえば、脆弱性対応が遅いときに、本当の原因が“個人の怠慢”であるケースは多くありません。依存関係の密結合、検証環境不足、変更承認の遅れ、止められない業務要件、移行コストの現実——そういう構造要因がほとんどです。そこを無視して個人評価に押し込むと、場が荒れて、報告が遅れ、結果的に被害最小化（ダメージコントロール）から遠ざかります。

逆に、「構造要因を可視化して前に進めた人」を評価できると、文化が変わります。例外を期限付きで明文化する、手順書を改訂する、訓練を回してギャップを出す、依存更新を定常化する。こうした地味な行動が、組織の安全度を上げます。

---

最後に、読者が明日から取りやすい“小さな一歩”を置きます。いきなり完璧を目指すと失速します。まずは次の順で進めるのが現実的です。

1. 役割（開発／SRE・情シス／PM・管理）ごとに、評価できる行動を10個だけ書き出す

2. そのうち3個をBaseline（最低限）として合意し、証跡の置き場を決める

3. 四半期だけ試して、抜け道（ゲーム化）と運用負債が出る箇所を直す

この「試して、直す」サイクルが回り始めた時点で、セキュリティは個人の善意から離れ、組織のデフォルト設定になり始めます。

---

ただし、ここまで述べたのは一般論です。実際の制度設計では、労務・評価制度の規程、監査要件、業務委託範囲、システム構成（クラウド／オンプレ、ID基盤、ログ基盤、運用体制）、そして過去のインシデントの性質で、最適解が変わります。たとえば「何を証跡にするか」ひとつ取っても、ログの取得範囲や保存期間、閲覧権限、個人情報の扱いは、組織によって設計が分かれます。

もし、具体的な案件・契約・システム構成・体制の前提が絡み、「どこまでを個人評価にし、どこからを組織改善にするべきか」で迷っているなら、株式会社情報工学研究所のような専門事業者に相談し、現場負担とリスク低減のバランスが取れた“実装可能な仕様”に落とし込むことをおすすめします。

この章のまとめ

• 評価の目的は「縛る」ではなく、現場が安全側に寄りやすいデフォルトを作ること。

• 罰則型・単一KPI・証跡不足は、制度を炎上/クレーム対応にしやすい。

• 一般論には限界がある。個別案件は体制・監査・構成に合わせた設計が必要。

　

補足：現在の主要プログラム言語ごとの注意点（セキュリティ行動を評価に落とす観点）

最後に、現場でよく使われるプログラム言語ごとに「起きやすいリスク」と「評価に落としやすい行動（証跡）」を整理します。ここでの狙いは、言語の優劣ではありません。言語ごとに事故のパターンが違うため、同じ評価項目を一律に当てはめると不公平になりやすい、という点を押さえるためです。

また、実際のリスクはフレームワーク、ライブラリ、実行環境、運用（CI/CD、権限、監査）で大きく変わります。以下はあくまで一般的な注意点であり、個別案件では株式会社情報工学研究所のような専門家と一緒に「現場で回るチェックポイント」に落とすのが安全です。

---

言語	注意点（起きやすいリスク）	評価に落としやすい行動（例）	証跡（例）
C / C++	メモリ安全性（バッファ境界、Use-after-free等）、未定義動作、手動メモリ管理に起因する脆弱性が起きやすい	境界チェック・安全APIの採用、静的解析/サニタイザ導入、危険関数の禁止・置換	ビルド設定、CIログ、静的解析レポート、レビュー指摘
Rust	メモリ安全性は高いが、unsafe領域、依存関係、シリアライズ/デシリアライズ、ロジックミスは残る	unsafe利用のレビュー基準、依存更新・監査、入力検証、権限境界の明確化	unsafe箇所のレビュー記録、依存更新PR、セキュリティレビューコメント
Go	並行処理の誤用（競合、デッドロック）、HTTP実装の慣れによる設定漏れ、依存関係の供給網リスク	競合検知の運用、タイムアウト/リトライ設計の明文化、依存関係の固定・更新運用	CIの競合検知ログ、設計レビュー、依存管理の差分
Java	依存ライブラリ由来の脆弱性、設定ミス、デシリアライズやテンプレート処理、認可設計の漏れ	依存更新の定常化、危険なデシリアライズ回避、認可/入力検証のレビュー観点テンプレ化	依存更新PR、チケット、レビュー観点のドキュメント
C# (.NET)	設定・シリアライズ周りの落とし穴、認可・権限境界の漏れ、依存関係の脆弱性	認可ポリシーの明文化、危険な設定の棚卸し、依存更新の運用	設定差分、PRレビュー、依存更新記録
Python	動的実行（eval等）の誤用、依存関係の供給網リスク、機密情報の取り扱い、入力検証不足	危険APIの禁止、依存固定（ロック）と更新手順、秘密情報の管理（環境変数/秘匿ストア）	CI設定、依存ロックファイル、シークレット管理の設定
JavaScript / TypeScript	依存関係の供給網リスク、XSS/CSRFなどWeb特有の攻撃、ビルド/配布経路のリスク	依存更新・監査の習慣化、入力/出力のエスケープ、CSP等の防御設定、ビルド成果物の検証	依存更新PR、セキュリティヘッダ設定、レビュー指摘
PHP	SQLインジェクション、XSS、ファイルアップロード周り、レガシー運用での更新停滞	プリペアドステートメント徹底、出力エスケープ、アップロード検証、更新計画の合意形成	コードレビュー、セキュリティテスト結果、更新計画ドキュメント
Ruby	依存関係の脆弱性、設定ミス、入力検証・認可の抜け、テンプレート周り	依存更新の定常化、認可のレビュー観点整備、セキュリティ設定の棚卸し	依存更新PR、設定差分、レビューコメント
SQL	権限設計ミス、過剰権限、監査不足、クエリによる情報露出、ログの扱い	最小権限、権限棚卸し、監査ログ整備、機密データのマスキング方針	権限台帳、監査ログ設定、レビュー記録
Swift / Kotlin	モバイル特有の機密情報保管、証明書ピンニング等の通信設定、ログ露出、依存関係	安全なストレージ利用、通信設定のレビュー、ログの最小化、依存更新	コードレビュー、設定差分、テスト結果

---

この補足から読み取れる実務的な結論は、次の2つです。

• 言語・領域ごとに“事故のパターン”が違うため、評価項目は役割と技術スタックに合わせて調整すべき（一律の指標は不公平になりやすい）。

• 評価に落としやすいのは「証跡が自然に残る行動」であり、提出物を増やすほど制度は形骸化しやすい。

もし、自社のスタック（言語、フレームワーク、クラウド、ID基盤、ログ基盤）や、監査・BCP・委託範囲などの条件が絡み、「どの行動をBaselineにし、どの証跡をどこまで残すべきか」で迷う場合は、一般論のまま進めると運用負債になりがちです。具体条件に合わせて“現場で回る仕様”へ落とし込むために、株式会社情報工学研究所のような専門家へ相談し、設計・運用・証跡・評価の整合を取ることをおすすめします。