Joined August 2019
- Tweets 3,122
- Following 874
- Followers 3,883
- Likes 17,499
169 Photos and videos
Pinned Tweet
May 9
「データエンジニアって何？」
「データ系の職種って何がある？」と
よく聞かれるので図でまとめてみました！
転職や初学者の整理に使ってもらえると嬉しいです。
面接前にこの図を使って各職種の役割と
合意形成までの流れを把握しておくと良いと思います。
あなたはどの職種やってますか？
2
8
155
17,919
データサイエンス学部があるなら、データエンジニア学部があってもいい気がする。
DEって新卒採用がほぼなくて、他職種からのジョブチェンジで入る人が多い。
偏った意見だけど、もう少し育てる仕組みがあってもいいよなと
2
1
27
3,029
TsK｜データエンジニア@メガベン retweeted
直近3年間、データアナリストとデータエンジニアの両方の採用を走らせてましたが、データエンジニアの応募数はデータアナリストの1/5以下でしたね、、
DEの新卒採用ってほとんどないし、何某かのエンジニアからDEにジョブチェンジした人がボリューム層なので、市場にDEがマジで少ないです。
何某かのエンジニアからDEにジョブチェンジさせ、社内で育成することを前提とすれば母数を広げられますが、経験上ソフト面の育成がとても難しかったです。
データエンジニアとアナリティクスエンジニア、どこにいるんだ…
仕事は山のようにあるのに、全然人が入ってこないし、人手が足りていない。
これってこの職種だけの話なんだろうか?
それとも、データ職全体で同じように人手不足なのか気になる。
2
3
59
20,117
TsK｜データエンジニア@メガベン retweeted
調査で使う機会があるような気がしますが(例えば、a right outer bでbに結合できないaの行を確認)、でもそれだったらfull outer joinでまとめて両方の表の互いに結合できない行をまとめて確認すればいいような気がします。
Jun 13
SQLずっと触ってきたけど、RIGHT OUTER JOINって一度も使ったことない。
実務で使うケースあるんだろうか? だいたいLEFT JOINで書けるし、出番が思いつかない。
「LEFT作ったしRIGHTも作っとくか」のノリで生まれたんじゃ…とすら思ってる（さすがに違うと思う）
1
1
4
708
データエンジニアとアナリティクスエンジニア、どこにいるんだ…
仕事は山のようにあるのに、全然人が入ってこないし、人手が足りていない。
これってこの職種だけの話なんだろうか?
それとも、データ職全体で同じように人手不足なのか気になる。
11
10
118
38,350
TsK｜データエンジニア@メガベン retweeted
Jun 13
20年以上SQL使ってきたけど、RIGHTはいまだに一度もつかったことありません。
Jun 13
SQLずっと触ってきたけど、RIGHT OUTER JOINって一度も使ったことない。
実務で使うケースあるんだろうか? だいたいLEFT JOINで書けるし、出番が思いつかない。
「LEFT作ったしRIGHTも作っとくか」のノリで生まれたんじゃ…とすら思ってる（さすがに違うと思う）
1
1
21
3,675
Jun 13
エンジニアで「新人はAI禁止」みたいなの、めちゃくちゃ違和感があるんだよなー
確かに、何も考えずにAIの出した結果をそのまま使うのは避けるべき。
だけど一方で、特に新しい知識をインプットするときはかなり捗るし、AIを使えるかどうかで成長速度が全然違うと思ってる。
はたから見ると、AIの使いどころのルール整備ができていないから、一律で「新人はAI禁止」にしている様に見えている。
禁止するんじゃなくて、使いどころを教える方が建設的なのでは？と
Jun 12
まだ基礎が身についてない人がAIを使うと2,3年後にどうなるか想像できる。AIは神様じゃない。AIを使いすぎると思考する脳が揉まれなくなり、閃き「神が降りてきた」がゼロになって新しいものが生まれなくなるんよ
1
3
34
9,165
TsK｜データエンジニア@メガベン retweeted
Jun 13
で、実務でもLEFT JOIN十分だと思われる。一応SQLの可読性みたいなところで使い分ける人もいるけど、LEFT JOINで統一したほうがいい気もするし、確かパフォーマンスも変わらないはず。
1
1
20
1,542
Jun 13
最近、AIを使ってかなり速いスピードでアウトプットを出せるようになったのだけど、まるで高速で車を走らせているような感覚になる。
スピードが出ているぶん、状況を判断する時間はどんどん短くなっている。
道幅が広いところはいいけど、狭い道で同じスピードを出すと一瞬で事故る。
信号無視も、側溝への脱輪も、判断の間違いは速ければ速いほど起きやすい。
要するに、周りの状況を見ながら、事故らない範囲でスピードを出すことが今求められてるんだと思う。
1
1
19
2,025
Jun 13
SQLずっと触ってきたけど、RIGHT OUTER JOINって一度も使ったことない。
実務で使うケースあるんだろうか? だいたいLEFT JOINで書けるし、出番が思いつかない。
「LEFT作ったしRIGHTも作っとくか」のノリで生まれたんじゃ…とすら思ってる（さすがに違うと思う）
30
52
517
144,294
Jun 12
最近、人と話す時間よりClaudeと話す時間の方が長いかもしれない。 1日の半分以上は話している気がする。
たたき台のブラッシュアップも、会議のアジェンダ作りも、相談しながら一緒に進める感じ。
自分だけだと出てこなかったアイデアをくれたりして、明らかにアウトプットの質が上がった。
ただ、言われたことをそのまま鵜呑みにする使い方は違うと思っている。議論しながら、自分自身もレベルアップしていける関係がちょうどいい。
だからこれからの転職先選びは、「最新のAIが使える環境か」も基準に入れた方がいいと思う。ここで成長速度も経験量も、かなり差がつくはず。
ただその分、めちゃくちゃ頭を使うので1日の疲労感はすごいなと 笑
1
23
1,471
Jun 11
自社開発に来て改めて思うけど、SIerと自社開発は本当に環境が違う。
どっちが良いというより、性格による合う合わないが大きい。
自社開発が向いている人
・自分で期限を調整しながら進めたい
・プレッシャーは少ない方が力を出せる
・気軽に上流から挑戦してみたい
SIerが向いている人
・決まった期限の中でカッチリ進めたい
・明確なゴールがある方が動きやすい
・責任感を持って顧客と向き合いたい
ちなみに今は、上流を動かせる人が一番足りていない。 それを低リスクで経験できるのは、自社開発の大きな魅力だと思う。
転職を考えるなら、まず「自分はどっちのタイプか」を意識すると失敗しにくいはず。
6
5
113
29,293
Jun 9
「エンジニアはもう不要」と「エンジニアが足りない」、真逆のことが同時に言われてるけど、最近どっちも正しいと分かってきた。
足りないのは「実装する人」じゃなくて、課題に対して要件定義やフェーズ分けをして、場合によっては課題そのものを見直す。そういう上流を動かせる人。
逆に、決まった仕様をその通り実装する仕事は、AIに侵食され始めているし、できる人も多い。
だからこの層の需要は減っている。
現場感覚でも、要件定義やフェーズ分けの仕事がめちゃくちゃあるのに、人が全く足りていない。
これから目指すなら、実装だけで終わらず、上流を経験できる環境を選んだ方がいいと思う。
3
4
37
3,936
TsK｜データエンジニア@メガベン retweeted
僕は奇跡的に、SESでのテスター生活から脱却し、キャリアを好転させることができました。
志望なんて全くしてないのに、2年半もテスターをやっていた。
ジョブチェンジへ向けた僕の努力や戦略が功を奏した部分はあるとは思いますが、大前提として本当にラッキーでした。
Jun 8
未経験SESのとき、テスターとかキッティングはヤバそうと思って、志望しなかったんだけど
実際そこからうまく転職、キャリアアップ出来た人はいるんだろうか、と気になってる。
一回入ると、そこから抜け出せずに、ずっと同じような案件にいる人が多い気がしてる。
1
1
11
2,470
TsK｜データエンジニア@メガベン retweeted
Jun 8
コールセンターがスタートで、SES→SIer→事業会社の社内SEです。
会社内での知名度を上げて異動の希望を通りやすくして2回異動、かつ各現場のお客様やメンバーとは良好な関係を続け、結果最初の現場の元請けに転職しました。
今思うとどんな知識や経験も役に立ったなと思います。
Jun 8
未経験SESのとき、テスターとかキッティングはヤバそうと思って、志望しなかったんだけど
実際そこからうまく転職、キャリアアップ出来た人はいるんだろうか、と気になってる。
一回入ると、そこから抜け出せずに、ずっと同じような案件にいる人が多い気がしてる。
1
1
7
1,986
Jun 8
未経験SESのとき、テスターとかキッティングはヤバそうと思って、志望しなかったんだけど
実際そこからうまく転職、キャリアアップ出来た人はいるんだろうか、と気になってる。
一回入ると、そこから抜け出せずに、ずっと同じような案件にいる人が多い気がしてる。
1
1
23
10,501
TsK｜データエンジニア@メガベン retweeted
SQLは、AIエンジニアにとっても必須スキル。
pandasだけでは対応できない現場が多々あります。
自分もSQLの学習は教科書から入ったけど、
文法は頭に入っても「膨大なDBテーブルからどう取り出すか、どう組み合わせるか」は全く身につかなかった。効いたのは以下
① SQLコードと入出力テーブルを見比べながら、差分を確認する
② 現場のSQLをAIに投げて、その場で必要な文法の例題を出してもらう
これだけで感覚の身につき方が全然違う。
SQLに限らず、プログラミングを理解するには「AIに書かせる」より「自分で書いて動かす」方が圧倒的に早い。
まず自分で自由自在に扱えるようになってから、AIを使うのがベスト。
Jun 7
SQLを勉強し始めるとき、 参考書から入るのは本当にやめた方がいい。
実際、自分もそこから始めたんだけど、全く理解できなかった。
一番効いたのは、練習問題などで「実際のデータベースにSQLを投げて、返ってきたデータを見ながら理解する」こと。
少しずつSQLを変えて、どこで結果が変わるのか差分を確認しながら学んでいった。
特にJOINは、教科書だと意味不明だったのに、この方法だと早い段階で理解できた。
SQLは座学より、実際に手を動かして結果を見て覚えるのが一番効率がいいと思う。
2
12
198
42,108
TsK｜データエンジニア@メガベン retweeted
Jun 7
私もどうやってDB関連の勉強したかなぁと思い返すと、某製品使ってて出来上がったDBを別のサーバーにリストアして、どんな風なデータ構造になってるかとかそこからどういうSQL発行すればいいのかとか調べて勉強したなぁ。
多分中身空っぽのDBを触ってもあんまり面白くないので、なんらかのサンプルDB（と言いつつ実際に使われたようなもの）を入手していじくり回すというのは理にかなってると思います。
Jun 7
SQLを勉強し始めるとき、 参考書から入るのは本当にやめた方がいい。
実際、自分もそこから始めたんだけど、全く理解できなかった。
一番効いたのは、練習問題などで「実際のデータベースにSQLを投げて、返ってきたデータを見ながら理解する」こと。
少しずつSQLを変えて、どこで結果が変わるのか差分を確認しながら学んでいった。
特にJOINは、教科書だと意味不明だったのに、この方法だと早い段階で理解できた。
SQLは座学より、実際に手を動かして結果を見て覚えるのが一番効率がいいと思う。
1
2
9
1,414
Jun 7
SQLを勉強し始めるとき、 参考書から入るのは本当にやめた方がいい。
実際、自分もそこから始めたんだけど、全く理解できなかった。
一番効いたのは、練習問題などで「実際のデータベースにSQLを投げて、返ってきたデータを見ながら理解する」こと。
少しずつSQLを変えて、どこで結果が変わるのか差分を確認しながら学んでいった。
特にJOINは、教科書だと意味不明だったのに、この方法だと早い段階で理解できた。
SQLは座学より、実際に手を動かして結果を見て覚えるのが一番効率がいいと思う。
4
17
186
67,156