1. 余談ですが.fm
  2. 190(前半). ゲスト「だいち..
2022-10-28 33:14

190(前半). ゲスト「だいち」さんとデータベースエンジニアについて雑談

はい.今回はゲストトーク第8弾の前半パートということで,データベースエンジニアをされている「だいち」さんと「データベースエンジニア」について色々お話させていただきました❗

是非お楽しみいただければと思います😆


ではでは(=゚ω゚)ノ

だいちさん
https://twitter.com/da_i_chi_dev

#雑談 #エンジニア #データベース #サーバーサイド #MySQL #PostgreSQL #Oracle #転職 #SQL #勉強法
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/5e70dd5881d4e84e1ff1cab4
00:07
皆さんこんにちは。Web 業界のなんでも 雑談室パーソナリティーのキース
ことくわはらです。この番組では Web 業界に関すること、日々感じている
ことなど様々なコンテンツをお届け していきます。今回はまた時間が
来ましたけど、久しぶりにゲスト 会になりたいと思います。今日も
楽しく話していただけたらなと思います ので。では今日はゲストにだいち
さんという方をお呼びしております。 だいちさんよろしくお願いいたします。
だいち どうも初めましてだいちです。よろしくお願いいたします。
おだしょー よろしくお願いします。だいちさんとはツイッターで初めて
知り合ったぐらいで、本当に直接 話すの今初めてなんですよね。
だいち そうですね。僕も始まる前 から緊張して。本当にツイッター
のDMぐらいですね。見やり取りを 直接的にしていたっていうのは。
おだしょー ぐらいですもんね。あと1回だけ聞いた
のを記事にコメントさせてもらった ぐらいの感じの気がします。
だいち そういえばレビューいただき ました。レビューありがとうございました。
おだしょー 簡単ですけど、だいちさんから
自己紹介いただければと思います。
だいち はい。ツイッターのほうで僕は
だいちとしてやらせている。一応 名前自体本名でございます。以前までは
つい数ヶ月前ですね。まではバック エンジニアとして自宅開発で勤めて
たんですが、今現在はデータベース エンジニアとして勤めております。
最近今年の1月末に息子が生まれ まして、最近はもう息子に付きっきり
な状況で子育てを楽しんでおります。 今日はよろしくお願いします。
おだしょー はい。よろしくいたします。
1月、9ヶ月か。
だいち そうなんですよ。来週、今週か
今週26でも丸9ヶ月になるんで、だい ぶ大きくなってきて成長が楽しい
です。
おだしょー 大変な中本当にお時間ありがとうございます。
だいち 大丈夫です。
おだしょー 今日は本当に雑にしゃべ っていきたいんですけど、やっぱり
せっかくデータベースエンジニア の方と話す機会ってほぼほぼ実は
僕なくて、やっぱり僕がフロント 周りにいるので、せっかくなんで
データベースエンジニアって実際に 何するのっていうとかを聞いて
みたいなと思ったんですけど、実際 どんな感じのことをしたらいいですか
今は。
だいち そうです。僕も入社したばっかり
で多くは任せてもらってないんですけど、 やっぱり大きいところでいくと
データベースの管理っていうところ で、かつ前の自宅で勤めてたとき
では全然そのデータベースでそんな ところまで設計するのっていう
認識でいたのが、テーブルごとに 権限をこのユーザーにはつけて
つけないみたいなのを細かく管理 されていて、そこまでやるんだ
っていうところで、そういった兼ね合い でアプリケーションを開発してる
側から、何かしらこういうユーザー でこういう機能、このテーブル
参照させたいってなったら、ほんと 緊密に参照だけをさせる、もしくは
03:03
更新をさせるみたいなのも細かく 分けられていて、それの権限を
追加してください、なくしてください とかいうのを依頼を受けてやったり
または定期的な監視っていうところ だったりとかっていうのを結構
やってますね。あと僕自身が任されてる ところでいくと、割と構築関連を
テラフォームでやっていけるように っていうのを推進していきたい
っていうところでの二人目、自分が 二人目になるみたいなところで
なのでまだ立ち上がったばっかりで 今思考錯誤しながらテラフォームで
いじってるような状況ですね。そんな 感じで、管理、監視、構築
関連をほぼやっております。
はい、ありがとうございます。確かにテーブル 周り、レベルでロール管理する
っていうのは聞いたことなかったですね。
僕も本当にびっくりしました。パッチ ユーザーでこのテーブルだけにしか
参照絶対しないからっていうので、それを することで監視とかに関しても
厳密にどのユーザーで負荷を 買ってるのかみたいなところまで見れる
っていうところがメリットにはなる っていうので、結構勉強になります。
なるほど。そこまでやれば、そうですね。 ロールによるバグってあんま起きないですね。
データベースでロックしてるぐらい ですからね。
はい。
いやいやいや、ちょっと驚きです。
結構ハードなことです。
取り画面とかに入ってロール管理 してて、このロールの人はここしか
見れないっていうのをAPIレベルで やるのはよく聞く話だったり。
ちなみにテーブル周りの話ちょっと 聞いてみたいんですけど、
はい。
既存のアプリケーションだったり、 新規でやる場合もあると思いますけど、
はい。
データベースのテーブル設計だったり、 正規化だったりっていうところも
全然やったりするんですか?既存の テーブルのいわゆるリファクタリング
じゃないですけど、的なこともやったり されるんですかね?
そうですね。必要に応じてそこもやって、 かなり規模が大きいサービス
っていうところで、大掛かりになると 本当1年、2年単位で見積もって書いて
いくみたいなのを、結構ここ最近 言うと2年前ぐらいにそういうのを
やって、もうその時はテーブル周りの 再設計をし直してっていうのを
やってるっていう話は聞いて、僕は ちょうどその場面に立ち会っては
いなかったんで、めちゃくちゃ大変 だったよっていうのしか聞かなかった
んですけど、そんな感じのですね。
1年レベルって相当すごいですよね。 移行だったり、実際にでもやってみないと
本当怖いですからね、そういうのって。
そうですね。めちゃくちゃ、それこそ CMに出てるぐらいのサービスを
扱ってるんですよね。
すごい。
それゆえにデータ量も膨大で。
そうですね。移行計画めっちゃ大変そう って感じですね。
僕が以前やったもんだと、本当多くて データ量で言っても数千万あれば
06:01
多いデータだなっていうところだった のが、もう普通に億単位であるんで。
億も億で何百億みたいなレベルで。
デカ。
言ってて、僕も全然想像つかないんで。
やばいですね。数百億はやったことない ですね、さすがに。
そこまでいくとクエリ一発じゃ無理 じゃないみたいなとこありそうですね。
そうですね。もうSQLも見ててもよく わかんなくなってます。
これはもうちょっともう一回腰を 擦って勉強しないとみたいな。
僕の経験、過去イージーサイトいくつか 出かけたことあるんです。
僕が入ったときにテーブル6、7個ぐらい ジョインしてわちゃわちゃやってる
クエリだけでやっぱりめちゃめちゃ 長いクエリ見たことがあるんですけど。
やっぱりそういうのって全然現実 である話なんですか?
クエリ自体はイジるっていうのは 今のところまだやってないんですけども。
ちょいちょい見るものを見てると長いですね。
SQLで百何行とかはザラですって ベースでありまして。
本当に長いものは最初の一ページ、 一画面開いたらもうこれ以上見ない方がいいな
くらいの、下長すぎて多分終わりがないなみたいな。
とりあえず長いんだなっていうぐらいで 見てますね。
データベースエンジニアって名前が付くぐらい 専門職必要だなっていうのはやっぱり話聞くと
つくづく感じますね、そういうの聞くと。
そうですね、そういうふうにしかも しっかり分けることによって
分けたからこそそのテーブルごとに ロール管理してみたいなのもできるんだな。
多分全職の受託で行くとフロント、 バックエンドエンジニアとしてやってるけども
インフラ周りも含めフロントもちょこちょこっと っていうのでやったんで、それで兼領して
見るってなると負荷が大きすぎますね、さすがに。
そうなんだよね。
バックエンドの人って結構見る範囲広いですもんね。
今はインフラ周りがクラウド化したので じゃあやれるじゃんみたいな。
じゃあやれるじゃんじゃないんだよって思った。
思いますけどね。
全然スケールでかいですかね、インフラは。
バックエンドだけどアプリケーション作る人と インフラメンテナー、クラウドでやる人と
やっぱデータベースは分けたほうがいいよな っていうのも思ったり。
ただバックエンドも、いわゆる工技並みの フロントエンドってネイティブアプリもそうですけど
フロントエンドってほぼ言語一択しかないので バックエンドって言語大量にあるんですよ。
っていうのもあるので、その言語ごとに 特性であったりするので、それ専門の
エンジニアが立っても、まあまあ細分化する 意味ではありだよなっていうのを思ったりも
最近してて。
弊社のバックエンドのほうでもテックリード チームがあるんですけど、テックリードチームの
アプリケーションだけの人たちでも、 逆に分からんものは分からん。
語をやったことあるとか、英語知識ないとか 訳もしかりだったりするので、それをテックリードで
サポートするほうがつらくないみたいな 感じがあって。
バックエンドの人はすごく今大変すぎるな っていうのを何となく思ってました。
09:04
僕もそれやっぱりそこですね、それゆえに この先のキャリアパスどうしてこうみたいな
あまりにも広大すぎて、どっか的絞れないかな っていう矢先で今のデータベースエンジニア
の話が舞い込んできたんで、データベースで 一本の道絞って、そこを極めるまで
いかないにしても、データベースのことを 大事に聞いたら何か分かるよみたいな
ポジションが得られたらな、みたいな感じで 今に至りますね。
データベースを選んだのは本当に僕は正解 というふうに思っていて、やっぱり一本
突破するんだったら、絶対なくなることがない データベースではなと思ってますよ。
言語で言えるとかだったら、使われないことを 言うしょっちゅうありますからね。
クラウドベンダー変わったりしたら えーってなったりするし。
そういった意味ではデータベースって やっぱもう地球でいうと地面みたいな
話なんで、固いなっていうところで そこを選びました。
結果、アプリケーションとかシステムって データをどう管理するかとそれをどう見せるか
要はアルゴリズムです。
極力二択に尽きるので、その方になるのは 本当正解というか、その分大変なんですよね。
何十年ずっとデータベースのソフトウェアって だいたい今はマイスケールか、キュースグレーか
ノイスケールは大量に這いまくってますけど、 基本的にリレーショナルっていうと
あとオラクルか。
そうですね、その3つが。
そのくらいですもんね。
僕はもうこの業界来て10年目くらい来ましたけど、 未だにずっとやっぱりマイスケールがって話か
とかキュースグレーがの話か、 永遠に出続けてるので。
まあこの先も早々変わらないんでしょうね、 と思ったりしてますけどね。
そうですね、極端に変わることはないのかなっていうので。
僕前職だともう本当マイスケールが ほぼほぼだったんで、
ほんと若干の補修作業みたいなところで SQLサーバーですね。
もうちょっと触って、もうSQLサーバー 何じゃこりゃっていうような
分かんないみたいな感じで何とか乗り越えて。
今に至ってはオラクルが現状メインなんですよね。
オラクルメインでちょっとクラウド移行していこう みたいなところで、
ポスグレーを中心に使ってるような状況で。
マイスケールから入った自分からしたら、
オラクルもちょっと癖あるなっていうところが、
なかなか今もがいてるような状況で。
だからといってオラクルを集中して じゃあ勉強しようみたいになったら、
今ちょうど移行してるっていう話なんで。
そこでオラクル変に意識つけて、
全くないよりはあったほうがっていうところで ありますけど。
っていうのでちょっと右往左往しつつも データベースエンジニアとしていろいろやってますね。
オラクルは高いんですよね、そもそもお金が。
びっくりした、金額減るときはね。
とはいえ、もうあんだけのシェアを取ってるっていうのが事実なので。
12:03
オラクルの資格があるぐらいですからね。
そうですね、会社でもさらっとゴール持ってるよ みたいな話を聞いて、
そんな簡単に取ってるぐらいなネガースでいて、
そんな簡単に取れるもんでもないよねって思いながら。
えー、すご。
結構年違い方で取ってます。
そうなんですね。
あれを、僕も話だけは知ってて、 実は僕オラクル一回も触ったことないんですよ。
クエリも書いたことない。
たまたま使わなかったらやっぱり 住宅系の会社でOSSでやるので、
普通にお客さんがそこにお金払う気がないみたいな。
それはありますよね、お金どこに払うっていうこと。
そうですね。
使うかわからないサポート費に あんな値段出すかみたいな。
その仮に一度やってくれたサポートは ついにかもしれないですし、
やっぱり商用データベースっていうと 信頼性はやっぱりありますけどね。
そうですね。
大きいとこだったらそこを選ばずらえない みたいなところは出てくるだろうけど、
多少の一般的な企業で行くってなったら もう手堅いところに行きがちですね、そこは。
安いし。
そうなんだよな。
だいぶ前にオラクルが値段が3倍くらいに 跳ね上がったみたいな話をどっかで聞いたことがあって。
それを、それゆえの高かったのか。
金額聞いたときびっくりしましたね。
オラクルだった気がしますね。
社内のチャットツールで先輩が 3倍開業権って言い出したから何のことになるか。
そんな開業権はいらないですね。
すげえなと思います。
でも、今まだうちは伸びるんだっていう 判断になったんでしょうね。
そのとき僕がいた、前職ですけどね。
そのときもデータベースまであんまり 触らなかったなっていうのがあるので。
先輩が別の会社のお仕事してるときに オラクルの話をしてたので。
本当にさすがやなっていうのを思い出してました。
マインスケールってよくも悪くも入門しやすいですけど、 ちょっとゆるいというか。
吉田にやってくれちゃうところがあるのが 厳密性が足らないので
ポスグレのほうがいいんじゃないみたいな 感覚が個人的にはあるんですけど。
だいぶ前の知識ですけどね。 僕がだいぶ前にやった話ですけど。
そうですね。
こっちのほうでもそんな感覚での話。
僕も正直ポスグレ全然触ってなかったんで 知識ないんですけども。
マインスケールはゆるいからみたいなところは やっぱり言ってましたね。
ゆるいからポスグレのほうを中心的に 使ってるみたいな感じでしょうね。
なるほどですね。
ちなみに今からデータベース勉強するとなった場合、 おすすめの学習パターンというか、
こういうサイト見たらいいとか、こういうドキュメント、 おすすめ書籍とかあったら聞いてみたいなと思ったんですけど。
15:05
そうですね。僕がデータベースを追ってなった時は、
正直入り口僕データベースSQL嫌いだったんですよね。
何やってるかちょっとよくわかんないみたいなところから入って、
簡単なセレクト文とか更新系だったりとかっていうのは 何回かやればそれなりに理解できて。
多分よくなかったのがその後、
そのSQLを軽く触った後にフレームワークでララベル使って、
エロクエントで書けるようになっちゃって、
あれもうゆるゆるじゃないですか、すごい抽象化されててというか、
書いてたが故にすごいSQL見たらよくわからない みたいな状態に多少なっちゃってて、
それこそ全職でですね。
補修の担当で、ページが読み込みすごい遅いというのがあって、
めちゃくちゃジョインした情報を取ってくるみたいなのがあって、
それを高速化してほしいみたいなのを対応を始めてしたときに、
そのときでも有定SQLで書いたとしても、
50秒いけばぐらいの長さだったんですけど、
当時の僕からしたらもうSQL嫌い無理みたいなところから入っての、
それを何とかこんとか上司の力も使いつつ読み解いて直して、
だいたい何秒だったかな、
当時7,8秒かかったものを何とか1,2秒まで抑えたみたいなのをやって、
その成果はほぼほぼ上司7割、僕3割みたいな感じではあるんですけども、
そういった上司やってるところを見て、
つけたところからSQLが読み解けるようになったみたいなところがあるんで、
なのでなんて言うんですかね、
SQLをまずは書くより読んで試すみたいなところができればいいのかなっていうふうには思いますね。
なので本とかで学ん、
でも全く僕も知識は基本的な知識を吸っ飛ばして実務みたいなところで入ったんで、
それに基本的な書き方、
フロンクがここでセレクトクがどういう構造ってみたいなところっていうのは後からつけた知識みたいなところで、
それに行くと本で行くと、
名前がパッと出てこない。
ちょっと本がありすぎてすぐ出てこない。
あ、違う。
Kindleだな。
ちなみにKindleで読むの派手ですか?
18:01
結構物によって分けていって、
例えば直近で行くと、
数ヶ月前にデータベーススペシャリストを取ろうみたいな意気込みでいて、
書籍買ったんですけど、
それは物理で買ったんですね、
紙の本。
どうせ資格取る、もしくは落ちて諦めようみたいになったら、
その書籍も絶対二度と見なくなると思って。
そうなったらメルカリなり譲るなりしようみたいな。
まあまあ確かにそうですね。
長く使いたい、
例えばそのバックエンドで目線で行くと、
リーダブルコードとかいうのは、
辞書的な感じでちょこちょこ定期的見れたらなみたいなところで、
書籍じゃない、Kindleの方で。
長く付き合うみたいな。
なので一回本屋さんで中身ちょっとパラ見してから、
本で買う、物理で買うかKindleで買うかみたいな、
結構選んだりしてます。
なるほどですね。
長く読む本がそうなんだ。
Kindleなのか。
そうですね、そんな感じで僕自身は使い分けています。
という風に今話してる中で、
その書籍がいつか、
最近Kindleで技術書読んでないんで、
漫画の方がちょっとこう上に来てる。
上に来てて全然探せないっていう状況ですね。
漫画上に来ちゃいますよね。
漫画上に来ちゃうんですね、トップに来ちゃって。
僕が読み物系の本、あんまソースコード出てこないとか、
技術的なネタが出てこないような本をKindleにしてます。
いつでも読めるようにして、
技術のデジタルで読むと、
ソースコードが行ったり戻ったりすると、
違うところで開業されたりとか、
そういうのが正直あったんですね。
ありますね、Kindleに適応してないタイプですね。
あ、あったあった。
達人に学ぶSQLですね。
徹底指南書。
名前は知ってて読んだことないやつ。
誰が書いてるの?
Mickさんが書いてるやつの本ですね。
入り口これ読むの辛いと思うんですよね。
僕でやっと、こういう意味なんだ、こういう意味なんだ、
みたいな感じで紙砕きながら読み解けたんで。
入門ではなくて、初級ぐらいはトップに終わった人が
次のステップ行くぐらいの書籍ですよね。
そうだよね、それで僕初級でっていうのはあんまり、
本では読んでないで、
実務で身につけた感が。
僕、プログラミングスクール的なところから出て
エンジニアになったんですよね。
それがちょうど2年前。
自宅に入社して、それでいくと今から丸3年前ぐらいから
21:03
勉強し始めて。
その時が当時、携帯ショップの店にあったんで。
そこからコミュニティの中で勉強して、
コミュニティの中の勉強方法が課題が与えられて、
その課題を自力で解くっていう。
コードに落とし込んでいくみたいなのをやって、
その中でSQLを書いて、
っていう風な身につけ方をしたっていう感じだったんで。
実践あるのみみたいなところがSQLは大きいんですかね、多分。
じゃあもう、何かしら自分の中でネットで何でもいいので
課題見つけできて、
DockerでSQL環境を適当に立ち上げて、
クエリガンガン一回書いてみたり、
読めるんだったらクエリ読んでみたりがいいって感じですかね。
課題的なのでいくのであれば、
最近ちょこっと出てきたSQLのコンテストがあって、
つい先日の第3回かな、行われてて、
僕それ参加しようと思ったら全く時間を勘違いしてて、
参加できずじまいだったんですけども、
今リンクを送りますね。
これをコンテスト自体に参加しなくても問題が出てるんで、
それをいい感じに勉強として使うのがありなのかなっていう風に、
問題があるんで、
ほんと最近ですね。
最近ですね、これ。60分時間内で難易度が4つ。
なんか普通に強プロ感がある出し方。
そうです。のSQLバージョンみたいなので、
これで実践していくのが割といいんじゃないかな、
問題としてあるんで、
結構実務に近しい部分があるのかなっていうので、
そんな感じです。
いやもうSQL数年書いてないから、
久しぶりに書くと絶対いろいろ忘れてる気がする。
優先度はちょっと考えつつ、
たまにはやろうかな。
きっさん結構言語の幅広いですよね。
いろいろ、僕もさてPHPもしっかり、
いろいろ触ってきてはいるみたいな感じじゃないですか。
そうですね。一応触ったってだけで言うと、
そんなに狭くはないかなと思いますけど、
あんま広いことが強みになるかっていう感覚はないですけど、
PHPと若干のRubyレールズもやったし、
ECサイトやったので、
バックエンドももちろんやって、
データベースですね、
KeyValue型のSQLはいくつか触りましたけど、
でもKeyValue型は何使ってもそんな変わんないので、
ぐらいじゃないですかね、言語。
大学で必須科目にC言語とJava終わりましたけど、
24:00
なるほどなるほど。
全力で友達に単位取ってもらって卒業したので、
一応若干わかりますけど、ほんと若干。
ラベルも本格的に触ったことは実はなくてですね。
一応単語聞いた記事だったり全記事見て、
こんなのあるんやなぐらいの感覚でしかわからなくて。
僕がPHPでやったのは、バージョン4から触ったんですけど実は。
バージョン4。
その当時YAMでインストールが4点いくつか確か入ってた気がしてて。
途中から確か5.3がデフォになってますけど、
その辺ぐらいしか記憶にならなくて。
いいってわかります?YIIっていうフレームワーク。
そんなフレームワークは確かに初耳ですね。
確かにYes, It, Isの省略だった気がしますね。
もう今YIIは2でも出たんかな?YII3までいったのかわかんないですけど。
っていうのが確か出てて。
いやー懐かしいですね。
そんなフレームワークあるんだ。
やっぱりYIIです。もうYIIで出てるんだな。
YIIと読むらしいですね。
簡単・効率的・広角調整って書いてるんですけど、
僕1の頃にしか触ってないんですけど、
広角調整悪すぎましたけどね。
簡単かっていうとそれもちょっと悩ましくて。
よくも悪くもフレームワークに乗っかれよっていうフレームワークですね。
ガチガチに。これに乗っかったら同じように書けば保湿性も統一性も上がるし、
この通り作ってくれよって言ってたので、
外れた瞬間に茨の道みたいなフレームワークでした。
へー。
その時に僕のORマッパー周りも結構触り始めて、
その周りORマッパーっていう単語さえ知らなくて、
みんなが使ってるものこういうものねって知ったんですけど、
独自フレームワークを使ってる会社にいて、
そこに言いも組み込もうと頑張ってて中途半端になって、
どっちも知らなかったりしたのと、
クエリーも複雑度があって、
ORマッパーの制約とクエリーの複雑度とか柔軟性が求められる中に、
マッパーの制約厳しすぎて、
もうすらんけだったので、
そこからORマッパーあんま好きじゃなくなったんですけど、
別にマッパーが悪いわけじゃないことはないですし、
実装は全然悪いけど、
多分直線で書きたいなみたいな調子になります。
とかあとコードイグナイターとかフューエルPHPとかですかね。
あれぐらいライトで書きやすいのは僕は結構好きだったんですけどね。
もうメンテナンスされなくなったっぽいし、イグナイターのほうは。
イグナイターって聞いたことなかったですね。
そのコードイグナイターのメンバーがフューエルPHPを作ったんですよね、新たに。
なるほど。
同じように燃やす系の単語が出ますけど。
フューエルは電流でイグナイターは確かに比例ですからね。
なるほど、なるほど。
URLベースのもので、いわゆるAPI作るんだったらこれぐらいライトで、
かつ直接的で分かりやすいなって僕は思ってたんですよ。
僕まだ業界として人間しかいないんで、常に知らないことが出てくるっていうのが。
27:00
ですよね。
当時はもうなかなか、またこれも覚えなきゃ、これも覚えなきゃみたいなテンテコ前でしたけども、
ある程度来ると、あ、そういうのがあるんだね、分かったよぐらいな感じで流していける。
本当に自分が必要だって思うものを後押し持って進めるようになってきたなっていう。
そこがめちゃくちゃ大事ですね。
本当その感覚になるのがね、初級からそこに行くのが多分一つの壁の中も僕はありますけどね。
銀さんで言うとこの業界は何年ぐらいになるんですか?
僕が?本当は確か10年目だった気がします。
大学院僕一浪して入って大学卒業して、帰って25から。
今年35なんで、満10年経ったのかな?10年目なのかな?いや、経ったのかな?って感じです、実は。
へー、そうなんですね。大先輩だ。
僕は浅く広くなタイプで、あんまり頭が良くなく、コンピューターサイエンスの勉強したけど忘れて卒業してるので。
とにかく実践の方があるのみやなっていうので。
僕もそういうなんですか、バータリテキと言ったら聞こえ悪いですけど、とにかく飛び込んでしまって見つければいいじゃんタイプだったので。
確かにそれはありますね。
逆に言うと体系だって学んだり、いろんなものをまとめてドキュメントに書いたり、記事書かれる方には未だに敵わんなって思うなんとなく。
同感的なのはありますけどね。
でもそれを自分がやるかって言ったら合わないというか、なんか違うんですよね。
やりたい欲はあるけど、モチベーションがそんなに高いかって言うとそんなこともないなっていう。
大抵的なのは本当。
そういうことをね、やってくれる人が他にいるので、また乗っかりたいっていう。
なるほどね、確かに。
でも、ちゃんと最終的には抽象化したものごとが考えられるようにしたいところでありますしね。
まあまあそんな感じです。
あれですね、ちょっと話が脱線しちゃったんですけどね。
結論としてあれですね、僕が学んできたみたいなところはもう実践あるのみたいなところでですね。
僕のやっぱりまだ歴が浅いっていうか、入り口がもう初学からでっていうところで始めたんで、
初めてこれからプログラミングを学びたいんですけどみたいな人の話聞いたりとかするんで、
そういった人向けでいくと、
本当に読みやすい何か書籍を見つけて順を追って学んでいった方がいいのかなっていう。
もしくはもし可能であれば実務的なところを触れる環境を見つけてそこに飛び込んでみるのどちらかかなっていう感じですかね。
そんな感じのやり方でやっていければいいんじゃないかなっていう気がします。
お話聞いた感じ、このだいぶ前ですけど転職ブログ書いてるじゃないですか。
30:03
あれも拝見させていただいて。
ありがとうございます。
データベースエンジニアになって今楽しいのかなっていうのが一番聞いてみたかったんですけど、話しぶりが楽しそうだなって聞こえました。
そうですね。やっぱり的が絞ってるのがやりやすいんですかね。
前職の受託でいくと今日はしっかりコード書いて、明日はインフラについて調べてみたいな。
次の日はJSをどう書いたらいいんだって全然当たんないんだけどこれ何?みたいな。
あっち行ってこっち行ってみたいなのがないのがストレスフリーですかね、自分にとっては。
なるほどですね。
で、ガッツリ触ってるわけではないんですけどね、ちょっとした機能を言われたときになかなか辛い思いが。
ゆえにすごい勉強になった分はすごい転職の会社にはすごい感謝している。
上司の人には直続に見てもらっていたんですけども、そこの中で辞めてっていうのは非常に申し訳ないですね。
ただ自分のキャリアはみたいなところでそこは ちょっと割り切ってやってるんですね
ただ感謝だけはずっと伝えたいなみたいな感じ
なるほどですね
そういう先輩は誰かしらみんないるんだろうなって 勘違いはありますけど
うーん、ありますね
伝えられるのはすごく大事ですけど 恩をお送りって言葉があるんで
広築に続く方にはどんどん伝えていけば いいのかなっていう感はありますね
いいですね、恩をお送り
僕も見知らぬ人、会ったことも話したことない人の いろんな知見だったり
技術記事だったりとか書籍だったりから学んで
今に至るまでにもらった知識を 次の人に送りたいなっていうのがあります
いいですね、僕も恩をお送りって言葉を知ってますし
今改めて意味を聞いたら
それだなっていう気がしましたので
この言葉は僕ももらったので今こう伝える感じですね
僕ちょっとまたどなたかにパスしていく
どんどん広めていかないと
ある意味でOSSって恩送りの連続みたいなところ
みんな無償でやってますもんね 自分の時間を使って
でも本当そういうことだよなって感じがあるので
その意味でエンジニア界隈の業界は ある意味で温かいなと思ったりします
そうですね、結構会社によっては みたいな話は聞きますけど
実際に業界入ってみたらいい人ばかりというのも
あれかも大げさかもしれないですけども
温かみはやっぱりありますね
エンジニア的なのがすごく聞きたかったので
割と満足をしている
はい盛り上がっているところなんですけど
一旦ここで区切らせていただきたいなと思います
また今回のゲスト公開もですね
長くなってしまったので 前半後半に分けていこうと思います
というわけで前半パートの エンジニアの関するお話は
33:01
ここで終了になります
では後半も楽しく雑談をしていきますので
お楽しみいただければと思います
では前半パート終了いたします 後半で会いましょう
バイバイ
33:14

Comments

Scroll