ある研究者の手記

セキュリティとかゲームとかプログラミングとかそのへん

転職します(Cookpad → Ubie)

f:id:mztnex:20210731121501p:plain
https://github.com/m-mizutani/m-mizutani/commit/067a421f3e3e8405cba870bb461446c545128a2e

2021年7月30日を最終出社日として現職のCookpadを退職し、9月からUbieという医療系のスタートアップに入社します。

Cookpadでのこれまで

2017年11月に入社したので、在籍期間は4年弱でした。この間、組織変更に伴う部署異動はありましたが、ずっと情報セキュリティに関わる業務をやってきました。

システムのセキュリティ対策

主な業務は「インフラや社内システム、開発サービスに対するセキュリティの機能をエンジニアリングによって向上させること」でした。 製品やサービスをそのまま導入することもありますが、自分たちの必要に応じて既存ツールを拡張したり、全く新しいシステムを自作することもありました。 例えば以下が代表的なやつです。

セキュリティに関する社内の問題を見つけ出してエンジニアリングによってそれを解決していく、という仕事内容は自分の志向とマッチしており仕事はとても楽しかったです。 さらに仕事で取り組んだ結果を発表する機会も各所から多くいただき、これについてもありがたかったです。 USに飛んで英語で撮影するぞという話を突然もらって、七転八倒しながら達成したのも良い思い出です。

ただ調子に乗っていろいろやりすぎてしまった感があり、退職に伴って大量のシステムを引き継ぐことになってしまった点については少し申し訳ないなと感じている次第です。

社内リスク対応

いわゆる社内の情報セキュリティ委員会というやつもやっており、社内で新たに起きる情報セキュリティのリスクをコントロールするということもやっていました。 自分もこの業務に携わるまであまり意識したことがなかったんですが、会社の活動というのは目まぐるしく変化し、それに伴って様々なリスクが発生します。 そういったリスクに対応するため、どんな情報システムを使ったらいいのか、どのように使ったらいいのか、どんなデータを扱っていいのか、という相談をうけたり判断をしたりということもやっていました。

これは単純に社内ルールに準拠するだけでなく、法律や規制などについても配慮し、とりあつかう情報の重要度などから実際のリスクを考え、現実的な落とし所を考える必要があり、最初のうちはかなりハードな業務でした。 自分もそもそも法律などについては素人だったり、(セキュリティの人にありがちですが)過度に安全側に倒して現実的でない方法になってしまうなど四苦八苦していました。 しかし同僚の助けも借りつつ最終的にはある程度の部分をこなせるようになった気がしており、自分としてはなかなか良い経験値になったのではと思います。

その他会社生活全般

組織のカルチャーや雰囲気も自分にとってはかなりマッチしていたと思います。 前職が大手SI企業だったこともあり、そのギャップの衝撃から入社直後にわりとはしゃいでいる記事を書いたりしていました。 さすがに今はもうこの記事のテンションはありませんが、ここで良かったと感じたことは特に変わっていません。

今回の転職直前にオフィスが恵比寿からみなとみらいへ移転するという一大イベントがありましたが、これについても今回の転職とはあまり関係ありません。 個人的にみなとみらいはいろいろ思い出深い土地で気持ちがあったし、WeWorkの無限にビールが飲めるサービスとか楽しみにしていたのですが、情勢によって結局ほとんど恩恵に預かれませんでした。悲しい。

転職のきっかけ

ということで現職に対して特に厳しいことがあったというわけではないのですが、自分の能力の幅を広げるという観点でこの度転職をすることにしました。

セキュリティエンジニアのキャリアパスというのもいろいろあると思うのですが、自分は「システムのセキュリティ対策」というのがやはり最も興味の強い範囲で、 これを継続していった場合にどのようにキャリアを重ねていけばいいのかという点についてはこれまでずっと模索してきました。 社内リスク対応の方はパスとして例えばCISOになるというような話があったりすると思いますが、 どちらかというと現場でエンジニアリングしていたいので、役職を上げるのとはまた違うかなと考えています。

というようなことを長らくもやもやと考えていたのですが、あるきっかけで「違う事業ドメインにチャレンジしてみることで幅を広げるのがいいのでは」と思いつきました。

同じWeb系であっても他社のセキュリティ担当の方と話させてもらうと、やはり会社の事業ごとにリスクであったり守るべき資産の捉え方というのが大きく違うな、というのは以前から感じていました。 そのため現職でうまくいっている事例を話しても「うちとは(環境や背景が)違いますね」という反応になることがあり、自分のやっていることが他の会社や事業ドメインでどのくらい通用するのか?というのが未知なままでした。 そこは確かにやってみないとわからないので「だったら環境を変えてチャレンジすることでより多くの場所で通用することを増やしていこう」と考えるようになりました。

