ハクソク

世界を動かす技術を、日本語で。

速い

2025年7月31日原文(catherinejue.com)

概要

  • ソフトウェア開発 では「速さ」を求める声は少ないが、その影響は大きい現状
  • 高速なソフトウェア はユーザーや開発者の行動変容を促進
  • 遅いソフトウェア は無意識のうちに利用を制限
  • 速さ はシンプルさや集中力の証明
  • AI時代 の新たな最適化フェーズへの期待

ソフトウェアにおける「速さ」の価値

  • ソフトウェア開発現場で「速さ」を求める声はほとんど聞かれない現実
  • 要望の中心は機能追加や ボリュームディスカウント、データ連携など
  • しかし、 高速なソフトウェア はユーザーや開発者の行動を大きく変化させる要素
  • デプロイが数秒で完了することで、開発者のリリース頻度が向上
  • AIによるコード補完で、 未経験言語 でのプロトタイピングが可能
  • リアルタイムストリーミングにより、 リモートワーク が現実的選択肢に
  • 逆に、 遅いソフトウェア はユーザー体験を著しく制限
  • 例：飛行機のWiFi利用時に感じる生産性の低下、Google Docsの不安定さ
  • 一方、InstagramやFacebookは 速さの重要性 を深く理解し実装
  • Raycast や Superhuman など、速さがまるで魔法のような体験を生む
  • Mercuryの即時決済体験も、従来の銀行振込との大きな違いを実感

速さがもたらすシンプルさと誠実さ

  • 多くのユーザーは「速さ」自体を明確に評価しないが、 体験として魔法のように感じる
  • 速さ はシンプルさの象徴であり、複雑さを隠せない厳しさも伴う
  • ネットワーク遅延や依存関係の露呈が、 設計の規律 を強制
  • 高速なソフトウェアを提供する企業は、 プロダクトの焦点 が明確
  • Linearのような シンプルなツール と、WorkdayやOracleのような 巨大なエンタープライズアプリ の速度差
  • 「足し算」よりも「引き算」が重視される時代、 速さは究極のリスペクト
  • Cash Appでは、ユーザー体験を損なわないために、 裏側の複雑さ を徹底して隠蔽
  • Instagramでは、写真アップロード時に 楽観的アップロード を採用し、即時性を実現

速さが示す優先順位と楽しさ

  • 速さ は単なる技術的成果ではなく、 優先順位や集中力 の証明
  • 速いソフトウェアは使っていて 楽しい体験
  • タイピング速度（WPM）を競うのも、単に 速さが楽しい から
  • 新しいPC環境でも、ショートカットキーや ホットキー設定 を真っ先に行う理由

相対的な速さとAI時代の変化

  • LLM（大規模言語モデル） を活用したワークフローは、従来より圧倒的に高速
  • 例：LLMによる6分間のリサーチは、従来のレポート作成の数千倍の速さ
  • しかし、現状のAI開発ツールは、 従来ソフトウェアの快適さ にはまだ届かない
  • 現在は「できること」への注目が先行し、 パフォーマンスや体験 への最適化はこれから
  • 今後は、 低遅延・UI設計・接続性・信頼性 の最適化が進む見込み
  • これにより、今は想像できない 新たなユースケースや体験 が生まれる可能性
  • 最高のソフトウェア は、私たちの生活様式そのものを変え、 スーパーパワー のような存在になる

Hackerたちの意見

ちょっと面白いけど、LLMを使ったワークフローって結構遅いことが多い気がする。IDEの「リファクタリング」機能を使うと1秒で終わるのに、速いタイプのアシスタントに頼むと30秒かかるし、「エージェント」タイプのアシスタントに頼むと15分もかかる。仕事終わりに、残り30分でHTTPエンドポイントを書いてもらうように頼んだんだけど、最初は「1日かかるところを10分でやった」と思った。でも、次に「4時間分の仕事を20分でやったのかも」と考え直した。翌日見てみたら、ロジックが複雑で、良いエラーハンドリングを書こうとして失敗してた。結局、手動でたくさんのコードを書き直す羽目になった。5時間で本当に完成させたけど、自分が書いたものよりもずっと良いテストスイートができたし、多分エラーハンドリングも良くなった。

└

