ep 17 @cakephper と Web脆弱性診断ツールVaddy, DNS改竄検知ツール, ウルトラワイドモニターについて

00:06

こんばんは、Yokohama North AM第17回です。

Yokohama North AMは、中年エンジニアがウェブテック系のキーワードをネタにして雑談をするポッドキャフトです。

ホスト役は、自称フルサイクルエンジニアのHanhan1978です。

本日のお相手は、いちかわさんです。

こんにちは、いちかわです。

こんにちは。

よろしくお願いします。

ようこそ、よろしくお願いします。

来ちゃいました。

来ちゃいました、ありがとうございます。

初めてダイレクトメッセージで俺を出せっていうリクエストを。

グイグイ言っちゃいました。

グイグイ来てくれて嬉しいです。

トミドコロさんがDMを直接送れるツイートみたいな。

そうですね。

そこでとりあえず行ってみようと思って。

すごい来たと思って、すごい嬉しかったです。

本当ですか、よかったです。

普段だと僕が自分でDMで突撃するんで。

すいません、ちょっとこの日どうですかとか。

毎週だと大変ですよね。

そうなんですよね。

基本1月以上予約を取ってるんで。

すごい。

10月までなんとか。

10月まで待ってる、すげー。

ゲストのご紹介ですね、いちかわさん。

PHPからだとケークペチパーさんというのが通称というか。

やってます、ケークPHP。

ケークPHPやってるんですか。

やってますよ、ゼロじゃない。

ゼロじゃない、若干苦しそうです。

大丈夫です、やってますよ。

やられてるということで。

株式会社ビットフォレストさんですね。

セキュリティとかその系の製品とか。

今はクラウド型WAFのバディの事業開発責任者。

クラウド型WAFスキュータムと脆弱性診断。

クラウド型脆弱性診断のバディ。

2つやってます。

出た頃に使って、

どっかで使ってみようって言ってそのままになってしまう。

申し訳ない。

いいです。

各地のPHPカンファレンスとかでよく登壇されているので。

今はね、ちょっとオフラインの登壇がなくなっちゃってるんで。

全然ないですね。

全然ないんで、お会いする機会ない。

福岡だとあれですかね、今は。

そっか、ピール一緒に飲みに行ったりとかそういうことも今でやりづらい感じなんですか。

今はもうやってないことになってます、みたいな。

本当にやってないんですけど。

できなくなっちゃいました。

気軽に飲み。

気軽に飲んで、みんなでウェーイみたいなのをツイート上げたらなんか怒られてるそうですもんね。

いやー、嫌な世の中になっちゃいましたね。

なんかみんながみんなを監視してるみたいな感じ。

03:02

人の敵は人、みたいな。

ちょっと怖い。

怖いですね。

朝、土手をランニングしてるんですけど、

マスクしてない人をすごい睨みつけながら歩くおじさんとかいますよね。

あー、そう。

いやー、でも本当ね、マスクせずにコンビニとか入るの、ちょっとためらっちゃうから、いつも不安な気持ちになってマスクを常備してるんですけど。

分かります。車の中でしょ。

あと、ガバンの中とかに、とこかしこに入れて忘れた時に。

忘れ物をよくする子みたいな感じで、いろんなところに置いてます。

そうですよね。今、お金よりマスク忘れたほうがあって感じになりますね。

怒られちゃう。

今日のトークキーワードなんですが、せっかく市川さん来ていただいてるので、

脆弱性の診断の話ということで、バディとかその周辺の話を1個目。

次が、最近趣味でDNSの改ざん検知ツールを作られたということなので、

その話と、あとはあれですかね、ちょっと定例屋周辺の趣味の講じる話を。

3番目はですね、もはや人権と言われているウルトラワイドディスプレイの話ですね。

この3本だけでよろしくお願いします。

まずはあれですね、バディですね。

バディは2015年にリリースしたんですね。

もうそんな前なんだ。

クラウド型脆弱性診断ツールという立ち位置で、

クラウドから実際にウェブアプリケーションに対して脆弱性診断のブラックボックステストと呼んでいる、

実際にHTTPリクエストを送って診断していくタイプ、ソースコードを見ないタイプのツールになっています。

で、これ最初からCIとか自動化前提で設計し始めて、

