00:01
ITトリオの日常は エンジニアとして働く3人が集まって バトターミーティングする番組です
毎週月曜日に更新するこのポッドキャストは 東京のスタートアップでフルスタックエンジニアとして働く小倉くんと
名古屋でエンジニアとして働く元デザイナーチーズと
動画投稿が趣味のフルスタックエンジニアのなべちゃん でお届けしています
今回はですね 11月21日に開催された 技術的負債に向き合うオンラインカンファレンスのスライドが
すごいいいものだったんで それについて話していこうと思います よろしくお願いします
よろしくお願いします
3人参加できてないんですけど 後からXで流れてきたスライド 読んだらすごいいいものだったんで
話したいなと思った感じですね
最初にイベントの説明 参加してないんですけどしておくと
言っていた通り11月21日にオンラインで開催されたものです
テーマが技術的負債に向き合うっていうものですね
これすごいなと思ったのが 参加者がなんとオンライン参加額で1800人もいるっていう
すごいね
すごいな
正直参加してないけど知ってた イベントは
そうなんだ
それくらい有名ってことですよね
平日だもんね 平日の12時から19時なんで
参加したくても業務的に参加できないっていう人も多かったのかもしれないんですけど
とにかく申し込んだ人がめちゃくちゃ多くて
そのおかげかXでもすごい技術的負債がトレンドになっていたような気もして
結構話題になってたやつですね
結構スライドいろいろ見て学びが多いものたくさんあったんですけど
今回はその中の一つの株式会社ヘンリーVPOオブエンジニアリングの孫無さんの
何が技術的負債に変わるのかっていうスライドを元に話していきたいなって感じですね
今回もいつもの通りこの触れるスライドのリンクを放送の概要欄に貼ってあるんで
ぜひ読んでない人は目を通して見ていただければと思いますって感じです
ということで話していこうと思うんですけど
どうですか読んでみた感想は
共感の嵐
おー共感の嵐
月並みな表現だけど
確かにね
なんか結構さこのスライドが何て言うんだろう
この方が孫無さんが結構リードエンジニアとかCTOとかVPOオブエンジニアリングとかいろいろやっているから
結構その組織とか開発組織エンジニア全体を見た上での経験が結構反映された上の言語化かなと思って
結構技術的負債がそもそも何なのかとか何で生まれるのかとか
どういうふうにハンドリングするのが結果バランスよく落ち着くのかっていうのが
すごい現実味のある形ですごい分かりやすく説明されていて
03:00
すごい技術的負債ってただ言葉に出すだけじゃなくて
ちゃんとそれをどのようにハンドリングすべきかってことについて
すごい解像度が上がるいい資料だなーって僕はちょっと思いましたね
なんか思ったのは特に事業会社いわゆるビジネスに結構近しいエンジニアの方が共感値高いかなと思ってて
ここにいる3人は確かに歴史あるビジネス歴史ないビジネスあるかもしれへんけど
そういう編成をたどってきたサービスを開発する会社で自社会社として働いてきているエンジニアが多いから
より共感値が高かったかなっていうふうには感じた
確かに確かにそうかもな単純にこうちょっと保守してくださいとかだとここまで考えないしな確かに
まあどんなサービスでもねあるとは思うけど確かに代償はあるかもね
なんか多分どんなサービスどんなプロダクトにも技術的不採として扱われるものはあるんだろうけど
なんかそれを解決しようとするかしないかは確かになんかただ保守してくださいという立場だと
別にそれを解決積極的にしようみたいな考えにはならないし
そこまでする責任もねえもんなっていう感じですかね
たしかにたしかに
小倉くんが一番いろんなケースに今の人生において当たってるのかなとは思うんだけどさ
働き方とかも全然違ったり
なんかそれで言うとあれかな
他のこの方以外のスライドでも目を通したんですけど
結構このスライドは中規模大規模の開発組織で働く中で
技術的不採にちょっと苦しんだ経験があるみたいな人に特に響くのかなと思って
逆にスタートアップで技術的不採と向き合うみたいな人には
他のなんかもっとスタートアップにフォーカスを当てた発表とかスライドとかあったりしたので
そっちの方が響くのかなっていう感じではありましたね
なんかそうですね
僕なんかこのスライドで触れている技術的不採とは何が技術的不採に変わるのか
技術的不採に向き合ういくつかのヒントで積極的バージョンアップの進めみたいな感じで言われている中で
僕がなんか一番思ったのはスライドの17ページぐらいにある
技術的不採に向き合えるのは幸せっていうところがすごい心に来たというか
ワードがね
そうワードがエモいし日々の業務の中でそういう技術的不採返却のために頑張るみたいなことをやっていると
この気持ちついつい忘れがちだなと思ってちょっと心を改めたというか
ちょっと響くものがありましたね
なんかこの言葉の意味は前のスライドとも含めると
なんかそもそも技術的不採っていうのは何らかの技術的な借り入れで
06:05
そのプロダクトとか新しい機能を開発するときに短期的に見て
早くリリースするために一時的に最適じゃないコードを書いた上でプロダクトをリリースするみたいなことなんですけど
なんかそもそもじゃあそうやって作った不採を後から向き合って解決しましょうってなるためには
やっぱプロダクトがうまくいっていったりとか
会社の経営状況がちゃんと安定して黒字化とか黒字化はしなくてもいいかもしれないんだけど
ちゃんと会社が1年2年残る前提っていうのがないと
そもそも技術的不採を返却しましょうっていう段階にはなりませんよねっていうことを言ってるんだと思って
だからその向き合う前に多くのプロダクトが消えちゃうし多くの会社潰れてしまうし
だから向き合えるステージに到達できたっていうのは事業的に見て会社的に見てすごい幸せなことですよねっていう意味だと思うんですけど
いやほんとそうだよなみたいな
確かにね
僕は最近スタートアップ系の会社で働くことが多かったんですけど
まあなんかそうっすよね
スタートアップね厳しくなるよね経営ねとか
いろいろ見て思ったりしたんで
そこを乗り越えてちゃんと向き合えるところに達せれたっていうのは
そんなになんかその経営とかに目を向けていなければ幸せって感じることはないのかもしれないけど
そういうところに目を向けると結構感じ方変わってくるよなっていう
なんかシンプルに不災に目を向けられるのって
サービスが健康状態が良い不災は溜まってるかもしれないけど
病気で居続けることもできるじゃないですか正直言うと
追加機能をどんどん追加していきたいみたいなスタンスのサービスだって絶対あると思ってて
ただそこで一旦今ここでちゃんと不災を解消していかないと
そのサービスの中長期的に見て継続できないっていうところがにちゃんと気づけてる
いわゆる自分の定期検診でちゃんと異常を検知できてる状態だと思ってて
気づかないパターンもあるかなと思うから
それにちゃんと気づいて向き合えるのって素晴らしいし
たとえ気づいていてもなかなか向き合える時間を取らせてもらえない会社とか
工数が足りなくてできない会社とかも多いから
そういう機会があったらありがたみを感じようって思いましたね私も
ちゃんと向き合えてるって
大事だと思うな本当それ
不災会社ってめっちゃ辛くなることが多いから
自分でこうこうとかあえてて
ブレイムとかしちゃうとかもあるじゃんこれ誰がやったねんとかって
09:01
ないかな俺だけかな
確かにこれどこで生まれたんだろうみたいな
どこのプールリックからこれが来るんだろう
このプールリックだみたいなコメント
あーコメントもあーみたいな
確かにないとは言えない
攻めたりはしないんだけどもちろん
ここで攻めたりはしないんだけど
ちょっと昔やってたんだなちょっと聞いてみようかな話とか
そういうのでやるんだけど聞いてみたら
覚えてないとかってのは大変でそうで
当時のなんでこの機能実装したんだろうって調べようとしても
issueとかに全然何も書いてなくて
なんでこの機能いるんだろうなとかって
今この機能たぶん使われてないんじゃね必要ないんじゃねとかって思ったりするけど
でも書いてもわからないから消してもいいのかそれわからないとか
あるあるですね
それを今の人たちにビジネスの人たちに構えて
この機能使ってますかどうですかねって言っても
わかんないですとかってなって
え何も書いてないどうしようみたいな
これ消せるんかなみたいな
消してもいいよなとか
油断リクエストそんなないしみたいな
でも消したら消したらどっかで不具合が
実は起きたりするとかもあるかもしれないしみたいな
結構そういう辛いことがたくさんあって再開所してると
そういうのをやれるぐらい成長したんだなこの子はって思ってやったら
確かにちょっと可愛く見えるかも楽しく見えるかもなって
確かに確かに成長した証だもんね
なんかスライドでもさ何が技術的不細に変わるのかっていう機関
機関じゃないやセクションがあって
そこで挙げられているのが何個だ4つ
なんか自分たちの技術的成長自分たちの事業成長
ビジネスの変化技術の変遷ってのがあるんだけど
今の話は自分たちの事業成長に当てはまるのかなと思って
最初作った時は別に不細とはなってなかったんだけど
プロダクターが大きくなって高度が増えて
ユーザーも増えてくるにつれそれが後から不細になっていった
それは確かに不細になるだけの成長ができたっていうことでもあるから
確かにな私さちょうどさ今そういう時に言ってさ
明日からアーキテクチャーを再興するっていう業務が待っているんですよ
マジ明日からなんだ結構すごいなそれ
タイムリーに明日からでそれがなぜ必要になったかっていうのは
この新しい機能新しいユーザーに届けたい機能を実装する上で
今のアーキテクチャーが耐えられなくなったから
その機能がビジネスインパクトとしても大きいからっていうところ
確かにそれができることってサービスの成長だなと思ってて
事業が成長してそれに投資ができるって判断したから
そういう利益できる時間が取れてるんだなって思ったら
正直明日からの仕事がなんかちょっと重いしな
重いし大変だなって思ってたけど
今これができることに対して幸せを感じなきゃなって思えたわ今
12:06
ちょうど今事業成長してんだなって思えたわ
しかもその理由がまさにクリティカルだった
具体的に言うとレイヤードアーキテクチャーのレイヤーが足りなくなってしまったっていうので
今までの小さめの機能を開発する上では今のレイヤーで全然耐えられていたんだけど
もう少し大きなサービスというか価値を提供するには今のレイヤーだったら足りないよねとか
もう少し見直すべき部分が細部にあったりとか追加回収ができなくなったりとかっていう状況になって
今まで最適はずっと尽くしてきたつもりないよ
自分たちの行動が悪かったというかその場その場で最適なアーキテクチャーを選定していったと自負してるんだけど
それに耐えられなくなった事業の成長って思うと夫妻が可愛い
やっとわかった今まで自分たちが書いたものはダメだったとかではないんだなっていうので
ダメじゃなかったしさ多分その大きくなる前だったら多分それが一番の最適だったっていうこと
最適だったと思ってる
それを忘れてたその気持ち忘れてた
なんかさそれ結構さ転職したりとか新しいコードベース触り始めた時に落ち入りやすいマイナス感情かなと思って
それまでの経緯とかを知らない今まで生み出していた価値を知らないから今その場のコードと今その場の状況だけを見て
いやこのコードちょっとやばいね
あるある
思い出したと思うんだけど本当は事業的に見たらそれまでちゃんと価値を生み出してきたっていうものが多い
そうじゃないものも多分あるとは思うんですけど
まあきっと価値を生み出してきたものだし
その昔のその時点では一番最適だったものっていうのも多々あると思うから
そういうところも含めて考えれたら嬉しい嬉しいというか心穏やかというかいいなって感じ
そう思うとコードってなんか生きてる感じするね生命宿ってるよね
私だけそう感じたの
うーん
じゃあこれちょっとこれないことにしといて
ある意味でも思想とかは入ってるから多分コードってきっと
なんかそのコードを通じてこう誰かの思惑とか思想とかなんか考えとか
全部一緒かな分かんないけど
なんかそういうのが多分感じ取れてそれを命として認識できなくもないかもしれないねもしかしたら
ITトリオ
若干話は揃えるかもなんですけど
なんか生物学で有名な生物学者の人で
15:02
福岡新一さんという方がいるんですけど
ほう
その方が動的平衡っていう言葉を言っていてですね
ちょっと待ってこれ読み方あってるのかな
動的?
平衡
平衡
そう動的平衡
変えまない中で流れの中で一種のバランスが取れた状態
なんか聞いたことあるな
これなんかもしかしたらボットキャストに言ったことあるのかも
なんかねうん
私オクラ君の口から聞いたことある
聞いたかもない気がするわ
なんか改めて説明しておくと結構その
これ結構その福岡さんがその生物を見た
見たとき研究した中で
出会ったというか生み出した生命感なんですけど
いろんな生物って結構安定を保っているように一見見えるじゃないですか
なんか僕たちもそうじゃないですか
このチーズ鍋ちゃんオクラ君も今まで生まれてから
今この瞬間の27,8,9年間
鍋ちゃんチーズオクラ君としてちゃんと安定して保ってきたから
今ここで3人集って喋ってると思うんですけど
それはその生物のなんか中身を見てみると
本当はすべてが安定してっていうよりかは
部分部分でいろんな分子が入れ替わりながら
今ここまでやってきたみたいな
そうだから例えば人間の体の血液
人間の体の細胞とかってなんか
ちょっと細かい数字忘れましたけど
なんか2ヶ月とか半年ぐらいで全部入れ替わるみたいな
そうらしいんですけど
それもなんかずっと同じ細胞を使い続けるんじゃなくて
自分からあえて古いものを捨てて新しいものを生み出すっていうことによって
全体としては一つの生命を保っているみたいな
やっぱ生きてるやん行動
それは確かに行動には動的並行が当てはまるのかもなみたいな
生命宿してるじゃん
部分部分でいつも動いてはいるんだけど
全体としては一つの形をちゃんと保っている
コードの中でも新しいコードが投入されたりとか
同じ機能でもその中のコードが一部捨て去られて
新しいコードでリファクタリングがしたりとか
部分部分で見ると絶え間なくいつも動いているんだけど
全体として見たプロダクトとしてはちゃんと一つの形を保っていて
ちゃんと動いているっていうのはそれこそ動的並行なのかな
なんかウナギのタレ的な話それって
違うか
いやウナギのタレもさ
ヒレのタレもさ
継ぎ足し継ぎ足ししていくじゃん
継ぎ足し
確かに
ウナギのタレだとさ
継ぎ足されて残ってるからさ
それは動的並行ではないの?
違うかな
どうなんだろう
なんか違う気がする
違うか
ごめんなさいちょっとこれはボケたかもしれない
はい
ボケなんで気にしないでください
だからそういう動的並行っていうその
放っておくと崩壊するから崩壊する前に自分から
分解して新しいものを生み出して全体の並行を保つっていうのは確かに
18:03
コードにも当てはまるのかなみたいな
これあれだね
もし次移植的再カンファレンスがあったら勝手にこの
プログなんだろう
プロダクトのコードと動的並行みたいなテーマでちょっと話したら
おーってなるのかもしれない
すごいね
生物学とひわづけて語ってくるのね
全然生物学で専門の人じゃないけど
すごい
コードは生命である
なんかスピリチュアルになるねすごい
動的並行とはみたいな
大丈夫かな
ちょっとな
他なんてなっちゃったかもしれないな
追いつけるかな
で他に話したいことがあってさ
あーはいはい
自分が別のところでちょっと共感というか
もうこれ本当になって思うところとしては
ヤグニの原則っていうのを紹介したんだけど
YAG
有名ね
機能必要になるまで追加するなっていうやつだけど
やらなくてもいいことはやらないようにした方がいいです
将来的にこういうことの可能性があるから
先にこういうの実装しておこうとか
消費税
このスライドの消費税がない時代に
消費税をケアして
想定して特定の変数ができるように
ちょっとパラメータ変えられるようにしとこうか
とかっていうの多分
そういうのもあると思うんだけど
そういうのを事例として言ってるんだけど
なんかこれねすげー共感するんだよね
実際の授業とかでも
僕は最近だとMVCって言ってさ
最小機能で
なんていうんだ
MVPだよね
MVCでモデル
ミニマルバリュー
MVPって言った今は
MVTに聞こえた
MVCって言った最初
Tに聞こえたからモデル
MVP
顧客のニーズを満たす最小限のプロダクト
そういうのもあってさ
自分はその考えすごい大事だなと思うんだけど
実際その授業として
新しく新規授業とかやりましょうとかになった時に
運用としてこういう機能も必要になるよねとか
将来的にちょっとこう
なんていうのかな
たぶん授業がスキルしてくると
手動でちょっと厳しいから
先にこういうとこも自動化して機能として作っておこうとか
そういう話とかいろいろ出てくるんだけど
それは必要な時に作ればよくねって
最初にそこのスコープに入れるべきじゃないのかなって
僕はすごい思ってて
売上を発生するために
最小限必要なものっていうのを作って
それを作ってテストマーケティングして
それでなんかいける見込みが立ったら
テストマーケティングが終わりました
じゃあ本格的にこういうの必要な人だと
運用として作っていこうとかっていうのだったら
めっちゃありだなって思うんだけど
そういうのを考えずに
いきなり完成された製品を求められて
その完成された製品を作るスキルを立てて
21:01
やっていくっていうので
でもそれって不確実性が高いし
実際に作った時に
やっぱりイニシャルの開発期間ってすごく長くなるし
いざ出してみたらうまくいきませんでしたとか
思ったりも伸びなかったりするとか
全然あるわけだし
やっぱりそういうのって
僕はなんか結構
今まで無駄だったなとか
ちょっともったいなかったんじゃないとかって
思うことがすごい体感としてあって
それでなんかその
こういう
技術的塞いにしないために
最初からやっぱりその
後々動向っていうのももちろん大事なんだけど
一定のここまでにしとこうっていう
判断もやっぱ必要なのかなってすごいね
ここは僕は共感したポイントでした
ビジネスもコードもね
机上の空論になりがちだからね
そうそう
ある程度今見えてるものに対してね
アプローチしなきゃいけないし
やぐによく言うのはさ
コードレビューの指針として定めるとか
結構多いよね
このコードって何ですか
やぐにじゃないですかっていうのを
いつでも言えるように準備しておくとか
なるほどね
なんかそういう指針を定めてるところも
よく聞くなって
まあ私はやってないんですけど
今めっちゃやってる風にさ
喋ってるけど
私はやってないんだけど
そういう指針を定めているところとかも
多いなっていうイメージはあって
なんかそこら辺ってなんか
やっぱチーム内での感覚を揃えることって
すごい大事だなって思ってて
めっちゃ思うわそれ
確かにそれ大事だわ
ただ一人がこの指針を定めていた
知ってたけど
ビジネスの方針が違ったりとか
なんかそこの共通認識が取れてなかったら
みんなの思うように
コードがやぐにならないとか
全然あると思うんだよね
しかもそのやぐにを
なんかどのスパンで持って
やぐにとして見るかみたいなのも
結構チームの共通認識作った上じゃないと
なかなかメンバー間で
共通認識作れないのかなと思って
例えばなんか
やぐにですねって言って
フロントエンドとかだと
コンポネントぐちゃぐちゃな形で
むしろコンポネントを分割せずに
一つの画面を一つのコンポネントで
何千行ものコードを書いて
はい動きますからいいですよね
っていうのに対して
やぐには言わないだろうなっていうのは
誰でも思うとは思うんですけど
もうちょっとそれが細かいレールになってくると
とはいえ
こういうケースはすぐに起きがちだし
一般的に起きがちなので
認識しておいた方が良くないですかみたいな
っていう
どの程度将来に備えるかっていうのは
結構プロダクトとかチームが
どういう風に考えるかによって変わってくるから
やっぱそこの
共通認識をなるべく作らないと
レビューの時とかで
衝突が起きたり
あったが確かに実際に
すっげー納得してる
あったあった
自分としては
将来的にこういうことも必要になるかもなっていう
頭はもちろんあるんだけど
でも必要にならない可能性も高いしな
24:01
ちょっと迷うな
じゃあやめとくかって言って
実装しなかった機能がとか
実装しなかった
コードの
書き方とかをした時に
実際に出席されて
で
自分としてこういう風に思ってて
っていう話して
衝突までいかないけど話し合って
直接話してとかは結構あって
確かにその感覚を擦り合わせとくって
すごい大事なんだろうなって
なんか一番いいアーキテクチャは
誰が書いても同じコードになること
だからそこの認識とかも
誰が書いたとしても
同じアウトプットができるのが
一番の理想だから
機能面でも
コード面でも
ちゃんと擦り合わされてる状態が
理想だし
それがちゃんと定義して
みんなが分かって
分かる
その後入った人でも分かる
っていうのは大事だよね
確かに確かに
なんか長く秘伝のタレがあるコードって
誰かがいなくなると
誰も分からないコードって
生まれがちだと思うんだけど
そういうものがなくなるように
デザインドックであったりとか
工夫とかも必要だし
それもなんだろう
やっぱり生きているコードのために
必要なパーツのうちの一つだと思うんだよね
そうね
なんかさ
1個あったのが面白いので
外中の人がいて
外中の人に
管理画面でこういうの作ってくださいって
言ったときに
管理画面として欲しかったのは
単純に表としてデータを出せるようにしてほしい
とかそういうぐらいの機能だったんだけど
この人が
ちょっとグラフあったら見やすいと思うんで
グラフの機能とかも作って
実装しましたとかって
グラフ使うのにあたって
ライブラリとかこういうのを入れてますとか
いろいろあったりして
それやっちゃうと
グラフの管理とかもコストとかも
やっぱ大変なわけよ
いろんなライブラリが既存してて
ライブラリに選定する
そういうのもあるから
言ってもないけど
やってくれたときがあって
その人はやっぱり
いいと思ってやってくれてると思うんだけど
将来的なことがあると
ライブラリの話もあるし
いろいろギリギリ積み重ねる可能性が
高いっていうのもあって
そうね
やらなくても
やったほうが
一見その場ではよく見えるんだけど
やっぱり将来的なことも
やらないほうがいいんじゃないかとか
そもそもそういう機能
求められてないしとか
そういうことがちょっと面白かった
確かにね
視野が違うからね
人それぞれ
難しさあるね
事業ドメインへの理解度が
ちゃんと高くないと
技術的不才の
上手なハンドリングっていうのも
難しいのかな
そうね
すごい思う
本当にね
そうなんだよね
そうね
技術の話だから
エンジニアとか開発組織なんて
柑橘するかと思いきや
そういうわけではないっていう
そうそうそうそう
27:00
だから多分いろんなところで
エンジニア同士もそうだし
その外の組織とか
外のチームに対しても
これをテーマに
多分衝突が生まれて
これを解決する時間が
欲しいんですけど
っていう
エンジニアたちは言ってるけど
経営層的には
そんなことやるくらいだったら
新しい機能を開発してください
そんな時間はありませんみたいな
とか
ガチなのかな
とか思ったりするから結構
そうだね
やっぱ1800人も集まるから
やっぱ難しい
テーマなんですよね
っていう
確かに確かに
そんだけ悩んでる人いるからね
みんな悩んでるんだよ
でもない会社ないから
ね
そうね
技術的不才はね
確かに
やっぱ個人的には
なんかやっぱ経営層に近い人たちが
この辺りを
うまくハンドリングすることの
なんか重要性を理解している
開発組織で働きたいな
とか思っちゃうね
なんか
それはすごく思うよ
上の人が分かってないから
現場の人から
ちゃんとCを作って説明して
上の人を納得させるところから
始めようみたいなのは
うーん
まぁなんか
うーん
まぁやらなきゃいけなそうなのは
分かるんだけど
それやるくらいだったら
もうなんか
働く場所を変えて
もうちょっとエンジニアとして
なんか恵まれそうな環境に
行っちゃいたいなっていう
まぁ分かる
まぁ確かに
まぁそのサービスのあり方によってね
全然そこのバランス感とか
向き合い方とか
全然違うから
そうね
なんか組織って
すごい密着してるなっていうのは
すごい思う
うーん
この技術的不細って言葉と
組織っていうところは
そうだね
なんか
今回はメインで話さなかったんだけど
このイベントの中で
よく拡散されたスライドのうちの一つが
結構その組織設計と
技術的不細の関係みたいなことに
フォーカスを当てて話していたこと
ものもあって
うーん
やっぱそのなんか
組織設計そのものが原因で
技術的不細が生まれちゃってるみたいなのも
なんか
よくあるかなっていう
うーん
印象なので
あると思うあると思う
めっちゃ影響でかいと思うそこ
そうだよね
なんか時間を使えないとか
開発を担当するチームの構成とか
チームのメンバーがコロコロ変わるとか
逆にいろんな人が全ての行動されるから
ぐちゃぐちゃになるとか
いろいろあると思うんですけど
うーん
いやーそうよね
うーん難しい
うーん
あとね
もう一個だけ話したいことあったんだけど
またにしようかな
別の機会とかで
これは続編をやる
やりますか
そんな技術的不細は
いつの時代も
多分人を困らせる
そうだよね
なんかAIがさ
話しちゃうけど
AIがエンジニアの仕事奪うぞーっていうのをさ
エンジニアじゃない人が
よく言っている気がするんですけど
いやそれで生み出された
コードの中身誰が保守するんだろうとか
うーん
いうのを考えると
なんかまだまだ
エンジニアの仕事ゼロにはならないんだろうなー
30:00
とか思ったり
うちらが生きてる間大丈夫でしょ
そういう気がする
そう思うそう思う
アップデートとかどうやってやるのかなって思うもんね
新しいコードがどんどんどんどん追加されていく
新しい技術とかが
それを
都度都度さ
AIが学習するのを待ってるわけにもいかんと思ってて
仮になんか一瞬で学習できたとしても
その中でどうバランス取りたいかも
多分授業の場面によって
全然違ってくるから
多分それを考え抜くのはね
結局やる側の人間っていう
なんだろうなー
そう
これも広がりそうなのでそろそろそろそろ
そうですねすいません
それは別のテーマで急を投げましょう
そうね
技術的不採はまた今度いろいろ話しましょう
はい
はいじゃあということで今回はあれですね
技術的不採のハンドリングって難しいですね
ってかもっすね
つまりツラタニエ
はいツラタニエ
まあでも頑張っていきましょう
はい
はい
じゃあそういうことで今回は終わりにしたいと思います
ありがとうございました
ありがとうございました
言えてないやん
ITトリオの日常は番組へのお便りを募集しています
番組の感想や質問など
放送の概要欄にあるリンクから送ってくれると嬉しいです
またこのポッドキャストは毎週月曜日に更新しています
番組のフォローやレビューが励みになるので
ぜひお願いします
それではまた来週お会いしましょう
ありがとうございました
ありがとうございました
