😺

若手セキュリティエンジニアのインタビュー記事4「pizzacat83」

2025/01/29に公開

始めに

本稿は、新卒1~3年目の若手セキュリティエンジニアを対象に、セキュリティの職に興味ある学生や若手向けのインタビュー記事です。

第4弾は、「セキュリティ若手の会」の幹事メンバーであり、セキュリティベンダー企業で働く新卒1年目の「pizzacat83(@pizzacat83b)」さんです。

「セキュリティ若手の会」とは

セキュリティ若手の会」とは、将来セキュリティエンジニアになりたい学生やセキュリティ業務に携わる若手セキュリティエンジニアたちがセキュリティに関する技術や業務内容、進路やキャリアについて、直接話し合える場として交流・情報交換できるコミュニティです。

若手セキュリティエンジニアのインタビュー記事」は、「セキュリティ若手の会」が実施するプロジェクトの一つです。

https://sec-wakate.notion.site/119382dfaec98058902bec703686c43c
https://sec-wakate.notion.site/172382dfaec9800d8a69def480ee3e9f

インタビュー「pizzacat83」

0. 自己紹介

  • セキュリティベンダー企業で開発をしている24卒のソフトウェアエンジニア(新卒1年目)
  • 専門分野:Web Security とその自動化技術
  • X:https://x.com/pizzacat83b
  • Portfolio:https://pizzacat83.com
  • Blog:https://pizzacat83.hatenablog.com
  • 修了: セキュリティキャンプ全国大会(2020)
  • セキュリティ若手の会:幹事メンバー(第1期), 第1回イベントLT登壇者

最近は趣味で自作ブラウザを Rust で作っています。

各種 Web 仕様の勉強を目的の一つに掲げているので、外部ライブラリにはなるべく頼らず、仕様書を読んで Rust に翻訳していくやり方で進めています。

1. 現在はどういう業務に取り組まれていますか?

GMO Flatt Security株式会社で、開発組織のためのセキュリティプラットフォーム「Shisho Cloud byGMO」開発のリードをしています。新卒1年目のソフトウェアエンジニアですが、2020年からアルバイトをしていて、もうすぐ勤続5年です。

Flattは「エンジニアの背中を預かる」をミッションに掲げています。世の中のエンジニアたちがプロダクトづくりそのものに向き合う時間を最大化すべく、開発組織に寄り添ったセキュリティサービスとして高度な手動脆弱性診断サービスや自動脆弱性診断 SaaS などを提供し、エンジニアたちの良き相棒として共に前進することを目指しています。

Shisho Cloud は自動脆弱性診断 SaaS として提供していますが、手動診断サービスの各ステークホルダーを支えるソフトウェア基盤でもあります。簡単に言えば、「Shisho Cloud に GitHub リポジトリ等を連携して簡単なセットアップをすると、Shisho Cloud が自動でアプリケーション情報を分析して、すぐに自動の脆弱性診断を開始できるし、自動診断で蓄積されたデータをもとに、高度な手動診断を簡単に発注することもできる」という、自動・手動の診断が統合された体験を目指しています。「診断を発注するユーザー企業のエンジニア」や「診断を担当する Flatt のセキュリティエンジニア」のそれぞれの業務プロセスや相互のやりとりを徹底的にソフトウェアで最適化し連携させることで、ユーザー企業のエンジニアが「プロダクトづくりそのもの」に向き合える時間、そして Flatt のセキュリティエンジニアが「人にしかできない高度な調査」に取り組める時間を最大化することに取り組んでいます。

ここまで抽象的に書いてきましたが、Web 診断に関連する具体的な技術として、以下のようなことにチームで取り組んでいます。

  • クラウド構成情報を収集してインターネットに露出しているリソースを洗い出し、Web 診断すべきものを見つけ出す技術
  • アプリケーションの自動クロールや API スキーマ等の分析によって、診断対象に関する情報を収集・分析する技術
  • 収集した情報をもとに、アプリケーションに擬似攻撃を行い脆弱性を検出する技術

