00:00
今回はですね、ちょっとどうやって新しいことを学び続けるかっていう話をちょっとしていきたいなと思うんですけど、
くにわけさんって、こう、どうやって新しいことを学んだりとか、情報を得ていたりしますかね。
僕の場合は、まぁだいたいXで流れてきたとか、あとはポッドキャストで聞いたとか、あとは時々、あのー、はてのブックマークとかで見かけたとか、
そんな感じなんですけどね、最近。どうですかね。
はい。私は、新しいことっていうのには2つあると思ってます。
まず、1つ目は世界にとって新しい情報です。
例えば、クロードコードにこんな新機能きました、カーソルにこんな機能きました、みたいな、こういうのがありますね、ニュースとかの類ですね。
もう1つは、世界にとっては新しくないんだが、自分の知らなかった情報の類です。
例えば、形式手法とか、人によっては低レイヤーの知識とかですね。
それぞれでインプットを探す場所は違うと思っていて、あと大事なのはやっぱりそのバランスだと思っていますね。
うん。バランスが重要。まぁ何にでも言えることなのかなとは思いつつも、
何か、そうですね。じゃあ例えば具体的に、何かこう最近こういうの、ここの場所で知ったよ、みたいな具体例あったりします?
そうですね。前者、例えば新しいニュースとかで言うと、クロードコードにこんな機能入ったねとか、やっぱりよく使えますよね。
で、あとは例えばオーパスの4.8が来たとか、そういう話とかがあって、
これは、私はよくハテナブックマークとかで手に入れてるんですけど、
もう一つのこう、自分が知らなかっただけで世界には元からあった知識っていうのは、私は最近よくチャットGPTとかから聞き出すことが多いですね。
なるほど。じゃあLLMに聞いて、もうちょっと話を深掘っていくみたいな感じの使い方をしてるって感じなんですかね。
そうです。で、これはチャットGPTとかディープリサーチの機能を使ったようなものでも、今はディープリサーチなんて言わないですけど、
例えばですけど、私がつい最近調べたのは2つのパターンがあって、1つは意思決定モデルっていうのが気になったっていうのがあったんですよ。
つまり、ケイソーとかの仕事を見ていて、ケイソーは我々に仕事を振るわけですよね。
我々は何か手に負えなくなったりとかしたらエスカレーションとかをするわけですけど、それがどうあったら最も効率が良くなるのかって。
これは一種の研究とかの体制になるようなものですよね。
こういうのって既存の研究ってどんなものがあるんでしょうかっていうのを見るために、やっぱ論文いっぱい読まなきゃいけなくて、
論文読んでとか、しかも専門外の論文ですよ。やっぱ大変なんですよ。
それはやっぱチャットGPTとかに読んでもらって、予約してもらって、こんな研究がありますとか、これは良い要素が多いですとか、そういうのとかから知識を得ているっていう感じですね。
ちなみにちょっと気になったのが、チャットGPTに聞くにしろ、
検索、Google検索、そのチャットGPTとかがなかった頃、おそらくGoogle検索して調べてたかなと思うんですけど、同じようなことをしてたかなと思うんですけど、
その時に一個重要になるのが、検索ワードだったりとか、あとはさっきので言うとあれですかね、意思決定モデルという単語ですよね。
それを知らないと検索したりとか、チャットGPTにも聞けなかったりするわけじゃないですか、そこってどうしてました?意思決定モデルってもともと知ってたんですか?
03:10
意思決定モデルは、いや、ちゃんとは知ってなかったと思いますね。どんな定義なのかとかは知らなくて、ただこれは多分私の造語でもあるのかな。
意思決定って何かありますよねっていうのと、それがどういうふうに数理的に記述されるのか。数理的っていうのは要するに数式ですね。
例えば、よくある数理モデルとかだと、上の人は下の人のやることは全部できる。
だけど下の人に任せないと上の層が飽和しちゃうから、下になるべく丸投げして、簡単な問題は下に投げるみたいな感じの意思決定モデルってあるんですよ。
こういうふうなやつが数式で書かれるんですね。何パーセントが下の人ができるみたいな。こういうふうなのが一種の意思決定モデルなんですけど、
これは一般的にはモデルって呼ばれてて、現実には人には感情とかいろんなパラメーターがあるんですよ。
やりたいこととか、ビルとか。そういうパラメーター一切抜きにして、仕事のできる部分だけを、この人はこの仕事ができる、上位層の人はこの仕事ができるみたいな感じで、
取捨選択してるのって基本的にモデリングって言い方をするようなものになっているので、その2つから意思決定モデルってのはきっとあるだろうと思って、
チャットGPTの検索キーワードで聞いたと。なんでそれで大丈夫かっていうと、一昔前の検索も、今のチャットGPTも単語の文字列の一致で見てないんですよね。
意味の近さで見ているっていうのがあって、これはベクトルとかで見てたりするらしいんですけど、
今自分の話している検索キーワードとかから、これはこんな感じの意味なんじゃないっていう意味空間へのマップを作って、それと近しいような文献を出すってことをGoogleとかやってましたから、
ドンピシャンじゃなくてよかったんですよ、元から。
完全一致である必要性はないってことですかね。
なかったってことです。たぶんこういうことがあるだろうなと思ったら案の定あった。そんな感じで使ってましたね。
じゃあ今回の意思決定モデルをチャットGPTに聞いてみたらどうでした。結構学べたというか、いい知見もらえましたかね。
そうですね、いい知見はもらえたんですけど、2つわかったことがありました。
1つは意思決定モデルって言うほど研究が進んでないんだなっていうのがまず1つの学びでしたね。
っていうのは、実際にいくつかのバリエーションの意思決定モデル見てみると、これちょっと現実じゃ使えないだろうみたいなのも結構食われてるんですよ。
それが意外と新しかったりして、まだ進んでない分野なんだなっていうのはまず1つ分かりましたね。
ただ、その中のいくつかの要素を取ってきたハイブリッドな数理モデルを考えると、今のうちの組織に近いっていうものを作ることができて、
うちの組織の意思決定モデルってこうだったんだ、これの良さ悪さってどんなものなんだっけって論文とかの解析とか解説とか整理すると、
あなたの組織ってのは、ただの計算はすごく偏らなくていいですねとか、なんだけど最適な意思決定をするとは限らないですねみたいなとか分かるんですよ。
そういうところとかっていうのでから、世界は知ってるんだけど、自分はまた知らなかった知識っていうのを学んでるって感じですね。
06:01
ちなみに今ちょっと聞いてて気になっちゃったので聞きたいんですけど、そのハイブリッドのモデルって具体的にはどういった要素を組み合わせたものなんですかね。
今私が勤めてる会社の意思決定モデルって、すごく日本語で説明するとこんな感じなんですよ。
まず現場の人たちっていうのは高い専門性を持っている人たちがいて、意思決定層は高い専門性を持っているとは限らないんですね。
つまり上の人は、下の人ができることは全部上の人ができるとは限らないっていうモデルになってて、
なんだけど上の人はより広範なリソースを制御する権限を持っていて、つまり人の大量投入をしたりだとか、
あとはプロジェクトの中小を決めたりとかそういう風な権限を持っている。つまりより強い権限を上の人が持っているってモデルなんですよね。
なので下の人は自分の部署の手に追えないぞって判断した瞬間に、上にエスカレーションするんです。
そうすると上の人がこれ自分の手で追えるかなっていうのを考えて、手に追えなかったらさらにエスカレーション。
これ自分の制御からできるなって思ったら制御するって感じです。
これは意思決定層の計算が結構小さくて済むんですよ。っていうのが良いところ。
なんですけど悪いところはエスカレーションが連鎖していくので時間がかかっちゃうんですよ。
緊急性のあるものとかって即応されないって問題があるっていうのと、あとは最適とは限らないですね。
つまりその良い解を見つけられるか、絶対一番良い解を見つけられるかっていうと相当は限らないっていうのが今回の意思決定モデルの特徴ですかね。
大前提、現場の人の方が専門性がある。
経営層の人たちは専門家ではなくてリソースの配分を意思決定できるという権限を持っているというような大前提の中でどう進めていくかというところ。
そうです。
っていうことなんですね。
そうですね。それとエスカレーションの条件がついてるって感じですね。
ちなみに何か具体として、これがハイブリッドのモデルとして良さそうだっていうのが分かった中で何か動いたこととかってあったりするんですか。もう何か動いてたりするんですか。
まずはやっぱり思うのは緊急性が高い案件とかがあったときに即応する能力がないってことなんですよ。この意思決定モデルだと。
つまり現場がこれダメだエスカレーションしようと思ってエスカレーションする子には手遅れなことがあるってことなんですよね。
なんでそういうふうな緊急度の高い情報を早期に上げるっていう仕組みを別で作っておかなきゃいけないってことを認識しました。
なるほど。レポートラインが複数あるだったりとか、あとは多段であるだったりとか、そういう意思決定者がいっぱいいたり、あとは反応が遅かったりだったりとかそういったところがあるから別で緊急度が高いものに関してはCEOに直結で渡せるようにする。
そうですね、例えばそれとあともう一つは観測ですね。例えばこのプロジェクト遅れそうだっていうのがわかるのって、PMが遅れそうですって報告した瞬間だと遅すぎて、それよりも前にPMって何かの情報を見てたはずですよね。
09:09
例えばJiraの進み状況なのかそれとも何なのかわかんないですけど、そういう位置情報を初めから意思決定者が見れた方がいいわけじゃないですか。
そのためには、例えばJiraの進捗とか理由の前にどれくらい終わってるか、超過してるものがどれくらいあるか、それが偏ってるかとかっていう情報ってのは全部意思決定者には最初から見えてた方がいいと。
そうするとエスカレーションは早くできるようになりますよね。そういうふうなことを考えてましたね。
なるほど、なんか一言で言うと透明性みたいな話なのかなと。
そうです、透明性です。
思いましたね。そのプロジェクトの内情というか、現時点のところを意思決定者が先に見れるようにするというか、気づけるようにしておくみたいな体制ですかね。
そうですね。
なるほど、そういったところが重要なんじゃないかっていうところで気づけたっていうところなんですね。
そうですね。
なんか元々のすごい根源的な話になってきちゃうかなと思うんですけど、そういうなんて言うんでしょう、この部分が足りないから、じゃあ自分はちゃんと例えば具体の学び方としてチャットGPTに聞いてみようみたいなそういうモチベーションがそもそも発生しないと聞きたりしないとは思うんですけど、
そういうところなんて言うんですかね、自分のモチベーションの持ち方だったりとか、そういったのってどうなってるんですかね。そもそもそういうのはないと思うんですよ。なんか窓棒みたいな感じ。
そうですね。私の場合は2つあるのかな。まず1つは、どっちも同じことで疑問を持つことがすごく大事だと思っていて、特に疑問って漠然とは持ってないので、何か書いてみたり表現してみたりすると気づくことが多いんですよ。
例えば私の場合は、うちってエスカレーションしたりとかしてるけど、それってどういう基準でエスカレーションすればいいんだろう。それはどういうふうにするのが一番いいんだろう、一番いいんだろうですね。っていうのがすごく大事で、そうすると一番ってことは、じゃあエスカレーションする基準には良し悪しがあるはずだよねと。それのチャンピオンが今回探したことだと。
その良し悪しの基準って何なんだろうって考え始めると、パラメータが分かってくるんですよ、だんだんと。エスカレーションする速度大事だよねと。かといってエスカレーションなんでもかんでも下の人がエスカレーションしたら、上が飽和しちゃうから、飽和してるかしてないかも大事だよねみたいな、こんなふうに試行実験してみるとパラメータがいっぱい出てくるんですよ。
このパラメータっていうのがどういう数式で組み立てられて、それをどういうふうにすれば一番いいって言えるのかってことで考える。つまり、形式化する疑問を持つ、形式化する疑問を持つ、このサイクルを繰り返すと、だんだん問題の確信に迫っていくっていうサイクルになりますね。
その疑問を持って、それを自分が解釈できる抽象度に落とし込んでいって、ちょっとずつ解決するというか、探していって、もう一回ちょっと立ち返って、実際に実践してみるか何かして、もう一回疑問を持ちっていうサイクルをどんどん回していくっていうところが重要というか、常に新しいところ、新しいスキルなのかどうなのかっていうのが大事だと思います。
12:20
何かわかんないですけど、そういったところに繋がっていくんじゃないかっていうところなんですね。
そうですね。このやり方っていうのはメリットが一個あって、なぜっていうのを説明できるようになるんですよ。例えば、どうしてこれをあなたはこの方法知ってるんですかって言われたら、それはね、これこれこういう問題に出会わせたときに、これこれこういうふうに思って、だからこういうふうなことになったんだよみたいなのが全部あるんで、つまり何か問題だと思ったら、それがなぜにちゃんと紐づいていて、ちゃんと自分が学びたいってものだけが学ばれている状況になるんですよね。
すごいいいですね。
イチベーション高いものだけが残るっていう。
いわゆる何かトヨタとかの改善サイクルみたいな感じですよね。もう全く一緒なサイクルなのかなと若干思うんですけど、じゃあちょっと思うのが、その常に何かこう問いを持ち続けるために、まあ結構それも労力だと思うんですよ。
で、それが何でしょうね、久里明さんの性格が常に何だろう、ここってもっと改善できないのかなだったり、これって何か一番いい方法がもっとあるんじゃないかみたいないうところに目指してるんだったら、何かそういう性格だからこういうサイクルができてる、で終わっちゃうかなと思うんですけど、何かそういう構造、その問いを持ち続けるために何かこう大切にしているような構造だったりとか習慣とかってあったりするんですかね。
これはでもやっぱりちょっと個人によっちゃう気がするんですけど、私は効率中であることって結構大事だと思ってるんですよ。
なるほど。
効率中、つまり私もその一番いい方法を探してるのは効率中だからですよね。一番いい方法が一番効率高いじゃないかって思ってるわけですよ。
なるほど。その効率を高めることに重きを置いている人だから、あの効率を高めてたくなってしまうという。
そうそうそうそう。効率中ってよく悪い意味で使われますよね。つまり例えば映画とかはタイパーが悪いから見ない、自分は本で見るみたいなとかよく言いますよね。
それは何て言うんだろう、大事な部分を損なってるみたいな言い方でよく批判されますけど、ただ私、仕事においては効率中って結構大事だと思っていて、
そこってもっとコスト安くできないかなとか、そこってもっと何かスケジュール短くできないかなとかっていうふうに、
どんどんどんどん模索して一番いいのはどこかってことを探っていくっていうのはすごく大事だと思ってるんですよね。
それは私はみんなが持たなきゃいけない姿勢だと思っていて、なのでその姿勢を突き詰めていった先に、今私みたいなモデル化して考えてみたいなそういうサイクルがあるんだと私は思ってますね。
なるほど。常に効率を意識するっていうところですね。効率中というよりかは本当に根源的に自分がやってるやつを手だけで何とかせずに、ちゃんと構造的に考えるっていうところから効率を高めていくっていうのがみんなやるべきだっていう考え方なんですね。
15:14
そうですね。
なるほど。確かにそういうのがあったらどんどん自分から学んでいくし、なんて言うんでしょうね、そういう人だけの会社があったらなんとなく強そうですよね。
ただもちろん世の中はそういうふうなことばっかりじゃないっていうのもわかっていて、効率中のいけないところはさっきも言った通り、大事な側面が切り落とされちゃうことっていうのも大事なんですよね。例えば効率がめっちゃいいからといって法律を違反したりとかするのはダメなわけですよ。
それはそうだね。
ダメな側面だけですね。
そりゃそう。
だから、これは効率を度外視するみたいなパラメータがあるんですよ。法律だったり、あるいは他人と気持ちよく働くために他人を例えば利用したり、利用って言い方変だな。騙したりしてないとか、そういう倫理観的なものもありますし、そういうものっていうのはちゃんと抑えた上で、
所有の範囲の中、つまり常識的に認められる範囲の中でどこが一番いいのかなって探るってことですよね。
そこら辺のバランスってどうとってたりするんですか。
いや、調整しかないですね、これは。
ここら辺のバランスが難しいからこそ、前回のあった正論で殴って敵になるみたいなそういったことが起き得るっていうことなのかなとは若干思うんですけど。
そうですね、例えばなんですけど、一昔前にそのAIエージェントに様々なことを任せて、例えばメールの要約とかをさせて返信するメールを抽出するみたいなこと絶対考えなかったじゃないですか。
でも今はちらほらそういうことをやる人たちが現れている。それって常識的の外にあるんですよね。私にとっては常識の外にあったわけですよ。
そこ自分で見ないの?っていう。で、なんで、なるほどなぁ、でもそれでうまくいっちゃうのかってなると常識がちょっと広い方向に修正されるわけですよ。
逆に、ある人がすごく傷ついたとか、人間性の対話をつけて傷ついたとか、デキンの話ですね、デキンみたいになると、
自分の常識広すぎたなと思って、この辺りが人を傷つけないラインなんだみたいなとかっていうふうに常識を縮小させるっていうことをやってて、
これ要するに拡大もあるし縮小もあるし、それを調整していくしかないんですよね。
なるほど、常識なんてその人の常識でしかないですからね。
そうですね、その人の置かれている環境での常識でしかないからですからね。
難しいですよね、そんな。環境によって常識違いますからね。
そう、だって人によって全然違うし、例えばスーツ着るのが当たり前の会社だったらスーツ着るのが常識なわけですよ。
だけど、例えば服装気にしないウェブ系の企業とかだったら、いやスーツなんて着るの非効率でしょって思ってるわけですよね。
それによって常識が全然違うわけで、その人の置かれている環境によって常識が変わるっていうのはすごく大事で、
そして置かれている環境ってのは刻一刻変わっていくんですよね。
例えば、スーツ着てる人たちも昔はネクタイしなきゃダメだったはずなのが、
今だってめちゃくちゃ暑くなってネクタイしてたら死んじまうってなったんで、クーリリズムみたいなのが入り始めたわけですよね。
18:04
っていう風にその環境も変わっていくので、それをやっぱりどんな人も調整し続けなきゃいけないと思うんですよ。
それが個人的には環境に適応する術だと思うんですよね。
なるほど、ちょっと生存戦略的な話でもありますね。
ちょっと話変わって、ちょっと技術的なところ、今話してたのってなんとなくどちらかというとソフトスキルだったりとか、
あとは意思決定モデルも技術というよりかはプロジェクトを回しやすくするとか組織を回しやすくするみたいな、
そんな話なのかなと思ったんですけど、次は技術的なところ、例えば低レイヤーの話だったり、インフラの話だったり、
あとはこれを低レイヤーと言っていいのか、なのかわかんないんですけど、C++の書き方だったりとか、適切な例があれですけど、だったりとか、
あとは高レイヤーの話、AIの使い方みたいなところだったりとか、そこら辺ってあったりするんですかね、
どこまで低レイヤーを学んでいくだったりとか、人の好き好みに分かりそうな気もするんですけど。
まず低レイヤーの話からしましょうか。低レイヤーって、例えば私が勤めてるようなウェブ企業とかだったりすると、低レイヤーのことあんまり知らなくてもアプリケーションの開発はできちゃうんですよね。
例えばOSがどういうふうにタスクスケジュールしてるのかとか、そういうこと知らなくても使えちゃう。
例えばAWSのこれとこれくっつければ、もう俺の作りたいサイトできんじゃんみたいなとかになっちゃうわけですけど、実はこれだけだと避けては通れない2つの関門があると思っています。
一つはセキュリティです。セキュリティっていうのは一気通貫で知らないと、どこに脆弱性が入るかわからないわけですよ。
だから例えばAWSのこれ使ってれば安心じゃんって思ってたら、実はここにこんな設定があって、それで実は私のプライベートなパケットが全世界に公開されてましたみたいなことが起こったりするわけですよね。
それってどういうふうにアクセス制御してるのとか、これ実は他の人が推測可能じゃんとかっていうのがあったりするとっていうのがあって、結構これってAWSがどういうふうにしたものを作ってるのかってことまで知らないとわからないっていうのもあるし、
例えば自分でGCEとかでインスタンスを持ってるときにOSのアップデートしなかったときに何が起こるか、例えば脆弱性使われて権限昇格されちゃって、ルート取られちゃって、私が占め出されちゃってマイニングマシンになっちゃいましたとかっていうのが起こるわけで、
これもやっぱり脆弱性っていうのはどのレイヤーに入ってもおかしくないんですよ。だから低レイヤーも知ってる人はすごくちゃんといろんな多層的な防御ができるってことになりますね。
なのでまとめると低レイヤーを知ってると防御の面が増えるので、より防御力を高められるってことですね。もう一つはセキュリティじゃなくてパフォーマンスチューニングです。
21:02
パフォーマンスチューニングもすごく大事で、っていうのはソフトウェアって自分たちは高いレイヤーのものだけWeb企業の人たちは記述するわけですけど、実際はその中にコンパイルとかがされたりとか、あるいはジッドとか、ジッドコンパイルとかされるかもしれないですけど、
だからされて実際に機械で解釈可能な命令列になって実行されていくっていう、一連高いところから深いところまで全部実行されてアプリケーションが動いてるわけですよね。
だからパフォーマンスチューニングするときって高いところだけでカリカリしてても大体削減幅って大したことなくて、深いところまで知っておくと削減幅がたくさん見つかるっていう類のものなんですよね。
なので、この2つ、セキュリティとパフォーマンスチューニングが2つまでちゃんとやろうと思ったら低レイヤーに手を出さざるを得ないというふうに思っています。
なので、低レイヤーの勉強というか、知識の獲得みたいなところは非常に重要だよねっていう。
そうです。それでモチベーション付けできるよねってことですね。
それも何でしょうね、効率みたいなところに効率中的なところに落とし込まれるんですかね、最終的には。
これは難しいですね。効率中が拙速にやばいサービスを作って脆弱性いっぱいありましたみたいなのって、効率中的にはたぶん嬉しくないと思うんですよね。
なんか得られた成果物がしょぼかったって話だと思ってて。
効率中って時間的なその短さっていうのはもう去ることながら、成果物の質をやっぱり見てるわけですよ。
その質が下がるってことはやっぱ効率中は許容しがたいっていうのは結構あって。
例えばいくら早くできたとって、秘密情報が秘密じゃなくなっちゃってる脆弱性があるようなものっていうのは問題があるわけですよ。
そういうものとかを、つまりなるべく短くなるべくいいものを作るっていうのが大事ですよね。
その点でやっぱりパフォーマンスチューニングとセキュリティって両方とも大事なわけです。
重要ですね、確かに。効率を高める場合においても絶対に重要だから、やっぱし同じ話で何か仕事をする上ではどっちにしろ必要になる観点ではありますね、低レイヤー。
ただ私がちょっと低レイヤーの難しいなって思うところは、一番最初に言った通り、低レイヤー見なくてもなんとなくアプリケーションは開発できちゃうんですよ。
遅いなって思って初めてどうにかしなきゃっていうモチベーションが湧くっていうのがあって、パフォーマンスチューニングの話は遅いっていうのがわかるからまあいいんですけど、
セキュリティの場合は自分が大穴のあるサービス作っちゃったってわかってないですからね、攻撃されて初めてわかるっていうのがなかなか辛いなって思うところで、ここはちょっと個人的にはセキュリティの方は難しいなって思いますね。
なるほど、それはそれでセキュリティに関してはそれはそれでちゃんと専門性を持ってやっていかないといけないところでもありますもんね。
そうですね。
なんか片手までというよりかは、多分おそらく全員が広く浅くは知っていないといけないところもありつつも、深いところはあの専門家の人にちゃんとお願いしていくみたいな方がまあ効率的にもいい気もしますね。
24:00
はい、で私はあの、なんか低レイヤー調べようと思えばいくらでも広がってるわけですよ。
例えば低レイヤーのOSの話もさっき言いましたけど、ネットワークプロトコルTCPIPの話もあれば、例えばもっと近くまでいくとCMOSどうなってるかとかっていう超低レイヤーのところもあったりするわけですよね。
それを全部笑わなきゃいけないのかって言われたらそれなんか無茶ですごく感じるじゃないですか。
だから私のおすすめっていうのはセキュリティにせよパフォーマンスチューニングにせよ、ここからここまでのやつはよく見かけるからここまでは対処できるようにしようって線引きをすることが大事だと思っています。
例えばセキュリティとかだと世界のトップ脅威、ランキングいくつみたいなのがあったりするわけですよ。
一昔前はSQLインジェクションとクロサイドスクリプティングでしたよね。
っていうのがあって、そうやってどうして起こるんだっけ、そこだけ知れば一旦合格としようというふうにするわけですね。
細かいところは専門家に任せようと思う。
私はその辺りが合理的なラインじゃないかなと思っていて、なのでなるべくセキュリティにせよパフォーマンスチューニングにせよ、どういうところで一番やばいことが起こるのか。
ランキングみたいなのを調べて、ランキングのトップいくつまでは対応できるようにしようって思っておく。
それぐらいが健全なんじゃないかなって思いますね。
難しいなって聞いてて思ったんですけど、おそらくランキングを調べてここまではちゃんと対策しようみたいな思える人って多分大丈夫なんですよ。
それはそうかも。
思えない人が厳しいなというところでもありつつ。
でもそういった人に関しても今だったらGPTとかでセキュリティどこまで対策すればいいのかみたいな相談から入るみたいな方が一番いいってことですかね。
そうですかね。私は失敗するってことは取り返しがつくんだったらいいことだと思ってるんですよ。
だからセキュリティにせよパフォーマンスチューニングにせよ失敗するってことはすごく大事だと思ってます。
取り返しがつくんだったら、例えばうちみたいな暗号師さんがやばいことやっちゃいましたみたいなとか取り返しがつかないんでやばくなっちゃうわけですけど、
そうじゃなくて例えば個人でやってるサービスとかあれのでちょっとデータ消されちゃいましたとか、それは失敗。
取り返しのつく失敗ですよねと思っていて、そういうのは失敗いっぱいすればいいんじゃないかなって思ってます。
いや、非常に重要な話かなと思われる一方で、最近すごい必死と思うんですけど、例えば大学生の人とかが何かこう何か作りましたと、
いやこれはセキュリティ的にやばいんじゃないかみたいなのがめちゃくちゃくると、心くじけるんじゃないかなと何となく思うわけですよね。
だから安全に失敗するという環境がもうすでに崩壊しだしてるっていう何となくの気もするんですよ。
なるほど。
インターネットに公開してしまうとという意味がいいですけどね。
私は大学生とかがサービス公開して有識者に刺されるっていうのは私は取り返しのつく失敗だと思ってますね。
27:04
なるほど。
だからそういううちは人の大事な情報だったり大事な資産だったりを受け取るサービスを作っちゃいけないと思ってるんですよ。
リスクのことを考えるとね。失敗するかもしれないから失敗した時のダメージが大きいものはあんまり作らない方がいいよね。
それぐらいはアドバイスできると思うんですけど。
でもまあいろんな人にここをもっとうまく作らなきゃいけなかったねとかって指摘されること自体はいい失敗なんじゃないですかねと個人的には思いますね。
じゃあどちらかというとあれですね。有識者の刺し方ですね。
それは大事。
問題になるのは刺される方というよりかは刺し方で愛情を持って刺しに行こうというような形ですね。
そうですね。私は愛情っていう主観的なものをあんまり挟みたくなくて、大事なのはその人が失敗を乗り越えられるかって部分だと思ってるんですよね。
だから何かが悪いってことだけを伝えるとその人はどういう方向に歩き出したらいいのかわかんなくなっちゃうわけですよ。悪いのはわかった。どこに移動しなきゃいけないと。
なんだけどどこに向かって歩きゃいいのかわかんないわけですよね。だからこっちの方に向かってやるといいんじゃないみたいな改善案付きで出してあげることが個人的には優しいんじゃないかなって思いますね。
方向性をちゃんと示してあげるということですね。
いや、以上に重要だなと思いますね。
ただ一方でそれはすごく甘やかしてるともちょっと思うんですよ。
なので私は流法付きで出しますね。つまり最終的に決めるのはあなただと。
私の言う通りにやるんじゃなくてあなたが決めなさいってことは付け加えたくなりますね。
意思決定は自分自身ですべきだと。
あなたに私が言ったからやるとかじゃなくて、私が言ったことを受けてあなたがどう思ってどう決めるのかってことの方が大事なんだよって。
いやめちゃくちゃわかりますね。
多分マネジメントなんですけどこの話は完全に新人の方だったりとかジュニアの方に対する受け答えみたいなのも全く同じかなと思う一方。
おそらく今後AIネイティブの人たち、おそらく人によってはAIに言われたからだったりとかそういうのが結構多くなってくるなとは思うんですよね。
今の子供だったりとかもそうだと思うんですけど、そこら辺に対する対策というかやり方としてやっぱり意思決定は自分自身でやるべきで
そこは委ねるべきではないみたいなところは結構非常に重要になってくる考え方かなと思いますよね今後も。
そうですね、私はやっぱりここでも繰り返しになるんですけど疑問を持つことが大事だと思うんですよ。
あの人はああ言ったとかAIはああ言った、なんでって。
例えばこういう条件だったらAIの言ってることは間違いになるんじゃないのとかっていうふうにいろいろな実験をしてみるとやっぱりその意思決定の輪郭がこう見えてくるんですよ。
それはやっぱり大事で常に批判的精神を持つっていうのかな、そういうふうな精神がやっぱり大事だと思っています。
重要ですね確かに、批判的精神っていうか、これは本当にこの人が言ってること合ってるのかどうなのかっていうのは自分自身で検証すべきというかちゃんと調べるべきですよね。
30:08
じゃないとあの人が言ってるからっていう理由になっちゃいますもんね、全ての意思決定が。
そうなんですよ。私は何らかの改善提案とかっていうのは全て前提があると思ってるんですよ。
例えば、パフォーマンスチューニングする時になんかクエリめちゃくちゃ遅いって時に前提は、例えばインデックスあれば直るよって言われたとするじゃないですか。
その時に前提としてインデックスが張られてないとか、データベースの規模がでかいとかいろんな前提がありますよね。
その前提が初めて揃った上でその改善案が役に立つわけですけど、
前提が揃ってるかとか確認しないで改善提案する人いますよね。
そういう人の意見って大体やってみたらうまくいかなかったな、この解決策がいけてないみたいな感じになっちゃうわけですけど、問題なのは前提を確かめなかったことなんですよ。
と思っていて。だからこの人は本当に前提わかってんのかなとかっていうふうに批判的な精神をやっぱり持つことがすごく大事で、
なんかその前提が私の困ってることってこういうことなんですけど、本当にそれで解決できるんでしょうかって考える。
すごく大事だと思ってます。とにかく改善案は前提を確かめることが大事です。
そして疑うことですね。
疑うことですね、とにかく。
目の前にいる人は必ずしもあなたのことをすべて知っているわけではないという。
そう、だってログとか今あなたが見てるアプリケーションのこととかを知らないで改善提案みんなするわけですよね。
だから本当に前提が合ってるのかってことはやっぱり確認しなきゃいけないですね。
専門家もアイドバースするときは必ずこういう前提のときはこういう解決策になるんですけどねっていうふうに前提を確かめられる形で言ってあげないと検証がちょっと大変でしょうね。
いや重要、マジで重要な考え方ですね。ここは。
ありがとうございます。ちなみになんかあれですね、ちょっといい感じの時間になってきたんで最後の話題に行きたいなと思うんですけど、
今までは大体のことが何ですかね、インターネット上のお話だったかなとは思うんですけど、
本から得られる情報みたいなところで繰り分けさ、日常的に技術書だったりいろんな本だったり読めたりとかそういうのあったりしますかね。
ありますね。例えば私が最近読んだ本はユーザビリティエンジニアリング言論っていう本とか。
お堅いな。
お堅いですね。
あとは例えば何でしょうね。
ソフトウェア使用技術の先進技法Z言語とかそういうのを読んでたりするんですけど。
なるほど。
硬そうですよね。こういう本を読むっていうのは一体何のメリットか、インターネットに比べてどうなのかってことはやっぱり大事だと思っていて、
私はインターネット、例えばユーザビリティエンジニアリング言論を何で読もうと思ったかっていうと、
うちの会社でユーザビリティテストした方がいいねっていうふうに私が思ったんですよ、アプリの。
ユーザビリティテストっていろんなテストの仕方があって、ユーザインタビューとかいろんなやり方があるんですけど、
33:05
一体どんな方法が知られていて、それぞれのメリットデメリットは何でとかっていう方法を整理して知りたかったんですね。
インターネットを検索すれば、何かよくわかんない人が前提を抜きにこうすればいいんですよ、みたいなことを解説している。
だけどここで私はさっきの批判的性質が出てくるわけですよ。前提何?って。
そういうふうな前提がちゃんと書かれてる本を私はどうしても好んでいるってところがあって、さっきのお堅い本、結構お堅い。
これはユーザビリティっていうことを転職した人が書いた本なんですよ。超限定ですね。
その人がこの人の発想は面白いんだなってみんなが受け止めて、ユーザビリティって言葉が定着したわけで、それだけのインパクトのある本なんですよ。
なので読んでみて、少なくともその人が試したこととかっていうのを私が試さなくて済むようにしようと思った。
なのでそういう本を読んでたりするんですね。なので基本的に私は大事だと思っているのは、
なんか手軽に試せる知識っていうのは私はあんまり大事じゃないと思っている。
どっちかっていうと、そういうふうな手軽に試さなくて済む方法を書いてくれてる本の方が大事だと思っていて、
なので私はそういうふうな結構お堅い本とか教科書とかっていうのをよく好んで読むですね。
インターネットの記事とかだと、大体読みやすいように短かったりとかするかなと思うんですけど、
だからこそ前提が省かれていたりとか、あとは網羅性がなかったりとか、
先行研究としての検証がなかったりだったりとか、そういったところが批判のところになってくるのか、
批判的な観点で見るとちょっと抜け漏れてるよねみたいなところ。
一方、本とかだとそこら辺までちゃんとカバーされていたりとか。
そうですね。本にもよります。お堅い本っていうのは必ず先行研究を踏まえてるんですよ。
参考文献ってところにいろいろずらーっと本が書いてあって、その本を読まなくて済んだんですよ。
つまり参考文献にいっぱい書いてあるということは、それがまとめられてるってことですからね。
だからそういうふうに参考文献がずらーって書いてある本は私は有益な本だと思っているんですけど、
本によってはそういうふうなのがなくて、私はこう思った、こうやってみた、たまたまうまくいったみたいな本も多いので、
そういうのは私避けるようにしてますね。インターネットの記事と同じです。
参考文献がちゃんと書いてあれば論文チックな本の方が、本としての価値は高いんじゃないかっていう。
本というか情報としての価値っていうんですかね。
これは情報としての価値は一体何かっていうと、私たちが本を読んだりインターネットの記事を読んだりするのは、
平均的に成功したいからだと思ってるんですよ。
つまり何事もやっぱりリスクってあって失敗するときはあるわけですけど、
でもなるべくなら失敗は少ない方がいいと思ってるわけですよね。
だから他人の事例とかを読んだりして、あの人がこんな失敗したんだ、じゃあ私はしないようにしようとかって思うわけじゃないですか。
その、あの人が踏んだ罠っていうのをどれだけ知ってるかって、
どれだけ本を読んで他の人の失敗を知ってるかっていうのが大事だと思っていて、
36:01
その意味で参考文献っていうのはそこにリニアに関係してくるんですよね。
モロに効いてくるっていう部分なんで。
なので私は参考文献が多かったりだとか、私個人はこうでしたみたいな本ってあんま好きじゃないんで、
とかインターネットの記事も好きじゃないんで、なるべくお堅い。
なるべくいろんな人の失敗事例を集めたような本ってのを好みますね。
これは結構ノブリさんが言ってた、日々ジャンクな情報だけを摂取するんじゃなくて、
価値の高い情報を摂取しろって言ってたのとも通じると思ってて、
ノブリさんって消しからんってよく言ってる人いますよね。
ソフトイーサーっていうVPNのサービス作っててっていう研究者の方ですけど、
その方はよくジャンクな情報ばっかり食べてんじゃないよって言ってるんですよね。
私もそれにはすごく同感で、ジャンクな情報って軽いんだけど、
読み口は軽くて摂取しやすいんだけど、情報の量も軽いんですよ。
だからやっぱりそういうものばっかりやってても積み重ねにはならないなっていうのは思いますね。
非常にこれ聞いてる人の中にもぶっ刺さる人いっぱいいるんじゃないかなと思うんですけど、
やっぱりちゃんとした情報を摂取して、いい考えをどんどんみんな出していこうというような感じなんですね。
本を読むとしても、ちゃんと参考文献だったりとか、論文みたいな形のものの方がいい情報になってるっていうところで。
ちなみにその本を読む、そういう硬い本ってめちゃくちゃ読みづらいですよ、個人的には。
そういった時にはAI使ってたりするんですか?
AIは使ってないですね。私は寝かせますね、大体。
寝かせる。
わかんねえと思ったら寝かせます。
なるほど、積読をしとく。
積読して、しばらくでとってみて、こういう意味かなとかってひらめいたらもう一回読んでみて、そういうことかみたいな、そういう感じですね。
でも結構ありがちですよね。その時に置かれないと響かないところって絶対ありますよね。
ありますあります。
その当事者になってから、この章ってこういうことだったんだみたいな。絶対あると思うので、確かにそうやってちょっとずつ進めていくってことですね。
そうですね。
あとあれですかね、必要なところだけつまみ読みしてもいいんじゃないみたいな、そんな感じですかね。
もちろんもちろん、そうですそうです。
全部読まなくてもいいよねっていうところですね。
私もユーザビリティエンジニアリングゲームは全部読んでるんじゃなくて、自分の知りたいところだけ読むと思うんですね。
その、なんていうんですかね、割とあるのが全部を読まないといけない恐怖心みたいなのって。
わかる。最初から全部読まないといけないみたいな。
めっちゃあると思うんですけど、なんか僕自身もある時点から、これ別に目次見て読みたいところだけ読めばいいんじゃねって思ったらめちゃくちゃ読みやすくなったんですよ。
そうですそうです。だから目次真っ先に見ますよね。
わかりますわかります。
私もそうです。
で、本当に気軽になったので、本当にちゃんと読みたかったら全部は読むと思うんですけどね、その後。
なんですけど、本当にちゃんと身になるものだったら、つまみ食いでも全然いいっていう感じですね。
39:06
ありがとうございます。じゃあちょっとここまでで結構いい感じにお話できたかなと思うんで、最後に学習みたいな、学ぶみたいなところで最後言いたいところがあったらお願いします。
一つは批判的な精神を持つこと、そして前提を確かめること、この二つが私から言える大事かなって思うことですね。
批判的にちゃんとやっていくっていうところですね。
エンジニアだったらなんでしょうね、効率も三大美徳みたいな感じで、
怠惰であれとかそういうのがあるんで、場所にいたところと通じるかなっていうところですかね。
じゃあありがとうございました。ということで今回ここまでにしたいと思います。
もっと詳しく教えてください。
クワラジではスーパーエンジニアである国明さんにエンジニアであるヘンテコが技術的な質問していく番組になってます。
今後もいろいろなことを聞いていきたいなと思ってますので、お聞きのプラットフォームで高評価やフォローをお願いします。
またこんなことをですね、国明さんに聞いてほしいっていうことがありましたらコメントいただけると取り上げますのでよろしくお願いします。
Xなので感想もぜひお待ちしております。
クワラジでハッシュタグつけてもらえれば見やすくなるのでよろしくお願いします。
それでは今回もありがとうございました。
ありがとうございました。
