00:00
こんにちは、言語化.fmは、あんな話やこんな話を、キリンとダテの2人でゆるか話しながら言語化を試みるポッドキャストです。
というわけで、今回のテーマは、獲得した知識をどう活かすかを言語化したいです。お願いします。
難しいよね、獲得した知識を活かそうっていうのは。
難しいっす。難しいんで、ここやらで一回整理した上で言語化して、今後の人生を、ソフトウェアエンジニアリング人生を豊かにしていきたいなという、
なんかちょっと、なんか、日本語今日不自由な気がするけど、頑張っていければなって。
そこはね、そこは一緒にやっていきましょうということでね。
このトピック、なんか結構、昔にダテ氏が別の形でテーマとして挙げてくれて、その時はなんかこの本で学んだことをどう活かすかみたいな話としてネタとしてあって、
なんかずっと話しなかったんですけど、僕が最近、正式名称忘れたんですけど、通称セキュリティスペと呼ばれるIPAのセキュリティ関連の資格の試験を、ちょうど先週ですね、先週受けてきたところで、
元々のモチベーションとしては、育休中で、もし余力があるんだったらセキュリティ関連の勉強をして身に付けたというか、ある程度その実践に活かせる形でスキルを身に付けた上で仕事に復帰できたらなと思って、
というのも仕事でセキュリティチームの権利というか、一員ではあるので頑張っていきたいと思っていて、ただ、そうなった時に今日のテーマに立ち戻って、それこそ本でいろんな知識を獲得するとか、
今回見て、セキュリティ関連の資格勉強をするっていうのは、ある程度、確かであるというか、確からしい事実を知識として人の脳みそに入れていく、いわゆる暗記していくみたいな側面もあるし、
あとはそれを土台とした上で、いろんな方法論とかベストプラクティスを学んでいく作業になっていて、資格に関してはそれをペーパーテストという形で、IPAの場合はペーパーテストという形で定量的な点数で新たな知識を獲得できました、できませんでしたという判定がされるみたいな感じだと思うんですけど、
このテストの点数を、高いテストの点数を取って試験に合格するとか、知識を暗記して、例えば僕最近別の本でWebの通信最適化みたいな本を読んでるんですけど、
03:06
キャッシュマークの仕様とかがバーって書いてあって、このヘッダーをこうやって使うといいみたいなのがバーって書いてあるんだけど、別にそれを暗記して業務で引き出しとしてすぐ出せるようにするっていうのは大事目的じゃなくて、
この知識を得た上で、それを趣味のプログラミング、仕事のプログラミング、どっちでもいいんですけど、プロダクト作りとか仕事にどう一番いい形で生かしていくのかっていうのを、
あなたの思うそのベストな方法を説明しろって言われたら説明できないし、そもそもどういうのがいいんだっけ、分かんないなみたいなところで、改めてこのテーマに向き合っていこうかなと思った次第でございます。
実際試験を受けてみて、何かこうやっぱり知識は得られたという感覚はあるもんなんでしょうか。
そうですね、まあでも得られた感覚はめちゃくちゃあるかなと思って、単純に知らない、僕にとってセキュリティという領域って、
一応ソフトエンジニアとしてやっていく中で、これは覚えておけよっていうものしか握れてないっていう領域だったんで、
セキュリティというめちゃくちゃ曖昧で広い領域の中で、自分が何を知らないかは知らないんですよ。
ウェブ界隈だったらこの知識は未習得だけど、これは習得してるみたいな感じで、未習得、何が未習得かっていうのは大体多分答えられるけど、
セキュリティは自分が何ができないかっていうのはわかんないっていう状況で、その中で今回受けて、自分が何が未習得なのかっていうもののうちのいくつかは明らかにできたっていう意味ではめちゃくちゃ学びがあったなっていうところと、
あともう一つは、今までセキュリティちゃんとしよう、セキュリティ頑張るみたいなふわっとしたものに対して、じゃあ具体的にどう体系化して進めていけばいいんだっていうとか、
どういうマス目を埋めていったらセキュリティちゃんとやってると言えるんですかみたいなところに対して、全く打ち返せなかったところを今回獲得した知識のいくつかを使うことで、
これはこういうフレームワークで考えていけばいいんじゃないかみたいな、使えそうな枠とか考え方をいくつか暗記したわけではないけど、インプットできたりとか、存在を知れたっていうのがめちゃくちゃでかかったかなって。
そうね、セキュリティ特有の話というか、今言ったようなフロントエンドの技術を知ってますっていうのと、セキュリティとか現象とか、そういうアイソスタンダードな話を理解してるのかっていうのは多分レイヤーが違う話で、
確かに前者は知ってた方が武器にはなるけど、防御力は上がんないみたいな感じだよね。たぶんボロボロの鎧を着てる状態で穴があるとそこを突いて、それがそのまま静寂席になるんだろうけど、になっちゃうようなところと同じようなアナロジーで、
06:20
たぶん知識に穴があると、いざ引き出そうと思っても応用が効かないみたいになるのがセキュリティなんだろうなというふうに話を聞いていて思ったので、確かに網羅的にCBTとかで四択問題とかで四択可用みたいな批判はあるのかもしれないけども、
それで知識を総チェックできて、何ができないのかわかるっていうのはなかなか意味のある話かもしれんね。
なんか綺麗に頭の中で何が良かったかみたいなところはスッキリした気がするわ。これをどう生かすかとか、どう生かしていくかだよな。
生かすって言うと何なんだろうね。
なんか結構個人的にはすごい抽象的な感覚だけど、知識を獲得した自分からその知識を使いこなして自分のギャップをどう埋めるかがすごい不安を感じるというか、何だろうな。
多分今までできたときはできた。今までも多分何回もやってきてるはずなんだけど、こういうふうにすればいいみたいなのが自分の中でそんなに確立されてない、もしくは自分で認識できてない感覚がすごいあるかもしれない。
多分さっき話そうかどうか迷ったんだけど、多分本の話をしたときにも似たような話をしてるんじゃないかなと思うんだけど、多分知識を獲得するフェーズと運用するフェーズというのが多分あると思っていて、
試験勉強って知識を詰め込めますっていうのは広く言えば獲得するフェーズであって、それを実務に応用したりとか、いざというときに引っ張ってくるっていうのが運用の話だと思って、
使いこなすっていうのはある種運用の話なので、じゃあどうやってその運用の経験値を積んでいくのかっていうところだよね。それは資格試験で継続的に得られるものなのかなっていうときは結構会議的な話だし、
じゃあ常にそこら中の障害対応をしてればいいのかっていうと、そういうわけでもなかろうと、なんだろう障害なんて起こらない方がいい決まってるので、それを防ぐためのセキュリティだったりする話だと思うので、そういうのをどうやって技術的に体験できるのかなっていうのはちょっと気になったかな。
あと、結構話聞きながらパッと思い出したのは、やっぱ実践に持ち込むってなったときに、活かしやすい知識と活かしにくい知識があるなっていうのに今自分の中で気づいて、例えば僕はフロントエンド、別にできるわけじゃないんですけど、いろいろキャッチアップしたときにそれを活かそうと思ったら、
09:17
自分でちっちゃいアプリを自分だけのものを作って、ちょっと運用してみればすぐできたりもしたし、新卒時代とかにhttp2が出たらやばいじゃんっていうか、キャッチアップしなきゃみたいなときとかはRFC全部バーって読んで、JISをちょろっと見たり、自分でサーバスで設定して、デベロッパーコンソール見て確かめるみたいなことができたけど、
例えばセキュリティとか、あと今僕が読んでるCDNの最適な運用みたいな話とか、あと何だろうな、たぶん探せばいくらでもあると思うんだけど、自分の趣味の範囲では試せないんだけど、業務だったら試せる。
ただ業務でぶっけもまで試したときに、自分がそこまで自信のない領域っていうのをどう活かしていくかみたいなのが結構難しいかもっていうのに気づけました、自分は。
たぶんもうちょっと体系化されるといいのかなと思っていて、セキュリティスペースちゃんとやったことないからわかんないけど、セキュリティの領域もISOでちゃんと国際表示になってて、RFCと同様に多分スペックが出ていて、
なんていうか、どういうツールを使うとかまでは書いてないと思うけど、どういうコンセプトでこれが制定されるのかみたいなことはたぶんRFC同様に書いてあるんだろうから、そういうのを読んでみるとかで、その体系的な理解を得るみたいなのは1個あるかもしれないよね。
確かに大枠から埋めていくじゃないけど。
ある意味読み解くだけでも結構骨の折れる作業だからね。
あとは身も蓋もないことを言うと、何を考えていたかというと、ある程度失敗してもいいからスペックを言わずにやるのも大事かもなって気もしてて、
っていうのも多分自分が獲得した技術とかスキルを仕事で活かしたときは多分そういうことをしていて、結果いろんな技術的不才みたいな行動という形で残してきたりもしたから、
それらを繰り返したし、去年EMOやってたときも上手くいった部分もあれば上手くいかなかった部分もあって、でもやんないとできないみたいな部分はあるなって気はした。
だからセキュリティはチョンボするといけないので、まあでもシンプルか。チョンボしても大丈夫な領域なんてどのセキュリティかけずなんでもないけど、
小さく少しずつリスクの低いところからチャレンジしていってじわじわ進めていいのかな。
12:05
なのでさっき言ったところの話をすると、多分失敗できる環境を作った方が良くて、いきなり本番運用すると死ぬので、
そういう環境をプレイングラウンドみたいなものを用意して、技術的にこういう穴があった場合にどうなるかっていうのを見るみたいなことってできるのかね。
ネットワークを分離すればできる?
なんかそうだな、ちょっと地に足つけられてないというか、セキュリティ領域がちょっとありふやすぎて地に足つけられてないんだけど、
今、例えば新しい技術、フロントエンドの技術みたいなので置き換えると結構シンプルかもっていう気がしてて、あるあるはお客さん向けの本番アプリじゃなくて、
内部管理画面の1ページでだけちょっと使ってみて試すみたいな、運用してみるとか、
そういう考え方でいけそうな気はする。
セキュリティを置いてその切り口がどこかっていうのは、いましてに僕の中で何かはっきりしたものがあるわけじゃないし、
これから考えなきゃいけないけど、考え方としてはそういう考え方でいいんじゃないかなって気はする。
なるほどね。
まあでも、獲得しました。
それを活かして、個人的には活かしやすい知識と活かしにくい知識があって、
多分活かしやすいのは自分の持っているスキルの延長線上にがっつり繋がっているような、
自分の持っているスキルの延長線上にがっつり繋がっているような、
自分の持っているスキルの延長線上にがっつり繋がっているような、
自分の持っているスキルの延長線上にがっつり繋がっているような、
自分の持っているスキルの延長線上にがっつり繋がっているような、
気合で切り込む小さい切り口を探すと。
もっと踏み込むなら、その切り口をどうやって探すねっていうところが、
ケースはケースかなって気もするけど、見つけられたら綺麗な話だなって気がする。
今の聞いててちょっと思い出したことは、
IOSのドキュメントとかもそうなんだけど、
この関数を使えばこれができますみたいなことは書いてあるんだけど、
その分野のバックグラウンドみたいなところとか、
15:03
どうしてこれがこういうふうになっているのかみたいな、
これまではさすがに書いてないことがやっぱり多くて、
でもそういうセキスペとかIPAのコード試験とか、
あとISOの話とかRFCとかもそうだと思うけど、
そういうなんか標準を読むとバックグラウンドが得られるんじゃない。
その目たい知識が得られて、その知識を持った状態で改めてドキュメントを読み直すと、
あ、これはRFCに書いてあったやつやみたいなとか、
例えばEメールのフォーマットとかも全部RFCで規定されてるわけでしょ。
そういうのを感じ取って、だからこれはこうなっているのかみたいな、
そのドキュメントの読解みたいなことに多分応用できるなっていうのは、
経験上僕もあって、新しい領域とかちょっと日常領域触るときに、
どうしてもやっぱりRFC読んだりとか、
そのISOのやつをダウンロードして読んだりとかすることもあるんだけど、
それを読んだ上で提供されているAPIを眺めに行くと、
ああ、これはじゃあこういうことをマッチするよね、
ここはマッチしないよねみたいなのが大枠見えてきて、
それはそれで楽しいし、遥かに物事が進むやり方だなというふうには思ったりしますね。
なるほど、確かにすぎるね。
だからさっき言った俺の一つ目の分岐点がそもそも多分それと同一な気がしてて、
自分の延長線上っていうのは自分が大枠を把握したりするからサクッと導入できるし、
そうでないものに関しては確かに大枠からきちんと掴んでいくっていうのはめちゃくちゃ有効な気がする。
仕事の基本やな。なぜというか、ホワイオを吹き詰めましょうじゃないけど、
パーツだけ見てもってか。確かに。
あとは人に説明するときにそこがあると強いんだよね、やっぱり。
勉強会とかで語られがちなのはやっぱオアットの部分で、
こうすればこうできますは時間の制約上しょうがない部分もあるんだけど、
やっぱりそれを突っ込まれたときに答えの柱となるのはYの部分じゃないですか。
そこが分かってて、俺はこういう理由でこうなってるんですよってなると、
やっぱり相手が納得したりとかするじゃないですか。
確かに。間違いない。
自分自身も納得させられるってことは自分自身も深く理解した上で、
自分も納得してる焦点しないといけないから、
一つのベンチマークとしてめちゃくちゃいい。
珍しくこんな短い時間でスッキリし始めてる。
18:07
そこにもう一個加えると、最近どこで話したか覚えてないんだけど、
対相手に説明するときに、やっぱりストーリーで語らないと
人は納得しないよねって話をしてて、
まあそうやなと思ったんだけど、結局その相手の言ってることを飲み込むためには
やっぱり自分にもそれ層の意見が何かしらあるわけで、
じゃあ例えばAという実装とBという実装があったときに、
僕はAの方がいいと思うんだけど、向こうはBの方がいいと思ってるっていうのを
打ち崩さなきゃいけないときに、絶対にYの部分から始まって、
一通りどういうベネフィットがあるかとか、ランギングコストを考えたらこうなるとか、
一通りのストーリーを作って説得にかからないと、相手絶対折れないと思うんだよね。
それで、いやそこは違うと思うみたいな反応が飛んできたときには、
いやそうじゃなくてねって言ってちゃんと押し返せるとか、
それが議論のあるべき姿というか、そういったことをしていかないと
自分のやりたいことというか、あるべき姿にたどり着かないような気がしてるから、
そこも含めてストーリーで語れるようにならなきゃいけないなっていう風に最近思った次第でした。
いやでも間違いないね。本当シンプルに目線を揃えていくみたいな話かなって。
もう完全に何の異論もないわ。
目線が揃ってないとな、なんか、たとえ実際AとBの結果というかインとアウトがもし仮に同じだったとしても、
いやー、とかなんかその、自分で今散らかそうとしてたけど、
なんかやっぱその何かを意思決定しなきゃいけないときに、その結果に完全に客観的な得点をつけられる場面って
たぶん仕事によってはほぼないはずで、だから実装Aが70点、実装Bが50点、だから実装Aですみたいな話はほぼありえなくて、
その時にどこを目指してるんだっけ、何を達成したいんだっけをどれだけ深く掘り下げて、お互い開示した上で、
それすり合わせた上で、じゃあ改めてどっちがベターなのかみたいなのを合わせていく必要があるよね。
実装の場合はちょっと例があんまり良くなかったかもしれないけど、最低基準としてたぶん50点ぐらいのラインがあって、
そこを満たしていれば一旦どっちでもいいよ、それでやってみようぜみたいな話になって進むような気はするんだけど、
21:01
もっと対極的なアーキテクチャの話とか、出戻りが効かないような部分に関してはやっぱりそうやって進めないといかんよねと思ったりするんだよね。
あと最近マネージャーをやってると、やっぱりストーリーで語る部分が結構増えるなと思っていて、
何でかっていうと、マネージャーとメンバーの情報量って対象じゃないんですよね。
絶対的に非対象になっていて、組織によるのかもしれないけど、たぶん大体マネージャーの方が情報を多く持ってますと。
で、それをメンバーに適切に下ろさなきゃいけませんってなったときに、たぶん僕の考えの悪い例はここに書いてあるからこれを見ておいてなんですよね。
そこの見ておいてのところが、ちゃんと綺麗に起承転結なのか、Yから始まっているのかわかんないけど、
ちゃんとストーリーがなされていて、読めば理解できる同じぐらいの情報量が得られているようになっているんだったらいいんだけど、
そんなことは到底あり得ないので、やっぱり直接ちゃんとストーリーで語っていかなきゃいけないし、何ならストーリーでメンバーを引っ張っていかなきゃいけないっていうのをよく感じているんですよね。
ビジョンを語るんじゃないけど、結局上のレイヤーに行けば行くほど話は抽象度を増していくので、
いかに先の話を具体的性が描けるように語っていくみたいなことが求められてくるなぁと最近は感じております。
なるほどですね。
最高の近況報告です。
情報の非対称性があるっていうのは、わかんないけど、俺の経験上も観衆も基本そうなってるし、
縦の階層で区切っているマネージャーっていう観点だったら基本はそうなってるよねってそう思うわし、
その上でストーリーで語るみたいな部分がすごい大事っていうのもわかるっていうか、結局何も言ってないみたいになってるんだけど、
でも一時期マネージャーやった身としてはめちゃくちゃ同意するね。
エンジニアマネージャーの仕事という本がこのポッドキャストに何回か出てきてますけど、
適切な情報、適切な量をきちんと下ろしましょうみたいなのがどっかに書いてあった気がしてて、
その中の情報がただ事実をこれが決定されました、これをやりましょうみたいなのを下ろすんじゃなくて、
それに説得力を持たせるとか、どういう目線でそれに取り組めばいいのかみたいなのをきちんと、
24:02
マネージャーの上、上は何か組織の手違いなんですけど、会社とかCTOとか、
系層とマネージャーがきちんとシンクできるべきだし、
マネージャーはシンクされたものを同じようにメンバーにきちんとシンクしなきゃいけない。
その時に手段としてストーリーで語るっていうのがめちゃくちゃ大事っていうのは本当に同意というか、
自分ができてたかどうかは分かんない、ちょっと自信、そうですね、分かりませんがめちゃくちゃ大事だと思います。
ストーリーね、そうなんだね。逆にストーリーで語る以外の方法で目線を揃える方法はあるのかな?ない気もするよね。
たぶん逆のアプローチで、逆にマネージャーが情報が全然ありませんってなったら、
メンバーからうーんと話を聞くしかすべはない気がするんだよね。
そのメンバーが仮にストーリーを語るのがそんなに得意じゃなかった場合、
たぶん情報が断片的にバーって出てくるので、それを拾い上げて、正義して、
ストーリーをこっちで作っちゃって、つまりこれってこういうことだよねって言って、
そのストーリーを相手と共有して、そういうことですよって話になったら、それは一個ゴールじゃないですか。
つまり何が言いたいかっていうと、この言語化FMはそういうことをやってるんですよっていう感じです。
なるほど。やばい。言語化、第ゼロ回じゃんこれ。言語化FMを言語化したね。
なるほどね、確かに。間違いないわ。
そうでしょ。
ストーリーだね。このテーマ、つまり何がしたいのあなたっていう話をしてるね、確かに。
なるほどなー。なんかおもろいなー。すごい。
いろんな話をループしてる気がする。
今の話は間違いないし、なんか普通にシンプルにイメージクリエーションを持ったのは、
いろいろ掘り下げていくと、結局本質を出たみたいに俺はなっちゃうんだけど、
EMだからそのスキルが際立って重要っていうのは際立つと思うんだけど、
多分EMでなくても何かの意思決定をするような仕事をする立場のメンバーなんであれば、
ストーリーを語る能力も大事だし、ストーリーを引き出す能力もめちゃくちゃ大事だなっていうのは改めて思ったわ。
実際エイビーの話で、自分が開発1メンバーであっても自分が考えるストーリーを他の人に理解してもらわないと、
自分の出したカードがどういう意味を持つかってのは伝わらないし、
相手の出したカードの意味が伝わってこないときに、もちろん全員が全員ストーリーを語れれば、
27:01
ドリームチームで働いてるんだったらいいけど、基本的にはそういうわけではないし、
価値観とかの違いから読み取れない時もあった時に、そのストーリーをきちんとその人から引き出して、
チームとしてのアプリケーションがより良いものにできるかどうかっていうことを考えると、
個人としてはストーリーを引き出す能力っていうのも身につけた上でこの業界を渡り歩いていった方が、
結果的に自分に返ってくるリターンは大きい気がするね。
まあね、そこまでやってくれる人は世の中なかなか少ない、
俺が会ってないだけかもしれないけども、結構希少な人材だと思いますので、
そういう我こそはという方は見てみてください。
自戦でね。
どうする?来たらどうしようか?
オンシャトーっていったら是非欲しいよね、そんな人材いたら。
欲しいよね。
なんていうか、JDにかけないじゃん、そういうのって。
かけないね。
それこそ言語化FMじゃないですか、それをかけたらね。
確かに。
難しいね。
個人的にはJDにかけないし、難しいな。
この回で話すと長くなっちゃうから話さないけど、
そういういろんなストーリーを引き出すのと話してもらうみたいなところを
補強するためのチームとしてのフレームワークとかはいくつか存在する気がするから、
ある程度その組織で求める振る舞いみたいなバリューとか言語化した上でやっていくっていうのが
今の大半の会社の回し方な気は個人的にはする。
デザインドックとかをすごい思い出しながら話してる。
そうね。
あれこそね、いかに
そうね。
デザインドックな話して、した気も絶対した気するけどして。
まぁまぁまぁ。
DM来たら、伊達氏の会社と俺の会社から。
ハイアリングが飛びます。
オファーが。
オファーが行くかもしれない。
行くかもしれない。
見抜くの相当大変だけどね、来たとしてさ。
いやぁ、そうね。普通に面接します。
面接からです。
面接から頑張ります。
一番最初に戻るところ。
いやぁでもスッキリしたな。獲得した知識をどう活かすかみたいなところ。
逆算すれば、俺の今回のセキュリティ全て得た知識があって、知識を得た状態の今の私と
行く際明けに働き始める私が、それを使いこなしてより良いアドプトを出すみたいなギャップを埋めるには
30:05
そもそもセキュリティで目指してるところとか、目指してるストーリーって何なんだっけみたいなところを見つめ直して
逆算していけば、じゃあどういうパスを辿ればいいかとか、どういう知識を補強すればいいかとか、どういう立ち回りをすればいいかっていうのが
見えてくるんじゃないかという気がした。
いやぁ、スッキリしたなんか。
良かったね。
めっちゃモヤモヤしてたわけじゃないけど、なんかセキュリティ受けて、多分受かった、自己採点でまだ分かるんですけど
ここ多かったなぁみたいな思ってて、受かるのがゴールじゃないから別に落ちてもいいし、これ生かして何から手をつけていこうかなみたいな
CTFやるかーみたいな、ふわっとしてからセーブできたのが良かったわ。
良かった、なんか話してて綺麗に話が繋がったなぁという気がしていて、ちょっとストーリーテイキングの話まで行っちゃいましたけど、そこまで行かなくてもね。
全然、いやストーリーの話もね、みんなストーリーかっこいいなぁして
そんな感じで、今回は獲得した知識をどう生かすかを、どう生かすかプラスアルファですね、を言語化しました。
また次回何を話すかわかんないですけど、ぜひお聞きください。それではみなさんさようなら。
