やり切る、伝える、巻き込む。セキュリティPMの仕事術

これは

セキュリティプロジェクトのPMに関するポイントを紹介

この記事ではPM = Project Managementの意味で話を進めています。

ターゲット

• セキュリティマネージャ、セキュリティエンジニアではじめてPMを任された人
• セキュリティマネージャ、セキュリティエンジニアでプロジェクトマネジメント経験者で基本を確認したい人

---

1. はじめに：なぜセキュリティPMは難しいのか？

セキュリティプロジェクトのマネジメントは、単なる「進行管理」では収まりません。私がこれまで数十のセキュリティ施策を経験してきた中で、一貫して感じているのは──セキュリティPMは、もっとも可視化されにくく、誤解されやすいプロジェクトマネジメントの一つであるということです。

セキュリティプロジェクトの特性

まず、セキュリティ施策には次のような特性があります：

• 専門性が高い：暗号化方式、認証フロー、SOC2やNISTなどのコンプライアンス、ゼロトラスト……用語だけでも頭が痛くなる人が多い中で、技術と業務の両方を理解し、関係者にかみ砕いて説明できる必要があります。

• 関係者が多くマイナススタート：開発、情シス、経営、法務、外部ベンダー、CSIRT、現場部門……それぞれの立場や言語が違い、合意形成が簡単には進みません。またセキュリティは最初から嫌われていることも多く、マイナスからスタートすることもあります。

• 成果が見えにくい：「リスクを下げた」ことは、何も起きなかったこととして扱われがちです。そのため、完了後に「結局、何が良くなったの？」という声が上がりやすいのです。

これらは、プロジェクトとしての進捗や成果を「数値で語る」ことが難しい領域でもあることを意味します。“価値の見える化”ができなければ、組織からの支援も得られにくいのです。

PM初心者や兼務マネージャーが苦労しやすい理由

セキュリティエンジニアやマネージャーが初めてPMを任されたとき、最もつまずきやすいのが、「自分の専門性が通じない世界がある」という現実です。

• 技術的には正しくても、現場が使えなければ意味がない
• ベンダー管理や契約調整、稟議の通し方に時間を取られる
• 経営への報告資料作成が多く、「手を動かす時間が減った」と感じる

つまり、技術者視点ではなく、全体視点での“翻訳者”になる必要があるのです。このマインドチェンジに時間がかかり、最初の1〜2件のプロジェクトで自信を失ってしまう方も多く見てきました。

しかし、裏を返せば──この「翻訳力」こそが、セキュリティPMの最大の武器でもあります。

---

2. 勘所1：目的の明確化と共有

セキュリティ施策がうまくいかない理由の多くは、技術でもスケジュールでもありません。
「なぜやるのか」が関係者に共有されていないこと──これが最大の原因です。

「目的なき施策」がもたらす“やらされ感”

たとえば、「EDRを全社導入する」「多要素認証を全社で必須化する」…これらは一見、正しいセキュリティ施策です。しかし、現場の反応が「また仕事が増えた」「よく分からないけどやれと言われた」だったら、それはプロジェクトの失敗です。

セキュリティ施策は、「目的」が曖昧なまま進むと、“やらされ感”が蔓延し、形だけの導入で終わってしまう。この状態では、本来達成したかった「リスクの低減」は実現できません。

PMの最初の仕事は、「何のためにやるのか（Why）」を明らかにし、関係者に伝わる言葉で共有することです。そしてこのとき、ロジカルだけでなくストーリーとして共感が得られるような伝え方がベストです。

プロジェクト化の前の企画段階で、セキュリティチーム内で「何のためにやるのか（Why）」を議論しておき共通認識を持っておきます。そうするとプロジェクトのキックオフでスムーズに目的を説明できます。

言葉のチューニングが信頼を生む

セキュリティの目的を伝えるとき、相手によって「言葉のレベル」を変えることはとても重要です。

▷ 経営層には「経営リスク」として語る
×「攻撃される可能性があるのでWAFを導入します」

○「顧客データが流出すれば年間契約の30%が失われるリスクがあります。その対策です」

経営層が興味を持つのは“守ること”ではなく、“損をしないこと”です。損益、契約、評判…これらと結びつけて話すことで、支援を得やすくなります。

▷ 開発チームには「無駄な手戻りを減らす話」として語る
×「脆弱性を防ぐためのチェックを追加します」

○「後で見つかるともっと手間なので、早い段階でチェックを入れて手戻りをなくしましょう」

開発は納期が最優先です。「セキュリティ＝ブロッカー」にならないように、開発体験を守るメッセージで伝えることが肝心です。

▷ 情シスや運用チームには「運用負荷の見通し」を伝える
×「ログをすべて収集しておいてください」