Web 診断以外の領域でも、クラウド設定の自動診断など、プロダクトを取り巻く様々なリスクを検出・分析する技術に取り組んでいます。

エンジニアがものづくりに集中できるためのセキュリティプラットフォームになるためには、上記の技術そのものだけでは不十分です。不可欠なのは、「セキュリティの専門家でなくても、簡単に楽に、セットアップから診断結果への対応までできる」ためのユーザー体験の磨き込みです。この点についても、プロダクトデザイナーと連携して使いやすさやわかりやすさを徹底的に追求しています。

このようなビジョンに向けて、ユーザーのニーズやペインを捉え、セールス・マーケティングチームやセキュリティエンジニアと連携し、Shisho Cloud のロードマップを描いてそれを実行していくのが私の仕事です。ソフトウェアエンジニアとして自らコードを書いたりもする、プレイングマネージャーのスタイルです。またアプリケーション情報の分析や脆弱性の検出を自動化する技術に強い興味があるので、役立ちそうな技術を調べて PoC ツールを作り、勉強会や社内ブログのような形で社内に広めたりすることもあります。

2. 学生時代はどういうことに取り組まれていましたか?

ゲーム開発や自然言語処理、bot やブラウザ拡張機能の開発など、気の赴くままにプログラミングをする学生時代でした。「セキュリティが大好きな人」というよりは、「開発が大好きな人」だと思います。「日々を楽しく・便利にするソフトウェアをつくる」ということが何よりも好きで、その価値を提供し続けるために不可欠な要素の一つがセキュリティである、と今も昔も思っています。

そんなわけで、趣味の時間の大半はセキュリティというよりは開発に没頭していました。
興味のままに色々開発してみたはいいものの、そのセキュリティに自信が持てないために、作ったものを公開することを躊躇していました。そこで「セキュリティをちゃんと勉強して、堅牢なソフトウェアを作れるようになりたい」という動機で、Flatt でのアルバイトを大学3年に始めました。開発ばかりやってきていたとはいえ、Web アプリやブラウザ拡張の開発を通じて HTTP や DOM API、ブラウザのセキュリティ機構などに触れていたことが、Web セキュリティに取り組むための橋頭堡になったと思います。

Flatt のバイトでは、Web アプリケーションの脆弱性を探してリスクを報告するセキュリティ診断を主に担当していました。特に Firebase や GraphQL などのモダンな技術スタックに対し、そのセキュリティ上の落とし穴を調べて診断をしたり、調べた知見を会社のブログで発信したりしました (就活の面接で、「Flatt でバイトしてるんだ、Flatt と言えば Firebase のブログが有名だよね」「その記事、私が書きました」という会話をしたことがあります。2回)。また、診断業務を支える社内システムの開発にも携わりました。バイトを始めて2年後ぐらいにセキュリティ診断からプロダクト開発へチェンジしたのですが、それについては後述します。

サークル活動としては、TSG というコンピュータサークルに所属していました。TSG はコンピュータが好きな人々が勉強会や Slack 雑談などでゆるく交流するサークルです。こうした人々との繋がりを持っておくと、誰かの活動に刺激を受けて興味を広げることができたり、有益なイベント情報が流れてきたりするので、サークルであれ SNS であれ、交流の輪を広げておくことはおすすめです。実際、TSG が SECCON CTF 国際大会で優勝したことは私がセキュリティに触れるきっかけの一つでしたし、セキュリティキャンプ全国大会2020に参加したのも、TSG のメンバーがおすすめしていたからでした。

まとめると、そんなにセキュリティひとすじではない学生時代でした。「セキュリティが大事だと思っている開発者」という感じです。

3. 新卒の就活はどういう感じに取り組まれていましたか?

就活について考え始めたのは修士1年の春でした。Flatt でのアルバイトでセキュリティ診断を2年ほど担当し、プロダクトセキュリティのリアルに向き合ってきた中で、「年に1回程度のセキュリティ診断まで、重大な脆弱性が気づかれずに残っている」という現実に強い課題意識を抱くようになっていました。この時点で、ファーストキャリアではこの課題の解決に取り組むと決心、というより、この課題から目を背けて生きていくことには耐えられないと感じていました。