LLMが僕の仕事を速くする唯一の方法は、高度な検索と置換みたいなものだね。「XXXに関わるロジックのコードを変更したい。XXXにする/追加する/何かロジックを変える/なんでも」みたいなプロンプトが結構役立ってる。手動で更新する必要がある場所を探す手間を省いてくれるから、時間の節約になってる。ただ、大規模なコードベースでは試したことがないけど。

└

40%から60%のスピードアップについての個人的な体験談や共有された話をよく見るよ。エージェントは好きだけど、それを使う人がまだリラックスして怠けることはできないと思うな！

└

それは場合によるかな？「リファクタリング」のことだけど、IDEや言語サーバーがそれに対応できるなら、確かにLLMは遅いと感じるよ。でも、LLMがすごく役立つケースもあるんだ。昨日、URLの正規化ロジックを書いてたんだけど、これをMVPとして展開したから、顧客がいろんな形式でURLを入れてDBに保存してたんだ。最初のロジックは一部のケースで失敗しちゃったけど、URLの正規化はテストしやすいから助かった。DBからよく使われている顧客をピックアップして、Claudeに送って「この動作をカバーする最小限のテストケース」を考えてもらったんだ。これには5〜10秒くらいかかった。その後、Zedのエージェントモードを使って、テストファイルを作成して、これらのテストケースを使って自分の関数を呼び出すように指示した。テストケースを監査して、いくつかの無駄なものを削除したよ。ロジックを改善して、それで終わり。自分でやるよりも確実に速かった。

ソフトウェアでは「速さ」を求める人はめったにいない。明示的に求めるわけじゃないけど、少なくともそれを装わないと真剣に受け取ってもらえない。「速さ」は当然の前提。もしRustが他の部分は全く同じなのに、「でもRubyより遅いです」と言ってたら、誰も相手にしなかっただろう。注目を集められたのは「C++より速い」と主張したからだ。HNをしばらく見てると、「速さ」が心を掴むために必要な唯一の特徴だって気づくよ。何かが前のものより速いって言った瞬間、蛾が炎に引き寄せられるみたいに。

└

言語に関してはそうかもしれないけど、フレームワークを探すときは「速さ」は簡単に後回しにされる。みんな機能を求めるし、互換性も重視するし、Electronを使う人も多い。

└

それでも、特にウェブアプリの世界では、ユーザーの入力に対する更新が数秒かかるような、信じられないほど遅いアプリが多いよね。速さが人を惹きつけるのは確かだけど、日常のコンピュータ体験はしばしばとても遅いんだよね。

└

HNに投稿するプログラマーのごく一部だけがそう思ってるんじゃないかな。ほとんどのユーザーや開発者は、遅いものや「フローステートに入る」とか気にしないで、ただ良いUIを求めてる。プロのデータサイエンティストが、簡単に10倍の時間を節約するために、Gitコマンドを覚える代わりにWindowsのGithub Desktopを使ってるのを見たことがあるよ。

└

うーん、HNの人たちは速さが好きだと思うよ。今のテクノロジーは不合理に遅いから、もっと速くできるって分かってるし。

ソフトウェアでは「速さ」を求める人はめったにいない。私たちは機能を求めるし、ボリュームディスカウントを求めるし、次のデータ統合を求める。速さを求めることは考えもしない。私が働いてきたほとんどの場所では、ユーザー向けのスピードが最優先事項の一つだった。小さなスタートアップから数十億ドルの企業まで。目標指標を設定している会社では、スピードとレイテンシーは常に指標の一つだった。私の経験はそんなに特別じゃないと思う。むしろ、もし入った会社が製品の応答性やページの読み込み速度、変なラグに気にしないなら、そっちの方が驚きだよ。

└

私の経験では、みんな検索結果が返ってくる速さにはこだわるけど、ページのレンダリング速度やユーザーに送るバイト数にはあまりこだわらないことがある。

└

僕が働いた8社のうち6社（ほとんどがテックとファイナンスのミックス）では、パフォーマンス最適化のための時間を確保するのにいつも苦労してた。だから、だいたい自分でこっそりやってたんだ。レイテンシを測定して重要だと言っている会社でも、通常は新しい機能を追加する方が優先されてた。

Hacker Newsで議論の続きを見る