私はソフトウェアエンジニアではない
(huronbikes.mataroa.blog)- ソフトウェアエンジニアというアイデンティティの拒否は、23年前に「優れたハッカーだがエンジニアではない」という評価を受けたことから始まった
- エージェント・パラダイムは、決定的であるべきプログラムを非決定的なプログラムで作るやり方のように感じられる
- コードに対する信念は、可読性、理解可能性、効率性、推論可能性、同じ入力に同じ出力を返す再現性にある
- 職場の agentic user flows とAI利用KPIは、良いコードよりも指標と自然言語入力を前面に出すやり方として受け止められる
- AI業界の未来像は、ソフトウェア開発の代替を超えて、思考そのものに堀を巡らせようとする想像として映る
ソフトウェアエンジニアリングとエージェント・パラダイム
- ソフトウェアエンジニアというアイデンティティから自分を外す姿勢は、23年前に同僚から「優れたハッカー」だがエンジニアではないと言われた経験に始まる
- 最近の「新しい エージェント・パラダイム」は、Waylon Smithers のような機械にミスをするなと頼み、その結果を専門的なソフトウェアエンジニアリングとして包み直すやり方のように見える
- 非決定的な出力を返すプログラムで、決定的であるべきプログラムを書くやり方が、ソフトウェアエンジニアリングの未来として提示されている
- コードに対する基本的な信念は、依然として 可読性、理解可能性、効率性、十分な推論可能性、同じ入力に同じ出力を返す再現性にある
- 実際のシステムでは再現性を保つこと自体がすでに難しいため、コードを書くという行為そのものが「動く砂」の上に築かれてはならない
- 結合されたサブクエリと集約式で構成されたビューが クエリ性能 に与える影響、制御の反転（Inversion-of-Control）、機能をメソッドから切り離して独立してテスト可能にする設計といった細部は、今もなお重要である
AI中心の開発フローへの不信
- 職場で求められる agentic user flows は意味が明確でなく、自然言語入力テキストボックスが小さな選択肢の集合から選ぶ方式より、なぜ優れているのかも納得しがたい
- ソフトウェア開発ライフサイクルのあらゆる段階でエージェントを使おうとする動きがあり、手でコードを書くことは COBOL を書くことのように扱われるだろうとも言われている
- エージェントは、文脈に応じて出力を評価するLLMプロンプトのラッパーのように見え、実際の出力はしばしば不十分に感じられる
- AI利用量が KPI として追跡されているが、この23年間でKPIよりも良いコードを書くことのほうが重要だった
- 以前に書いたコードが「数学専攻の人が書いたようだ」と評され、それを高い賛辞として受け止めた
- 同じ職場のあるスタッフ・ソフトウェアエンジニアの実装には明示的なインターフェースがなく、DIコンテナを public static メンバーとして公開し、表形式データに適しているからではなく「ビジネスユーザーが使いやすい」という理由でCSV設定を使っていた
- その実装を非常にひどいと言ったことで問題になり、この出来事は、自分はソフトウェアエンジニアではないという皮肉な結論へとつながった
- 自分が賢いと思っている人から、AIはソフトウェアを書くことと業界の未来なのだから受け入れるべきだという助言を二度受けたが、その態度は不用意に見える
- 使ってみた AIソフトウェア は、思考の過程を助けるというより妨げたり積極的に奪ったりするように感じられ、そうした取り込み（co-option）が懸念される
- 大手AI企業のリーダーたちは、ソフトウェア開発業界の未来を楽しげに語り、自社製品が雇用に devastating effects を与えると発表し、"intelligence too cheap to meter" という表現を使う
- その未来が恐ろしいのは、機械が皆を紙クリップに変えてしまうからではなく、彼らが 思考そのものに堀 を巡らせることを想像しているからだ
1件のコメント
Lobste.rsの意見
Mary WaltonのW. Edwards Deming本にこんな逸話が出てくる。ある工場労働者が機械の故障で不良品しか出なくなり、報告はしたものの整備が遅れたため自分で直そうとしたところ、監督が来てそのまま回せと言ったらしい
結局それは「不良品を作れ」という指示であり、彼は「自分の作業者としての誇りはどこにあるんだ？ 監督が機械に向けるのと同じくらいでも自分を尊重してくれたらましなのに」と言ったという。彼は不良品を作って金をもらいたくなかったのだ
読む価値ある？
筆者よりはるかに経験は浅いが、キャリア初期にCSVのさまざまな問題のせいで、業務フローの一部をCSVから離してみようとしたことがあり、そのとき「ビジネスの業務フローではCSVのほうが簡単だ」という返答を受けた
当時は筆者と同じようにその答えをかなりひどいと感じたが、時間がたつにつれて、その判断のほうが正しかったのに近いと思うようになった
「23年前に誰かがソフトウェアエンジニアじゃないと言った」みたいなばかげた意見にいまだに悩まされているなら、解決策は他人の意見をそこまで気にしないことだと思う
雇用主の愚かな方針や同僚の誠実さの欠如にうんざりしているなら、別の会社を探せばいい。世界には80億人いて、その多くがコンピュータに何かをやってほしいと思っており、そのまた多くがプログラミングの費用を払う
「最初にパン屋で働いたとき、同僚がクロワッサンはバターをもっと売るためのBig Dairyの陰謀だと言ったので、それを世界観の土台にして、もう二度とパン屋では働けないと結論づけた」と言っているように聞こえる。筆者の年齢が書かれていなければ高校生くらいかと思っただろうが、23年前のことを語れるなら、もうとっくにそういう年齢は過ぎているはずだ
要点は、筆者が実際にはソフトウェアエンジニアではないということではなく、おそらく長いあいだそういう肩書きで働いてきたということだ。要するに、その肩書きから自分を切り離す態度は、この業界が変わってしまった姿への反応に近い
「これはエンジニアリングじゃなくてでたらめだ。ソフトウェアエンジニアであることがこういう意味なら、自分はそれではない」と言っているようなものだ
個人的にはその感情に共感する。自分たちがソフトウェア開発者としてやっていることを「エンジニアリング」と呼ぶのは、他の工学分野への侮辱のように感じられたことが何度もある。特に、そう呼んでおきながら、実際に自分たちが作っているものにはあまり関心を払っていないからだ
土木エンジニアは橋が崩落するような事態を本当に深刻に受け止め、大きな崩壊が起きれば業界全体が反応し、学び、二度と同じことが起きないようにしようとする。一方、いわゆるソフトウェア「エンジニア」は、完全に防げたはずの理由で本番環境を何度も障害にしても、それを履歴書の成功談のように書けてしまう
今のソフトウェアエンジニアリングの流れ、つまり実際にデプロイするコードを気にせず、その作成を別の「知能」に委ねる傾向について自分がどう考えているかも、想像がつくだろう
なぜこんなことが起きるのかは理解しているし、どうすべきかについてすべての答えを持っていると言いたいわけでもない。ただ、これを真面目な仕事、つまり「エンジニアリング」だと装うべきではない