メインコンテンツまでスキップ

セキュリティ人材マップの作り方

はじめに​

サイバーセキュリティ組織を立ち上げたものの、どこか中途半端に見える場合、最初に作るべきものは「全員の資格一覧」ではない。まず必要なのは、自組織にどの役割が存在し、どのタスクが自走でき、どこが未整備なのかを見える化するマップである。

本稿では、デジタルスキル標準（DSS）ver.2.0、サイバーセキュリティ人材フレームワーク2026、NIST SSDFを参照しながら、セキュリティ組織の現在地評価と次アクションを決めるための表を作る。DSSはDX推進人材の類型としてサイバーセキュリティを含み、サイバーセキュリティ人材フレームワーク2026は役割・タスク・知識・スキルをより実務寄りに整理している。SSDFは、セキュア開発を開発・運用・調達を含むSDLC全体に組み込むための共通言語として使える。123

ここで扱う人材は2種類に分ける。

区分対象位置付け
専門セキュリティ専門業務セキュリティ専門業務を担う人材
＋現場業務本務の中でセキュリティ観点の整理を支えるセキュアフォロー人材

＋ は「プラス・セキュリティ」の意味で使う。ここでいうセキュアフォロー人材は、リスクを単独で受容したり、専門判断を肩代わりしたりする人ではない。業務影響、設計上の懸念、運用制約、委託先情報などを整理し、必要なタイミングで専門人材や正式な判断プロセスに載せる人である。

まず作る3つのマップ​

作る表は1つに集約しない。マクロとミクロを分ける。

マップ見るもの使いどころ
全体マップ不在役割採用計画
詳細タスクマップ実行可否改善計画
セキュアフォロー成長マップ自走範囲育成設計

表を作るときの原則は、1セル1項目である。1セルに複数の役割、複数のスキル、複数の担当者を書かない。複数該当するなら行を分ける。この原則を守ると、あとで人数集計、ピボット、フィルタ、タスク別の不足分析がしやすくなる。

Step 1：全体マップで「いない役割」を見る​

最初に、組織として必要な役割が存在するかを見る。ここでは個人の細かいスキル評価まではしない。必要人数、現有人数、不足人数だけを入れる。

列入力する内容
区分専門または＋
役割ID一意なID
役割名役割を1つだけ記載
スキル領域代表するスキル領域を1つだけ記載
必要人数当面必要な人数
現有人数現時点で任せられる人数
不足人数必要人数から現有人数を引いた数
打ち手次に行う対策を1つだけ記載

この表の目的は、現有人数=0の領域を見つけることだ。たとえば、SOCの監視は存在していても、戦略推進、設計開発、法務、監査が空欄なら、セキュリティ組織は「ある」が、組織としては穴が残っている。

サンプル表：全体マップ
区分役割ID役割名スキル領域必要人数現有人数不足人数打ち手
専門R01戦略策定セキュリティ体制運営110維持
専門R02プロジェクト管理セキュリティマネジメント211育成
専門R03監視セキュリティ監視321採用
専門R04対処インシデント対応312育成
専門R05脅威情報分析脅威情報分析101外部委託
専門R06脆弱性評価脆弱性診断211採用
専門R07フォレンジックデジタルフォレンジック101外部委託
専門R08運用管理アクセス制御220維持
専門R09教育セキュリティ教育110改善
専門R10法務プライバシー保護101兼務定義
専門R11監査セキュリティ監査101外部委託
専門R12設計開発セキュア設計211採用
専門R13研究先端技術調査101必要時委託
＋P01事業セキュアフォロー業務影響整理523育成
＋P02PMセキュアフォローセキュリティ要件確認835育成
＋P03開発セキュアフォロー設計懸念整理615育成
＋P04運用セキュアフォロー運用リスク整理413育成
＋P05調達セキュアフォロー委託先確認303育成
＋P06法務セキュアフォロー契約論点確認202兼務定義

Step 2：専門人材と＋人材の責任境界を決める​

全体マップに＋を入れる理由は、専門部署が全部を引き取らないためである。一方で、現場側に重い判断を背負わせるためでもない。境界を先に決める。

区分担うこと担わないこと
専門専門判断を行うこと現場業務の事実確認を全件代行すること
＋必要情報を整理することリスク受容を単独で行うこと

SSDFでも、セキュア開発にはサイバーセキュリティ担当だけでなく、開発者、プロジェクトリード、プロダクトオーナー、運用・プラットフォームエンジニアなどSDLC関係者の役割定義とロール別教育が必要になる。4

サンプル表：セキュアフォロー人材の役割定義
区分役割名担うこと担わないこと
＋事業セキュアフォロー業務影響を整理するリスク受容の単独判断
＋PMセキュアフォロー未決事項を拾い上げるセキュリティ要件の最終承認
＋開発セキュアフォロー設計論点を整理する高度な脆弱性評価
＋運用セキュアフォロー変更情報を整理するインシデントの最終判定
＋調達セキュアフォロー責任分界を整理する委託先リスクの最終評価
＋法務セキュアフォロー契約条項を整理するサイバーリスク全体の判断

Step 3：詳細タスクマップで「できない業務」を見る​

