セキュリティコンサルタントのスキルシートの書き方｜面談で評価される実績の見せ方

セキュリティコンサルタントのスキルシートは、プロジェクトごとに案件の型（リスク評価、規程と体制づくり、認証取得の支援、監査への対応、事故への備えなど）と自分の役割を書き、作った成果物の種類と、誰と合意を作ったかを添えるのが基本です。コンサルタントの成果は、組織が決めたことや運用し続けた仕組みの中にあるため、「何を作ったか」と「誰に何を決めてもらったか」を分けて書くと、担った範囲が伝わります。

一方で、リスク評価の結果や監査の指摘は、顧客の弱点そのものです。中身は書かず、作り方と進め方で示します。案件で求められるスキルはセキュリティコンサルタントのスキルの記事、全体の構成はスキルシートの基本で扱っています。

案件の型と役割を一行目に置く

セキュリティコンサルタントの案件は、型によって求められる経験が違います。プロジェクト欄の冒頭に、型と自分の役割を書くと、読み手が案件と結びつけやすくなります。

同じ型でも、「主導した」「支援した」「一部を担当した」で読まれ方が変わります。主導していない部分は、そのとおりに書きましょう。

成果物は「種類」と「作り方」で書く

コンサルタントの経歴では、作った成果物が実績の中心になります。ただし、前職や参画先の文書そのものは持ち出せず、スキルシートに添付することもできません。そこで、成果物は種類と構成と作り方で書きます。

• 種類：規程、手順書、リスク評価の結果の一覧、改善計画、訓練の計画と報告
• 構成：「基本方針・対策基準・実施手順の3層に整理」のように、骨組みだけ
• 作り方：「各部門の担当者への聞き取りをもとに、既存の手順と照らして作成」

構成と作り方が書かれていれば、面談で「どう作ったか」を説明する入り口になります。成果物の中身を具体的に書けないことは、読み手も分かっています。

「誰と合意を作ったか」を書く

セキュリティコンサルタントに求められるのは、対策を決めてもらい、現場に守ってもらう力です。スキルシートでは、関わった相手の層を書くと、この力が伝わります。

• 経営層：対策の優先順位と予算の判断を仰いだ
• 部門の責任者：規程の変更による業務の影響を説明し、運用の開始時期を合意した
• 現場の担当者：手順書を一緒に試し、守りにくい点を直した
• 外部：審査を行う機関や、委託先との調整

ここでは役職名を書く必要はありません。「経営層への説明を年○回程度担当」のように、頻度でぼかして書けば十分です。

顧客の弱点にあたる情報は書かない

守秘義務の一般的な考え方はスキルシートに書いてよいこと・いけないことで扱っています。ここでは、セキュリティコンサルタントに固有の注意をまとめます。

認証の取得は「組み合わせ」に気をつける

ISMS適合性評価制度では、認証を取得した組織を検索できるページが公開されています。そのため、「○○業・従業員○○名規模・20XX年に認証取得を支援」と書くと、組み合わせから支援先が推測されることがあります。業種は広めに、規模は「中規模」程度に、時期は年単位でぼかすのが安全です。

あわせて、認証の取得は組織が審査を経て得るものです。スキルシートには「認証を取得させた」ではなく、「認証取得に向けた文書の整備と内部監査の準備を支援」のように、自分が担った範囲を書きます。

プロジェクト欄の記入例

以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年〜20XX年（1年）
案件の型：規程と体制づくり、認証取得の支援
案件概要：サービス業向け（中規模） 情報セキュリティの規程の見直しと、認証取得に向けた運用の立ち上げ
規模・立場：コンサルタント2名（自分は規程と内部監査の担当）
作った成果物：規程の体系の見直し案、部門ごとの手順書の雛形、内部監査の計画とチェック項目
作り方：各部門の担当者に聞き取りをし、既存の業務の手順と規程の食い違いを洗い出してから改めた
合意を作った相手：経営層（優先順位の判断）、部門の責任者（運用の開始時期）、現場の担当者（手順書の試行）
工夫・成果：守りにくいと声が上がった手順を、業務の流れに合わせて書き直した。内部監査の担当者を顧客の社内で育て、自分たちが抜けたあとも監査を回せる形にした

リスクの内容や指摘の件数は書いていません。それでも、作り方と合意の相手が書かれていれば、どの程度の役割を担える人かは伝わります。

公的な指針や規格は「使い方」と一緒に書く

セキュリティコンサルタントの経歴では、参考にした規格や公的な指針の名前を書くことがよくあります。名前だけを並べると、読んだことがあるだけなのか、顧客に合わせて使いこなしたのかが分かりません。

• 「規格の管理策と既存の規程を照らし、足りない項目を一覧にした」
• 「中小企業向けの公的な指針をもとに、顧客の規模に合わせて対策を絞り込んだ」

規格の版が改められることもあるため、どの時点の版をもとにしたかが分かるように書くと、読み手が経験の新しさを判断できます。

技術の経験はどこまで書くか

セキュリティコンサルタントの案件では、技術の作業そのものより、技術の話を理解して判断に結びつけられるかが見られます。エンジニアとしての経歴がある方は、次のように絞って書きます。

• 規程や評価で使える技術の理解（例：クラウドの設定の確認、脆弱性診断の結果の読み方）
• 技術の担当者と会話して対策を決めた経験

技術の経歴を細かく書きすぎると、コンサルタントの案件では作業の担当者として読まれることがあります。技術の作業が中心の案件にも応募する場合は、シートを分けて、セキュリティエンジニアのスキルシートの記事の書き方を参考にしてください。

資格の書き方

国家資格の「情報処理安全確保支援士（登録セキスペ）」は、2016年10月の法改正で生まれた資格で、登録を続けるには所定の講習を期限までに修了することが求められます（2026年10月時点のIPAの案内による）。スキルシートには、合格しただけなのか、登録しているのかを分けて書きます。

監査やマネジメントシステムの分野には、民間の資格や研修の修了の制度もあります。書く場合は、略称ではなく正式な名称と、取得した年月を書きます。更新の条件がある資格は、有効な状態かどうかが分かるようにしておきましょう。

よくある質問

内部の情報システム部門での経験も、コンサルタントの経歴として書けますか？

書けます。社内で規程を作った経験や、監査への対応を担った経験は、案件の型に沿って同じように書けます。立場が社内だったことは隠さずに書き、関わった部門と合意を作った相手を添えると、外部から支援する案件でも判断材料になります。

ITコンサルタントの案件にも応募したい場合は、どう書き分けますか？

要約と並び順を入れ替えます。ITコンサルタントの案件では、業務の改革やシステムの選定が読まれるため、セキュリティの経験は「関連する経験」として添える形が読みやすくなります。書き方はITコンサルタントのスキルシートの記事をご覧ください。

成果物のサンプルを求められたら、どうすればよいですか？

参画先や前職の文書は出せません。求められた場合は、架空の組織を想定して自分で作った雛形や、構成の説明であれば示せます。作るときは、実際の案件の文書を下敷きにしないよう気をつけましょう。