00:01
ITトリオの時間です
ITトリオの日常は エンジニアとして働く3人が集まって 雑談ミーティングする番組です
毎週月曜日に更新するこのポッドキャストは 東京のスタートアップでフルスタックエンジニアとして働く小倉くんと
名古屋でエンジニアとして働く元デザイナーチーズと
動画投稿が趣味のフルスタックエンジニアのラベちゃんでお届けしています
はい、じゃあ今回は技術領域を初めて越境したら大変だった話をしたいと思います
よろしくお願いします
なんかチーズさんが最近技術領域を越境したら大変だったということで聞いていこうと思うんですが
ちなみに今日の放送は最後の方にお便り読むコーナー作ろうと思うので
ぜひ最後まで聞いていただけたら嬉しいです
よろしくお願いします
よろしくお願いしますということでテーマに移るんですが
越境したんですねチーズさん
結構私のキャリア喋ってること多いと思うんですけどまず元々デザイナーですと
確かに
フロントエンドで初めてエンジニアリングというかちゃんとコードを書くようになって
一回もサーバーサイドやインフラって取得できていなかったんですけど
この度会社で機会があってサーバーサイドをチャレンジしてみたんですよ
それこそ触ったことのない言語コトリンっていう言語だったんですよ
モデリングからDB設計とかも含めてもう一つの機能を作り切ったっていうのをやったんだけど
だいぶ大変だね
だいぶ重かった
想定が2週間程度で終わるぐらいなそこまで大きくない機能だったんですけど
私がやることによって倍の4週間かかってしまい
毎回すみません遅れてますって言い続けて心が痛かった
痛くなるよなそれは確かに
反省点とここは良かったなと越境してみて思ったこととか色々あるので
そういうのを話していこうかなって思ってます
まずね失敗したというか思った通りにうまくいかなかったこと
さっき話した通り想定2週間で終わる予定だったものが伸びちゃっているんですけど
小さな機能だったから設している人の真似をしていけばそこまで大きくは膨らまないだろうと
あっても2倍以上はかからないだろうと思ってたんですよ
プラス5時間とかかなって
そんくらいかなって思ってたけどだいぶ多く見積もった方がいいです
2、3倍かかるかなと思って
そうだよね
ここで見積もりをミスってしまったことが一番の範囲で
03:03
見積もりとずれてしまう背景としては
まずコードに対する執着感がないからそこを習得していったりとか
言語に対するエコシステムの理解とか知識がまず土台が全然違うから
それも学びながら自分は作っていくんだぞっていうところで
その覚悟をすることと
今回一つの機能作りきったと思うんだけど
一つの機能よりもう少し小さいところから一挙していくべきだったなっていうところ
ガツンとやりました最初から
確かに機能1個って結構大変だよな
DBのモデリングからとかって全てかなり重要に大きな
そうだよね
一番の反省はもっとフロントの近いところからやっていけばよかったなって
そうだねデータ触るって結構大変だね
しかもなんかつまづいたところでそういうデータの暗号化周りを忘れていたとか
そういうところも含まれてて
やり方考えようって思いました
でそんだけでかいものだと見積もりとずれる量が膨らむんですよ
そもそも見積もりなんてできないよね
そんななんか触ったことない言語で触ったことないコードベースで触ったことないツールを使って
1から10まで全部やります
見積もりはって言われてもいやーわかんないですよね
わかんなかった
2倍くらいっしょ2倍もかからんっしょって楽観的に言ったが
その見積もりをそんぐらいでいけますって言っちゃったから遅れましたっていう報告をしなきゃいけない羽目になりまして
はいはいはい
まじでしくじり先生ですねこれも
しくじり会がこっから
しくじり会が
でもめちゃくちゃ良かったなってやってよかったなってことはめっちゃある
例えばなんか今までフロントエンドでこうやって考えてきたアーキテクチャの考え
なんかバックエンドを一回行ってみるとまあより堅牢でちゃんとしているみたいなところがあって
なんかフロントもろいなーって思っちゃって
なんかそういうところをバックエンドのそういうアーキテクチャの考えとかをフロントエンドに導入してもっと固い設計ができないかなとか
フロントより誰が書いても同じコードになるなーっていう印象があって
例えばさフロントスタイリングとかもフロントエンドって含めてと思うんだけどスタイリング実現するために結構違うコードになりがちなんだよね
そういうところをスタイリングあまり精通してない人でも書きやすいようなエコシステムを構築しておいて
06:07
誰でも簡単に見た目を再現できるとか
そういうことをうまく隠蔽すればできそうだなーとか
そういう考えもバックエンドを経由して思ったし
感情としてバックエンド行ってからフロント書いた時に
なんか分かんないけどフロント書きたくないなって思ったよ
あれ?
そんなことあるんだ
そう
フロントのコードってすごい不安になっちゃって
バックエンドはこれが正しいってちゃんと思えるようなコードが書けたなと思ってて
それはアーキテクチャに沿っているとか
革新的な土台のモデリングとかDBの設計とかちゃんとしてれば
中のロジックで結構革新的に書けるなって
そういう文法的な違いはあるとは思うけど
そういうところがちゃんとフロントエンドのアーキテクチャ導入しているんだけど
まだ脆いなってこの部分一旦迷うよなみんなって
どう判断してるんだろうって
例えばなんかちょっとだいぶ昔の話になるけど
アトミックデザインって流行ったじゃんねフロント界隈って
流行ったんですよ
コンポーネント原子分子なんだったっけ
その先忘れたんですけど
そういう流度に分けるっていう
でもそれってこの流度判断って
内部の人間たちに結構よる部分とかあったりして
判断するの難しかったんですけど
バックエンドは結構そういうドメインロジックを切り分けてとか
確かに部分的には判断が必要な部分はあるけど
ある程度そういうアーキテクチャに沿って考えれば
正解にたどり着けるなっていうところが多くて
私が使ってたサービスはオニオンアーキテクチャっていう
アーキテクチャの手法を用いてたんですけど
クリーンアーキテクチャの一種でサマンネギ型って
そういうのがあって
それに沿えば
その教科書みたいな本があって
それを見て
これは何々層に書けばいいんだなっていうことがある程度わかる
状態にはなってたので
ちゃんとしてる設計のサービスに入れたっていうのもあるんだけど
確かにそれはあるね
っていうところは感じたな
ITトリオ
僕も前職で越境したんですよ
したんですよっていう言い方があるかもだけど
僕その前々職までは
ウェブフロントエンジニアとしてやってたんですけど
09:00
前職の会社が
言語は全部タイプスクリプトとかで同じなんですけど
ウェブがリアクトで
スマホのアプリがリアクトネイティブで
バックエンドはタイプスクリプトで色々使ってっていう感じだったんで
なんかフロントエンド
バックエンドからフロントエンドまで
全部書けるみたいな環境で
そこで初めてモバイルアプリ系の開発とか
バックエンド系の開発とかっていうのを
僕もしたんですけど
結構いろいろ今チーズが言っていたことにすごい共感できるなと思ったですね
本当?
そうなんだ
なんかまずむず
越境した最初ってなんか
土地感がないのは
まさにそうで苦労したなっていう風に思って
僕それを特に感じたのが
リアクトネイティブはタイプスクリプトとかで書くんだけど
モバイルアプリの開発って
機能によっては
ネイティブ側の言語でネイティブ側の処理を書いて
それをつなげるっていうことが必要だったりするんですよ
リアクトネイティブの場合
だからタイプスクリプトでリアクトで書く部分書いておいて
そこからOSのAPI呼び出す部分を
それぞれのAndroidとiOSの言語
AndroidだとKotlinかJava使って
iOSだとSwiftかObjective-C使って書くっていうのを
僕何回かやったんですけど
そのときにめちゃくちゃ感じて
特に言語が違うだけだったら正直
文法のところはなんとなく
文法だけならわかる
そうね文法わかるね
それ以外のエコシステムが全くわからなくて
最初順を追ってやると
最初にまずエディターの部分でつまずいて
わかる
僕いつもVS Code使ってるんですけど
Kotlin書くときって
多分Androidの場合はAndroid Studioを使ったほうが
いろいろ整備整っていて
iOSの場合はXcodeを使って
そういう人とか書くのが普通だと思うんですけど
そもそもその時点で
エディターのオプションとか
コマンドの使い方とか全然違うから
あのVS Codeで言う
あのコードをしたいと思ったときに
そもそもそのコマンドがどれだかわからないから
まずそれを調べるところから始めるみたいな
やったー
最初はそもそもコードを書く前の
衝撃が結構高い
っていうのがね
あったなーとか思って
それは調べるしかないんですけど
すぐに覚えれるわけではないから
時間もかかるっていう
で、その後どうなるかっていうと
なんか言語を書くための環境を整備するとかなるんですけど
なんかその
Web系とかだったら
大体その
NPMインストールで必要なものを入れて
まあなんか大体データ通信するなら
12:01
あのライブラリを入れて
なんかJavaScriptでサーバー立てないなら
ExpressかNestJSかなとかそういうのが
とにかく分かって
周辺ツールもなんか
ESLintとかプリッターを入れれば
うまくなるんでしょうっていうことが
コードを書くための
ライブラリとその補助ツールとかを
大体分かっているんだけど
それが他の言語になると
えーっと何を使うんですかねー
っていうところから始まって
それがね
なんか
どこを見れば正解があるかも
最初分かんないから
そこでまたエディタの設定終わった後でも
コードを書く前の段階で
またさらに若干
周辺ツールをさらに調べていくということで
時間がかかり
ないよねみたいな
すごい苦労したなーとかいうのも
あり
でもなんかそれで
コード書くための環境整備できました
ってなってやっとコード書くってなったら
やっぱコード書く
ってなったらなったで
大体の
言語の文法は分かるんだが細かいこと
しようとした時に若干エラーが出て
なんだこのエラーの内容は
っていうところで
細かく調べる
言ってることは分かるんだが
他の言語触ってるし
なんとなく分かるだけだと
実際に開発する
コードが書けないんで結局なんか
その部分については詳しく調べなきゃいけないぜ
っていう
そういうところで
まあなんか
障壁がなんか
4個ぐらいあって
何かをしようとするたびにその5個全ての壁を
ぶち破る必要があるっていうのを
連続でどんどんやる必要があった印象で
すごい大変だったなぁ
っていう思い出があります
いやめちゃくちゃ共感だわ
本当にエラーにぶつかった時の
うーん
ってなる時間の長さが
あまりにも長かったなっていうのは
すごい覚えてて
特に自分の実装の
コースの割合なんだけど
見積もりが1割
メインのコード書いてるのが3割
残りテストだと思ってて
あーテスト通らんかったのよ
テスト通らん時のエラーが読めないのよ
しかも
どういうテストをしてるか
ロジックのテストだけじゃなくて
ちゃんとDBに格納して
そのDBの値が整合性取れてるかみたいな
ところまでやってるっていうのに
気づくのに時間がかかった
あそこまでテストやってんだね
すごーいって
あーそういうことか
すごい厳格で
テストも自分が想像していたより厳格なもの
ただ単に
テストアウトプットのチェックをしてるだけじゃなくて
例えば
グラフQLスキーマだったら
このスキーマのやつを実行したら
こういうデータが格納されてて
そのDBの値とかをチェックしてるよみたいな
そういうことか
確かにさ
それってさバックエンド出身だとさ
当たり前にやってて
前提としてなってるからさ
15:00
それを逆に教えるとか
難しいかもしれないしね
そうなんだよねきっと初めて知ったんだよね
フロント結構さ
フロントもコンポーネントテストって
バックエンドの側でなんでやってるのって感じだったり
すると思うんだけど
確かにね
それに近くて
ロジックのテストだけはやってるかと思ったら
思った以上にちゃんとテスト
その
データベースとの値の整合性とかも
やってるんだっていうところ
に
気づけなかったりとかあるから
これ多分お互いの影響であるんだろうな
って思いますね
エディターもめっちゃ
時間かかったな
あとねそうやって
迷子になり続けながら前に進むとですね
まずコミット汚くなる
それはわかるわ
コミット汚くなって
一旦すべてリセットして
コミット全部整えました
はいはいはい
であとプルリク超絶でかくなる
分割ポイント分かんない
どういう文脈で
切り分けたら
コードレビューしてくれる人が
見やすいかっていうのがわかんなくて聞きに来ました
それは
あと何か
あったかな
何かあったかちょっと思い出せないけど
やっぱ小倉くんが言う通り
自分が想定しているところ
以外の壁が大きかったりするね
そうね
あと
やっぱ文法も
頭に入ってないからチャットGPTに
こういうコードが
JavaScriptだとこういうコードを書きます
コトリンだったらどう書きますか
っていう質問を
すっごいやった
こう書けるのねありがとうって
結構近いからそこを繰り返していって
コトリンの文法を覚えた
なるほど
一冊はやったんだけどね
勉強したんだけど
一冊だったら文法足りなかった
ジズムで書くんだったのね
もっと効率的なコードあるでしょうとか
そう
それそれそれ
思った
自分の理想とする挙動を
実現するコードを書けたとしても
果たしてそれが
最善の書き方なのかが
普段つかないので
どうするんだこれ
っていうのは何回かあった気がするな
それはほんとあるわ
なんかこれ気にくわんなみたいな書き方あるもんね
もっといい書き方
あるんじゃねっていう
何年経っても脱げないみたいな
それはある
コトリンはありがたいことにさ
すごいJavaScriptに近い考え方の
ものが多くて
それこそあの
JavaScript出身の人ってあれプロトタイプ
みたいなやつめっちゃ使いたいんだよ
マップとか
はいはいはい
そういうのは結構ちゃんとあるから
配列操作しやすいなーって
でもあれってさ
ない言語全然あるじゃん
なんか
語とかってそういう便利
ユーティリティみたいなのが少ないイメージで
18:00
だからこそ
語はそれこそ
書く人が複数人いたとしても
だいたい同じ書き方になるっていう
噂を聞いたことがあるんですが
この辺は言語によって
全然違うよね
そういうところもね
なんかやっぱ自分が今まで
書いてある言語通り
なんか今まで
書いてる言語だと自信持って
これいいことだわって思える場合あるけど
勉強して
普段書いてない言語で書いてみたりとか
使ってないフレームワークだと
これでいいのか
みんなどうしてるんだろうっていう
寄り道だったりとかしちゃったりとか
結局なんか
そこら辺の
理解するために時間をかけるしか
方法ないなっていうのは
僕はやってみて思いましたね
なんかJISMの中でやってると
どうしてもなんかJISMの成果に
コミットするために
一番早い方法で
とりあえずプルリック作りたいなって
思って最初やるんだけど
なんか壁にぶち当たって解決とかをしてるうちに
結局なんか
ちゃんと報道の品質
一定に保ったプルリックを
出すためには結局
そこら辺の周辺知識も含めて
理解しなきゃいけないから
なんか急がば回れではないですが
近道はないんだな
っていうのをなんか
思いましたね
思いますわ確かに
鍋ちゃんって結構フルスタック売りじゃんね
そうだねフルスタック売りだと思う
あんまりそういう苦労とかない?
フルスタックだと
なんだろうね
絶対あるんだけど
あんま覚えてないんだよねっていうのが正直あって
当時のこととかを
どういうことに苦労したかなみたいな
なるほどね
そうなんだよね
苦労したんだけど全然わからんところから
スタートして
でもなんかこうみよみよねで頑張ってやってたら
気が付いたらまあ
そこそこできるようになってたぐらい
なんかわかんないだろうな
頑張ってやってましたっていう感じ
なんかやる順序には
グラデーションがあったの?
最初から全部じゃなくてちょくちょくみたいな
いやでも最初から全部やろうとしてたかな
あそうなんだ
いきなりインフラとか
いきなりフロントとかって感じで
リアクトは確かに
なんでそんなスムーズに入れたのかなって
リアクトとかフロントとか
そんなスムーズに入れたのかなって思ったのは
あれだね
学習サイトやったからかな
あー
結構ちゃんと充実した学習サイト
ありがちだよねリアクト系は
それで入ったから
なるほどね
こういう感じでこういう風にやってんだっていうのが
たぶんスッて入ってきたから
あんまりなんかこう苦労せずに
スッて入れたのは
今思えばあるかもしれない
あーなるほどね
それで言うとねサーバーサイドコトリンはね
情報が少なかった
ない?
たまにだって聞いたことない
使ってる企業とか
そう
21:00
それはあったな
そういう私もユーデミとか使って
入り口めっちゃ初心者からやるみたいなやつを
通ってからじゃないと
今まで通ってから入るみたいなのやってたよ
例えばレイルズはそれなりに
思えば苦労しなかったな
って思った時があって
若干触ってたレイルズに関しては
お遊び程度のものは作れるっていうぐらいの
程度でビジネスに通用する
ものは作れないんだけどたぶん
あとなんか結構レイルズの
学習サイトってプロゲートとか
ユーデミとか情報が
めっちゃあるんよ
レイルズは多いね本当に情報
あと初心者向けの本とか
めっちゃあるんよ
サーバーサイド小鳥ね
なくてね
あんまりその自分が読んでたやつは
初学者向けだったけど
結構その文
なんかこういう分野が
ありますよっていう紹介ぐらいで
例えばテスト作る時は
コテストっていうものを使ってとか
そうかもねなんかそのさ
浅かったんだよねすごい
第2言語としてやる人が多いんじゃないかなと思って
サーバーサイド小鳥とか
第1言語でたぶんJavaとか入ってるのよ
確かに確かに
だから
Javaとかの基本的な部分は
はしょっちゃって
いきなりこう
Javaの
オブジェクト思考の
基本的な話とか
データの取扱いとか
そういう基本的な話とか全部すっ飛ばして
小鳥だったらこうやってやるんだよっていうのが入っちゃうから
あとめちゃくちゃね
フレームワークの話が多かった
はいはいはい
クレイドルとかそういう
いわゆるJavaScriptという
NPMとか
いわゆるNext.jsとか
そういう話とかを浅く
いろいろ網羅的にやってくれる本
私が読んじゃって
はいはいはい
ORマッパーとか
結局
バックエンドを極めて
似たような言語だったら
この言語だったら
どういうフレームワークでやるんだろうとか知れれば
できちゃうからバックエンド
なるほどね
1個やってる人からすると多分
そっちの方が話が早いってなるんだと思う
そういうところを精通するために
あれだったね
別の入り口からやった方が
バックエンドを
もうちょっと小学生がよく通る
道を通ってから
やった方がやりやすかったかもなーって思いつつ
私はコトリン大好きです
すごいそうなんだ
コトリンめちゃくちゃいいなって思いました
コトリン書きやすかった印象
そんなにガッツリやったわけじゃないけど
タイプスクリプト書いてる人はね
コトリン好きないよ
そうなんだ
まず文法充実してて
語とかの思想とは違くて
いわゆる
Javaを
って結構
Javaもバージョン上がってから変わってるって
よく聞くけど
古い情報だと
Javaの
いろんな関数使うときに
24:00
結構長々しい
コードを書かなきゃいけない
観客が書けたりとか
型を
原格だし
そうだね
人によって
コードがあんまり変わらないような
印象はあって
見通しがいい
本当に見通しがいい
確かに見通し
僕最近Pythonちょっと触る機会が
あったんですけど
Pythonとか真逆な気がして
めちゃくちゃ柔軟だから
頭の使い方
全然違うんですよ
変数に値入れると変数の
型勝手に変わってるし
ここから呼び出した
関数呼び出して実行したとしても
中に入ってる値によって
挙動がちょっと違うとか
すごい柔軟で
見方によっては
すごいやりやすいとは思うんですけど
タイプスクリプトとか型を
原格に書くっていうところから
Pythonに入ってくると
なんだこの混沌とした世界は
とか思っちゃう
なかなかつれいぜ
っていうのが最近
あったですね
Python
ってツール系で使うイメージあるけど
Webフレームワークももちろんあるけど
ツールとか
あれも
風景とか再起など
ツールとかそういうところから
広がってきた感じがあって
機械学習のコードとかはちょっと見たんだけど
確かに学習元
データの差異をいい感じに吸収した上で
計算を
関数の挙動として変えるところで
吸収するみたいなところは
確かに
大分のデータ集めてどうのこうのするっていうのでは
すごい便利だなとは思ったんですよね
確かに
あんまり継続的に変えてく
みたいな印象はないんだよな
確かに
実際に使われてる
一度書いたら
運用していかないって感じなの
多少の改善はあるけど
複数に開発するケースっていうのは
あんまないのと
そうなんだ
僕が知っているPythonプロジェクトは
あまり知らないから
Webとかで使って
Djangoとかで開発するところもあるけどもちろん
そういう
そこってあんまないからさ
基本的には機械学習とか
そうだね機械学習
ツール系とか
機械学習とかツール系って
大人数でやるよりかは
小さなチームでとか
小人数でとかってイメージだから
あんまり大規模フレームワークに特化してないのかな
書き方的には
個人用に特化された言語なのかな
っていう気がする
なるほどね
それで機械学習とかで受けが良かったから
そっち系流行ったんですけど
そっちで精通した人が
現れるとやっぱ
人口も増えるとどうしてもその言語で
全てを書きたいねっていう
ニュースが生まれるから
サーバーのライブラリとか
27:00
最近だと名前忘れたけど
WebのJavaScriptの代わりに
Pythonで書くみたいな
何かも生まれたりしていて
なんかJavaScriptとパラレルワールドだな
みたいな感じの
はいはいはい
Webフロントエンドで書いててさ
人が増えた結果
サーバー書きたいってなって
片付けたいって生まれ
アプリ書きたいで
リアクトネイティブやら何やら生まれ
っていう感じで
今の時代だったら
JavaScriptと抽選ツール書けば
どこでも動くものが
JavaScriptのみで完結して書ける
っていう感じだとは思うんですけど
Pythonも始まった視点は
機械学習視点とかで
違うと思うんだが
エコシステムとか
ツールの拡大みたいなところは
すごい似たような
世界観というか
ワールドを感じましたね
ワールド
確かにパラレルワールドっていうの
すげえなんとなく
マジパラレルワールド
言語の人口増えていくとパラレルワールドが複数化して
面白いな
この話はそろそろかな
お便り読まなきゃいけないよ
これ盛り上がっちゃったわ
私もめっちゃ長くしゃべっちゃったしね
ITトリオの日常
ITトリオと言いつつ
技術系の話題がっつりは
珍しいんですが
盛り上がりますね
エンジニアなんて
無限にしゃべっちゃうね
こんな感じで
今回は終わりにしまして
お便りを最後に
読ませていただこうと思います
お便りコーナーです
イェーイ
ITトリオ
お便り読もうと思います
Sさんからいただきました
大文字アルファベットSのSさんです
読み上げます
いつも楽しく拝聴しております
愛知県在住のウェブエンジニアです
愛知
突然マレーシアに行ってしまう
小倉くんさんや
愛する小倉くんを追いかけて
本当に現地に行ってしまうなべちゃんさんや
学生の頃から団体運営に
関わっていらっしゃる知事さんに
なんだかとても刺激を受けています
ありがとうございます
また自分が愛知県在住なので
名古屋にも楽しいエンジニアさんが
いらっしゃって嬉しく思いつつ
もし名古屋で公開収録があれば参加しますので
ぜひご検討いただければ幸いです
他のレスナーさんに
名古屋かよって怒られそうですね
実は知り合いだったら
知り合いでしたみたいな可能性ってあるのか
あるんじゃないの実は
全然なんか結構近い知り合いとかが
いるとかありそうだよね
公開収録しますか
小倉くんが頑張ってこっちまで来てくれたら
頑張っていくわ
お便りまだ最後ありまして
毎回テーマが様々で
お気に入りの番組になっています
今後も配信を楽しみにしております
ということでした
ありがとうございます
ありがとうございます
30:00
めちゃくちゃ嬉しいですね
直接の知り合いじゃないとしても
エンジニアの知り合い
たどれば1人か2人たどれば
実は知り合いって
知り合いの知り合いでしたっていうのありそうですよね
うん
という感じで
Sさんからお便りいただきました
ありがとうございます
めちゃくちゃ嬉しい
ありがとうございます
ということで
こんな感じで番組の感想も
お便り募集していますので
Googleフォームからぜひ送ってください
はいじゃあ今回の放送は
これで終わりにしたいと思います
ちょっと長めになっちゃったんですけど
ありがとうございました
ありがとうございました
ITトリオの日常は番組への
お便りを募集しています
番組の感想や質問など
放送の概要欄にあるリンクから
送ってくれると嬉しいです
またこのポッドキャストは
毎週月曜日に更新しています
番組のフォローやレビューが励みになるので
ぜひお願いします
それではまた来週お会いしましょう
ありがとうございました
ありがとうございました