○「インシデント時に5分で原因を特定できるよう、最低限この3つのログは取っておきたいです」

運用チームにとっては、日々の作業量が最も重要です。手間に見合う理由と、優先順位を示すことで、協力を得やすくなります。

成功のゴールは「導入」ではない

多くのセキュリティプロジェクトでは、施策が導入された瞬間が“ゴール”とされがちです。しかし、本来のゴールは「組織が実感できるリスク低減」 であるべきです。

• MFAを入れても、みんなが使わなければ意味がない
• ポリシーを作っても、現場で実践されなければリスクは残る
• ツールを入れても、アラートが放置されればリスクはむしろ増える

つまり、セキュリティPMとしての成功とは、施策を通じて「安全になった」という実感が社内に広がることです。そのためには、導入後の利用状況、定着率、関係者の声といった効果の見える化まで設計に含める必要があります。

最後に：PMが先にWhyを問うこと

「このプロジェクト、なんのためにやるんだっけ？」
PMであるあなたが、プロジェクト期間中、この問いをメンバーや自分に投げかけ続けてください。プロジェクトが始まってからは、特に目的を見失いがいがちです。それを回避するために自分や周囲に投げかけ続けるのです。

そして関係者に伝わる言葉で「Why」を設計し、浸透させていく──それが、セキュリティPMにおける最初の“勘所”です。

---

3. 勘所2：関係者の巻き込み方

セキュリティ施策は、「技術だけ」でも「正論だけ」でも前に進みません。
特にセキュリティ部門が中心となってプロジェクトを進める場合、「自分たちが正しいことをやっている」という信念が強すぎると──気がつけば孤立している、ということが起きがちです。

私も大昔、正論でプロジェクトを進めても、関係者からの協力が得られず頓挫したことがありました。そこから学んだのが、それぞれの立場や感情を考慮して、「誰と、どの順番で、どうやって進めるか」の設計です。

セキュリティ部門だけで進めない

セキュリティの施策はしばしば、トップダウンで開始されます。しかし、トップの理解があるからといって、現場の納得を得られるとは限りません。

セキュリティ部門が主導しすぎると、こうなります：

• 「セキュリティがまた変なルールを作ってきた」
• 「どうせ守るだけで、現場のことは分かっていない」
• 「やるけど、本当に意味あるの？」

こうなった瞬間、セキュリティ施策は“形式だけの義務”に変わり、真の効果を失います。

利害関係者マップを作る

そこで重要になるのが、「利害関係者マップ（ステークホルダーマップ）」です。
これは、プロジェクトに影響を与える（あるいは受ける）人物・部門を洗い出し、それぞれに以下の4軸で整理するものです。

ステークホルダー	関心度	影響度	キーマインド	目標とする関係性
開発部門	高	高	納期厳守	協力者
情報システム部門	中	高	安定運用	共闘者
経営層	中	高	コンプラ対応	支援者
法務部門	中	中	契約リスク回避	合意者
一般従業員	低	中	めんどくさい	当事者化

この表のように、それぞれがどんな立場で何を気にしているかを把握し、どの段階で・どう巻き込むかを事前に設計しておきます。

実際に効果があった関係者巻き込みの例

▷ 開発部門との「共創」
SaaSプロダクトのセキュリティ強化で、OAuthの見直しを行ったときは、最初から開発チームのリードエンジニアをプロジェクトメンバーに入れました。技術選定もセキュリティだけで決めるのではなく、「認証のUXと実装コストのトレードオフ」を一緒に検討する体制にしたことで、「セキュリティ施策をやらされる」ではなく「自分たちで決めて進める」という空気が生まれ、結果的に予定より早くリリースできました。

▷ 情シスとの信頼構築
ログの統合管理（SIEM）を導入するとき、情シスに「また面倒な作業が増える」と抵抗されました。
しかし、最初に「現状どんなインシデント対応で苦労しているか？」をヒアリングしたところ、「各サーバにログインして手作業で調査している」との声が。

その悩みを出発点にして「このツールであなたの負担を減らせます」と提案し、実際に導入後は対応時間が半分になりました。この経験が情シスとの信頼関係の第一歩になり、後続のプロジェクトにも協力を得やすくなりました。

巻き込みとは「協力」ではなく「共創」

多くのPMが「協力をお願いする」というスタンスを取ります。でも、それは「あなたの仕事を手伝ってください」に過ぎません。

セキュリティPMとして目指すべきは、「一緒にプロジェクトを創る」という関係です。
相手のゴールと自分のゴールを重ね合わせ、互いの成功に貢献し合う関係性をつくること。

それが、関係者を動かす本当の巻き込みであり、施策を組織に根づかせる最短ルートです。