世の中にそういうツールがその当時なかったんで、もう全部フルスクラッチで書いてやってます。

大変そうって。

あとそうですね、アイディア自体は僕が持ってて、そこから事業化したんですけど、

なので僕が開発責任者になっていて、フロント側の実装をしていて、

裏側の実装はJavaでやってて、私じゃないセキュリティエンジニアの人が作ってるんですけど、

で、それと即結合みたいになっていて、

で、あとサポートとかですね、チャットメールのサポートをしてたりとかしてます。

大変そう。

06:02

バディのアカウント、これ市川さんかなっていう感じの。

公式アカウントは私じゃないです。

違うんですか。

完全にもう一人の営業とか契約とかをやってもらってる人に託しました。

そうだったんですね。

これは完全に市川さんだろうと思って、いつも疑いのみを。

そう。

福岡大変だなと思いました。

自作自演があって。

自作自演してる。

確かにそうやってみると滑稽ですね。

でもその後悔が。

後悔が解けてよかった。

あれですね、市川さんとは僕の関係で言うと、

バディ最初出た頃に使って、ちょっとフィードバックをほんの少しだけですけど。

ありがとうございます。

実際に何かどっかで使えたらなーなんて思ってたら、

もう5年経ってました、すいませんですっていう感じで。

大体のセキュリティツールってそういう感じで。

こういう運命にある。

いつかやらなきゃねっていう。

5年よりもっと前かもしれないですけど、

PALOSとかって脆弱性の診断ツールがあって、

おそらくやることはバディと同じような感じで、

プロキシに設定して、実際にユーザーが動く動きをやった後に、

リクエストパラメーターとかいろんなのに攻撃の文字列とか入れて、

テストしてくれるみたいなツール。

最近だと、なんだっけ?

OWASPじゃなくて、

OWASP ZAP?

OWASP ZAPか。

あの辺とかもそういうツールですよね。

そうですね、オープンソースツールはそれ系ですね。

それのマネージドサービスみたいなイメージ?

そうですね。

ただそっち系のツールはクライアントアプリケーションでGUIアプリとかになってるんで、

それだと結構自動化しにくかったりとか。

しにくいですね。

あと、かなりリッチな機能があるんですけど、

使いこなすのが相当難しいので、

それをいきなり開発現場で使ってもらうのはちょっとしんどいっていうのがあって、

僕としてはずっとウェブの開発やってきたんで、

ウェブの開発の人たちとか周辺の人たちが使える脆弱性検査ツールを作りたいなっていう形で

Buddyを作ったんですよね。

なのでBuddyってほとんど今設定項目がなくて、

さっきのプロキシー投資クロールっていうところだけで、

あとは勝手にここがログイン画面ですとか、

ここにCサーフ対策トークンがありますとかっていうのを全部こっちで機械的に見つけてしまって、

09:05

なので何か設定しないと、

例えばセッションが切れたらもう検査できないとか、

トークンが切れたら検査できないみたいなのはなくて、

全部機械的にこっちで吉田にやるんで、

お客さんはクロールって呼んでる作業は本当に自分の作ったウェブアプリの正常繊維を

受け入れテストみたいな形で操作するだけなんで、

そういうあなたの作ったツールをあなたが一番知ってるんで動かしたら、

その結果をもとに私たちがちゃんと検査しますよっていう立ち位置のツールになってます。

あれですね、開発者の人がちゃんと考えましたっていう。

開発に専念できるようにしたいなと思ってますね。

面倒くさいツール使いたくなくなっちゃいますからね。

あとこだわってるのは速さ、検査の速さとかですね、

何でもかんでもいろんなテストをやりますっていう立ち位置にはしなかったんですよね。

なので私たちはこれぐらいで十分であるという検査をまず定義して、

あんまりむやみに増やしたりしないように検査項目でCIの中でちゃんと回るように。

大体のツールって普通に設定すると1日ぐらい検査かかったりするんで、

みんな週末とかに実行したりとかしてるとCIとかに組み込めないので。

組み込めないですね、それだと。

なのでそういうのも踏み越して、

もう一つのScutumっていうクラウド型WAFの方で実際の攻撃観測してるんで、

そういう攻撃の傾向とかリスクから考えて、これぐらいでいいっていう線引きをしてやってますね。

なるほど、そっかそっか。