次に、タスク単位で現在地を測る。全体マップが「人がいるか」を見る表なら、詳細タスクマップは「実際にできるか」を見る表である。

列入力する内容
区分専門または＋
業務領域業務領域を1つだけ記載
タスクIDタスク単位の一意なID
タスク実行する行動を1つだけ記載
担当役割全体マップの役割名を1つだけ記載
必要レベルそのタスクに必要なレベル
現在レベル現時点の実行レベル
判定判定語を1つだけ記載
証跡確認できる証跡を1つだけ記載
不足理由主な不足を1つだけ記載
次アクション次に行うことを1つだけ記載

判定は感覚で書かず、レベル差で決める。

レベル意味
0できない
1説明を受ければ理解できる
2手順があれば実行できる
3独力で実行できる
4標準化できる
条件判定
現在レベルが必要レベル以上できる
現在レベルが必要レベルより1低い部分的
現在レベルが必要レベルより2以上低い弱い
現在レベルが0できない
サンプル表：詳細タスクマップ
区分業務領域タスクIDタスク担当役割必要レベル現在レベル判定証跡不足理由次アクション
専門統括T001セキュリティ年度計画を作成する戦略策定32部分的年度計画人員計画と接続していない不足人数を追記する
専門統括T002セキュリティ予算を整理する戦略策定32部分的予算資料リスク低減効果が説明できていない説明欄を追加する
専門規程T003セキュリティ規程を更新するプロジェクト管理33できる規程なし年次レビューを継続する
専門規程T004例外申請を承認するプロジェクト管理31弱い申請書承認基準が曖昧承認基準を定義する
＋企画T005新規サービスの業務影響を整理する事業セキュアフォロー21弱い企画書共有観点が定まっていない業務影響欄を追加する
＋企画T006判断が必要な論点を相談できる状態にする事業セキュアフォロー21弱い相談記録相談条件が不明確相談条件を定義する
＋要件定義T007セキュリティ要件の確認が必要な箇所を整理するPMセキュアフォロー21弱い要件定義書相談タイミングが遅い要件定義チェックリストに確認条件を入れる
＋設計T008設計上の懸念点を整理する開発セキュアフォロー20できないなし何を相談すべきか分からない設計相談テンプレを作る
専門設計T009脅威モデリングをレビューする設計開発31弱いレビュー記録レビュー観点が属人的レビュー観点表を作る
＋開発T010判断に迷うSAST検出を整理する開発セキュアフォロー22できるCIログなし確認条件を明文化する
＋開発T011SCAの検出結果を確認する開発セキュアフォロー21部分的CIログライブラリ更新判断が難しい依存関係更新ルールを作る
専門脆弱性T012脆弱性診断を計画する脆弱性評価32部分的診断計画対象選定が属人的対象選定基準を定義する
専門脆弱性T013診断結果のリスクを評価する脆弱性評価33できる診断報告書なし是正期限管理へ接続する
＋脆弱性T014脆弱性修正の業務制約を整理する開発セキュアフォロー22できるチケット期限超過理由が見えにくい制約欄を追加する
専門監視T015EDRアラートを確認する監視33できるアラート記録なし対応品質を定期確認する
専門対処T016インシデント初動を判断する対処32部分的手順書判断者が限定される代理判断者を定義する
＋対処T017インシデント時の業務影響を共有する事業セキュアフォロー21弱いなし報告様式がない影響報告テンプレを作る
＋運用T018セキュリティ確認が必要な変更情報を整理する運用セキュアフォロー21弱いログ設定確認タイミングが定まっていない確認条件を作る
専門教育T019職種別教育を設計する教育31弱い研修資料全社一律研修のみPM向け研修を設計する
専門監査T020是正状況を確認する監査30できないなし監査機能が未整備四半期レビューを設ける

Step 4：セキュアフォロー成長マップを作る​

セキュアフォロー人材は、専門人材の代替ではない。ただし、本務の中でセキュリティ観点を扱う経験を積むことで、専門人材に近いタスクへ進める人もいる。そこで、移行判定までは行わず、どのレベルでどのタスクを自走できるかだけを整理する。

レベル位置付け自走できる範囲
1気づく決められた観点で確認できる
2整理する必要情報を集めて説明できる
3案を作る専門人材がレビューできる形にできる

ここでのレベル3は、専門人材として任命する判定ではない。専門人材のレビューを受けながら、専門業務に近い成果物を作れる状態である。採用や異動の判定は、このマップとは別に本人希望、組織都合、実績、評価プロセスを踏まえて行う。

