セキュリティエンジニア 兼 QAエンジニア の黒澤です。
本記事は Sansan Advent Calendar 2022 の5日目の記事になります。
adventar.org
AIイラストにチャレンジしてみたら、環境構築から始めてもおもったより簡単にそれっぽいイラストが描けてびっくりしています。
ものづくりをテーマにしているブログでこんな記事を書くのもなんですが、「ものをつくらない」エンジニアをしています。
アドベントカレンダーを見ていただくとわかりますが、 MLで新しい価値を届ける研究員や、大規模なデータ量に耐えたシステムを設計するアーキテクト、新規プロダクトを高速に開発していく組織など、自社のことながら優れたメンバーが多いと思います。
そんなエンジニアがサービスをつくり提供していく。利用してくれる方にとって最大の価値だと思います。私自身以前は、営業DXサービスのSansanの開発や運用、そこから派生する新サービスの開発といった仕事に関わってきた「ものをつくる」エンジニアをしていましたが、社内での役割の変化もあり、いまでは「ものをつくらない」エンジニアをしています。
スキルリスト
私自身のスキルをリストアップしてみると以下のようなものになるかと思います。
- プロジェクト管理（10名程度のPM経験はあるが、経験豊富なプロジェクトマネージャーには及ばない）
- アーキテクチャ設計（それなりにできるがアーキテクトほどではない）
- セキュリティ（基本的なセキュリティ診断やWebセキュリティはカバーしているが、専門のセキュリティエンジニアほどの技術はない）
- QA（開発者としてのテスト設計スキルや、PMとしての基本的な品質管理はできるがQAエンジニアほどの知識はない）
といったように、Sansanのエンジニアの中では突出している点は無いと思います。器用貧乏な赤魔道士といった評価ですね。
Sansanでの役割
そんなスキルの持ち主ですが、現在は情報セキュリティ部CSIRTグループ 兼 情報セキュリティマネジメント部 兼 Quality Assuranceグループ と専門分野の異なる3領域を担当しています。
CSIRTとして
- 自社で運用するサービスの脆弱性診断(セキュリティ + 開発)
- 新規機能の設計に対してのセキュリティ面からのアドバイス(セキュリティ + 開発)
- セキュリティに関する運用相談(セキュリティ + 自社プロダクト知識)
情報セキュリティマネジメントとして
- プロダクトのガバナンスに関わる統制の推進(セキュリティ + プロダクト知識)
- プロダクトに内在するセキュリティやシステムに関するリスクの摘出や是正(セキュリティ + 開発)
- プロダクトへのセキュリティ向上施策の立案、推進(セキュリティ + プロダクト知識)
- 社内で発生したインシデントの潜在的な原因分析の支援(セキュリティ + 開発 + プロダクト知識)
QAとしては
- プロダクトに付随するバックオフィスの業務から内部仕様まで把握しての総合的な品質保証(QA + 開発 + プロダクト知識)
- 内部仕様を把握した上でのプロジェクトのリスク分析(QA + 開発)
- QAチームのマネジメント(QA + PjM)
といったようにその分野一筋の専門家では担当することができない領域をカバーしています。
今の状態を表すのであれば、 Web開発をコア技術としながら、そこにPjMやセキュリティといったサブスキルを組み合わせて自社のプロダクトに対して最適化していったスキルセットと言えるでしょうか。
器用貧乏なエンジニアが活躍できる場所
いちエンジニアとしては、もう少し「つくりたい」という気持ちもないわけではないですが、Sansanという会社全体の最適化という観点から考えると、このような横断的な視点から各組織の抱える課題を解決し、最適化を図ることで一人のエンジニアでは成し遂げることのできない成果をSansanという組織全体に対して与えることができているのではないかと思います。
大きくなってきたプロダクトには外部の視点から課題を摘出できる視点は大きな力になると思いますし、小さなプロダクトでは、自分たちだけでは解決できない課題に対して外部からの協力を得られる。また、複数プロダクト間で車輪の再発明を防ぐといった意味でもこのような部門横断部署が担うべき役割は大きくなってきているように感じています。
T型人材やπ型人材といったように、スキルは掛け算で複数領域の組み合わせで価値を高めるといった話を聞きますが、このような器用貧乏なスキルセットで活躍するためには組織構造に依存すると思います。
ある程度規模が大きくなり、一人が担う役割が専門化してきていて、それぞれの専門家との間を横断的に業務を進めていく需要があること。また、それに対して各エンジニアが協力してくれる信頼関係が必要です。
幸いにもSansanのエンジニアは皆、安心して利用できるプロダクトのために協力してくれるためこのような役割が成り立っているのではないかと考えています。
願わくば自分に尖ったところがないと悩んでいるエンジニアへのヒントになれば幸いです。
最後にこのようなキャリアパスを選んで困っている点が一つだけあって、開発していた時期を知らない方に「本職は Webエンジニアです！」と言っても信じてくれないことです。
真っ白だった github にも来年はプライベートでもう少し草を生やせるように頑張ろうと思います。
