ディスカッション (11件)
「AIを導入すれば仕事が速くなる」と信じている人は多いですが、実際のプロセスが劇的に改善することは稀です。AIは魔法の杖ではなく、既存のワークフローを補強するツールに過ぎません。むしろ、AIを無理に組み込むことで新たなタスクや管理コストが増大するリスクについても考慮すべきです。
一方で、この投稿はクリーンで、私たち技術者が大企業で働いている時に感じたり見たりしていることを的確に説明しているね。投稿者に言いたい、110%同意するよ。みんなにもこの内容を理解してもらいたいね。もう一方で、最近HNや仕事の現場で、もう何十回も同じような話をしてきたような気がするんだ。AIが本当にスピードアップしてくれるという幻想を信じたい経営陣に対し、別のブログ投稿を一つ足したところで、世界がどう動いているかなんて彼らは納得しないだろう。だから今は、彼らのAIプロジェクトが失敗するか、以前のプロジェクトと同じくらいゆっくり進むのを待って、何かを学んでくれることを願うしかないな。
確かにAIはコードを素早く生成できる(それが良いことかは議論の余地があるけど)が、正しいコードを生成しているとは限らない。
いや、コード自体はほとんどの場合正しいよ。もしコードベースをよく知っている人なら、AIによるコードの追加の仕方が気に入らない可能性が高い。どこに追加するか、どう命名するか、どの程度コメントを加えるか、正確にどこに記述するか、といった「作法」があるだろ?AIがそれを正しくやってくれないと、自分みたいな人間はイライラするんだよね。AGENTS.mdに書いてあっても失敗するみたいだし。
人間の開発者にも同じくらい詳細な要件や仕様ドキュメントを与えれば、生産性は劇的に向上するはず。
IT業界に20年近くいるけど、そんなことが起こるとは全く思えない。仮にあったとしても、あまりに稀すぎて議論する価値すらないよ。
LLMが登場した当初、みんな「Facebookのクローンを作って」みたいに言えば済むと思っていたんだろうね。でも今、要件をより正確に伝え、物事をしっかり定義する必要があると気づき始めている。結局、それがソフトウェア開発においてずっとボトルネックだったんだ。
昔働いていた頃、文字通り「データを取ってユーザーに渡して」みたいな要件が来てたよ。何のデータか、どこに保存されているか、どんなフォーマットで返すか、何一つ定義されてない。結局、プロダクトマネージャーと何がしたいのかを突き詰めるために、かなりの時間を費やしていたものさ。
LLMで良い結果を得るには、同じことをする必要がある。曖昧な要件からは、曖昧な結果しか返ってこないんだよ。
この主張はほぼ正しいし、AIでプロセスを高速化するためにどこに焦点を当てるべきかのヒントもくれるね。
例えば、あるプロダクトマネージャーが言ってたんだ。「会議の終わりまでにインタラクティブなプロトタイプができないようなステークホルダーとの会議は、失敗とみなすべきだ」という未来を描いているとね。これは方向性として正しい気がする。
もう一つ予想しているのは、「Vibecoding」がExcel 2.0のようになることだね。インタラクティブなアプリをセルフサービスで構築できる一方で、セキュリティやアクセス制御、ロギング、スケーラビリティなどを担保するために、情シス部門と終わりのない戦いを繰り広げる未来だ。
ただ、歴史的な視点で言えば、革命的な移行期には必ず初期段階で「蒸気馬(Steam Horses)」が生まれるものさ。蒸気機関の発明当初、人々は蒸気で動く馬の形をした機械が馬車を引く未来を想像した。輸送の機能が形から切り離されることを理解したのは、ずっと後のことだったんだ。
もともとMOOC(大規模公開オンライン講座)が典型的な「蒸気馬」的なアイデアだという文脈で、この話を始めたんだけどね。
興味深い二分法があると思う。自分がすでに得意なことに関しては、LLMはそこまで重要じゃない。でも、自分が苦手なことに関しては、状況を劇的に変えるゲームチェンジャーになる。プロジェクトに必要な人員を十分に雇える大企業にとって、この影響は比較的小さい。せいぜい、1人に5人分の仕事を中途半端に押し付けて人件費を削るくらいだろうけど、結果として製品の質は下がる。短期的な利益のために長期的なコストを払うなんて、何を考えてるんだろうね?
でも、小さなスタジオや独立系の開発者にとっては、LLMは大きなゲームチェンジャーだよ。5人分の仕事を中途半端にでもこなせるようになるのは、そういったリソースなしで何とかしようとするより、ずっと大きな飛躍だ。サードパーティの素材に頼ったり、ひどいやり方で強引に埋め合わせたりするよりマシだろ。プログラマーがデザインしたせいでレイアウトが崩壊しているUIや、Dribbbleを真似しようとしてスキル不足で失敗している例を思い浮かべてみて。AIを使えば、突然あらゆるものを上手に模倣できるようになる。それが彼らのやり方なんだろうね。
この記事はAIの影響が開発フェーズにしかないという前提だけど、それは確実に違うね。アイディエーションから法務、ドキュメンテーション、開発、デプロイメントまで、すべてのステップを加速できる。
アイディエーション:アイデアを出し合い、ナレッジベースと照らし合わせ、設計ドキュメントを生成する。ドキュメンテーション:ドキュメントの大部分を生成する。開発:言うまでもない。デプロイメント:デプロイ用マニフェストの作成やテストツール、クラウドプラットフォームの知見など。
すべてのステップがAIでより良く、速く実行できる。すべてではないにせよ、大部分はね。開発でさえそうだ。もちろん仕事の一部は問題を深く理解して解決策を作ることだけど、一部は単なる雑務だ。ボタンの動作が決まっていれば、デザインして配置し、ホバーやプレスの挙動を調整し、バックエンドと繋ぐなんていう作業は、スキップできる雑務だよ。同じ原則がほぼすべてのステップに当てはまるんだ。
これこそが、ソフトウェア開発者が職業の始まりからずっと切望していたものだ:問題の詳細なアウトラインと、最終結果がどうあるべきかの提示。
これがソフトウェア開発を遅らせる原因だ。曖昧でタイトルしかない機能要件が何を意味するのかを解明する作業だよ。
でも、それこそがソフトウェアエンジニアリングそのものだろ!2026年になっても、完璧なソリューションを一発で出せるほど詳細な要件や仕様が得られるなんていう考えは捨てるべきだよ。
自分の経験では、AIのおかげで機能やアイデアのイテレーションははるかに速くなった。今の摩擦の原因は、他チームとのすり合わせや調整にある。プロセスを加速させるには、調整のオーバーヘッドを減らし、個人やチームが意思決定して実行できるように権限を与えるべきだと思うね。
みんな勘違いしてるけど、重要度の高いソフトウェア開発において、コーディングは全体の50%にも満たないよ。コーディング工程は一般的に「最も簡単な」部分で、ジュニア開発者に任されるものだ。大企業におけるプロダクトの変更は、複数のシステムや人間系にまたがっている。シニアやミドルレベルの開発者は、既存のサイバネティックな巨大システムに、どうやってローカルな優先順位を組み込むかを考え、他チームの優先順位を考慮しながら合意を得ることに大半の時間を費やしているんだ。
これには当然、多くの妥協や政治的な駆け引きが伴う。シニアエンジニアは、自分たちのシステムに無駄な重荷を背負わせないよう、また意図した方向性から外れないように必死に戦う。だから妥協が必要になるか、経営陣に優先順位の判断を仰ぐためのエスカレーションが必要になる。
AIがそれも解決してくれるのかもしれないけど、それはかなりハードルが高い話だね。
AIはプロセスをバイパスするためのものじゃないけど、それでもスピードアップは助けてくれる。リファクタリング、ボイラープレートの記述、これまで見逃していたエラーの発見など、リンターでは検知できない部分をカバーしてくれるんだ。
AIを使っている人のコメントを見てると、標準的なプロセスを守っていないか、AIを使えばルールに従わなくていいと勘違いしている人が多すぎる気がする。
要件がしっかりしていてテストが十分なら、コードや機能をより多く出せるか?もちろんだよ。AIが書いたコードはすべてレビューとテストが必要だし、細かくコミットやプルリクエストに分けるべきだ。数千行のPRなんて、AIなしでもNGだろう?なぜAIを使えばOKになると思うんだ?大規模な書き換えやリファクタリング以外は論外だし、それだって変更が追えるようにコミットを分けるべきだ。情報に基づいた意思決定をするためにもね。
もし巨大な一括コミットやPRを見せられたら、自分なら却下するよ。普通の開発者が精査できるサイズに分解してくれ。
提示されたガントチャートはウォーターフォールか、あるいはソフトウェアに最終到達点があるような手法の例だ。今日のソフトウェアの99.999%はそんな風には作られていない。
現代のソフトウェア開発に到達点なんてない。2週間おきにビジネスサイドはソフトウェアの目的を変える。新機能、新統合、仕様変更、コンポーネントの入れ替え、規模拡大、ホスティング先の変更…。
数年経てばソフトウェアは根本から変わってしまう。品質やテストはおざなりになり、アドホックな修正とエントロピーとの戦いが続く。ソフトウェアは生き物になり、傷つき、ライフスタイルを変え、老いていく。会社は、うつ病の動物を飼いならそうとする動物園の飼育員のように、怪物のようなシステムの管理人に成り下がるんだ。
人間は習慣の生き物だから、AIを使っても同じ問題が繰り返されるだろうね。すべてが少しだけ速くなり、コードレビューでコードが少しだけ良くなるかもしれない。でも同時に、テスト不足やデプロイを急ぐ欲求が、すべてを少しだけ悪くする。この綱引きの結果、ソフトウェアの品質は変わらず、ペースだけが少し速くなる。結局、プロセスが高速化するだけで、誰もそれに気づかず、残りの仕事は泥沼のまま。全員が以前より早く燃え尽きるだけじゃないかな。
物事には複雑な理由があるし、その理由を取り除かずに複雑さを排除することはできないんだ。ビジネスの問題をツールだけで解決なんてできないよ。