一緒にプロジェクトを創ることで関係者の納得感が大きく代わり、やらされ仕事から積極的にやっていきたい仕事に変わります。セキュリティのプロジェクトは他の領域のプロジェクト以上に、人間心理を理解したうえで感情とロジックをうまく使い分けることが求められます。

---

4. 勘所3：スコープの切り方と段階的実行

セキュリティ施策は、理想を描けば描くほど、終わらないプロジェクトになるという落とし穴があります。

「全社にEDRを導入したい」「全社員にセキュリティ教育を浸透させたい」「すべてのAPIに認可機構を入れたい」──いずれも必要な施策ですが、いきなりフルスコープで実現しようとすると、組織のキャパシティも協力度も限界を超えてしまいます。

完璧主義のセキュリティPMが陥りがちなこの罠に、私もかつて何度もハマりました。
しかし、ある視点を得てから、施策は加速度的に進むようになりました。それが、「スコープの分割と段階的実行」です。

なぜ“理想の全体像”は罠になるのか？

セキュリティPMの多くは、善意と責任感から“全体最適”を考えます。
全社に効く仕組みを一度に導入できれば、効率的だし効果も大きい──そう思いたくなるのは当然です。

しかし、現場の温度感、技術的な制約、人的リソースの不足、そして社内の合意形成の遅さを考えると、理想を一度に実現しようとすることこそ、最大のリスクです。

失敗例にありがちなのがこちら：

• フルスコープでPoCを始めたが、関係者の巻き込みに失敗して頓挫
• 技術的な課題が出て対応に時間がかかり、現場の熱が冷めてしまう
• 本番を見据えた設計に時間がかかりすぎ、実装に入る前にプロジェクトが棚上げ

「まずここからやる」を決めるスコーピングテクニック

そこで鍵になるのが、スモールスタートのためのスコーピングです。
具体的には、以下の観点から「まずどこで」「何を」「どの程度やるか」を明確に定めます。

▷ スコーピングの観点

観点	例	意図
対象範囲	特定の部署、特定のプロダクト	全社展開の前に、現場で受け入れられるかを確認する
技術範囲	最低限のログ収集、基本的なポリシー設定	コア機能だけを先に試すことで、実用性を見極める
ユーザーペルソナ	新人社員、CSIRT、特定業務ユーザー	導入しやすい or 影響が大きい層から始める
期間	2週間、1ヶ月などの短期間	長期化を防ぎ、成果と課題の可視化を早める

スコーピングの目的は、早く試す・早く学ぶ・早く改善する。
これはアジャイル開発の原則と同じで、セキュリティにも極めて有効です。

PoC → パイロット → 本番展開の3ステップ

セキュリティ施策を成功させる王道パターンが、この3ステップです：

① PoC（Proof of Concept）

• 小さく試すことで技術的・運用的な課題を炙り出す
• 成功の定義（Success Criteria）を事前に決めておくことが重要
• 結果をレポート化し、社内への説得材料に使う

② パイロット

• 対象範囲を拡大して、運用現場での定着性を確認
• 関係者からのフィードバックを得て、チューニングを実施
• 改善点をもとに“本番展開の設計”を練り直す

③ 本番展開（Rollout）

• 組織全体へ計画的に展開
• マニュアル整備・教育・KPIモニタリングまで設計に含める
• 導入後の継続運用・改善まで責任を持つ

この流れで進めることで、関係者の合意・技術の安定性・運用の現実性を一つずつ積み上げられます。

完璧をやめて、完了を目指す

セキュリティPMの世界では、「100点の理想」を目指して0点で終わるよりも、「70点を3回繰り返して、90点に近づく」方が価値があります。

完璧を手放し、着実に前に進むためには、「小さく始める」「途中で振り返る」「やめる判断も持つ」という覚悟が必要です。

段階的な実行は、妥協ではなく戦略です。
それができるPMこそ、施策を組織に根付かせ、結果として大きなリスク低減を実現できるのです。

---

5. 勘所4：成果の見える化と伝え方

セキュリティPMの永遠の課題、それは──
成果が見えづらい仕事を、どう価値として伝えるかです。

セキュリティ施策は、その性質上「何も起きなかったことが成功」とされがちです。
でも、“何も起きなかった”ことを証明するのは極めて難しい。そのままだと、予算も人も支援も集まりません。

だからこそ、セキュリティの「成功」を意識的に定義し、見える形にすることがセキュリティPMの重要な仕事です。

セキュリティの「成功」とは何か？

セキュリティ施策における成功とは、「脅威が減った」「リスクが抑えられた」「備えが強化された」と関係者が実感できる状態です。

これは技術的な完遂よりも、組織の理解と納得が伴っているかどうかで決まります。

たとえば：