そこで、「年に一度のセキュリティ診断」よりも密接な立場でプロダクトセキュリティに向き合うべく、プロダクトづくりからゼロ距離にある開発者になろうと考えました。開発者と同じ目線で、顧客のニーズや事業の成長などセキュリティ以外の目標にも向き合い、専門家からの押し付けでない、開発者に寄り添ったセキュアな開発体制を実現したいと考えました。そこで就活ではセキュリティエンジニアではなくソフトウェアエンジニアのポジションを探すことに決め、また Flatt でのアルバイト業務もセキュリティ診断から Shisho Cloud の開発にチェンジしました。

就職先を選ぶにあたっては、可能な限り実際に働いてみてその感触を考慮して決めたいと思っていたので、夏休みのインターンは体験入社の機会と捉えていました。色々な会社の採用情報を読んだり会社説明会に参加したりして、「このプロダクトの開発をしたいかも」と思ったところの実務型インターンに応募しました。

選ぶ軸は「仕事をやらされているのではなく、仕事を自ら望んでやっている」と思えることです。例えばディレクターに「こういう機能を作ってほしいんだよね」と言われた時に、言われるがまま作るのではなく、自分の頭でも考えてブラッシュアップし、 120% の成果物を作る、という働き方をしたいと思っています。第一に必要なのは、最高のプロダクトにしたいという情熱、つまりプロダクトが解決しようとする課題に深く共感し、その解決に心血を注ぎたいと思えることです。情熱の次に必要なのは、ディレクターの意見を鵜呑みにしないための自信を持ち、説得力のある提案をするために、プロダクトが扱うドメインや課題を十分に理解できていることです。もちろん就活の時点でドメイン知識が揃っているわけではないですが、エンジニアとして働く中で十分に理解を深めていけそうか、先輩エンジニアはどれほどの解像度を持っているか、などは注視していました。最後に、「より良いプロダクトにするための提案が、職種や役職の垣根に妨げられず歓迎されること」も必要です。この3点に着目してインターンを探しました。

実際に働いてみた感触を掴むため、1ヶ月程度の中期的な実務型インターンを中心に応募していましたが、学業と両立させる都合上、夏休みに2社で1ヶ月ずつインターンをするのが限界でした。「もっと若いうちからインターンに応募していたら色々な会社を見られたのに」という後悔はありますが、学生の時間の使途はインターンだけではないので、「若いうちからインターンをしまくろう」とは一概に言えないのが難しいところです。

さて2社でのインターンはどちらも魅力的で、これらを終えた時点で、「この2社と Flatt の3択でも後悔はない」と思ったため、一般の新卒選考の情報収集は特にしませんでした。インターンをせずに入社を決めるということには、働く前のイメージと実際に働いてみた感触にギャップがあるかもしれないリスクが伴います。そのようなリスクや選考情報を収集する労力を考慮して、実務を経験した上記の3社に絞ることを決めました。

3社はどれも魅力的でなかなか決め手に欠けましたが、最終的には「今ここで働かなければ経験できない面白さ」のある Flatt に決めました。他の2社に感じていた魅力は3年後でも享受できるだろうと思ったのに対し、当時の Flatt は新プロダクトのリリースなど、今でしか経験できないことがたくさん待ち受けていたので、これらを今逃したら取り返すことはできず、きっと後悔すると考えました。

Flatt への入社を決めた経緯について、詳しくは以下のブログに書いています。

https://pizzacat83.hatenablog.com/entry/2024/04/01/093529

就活を本格的に始める前におすすめしたいことが一つあります。それは、アルバイトや実務型インターンを通じて、自分によくマッチする仕事環境 (企業・業務内容・仕事仲間等) に少なくとも1つ出会っておくことです。インターン先にそのまま入社することを勧めているのではなく、「自分とマッチする仕事環境」の具体例と実体験を持って就活に臨もう、ということです。