Ubieでのこれから

というわけで冒頭で書いたとおり、Ubieという医療系のスタートアップに転職することにしました。現状では医療機関向け、および患者さん向けのサポートをして患者さんを適切な医療へつないでいく、といったサービスを提供しています。(私もまだ事業の細かいところを知っているわけではないので、詳しくはこちらの資料を見ていただくか、あるいは興味のある方はぜひお声がけください)

ubie.app

Ubieに決めた理由

実は今回の転職では他の会社の選考は受けておらずUbie一本だった*1ため、他社との比較はしていません。普通に考えて転職するときは複数社を受けてオファーを並べて検討するものと思うのですが、1社目で転職しようと考えた決定的な理由は以下の2つでした。

  1. 事業ドメインが今までと大きく違う
  2. セキュリティをエンジニアリングしていくことへの理解

1については転職のきっかけの話の通り、事業ドメインがなるべく違うところが望ましいというのがありました。 特にセキュリティに対しての厳しさでいうと自分の中では医療と金融が最も難しい分野であり、その片方である医療の分野というのは自分の思惑にとてもマッチしていました。 また、事業についても「今あるアナログなビジネスをちゃんとデジタル化していく」という分野は個人的にとても面白く、熱い領域であると考えています。 (流行り言葉を使うといわゆる "DX" になるんだと思います) Ubieの事業が医療機関に関わってくることで自分たちのサービスだけでなく、医療機関でのセキュリティというのも同時に携わっていく必要があり、 それについてもチャレンジングで興味深いと考えています。

自分の中でさらに決定打になったのは2の「セキュリティをエンジニアリングしてくことへの理解」が大きかったです。 これはCookpadへ入社する際の転職活動で感じたことでもあるのですが、 いわゆるセキュリティの問題に対して製品やサービスの導入するだけでなく、 ちゃんと自分たちでエンジニアリングをして問題を解決しようというマインドを持った組織というのは日本だとまだかなり少ない印象です*2。 Ubieのメンバーとカジュアル面談をした際に彼らもその課題感をもっており、しかしまだそこにアプローチするメンバーがいないという話を聞いたときに、 ここで働いてみたいなとう気持ちが強くなったことを覚えています。

この他にもマネジメント的な上下関係がない組織構造(ホラクラシー)や評価のない制度、会社の雰囲気など惹かれた部分はいろいろあります。ただまだ直接働いたわけではなく「良さそう」という印象でしかないので、詳しくはいずれ別の機会にという感じです。

やっていきたいこと

というわけでUbieへの転職後も引き続きセキュリティエンジニアをやっていく予定です。

今回は医療という領域になるため、リスクに対する考え方や対応がよりシビアになっていくのではないかと考えています。 利用してもらう人のために十分な安全性を担保していかなければならないのですが、じゃあどこまでやったら「十分か」ということを常に見極めていく必要があります。 そうしたことを突き詰めていく課程で、最適なセキュリティとはなんなのか?、そもそも最適というものがあるのか? ということを考えていきたいと思っています。

また自分の密かな目標として、サービス運用をソフトウェアエンジニアリングの方法でアプローチするSRE(Site Reliability Engineering)にあやかり、Security Reliability Engineering*3の方法論を探求していきたい、というものがあります。 Site Reliability EngineeringはもともとGoogle社内で運用にまつわる作業や問題をソフトウェア開発の考え方・発想・手法で解決する方法論を体系化して世に出したのが発端という認識です*4。 この着想はセキュリティに関する運用にも適用でき、ソフトウェアエンジニアリングの応用で解決できる問題というのは多くあるのではないかと自分は考えています。 ただSREとは領域や前提がいろいろ違うためそのまま持ってくることはできず、セキュリティ分野ならどうかということを改めて検討しなければなりません。

自分が新しい領域でチャレンジすることでSecurityのReliability Engineeringの方法論を体系化していく足がかりになればと考えており、引き続きやっていきたいと思います。

ということで

各位、引き続きどうぞよろしくお願いいたします。

*1:厳密に言うとUbieに最初に声をかけてもらったので、Ubieの選考がだめだったら他を考えようとしていました

*2:逆に海外のbig tech companyはこのマインドがかなり強い印象で、例えばAWSの事例紹介などでユーザ企業がAWSのサービスを組み合わせてセキュリティの問題を解決しているという話は多くあります

*3:略語がSREともろかぶりなので、この名付けはどうかと思うんですが

*4:なんですが門外漢なので違ったらこっそり教えて下さい