00:00
ちょっと今回はですね、フレームワークを使うな、みたいな過激派なことを、なんかどっかで言ってるのを聞いた気がしたんですけど、
ちょっとこの過激派すぎてめちゃくちゃ面白いので、今日この話していけたらなと思うんですけど、なんでこんな思想が出てきたんですかね。
えっとですね、私はちょっといろいろ過去にいろんな経験があって、今はフレームワークを使うときって、ビジネスの成功っていう観点で80点以上目指さないっていう決断であると私は思っているんですね。
なので100点を目指したいんだったら使わない方がいいと思っているっていう趣旨でした。
ただ何がフレームワークで何がフレームワークじゃないかっていうのは整理してからじゃないと、多分話がまとまらないと思うんで、整理してからちょっと本題に入っていきましょう。
そうですね。とりあえず今の主張としては80点以上、ビジネス観点での成功で80点以上を目指さないというような決断をフレームワークを使ってる時点でしてるんじゃないかというような過激派意見っていう感じですね。
じゃあまずはフレームワークの定義ですね。どこからどこまでがフレームワークって具体的な例とかあったらわかりやすいんですけど。
そうですね。まずはその具体的な例の前にちょっと定義を話していこうと思います。
私がここで言及しているフレームワークというのは、部品を足すの規格を決める側をフレームワークと言っています。
例えばレイルズとかであるとコントローラーとかモデルとかいろんなものがあると思うんですけど、これの規格を決めてるっていうのがレイルズでやってることですよね。
だから例えばここに何かこういうふうなミドルウェア追加したいとかっていうふうなそのミドルウェアの規格も決めてますから、ミドルウェアっていうのを入れたいってやるとそのレイルズ用のミドルウェアを探してきて入れるとガチャッとはまってその機能が実現できる。
こういうふうなその規格を決めるもの、これが私はフレームワークだと思っています。
ルールを定義しているものってことですね。
ちょっとここは少し押さえておきたいのはフレームワークっぽいけどあるところから見るとライブラリーっぽいものみたいなものがあります。
例えばリアクトってあるじゃないですか。リアクトってビューソーの入れ替えとかリアクトを使わなくても別にDOMとかいろいろ書いたりするっていうことができるっていう意味ですごくアプリケーション全体としてはリアクトはライブラリー的に見えるんですよね。
部品の規格は決めてないと。なんだけどひとたびUIの中に入ってみるとJSXとか使ってコンポーネントを定義していくわけですけど
そのコンポーネントのやり方とかユーズステートとかユーズエフェクトとかああいうふうなやつっていうのは全部リアクトの規格で決まっているっていう意味で
ビューソーからはフレームワークとして見える。そういうものもあります。
なのでフレームワークってあくまでその規格をどれぐらい決めてくるかっていうその強さによってフレームワークの大きさっていうか強さっていうのが決まってくるんですけど
そのフレームワークが強ければ強くほど私はビジネスの成功という観点で成功を目指しにくくなると思っているってことなんですね。
思想が強いというよりかフレームワークが規定しているルールがどれだけ強制されるかどうかっていうのが非常に重要ってことですかね。
03:00
そうですね。強制されるのが重要っていうのもありますね。
なんでこういうふうな思想に至ったかというとですね、過去いろいろフレームワークとかを使って私も開発をしてきたんですけど
なんかバニラだったらちょっとした工夫でできちゃうことがフレームワークに乗せようと思った途端に難しくなるってことをよく経験してきたんですね。
つまりこれ私が何が起こってたかっていうとある実現したいことがある。
フレームワークの部品をはめることでそれを実現したいんだがフレームワークの部品を経由すると壮大な行動が必要になってしまう。
そういうふうな経験をたくさんしてきました。
そうすると当然ビジネス的には早く機能とかを出したいっていうわけなのに
そのフレームワークの型にはめるためだけにいろいろな苦労をしなきゃいけなくなっている。
本質的じゃない苦労をしているってことになりますね。
なのでそういう経験が本当にたくさんあったんですよ。
そしてもう一発きたのがフレームワークのアップデートですね。
フレームワークって例日もそうですけどアップデートが結構定期的にきますよね。
その度に私たちは部品の規格がちょっとずつ変わっていってしまうので
それに対する対応をしていかなきゃいけなくなっています。
なのでこれをする自分がちゃんとアップデートの恩恵を受けてるんだったらわかるんですよ。
これによってすごく便利になったなっていうものばっかりだったら
アップデートについていくことがもしかしたら意味があるのかもしれないけど
大抵はそうじゃないことが多いですね。
例えば私じゃない誰か他のフレームワークの利用者がこうしたいって言ってるのが取り入れられた。
だから部品の規格がちょっと変わった。
なんかわかんないけど変えなきゃいけなくなったみたいな。
それが私はビジネスの速度を促すと思っているんですね。
アップデートに通じるためにいろいろやらないといけない。
本質的な作業じゃないところがどんどん挟まってくるっていうところが
本質的な嫌なところなんですかね。
そうですね。
だから例えばバージョンが上がるごとに関数のシグネチャが変わるとか追加されるとか
あとはその意味が変わってこういう時はこういうふうなことを書いてると壊れるようになりますとか
それに対応を迫られるわけじゃないですか。
それが必要なことだったらいいんですよ本当に。
だけど私が経験してきた中では必要じゃないことが圧倒的に多かったんですね。
なのでこれは何のために私はアップデートっていう時間を払っているんだろう。
誰のためにそれを払っているんだろうってことを考えると
フレームワークを使うって決断をした人のために払ってる感じがしてきてしまったんですよね。
なるほど。
そういった点で100点目指すためには必要ないっていうような思想になっていったっていうところですね。
ただそれを直ちにフレームワークを使う意味ではなくて
フレームワークの良いところは良くも悪くも60点から80点の間に収まりやすいっていうのがあると思っています。
自分でフレームワークなしで1から作っていくってことは全然できるんですけど
これは40点とか30点とかになることもあり得る。
経験がない人が作ればそうなってしまいますね。
なのでそういう意味では底上げはしてくれてるんですけど
100点まではあまり届かないと思っているという感じです。
06:02
これが私のフレームワークを100点取りたいときには使わない方がいいって言ってることの真意ですね。
スペーカー力使うなって言ってるわけではない。
そういうことです。
要所要所で使うべきだし、使わないタイミングもあるよねっていう。
エンジニアがジュニアばっかりだったりするときには
ちゃんとクラス切れるかしら、分割できるかしらっていうことが不安だったりするときには
フレームワークである程度強制的に分け方を決めてもらうっていうことは
開発速度をきっと上げるだろうと思うんですよ。
なのでそういう時とかにはフレームワークはきっと役に立つと思うんですけど
逆にシニアの人たちが集まっていて
どのフレームワーク使うかみたいな話してるのを聞くと
いやあなたたちフレームワーク使わなくて書けるでしょって思ってるわけです。
なるほど。
タイミングにもよるんですかね、ビジネスの。
0から1のタイミングと1から10、10から100のタイミング
全然違うかなと思うんですけど。
もちろんその通りだと思いますね。
0から1のタイミングでは使うべき時と使わざるべき、両方ともあると思いますね。
0から1の時って圧倒的に高速に作って高速に捨てたいっていうのがあると思うんですよ。
そういう時にフレームワークを使うことで既存のコードを上手く使って
部品を組み合わせるだけで上手く実現できるんだったら
それをやればいいと思います。
ただ現実的にはそれ難しいと思うんですよ。
だって何でかっていうとフレームワークで簡単に作れちゃうんだったらみんな作ってるじゃないですか。
はい。
だから私はそれ実はちょっと難しいかなと思っていて
ただもしあなたのアイデアがフレームワークの部品の組み合わせで簡単に実現できるんだったら
それは迷うことなくフレームワークを使って
あっという間にコードを組み立ててそして捨てていくべきだと思っています。
ちゃんと技術選定をしましょうっていう話ですかね。
ここに関しては。
楽にしてとりあえずRails使っておけばいいでしょみたいな話ではなくてっていうところ。
そういうことです。
ちゃんと選んでやっていきましょうっていうところですね。
やりたいことに合わせて。
そうですね。
じゃああとはちょっと疑問なのが
大体の現場において現実において何らかフレームワークを使っている
ReactもしかりRailsもしかり使ってるかなと思うんですけど
大体においてその付けを技術的に塞いで言われるのかもしれないんですけど
あるレイヤーによっては
それを解消していかないといけないのはゼロから一応やった人ではなくて
その後入ってきた人だったりするわけじゃないですか。
その中からどんどんフレームワークを剥がしてきたりだったりとか
どんどんメンバーも成長してきたし
っていう面でどうやっていくのかっていうのは結構難しいところですよね。
ここに関しては。
そうですね。
今は昔と比べればAIが出てきたんで書き換えコストって劇的に減ったと思うんで
やりやすくなってきてると思います。
昔はできないって言ってたのがほとんどだったと思います。
なのでその点は最初にフレームワークを選びやすい時代になってきたんだな
とは思っていますね。
09:01
なんでフレームワークからふたつフレームワークするのが難しいかというと
自分たちが企画に合わせて部品を作っちゃったからなんですよね。
その企画に合った部品が自分たちだけの財産になっていて
それをその財産をうまく活用して
ウェブアプリケーションを作り直してくださいって言われたら
企画使った方が早いじゃんってなって
ウェブフレームワークから離れられなくなるんですよ。
当たり前ですよね。
そうですね。
なので私はフレームワークはなるべく使いたくなくて
本当だったらライブラリーをうまく使って
つまり自分たちが企画を決めるんだっていう主導権を握って
インターフェースとかっていうのを調整していきたいっていう風に思っていますね。
なるほど。
すごい雑な説明をするとあれですかね
レゴブロックの企画に沿った形でレゴを作ってきているから
各関数を作ってきているから
レゴ以外くっつけられないよねっていう感じだけで
他のフレームワークでも
フレームワーク使わなくてもどっちでもいいんですけど
移行可能なように作っておけばよかったよねっていうところですよね。
ただフレームワークを使う以上
その部品の中で生きていくしかできないんですよ。
だからその部品にどうしてもその部品のサブセットしかできないんですよ。
つまり部品にはまるように作らなきゃいけないわけですから
だからもしそこで工夫できるとしても
その企画をこれは使わないとか
これは使うみたいな感じの
サブセットを選ぶっていうことしかできないんですよね。
それは相当厳しいゲームだと私は思っています。
なるほど。
使うって選んだ時点で厳しい戦いにはなっているかもしれないところですね。
あとちょっと気になったのが
フレームワークとライブラリの使い分けみたいな
例えばリアクトの中の一部のライブラリを使いたいだったりとか
あとはさっき話の中で出てきた
バニラであればできたのにみたいなところもそうなんですけど
何がバニラとすべきかみたいなところも結構気になっているところで
それは標準化されているからバニラなのかとか
そういったところってあったりしますか?
何がフレームワークとライブラリの境目があって
そのライブラリとバニラの境目もあるのかなと思うんですけど
そうですね。
先ほどフレームワークは提起しましたけど
ライブラリは提起していなかったのでライブラリをまず提起しましょう。
ライブラリは逆に部品側です。
つまりフレームワークにとっては我々はライブラリを作っている側になるわけですね。
なるほど。
そのライブラリっていうのはいろんな規格のものがあるわけで
一番いい規格のものっていうのは
その言語での関数呼び出しだけが必要となっているケースです。
例えばアップルーターみたいなところに差し込まなくていいみたいなことですね。
12:01
つまり呼ぶだけでいいみたいな。
これが一番ライブラリとしては一番ゆるい規格になっている。
関数呼び出しだけでいい?
関数呼び出しだけ。
引数とかにも全然制限がかかっていなくて呼んでくれりゃいい仕事して返すよと。
こういうものがライブラリだと私は思っています。
なのでライブラリを自分たちで決めるっていうことは
好きなようにネジを入れて首立てていくことができるっていうことなんですよね。
なるほど。
対してフレームワークっていうのはハマる場所がもう決まってるんですよね。
カセットをはめる場所が決まってるんで
なので私昔はよくこのカセットに別のコンポーネントを
ライブラリを埋め込んでアダプターを作るみたいなことをよくやってたんですけど
そういうふうにインターフェースを調整してあげて使えるように
いいライブラリはだいたいそういうふうにインターフェースを調整しても使えることが多いんで
これはフレームワーク用のやつにこのライブラリのやつを詰め込んだっていうのを
例えばホゲフレームワークのフガライブラリだったら
ホゲフガなんちゃらみたいな感じのギターのようにバーンみたいなのを公開してたんですよ。
そういうことをやってたんですけどこれがフレームワークとライブラリの違い
つまり企画を決められる側と企画を決める側がいるってことなんですね。
決められる側がライブラリ、決める側がフレームワークということです。
なるほど。フレームワークちょっと今の聞いて分かったのが
やっぱりそのプロジェクトの中のルールは全てそのプロジェクトのメンバーが決めるべきであるというような
大きな思想がありそうですね。
そうですね。どういう風に呼び出したりとかどういう風な部品がいいかっていうのは
本来それぞれのプロジェクトで違うんだと思ってるんですよ。
例えばいろんなウェブフレームワークとか
JavaScriptのフロントエンドフレームワークもそうなんですけど
大体その企画を決めてるわけでその企画っていうのがどういう基準でいいかっていうと
みんなが平均的にいいみたいなところがありますよね。
で、ある人が要望を言ってこれ多くの人がオッケーオッケーってプラ1プラ1みたいなのをつけてると
それが取り込まれるっていうのはそういうことなわけですよね。
みんなにとって平均的にいいと。
民主的な決定ですね。
だけで逆に尖った要求っていうのは入らないですよね。
入りづらいですよね。
誰もいらんみたいなことを言ってる。
大抵私はビジネスの時にこういうこと面白いことやりたいんだ他社を出し抜きたいんだっていう時に
その尖ったことをやらなきゃいけないことが多かったんですよね。
そういう時って本当にフレームワーク足架線しか立たなくて
辛い思いをずっとしてきたっていう感じなんですよね。
こういう時に私はフレームワークのライブラリーに埋め込む職人さんを辞めて
ライブラリーを直接使う人になるって決断をして
そこからずっとやってきてるんですけど
やっぱりうまくコツを掴むとフレームワーク使うより早くできるんですよね。
このライブラリーとこのライブラリーとこのライブラリー
ここで雑にくっつけて今はいいよみたいな
平均的なユースケースじゃなくて私だけのユースケースを満たしてくれれば
15:01
できますからインターフェースを雑にできるんですよね。
それが私は開発速度を上げていると思っている。
これが100点に近い部分だと私は思っていますね。
今までのフレームワークを使う利点って
今までって言ってるのはこの2,3年より前ですね。
AIが出てくるような前で
例えばRailsとかNext.jsとかを使う利点って
とりあえず少ないコードを書いたら
人間が書いたらなんか動いていい感じの
APIとかが流せるみたいな感じだったじゃないですか。
それ今話聞いてて思ったのが
現代のAIにおいてはそこいらないなと思ったんですよ。
人間が数行書いていい感じのAPIが入るなんて
AIにお願いしたらできるわけじゃないですか別に
フレームワーク使わなくても。
であれば言ってるようにフレームワーク使わないで
本当にバニラでできる限りバニラで
ライブラリを選定していった上で
どうそれを構築していくかの方に
人間は重きを置いていった方が良さそうだなって
普通に共感してきました。
一応やっぱりちゃんと良いところも悪いところも
説明しておきたいと思っていて
それが技術的判断だと思うんですよ。
一番最初に言った通りこれは
ある程度その部品の分け方とかどういう部品を使うかって
選定眼が鍛えられた人だったら取れる選択肢だと思ってます。
そういう人が100点を、80点じゃなくて100点を目指す。
ビジネス的に高速に自分がバリバリ出していくんだってことが
ガツガツできる人はフレームワークを使わないって決断が
きっと私はいいと思ってるんですけど
そうじゃなくてやっぱりジュニアの人たちを率いて
うまく広げていきたいとか
そういう風なケースとかっていうのだと
私はやっぱりフレームワークを使う方が良いケースも
やっぱり残っていると思っています。
現実は残ってそうだよね。
現実は残っていると。
ただそれはメンバーの実力に応じて
とりあえずレール図みたいな感じとかじゃなくて
メンバー見てこのチームだったらいけそうだなと思ったら
行くっていう風な決断とかっていうのができると
アーキテクトとしてはいいよねって思ってる感じですね。
ちなみにじゃあ今のAI
クロードコードでもいいですし
コーデックスでもいいんですけど
使うモデルによるかもしれないんですが
オーパス3.8とかフェブル5とか
それによって結構違うかなと思いつつも
そういった選定眼がある
ライブラリーの選定眼があるアーキテクトが1人いて
AIを使っていくっていうような環境においては
どっちが現時点でいいと思いますか?
私が観測する限り
フェブルはまだ使ってないですけど
オーパスとかレベルだとまだ設計が下手なんですよね
なので部品の分け方が非常に下手だと思っています
これは特に何も工夫しなかったときですね
何も工夫せずに夜を作ってみたいな感じでやると
18:00
そうなっちゃうと思っていて
ただ私がこれまで試してきた中だと
TDDテスト駆動開発を試させたとき
そのステップに厳密に準拠させたときは
それなりに見られるものが出てくると思っていて
この辺りの勘どころはやっぱり大事だと思います
つまり今生成されているコードの設計がひどいって分からないと
何が起こるか分からなくなっちゃうわけですよ
その意味で生成AIを作る人のスキルってのは
依然としてまだ重要だと思っていて
全部フェブルとかに丸投げできるっていうフェーズじゃないと思っていて
なので今やっぱり一応のジュニアな人たちが
AIを使って5倍10倍くらいの生産性で組むぞってときには
やっぱりフレームワーク使った方がいいみたいな瞬間はあると思っています
なるほど
今の話の前提は国明さんみたいな形で
シニアなエンジニア スーパーなエンジニアの人が
ちゃんとTDDだったりとかそういう設計の部分を
コードの匂いだったりとかコードの気持ちを組んだ上で
AIを使っていくっていう前提でした
その人が使っていくっていう前提でした
それにおいてはフレームワーク使わなくてもいいよねって感じ
なんですかね 現時点においても
なんとなく今聞いてて思ったのが
そういうプロジェクトがめちゃくちゃ今後増えてきそうだなと思いましたね
世間で
そのジュニアな人たちが多分増えない
増えないって言ったらあれなんですけど
難しいかなとは思うんですけど
結構厳しい時代になってくるかなと思うので
そういうプロジェクトがガンガン増えてきて
逆にRailsとかのシェアが落ちてきてしまうとかもあり得るのかなと
どうなんでしょうね
私が特にプロンプと何も工夫せずに
CLIツール作ってやろうってやると
まず先にCOBRAとかああいうCLIフレームワーク落としてきちゃうんで
ちょっと待ってみたいな感じで使ってくるんで
多分AIは初手選んできます
それがそういうOSSプロジェクトが多かったからですよね
たぶんそうですよね
今まで学習してるものが
だからここはあえてこっちの方が私たちは成功できると思うっていう
かなり思想の強い意見を注入してあげないと
AIは真っさらには作っていけないんですね
それを入れればいいってことですよね
入れればいいってことだね
こういう思想でフレームワーク使ってしまうと
アップデートになったりとか自由さがなくなってくるから
絶対にこのプロジェクトではできる限りVanillaで
できる限り依存もなくっていうような形で
作っていってくれみたいな形ですよね
今こう言いながら思ったんですけど
AI使っていく中で依存の簡潔さというか
依存が多すぎると厳しいことになるなと自分自身思ってて
だからこそフレームワークは使わないというよりかは
依存をできる限りしていかないみたいなところの方向性で
21:04
結構考え方が近しいなとは思いましたね今
そうですね依存が増えれば増えるほど
いっぱい辛いことがあってアップデートはもちろん
依存しているコンポイントが多ければ多いほど
アップデートが頻繁に発生するし
そして脆弱性も入り込むし
なんならサプライチェーンアタックされるし
というようなことがあるわけで
今は依存が多いほど不利な時代に
どんどんなってきているなというのは感じますね
それよりかはAIとかで使って
授業とかAIが書いてテストするだけで済むんだったら
ライブラリ使わないでハードコードしてくれって
いうふうにの方が得だと思った
そうですね
ちょっと途中で出てきた
ライブラリとバニラの差というか
あれなんですけどバニラというのは
言語の標準
標準ライブラリしか使わないということですね
標準APIを呼び出すみたいな
プラットフォームごとの標準APIを呼び出す
みたいなところってことですね
そうですね
やっぱそうですよね
あとちょっと気になったのが
JavaScriptでいうとTypeScriptはどうなのかという
TypeScriptみたいなトランスパイラー
私が唯一NPMで真っ先にインストールするのは
TypeScriptだけで
あとはその定義ライブラリぐらいで
あとはほとんど入れないですね
っていうことはTypeScriptはちょっと例外すぎる
そうなんですよ
言語っていうのはちょっとやっぱり
別格な感じありますね
ですよね
それはわかるなと思う一方
TypeScriptが出てくる前
CoffeeScriptというものが
流行ってたかなとか
あとはJQueryを
あれはライブラリなのかフレームワークなのか
もしかしたら言語という人もいるかもしれないですけど
そういう規定となるところは
やっぱ外せないっていうところなんですかね
TypeScriptぐらいになると
そうですね
TypeScriptのいいところ
フレームワークの悪いところが出てないんですよ
何でかっていうと
フレームワークの悪いところって
さっき言われたとおり制限されちゃうっていうのが
あるわけですけど
そのTypeScriptって
大抵動くものは型検査が通るように作られてる
これは完全性って言い方をよくするんですけど
TypeScriptって
型検査が通るものは動くっていう健全性よりも
動くものは型検査が通るっていう
完全性の方を重視してる言語だなと思っていて
なので大体のものは
動く行動っていうのはTypeScriptで書けるんですよ
なんならAmyとかで逃げられますからね
そう考えるとすごく自由度はあるんです
だってしかもJavaScriptの完成日だしみたいなのできるし
JavaScriptのライブラリ使えるし
その自由度が損なわれてないんですよ
なるほど
それに比べてCoffeeScriptって
JavaScriptでできることは大体できるんだけど
めんどくさい方法を駆使しないと
JavaScriptのコードが素直に呼べなかったりとか
っていうのが
あったっていうのはやっぱりあると思っていて
そうするとやっぱり言語の力
どっか制限しちゃってるんですよね
その制限がない方が私は好ましいと思っている
なるほど
って思います
TypeScriptは完全にJavaScriptを語幹の上に乗った
24:03
プラスアルファ型を付けた
ものだからいいっていう
そうですねプラスアルファいらんなと思ってるんですけど
いらむとかあとはネームスペースみたいな
別にいらんなって思いながら
ああいうの消せばいいかと思ってました
なるほど
だからそのぐらいシンプルな
トランスファイラーだったら
いいよね
ところなんですね
Javaで言うこと林がどの程度その
立ち位置になっているかどうか
ちょっとあれですけど
いろんな言語がある中で
そういう言語としては
しょうがないかなというところがあるんですね
やっぱり言語としてもフレームワークとしての
強さと似たような尺度はあると思っていて
他の関数他の言語で書かれた関数を
どれぐらいちゃんと呼べるかっていうのが
結構私は基本になると思っているんですよ
その意味で言うと最強なのがC言語で
どの言語からもだいたい呼べるように
作られている
正確に言うとみんながどの言語も
C言語は呼べるようにしておくかと思って
C言語の規約で呼べるように作っているので
そうできちゃうんですよね
それはC言語のすごいところだと思うんですが
じゃあ最終的には全部C言語で書きましょう
絶対に書けないですね
自分の足を踏み抜く
打ち抜く未来しか見えないんで
そうはならないってことですね
そうですね
なので私は自由に書ける中でも
やっちゃヤバい領域ってのがあると思っていて
やっちゃヤバい領域をどれだけ守ってくれるか
っていうのは結構大事だと思っているんですよ
これはJavaScriptじゃなくてTypeScriptを
使う理由なんですよね
明らかにエラーを吐くコードは
許してほしくないってことですね
それで言うとC言語は
エラーになるかもしれないけど
とにかくお前は速さを要求したみたいな時に
すごく使える言語なんで
そういう時にはやっぱりC言語を
使うしかないんじゃないと思うんですけど
そうじゃない限りは
そんな性能いらんよっていう時には
なるべく安全な言語を使いたいですね
今C言語って言ってましたけど
多分一昔前はアセンブリ書くかどうかみたいな
そういう議論になってたと思うんで
そこのレイヤーがどんどん上がってきたっていうような
今だったらTypeScriptだったりとか
他のプライマリーな言語だったりとか
ここに私が普段ラスト言語をあまり使わなくて
語言語とかを使ってるっていうのも
理由がここにあって
ラストっていうのはすごくやっぱり
カリカリに早く書くことができて
CとかC++にも安全な言語だと思ってるんですね
ただ私はそこまでの安全性は別に
必要ないことが多いんですよ
カリカリにする必要がないので
別にGCがあっても
インクリメンタリーGCみたいなのだったら
全然構わないし
インクリメンタリーGCって
要するにGCがかかった瞬間に
止まっちゃうとかってのが
昔あったじゃないですか
ああいうのがなくて
インクリメンタリーつまり
ちょっとだけCPU組んだけど
でも止まらないとできるみたいな
そういう風なGCとかがついている
っていうのであれば
まあいいじゃんそれで
メモリリングしないし
そういう風に思ってるっていうことですね
書きやすさと言語の堅牢さみたいなところは
いい感じにバランスすればいいよねっていう
そうですね
書きやすさというよりかは
27:02
制約
どれだけ制約を気にしなきゃいけないか
っていう部分が
フレームワークとも近い話になっていて
例えばラストとかだと
型とかっていうのを
型の特にメモリとかっていうのを
開放タイミングとかっていうのを
決定できるようにするために
いろいろな型のトレートって呼ばれてるような
制約を書くことができるようになってると思うんですけど
あのトレート別にいらんやん
とかっていう瞬間あるわけですよ
だってそのトレートとか
使いたくなるのは
ヒープに置くかスタックに置くかみたいな
そういう風な話とかっていうのを
どうするかっていう決定を
常々しなきゃいけないってことなんですよね
その決定は別に
自分のアプリケーションだと大事じゃないってことは
往々にしてあるわけで
そういう時には
ストレートにやりたいこと書いて
それで動くって方がいいじゃん
って思ってるってことですね
なるほど
そもそもラスト
使いどころかなとは思いますね
ラスト自体
Modularが開発した経緯が
おそらくブラウザで
ブラウザの実装のために
C言語から置き換えていくための
ラスト言語っていうようなところだったのかな
という面を考えると
ちょっとGoとは立ち位置違いそうではある
だいぶ違うと思いますね
どっちかと言ったらGoは
Cみたいな領域を狙ってる言語だなと思ってて
だから素朴に動く
っていうところを狙ってるんじゃないかなと思ってて
それに比べてC++とか
ラストとかって
かりっかりに動かすぞ
その代わり
お前は自分の足を打ち抜かないことは
自分で確認しろみたいなところがあると思っていて
そういうとこってのはやっぱり
生きるシーンは結構あると思うんですよ
すごくメモリが
制約が強いような言語だったりだとか
あとは速さがとても大事なものって
世の中にまだいくらでもありますよね
そういうものとかっていうのは
やっぱラストが生きるんだろうと思います
そこでしか価値を出せないのであれば
やっぱやるビジネスというか
やるプロダクトによって
そこは選定していくべき
そうですね
そのやっぱ
ある今回の話の中の一本筋とってところとして
自分のプロジェクトは
ちゃんと自分で意思決定をして
技術選定を
ぬかりなくちゃんと
適切なものを選びましょう
というようなお話かなと思うんですけど
言ってしまえば当たり前の話なんですが
安易にフレームワークを選ぶなというところが
ちょっとそこが
強い思想として出てきて
そうですね
つまり
フレームワークを使う使わないは選択肢なんだって
自覚することが私は大事だと思っていて
使わないって選択があるんだと常に
ライブラリーもそうです
自分で書くって選択が常にあって
それを我々は選んで
その一つのコードを作り上げていくわけですよね
その一瞬一瞬
その選んでいく一瞬一瞬で
これはこれを選ぶとどうなるのか
どういうふうな他に選択肢があるのか
っていうことを考え続けるってことは
私はアーキテクトのすごく重要な支出だと思っています
なので
その一個一個のその決断っていうのを
やっぱ大事にしていきたいですね
っていうのはすごく思いますね
すごい重要な話ですね
今後のエンジニアの在り方として
30:01
そういう意思決定をどれだけしてきたか
どれだけする気概があるか
やりたいと思っているか
っていうところがかなり重要になってくるかなと思う
そうですね
特に最近私がAIと付き合ってて
そのこの意思決定で大事だなと思っているのは
実現しすぎないっていうことだと思っていて
実現しすぎない
AIってすぐこれ何とかもできますよ
やりましょうかっていうので終わるじゃないですか
確かに
あれあれですね
やめろみたいなとか
最後に提案してくる感じ
提案してくる感じのやつ
それが大体余計なんですよ
私が思うにその機能の8割ぐらいを
満たしていて
欲しい機能ってやっぱ100とかあると思うんですよ
これやったらもう最高ピカピカみたいなのがあるんですけど
そこまでやっちゃうと
すっごくコードの量が多くなってしまうことが
私は経験的に多いなと思っていて
8割ぐらいで止めておくと
ちょうどいい保守性で
でも実現されてることは実現されてるから
まあまあいいんじゃみたいな
それでちゃんとメンテすることが
し続けることができるっていうのだと思っていて
この8割をどう見てやめるかっていうのが
結構大事だなと思ってて
AIとかが例えばパフォーマンスチューニングお願いしたときに
ここもパフォーマンスチューニングしときましょうか
って言ってくるので
おいおいやめろそこはパフォーマンスチューニングするんじゃないみたいな
とか結構あるんですよ
そこチューニングすると変更容易性が失われるから
やりづらくなるとか
あとはテスト用意性が下がるから
品質が下がるみたいな
とかにパフォーマンスチューニングしてほしくないと
っていうのがあって
そういうときとかはやめろみたいな
止めに入れることが大事だと思ってますね
いやめちゃくちゃありますね
そこの勘どころが
今までエンジニアやってきた人で
もちろんない人もいるかもしれないですけど
ある人がAIを使っていく利点でもあるかなと思いますね
ただこれは何かこう
何でそれが成立してるのかっていうと
痛い目を見てきたんだと思うんですよ我々は
AIはまだその痛い目を見てきたっていうのを
その時点ではそのコンテキストでは
自覚していないんだと思うんですね
それをこう
うまくスキルに落とし込んだ人がいて
この前私がその会社で紹介してもらった
プレモーテムっていう概念があって
プロモーテム
プレモーテム
ポストモーテムはよく知られてると思うんですよ
振り返りとかです
例えば障害とか起きちゃったとか
何でそれが起きちゃったんだっけ
我々の対話適切だったんだっけっていうのを
後から振り返るポストモーテムって言いますよね
そのポストモーテムの事前にやる番
プレモーテム
っていうのがあって
これで例えばこの設計にしようと思うんだけど
これで何が起こるみたいなことを
AIに聞いてみるわけですね
そうするとコンテキストの中に
このまま行くとこういう風にして破滅します
みたいなところが予測できるようになる
そういう風に未来のことを
AIに意識させてあげるっていうようなことを
してあげると
比較的いい選択肢が
これから出てきやすくなるんだろうと思っています
なるほど
事前にこういう選択をしようと思うけど
ちょっとどう思うかなっていうところを
相談しつつ検討していく
その知識を貯めていくっていうところ
プロジェクトごとに
先にADRを書くみたいなところと
若干似てるのかなと思うんですけど
33:00
技術選定する時にADR書いて
A案 B案 C案っていうのがあったけど
A案はこれこれの理由で却下
B案はこれこれの理由で却下
C案にしますみたいな
そういうのは若干近しいですかね
近しいですね
そこは間違いなくアーキテクトとしては
未来を見ながら意思決定してるんですよね
これあるとどうなる
このまま意思決定が
こういう風な意思決定をし続けたら
何が起こるみたいなことを考えて
やってるわけで
AIにはやっぱりそこがなくて
もうちょっと近視眼的ですよね
今のコンテキスト
やるかどうかみたいな
そんな感じ
なのでそこがやっぱり
まだ人間が必要とされてる部分なんだろうと
思っています
いや重要だな
本当にそこさえやっていけば
空に困らなそう
エンジニアとしては
どうでしょうね
コンテキストが広がってきたら
分かんないですよ
AIが何でもできるようになってきたら
そこまでできちゃうかもしれないですけど
来年もしかしてできてるかもしれないですけど
そう
でもちゃんと自分がコントロールしていくんだ
ちゃんとこのプロジェクトは
自分が決めてこうしていった
だからこうなって
ちゃんとできてる
もしくはできてない
ちゃんと失敗も
自分の糧として
その経験自体は
人間にたまるはずなんだね
そうですね
それは別に
AIが進化したとしても
どこかで行きそうかなとは思います
そうですね
今まだAIって
コンテキストがすごい小さいので
人間って昨日あったこと
去年あったこととかって
覚えてるじゃないですか
去年にあったことが大抵
おぼろげになってると思いますけど
そこまでコンテキストが広いって
驚異的だと思うんですよ
私だと今
37歳
8歳
分かんないな
そういうぐらいなんですけど
38年間分の記憶が
ある程度コンパクションされながらも
あるわけですよ
それはさすがに
AIではなかなか
保持するのが難しいコンテキストなので
それがその
10年間
20年間で
私がいろいろ失敗をしてきたっていう
そのコンテキストは
私を今の
意思決定に生かしている
それがまだ
AIでは真似できない
コンテキストがもっと広がらないと
真似できないと思いますね
その38年間分のコンテキストを
有することができるようになった
AIが現れた瞬間
はい、ごめんなさいってなる
そうですね
そしたら
あなたの方が正解だ
みたいな感じになるんで
アーキテクトとしては
約ごめんってことでしょうね
それを実現するには
人間の脳みそぐらい
すごい圧縮率を持ったデータ構造が
必要そう
な気もするんで
しかもエネルギーも
相当小さくしなきゃいけないですから
みんなが使うとかってなると
なかなかまだ難しいと思いますね
でも何年後かには出てきそう
なんで
そうですね
まあまあ
前回話したような感じで
暗い未来になりそうなんで
このぐらいで
まとめたいなと思うんですけど
話聞いてみて
フレームワーク使うなみたいな
過激派な意見
すごい過激派だなとは思いつつも
話聞いていくとやっぱり
依存関係をできる限り
少なくしていくだったりとか
このプロジェクトは絶対
36:00
自分が意思決定していくんだ
というような
モチベーションだったりとか
あとは意思決定を
どうしていくのかという
アーキテクトの思想だったりとか
そういうところはかなり
思想として共感できるな
というところだったんで
過激派というよりかはやっぱ
堅実的なところなのかな
というのが若干思ったところなんですが
なんか最後に
私のこの過激派として
もうちょっと過激派なところ
あったりするんですかね
そうですね
フレームワークが補助品って
言い方をしてたのは
すごく過激派だなと思ってて
でも良くも悪くも
私は補助品だと思うんですよ
すごくいい人にとっては
補助品はありがたい
だけど補助品を付けてると
速度は出ないんですよ
確かに
そういう塩梅だと思っていて
それを意識してやるのが
いいと思います
あくまでもこれ補助品であって
加速装置ではないんだぞ
というところですね
エンジンはお前自身なんだ
だから頑張れみたいなところですね
すごいいい話だなと思いました
ありがとうございます
ということで今回は
ここまでにしたいなと思います
もっと詳しく教えてください
ラジオ略してクワラジでは
スーパーエンジニアである
国明さんに
一般エンジニアである
ヘントゴが技術的な質問を
していく番組になってます
今後もいろんなことを
聞いていきたいなと思いますので
大ききなプラットフォームで
高評価やフォローのほうを
お願いします
またこんなことを聞いてみてほしい
みたいなことがありましたら
コメントとか
Twitterとかで
呟いていただけると
非常に嬉しいです
よろしくお願いします
ハッシュタグつけて
クワラジで呟いてもらえると
非常にありがたいです
感想もお待ちしています
それでは今回もありがとうございました
ありがとうございました