「ソフトウェア工場」はなぜ失敗するのか？エンジニアリングだけでは足りない理由

「ソフトウェア工場」というメタファーは、一見効率的に思えますが、現実には多くのプロジェクトがこの罠に陥り失敗しています。単なる「ハーネス（自動化の仕組み）」の構築だけでは、真の生産性向上や価値創出には不十分です。ソフトウェア開発は単純な製造ラインではなく、絶え間ない適応と創造性が求められるプロセスであるという事実を再認識する必要があります。なぜ「工場モデル」が現場と噛み合わないのか、その本質的な乖離について深掘りします。

これは今まで見た中でも最高の解説記事の一つだよ。モデルの制約の多くは、結局のところどうやってRL（強化学習）されているかに帰結するんだ。みんながモデルの学習レベル（あるいはデータラベリングの工程）について少しでも理解していれば、ネット上の議論はずっと建設的になるはずなんだけどね。

今の状況で一番引っかかっているのは、PRレビューについてだ。理想の世界では、PRは読みやすく、レビューするのも楽しく、議論の内容がしっかり反映されているものだけど、現実を直視しないといけない。そこには限界があるんだよ。最高のチームがどうやってレビューしてるかはわからないけど、正直今のやり方は最悪だと思う。特にUXがね。昔からGithubのPRページが大嫌いだったから、たいていはブランチを落として$EDITORでdiffを開いて確認していた。今の時代、こんなひどいUXを放置している言い訳なんてないはずだ。Linearが（コードレビューを専門にしていないにもかかわらず）出した基本的なPRレビュー機能[0]は、すでにGHのものより優れている。仕組みはシンプルで、小さなモデルにPRを読み込ませて、テーマごとにファイルの変更をグループ化し、コメントを付け、重要度でソートする（スキーマ変更 > openapi spec、といった具合に）。これだけで、レビュー側も依頼側も何もしなくても精神的負荷が激減する。すごく基本的なことだけど、製品として作り込めば、ビジュアルの生成みたいな次のステップも絶対に見えてくるはず。これが間違ったアプローチだと思う理由や、広く使われているもっといいツールがあるなら教えてほしい。あるいは、そもそも着目すべき問題が違うのか、意見を聞きたいな。[0] - https://linear.app/docs/diffs#guides

いいアイデアや指摘もあるけど、この部分には引っかかったよ。「# 試してみたこと、2025年7月に完全に灯りを消した（開発を停止した）」っていうところ。2025年秋から2026年春にかけて、モデルの有用性が劇的に変わったってことは、もう広く認められていることじゃないかな？僕自身、その時期を境にエージェントに機能全体を任せられるようになったし、それ以前は無理だった。その時期以前の「エージェントにできること・できないこと」に関する見解や経験は、現代においては少し関連性が薄いんじゃないかな。記事の中でも数セクション後に「モデルはその後改善されたはずだ」と触れているのに、結局その改善を無視してしまっている。自分の経験とは一致しないんだよね。

最近、LLM駆動の開発や検証を、RFCベースの仕様に基づいた「グランディング」と組み合わせる実験を始めたんだ。これによって、実装中にいちいちLLMを細かく誘導したり、お粗末なプルリクエストのレビューに追われたりする手間を省こうという狙いがある。かなりうまくいっているよ。議論の焦点が「LLMとのコードレビューを通じた不毛なやり取り」から「曖昧さのない（ことを願う）仕様書の記述」に移るからね。ただ一つの欠点は、自分が何をしたいのかを完全に把握していないと機能しないところで、常にそうとは限らないのが悩みの種だ。

「なぜモデルはソフトウェアの保守性を維持できないのか？」という問いに対し、その説明は理由を解明する役割を果たしていない気がする。これはLLMの本質的な弱点なのか？学習プロセスの問題か？よく聞く「ゴミコードだ」という評価が原因か？記事は強化学習（RL）や、悪い設計に対するペナルティがないことについて書いているけれど、それは質問をすり替えているだけじゃないかな。「なら、悪い設計にペナルティを与えるようなRLをやればいいのでは？」という疑問がわく。モデルが今のところ苦手なのは当然だよ。調整されていないモデルは、良い修正には報酬を与え、悪い修正には破棄（改善）を促すような仕組みの中に置かない限り、何をやってもダメなんだ。つまり、問題は「モデルが保守性を扱えないこと」ではなく、「どういう仕組み（ハーネス）があれば保守性を扱えるか」ということだよね。（まあ、ページの最後にある広告の目的はそれなんだろうけど。）