サンプル表：セキュアフォロー成長マップ
区分対象領域レベルタスクIDタスク自走条件接続する専門役割
＋事業1SF-BIZ-01業務影響を記録する指定テンプレを使える戦略策定
＋事業2SF-BIZ-02業務影響を説明する影響範囲を説明できるプロジェクト管理
＋事業3SF-BIZ-03リスク論点を整理する判断材料を作成できるプロジェクト管理
＋PM1SF-PM-01セキュリティ確認項目を拾うチェックリストを使えるプロジェクト管理
＋PM2SF-PM-02未確認事項を管理するチケットで追跡できるプロジェクト管理
＋PM3SF-PM-03セキュリティ対応計画案を作る対応期限を整理できるプロジェクト管理
＋開発1SF-DEV-01SAST結果を確認する検出結果を読める設計開発
＋開発2SF-DEV-02修正方針を整理する修正案を説明できる設計開発
＋開発3SF-DEV-03設計レビュー案を作るレビュー観点を提示できる設計開発
＋開発1SF-DEV-04SCA結果を確認する依存関係を確認できる脆弱性評価
＋開発2SF-DEV-05脆弱性修正を調整する修正期限を管理できる脆弱性評価
＋開発3SF-DEV-06脆弱性対応方針案を作る優先順位案を作成できる脆弱性評価
＋運用1SF-OPS-01ログ保存状況を確認する保存有無を確認できる運用管理
＋運用2SF-OPS-02ログ不足を整理する不足項目を説明できる運用管理
＋運用3SF-OPS-03ログ改善案を作る取得方針を提案できる運用管理
＋調達1SF-PROC-01委託先情報を収集する指定項目を集められる法務
＋調達2SF-PROC-02責任分界を整理する不足項目を説明できるプロジェクト管理
＋調達3SF-PROC-03委託先確認案を作る確認観点を提示できる監査
＋法務1SF-LEGAL-01個人情報論点を拾う該当有無を確認できる法務
＋法務2SF-LEGAL-02契約論点を整理する確認事項を説明できる法務
＋法務3SF-LEGAL-03確認プロセス改善案を作る再発防止案を提示できる法務

Step 5：90日アクションへ落とす​

表を作って終わりにしない。最後に、90日で動かす項目だけを抜き出す。

期間やること成果物
1から2週目既存のセキュリティ業務を棚卸する業務一覧
1から2週目既存の担当者を棚卸する担当一覧
1から2週目既存の証跡を棚卸する証跡一覧
3から4週目全体マップを作る役割別の必要人数
3から4週目不在役割を確認する役割別の不足人数
5から6週目詳細タスクマップを作るタスク別の現在レベル
5から6週目弱いタスクを抽出するタスク別の不足理由
7から8週目＋人材のセキュアフォロー範囲を決める部門別のセキュアフォロー役割定義
9から12週目不足が大きい領域から対策を決めるアクションリスト

優先順位は、表の列に入れなくてもよい。まずは不足人数、判定、不足理由で並べ替え、会議体で次アクションを決める。表に優先度列を入れると、初回から主観的な議論が増えやすい。

運用時の注意点​

このマップは、人事評価のために最初から使わない方がよい。初回の目的は、個人の点数付けではなく、組織としての欠落を見つけることである。

特に避けたいのは次の運用である。

避けたい運用理由
資格名だけで充足判定する実務タスクができるか分からない
専門人材と＋人材を同じ責任で扱う現場側に過剰な判断責任が乗る
1セルに複数項目を書く改善追跡ができなくなる
最初から全タスクを精密評価する改善に進まない
移行判定まで同時に行う育成マップと人事判断が混ざる

最初の一周では、粗くてもよいので表を埋める。2周目で、証跡の粒度やレベル定義を直せばよい。

まとめ​

セキュリティ組織の強化は、「専門人材を何人採るか」だけでは進まない。専門人材が担うべき役割と、現場側でセキュリティ観点を拾うセキュアフォロー人材の役割を分け、業務プロセス上で接続する必要がある。

そのための最初の作業は明確である。

  1. 全体マップで、いない役割を見つける。
  2. 詳細タスクマップで、できないタスクを見つける。
  3. セキュアフォロー成長マップで、＋人材がどのタスクまで自走できるかを決める。
  4. 90日アクションに落とす。

この順で進めると、セキュリティ組織が「あるが中途半端」という状態を、採用、育成、委託、標準化の具体的な判断へ変えやすくなる。

参考資料（出典）​

Footnotes​

  1. IPA, プレス発表 デジタルスキル標準ver.2.0を公開（Web, 2026年4月16日）。DSS ver.2.0の概要、6類型、サイバーセキュリティを含むDX推進スキル標準の改訂内容を示す。https://www.ipa.go.jp/pressrelease/2026/press20260416.html ↩

  2. 国家サイバー統括室, サイバーセキュリティ人材フレームワークに関する検討会（Web, 2026年4月参照）。サイバーセキュリティ人材フレームワーク2026、フレームワーク活用の手引き、個人向け手引き等の掲載ページ。https://www.cyber.go.jp/council/csjinzai/index.html ↩

  3. NIST, SP 800-218, Secure Software Development Framework (SSDF) Version 1.1（Web/PDF, 2022年2月）。SSDFを既存のソフトウェア開発実務へ組み込むための高水準プラクティスとして整理。https://csrc.nist.gov/pubs/sp/800/218/final ↩

  4. NIST, SP 800-218, Secure Software Development Framework (SSDF) Version 1.1（Web/PDF, 2022年2月）。PO.2で、SDLCに関わる役割・責任の定義とロール別トレーニングを扱う。https://doi.org/10.6028/NIST.SP.800-218 ↩

公開日：更新日：