1. 言語化.fm
  2. #31 きりんのお仕事の面白さを..
2024-08-23 40:15

#31 きりんのお仕事の面白さを言語化する

spotify apple_podcasts

以下の話を言語化しました


- きりんがどんな仕事してるのか

- 何が面白いのか

- 難しいポイント

サマリー

このエピソードでは、プロダクトセキュリティ領域におけるセキュリティチームの構築と進化について語られています。ゲストは自身のキャリアや仕事の面白さを紹介し、特にセキュリティに特化したチームの組織的な変革や文化的背景について触れています。また、エンジニアリングやセキュリティの分野における仕事の難しさや面白さについても話されています。特に、ソフトウェアエンジニアとしての経験がセキュリティ業務にどのように役立つのか、実践的な見解が示されています。さらに、リボルピングドアという概念のもと、企業内での人材の流動性とそのメリットについても言及されており、セキュリティ業界の魅力やリスクを理解する過程で、参加者が学んだ新たな視点が紹介されています。最後に、ソフトウェアエンジニアリングにおけるセキュリティの重要性と実践的な視点に焦点を当て、開発チームが安全性を考慮することの価値や必要な知識について深掘りされています。

仕事の面白さの探求
こんにちは。言語化.fmは、あんな話やこんな話を、きりんとだての2人でゆるく話しながら、言語化を試みるポッドキャストです。
というわけで、今回は、俺の仕事の面白さを言語化するキリン編にやっていこうかなと。
シリーズに勝手に、シリーズっぽい名前勝手にしちゃいましたけど。
2話で終わっちゃうよ、それ。
あ、違うか。1人でいっぱいやってもいいのか、別に。そっか。
いやー、マジで?
いやー、語り尽くせないでしょ、3部じゃあ、やっぱり。
俺の、まあそうね、確かに。
過去まで放っちゃったら、もう無限に話しちゃうよな。
いやー、まあでも今にね、今してる仕事の楽しさ、面白さをね、前回も話して思ったので、やっていこうかなと思うんですけど。
自分に言った方がいいが、なんか恥ずかしいな。恥ずかしくはないんですよ。
恥ずかしいの?恥ずかしいんだ。
なんだろう、ちょっとこしょばい気持ちにならないと。
まあ、あんまりこう、普段さらけ出さないものであるかもね。
わざわざだって、面白く楽しんでることを言葉に載せることなんてそんなにないでしょ。
ないね。なんか、なんだっけ、リア充はSNSをやんないみたいなよくわかんない格言。
ああ、そういうやつだよね。
だって言う必要がないもんね、普通は。
うちとかは言うんだろうけど。
だいたいそういうの書くときはね、いいことじゃないんだけど、あえてそのいいところを言っていこうっていう取り組みですね。
セキュリティチームの発展
そういうことです。
いやー、ノープランなんでね、どっから話してもらうか。
何をしてるのかをまず話さないといけないな。
そうだね。じゃあインタビュー形式にしてあげようか。
ちょっと、お願いしてもいいですか?
じゃあ、自己紹介がてら、今何のお仕事をしているか教えてください。
はい、自己紹介。
ヒリン、年齢とかいう時代じゃないんで、中堅、中堅と呼ばれつつある、社会人10年目ですか?
今の仕事は、一般的な定義で言うところで言うと難しいんですけど、
プロダクトセキュリティ領域を担うセキュリティチームの中で、ソフトウェアエンジニアとしてあれやこれをやってるっていうのが、一言で言うとそういう仕事をしております。
セキュリティの仕事をやってるんですね。
もともと今の会社入ったときはセキュリティじゃなかったんだよね。
そうなんですよ。もともとは普通にソフトウェアエンジニアとして、今のうちの会社はバックエンドクライアントを分けるみたいな文化というか分けないっていうフィロソフィック、哲学なんで、何でもやるマンとして入って、機能開発とか最初は普通にやってた。
そこからセキュリティに移ったのは何かきっかけがあるんですか?
いい質問しか飛んでこない。ありがてー。
ちょっと面接みたいになってきたな。
俺がね、たぶんちゃんとね、自分で膨らませろっていう話はあるけど。
セキュリティに転校したのは、オフィシャルにたぶん喋ったことないかもろって今ふと思ったんですけど、
2ステップあって、1ステップ目は、僕が入社したタイミングは開発、バックエンド、フロントエンド、関係なく機能開発していきましょうみたいな感じで。
チームの概念がなかったんでね。エンジニアの数も少ないし、会社の規模もちっちゃいし、フェーズ的に作って私作って私だったんで、
イメージとしてはめっちゃでかい1枚のプロダクトバックログを各エンジニアが自分で考えて、上から取っていって、
必要な仕様も決めて、ひたすらリリースリリース消化していくみたいなスタイルでやってたけど、
入社してしばらくしてから色々その、その方式って良さとしてはスピードがめっちゃ出る。ひたすらスピードが出るんで、
事実僕が入った時点でその人数でありえないぐらいのアウトカムが出ていったし、プロダクトもかなり大きくなってたんだが、
作った出しって感じなんで、例えばその作った機能を誰がメンテ見るのかみたいなところで言うと、
だいたい作った人が詳しいんで、作った人に質問が飛んでいって、負荷が偏るとか、
チームがないってことは、例えばSREチームとか、セキュリティもそうですし、品質保証するとか、
基盤を作るチームみたいなそういうものもないんで、その辺はなんていうか個々人が判断して必要ならやるみたいだったんで、
まあなんていうか、そういうようなシップがないっていうのがまず一つの課題なのと、
2つは今ニュルっといったところにも含まれているのなんですけど、やっぱりプロダクトバックログを消化するのが、
全員の思考命題にどうしてもなってくるんで、それ以外の優先度が壮大的に下がって、
例えば品質がいつの間にか下がってるとか、可用性がいつの間にか下がってるとか、基盤がいつの間にかちょっと辛い感じのような、
でも依頼先はないし、プロダクトバックログにそれが乗ってくることはないんで、
なかなか回線が進まないっていうのが一種としてあって、
プロダクトに対してめちゃくちゃシンプルに、チームを切ってオーナーシップを少しずつ切り分けましょう、組織転換。
開発の組織転換があって、そのタイミングでエンジニアが確か7、8人いたんですかね、
転換前はCTOが全員ワンワンできてなかったんじゃないかな、できてなかったし、
でも評価はCTOが全員頑張るみたいな感じで、評価の時期にCTOが完全に機能しなくなるところがあったんで、
僕がEMっていうロールを作って、行って意思決定を権限にしようというのがあって、
そこで僕がEMにちょっとやってくれませんかって言われて、
分かんないけどやりますって言ったのがステップ1。
そのステップ1の時に3チーム分かれたんですけど、
開発チームが2チームで基盤全般をやるみたいなふわっとしたチームが僕がEMをやるチームで、
そうなった時に結構ふわっと投げられたんですけど、
これはなんか僕は別にネガティブだと思ってました。
社員を信頼してるから、かつ序盤だからできる。
開発以外のSRE領域とか積極的領域とか品質とか、
当時はCICDもかなりそれこそリリースフローとかに課題があったんで、
その辺ちょっとまるっとどうしてくれって感じになって、
僕に託されたのはメンバーとそのミッションだけって感じで、
そこに対して、別に僕一人で決めたわけでも全くないですけど、
チームどうあるべきかみたいなので、
そのチームの中にサブチームじゃないと、SRE担当この何人か、
CICD担当この何人かみたいな感じで分けて、
その中で1つセキュリティチームを作ったのが、
セキュリティチームの一番最初の生まれた感じで、
そこから半年、9ヶ月EMやって、
子供が生まれるって時に入るんでEMを引き渡して、
休んで戻ってきて、基盤チームみたいなちょっと形は変わったけど、
セキュリティチームっていうのは存続してたものの、
サインが実質1人、1.2人ぐらいかな、
1.2人ぐらいって感じだったんで、とても回んないっていうので、
言い出しっぺだし、興味もあるし、セキュリティに戻って、
専任としてメンバーとしてやりますっていうのが、
セキュリティチームに配属されたというか、
勝手に配属されるように仕組んだって言い方あるけど、
自分で作ったチームを蹴っ持たないとあれじゃん、
自分に戻ってきたっていうのが今に至るって感じ。
会社の文化と風土
なんか急に会社のポッドキャストになってきたような気がするんですけど、
一応言っておきますけど、僕ときには全然違う所属なので、
そこは一応間違いなきよう。
これあれじゃん、後で会社のチェック通さなくて大丈夫なのかわかんないけど。
大丈夫、大丈夫。
大丈夫、そっか、そんなにあれですけどね。
でもあれですよね、会社が拡大してきて、
中にいるメンバーからファンクションが分化していって、
自分でEMをやるようになって、
EMを退いてまたメンバーに戻るっていう、
そうあったらいいよね、みたいなロールの動かし方を見事にやってるような感じがするんですけど。
いろんなロールでやったと思うんだけど、
面白さ的にはどうだった?全部面白いなって感じだったんですか?
全部面白かったですね。
最初の開発もそうだし、EMもそうだし、
セキュリティチームのIC、インディビジュアルコントリビューターとしてやるのも全部面白いですね。
全然面白さはやっぱり、
あとは何か、そうですね、言った通り、
多分結果的には結構、個人目線としては誤解を恐れずに言うと美味しいロールチェンジをしてる気はするとしてて、
なかなかEMとかってやりたくてもやらないし、チームを作るとかもやりたくてできることじゃないし、
こんな規模のように社内転職、結果的になるっていうのは、
いつかの回で話した行動、アクションを取った結果のリターン、
別にリターンを期待してたわけでは全くないけど、こうなるのかみたいな感じ。
聞いてる感じ、まさに今社内転職って自分で言ったけど、
普通というか他の会社だと結構、セグメントがされちゃってるとなかなか部門間の影響がしにくいとか、
ロールチェンジも含めた部署移動みたいなものって結構やっぱりハードルが高かったりすると思うんですけど、
多分元々の会社の文化風土でそういうのがしやすい土壌が多分あったからこその大胆な、
もともとプロダクトをバンバン作ってましたって人が、
今やセキュリティを支えるロールになるっていうのはなかなかできる意思決定ではないと思ったりしてるんで、
そういうのをやりやすかった、会社のなんかがあるかなと思ってるんですけど、
会社のそういうところで言うと、なんかそういう風土とか雰囲気とかどうなんですか?
そうですね、当時のバリューで言うと、
でも急に言語化が難しくなったな、
なんか必要ならやればいいよね、雰囲気はあるような、
結構オーナーシップを大事にしてくれる風土はあるかも、
セキュリティでもなんでもいいですけど、これまずいと思いますって言った時に、
じゃあやればいいんじゃない?そういう返答をくれる会社という、
もちろん動かす、
思い出した、うちの会社バリューが1回変わってるんで、
ちょっと時間かかっちゃったんですけど、
小さく探索し始めて大きな成果を出そうみたいなバリューが、
当時の1個前のバリューとしてあって、
何か課題感とかやりたいことがあるんだったら、
まずやればいいじゃんっていうところと、
やってうまくいくんだって大きくすればいいし、
ダメならそれは失敗したところの風土はやっぱあるかなって気はするね、
だからセキュリティチームを作ったとかは、
結果としてうまくいったから大きくしたけど、
引き返したっていうのも全然ありえたかなとは思ってて、
でもやらないことにはそれがいいのか、
課題があることは多分やってもやらなくても確実で、
それを誰かが解かなきゃいけない確実で、
じゃあ何かのレバーは引かなきゃいけないみたいな、
そのレバーを引くのは何でしょうね、
どっかに説明責任を果たさなきゃいけないとか、
CTOの許可が必要とか、
ソフトウェアエンジニアはやっちゃいけないとか、
Vizではやっちゃいけないとか、
コーポレートだからやっちゃいけないとか、
そういう縛りというか、
縦付け上も社内の空気としてもないっていうのは、
この行動を取れた土台としてあるかなっていうのは。
最近そういう会社増えてきてるなっていうふうにも感じてて、
もちろん今ケリングさんがいる会社は結構先駆けだったと思っているけども、
元々の職能にとらわれずいろいろやっていくためのチーム作りとか、
組織のシステムを作ったりみたいなのって、
そういう本もいろいろ出始めてはいたし、
元々自分たちでやりたいことをやった方がいいよねっていうところから、
多分そういうのが来てるんだと思うから、
仕事の環境の特殊性
うまくいっている事例の一つとしていいなというところもあるし、
単純に今の話聞いて、
面白そうと思った人も結構いるかなとは思いました。
僕の仕事というよりかは、
僕の会社のこういう風とは結構、
会う人にやっぱりとことん合うような気がするっすね。
よく言えば、
自由って言葉で言うにはちょっとあまり言葉足らずだけど、
まあまあそうしたとおりで、
逆になんか悪く捉えるなら、
多分意思とかウィルがない人は結構腐りやすい環境ではある。
まあ腐りやすいのかな、
でもなんかやればいいじゃんのやりたいがない人は、
ちょっと辛いよね、多分。
うちの会社は。
辛いっていうか、
なんか待ってても別にタスク降ってこないしミッションも。
抽象化されたミッションは降ってくるけど、
指示は降ってこない。
まあそれはなんかうちの。
あとなんか自分のちょっとしては自分に戻すと、
今話しててちょっと思った面白さとして思ったのは、
なんかこれも結構特殊というか、
まあでも特殊だけど、
なんか再現できるし、
なんか再現する人が増えてほしいなとちょっと思ってるんだけど、
今の会社で言うと、
ソフトエンジニアとして派遣と、
EMとして派遣と、
セキュリティチームで働いてるときの3つを経てるわけで、
それを同じ関係でやってるんだけど、
そうなるとなんか単純に視点がめちゃくちゃ、
経験した視点が増えるんで視野がめちゃくちゃ広いなと思って、
特になんかその再現、
他の人も再現してほしいと思ってる部分は、
エンジニアやってからセキュリティに行くっていうパターンで、
逆はしれないです。
僕セキュリティから来たわけじゃなくてわからないですけど、
エンジニアやってからセキュリティの世界行くと、
めちゃくちゃ有利だ、
有利というか、
まあ有利かな、
フラットに見て有利かなと思って、
セキュリティの難しさであり、
面白さであり、
腕のミスどころって、
あらゆるトレードオフで、
いかにベターな回答を取るかっていうのがめちゃくちゃ難しくて、
基本的に絶対に100点はあるんですよね。
教科書的に100点はあるんだけど、
現実問題100点取りたかったら予算10倍必要ですとか、
売上立ってないのにそのお金どっから出てくるのとか、
そのデリバリーが大事なフェーズで、
じゃあ3ヶ月開発止めてくださいって言えんのとか、
そういう現実の問題っていうのが絶対にあるわけで、
そんなったときに、
じゃあ今はここは守りましょう、
ここはリスクとしてあるのは分かるんだけど受容して、
じゃあ半年後に見直してもらうとか、
そういう回答を絶えず、
いろんな領域で出し続けなきゃいけないのが、
セキュリティの難しい要素の一つと思ってて、
それやるときに必要になってくるのが、
セキュリティ施策とか仕組みを適用したい領域で、
普段開発をしたり運用したり働いてる人たちから見たときに、
その施策がどうなのかって絶対に考えなきゃいけないので、
例えばなんか今うちとかだと、
パッケージのアップデートによるみたいな、
ブログ一回書いたんですけど、
NPMとか他の言語とかパッと出てくるくらい、
RubyだとGemとか各言語あると思うんですけど、
ああいうパッケージマネージャーのパッケージを最新にし続けましょうみたいなのをやっていきたい、
今セキュリティチームもやってるけど、
いろんなチームに自分たちでちょっとずつやってもらって、
負荷分散したいと思ってるが、
それを多分開発経験がない状態でやると、
やってください、こんないいことがあります、
こんな安全になります、
これはもうそもそもやらなきゃいけません、
話したところで、
多分頭ではみんなわかってくれるけど、
いやでもさ、みたいな、
うちのバックログ見たことあんの?とか、
いや開発QAどうすんだよ?とか、
エンジニング知識がないチームの中には、
例えばデータチームとかがあるわけで、
そこに対してそれを引き付けて、
そういう回答が返ってきたときに、
建設的なキャッチボグができるかどうかは、
結構そこのコンテキストをいかに掴めるかな気がして、
そのコンテキストを掴むところにおいて、
めちゃくちゃリードできてる、
リードというか、
アドバンテージになるな、
そのソフトエンジニアの経験は強いなと思ってて、
かつ今の僕のパターンでいうと、
同じ会社で一回ソフトエンジニアやってるおかげで、
なおそれが色濃く出てるっていうのは、
結構いいなみたいな、
なんかあるあるが、
ここ直してくださいって言いつつ、
いやでもここの行動ですな、
カオスなんだよなと思いながら依頼するみたいな、
相手がそういう顔したら、
いや分かりますみたいな、
言って、
現状どうしましょうねみたいな相談を
すごいしやすかったりとかっていうのは、
結構面白いし、
面白いっていうか、今の状況でしょうがない、
めっちゃ喋った。
セキュリティ業務の複雑さ
1機械19で。
ね、なんかあれだね、
ソフトウェアエンジニアやってた経験が、
セキュリティでフルにいけるってところが、
多分ね、
セキュリティをちょっとかじってみたいけど、
こんなセキュリティ未経験の私でもいけるのかしら、
みたいな人たちにとってはね、
すごいいい話だったと思うんだよね。
なんかやっぱりその、
セキュリティが不要になる世の中は多分来ないと思ってるし、
常に脅威と隣り合わせの世界だから、
すごくやっぱり自分のやったことに対して、
結構責任を取らなきゃいけないと、
身構えちゃってる人が多いし、
僕もその一人ですけど、
でもなんかそういうわけでもないし、
なんかやってみたらいいんじゃないかなって気持ちになったので、
きりんさんと一緒にセキュリティをやりたい人は、
会社に連絡するとか、
そういう回ですか?
いや、そういう回じゃない。
そういう回じゃないよね。
別に、
そういう回のつもりではない。
そういう回のつもりではないけど、
それでいい仲間が増えたら、
それはいい話だね。
良さそうだなと思った感じですけど。
なるほどね。
じゃあもうあれですか、
当分セキュリティはずっとやっていくような感じですか?
そうだね。
それとも何年かで利用をつけて、
それこそまたプロダクトを作る方に行くのか、
それともまた全然新しいところにチャレンジするのかとか、
なんかそういうのあるんですか?
未定ですね、答えとしては。
未定だけど、
まあでも当分やりたいかなっていう、
なんか少なくとも自分の代わりが入ってきたり、
埋められる場所が出てこない限りはやんなきゃいけないし、
必要性があるうちはやるよっていう。
必要性は多分一生なくならないんで、
まあ、やり続けるんじゃないかな、
で区切りとかも全く決めてないですね。
なんか開発は、
いやー、
なんかめちゃくちゃパラダイムシフトが
4回ぐらい起きなければ戻れると思ってるから、
またなんか結局、
あ、そう、もう一つソフトエンジニアの経験があると、
いい強みとしてはツールめっちゃ作れるんですよね、セキュリティの。
うーん。
なんか結構、
いやーちょっと見てる世界が勝手に言ってるかもしんない、
勘違いだと、
それは違うっていう方がいたら、
DMは怖いな、
まあでもDMでいいですっていう、
くれていいんですけど、
その、
まあセキュリティ業界でいろいろその、
大概的に採用活動とかをしていく中で、
まあセキュリティってめちゃくちゃ、
セキュリティのお仕事っていうのがマジで幅広すぎて、
かつ深いんで、
なんか多分大きい企業になればなってことを、
どうしても分業せざるを得ない、
領域だなと思ってて、
それこそ、
今、
今というか、
まあ今もですね、
そのGoogleがなんかコーシャーっていう、
授業受けられるやつで、
なんかサイバーセキュリティの授業無料で、
2万名かなに、
受講金かかりますって、
面白そうだから、
受講してみてるんですけど、
結構、
まあその講座の良し悪しは、
その講座の中で、
Googleで実際にいろんなチームで働いている、
セキュリティ領域で働いている人が、
3分間くらい、
自分の仕事の面白いことを話すみたいな、
この言語開封の、
僕のぐだぐだ話してるバージョンじゃないのを、
めっちゃかっこよく、
3分間の映像でまとめみたいなことを、
彼らがやってるんですけど、
まあそれ見てるだけでも、
やっぱ本当にめっちゃ分業されてるんですよね。
例えば、
セキュリティ関連のアクティビティログが、
まああるツールでバーって出てきてて、
それを監視して、
何かあらたがかったらチェックする人とか、
個人情報を取り扱うために、
そのポリシーの遵守を徹底する人とか、
分業されていて、
分業されると、
いいこととしては、
自分の領域にフォーカスできるし、
セキュリティってめちゃくちゃ深いんで、
どんどんどんどん深くできるんだけど、
うちみたいなベンチャーで、
そういう人材が活かせるかというと、
活かしてあげられないと思うんですよね。
うちはなんか全部15点みたいな状況なんで、
1つ100点取ってもしょうがないみたいな状態になると、
全部15点からまずは30点とか、
30点から50点あげるとしなきゃいけなくて、
そうなった時に特定のセキュリティ領域では、
エンジニアリングの力がめちゃくちゃ有用な領域があって、
さっきのパッケージアップデートの話だったら、
アップデートの取り味を簡単にするためのツールがあったら、
運用ってめっちゃ効率化できるよねとか、
いろんな場所で効率化の余地があって、
そこでコードが書けないってなると、
多分積むというか何もできないんで、
どっかから開発リソースがいっぱいあるしかないか、
開発できるメンバーをセキュリティチームに呼ぶかしないといけないけど、
ソフトエンジニアであれば書けるんで、書きゃいいじゃんっていうのは、
マジでめっちゃいいところだな。
ソフトウェアをまともに、
ソフトウェアをゴリゴリ書けますっていうセキュリティ領域の人は、
意外と多分市場にはそんなにいない。
いるんですけど、めちゃくちゃ高いお給料で、
もう各地にドンって、
もうその会社の柱になってる。
採用するのは実は絶望的なんで、
そういう意味ではめちゃくちゃソフトエンジニアのバックグラウンドは強い。
確かにね、
外からセキュリティできる人っていう募集の書き方をしてもね、
よほどその会社の事業に共感してるとか、
セキュリティをガンガンやれる土壌があるとか、
そういう強い動機がないと、
リボルピングドアの概念
もちろん今いる会社が嫌になったら普通にやめると思うんだけど、
でもなかなか採用するのは大変なので、
その中の人材からコンバートするっていうのは、
イコールの戦略の取り方なんで、
なんかね、分かんないですけど、
例えば、キリン以外にもね、
ちょっとセキュリティやってみたいっていう社内の人材がいたら、
ちょっと行ってコンバートするのを手伝って、
自分が先に戻るのか、コンバートした人が戻ってくるのか分かんないけど、
そういった意味で、
よく国だとそういうスキルの話を、
リボルピングドアって名前で色々説明してたりするんですけど、
行ったり来たりするような、
やり方があっても面白いと思いますし、
それは自分のスキルの幅を、
割とリスクをかぶってくれる人は先にいるわけなんで、
そういう気軽に、
とは言わんけど、
ちょっとやってみようかなぐらいで本当にできて、
それはいい環境なのかなって思いましたね。
そうですね。
もっとこういうのを許容するというか、
こういうところに投資する会社が増えたらいい。
例えば僕が、
今の会社もういいかなっていうか、
転職したいと思って、責任をしようと続けたいと思って、
エグザクトリーマッチなJDってあんまないんですよ。
やっぱセキュリティの職種は、
セキュリティの結構深い経験、
例えば脆弱性診断はSOC、
そういう。
資格はあんまないですけど、
これ必須だったら応募できないなってやつがどうしても多くて、
もしくはセキュリティ見習いみたいなJDたまにあるんですけど、
たぶん給料下がるんですよ。
そのリスクを取ってまでやりたいかどうか、
見かけなきゃいけない。
僕としてはソフトエンジニアからセキュリティに、
セキュリティにめちゃくちゃ興味のあるソフトエンジニアに、
その人のソフトエンジニアとしての能力と同水準の、
報酬とか待遇をした上で、
セキュリティに従事してもらうっていう世界は、
結構、
今人材が全くいない状況では、
そこに着目して、
今閉じちゃったJ社でも、
ジョブディスクリプション開けたりしてたんですけど、
あんまりそういう動きって、
そんなには見かけないなって、
すごい問題提起みたいになっちゃったけど、
フラットに業界を見て、
それが当たり前の世界になったらいい。
セキュリティ業界の魅力
最近じゃなくて、ここ1年くらい思うように。
面白さは語り尽くせたでしょうか?
面白さは、
あと2時間くらいはいける。
すごいね。
もう1個だけちょっと話。
ガッと収めるんで。
僕が無知だっただけだったら、それはそういうオチでいいんですけど、
セキュリティの仕事に身を投じて、
いろいろ勉強するじゃないですか。
死ぬ気で勉強して、
結構面白いなって思ったのは、
思ったよりちゃんと、
この世って危ないんだなって知れたのは結構良くて、
ソフトエンジニアとして働いてる頃は、
作ることに目が向く。
キャッチアップする技術って、
僕だったらノードJとかそれにまつわる有名どこのフレームワークとか、
フラッターの最低限のアップデートノートを読むとか、
そういうところに目が行って、
セキュリティニュースっていうのは、せず読んでもPOログを読む。
流れてきたPOログを読むとか、
Twitterで流れてきたヤバいこの漏洩みたいなのとか、
テレビでも取り上げられるようなレベルの情報漏洩のものを見るとか、
レベルだと思ってて、
それも別に悪くはないんですけど、
ちょっとやっぱ対岸な価値観に舐めないなっていうのを今振り返ると結構思っていて、
一方で、
色々セキュリティの仕事をするには勉強せないかなと思って、
色々勉強してみると、
結構自分は牧歌的な感覚で働いてしまってたんだなと思ってて、
一つは普通になんか、
世にある脅威は全然対岸の価値ではなくて、
気づいてないだけで自分の会社の情報全部引っこ抜かれてても、
多分僕も驚かない体になったの。
本当に、
自分の価値観だなっていうのをひしひしと肌で感じられてるのは、
学びだなっていうのと、
あともう一つは、
なんか、
僕は過去の自分への戒めなんですけど、
整善説という言葉をすごいよく使いすぎてきたなって思ってて、
例えば権限管理整善説で、
初期はスピード大事だから全員ざっくり権限付けてやりましょうとか、
こんなちっちゃいサービスなら攻撃されないでしょうじゃないけど、
まあまあ多少がわくてもいいでしょうじゃないけど、
なんかそういう無意識とか、
無意識的にも無意識的にもそういうのってどうしてもある気がしてて、
で、そういうのいろんなものを整善説で、
まあライブ版はいないでしょうとか、
まあそういうのでやってきたけど、
なんかそれがやっぱその整善説でこうやってますっていうのは別に攻撃する側かしたら
マジで関係ないし、
ありがとうございますじゃないですか、
おいしい穴作ってくれてありがとうでしかないから、
やっぱそこは正しく向き合わなきゃいけないなったっていうのは、
まあ面白いというか、
まあなんか思った以上にちゃんと戦争だなって思ったのは結構面白い、
面白いしちょっとこの2週間くらい若干目絶望して、
勝てないよとか思ってたんですけど、
技術的な不安と向き合う
まあまあでもかといって営み辞めるわけにはいかないので、
できることを限られた評論でどうやるか、
結構リアルファイト感がありますねっていうのは面白いと思います。
そうだね、
なんか我々は日々脅威に接しているっていうことを
必死必死と感じるよね多分、
アプリケーションの構造を描けば描くほどそういうものって、
既存のものに守られているところはもちろんあるんだけども、
逆に言うと自分で作った実装で簡単に穴が開いちゃうみたいなことはね、
よくある話だと思いますし、
まあそういったところもあるんですけど、
自分で作った実装で簡単に穴が開いちゃうみたいなことはね、
よくある話だと思いますし、
まあそのセキュリティ的なインシデントにはならないけども、
ユーザーの不信感を煽るような仕様にしてしまうとかもあるからね、
なんか本当にその辺の素養は俺も欲しいなと思った次第でした。
いやー、なんかね、
でもやっぱ作るのと違うっていうのを、
僕の尊敬するセキュリティエンジニアめっちゃ言うんだけど、
本当そうだなとは思ってて、
そこが不条理だなと思うね。
人間の脳が守ることも考えながら、
爆速で作るっていうことができる構造になってたらいいんだけど、
多分そうじゃないなっていうのは。
現実世界はやっぱ難しいな。
まあでも現実世界はベーシックなやり方は、
前に進める人と守る人で分岐をしてやりましょう。
きちんと密に消しましょう。
そこでも不条理なのは、
なんか最近読んだ本に書いてあって、なるほどなと思ったけど、
守ってくれる人がいると、
人は無意識にセキュリティレベルを落とすっていう話があって、
そこともセキュリティの人向けなきゃいけないっていうのはめちゃくちゃ、
いやーって感じの結構、
それはね、ちょっと、
これいい機会なのでリスナーの皆さんに知っておいてほしい。
僕の知った不条理。
最近は帰って安全じゃなくなるっていう話があるんですよ。
それは最近読んだ本に書いてあったんですけど、
そこであった例えは結構面白くて、
セキュリティの話じゃなくて、別の領域で話をした例えというか、
エビデンスを出して、
一つはパラシュートで落ちる時の自分でパッと開いて、
安全に降下する。
あれを例えば気を失ったら開けないんで当然死んじゃうんですけど、
気を失ったり何かの理由で開けなかった時に、
自動で開く安全装置っていうのが何年か前からあるらしいんですよ。
それを導入してからの方が死亡率が上がってる。
それはなぜかっていうと、
それがあるっていう無意識のおごりがあるから、
危険な行動に出やすくなってしまうとか、
あとアンチブレーキロック、名前忘れてた。
ブレーキが自動でかかる自動車の仕組みがあるんですけど、
あれが導入されてからの方が、
運転手が出すスピードが何パーセントか上昇してしまって、
かえって事故率の話とかがあって、
セキュリティも多分、サイバーセキュリティも一緒で、
結構僕考えなきゃいけないのは、
例えば権限管理は、
セキュリティチームが全部見てるんで大丈夫ですみたいに言い切っちゃったり、
そういう認識をしてしまうと、
多分みんなセキュリティが見てくれてるから大丈夫って言って、
目の届かない、目の届いてないってことに本人たちが気づかずに、
雑な権限設定をしてしまうとか、
ちょっと雑なアカウント管理をするとかっていうのが多分全然起きるから、
いやそれはね、
めっちゃ理不尽だなと思いながら、
そういう理不尽さと向き合うのも面白いっていうか、
ソフトエンジニア開発にはあんまないなと思うので、
結構面白いと思います。
好きな人は本当に好きだと思う。
これは聞いた。これ伝われ。世の皆に伝わってくれ。
安全じゃないんだ。
一人一人が気を付けるしかないんだ。
まあまあまあ、
そうですね。
バランスだと思いますので過度に不安になる必要はもちろんないと思いますけど、
そういった話もあるよってことはね、
認識しておかなきゃいけないので、
いやー今日は勉強になりました大変。
いやー面白いよやっぱ。
面白いと思う。
会う人は本当にお勧めしたいな。
なんかめんどくさいっていうのもあるから、
会わないパーソナリティーはあるかもね。
俺なんか割とキチキチ詰めるの実はあんま嫌いじゃないんで、
そのパーソナリティーと合致してるかも。
万人に勧められるかというと分かんないけど、
でもね、かじるぐらいはやってもいい。
ちなみにダティッシュは仕事からそんなに別に多分、
ソフトエンジニアよりは間違いなく意識がある。
だから相談もいるよ。
打ち返せるかどうか。
いやーそうだね。
エンジニアをやればやるほど、
そういったところに目が行ってしまうというか、
自分の書いてるコードに対する不安、
コードに対する不安は別にあれなんだけど、
自分が決めた実装の仕様とか技術的な仕様って、
本当にそういう要件守れてるんだっけってことは、
割と常に考えていて、
昔に比べるとそういう意思決定に、
逆に自信がなくなってきたってことはあるかな。
知識がついてきたときの。
そうなんだよ。これでいけると思うんだけど、
いやでもこういう穴あるよなみたいな、
毛穴みたいに小さい穴とかを結構発見しちゃうこととかあって、
これは多分僕だけじゃなくて、
周りの人たちにも、
僕より年上のエンジニアとか見てても、
結構そういう毛穴みたいなところに目が行って、
僕からすると、
なんでそんな細かいところやってるんだろうって、
見えることももちろんあるんだけども、
たぶん後々見たら、
エンジニアリングとセキュリティの関連
その毛穴みたいな穴が実は大きな穴でしたってことは全然あるし、
それこそ氷山の一角でしたってこともあったりすると思うんで、
なんか、
エンジニア極めるとこうなっちゃうんだなっていう、
こうなっちゃうっていうのは、
いい意味でこうなっちゃうんだなっていうのは思ったりしますね。
個人的には結構、
例えばデザイン段階とかでそこまで考えてくれてるだけで、
マジで150点だと思ってて、
なぜかというと、
何も考えてない人の方がめちゃくちゃ大多数占めてるので、
そこまで考えてくれてるだけで、
大多数占めてるので、
悪さできないかとかそういう視点を持つだけで、
たぶん100点で、
かつそこまで深く考えてたら150点だと思ってて、
ただ150点イコールそれで安全ですっていう話ではないのが、
ちょっと難しいところだよねと思って、
でもそこで安全を保証しようと思うと、
ソフトエンジニアがスーパーマンにならなきゃいけなくなっちゃうんで、
いろんな脆弱さを知ってて、トレンドを知ってて、
自分が使ってる技術でありがちな脆弱さを知っててとか、
それこそ脆弱性信頼員のスキルセットを持ってないと無理じゃんみたいになってきちゃうから、
やっぱそこは、
たぶんそこまで求めるのは違うし現実的ではないから、
そこまでいかなくてもいいけど、
認可制御漏れてませんかとか、
これってブログコメント機能で、
これ1万文字のコメントを投稿したら、
データベースぶっ壊れないんだっけとか、
そういう視点を持つだけで全然150点で、
その先のちょっと知識かしらんとわからんとかやつは、
マスキチームが何かしらの方法で担保するっていう世界が、
今の世界では最適解だし、
だからそんだけありがとうございますって気持ちですね。
みんなだって今言ってくれたように考えてくれてたら、
本当に十分だな、
また時間がなくてもその時間を取ってくれるかとか、
仕組みとしてそれをスキップできないようになってるか、
スケールとか考えると、
仕事の実例出して話したいな、
仕事がそれがやりづらいっていうのがちょっと、
ちっちゃいデメリットかもしれない。
これができてないって宣言にならないように挟まなきゃいけないんで、
そこが難しいなと思って。
聞きながらこれ自分話したら、
どこまで何喋れてるんだっけっていうのをちょっと考えながら聞いてましたけど。
そうだね、本社は何も話さないのが一番安全。
そうだね。
にごさん、にごしてこ。
でもありがたいです。
本当に開発チームに、
各開発チームのリード的なポジションの人が、
だてしみたいな思考回路になってくれたら、
たぶん相当やりやすいかもしれない。
ソフトエンジニアの方、声をはずいてみてください。
なんかセキュアバイデザインって本がめちゃくちゃよくて、
それを読んだことないな。
だてしは読まなくて。
興味があれば読んでください。
いやー、やっぱ2時間語れるな。
ちょっと切り上げよう。
面白いですよ。
面白い、本当に。
要はそんな悪さ考えるなっていう世界ですよ。
開発チームの取り組み
そんな使われ方すると思わないじゃんみたいな気になっちゃうけど、
現実的にそこについてくれたらバトルですね。
いやー、そうですね。
いやー、なんか僕レベルでも登壇できるセキュリティの勉強会ないかな。
話して、いろいろ。
なかったら作ればいいって誰かが言ってたよ。
いや、そうだよね。
ちょっと、やるか。
やりたい。
いや、1回やったんですよ。
1回やって忙しさを言い訳にできてないんで、
ちょっと頑張って。
ちょっとここでの宣言を持ってやろう。
それこそね、聞いてる人にそういうの一緒にやってあげてもいいよっていう、
優しい人がいたらDMくださいっていう。
ください。ガチで。
今回のは本当に欲しいやつだよね、理由はね。
いや、毎回欲しいよ、俺は。
一応毎回ね、本気で。
毎回ネタみたいに出ますけどね。
恥ずかしいんでね、こちら開けちゃうんですけど。
はい。
こんなとこかな、今回は。
タイトル何にしようかな。
まあ、適当につけます。適当につけますが。
今日はタイトルがありませんでした。
いや、私の仕事の面白さを言語化するキリン編。
ああ、いいんじゃないですか。
キリン編を言語化しましたね。
次回、もしくはいつかダジェイションの回か。
いや、ダジェイションの回聞きたいな。聞きたいんで、
まあ、僕は聞いておきます。
説得しとくんで、皆さんは。
じゃあ、ギリギリのラインまで話せるように考えておきます。
お願いします。
そんなわけで、今回もお話ししました。
それではまた次回お会いしましょう。
バイバイ。
40:15

コメント

スクロール