情報セキュリティマネジメントの視点で見る、プロダクトの「守り」
情報セキュリティマネジメント試験の学習を通じて、技術だけでなく統制と文化の話に触れてきました。ISMS（情報セキュリティマネジメントシステム）は、JIS Q 27001 / ISO/IEC 27001 などに規定される枠組みとして広く知られています（ウィキペディアの整理や認定スキームの公開情報など）。プロダクトでも、機能としてのセキュリティと運用としてのセキュリティは分けて考える必要があります。 セキュリティの会議でPdMが黙ると、議論は「専門家の祈り」に寄る。祈りは止まらない。
情報セキュリティマネジメント試験の学習を通じて、技術だけでなく統制と文化の話に触れてきました。PdMがセキュリティの専門家になる必要はありません。必要なのは、リスクを機能要件の隣に並べる言葉です。
ISMSの思考を、プロダクトに翻訳する
怖さをシナリオにし、要求を脅威と対策に分解する。専門職の代替ではなく、会議を前に進める翻訳です。
例外とログ
例外に所有者を付けないと、承認は形骸化します。誰が、いつ、何を守るために承認したかを短いコメントまで含めて運用するよう促しました。
脆弱性対応と優先順位
CVSS だけでは足りない場面があります。利用状況と露出が無いと現場は動きません。
インシデントは学習の入口
ポストモーテムで「人」を守るより、再発条件を書く。次の四半期の誰が手入れするか、まで決めない例外は永久例外になりがちです。
まとめ
統制は遅れの敵に見える。放置した統制は、インシデントの友軍になる。
ISMの学習は、プロダクトに統制の語彙をくれた。怖さをシナリオにし、要求を脅威と対策に分解し、例外に所有者を付け、ログと保持を最小化し、インシデントを学習に変える。専門職の代替じゃない。会議を前に進める翻訳だ。試験の知識は辞書。現場の正解そのものじゃない。
次の機能要件に一行。「守る対象は何か」。そこから境界の議論が始まる。うまくいかなかったリリースほど、次の統制の種になる。
仕上げのための自問（現場メモ）
記事にするほどではないが、私が自分用に残している自問です。全部に答えなくてよいです。
いまの議論は、次の一週間の行動に落ちるか
落ちないなら、まだ抽象度が高い。
反対意見を一行で言語化できるか
言えない反対は、ただの不安であることが多いです。
休む予定を入れたか
持続可能性はスローガンではなく、カレンダーの実装です。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）, https://isms.jp/index.html （参照: 2026-04-06）
- Wikipedia（日本語）, 情報セキュリティマネジメントシステム, https://ja.wikipedia.org/wiki/%E6%83%85%E5%A0%B1%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0 （参照: 2026-04-06）
- IPA, 情報セキュリティ関連のアーカイブ資料（ベンチマーク等）, https://www.ipa.go.jp/archive/security/sme/benchmark/benchmark-gaiyou.html （参照: 2026-04-06）