ホーム › 記事 › セキュリティには転職ではなく、社内で手を挙げて入った

セキュリティには転職ではなく、社内で手を挙げて入った

著者：SecBilly　公開 2026-09-10

セキュリティには、転職ではなく社内異動で入りました。外から応募した103社では、不採用理由の79%が「経験不足」です。

在籍していた会社でポジションがオープンになり、手を挙げただけでした。実務経験も資格もない状態です。中から動いたときは、年数を聞かれませんでした。

この記事の要点

セキュリティに入ったのは転職ではなく、社内のオープンポジションに手を挙げたから
外から入るときは経験年数を問われる。中から動くときは問われなかった
GRC で一番大変なのは技術ではなく、非エンジニアへの説明
そして GRC には、システムを理解している人が少ない
つまり開発経験は、この領域では不利ではなかった

どうやって入ったか

特別なことはしていません。社内でポジションがオープンになり、手を挙げただけです。

その前は、社内で使うサービスの要件をまとめたり、導入とライフサイクルの管理をしていました。開発とインフラを合わせて11年やったあとの話です。

セキュリティの資格は持っていませんでした。実務経験もありません。それでも異動できました。

なぜこれが現実的な道なのか

103社に応募したときの数字と並べると、はっきりします。

不採用の理由が記録できた76社のうち、79%は「経験不足」でした。「5年以上の経験がない」「セキュリティ以外の経験が長く即戦力として期待できない」といった文面です。

外の市場は、セキュリティ専任としての年数を見ます。そこに届いていないと、書類の段階で切られます。実際、103社のうち71社は書類で落ちています。

一方、社内で手を挙げたときは、その関門がありませんでした。何を評価されたのかは分かりません。選考の中身までは聞いていないからです。

ただ、年数を理由に断られなかった、という事実だけは残っています。

中の人は「未経験」ではない

外から見ると未経験でも、中から見ると「システムを分かっている人」です。ここが決定的に違います。

セキュリティの仕事は、既存のシステムと業務の上に乗ります。何がどこで動いていて、誰が管理しているかを知っている人は、その時点で仕事の半分を持っていることになります。

外部から採用すると、そこを一から覚えてもらう必要があります。社内異動なら、その分をスキップできます。

入ってみて、一番大変だったこと

技術ではありませんでした。非エンジニアへの説明です。

GRC の仕事は監査対応が多くを占めます。統制が意図どおり動いていることを、証拠を出して説明する仕事です。

相手は技術者ではありません。監査人、経理、法務、外部の会計士。システムの中身を知らない人に、システムがどう守られているかを説明します。

「動いています」では通らない

エンジニアどうしなら「このジョブが毎日回っています」で終わる話が、監査では終わりません。

そのジョブは、いつから動いているのか
誰が止められるのか
止まったときに気づく仕組みはあるか
それを示す記録は残っているか

技術的に正しいことと、監査で説明できることは別でした。ここに一番時間を使いました。

エンジニアの感覚が通じないところ

仕組みがあることと、それを第三者が確認できることは違います。

エンジニアの感覚だと「そういう作りになっているので大丈夫」で十分に思えます。監査ではそれだけでは足りません。作りがそうなっていることを、記録で示せるかが問われます。

この切り替えが、開発から来た人間には一番遠いところだと思います。

「証跡」という考え方

監査で使う言葉に証跡（エビデンス）があります。統制が動いていたことを、後から第三者が確認できる形で残したものです。

エンジニアが「ログを見れば分かります」と言うとき、それは証跡としては不十分なことがあります。証跡として成立するには、だいたいこの4つが要ります。

いつの時点のものか（タイムスタンプ）
誰が取得したか（作った本人が改変できない形か）
母集団が確定しているか（全件なのか、一部なのか）
同じ手順で再取得できるか

3つ目が分かりにくいところです。「権限を持っている人が適切か」を確認するとき、そもそも「権限を持っている人が何人いるか」が確定していないと、確認したことになりません。

エンジニアの感覚だと「怪しいものを見つけて直す」ですが、監査は「全部見た。問題はなかった」を示す仕事です。目的が違います。

自動化する側に回れる

ここで開発の経験が効きました。

証跡の収集を手作業でやると、取得のたびに条件が変わります。人によって範囲が違う、日付がずれる、スクリーンショットの撮り方が違う。それ自体が監査で指摘されます。

同じ手順で、同じ範囲を、決まった時刻に取る——これはコードで解ける問題です。監査対応を「面倒な作業」ではなく「自動化の対象」として見られたのは、開発をやっていたからでした。

そして分かったこと

GRC には、システムを理解している人が少ない。

これが1年やって一番はっきりしたことでした。

監査やコンプライアンスの側から来た人は、統制の考え方や文書化には慣れています。一方で、クラウドの権限がどう設計されているか、ログがどこに出ているか、そのジョブが何をしているかは、必ずしも分かりません。

だから「証拠を出してください」という依頼が、エンジニア側には意味の分からない形で降りてくることがあります。翻訳する人がいないからです。

開発経験は不利ではなかった

103社の書類選考では、開発11年は「セキュリティ以外の経験が長い」と読まれました。不利な材料として扱われています。

でも実際に GRC の中に入ってみると、その11年が一番効いています。

エンジニアに何を頼めばいいかが分かる
出てきた証拠が意味のあるものか判断できる
手作業でやっている確認を、自動化する側に回れる

市場が「経験不足」と読んだものと、現場で足りていないものが、ずれているということです。

これから入ろうとする人へ

自分の経験から言えるのは、この2つです。

まず、社内にセキュリティの機能があるなら、そこが一番近い入口です。求人が出ていなくても、誰がやっているかは分かるはずです。ポジションがオープンになったときに手を挙げられる位置にいるかどうかが、外から103社に応募するより効きます。

次に、開発の経験は捨てるものではありません。書類では「セキュリティ以外の経験」と読まれますが、入ったあとに効くのはそこです。少なくとも GRC 領域では、システムが分かる人は足りていません。

ただし、それが書類選考を通してくれるわけではないのも事実です。この記事は「開発経験があれば入れる」という話ではありません。入ったあとに効く、という話です。

社内にセキュリティ機能がない場合は

ここまでの話は、社内にセキュリティの機能があったという前提の上に立っています。

無い会社のほうが多いはずです。その場合にどうするのが最善かは、自分は答えを持っていません。経験していないからです。

言えるのは、103社に応募した側の数字だけです。外から入ろうとすると、書類の段階で69%が落ちます。楽な道ではありません。

まとめ

セキュリティには社内のオープンポジションに手を挙げて入った。転職ではない
外から入るときは経験年数を問われる。中から動くときは問われなかった
中の人は「未経験」ではなく、システムを分かっている人として評価される
GRC で一番大変なのは非エンジニアへの説明。技術的な正しさと、監査で説明できることは別
GRC にはシステムを理解している人が少ない。市場が「経験不足」と読んだものと、現場で足りていないものはずれている

これも一人分の経験です。ただ、103社に応募して分かったことと、入ってから分かったことが正反対だったというのは、記録しておく価値があると思っています。