「マッチする」とは、「自分が心地よく働けている」ということと、「自分が自然体で働くことが、周囲に受け入れられ評価されている」という2点だと思っています。このような仕事環境に出会っておくことは、履歴書に実務経験を書けること以上に、就活にメリットをもたらします。

仕事の時間が心地いいかどうかは、やってみないとわからないところがあります。かっこよく見えた仕事がやってみたら意外と泥臭い業務だったり、あるいは逆に、あまり自分に合わないように思えた仕事が、やってみると意外と苦でなかったり。自分が楽しいと思える仕事とは何か、理屈をこねくり回してあれこれ考えるよりも、実際にやってみるのが確実です。仕事を通じてリアルな課題と向き合う過程で、モチベーションが新たに生まれることもあります。私のセキュリティに対する情熱も、Flatt でのバイトで現実のプロダクトのリスク状態と向き合ってきたからこそ生まれたものです。

「自分が自然体で働くことが、周囲に受け入れられ評価されている」ということも、就活にとても役立ちます。就活では自分の長所を説明することをしばしば求められますが、仕事をする上での長所を客観的に一番よく知っているのは、共に働く仲間たちだと私は思っています。家族や学校の友達も長所を教えてくれますが、それは家族や友達としての長所であって、仕事をする上での長所とは必ずしも一致しません。仕事仲間が感じているあなたの長所は、実際に仕事で役に立っている特性であり、積み重ねられた実体験に基づく確かなものです。こうして自分の客観的な長所を知ることができれば、他の企業の選考でも自信を持ってそれをアピールできるでしょう。

そうして出会った「マッチする仕事環境」で、内定をもらっておけるとなお良いです。「ここなら心地よく働き、活躍できる」と実感できているところの内定を一つ持っていれば、それ以外の企業の選考に全部通らなくても、心地よく働ける場所は保証されているわけです。就職先が見つからないことを恐れて面接官の前で自分を偽る必要がなくなり、他社の選考にも自然体で向き合ってマッチ度を測ることができます。

私は運良く、たまたま始めたアルバイトが「マッチする仕事環境」になりました。ですが一発ではそういった仕事環境に出会えないこともあるでしょう。仕事をしてみてなんとなく違和感があるのであれば、その違和感を分析し、次に繋げることを繰り返す必要があるかもしれません。

就活の軸は人それぞれですが、「仕事の時間が心地よいこと」は多くの人が重視する点だと思います。一般的には週に40時間程度、人生のうちのかなりの時間を仕事に費やすわけですから、その時間を心地よく過ごすことは人生を充実させるために重要だと私は思います。誰もがいわゆる「就活ガチ勢」をやる必要はないと思っていますが、「自分にマッチする仕事環境を見つける」ということには、それなりにリソースを割くことをお勧めします。

4. 今後はどういうことにチャレンジしようと考えていますか?

「世の中のエンジニアがものづくりそのものに向き合える時間を最大化すること」「Flatt のセキュリティエンジニアが人が見るべき高度な調査に集中できること」を実現するため、ソフトウェアが奪えそうな仕事はまだまだたくさん見えているので、それらを一つずつ解いていくことが直近の目標です。

しかしソフトウェアエンジニアとしてフルタイムで1年弱働いてきた結果、「実現したいアイデアの量に対して自分の手が遅すぎる」と感じることが多々ありました。とはいえ、自分の手を高速化するのには限度があります。技術力はこれからも磨いていきたいですが、それだけでなく、実現したいことをチームの力で高速に実現するためのスキルも身につけなければならないと最近感じています。