リアルタイムの攻撃はWAFを使って防ぎましょうみたいな。

で、脆弱性の診断はBuddyを使って防ぎましょうみたいな検査しておきましょう。

そうですね、そもそもの根本的なところはBuddyで見つけて解決しておいてっていう。

なるほど、じゃあそういう提案の仕方ができそう。

できそうっていうか実際にたぶんされてそう。

なのでなんかしなきゃいけないけど、脆弱性検査してますかっていうチェックリストが回ってきて、

なんか答えなきゃいけないけどどうしようどうしよう。

で、どっかにお願いすると納期1、2ヶ月待ちみたいな。

言われますよね。

はい、すごい今混んでるんで、なかなか人がやる診断の方ですね。

やっぱり人気があるところは混んでて2、3ヶ月待ちとかになってしまって、なかなかリリースサイクルに合わないとか。

そういうのがあるんで、こういうツールを使って自分たちで受け入れテストとかユニットテストするみたいに、

エンドツーエンドテストするみたいにBuddyもそこの中に組み込むという思想で作ってます。

なるほど。

となるとこれ、すいません最近のBuddyを全然使ってないんであれなんですけど、

12:00

もしかしたら検査結果とかを出力したりとかもできたりするんですね、やはり。

1、2年前にPDFダウンロードを作りました。

あ、PDF、ありがたがる人がいそう。

そう、そういうのCIだからいらないかなと思ってたんですけど、やっぱりフタを開けると欲しいっていうリクエストが結構。

絶対言われますよね。

なんか自社でさえ多分なんか言われそうな気もするし、

クライアントからとか受託でこういうの使った場合もなんか言われそうですよね。

どんな検査したんだみたいな。

最初はですね、もう問題見つけたらこのURLのこのパラメータにこういう脆弱性があって、

検査リクエストはこれ、レスポンスはこれですっていう見せ方してたんで、

それを見れば大体の開発者の人は解決できるかなぐらいの情報量だったんですけど、

やっぱりPDFで手元に保存しておきたいと。

農品、一緒に農品したいっていうリクエストがあって作りました。

それですよね。絶対やるなと思いました。

すごい、でもそれもサポートしてるんですね。

はい、もうリクエストは答えれるものは答えていこうかなと。

投票出力はそれはそれでめんどくさいですか。

本当ね、そうですね。大変ですね、これ。

最近もうPDFって言われると印刷のやつで逃げちゃいますもん。

ブラウザーの?

ブラウザーの。

わかります。

メディアクエリでプリントにして、いらないやつ消して。

そうしてくださいって思ってたけど。

出力先をPDFにしてくださいって。

できますよね、これでっていう。

絶対このほうが安いんで。

最近それで逃げます。

なるほど。

じゃあBuddyは脆弱性診断をCIに組み込んで、

かつ開発者が何かに報告しなきゃいけないって言っても、

それも簡単にできますよって。

そうですね。

最近はあまり自動化っていう推しはしてなくて、

開発現場のほうですぐに使っていけると。

セキュリティエンジニアとかいなくても。

っていう感じですね。

そうですよね。

ちっちゃい現場はセキュリティエンジニアとか大きいところでも

専門の人いないなんてザラにありそうだから。

そうなんですよ。

いたとしてもいろんなサービスがリリース時期重なると、

結局診断納期のボトルネックが走って、

セキュリティエンジニアが足りなくて納期調整したりとか

リリース時期調整したりとかっていうのが発生するんで、

結局現場で簡単なものとか基本的なものは

潰したほうがいいかなっていう。

そうですね。

Buddyは無料プランとかってあるんでしたっけ?

15:00

無くしました。

無くしたんですよね。

1週間トライアルっていうのをやってたんですけど、

Buddy結構3年ぐらい泣かず飛ばずでいて、

もう大変な歴史だったんですけど、

最後この1年ここまで売り上げいかないとどうするか

みたいなところまで行ってたんですね。

その時にいろいろ手こいでして、

フリープランあるとそのままフリーにダウングレードして

お客さんそのまま戻ってこないんじゃないっていう傾向があって

じゃあ無くしちゃって短期でちゃんと評価してもらって

足りなければもう1回延長とかしますっていう感じで

極力お客さんと対話する方向に持ってたんですよね。

