AIとAshby Engineeringが切り拓く、エンジニアリングの未来

AIの台頭によって、エンジニアリングの現場はどう変わるのか？Ashby Engineeringの取り組みを切り口に、この先の技術開発のあり方と未来の展望について考察します。

ここ数年ずっとAshbyを日常的に使っている身として、AIに技術や製品の決定を任せてくれと願っているのが自分だけではないはず。この製品、まるでCチームかDチームが設計・構築したような感じなんだよね。Ripplingのような重さと肥大化に加え、狂気じみた、まるで悪夢のようなインタラクションモデルやワークフローには、フラストレーションが溜まるし混乱させられる。(それに、何か用があるときにメールをしないといけないのが最悪。アプリ内にアカウントのアップグレードやSAML追加といったセルフサービスの機能がほぼ皆無。本当にメールを送るしかないんだ。最後に確認したときは、フォームすらなくてmailto:リンクだったよ。)

我々には毎年3月/4月に一時的な変動があり、こうした周期的なパターンをここで説明するのは適切ではない。この「AI以降」の変動は、該当月で約30%増えている。正直なところ、「顧客の問題は概ね安定している」という仮説を証明あるいは否定するほどのデータはここにはない。「AIエンジニアリングは理想的な条件下では問題は増えないが、外部からのプレッシャーがかかると問題を増幅させる」といった議論の方が、むしろ説得力があるんじゃないかな。

最近、Ashbyを使っている企業の求人にたくさん応募していたんだけど、自分の履歴書をAIシステムで処理されないようにするためのオプトアウト用フォームへの小さなリンクがあったんだ。ただ、それが全く機能しない。フォームを送信してもスピナーが回るだけで何も起こらない。意図的なものなのかどうかは不明。最近、「バイブ・コーディング（vibe coding）」はエンジニアリングじゃない、という考えに傾きつつある。Ashbyがバイブ・コーディングだと言っているわけではないよ。記事では、変更のすべての行を全員が理解できるようにすることを非常に重視していると書かれているけど、実際どうやって管理しているのか疑問だね。GitHubやCodebergで私たちが日常的に行っている非公式なコードレビューがエラー率に与える影響についての実証研究はほとんどない。実際、大した影響はないんだ。ただ、ある小さな研究では、レビューの読み込み速度が上がれば上がるほど、エラー率を抑える効果が消えていくと指摘されていた。つまり、かつての「80/20の法則（20%のエンジニアが80%の仕事をする）」が、今や「大して仕事をせずに何とかやり過ごしている80%のメンバーが大量のコードを書き、そのレビューを20%の優秀なメンバーが押し付けられる」という状況になっている。しかも、読みすぎると効果がないという。だからどうだろうね。これに最近の価格高騰の波が組み合わされば、今年後半にはAIの利用を撤回する組織が出てきても不思議じゃないと思う。

誰か教えてくれないか、なぜAshbyがシリコンバレーやその他の世界でこんなに流行っているの？最近自分の会社も導入したんだけど、EM（エンジニアリングマネージャー）として……がっかりしているんだよね。VCマネーがつぎ込まれた、また別の採用システムという以外に、何がそんなに特別なんだ？

私には、AIを使って他人を混乱の渦に陥れる「新しいロックスター」と、AIを使っているようなフリをして実際は自分の仕事をこなしている「悪意あるコンプライアンス遵守者（仕事をこなさないとクビになるから）」の間で、20/80の分割が起きているようにしか聞こえないよ。まあでも、これはAIがなくてもあり得る構図だよね。誰かが散らかして、別の誰かが片付けるという。