また別軸の話として、バグを防ぐための設計理論を自分なりに体系化し実践したいと思っています。セキュリティ上の脆弱性に限らず、「意図通りに動く」「望まない挙動が起こらない」ことを仕組みで保証する技術にはずっと興味を持ち続けてきました。バグを防ぐ仕組みとしては型検査や静的解析、テスト、コードレビューなどが挙げられますが、それらの技術の効果を最大に発揮させるには、検査対象とするソフトウェアの設計が重要だと思っています。簡単に言えば、「誤ったプログラムが書けないようにする」あるいは「誤ったプログラムが、前述の検査技術で容易に検知されるようにする」ということです。

例えば React では、色々なアプローチで誤った使われ方を防止しています。React Hooks が正常に動作するための原則である Rules of Hooks を定めて言語化し、ESLint のルールとして静的解析で違反を検出できるようにしたり、実行時にエラーを出したりしています。また、XSS が起きうるパラメータを dangerouslySetInnerHTML と名付け、危険を承知の上で使うことを強制し、このパラメータの利用を簡単に静的解析で見つけてレビューできるようにしています。また Go の safesql というライブラリは、型を活用して SQL クエリを構築する際に文字列リテラルしか使えないように制約することで、ユーザー入力が含まれるような SQL クエリの構築がコンパイルできないようにし、SQL インジェクションを根本的に防いでいます。

こういった設計プラクティスは外部ライブラリだけでなく、アプリケーション開発の過程で生まれる内部ライブラリでも実践し、そのアプリ特有のバグを防ぐ仕組みを構築すべきだと考えています。そのために、「誤った使い方が型検査で引っかかるようにするための型設計」「誤った使い方をするとどう見ても危なそうなプログラムの見た目になり、コードレビューで絶対に気づけるようにするためのインターフェース設計」のようなトピックを探求していきたいと思っています。

バグを仕組みで防ぐ方法論は、AI がコードをバリバリ書くこの時代にますます重要になってくると思っています。AI に意図通りの正しいコードを書かせる上で、「何も考えずコードを書くと、正しいプログラムしか出来上がらない」「バグったプログラムを書く方が難しい」というガードレールを整えておくことは重要だと考えています。逆にそうでないコードベースにおいて、「実は重大なバグが潜んでいるが、型検査等には引っかからず、コードはパッと見人畜無害」なプルリクを AI が生成したとして、そのバグには誰がどうやって気づけるでしょうか。AI の力を活用して爆速でソフトウェアを正しい方向へ成長させていくためにも、こういったトピックに取り組んでいきたいと思っています。

5. セキュリティに興味ある学生や若手へのメッセージをお願いします!

セキュリティに興味がある皆さんへ、何よりも、「ありがとうございます」!

ベンダーであれユーザー企業であれ、セキュリティエンジニアであれソフトウェアエンジニアであれ、どんな立場であっても、セキュリティに真摯に向き合う人がそこにいることで、世の中は少しずつ良くなっていくと思います。自らの興味と才能を、どうか善きことに使ってください。

欲を言うならば、与えられた役務の枠に囚われず、自分が関わるシステムのセキュリティについて能動的に考え、理想のセキュリティ体制を追求していきましょう。

そしてセキュリティに対する興味を内に留めず、積極的に発信し、自分の周りをもセキュリティに惹き込んでいきましょう。

終わりに

本稿では、若手ソフトウェアエンジニアである「pizzacat83」さんについて紹介しました。

「セキュリティ若手の会」についても、興味を持っていただけたら幸いです。

ここまでお読みいただきありがとうございました。

次回

第5弾は、K(@K_1001011)さんのインタビュー記事です。

第2回イベントについて

2025/03/16(日)に東京で「第2回 セキュリティ若手の会(LT&交流会)」を開催予定です!

セキュリティ分野に興味ある方やセキュリティの職に就いている若手エンジニアの方は、ぜひ以下をチェックしてみてください。

第2回 セキュリティ若手の会(LT&交流会)

https://sec-wakate.connpass.com/event/339267/

スポンサー企業の一般募集について

https://zenn.dev/sec_wakate/scraps/f1c52a7ca6f57d

イベント開催記「第1回 セキュリティ若手の会(LT&交流会)」
https://zenn.dev/sec_wakate/articles/acd5935f189460

Discussion