• EDRを導入した → 成功ではない
• インシデント初動が3時間から15分に短縮された → 成功と認識されやすい
• 社内教育を実施した → 成功ではない
• 受講率が95%、その後のフィッシング訓練で誤クリック率が1/3に減った → 成果として伝わる

つまり、“事実”ではなく、“変化”を見せることが成果の可視化です。

KPI・KGIの設定例

セキュリティPMとして、施策ごとに変化を示す指標を最初に設計しておきましょう。以下はその一例です：

施策内容	KPI例	KGI例
EDR導入	アラート対応までの平均時間	インシデント封じ込めまでの平均時間短縮
社内教育	受講率、受講後テストの正答率	フィッシング訓練での誤クリック率の変化
権限見直し	不要権限の削減数、レビュー実施率	意図しないデータアクセスの減少
ログ基盤整備	検知ルールの数、アラート精度	誤検知率の減少、初動調査時間の短縮
セキュリティポリシー改定	閲覧数、各部門での説明会実施数	ルール違反件数の減少、申告件数の増加

KPIは「プロセス指標」、KGIは「結果指標」として、時間経過とともに“成果”が見えてくるように設計することがコツです。

成果報告は「相手に合わせて翻訳」せよ

セキュリティPMがよくやってしまう失敗のひとつが、「技術的にすごいことを、すごいまま伝える」こと。
“誰に・何を伝えるか”で、伝え方は大きく変えるべきです。

▷ 役員向けの報告のコツ：リスクと投資対効果で語る

• ✗「YARAルールで未知のマルウェアを検知できるようになりました」
• ○「過去には発見に2日かかっていたマルウェアを、今は初動で検知できています。調査時間が1/4になり、対応コストも削減できました」

役員にとって重要なのは、「何をやったか」よりも「それでどうリスクが減ったか、コストが抑えられたか」です。経営言語に変換することが成果伝達の鍵です。

▷ 現場向けの報告のコツ：負担の変化・手間の減少で語る

• ✗「ログを集約して監視ルールを強化しました」
• ○「今までは調査に30分かかっていた作業が、5分で済むようになりました」

現場は、「自分の仕事がどう変わったか」に関心があります。
報告内容は、“あなたたちの負担をどう減らせたか”にフォーカスすると共感を得られやすくなります。

成果を伝えることで次の支援が生まれる

成果をきちんと見える化し、伝えることで、組織内に次のような好循環が生まれます：

• 「セキュリティって意味あるんだな」と思ってもらえる
• 次の施策への協力が得られやすくなる
• 予算や人員の獲得にポジティブな影響が出る

逆に言えば、“やったことが伝わらない”のは、やっていないのと同じという認識で、伝達まで責任を持ちましょう。

セキュリティは“実績”で語れ

最後に、セキュリティPMとして私が常に心がけている言葉をご紹介します。

「成果を報告するのではない。“変化”を記録し、ストーリーとして語る”」

セキュリティは守りの分野ですが、PMの役割は“攻めの見せ方”が求められます。
あなたが動かしたプロジェクトが、組織の中でどう変化をもたらしたのか。
その「物語」を、数字と事実で編んで、伝える力がセキュリティPMの真価です

---

6. まとめ

最後になりますが、冒頭に説明したセキュリティプロジェクトの特性と解決策の関連性を整理しました。

セキュリティプロジェクトの特性	解決に寄与する勘所	解決の方向性・アプローチ例
専門性が高い	勘所①：目的の明確化と"Why"の共有	経営・開発・運用ごとに伝える言葉を調整し、専門用語をかみ砕いて施策の意義を伝える
	勘所④：成果の見える化と伝え方	技術的な改善を“現場の変化”や“時間短縮”に翻訳して成果として共有する
関係者が多くマイナススタート	勘所②：関係者の巻き込み方	ステークホルダーを分析し、誰を味方にすべきか戦略的に考えながら共創体制を築く
成果が見えにくい	勘所④：成果の見える化と伝え方	KPI/KGIの設計により“リスク低減の実感”を数値やストーリーで伝え、施策の意義を認識させる
	勘所③：スコープの切り方と段階的実行	小さな成功体験を積み重ねて可視化することで、段階的に周囲の理解と協力を得ていく

一般的なプロジェクトマネジメントのノウハウは多くありますが、現場で使えるレベルのものとなるほど、あまり見つかりません。そんな中でさらにセキュリティプロジェクトの特有の勘所について、まとめました。

この「勘所」シリーズを通じて、少しでもあなたの前進を後押しできればと願っています。

またこの記事には記載していませんが、一般的なプロジェクトマネジメントのノウハウもとても重要です。例えば、プロジェクト企画段階でQCDSの優先順位付けを行う、初期段階では頻度高く報告をするなどなど。そういったことも合わせて少しずつ意識できると皆さんの業務に活かせるかと思います。