快適な環境の重要性
じゃあ次行きますか。 楊 次行きますか。ちょっと自分はいまいろんな言語の話をピックアップしたんで、なんか金城さん、これ喋りたいってのはありますか?
金城 快適な環境を追求する、いこっかな。これ何章だっけな。 日本人の方に入ってる方ですね。
金城 そうですね。これはあれかな、達人プログラマーかなとかで言うと、職人として道具にこだわろうみたいなのはよく言われますもんね。あれ系の話ですよね。
そうですね。 金城 実際ここに書いてあるのもすごいな、例え話が端的で面白いな。端末、ターミナルですね。端末の背景色が白、それなら黒に変えてみましょう。
自分に合った見やすい色を探してみましょうみたいな書いてあって。なんか僕割と、開発環境に関してかなり保守的というか、環境をいじるぐらいだったらアプリケーションを書いたりとか、
リファクターやっちゃったりしたいなっていうニーズが強すぎて、あんまり今使ってる道具自体を整えようっていうのはそんなにめちゃくちゃするべきだし、こうあったらいいんだろうなって思うんですけど、
思いつつも今のままでいいかってサボりがちなのですね。なんかね、それこそなんちゃらRCみたいなファイルはだいぶ更新されてないの、それも使ってるしみたいな。
なんですけど、やっぱりエージェンティックコーディングやるようになってくると、環境が整ってないことがボトルネックだなとか環境扱う系のツール、ギットの使い方とか含めてですけど、
もっとこういうことできるはずなのに、今のその設定不備とか環境とか土台が整ってないことが明らかに今自分の足を引っ張ってるなっていうのを感じる場面が増えて、
快適な環境を追求するっていう話の重みが増してきてるような気がするなと思ってこのエッセイを取り上げたんですけど、どうですか。
設定とワークフロー
いやーなんかそれこそ自分も結構近所さんに近くて、理想的にはゼロコンフィグでやりたいっていうかデフォルト中なんですよね。極力いじりたくない。なぜならもう一回シェットアップするのがめんどくさいから。
っていう感じで、そんなにこう設定をどうしても例えばパスを落とさないといけないよねとか、さすがにターミナルに今ギットのブランチは表示しておきたいよねとか、
変更があった時にはちょっとわかるようにしておきたいよねとか、なのでドットファイルみたいなものにちょっと書き足すはやるけども、基本的にはあんまり何もしたくないなと思ってて、
それが昔はEmacsとかビームとかに憧れて、すごいハッカーっていうのはみんなビームかEmacsを使ってその設定を色々設置していてコードジャンプができてとか、黒い画面でガタガタするとなんか突然ファイルがパンと開かれてとか、
いやすごいなと思ってたんですけど、もうそれがなんか自分はやっぱ設定して何かをやっていくっていうのはできないなみたいな、そこについていくのが辛いなと思ったんで、むしろ逆に何も設定せずにそれでもパフォーマンスが出るように自分の方を変えようみたいな感じでずっとやってきてて、
PHPストームとかも必要最低限はそのPHPユニットの設定だったりとか、エクセルパックの設定とかはするけども、極力デフォルトでいたい、デフォルトのために日本語のパックを毎回振ってきてそれはいりませんってやり続けることをやってたりとか、
そうそうそう、変えるとわかんなくなっちゃうからサウンドロームやからっていうのをやったりしてて、確かに直近やっぱエージェントリコーディングだったりとか来て、もうちょいやっぱりGitWorks3の設定のGTWTとか最近便利なツールがどんどん増えてるんで、やっぱその辺はちょっと試してみないとなとか、
ターミナルも今までなんとなくItem2を使ってたけどGhostyとか出てきて、まさにゼロコンフィグで使えるようなターミナルが出てきたから、あ、だったら乗り換えてもいいかなとか、こう最近ちょっとずつ考えてて、なのでちょっと今こう全体的に転換点なのかなっていう気はしてますね。
おだしょー まさに昨日というか18時間前ぐらいにItem2からGhosty乗り換えようかなって思って、ゼロコンフィグでそのまま結構快適に動けましたっていう記事も見かけたんで、お、いけそうだなって思ったんですけど、待てよ、Item2自体がゼロコンフィグじゃないからどうしようって思って、じゃあ目の前のタスクやろうってなったんですよね。
おだしょー そこは勇気を持って設定を全部捨てていくしかないという。
おだしょー 捨てていくしかないよな、何がやりたいんだろう、GH2使えて、それは別にターミナル設定じゃないので、何が必要なの、GH2があってブランチ名が出て、でフォントが僕の好きなユータフォンコーディングになってればいけんだろうな。
おだしょー そうすると多分フォントぐらいのコンフィグ書いてあげれば、たぶん毎日。
おだしょー ターミナルそうですよね、ターミナル自体何が重要なんだろうっていうのはそんなに踏み込んでないからな。ターミナルで動くクロードコードだったり、コーデックスだったり、Gitとか諸々のコマンドだったりでしかないので。
パスが通っていれば明日ぐらいは通せるぞっていう自信がある。
おだしょー それって結局シェルの方の設定だったりするじゃないですか、基本的には。
おだしょー そうなんですよね。
おだしょー だからまあ設定でいけるはずって思いながらフォントサイズを調整したいとか、手に馴染んでるショートカット、例えばスプリットするときのショートカットが違ったりすると最初ちょっと覚えるのはあるよねとか。
おだしょー 自分はそもそもそういうことすらやってないので、ショートカットすら全然覚えてないんで、コマンドTでタブを開いて手でこう下に持ってくるみたいなことやってるぐらいなんで。
おだしょー なのでも移行コストがゼロなんで、じゃあとりあえずやってみるかができましたね。
おだしょー いやーそうですよね。ポータブリティの高い状態を保っておくの大事ですよね。
おだしょー でもその裏には職人として道具にこだわるっていうところのなんか追い目みたいな。だってキーボードもみんな自作キーボードであれがいいこれがいいってやってるけど、いやもうMacについてるんだからそれでいいじゃんって一番思ってて。
おだしょー まあCっていうんだったらA字の配列がいいねぐらいな感じで、もうそれでいいって思ってるぐらいなんで、本当にこだわりないんですよね。
おだしょー それもそれでありですよね。
おだしょー あとはあれですかね、でかい画面を使うっていうのはもしかしたら一個こだわりかもしれないですね。
おだしょー どのくらいの使ってるんですか?
おだしょー これはどれだ、ウルトラワイドで30何インチとかのやつだったかな確か。
おだしょー へーすごい。
おだしょー これを昔5年前コロナぐらいで買って、Type-C1本で給電とハブにもなる。給電もできるしハブもモニター側にUSBのポートがあってハブにもなるってやつを買ったんで、
並列作業の工夫
おだしょー まあケーブルが少なくていいよねとか、そういう邪魔にならない、邪魔になるものが増えないものがいいなとか、そういうこだわりはあるけども、
おだしょー 割とみんな結構最近同じ感じでやってるから、強いこだわりかって言われると意外と一般的かもなみたいなこと思ったりしますね、この辺は。
おだしょー あとあれか、環境っていう話と、さっき言ったショートカットの話とかも含めてですけど、自分のワークフローとか、こういう作業タスクが多いよねっていうの密接に関わってるなーっていう気はするので、環境もそうだけど僕が見直したいのはワークフローの方なのかな。
おだしょー それこそGitのワークツリーとかはちゃんと使いこなしましょうとかも、ちゃんとやれてないので。
おだしょー 分かる。やったらいいんだろうなと思いながら。
おだしょー ワークツリー、AIが書いたコードであれ何であれ、ちゃんと変更は自分の目で置いたかったんですよ。コードの変更を追うためにはちゃんとIDで表示したい。
おだしょー ってなるとワークツリー生やしちゃうと、生やしたツリーごとにPHPストームのプロジェクト設定してウィンドウ全部立ち上げるのかっていうのが奥すぎて、ワークツリーをせいぜいにメインのところとワークツリー生やしても1個か2個だなーっていう感覚が強かったんですけど、
おだしょー 最近ここ1ヶ月ちょいぐらい色々やってて、作業は作業で裏側でやらせておいて、チェックインというかコミットをそろそろするか整えるかってなったタイミングで一旦開いてみればいいかな。
その代わりに自分の作業はスケールアウトさせるというか、5ブランチとか6ブランチとか並列で生やしてある程度まとまった量作業を裏側でやらせておくぐらいでいけるかも。
最近やっと感覚になってきたので、てなるとワークツリー、いわゆるIDEに常に表示させておく前提じゃない作業進捗の作り方ができてきたなみたいな。できそうな気がしてきたぞってなって、ちょっと圭一郎さんのやつ使うかみたいな。
今多分その辺みんな結構色々試してて、もうちょいすると半年とかすると多分こんな感じがいいんじゃないかみたいなのがいっぱい出てくるんだろうけど、今みんなやってて、社内でもPHPストームがファイル変更されるたびに色々読み込みをやって2つ立ち上げてると、それでメモリーが圧迫されてPCが遅くなるみたいなこと言ってる人もいたし、
あと結局テスト書いて走らせてとかってやると、コンテナの中にあるとコンテナ複数必要だよね。じゃあもう1個コンテナを立ち上げようってやると、いやポートが被りますねみたいな。だから動的にポートを振り分けないといけないよねとかしないとロードコードが2列走ってると、これ使われてますね。まず殺しますねって言ってお互いポートを奪い合うみたいなことが起きる。
そう、ことが起きたりとかしてて。じゃあコンテナユース使おうねとか、多分その辺のワークフローみたいなものをみんな今試してて、もうちょいしたら決定盤ではないけど、一旦こんな感じが良さそうみたいな。徐々に徐々に溜まってくるんだろうなって思いながら、自分も今色々試しながら、じゃあ4タスクあったら1つはもうコード書かせて、あと3つは調査っていうかプランファイル作ってもらうっていうところをやっとこうねとかして、裏でプランファイル作ってもらうっていうところをやっとこうねとかして、裏でプランファイル作ってもらうっていうところをやっとこうねとかして、
それぞれOKだねってなったら、それやってる間に大体手元の作業が終わるんで、終わったらコミットしてプッシュしてやってねって依頼してプルリクエスト作ってねってやっておいて、それが終わったら次のさっきプランファイル作ってたやつを、じゃあ次はこっち対応してとかっていう風にやったりしてますね。
うん、僕も並列作業をするときにはすごいテッキーというかダーティーというか変なマネジメントしてるんですけど、うかつにPHPユニットのテストを実行させるとデータベースは所有してるので、データベースコンテナを毎回立ち上げたくなさすぎて、何個も増やしたくなさすぎて、なのでタスクAとタスクB並列でやるときは片方はデータベース触らないタスクやらせるか、
お前はテストを自動でやるなっていう風にしておいて、片方のメインで面倒見てるところはもうガンガンやるみたいな。あとPHPスタムやたら広いスコープで実行してくるので、なんかCPUの状態チェックしてプロセス使えるだけ使ってくるんですよね、それが2つ実行されると最悪クラッシュするので、ちょっとそれも待ってねみたいなやってますね。
いや、しかもこれがリポジトリのサイズがでかくなればなるほど大変になってくるんですよね、きっと。
だからあれなんだよな、なんかZbrainsのIDE使ってる前提ではあるので個人的には。デーモンというかLSPサーバーとしてPHPストームがPHPスタムの実行結果を返すようにしてくれればいいんだけどなーって思いながら、多分そこのツールが入ってなかった気がするので入ってんのかなどうなんだろう
プロのプログラマーの責任
まあとかね、なんか細かい話はありますけど、とりあえずできそうなことに対して今のワークフローとそれを支える関東整備が整ってないなーっていうのを明確にちょっと自分の中で課題になってきた。
はい、じゃあまた次のエピソードじゃないか、一斉に行こうかなと思いますけど、どれがいいですか、なんかありますかゲイさん。
自分はこれはちょっと今回のやつで取り上げたいなーと思ってたやつが、プロのプログラマーとはっていうやつですね。で、著者がロバートシーマーチンって書いてありますね。
で、どこでしたっけ、あ、64ですね、きりがいい。
で、自分がこれを読んでいくつかいいなーと思ったのがあって、4つあるんですけど、たぶん全部が6つぐらいだった気がするんだけど、うち4ついいなーって言ってて。
まあ1個目がキャリアに責任を持つというのは自分の力で自分の価値を高め成長していくということです。自分の意思で新たな知識と技術を習得し、次に最先端にいられる努力をするのです。
っていうのが1個目で、ちょっと4つ全部言っちゃいますね。で、2個目がプロのプログラマーは自分の書いたコードに責任を持ちます。間違いなく正しく動くと確認できるまでリリースをしません。
で、3つ目がプロのプログラマーはチームプレイヤーです。一人一人が自分の仕事だけでなくチーム全体のアウトプットに責任を持ちます。
で、4つ目がプロのプログラマーは絶対に間に合わせのいい加減な仕事はしません。っていうこの4つの言葉すごいいいなと思って、ちょっとこれ話したいなと思いましたね。
ちなみに全部で5つあるんで、今取り上げたのが4つなんで、1個だけね。
コードの品質とチームワーク
これ、そうですね、さっきチラッと署名言及したクリーンクラフトマンシップも、タイトルの通りというか、同じような目線の話をしてたなって思いながら今聞いてましたね。
いやあ、耳が痛いなあ。
全体的に、たぶん最初に読んだ、2014年に読んだとき、こう読んで、ああこれそうだよね、大事だよねって思ってた2年目の自分と、もう順に当たれた自分では、同じ言葉なんだけど、全然その重みというか、それがどれだけ大変なことかみたいなのを、今もう1回読むと実感できて、
いやあ、なんか、やっぱ大事だよなあ、本当にみたいな気持ちになりますね。
なんかね、元気なときに読んだらそんなに、そうだねわかるぞで済むかもしれないんですけど、なかなかこう調子が落ちてるときに読むと、うううごめんなさいってなりそうだな。
レッドラインが決まってるさ、もうちょっと来週にはリリースしないといけないんだよねっていう状態で、不具合が見つかっていて、みたいな状態でこれ読むと、すいませんみたいな気持ちになるような感じになりますね。
これでもタリアに責任を持つというのは、あのところだけ少し毛色が違う感じしますね。 確かに。なんか取り組むその対象のものではなく、もうちょいその取り組んでる自分自身っていう話ですもんね。
まあある種雇ってくれてる人、会社とか組織に対する責任っていうのが、例えば自分の書いたコードに責任を持ちますとか、自分の仕事だけじゃなくてチーム全体のアウトプットに責任を持ちますとか、間に合わせのいい加減な仕事はしませんっていうのが、
そうか、ここの3つはアウトプットに関することなのか。で、タリアに責任を持つっていうのはちょっと違いますもんね。これも会社がやってくれないとか、チームのせいでみたいな言い訳をするなっていうのは全部に通じてると思うんですけど。
間に合わせの仕事をしないとか、自分の書いたコードに責任を持つためにとか、いろんなアウトプットだったりするものに対して責任を持つためにはこういうことをやっていかないとダメですよっていう中で、それはやっぱ自分で学習をしてとか自分の価値を高めるとか成長していくとか、そういうことをちゃんと取り組みましょうねっていうことを言ってくれてますよね。
そうですよね。まあそれこそクラウドネイティブ前世の時代になってたけどクラウドっぽいやり方知りませんとかだと、それはもう会社とか雇用側に対して責任を果たせなくなるので、っていう意味だと間に合わせのいい加減な仕事をしてるのに近いじゃないですか。
そういう意味では全然通ずるものがあるんですけど、今日の仕事で何を書きましたかっていうのがさっきの3つなのに対して、明日もちゃんとやれんのかいが1個目な気がするな。
これだが、しかも今AIとかLFの話をさっきまでしてましたけど、そうやって時代の転換期にいる中で、今までと同じやり方が通用するかっていうより多分通用しなくなっていく。通用するんだけども、求められるスピード感とかアウトプットの量だったりとか、
一人が考えないといけない対象の広さみたいなものが多分今後変わっていくっていうことを考えた時に、大変な仕事だな、大変じゃない仕事なんてやんのかっていう話でもあるんですけど。
クラウドの時代がやってきて、クラウドに話がわかんない奴ダメだよねって言ってた人が、AIの話がついていくの大変ですってなっちゃったら、それ10年前にある種馬鹿にしてた人と同じことになってるんだよってことになっちゃうわけで。
大変な仕事です、大変な領域、職業だなと思いつつ、ただAIによって一番楽させてもらってる職業でも間違いなくありますからね。
最近の仕事はターミナルでAIさんがちゃんと頑張ってる顔を見る仕事をしてる気がするなって若干思いつつあって。楽になったけど、楽になったなって思ってるけど、たぶん半年後にずっと同じこと続けてられるわけじゃないだから、楽になった分もっとお前他のこと頑張るよって言われるんだろうなと思うと、
じゃあそれをやりながら何ができるんだっけってことを考えておかないと、自分のキャリアだったりとかってことを長い期間で見た時に、じゃあ今自分は何やるべきなんだっけとか、そういうことまで考えないといけないなーって思ったりしますね。
たしかに半年前とそのさらに半年前だと全然やってること違うからな。
そうですね、なんかタブを押したら勝手にやってくれるハッピーとか言ってた時代あったなって思いますもんね。
タブを押して気持ちいい時代があれなんですよ、PHPストームにあんまり来なかったんで、僕それも撮ってないんですよ。
そうか。テストコードとかね、ちょっと書いたら全部タブを押したらこうやってくれてたんですけどね、GitHubコパイロとか。で、もちろん今もね、それは自分がこうやってるけど、
でも全体の量から言ったら全然生成されてる、ターミナルで指示出して生成されてることの方が多いんで、もうちょっと話変わってきたなってなってますねやっぱり。
そうですね。
でもこういうのは変わってきてるけど、逆に変わってない部分っていうと、ちゃんと約束を守りましょうとか、自分が作ってるものに責任を持つ、これはAIがやったんでっていう言い訳は別にまだできないので、
その動作確認だったりとか、書いてるコードの品質、保守性みたいなところっていうのは、ちゃんと考えないといけないよっていうのは、全然変わってないよなっていうふうにも考えられますね。
AIとプログラミングの未来
どうやって責任を取るというか、どうやって自信を持ちますかっていうスタイルは変わってくる気がしますよね。こういうふうにできたから大丈夫です、のための手段として、今までだったら人間が書いた速度、人間がコードを書く速度っていうのがボトルネックになってる時代。
人間しかコードを書かないから、人間がコードを書くスピードがボトルネックになってる時代だったら、コードレビューで一乗一乗読んだり、コードレビューで一乗一乗読んでも別に正しさは何もわかんないんですけど、そのぐらいの粒度での細かいチェックっていうのを前提にしてたところが、1時間で3000乗とか普通に書けるわけじゃないですか。
1時間フルでエアにやらせてたら3000乗なんて済まないので、ミドルウェア1個ぐらい作れるからないとしたら、指示さえあれば。っていう中で今までと同じやり方してたら、やっぱりコードレビューがボトルネックになってくるかもねっていうのは言われてるので、
じゃあなんか違うテスティング手法を考えた方がいいよねとか、その代わりコードユニットテストか、それより小さいミクロのレベルのチェックっていうのは不要になってくるかもねーとか、
あといかに持続的に保守し続けられるか回収を加えられるかっていう目線で言うと、人間だったら変数名の1個1個まで見ないとちょっと認知不可が爆発するぜーだったのが、そこまで気にしなくていいけどってなるかもねーとか、
なってくるかもしれないので、だから責任の取り方というか、何を持って責任、自信を持ってますかっていうのが変わりそうだなーっていう気はするけど、ただ責任をちゃんと取れるのがプロであるっていう定義は変わらんそうだなーっていう気はするので、そこの難しさはありそうだなーって感じました。
そうですね。スピードは上がったけど、あとはその、ある種その、保守できるとか、不具合が少ないとかっていうガードレールをAIに対してどうやって敷いていくかみたいなところは、なんか一個すごい考えていくんだろうなーとか、あとはデータベースの設計をどれくらいAIに任せられるのかみたいなところも多分あるだろうし。
変えにくい部分のところをAIに言われた通りにはいはいやってると、後でこうしたいんだけどって言われたときに、AIも変更するためにすごい手活をかけるっていうことが発生するだろうし、それが起きるってことは、もちろん人間よりは早くできるかもしれないけども、今度AIとAIの中で競争したときには柔軟さが足りないよねーとか、
データベースのリファクター化するために、じゃあAIを使って2週間かけて、本番に適応するっていうことも含め2週間かけてやりますよってやってる間に競合はもっと速いスピードでプロダクトを出してくるって考えたときには、いくらAIを使ってるからといってもその使い方によってそういう差が出てくるよねっていう部分もあるってことを考えると、なんかこうデータベースとかってどれくらいAIに任せるのか、アシストはしてもらうけどやっぱ最後は人間で、
がもうちょいこう理解できる範囲で考えないといけないよねーとかいうのあったりするのかなみたいな、逆にコードはインプットとアウトプットが合ってれば何でもいいよって言えれば捨てやすくなるかもしれないなとか。
データベースの変更の頻度がそんなに高くない、毎日オルターテーブルかけるとかじゃなければある程度まだ我慢できるかもしれない、そこは人間がやろうぜっていうことで、アプリケーションだと1時間に何秒も何十秒も変わってくる
その変更頻度が高いところは5%でも10%でもやっぱり効率化していくと効果が高いよねっていう中で100%とか1000%とか効率化できる手段があるんだからそれはやろうよなんですけど、データベースのパフォーマンスとかの観点だったらいくらでも担保してくれそうな気がしますけど
どういうことに対して拡張性が必要なのかとか考慮しておかないといけないのかっていうのは多分人間が考えとかないと、コンテキストとしては仕掛けないとAIも多分無理だと思うんで
そうですね、真似できるものがないと弱いですからね、というかアプリケーションとかでもすごいドメインが明確に定義、ドメインモデルが定義されてますとか、レイヤーがちゃんと一貫性を持ってパターン化されて適切にデザインされてますってなると
要するにここの構造とか実装を真似してこれを作ってね、差分がここだよ、こういう要求の違いがあるよっていう風に言ってあげるとだいぶなんかいい感じなコードをアートプットしてくれるとかはあるんで、今からデータベースのテーブル定義しましょうってなるとやっぱりその見本というか元ネタがない質問だいたい
そう、でだいたいあとその要求ってものはプロダクトを触った後からやってきて、人間も予期してない変更とか、その市場環境が変わることによってこう要求が変わるっていうことがあるんで、みんなが予見してるわけじゃないっていうところがまた厄介ですよね
プログラマーの挑戦と経験
そうですね、だからあれじゃないですか、一旦スキーマレスでMongoDBとかで作らせて、である程度よしじゃあこれはちゃんとプロダクトとして提供するかってなったら、マイグレーションの計画をAIに立てさせて
それをでも言ってるスタートアップとか知り合いでやってるのですごいですよね、やっぱりやれるんだろうなって気持ちと、でもスタートアップだとそういう先例が取れるけど、もう10年20年続いているプロダクトでいろんな制約条件あるとまた難しかったりするよなとかったりして
3Xモデルがここで 安定運用の時代に入ってしまったらなかなか難しいとかありますね、だからそうなった時にじゃあどこまでを責任持って保守できる変更できる状態に置いておくかっていうのを人間側が考えるってことはやらないといけない
そこの経験の積み方ですよね、どうやるんだろうっていうのがある
今それをみんな試してるタイミングでもあるし、捨てやすく作っておくっていうのがいいんだろうなって気はしますけど、そこの捨てやすさみたいなところの共通認識を揃えるっていうのもまた大変だから
俺なら捨てられるぜの差がだいぶありますからね
あとは例えばインターフェースが安定化していれば多分その境界を越えた部分は捨てやすいと思うんですよね、これだけ守っておけばいいよっていうところがわかると
でも多分世の中いろんなソースコードを見てるとインターフェースがすごく具体なインターフェースだと具体が変わってしまうんで、つまりインターフェースが安定してないことによってちょっと変えようとすると辛くなっていく
でも抽象度がそれなりにちょうどいい感じになってると多分捨てやすくなっていくったり変更を加えやすくなったりするんだろうけど
その安定性をどうやって安定してるかってことを見つけるかっていうのがまた難しくて、それは多分経験的なものもそうだし具体と抽象の往復が上手にできるかどうかもあるし
この辺はやっぱ経験を積むしかないんだよなって思いながら最近ずっと思ってますね
コードが捨てやすくなってたとして捨てていいクラルカはまた別だったりしますからね、捨てやすさは大前提大事なんですけど
そこの捨てたいんじゃなくてそこの中身変えたいんですよが結局発生すると、それは縁が切れなかったなってなっちゃう
コード生成の速度と複雑性
だからここのプロのプログラマーとはみたいなところは抽象的な話をしてるからっていうのはあるんですけど、ここはあんまり古びなさそうですよね
そうですねそうですね、もしかしたらチームプレイみたいなところのチームサイズが小さくなっていくねとか
なんなら一人チームでプロダクトをどんどん作っていくねみたいなことが起きたらまたちょっと変わるかもしれないけど
まあサイズが小さくなるからといってそれぐらいの会社規模とかで働いてたら一人で全部やりますは多分まだないと思うので
昔は10人でやってたよねが5人になったよねとか5人でやってたのが3人になったよねとかっていうことは起きるだろうけど
チームでやるってことにはあんま変わりはないかなーっていう気がしますね
そうですね、まあなんか人いらなくなったからチーム減らそうぜにはなりづらいというか限界まで働かせると思うんで
プロダクトとかプロジェクト作ると思うんで、チームのサイズは小さくなるかそれでも
でも組織のサイズは結局
変わらないというか組織のサイズが変わってないのにパスが増えてるんだから複雑度が上がってますよそれは
で、どうせ5人チームだったのに分割したってことは兼任が発生するでしょみたいな匂いもするし
そうそうそう、そういう事例が増えていくんだろうなって
AIのおかげでチームは倍になったのにアウトプットが倍にもならずアウトカムも倍になりませんでしたって
なんでこうなったんでしょうねって言ってるんだろうな
アウトカムがそんなに変わってないこともあるだろうしアウトプットも思ったより増えてないことはあるんでしょうけど
ただいかんせんAIのおかげでコードを書くのが早くなったって言ってる上では
生み出されるコードの数量は増えてるので
すごいですよね、トータルの組織サイズが変わってないけどチームが分割されるパスが増えて複雑化してる
うまく売上につながってないけど生み出されるコードは増えてる
そらそこも複雑性が上がってるよねってなるんで
いやーヒリヒリしますね
いやー無駄なもの作らない方がいいと思うんだよな
いやーでも本当それはそうなんだよっていう
ただ何が無駄かを見極められないから作るしかないので
そうなんですよ
アウトカム大事なのはわかるんだけどそれは最低限のアウトプットの基礎体力ないとそもそも戦えないからなってなりますからね
アウトプットゼロだとアウトカム基本ゼロになるはずなんでね
そうですねアウトカムの期待値が100でアウトプット能力がゼロで尺掛けゼロの結果が出ました
うーん
というプロのプログラマーとはというエッセイです
じゃあまた次行きますか