お客さん勝手に評価して勝手に課金するっていう方じゃなくて

極力僕らがお客さんと会話できるようにしていく方向で

作り直したという形でフリープランを無くしました。

なるほど。そういうあれなんですね。

そうですそうです。

辛い地道な。

辛い過去が。

辛い低空飛行の3年間が。

でもそれを乗り越えてるってことは今はもう割り返し?

いや、えっとですね。

今はBuddy自体はそこまでめちゃくちゃ羽ばたいたみたいな感じではなくて

とりあえずは生き延びたっていう。

なるほど。

でもすごいですよ、生き延びるの。

とりあえずは両足で立ってるっていう状態ですね。

なるほど。

一応多分あんまりセキュリティのこと詳しくない方

セキュリティ業界じゃない人は市場規模とかあんまり知らない方が多いと思うので

とりあえず言っておくとBuddyとかがやってる

Webの脆弱性診断ツールの市場規模っていうのは

2020年で、ちょっと前の資料なんで

2020年の予測で国内で25億ぐらいの市場。

うわ、結構小さいですね。

そうそう、そうなんですよ。

2022年で28億ぐらいの市場規模。

そうか、でもなんとなく感覚は合うような気がしますね、少し。

そうなんです。

Buddyとはちょっと違う。

ネットワーク診断とかプラットフォーム診断って呼んでる市場は

大体2020年で40億ぐらい。

それでも40億。

あとクラウド型WAFみたいな市場は

今は2020年で40億ぐらいですかね。

なので100億、1000億みたいな規模では今ないと。

すごいですね。

そういうところで戦ってますと。

いや、もう本当お疲れ様です。

尊敬します。

18:05

セキュリティって結構もっとお金払ってくれるかなって思うんですけど

割と喉元過ぎたらみたいな話で。

そうですね。

ファイアウォールのアプライアンス市場とかはもっとでかいです。

100億規模とか。

あと標的型攻撃とかを見つけるような

そういうエンドポイントセキュリティとかだともう少し大きい規模にはありますけど

SaaS型とかクラウド型のツールになると大体こんなもんです。

なるほど。

いやー25億か。

そうです。ほとんどがもうトップ2社がその25億を占めてるみたいな。

厳しい。

そこに私たちはちょっと乗り込んでるっていう。

クサビを。

クサビをカウントされてないですけどね。

この市場調査資料には私たちはカウントされてないですけど、そこに行こうとしてますと。

すごいですね。導入事例とかもいっぱい書いてあるから。

そうですそうです。導入事例。お客さんにヒアリングしてこういう課題があったとか。

いろいろ共有してますね。

すごい。

こういう自社サービスを最初みんな大体泣かず飛ばすじゃないですか。

それを少しずつ少しずつチューンアップして

生き延びてるだけでも本当すごいなと。

だってそれで5年間もしかもちゃんとモチベーションを保ってやり続けてるのって。

そうですね。最初の3年間とかは何をしても響かないから

何したらいいんだろうこれ。何を俺は作ったらいいんだろうっていう思いの中でやってましたね。

いやお疲れ様でしたじゃないですね。これからさらに羽ばたいていく。

俺たちの戦いはこれからだと。

これからですよね。

いやすごいです。さらに尊敬の念が強くなりました。

ずっとサポート、今2人でやってるんですけど。

もう1人ツイッターアカウント運用してる人と2人でやってて。

技術的な方は全部僕がサポートを受け持ってるんですけど。

やっぱり基本サポートとドキュメントだけはサボんないようにしようと思って。

ドキュメントっていうのはお客さんのマニュアルですね。

何かもし問題があったらすぐにまずマニュアルの方に反映して

同じ問題が出ないようにしていくという形をずっと5年間繰り返してきましたね。

21:00

多分普通のウェブの開発とちょっと違うのが

プロキシを切り替えてクロールと呼んでる画面繊維のリクエストレスポンスを取得する

っていうところが多分普通のウェブ開発のところではないような形になってて

ここ結構サポートの肝というかサポートをめっちゃ手厚くしないといけないところで

いろんなパターンの問い合わせがあって随時それをログとか

ログに見えないログがあるんです。見えないログっていうか記録されてない状態で

お客さんが何かうまくできませんっていうのがあって

エスパー能力が高まってます。

