こんにちはAGI未満です。
みなさんスクラムしてましたか？AIしてましたか？
AI時代でプログラミングは完全に形を変えつつあります。
プログラミングという最も重要な作業が質と量の両面で変革を遂げたいま、開発手法についても色々と考え直すときが来たのではないかと考えている人は多いでしょう。少なくとも多少なりとも業界でキャリアを積んだ人間であればチームでの開発業務にいままでのやり方を当てはめるのが難しくなっているのは感じているとおもいます。
今回はそんな開発手法の中でも名前だけは有名なスクラムがこれからどうあるべきか、あるいはそもそもAI時代のマネジメント手法としてフィットするのか？などを考えていきましょう。
というわけで今回は見積もりについてです。
続きを読む2025年の4月頭に育休に入り、2026年の4月に復帰しました。
気がついたらもう先月のはなしっすねw
まあとにかく口を開けばAIはすごい（実際すごいが）からの
「いまのうちに使いこなして周りと差をつけないと危ない」
「おれは一晩中LLMを動かしてコーディングさせてます*1」
ばっかり。
僕の個人的予想では
だったので、一応センスよさそうな人たちだけフォローして情報だけ小耳に入れつつマジで一度もClaudeCodeもVSCodeも開かないで一年子育てしてた。
というかまあ、そんな時間の余裕はなかった。
ガチで一切問題ない。
もちろんClaudeCodeというツールの使い方のキャッチアップは必要だった。
どういうツールなのか？
設定ファイルは？
commandsってのを使えばいいのね……えっ、いまはもうskills？これ古い情報か〜
やらなんやら、そういうのはあったけどそんなもんエディタの乗り換えと大差ない作業で、AIの進歩云々は関係ない。
Reactが出た時に近い感覚かな、ドキュメントを読まなくても大体どう動くかわかるあの感じ。
ClaudeCodeがやろうとしていること、やってくれること、全てが僕の予想通りで一切の驚きがない……ということが驚き。
僕の予想ではこのレベルになるのは正しいコンセプトをもった会社が上手に活動してあと2-3年先だったので、去年の僕の想像はだいぶ保守的だったらしい。
一ヶ月ほど使っていて不思議におもっていることがひとつある。
情報収集のために色々とブログ読んでて感じるんだけど世間の人たちは「ClaudeCodeを使いこなそう」としすぎなんじゃあないだろうか？
純粋な技術的タスクならともかく、ある程度のベテランプログラマーであれば業務における開発のボトルネックってそもそもプログラミング速度ではないことが多い。
仕様を極限まで削るアートだったり、ビジネス側との折衝、コードレビューやリリース関係の作業みたいな会社ごとに存在するアレコレ。
だいたいClaudeCodeとはあまり関係ない（あるいはAIを組み込むことでいままで人が噛んでいた部分の自動化は可能になるかもしれないけど）レイヤーばかり。
その上でなんかこう、ガチャガチャとClaudeCodeに思い通りのコードを書かせるための方法論みたいなものが幅をきかせている（ようにみえる）。
一年前からタイムスリップしてきたから逆にわからないんだけど、恐らくは古いLLMにコードを書かせるためのバッドノウハウが脳裏にこびりついているんだろうか？
勝手に断言したいんだけど、詳細なCLAUDE.mdとか、仕様書駆動とか、プロンプトの駆動とかそういうのって中規模程度の機能開発ならマジで不要。
必要なのは受け入れ要件を固めること、MVPを定めること……みたいな古来からのアジャイルと大差ない作業。
既存のコードがよほど酷くない限りはコーディングの細かい指示も一切不要（LLMは空気を読むのが仕事なので既存のコードがひどいとそれに引っ張られることには注意）。
TypeScriptであれば僕と書くのと大差ないレベルのコードを一発で書き上げてくる。いまのモデルは型パズルすら解けるようになってる。
JTCがやるような「詳細設計書」をClaudeに渡すのは本当に悪手中の悪手だとおもう。
「いやまともなエンジニアならこの要件から類推できるっしょ」っていうものはいちいちうるさく言わずにまかせればよい。むしろそういうマイクロマネジメントすればするほど指示に紛れ込む矛盾が精度を落とす。
とにかく要件を削ぎ落とし、矛盾を排除すればよい。
そうすればかなり大きな規模のプロジェクトでもプロンプト一つで動くものが出てくる。あまりにもデカい機能だと難しいかもしれないけど、正直いまのClaudeが一発で作れないような機能を一つのリリースでやろうとすることそれ自体がミスなんじゃないかな。
要件のスリム化が足りてない。
去年のLLMは「アルゴリズム実装にだけやたらと特化した新入社員」って感じだったけど、いまのモデルたちは総じて「先週参加してくれたばかりのベテランエンジニア」みたいな風格がある。
であれば細かい指示は不要な反面、プロジェクトに残るノイズとかだけ丁寧に拾って教えてあげればよい。
まあだいたいそんな感じ。
上で述べたことは間違っているかもしれない。僕の世界観がまだ牧歌的すぎる可能性はある。
先端の速度感を出すにはAIをビシバシしごいて全自動化する必要があるのかもしれん。少なくともいまの僕はこう感じましたというお話。
以上。
*1:一年前のLLMってクソポンコツのゴミコードしか書けなかったけど、そんなやつに一晩かかるようなデッッッッカイタスク振ってた人たちの存在は今でも謎
こちらで試せます。
それなりのスペック、かつWebGPUが有効なブラウザで開くことをおすすめします。
つまりフロントエンドがやってきたことは
これだ。
いうは易しで、「事前に決めたユーザーの要望」っていうのをまともにできる人間は5%にも満たないから美味しいご飯を食べていられたわけだ。あとまぁJSONに色をつけられる人間も少なかった。
時は流れ2026年、小型のLLMが超発達を遂げており、中にはブラウザ上で動くものまで出てきた。
俺らの仕事はもう、ない。（あります）
これからの時代、UIはもういらなくなる。たぶん。
必要なものは要件のみ。
UIはAIが出す。
クエリもAIが発行する。
集計もAIが。
ビジュアライゼーションもAIがやるんだ。
たぶん。
web-llmを使い、適当な軽量LLM（今回はqwen3.5 smallを選択）をロードします。
サーバーはモックであり、ブラウザ上で完結しているためデータが外に漏れることはありません。プロンプトインジェクションされても漏れるデータはありません。そもそもそんな賢くありません。
今回は真面目にやってるけど、全てを度外視してevalを濫用すればあらゆるものが柔軟に表示できますよ（良い子は真似しないでね）。
あるいはServiceWorkerからRSCみたいにある程度ルールで縛ったコンポーネントを返すのでもいいかもしれない。
いうて小型モデルだからまともなGraphQLやJSON吐ければ御の字やね
動くやん！！！！！！！！！！！
なお動きは遅い
今回試してみて、全てのフロントエンドを消滅させる計画には程遠いけど、ネタ企画と切り捨てるには惜しいキラメキを感じた。
このデモのように、用途や渡すスキーマを絞って活用する分には面白い用途がでてくるのではないか？
GraphQLや可視化がある種のハーネスとして機能しており、2B程度の小規模モデルが驚くほど賢く働いてくれる。
いまやってるようなことはChatGPTやClaudeにやらせればもっと大規模で賢くて無限に柔軟なものができる。
でもやらない、金が死ぬほどかかるからだ。
その金で要件を固めてアプリをリリースしたほうが安い。
そもそもユーザーが見てるデータを全部サーバーに投げまくるのは色んな観点であまりにも危険すぎる。
しかしエッジLLMはファッキン無料。
しかもプライバシーも完璧。
みんな大規模モデルの進化にだけ注目しがちだけど、UXを変えるのはエッジで動く小型省電力モデルの進歩だと僕は最初からずっとおもっており、少なくともQwen3.5 smallはその目論見に可能性の光をみせてくれた。
ServiceWorkerを使ってくれとか、Svelteでとか、サーバーはin memoryモックでとか、そういうコンセプトの指示だけしてあとはほぼClaudeCodeに任せたぜ！
自然言語から集計や可視化への繋ぎはDSL構築でやるのがいいだろうなーとおもいつつあえて黙ってたんだけど、ちゃんとDSLを描き始めたのでほんとにえらい。去年のゴミみたいなAIとは別レベルにプログラミングがうまい。
しかしリポジトリのログをみると結構苦労してるのがわかる。
でもいい感じに声かけしつつ軌道修正してあげるとあっという間に解決するのでかわいいね。
最初はGemma2で試し、Qwen3.5に移行したりする中でモデルごとの出力の癖で失敗することがあった。
試す人がいるかどうかは知らないけどアプリに組み込むならモデルは絞っておくといいだろう。
AIと壁打ちする限りまだまだ改善の余地はあり、なかなか面白い実験になったかなとおもう。
おはようございます。オッサンです。
よく「ドリップ技術」なんて言われますが、コーヒーのドリップは豆の品質がほとんどです。
「ドリップ技術」なんていいますが、美味しい豆を使うのが全てです。
その場のノリで文章を書いているのでだいぶとっちらかった文章になってますね。同じことを2度書いてます。
大事なことだから2度書いたんだとおもいます。
ワタシの文章はいつだってAIフリー、推敲もそこそこに投稿ボタンポチー
とにかく美味しいコーヒーには一にも二にも豆の品質です。
はてブのコメントにも「いや、豆の品質が一番大事だからw」的なコメントが沢山ついてました。だからそう書いてるやろがい！！！！（とても鋭い視点です！本当にその通りです参考になりました！）。
豆の品質がまず前提にあり、それを損なわない、あるいは良さを引き出すための道具立ての話が↑の記事にあたるわけです。
特に大事なのはコーヒースケールです。
コーヒーなんてもんは嗜好品なので、他人のレシピで淹れてみて「薄いな」とおもったら豆の量を増やすなりお湯のタイミングを変えるなりして調整する必要があります。
スケールがないと調整もままなりません。
スケールとタイマーがあって、初めて自分の好みに合った濃度と粒度の調整が可能になるわけです。
長年住んできた東京を離れて札幌に引っ越してはや6年……だか5年だかそこら辺くらいです。
ちなみに東京に住んでた頃の私の認識は「自家用車とか壮大な金の無駄じゃん。必要になるたびタクシー呼んだほうがトータルで安いww」でした対戦よろしくお願いいたします。
本日のテーマはこちらです。
「東京の人は『田舎に住むとねえ〜、やっぱ車が必須になってくるでしょ？それはちょっと世間は許してくれませんよ』って言うけど完全に間違いだった件 〜地方移住で快適な自家用車ライフを過ごすことに決めた〜」
です。
その前に確認したいことがある。東京以外 = 地方 = 田舎 = 車が必須とかいう雑すぎる認識持っていないか？もっているなら改めよう。
率直に言って、地方都市の人で「生活には車が必須だから仕方なく買ってるんだよね……」なんて人はいない。運転嫌いな人は車買わなくても生活できるし。
どちらかといえば「東京で暮らすと車持つの無理なんじゃない？」といって嫌そうな顔をする。
いまは東京でフェラーリを6台持つようなクソ金持ちの話はしてないからな。