我々の仮説は、コードの生産コストはゼロに向かっているというものだ。この（正しい）仮説は、SaaS市場の未来について興味深い問いを投げかける。コードのコストがゼロに近づいたとき、SaaS市場はどうなるのか？偶然にも、この記事を書いた会社がその完璧なケーススタディになっている。ソフトウェア製品を市場に投入するのがどれほど大変か、理解している人は少ない。製品を売り始めるために必要な機能の密度を満たすだけでも、初期段階の投資家が引き受けてくれる以上の人的資本が必要になることが多い。それを説得できる経歴を持つ創業者もいるが、ほとんどは非常に小さなインサイトを持って市場に切り込むしかない。2021年にGreenhouseのCEOと食事をした際、新しいATSが買い手の検討対象に入るために、いかに深い機能セットが必要かを熱弁していたのを鮮明に覚えている。企業がこれらの市場に参入する偶然の手段の一つは、ある市場で立ち上げてから、別の市場へピボットすることだ。Ashbyは最初からATSを目指していたわけではない。もともとは中堅市場向けERP（当時はホットなテーマだった）をターゲットにしていた。Ashbyは、突破に必要なエンジニアリングリソースがあまりに膨大であるため、本来なら今の市場には参入できなかったであろう企業の好例だ（それをやり遂げた彼らには敬意を表する！）。しかし、コードのコストがゼロに近づくにつれ、市場参入の障壁もゼロに落ちていく。次のAshbyは初日からATSを狙えるだろう。ある意味で、これは人類、特にソフトウェアの歴史そのものだ（Leverが設立された2012年と、Ashbyが直面した2019年のATS構築コストを比較してみればわかる）。しかし、この変化の傾斜はこれまでの何とも比較にならない。ATSは、他の多くの市場と同様に、少数の大手プレイヤーと、その背後に長い裾野（ロングテール）を引く小規模なサービスで構成されている。どれだけロングテールのプロバイダーが増えようとも、これまでは市場参入の経済性がその数を抑制してきた。10年前のATS構築コストは、今よりも文字通り桁違いに高かったんだ。2016年、A16Zのパートナーが、すべてのソフトウェア市場で、想像しうるあらゆるニッチな分野にサービスが存在する未来について語っていたのを耳にした。LLMのルネッサンスよりも数年前の話で、当時は正気の沙汰とは思えなかった。市場がどうやってそれらすべてのサービスを構築・維持できるのか？企業が自前でATSを構築し始めるとは思わないが、コードの生産コストがゼロに近づいているのは事実であり、それはつまり、あらゆる形態、あらゆる方法で、何百、何千ものサービスが乱立することを意味しているんだ。

これまでのコメントのほとんどが、記事の最初の数段落にだけ反応しているようだな。読み進めてみると、実はLLMをソフトウェア組織でどう使うかという点において、かなりバランスの取れた見解だと思ったよ。記事で繰り返される「コードのコストはゼロになった」というミームには少しうんざりする。私の経験では、コードの最大のコストは常にコードそのものを取り巻く活動（計画、コミュニケーション、レビュー、検証）にあったからだ。著者はこのミームを繰り返しつつも、その点には同意しているようだね。人間向けのPR（プルリクエスト）説明や仕様書を書くことへのこだわりは、私の経験と一致するし、暗闇の中で狂気的な夢を追いかけるよりもずっと健全な働き方のように聞こえる。「2つの働き方」というセクションも有益だった。コーディングエージェントの使い方は人によって結果が大きく異なるのに、いつどちらを使うべきかという具体的な指針はあまり見かけなかったからね。個人的には、昨年の10月から（いわゆる「AIが進化する」という閾値よりも前から）、著者が言うところの「サイドキックモード」を使っている。エンジニアにとっては、「デリゲートモード」よりもこちらの方がデフォルトとして有益だと思う。

自分の履歴書がAIのスクリーニングプロセスで「ブラックホール」行きになっていないか知る方法があるって聞いたんだけど。修正するためのテストのようなものらしい。誰か仕組みを知ってる人いる？

結局、私たちが何十年も苦労してきた「ソフトウェアエンジニアリング」という極めて欠陥だらけのパラダイムに人間を縛り付けているだけだよ。実際、私たちはエンジニアじゃない。中世の時代のように、泥や石で建物を手作りしている職人にすぎない。「もっと考えろ」と言われても、業界が目を覚まして作業を標準化しない限り意味がない。標準化さえされれば、考える必要なんてなくなるんだから。この業界がようやく大人になる前に、自分が死んでしまわないことを願うよ。

皮肉なことに、AIコーディングを使えば自分だけのAshbyを作ることだってできるんだよね。AIを使えばAshbyを作るのは（どうやら）とても簡単みたいだからさ。