相手の技術知識とかにもよりますもんね。そういうの。

あとお客さんもプロキシを切り替える行為自体がそんな

よくやってるわけじゃないじゃないですか。なので

よく知ってる人だからといって解決できるわけでもないっていうか

一番最近でちょっと難易度高かったのは

ブラウザのプロキシ設定、OSとかも切り替えると

リクエストが全部うちのプロキシのに来るんですけど

切り替えたけどうまく記録されてないんですって言われて

どういうことかな。確かにログ見てもログに出てないしなと思って

いろんな、今どこら辺からどういう形でクロールしてますかとか

いろいろ聞いてたらもしかしてこれ

VPNなのかなと思って

VPNをチェック入れてるとOSのプロキシ設定無視されるんですよね。

で、もしかしてと思ってもしかしてVPN使ってますか

はい使ってます。それが一番

僕が興奮しました。

そうですね。リクエストが来ないっていうところからそこを累積するのは

すごく難しそうですね。すごく難しかったですね。それは

そうですよね。来ない理由はいくらでもありますもんね

プロキシの設定不備とか

もしくはお客さんの環境、社内の環境で出れないのかなとか

いろいろなパターンがある

ファイアウォールとかで落とされてるとか

そうですよね。厳しい会社だと変なリクエスト

全部遮断されちゃったりもするから

なるほど。

昔こういうことをよくやってた頃は

プロキシを簡単に切り替えるアプリとかを入れて

ありますよね。

やってましたね。ああいうのがないと

めんどくさくてやってらんないっていう

なるほど。

Buddyの

あれですかね。苦労話。苦労話というか

24:00

これから羽ばたいていくBuddyの

お話が聞けて

すごい嬉しいです。

そうですね。そろそろ2番目のトピックが

趣味で

DNS改善検知ツール

これちくいちブログ読んでました。僕

ありがとうございます。

だんだん

だんだんDNSのキャッシュとか

防ぐようになって

これちょっとお話ししますけど

まずそもそもDNSの改ざんの問題が

6月ぐらいにニュースになってて

何が問題だったかというと

レジストラーの方の脆弱性をつかれて

NSサーバー、ネームサーバーの向き先が変えられてしまった

変えられてメールも取られて

メールも取られてパスワードリセットもできるので

いろいろ被害が広がってしまったというところで

そもそも例えば

root53使ってます。

root53の中身をチェックしてますみたいな状態のものを

自分たちで作ったとしても

その上のところを書き換えられちゃうと

自分たちの方をチェックしてたとしても

何の意味もないというか

検知できないなと思ったんですよね。

これを検知しなきゃいけないよなと思って

Goの勉強がてら

ちょっと簡単なツールでも作ってみようと思って

最初にまずDNS改ざん検知ツールで

NS、MサーバーとMXを引いて

それが自分たちが期待した通りの値になってるかっていうのを

見るというツールをまず作ったんですけれども

まずGoの

lookupnsとかっていうメソッドがあって

これでいいじゃんと思って

速攻でできたんですよね、1日ぐらいで

ブログに書いてダーンって出したら

いろんな方が見てくださって

そもそもそれ

NS

それキャッシュサーバー見てると

ダメなんじゃないかみたいな意見があって

それも見ましたもん

なるほど、そうなんだ

でもキャッシュ時間とか

TTLでコントロールできなかったっけと思ったんですけど

最初のフィーズとかに出てくる情報は

48時間くらいキャッシュされちゃうんですよね

自分たちが設定できるAレコードとかMXは

TTLとか設定できるんですけど

そうするとそのフィーズとかに出てくるところを

検知しないとそもそもダメじゃん

1時間見つからないじゃんっていうのが分かって

そこはそれ7月末ですね

そこからまた戦いが始まって

これ別に

これDIGコマンド使ったら別にできるんですよね

DIGでNSで

27:02

ドメインで

例えばa.dns.jpとかの検証サーバーを引けば

別に返ってくる

それでいいじゃんって言われればそうなんですけど

でもそれは俺のツールが

それをしてほしかったっていうところがあって

じゃあちょっとツールでやってみよう

もしかしたらGoの中にそういうのがあるんじゃないかと思って

そしたらキャッシュサーバーの

指定ができるっていうのを見たんですけど

そうすると検証サーバーとかに問い合わせるとうまく取れなかったんで