ここには「ソフトウェアを構築する」ということ自体の根本的な問題があると思う。もしGithubのチケットをAIエージェントに丸投げして、自分はビーチでダイキリを飲んでいればいいと考えているなら、結局は抽象化と間接化の塔が積み上がるだけだということに気づくはず。コーディング中には「視点」というものが生まれるんだ。ある時点で人間が、「待てよ…ここでRedisを使うのはどうだ？」「待てよ…必要なデータはすでにAPIから返ってきているぞ」「待てよ…過去1年活動していない顧客はレポートから除外しよう」といった判断を下さなきゃいけない。そういうものだよ。

僕の過激な意見を言うと、LLMはソフトウェア開発にとって有害なんだ。究極の「goto」演算子みたいなものだよ。すべての実際のコードは人間の開発者が書くべきだ。その代わり、LLMは敵対的モードで使うべきだね。つまり、LLMエージェントをエンドユーザーの代わりに使って、バグを見つけるためのQAシナリオを実行させるんだ。

この投稿の内容が自分の経験と一致しすぎていて、自分と同じ現実を生きている人が他にもいるとわかって少し安心したよ。最近よく話題になる「テイスト（センス）」の話を思い出すね。建築の「品質」は、ファッションに正解がないのと同じで、客観的な善悪では測れないのかもしれない。私たちは皆、合理性を機械に譲り渡し、美学を学び始めなきゃいけないような気分だ。歴史的に見ても、自分の最大の苦闘は、いつもほぼ等価な二つの選択肢で迷うことだった。今、LLMを使っていると、実装の過程で自然と生まれるはずの「立ち止まる時間」がないから、この迷いがさらに増えるんだ。明確な客観基準がないトレードオフの中で、絶えず「テイスト」に基づいた判断を迫られていて、それがFableやGPT-5.6クラスのモデルを使ってもなお必要なコードレビューと同じくらい疲弊する。多くの場合、エージェント以前にジュニアエンジニアのコードをレビューしていたときと同じように、その場で判断を下すことにしている。壊れた窓を見つけたら指摘し、小さな問題ならあえて見過ごして記憶に留め、ある程度溜まったらまとめて対処する、といった具合に。エージェント以前の二つの開発会社を例に挙げると、一方は7人の優秀なエンジニアを雇って密接に連携させる会社で、もう一方は100人の平凡なエンジニアを雇ってモジュールごとに切り分ける会社。今、私たちはエージェントに対しても同じ選択を迫られている。少数のエージェントと密接に協力して設計やレビューを行うか、大量のエージェントを稼働させてYOLO（とりあえずやってみろ）精神で進め、後から自動化で選別するか。僕のテイストは前者の、小さくて高度に連携したチームだ。まあ、僕が正しいかどうかは時間が証明してくれるだろうね。

コードベースの健全化にRLを使うというアイデア、最高だね。それを測定するためのベンチマークも！例えば「MaintainabilityBench」なんてどうだろう。タスク中にコードの重複を見つけて、安易にコピー＆ペーストするのではなくリファクタリングするモデルに報酬を与えるとか。あるいは、新しいアーキテクチャレイヤーの必要性を検知したり、型制約を引き上げて無意味なキャストを不要にしたりね。シナリオならいくらでも思いつくよ。RLで強化すべき要素は数百は確実にあるだろう。『レガシーコード改善ガイド』や『Architecture of Open Source Applications』なんて最高の教材になるはず。悲しいかな、自分の目の前には山のようなレビューが積み上がっていて、実装する時間が全くないんだけどね…

「ダークソフトウェアファクトリー」について語っている人々が、生産性をプルリクエストやコミットの数という単位で議論しているのが面白いね。もしダークソフトウェアファクトリーの方向へ突き進むなら、そのコード単位のことを「bos（bunch of shit：クソの山）」と呼ぶのも時間の問題じゃないかな。