Kaigi on Rails 2026と豪華なキーノート
こんにちは、こばちえです。 こんにちは、たなけんです。
てくてくラジオは、仕事の合間にするような、ゆるい雑談を配信するポッドキャストです。
今週もよろしくお願いします。 よろしくお願いします。
はい、ではエピソード260、やっていきたいと思います。
はーい、やっていきましょう。
今回はですね、先日10月の16日、17日に東京で開催された
カイギオンレールズ2026の話をしたいと思います。
はい、楽しかったですね。
今回はね、たなけんさんも私もオフラインで会場の方で参加させてもらって、
たなけんさん、去年も参加しましたっけ?
去年は参加、去年は参加しました。
そっか、だから2人とも1年ぶりのカイギオンレールズだったっていう感じなんですけど、
今回はね、キーノートスピーカーがフェールズを作ったDHHさんと、
あとルビーのを作った松本さんのお二人ということで、
だいぶね、豪華なラインナップでの回でしたね。
どうでした?お二人の話聞きました?
聞きましたよ、もちろん。
いやーなんか、結構DHHも松本もそうですけど、
もうコードを自分自身で書くことはないということを結構しっかりと言い切っており、
ね。
そこまで断言して言うんだねって、
そのDHHに関しては、
AIコーディング時代の転換点
すでにね、そういう話を9月末頃か、
レールズワールドでね、
していましたが、
改めて、松本も、僕は全然書いてないんですけどね、みたいなスピンデルの話をしてた時もそういうふうに言っていて、
そういう時代になってるんだなと、
言語デザイナーもコードを書かない時代、
まあでもデザイナーだからそうなのかな、
という感じもしましたね。
ねー、そうAIにコードを書いてもらうっていうことと、
じゃあそれがもう前提になりつつあるじゃないですか。
みんなAIでコードを書かないってことも日々ないかなって思うんですけど、
一部のね、
一部の方を除き、みんなコードを書くときAI使ってると思うんですけど、
その先で自分たちが何を作って、どう開発を進めていくのかっていうのを、
なんか、
改めてではありますけど、
考えるきっかけをいただいたなって思ってます。
そうですね。
DHHのエールズワールドの時はちょっと過激めだったのかな、
私ちゃんと見れてないんですけど。
はい、そう聞きますね。僕も原文見たわけじゃないんで、
原文になっちゃいますけど。
っていう話だったけど、
DHHの時は多分比較的マイルドな形で私たちに伝えてくれたかなと思っていて、
このAIが使えるようになってきた、
AIにいろいろ任せられるようになってきたっていう中で、
自分たちが何をしていかなきゃいけないのかなっていうのを素直に受け止めて考えられる話し方をしてくれたんじゃないかなって思ってます。
あまりに過激な感じはなかったから。
そうですね。
そうそうそう、マイルドでしたね。
でもターニングポイントだなって改めて思いました。
そうですね。
なんか、
AIコーディング、AIエージェントにコードを書かせるということ自体はもうずいぶんやってきたと思うんですよね。
去年1年ぐらいで劇編だったなって、
今年もう10ヶ月ぐらい経ちましたけど、
それがすごく浸透して当たり前になったり、
劇編を受け入れた2026年っていうことは感じていて、
改めて今の現状とどう向き合っていくのか、
AIにコードを書かせる中でどう開発していくのかを突き詰めて考えることで、
本当にプロダクトであれば使ってくれるお客さんに届ける価値が何倍何十倍にも変わり得る。
ここで怠けてしまうと、
今まで通りの開発をし続けようとしてしまうと、
頑張って開発の仕方を工夫したり突き詰めた人との差分が、
本当にめちゃくちゃゼロ二つ違いうるみたいな桁が二つ違いうるぐらい、
10倍から100倍ぐらい普通に差が開く可能性あるなと思って。
本当にそう思ってますね。
設計原則と人間が読むコード
今年はさ、モデルがすごい進化したなと思ってて、
元々去年とかで初めの頃って、
AI便利だねって感じではあったけど、
まだそんな任せられる雰囲気ないよなって思ってたと思うんですよね。
かなり信用してなかった、今もちろん信用しきってないけど、
でもその明らかに何か変わった感はありますよね。
うん、もうすごくできるじゃんみたいな。
なんかそうね、HHにしてもMATSにしても、
書かせてそれをプロダクトの方に反映してるっていうのを見ても、
ある程度ね、AIができるようになっているっていうことだと思うんですけど、
そうそう。
なんでそのモデルの進化っていうのはすごく大きいなって思ってて、
じゃあその時にコードを書かなくてもプロダクト作っていけるじゃんとか、
ソリューション提供していけるじゃんっていう時代になってきた時に、
なんか今回ちょっと面白かったのが、DHHの話の中で面白かったのが、
設計原則、ソリッドとかドライとかっていうの。
原則として抑えておくべきものっていう考え方をしてきたと思うんですけど、
それが本当に必要なのか、考える必要があるよねみたいな話をしてくれた気がしてて、
なんかそこまで思ってなかったから、個人的には。
そっかそこももしかして変わってくるものなのか?みたいなやつは、
まだちゃんと理解はできてないし、本当にそうなのかも自分の中で答え出てないけど、
なるほどなって思った。
そう、一つはね、なんかそこもか?みたいな。
そこにも変化が出てくるのか?みたいなところは、
ちょっとなんか問題提起というかね、観点として面白いなって思いました。
そうですね、なんかAIが書いてくれるコードを完全に信頼して、
仮にね、もうノーレビューで要件だけ満たしてて、テストがあってテストが通ってれば、
もうマージしてそのまま使うものとするっていう前提に立つと、
別に人間に読めるコードじゃなくてももはや良くなるというのは多分あって、
だからもうバイナリで良くなるみたいな話があると思うんですよね。
AIが理解できるバイナリで直接生成するぐらいの話で、
それで問題なく動いてるんであれば、もはや今ノーレビューで
マージしているプルリクがもしあるんだとしたら、
それはもうコードが中身が何であってもOKっていう話になっちゃうから。
いやそうだよね。
特論そうだなとは思ってて。
そうすると、その部分がもうあんまり気にしなくてもいいよっていう感じになってきた時に、
エンジニアの役割と価値提供
じゃあ私たちは何をやっていくといいんだっけ?
ちゃんと考えていきたいなって思って、
今私のいるプロジェクトというかチームでも、
やっぱり開発、実装するプログラムを書くっていうプロセスのスピードアップがすごく進んでるなって思うんですけど、
その代わりにお客さんの業務だったりとか、
ドメインだったりとかをちゃんと理解した上で、
何を作るかを考えるっていうところが逆にボトルネックになりつつあるんですよね。
だからそっちなのかって思ったりしてて、
でもそれってエンジニアなのか?みたいなやつもまだふわふわしてる。
そうですね。
エンジニアリングをどう捉えるかみたいな、どう解釈するかという話にはなるかもしれないけど、
極論は何を作るか、プログラムのライターではなくてクリエイターになるみたいな、
そういう話が今回もあったような。
そうだね。
と思いますけど、何を作るのかを考えること、
結局何か作って終わりじゃないというところがミソというか肝だなとは思っていて、
そうだね。
だからクリエイターと言いつつ、
価値提供者である、あり続けるというのが多分求められていて、
その持続性と提供し続けるという、届ける、デリバリーと持続性みたいなところで言うと、
何かあったら何か変更させ戻したり、新しい機能を作り続けたりっていう責任があるっていうところが、
単にクリエイターと言っても作れれば ok じゃなくて、
メンテナブルで持続可能であるっていうことを考えるとやっぱり技術に精通していることは必要だろうと思ってはいて。
そうだね。
ソフトウェアをちゃんと設計できるっていうのと、
お客さんの業務をちゃんと理解した上でプロダクトに落とし込めるっていうのは、
もちろんこれまでも両方必要なスキルだったと思うんだけど、
ちょっと比重は変わっていくかもしれないですね。
これからエンジニアが持つべきスキルとして。
ソフトウェア設計とかの部分のスキルが今まで比重高かったかもしれないんですけど、
プロダクトの仕様決めたりとかはPDMとかっていう人たちが担ってたりとかもしたと思うんですけど、
もうちょっとエンジニアもPDM側に染み出していったりとかっていうのがね、
よりそう求められていくのかもしれないなとちょっと思い始めてますね。
PDM定義っていうのもちょっとふわっとしてるかもしれないけど。
これからのチームのどうなっていきたいっていうところも、個人のもそうだし、
組織としてどういう人をみんなに来てほしいかとか、
育成していくかっていうチーム編成とか体制のところもそうだし、
そう開発組織としての設計もね、なんか影響を受けそうだなと思ってて、
本当にAIでコードが書けるようになって便利になりました、ではないフェーズに来たなって思ってます。
そうですね。
そうだよな。便利になりましたのフェーズじゃなくなってるよな。
どこまで何が影響を受けて変わるかがね、まだ手探りな感じがする。
RubyとRailsに残る思想
そうそう。なんかその人間が読めるコードであるべきかみたいな、
人間にとって読みやすいコードの設計原則みたいなものって必要なのかみたいな話がさっきありましたけど、
なんかさっき極論バイナリを直接AIが出力してくれればOKみたいな話はしたんですけど、
価値提供者であるみたいな何か問題があった時に部分的にどこを書き換えるべきか判断できるっていうのを
人間がやっぱりするんだよっていう前提に立つと、そのためには人間が読めるコードであってほしいというのはあるんで、
なんか結構最初に作る時よりも、それをメンテナンスし続けていくために
人間が読める形に出力してもらっているという意味合いの方がもしかしたら強いのかもしれんなという気持ちがしてきましたね。
なるほどね。
そうするとRubyとかRailsは読める詩はみんな好きだから、やっぱそれを使って成長させていくっていうのは意味があることだよね。
RailsにしてもRubyにしても、今回DHHはラストに書き換える、ラストを使って書き換えるって話をしてたけど、
Railsの少人数のチームでアプリケーションを開発していけるとかっていうその思想自体は、
あとコミュニティの話だったりとか、それはこれからも各のものとして残るって言い切ってたかわかんないけど、
それはあり続けるっていう感じのことを言ってくれてた気がするし、
あとなんか松本さんはスピネル今使ってるけど、松本さんが作ってるからスピネルもRubyだみたいな。
これは松田さんの発表の中でちょっとチラッと出てるかな。
松田さんの話ね。
っていう話はしてたじゃないですか。
だからDHHと松がそれぞれクリエイターとして続ける限りはRailsとRubyはあるのかなとは思うんだけど、
何かしらの概念として少なくともね、概念としてはあり続けそうって思ってるけど、
なんかその先ってなってくるとどうなっていくのかはより一層わかんなくなったなって思いました。
そうですね。
ちょっと面白かったな。概念になっていくのかなって思うとちょっと面白かった。
確かに。これがRubyのエッセンスであるみたいなそのものが、
それは今現状Rubyと呼んでいる言語の形じゃなくても、こういう概念をRubyと呼ぶものとするみたいなものになりうるっていう感覚は理解できましたね。
面白かったですね。
それがもうちょっと言語化、自分の中で言語化できていくと面白そうだなと思ったから。
RailsとかRuby好きですって言っているもので、実際に何が好きなんだろう、もうちょっと自分で話せると面白そうだなってきました。
なるほど。
感じですね。
一般参加とDHHとの写真撮影
前にもちょっとお話ししたと思うんですけど、今回私は一般のアテンリーとして参加させてもらって、
ちゃんとね、GNOTEのセッションも一聴講者として聞けたから、この何だろうな、ターニングポイントというかすごく変化点である
2026年のセッションを聞けたことはすごくありがたいなと思ってて、とても良い機会になりました、経験になりました。
今まではね、スタッフ側だったからなかなかねじっくり聞くというのは難しかったかもしれないんでね。
そうそう、受付とかにいるとなかなかそのセッション始まっても会場にね、セッション会場の中に行けなかったりとかしてたから、そうなんですよ。ありがたいですね。
スタッフの皆さんに本当に感謝でございます。
いや本当にありがとうございます。スタッフの皆さんお疲れ様でした。
お疲れ様でした。
あとね、私ね、DHHと写真撮ってもらったんですよ。
いいですね。捕まえてましたね。
そう、並んでね、並んで写真を撮ってもらいました。
なんかすごくDHHフレンドリーな感じで、割とたくさんいろんな方と写真を撮ってくださっていたように見えて。
うん、本当に。
ちょっと僕、壁を感じていた部分あったんで、どれくらいフレンドリーに写真撮影とかに応じてくれる方なのか、ちょっとあんまり認識がなくてですね。
私もです。DHH初めてね。
寄り添ってくれる方なんだなという印象になりました。
本当にそうなんですよ。でもすごく緊張しました。撮ってもらうとき。
本当に一言、なんか素晴らしいお話ありがとうっていうことを言うだけでもすごい緊張したし、写真撮ってもらうのも緊張したし、
なんかね、わかんない、勝手に私が思ってるだけですけど、なんかオーラを感じた。
うん、確かにね。
嬉しいかったです。
いや、よかった。
はい、じゃあそんなところかな。
はい。
はい、ではではエピソード260は会議オンレールズ2026に参加してきたお話をしてきました。
今回も最後まで聞いていただいてありがとうございました。
ありがとうございました。
バイバイ。
バイバイ。