これじゃあどうしようかなと思って

DNSのことそこからちゃんと調べ始めて

DNSって多分自分たちが使っているときは

ローカルのキャッシュサーバーを使って

そいつがDNSのルートサーバーに聞いて

コムはこっちですよってコムに聞きに行って

あなたの何とか.comはこっちですよっていう

回想になっててそいつを代理で取ってくるんですけど

その代理のところをやらないとそもそもダメだ

ということに気づいて

代理をこのツールにやらせてみようと思って

まず調べ始めたんですね

なるほど

それが8月

ちょうど8月頭で大体

夜調べその間ずっと1週間くらい

DNSのこと調べてて

DNSとあと

Goでバイナリーをいろいろパケット作るんで

パケットの作り方とかいろいろ見てて

そこからかって感じですけど

それで材料揃えて

お盆の夏休みに一気に作れたっていうところですね

なるほど

だから賞味どれくらいなんですかね2週間くらい

これに当てた感じなんですかね

賞味2週間ですね

いいですねすごい役立った記事にDNSパケットの

作り方ってこんな記事もあるんですねちゃんと

そうなんです

しかもDNSパケットってすごいんですよあれ

UDPで送ってる場合は512バイト

512バイトですよキロじゃなくて

512バイトに収めないといけない

いまだに

これってあれですよね通信量の制限とかそういうことですよね

通信量できるだけ小さくしようみたいな

小さくしようとあとUDPとかでフラグ面とかみたいな

パケットが分割されちゃうと凄い処理が大変になっちゃうんで

極力そういうのはしないでおこうというところで

ワンパケでみたいな

ワンパケで済ませちゃおうっていうところですね

最初のルートサーバーがAからMくらいまでの

数しかないのはそのパケットに収まるサイズが

それしか入らない

そこに制限があったんですか

いろんな制限がそのパケットサイズによって決まってて

30:00

大変だけど

いまだにこの仕組みで動いてるのは凄いなって

凄いですねこれ誰が最初に設定したんだろう

RFC読めば見れるのかな

RFCも書いてますし

あとあれなんですよね

HTTPリクエストレスポンスとか自分で

テルネットとかでやろうとすると1文字ずつつまり1バイトずつ

やっていけばいいんですけどDNSはそういうバイトとか

贅沢に使っちゃいけませんっていう思想で

ビットまで大切に使おう

なので1バイト8ビットなんでその8ビットで

いろいろなことをしていくので

なのでバイトを制御するんじゃなくてビットを制御していかないと

ビットを制御するじゃあまさにバイナリーなんですね

本当にバイナリーでそうです

Goの中でエンコードバイナリーパッケージっていうのがあって

これだと思ってやったらそいつは

ビット単位じゃなくてバイト単位になってて

ダメですね

ダメだこれだと思って

もしかしたら頑張ればできたのかもしれないですけど

僕の調査ではできなくても自分で1ビットずつシフトして

はい

令和時代にパケットを1ビットずつシフトして作ってました

いやもう令和時代だからこそ貴重ですね

そうです

趣味の遊びですけど

これ仕事じゃないからここまで情熱持ってやったけど

仕事だったらまずライブラリー探そうかなって思っちゃいますけどね

俺仕事だったらさっきのディグですね

DHPとかってディグをシステムで叩いて終わらせちゃう

そうそう

普通ねディグかフィーズか引けばいいじゃんってなって

あとそれパーセスしたい場合終わりでしょっていう

そうですねすいませんもうバイトを

贅沢に使わせていただきました

いやほんとね

面白かったです

面白そうですね

こういうのが結構後の探偵能力とかに繋がるから

全然好きなんですよね

始まる前に

トークキーワードの話とかをしてた時に

なんかすぐに理解できないことを

長い時間かけて理解する欲求みたいな

僕もちょっとそういうのがあるので

すごくシンパシーがあるというか

どこから来るんですかね

ケークフェチパーさんのイチカーさんの

その知的本気ですね

いやそれできるようになったのはほんとこの1,2年ぐらい

今40ですけど

この1,2年ぐらいになって

やっとできるようになってて

多分いろんなものを諦めれるようになったからかな

っていうところはあるかもしれないですね

若い頃はなんかよしいろんなことやろう

みんなすごいなんか新しい技術が

33:00

みんな吸収してるから俺もしようと思って

まあ仕事に関係ないこととか色々勉強しようかなと思うんですけど

全然身につかなくて挫折し続けて

それ焦るだけなんだよっていう

状態がすごくしばらく続いて

それ30ちょいぐらいまで続いて

そこからちょっと子供とか生まれてバタバタして

何もできなくなって

35から34年ぐらいはもう何もしなくてもいいわ

僕はっていう気持ちになって

仕事だけしてそれ以外はもういいっす

何もしません

ドラマ見てビール飲んで寝るだけですっていう

生活をしばらく

お父さんに

そうそう普通のお父さんになって

それでやっとちょっと最近落ち着いてきたんで

そこからなんか一回諦めると

昔みたいな焦りはもうないんですよね

例えばフロントエンドのこのツール新しいぞ

みたいなのは全然興味なくて

はいそうですかっていう感じ

そうですね

僕も今42なんで

めちゃくちゃわかるなと思って

焦ってますよね

30代ってほんと焦ってますよね

焦ってた

今日は笑い話なんですけど

僕が前ポッドキャストで

PHPの現場に出たことを

僕は気づいてなくて知り合いの人に

教えてもらったんですけど

5,6年前に

他の人のツイートがあまりにも輝きすぎてて

見るとつらくて

強そうな人は全員ミュートしようって

ほとんどミュートした時が

その時に僕ティーワダさんミュートしてそのまんまになってて

俺は気づいてないっていう状況

そう

だから僕もすっごい焦ってましたね

なんかもうよくわかんないけどフロントの本とかもいっぱい買ったし

CSSとかね

そうなんですよ

わかるなほんと焦ってばっかり

でもそれを捨てられた

それ捨ててそこで

39とか40ぐらいになってから

なんか自分の時間

自分で好きに使っていいんじゃないって思ったんですよ

自分の仕事に関係ある

ことをしなくてもいいんじゃない

別に誰も責めないし焦らなくてもいいっていう

気持ちにやっとなってそこで

そうした時にずっと憧れてた

テイレイヤーの話とかOSの話ずっとOSとか作りたくて

本だけはあるんですようちに

でも一回ほぼ開いたことなくて

開いたことありますけど

ずっと閉じたままツンドグになってるのがたくさんあって

36:02

そういうのからちょっと手つけていこうかなと思って

まずテイレイヤーの方に入っていって

そこからですね

テイレイヤーってすぐに理解できないんじゃないですか

全然ダメですね

まず最初は何書いたんだろうこれ

そうなんですよ

本一冊読んでも全然分かんないんですよ

なのでそういうところから

ちょっとずつ

ロープレイの地下室に入ってる

ロウソクたる

見つけて周りしか見えませんみたいなので

ちょっとずつ広げていって

テイレイヤーのことがちょっとずつ分かるようになってきて

それで結構長いことかけてやってるのも面白いなと思って

それでやっと腰を押し付けて

一つのことに取り組めるようになったって感じですね

身に染みて

僕も本当同じ年代の人として

分かります

僕もここ1,2年ですかね

できるようになった

できないこととか興味がないこととか

興味ないですって言えるようになったの最近ですね

みんな設計の話とかするじゃないですか

DDだとかクリーンアーキテクチャーだとか

なんだかんだって

僕1ミリも興味ないんですよ

一応仕事で言われたときに答えられる程度の知識はつけるんですけど

己から読もうとか

自分から読もうとか

しようとか思わなくて

いいじゃんみたいな

テスト駆動開発してまとめていけば

大体似たような感じになるからそれでいいじゃんみたいな

っていうのを認められるようになってきたら

いろいろ整理されて

まあいいや俺は

どうせ最終的には低レイヤーのことが知りたいから

それだけやってもらう

それだけやってもらうっていう風に

慣れたのは最近ですね

あれもやってましたよね

PHPのソースコード

ああいうのもやっぱりその辺の絡みですね

仕事にはほぼほぼ

仕事で直接使うことはないけど

やってるときにすごい嬉しいんですよね

あとごく稀に

ごく稀に分かんなかったことが

変に繋がったりして

ピカーンって分かるときがあって

スター

メッセージを送信

Ryo Tomidokoro

スター

コメント

こちらもおすすめ