Fast - 速いソフトウェアの力

 (catherinejue.com)
18 ポイント 投稿者 GN⁺ 2025-07-31 | 1件のコメント | WhatsAppで共有
  • ソフトウェア開発で速さ（fast）が求められることはまれだが、速いソフトウェアはユーザー行動に変化を生み出す
  • 高速デプロイやリアルタイムストリーミングのような技術は、業務効率とリモートワークを革新的に向上させる
  • 遅いソフトウェアは認知的摩擦を引き起こし、実際にユーザーの生産性を大きく低下させる要因になる
  • 速いソフトウェアは複雑さを隠すのではなく、単純さと集中を示す
  • 今後の開発業界では、性能と体験の最適化を重視する流れが強まる見通しである

速さを求めないソフトウェア業界

  • ソフトウェア業界では主に機能、価格、データ統合などが求められ、「速さ」が直接求められることは少ない
  • しかし速いソフトウェアはユーザー行動そのものを変える力を持つ
  • コードをデプロイする時間が秒単位まで短縮されると、開発者のデプロイ頻度も増える
  • AIベースのコード自動補完機能は、慣れていない言語でのプロトタイピングを容易にする
  • リアルタイムストリーミング技術は、リモートワークの可能性を切り開く

遅いソフトウェアの限界

  • 遅いソフトウェアは私たちが思う以上の制約を与える
  • たとえば機内WiFiを使うとき、大きな成果を出しにくいという経験をすることがある
    • Slackでメッセージを送ったりメールに返信したりする程度しかできず、
    • Google Docsはまともに動かないことが多く、
    • 結局は諦めてしまうようなユーザー体験になる
  • 一方でInstagramのようなサービスは、一貫して速い体験を提供する

速いソフトウェアの効果

  • 速さは魔法のようだと感じさせる
  • 速いソフトウェアは認知的摩擦を取り除き、RaycastやSuperhumanのように予想より一歩先の反応を見せる
  • Superhumanの100ms以下の応答速度と優れたショートカット対応は、メール利用体験を革新する
  • Mercuryの即時送金機能も、遅い銀行取引に慣れたユーザーに驚きを与える
  • こうしたツールの速さは明示的に称賛されることは少ないが、ユーザーがまるで魔法のように感じる要因である

速さと単純さ、集中力

  • 速さはすなわちシンプルさを意味し、現代のソフトウェア環境ではますます希少な価値になっている
  • ソフトウェアを速くするには、不要な機能を取り除く努力が必要だ
  • Linearのような簡潔なプロジェクト管理ツールは、WorkdayやOracleのようなエンタープライズアプリに比べてはるかに速い利用体験を提供する
  • 速さはユーザーへの敬意であり、不要な要素を徹底的にそぎ落としたことを示す

速く作るための隠れた努力

  • 速いソフトウェアを作るには、複雑なバックエンド最適化が必要だ
  • Cash Appでは、ユーザーの導線に本当に必要な段階だけを追加するよう努め、複雑さは内部で処理する
  • Instagramは写真アップロード時にキャプション入力と同時にアップロードを開始し、ユーザーが即座にアップロードされたと感じられるようにした
  • 速さは単なる技術的達成ではなく、優先順位と集中力の結果である

速さは楽しさとモチベーション

  • 速いソフトウェアは、それ自体で楽しさと満足感を与える
  • タイピング速度（WPM）の計測やショートカット設定のような小さな部分でも、ユーザーは速くなる体験を楽しむ

速さの相対性

  • AIおよびLLMベースのワークフローは、従来方式と比べて圧倒的に速い体験を提供する
  • たとえば、6分でLLMにリサーチを任せることは、以前と比べて10,000倍以上速い生産性を生み出す
  • しかし現時点では、AIアプリの開発、ビルド、デプロイの過程には以前のソフトウェア時代に比べて不足している点がまだ多い
  • 現段階では、性能と体験よりも新機能にさらに注力している
  • 将来は、低遅延、インターフェースデザイン、接続性、信頼性といった最適化を優先する流れが来るだろう
  • そうなれば、より多くの新たな可能性とユーザー体験の進化が開かれるはずだ

参考資料

関連記事

1件のコメント

 
GN⁺ 2025-07-31
Hacker Newsの意見
  • YComがHNのインターフェースを高速で良好なまま維持してくれていることに本当に感謝している。Slashdotが「モダンUI」と称してインターフェースを完全に変えてしまい、ひどく余白が多くてスキャンしづらい構造になった後、すぐ離れた経験がある。以前は毎日読んでいたサイトだった
    • 情報密度や欲しい情報をすばやく見つけることは、「engagement」とは完全に逆の概念だ。たいていはサイト滞在時間の指標を上げるために、わざと複雑にして広告主にアピールしようとする。ページが意図的に遅く読み込まれて誤クリックを誘い、「コンバージョン」を促す。実際にはユーザー中心よりも、人をだます方が金になるのが現実だ
    • HNはインターネット接続が生きているか確認するために開くサイトだ。あらゆるWebの肥大化の中で本当に光る存在だ
    • HNのUIも、特にモバイルでは改善が必要だ。コントラストが低く、ボタンが小さすぎて操作しづらく、ダークモードもないなど、不満はある。自分が考える理想のUIをElmで、完全クライアントサイド、HN firebase APIで作った版がある https://seville.protostome.com/
    • Slashdotが衰退したのはUIのせいではないと思う。本当の価値は、ごく初期にいた質の高いSMEたちが残したコメントにあった。サイトが売却されてから、質の低いユーザー、よくない運営、離脱などで下り坂が始まったように思う。まだサイトが生きているのが不思議だ
    • orange site(HN)はいまだにMarkdownのリンクタグをサポートしていない
  • LLMを導入したワークフローは、実際には遅いことが多いと感じる。IDEの「リファクタ」は1秒で終わるのに、AIアシスタントに任せると30秒、「エージェント」方式だと15分かかる。たとえばエージェントにHTTPエンドポイントのコードを書かせたとき、最初は「1日分の作業を10分で終えた」と思ったが、見直すとロジックがねじれていて、エラー処理も甘かった。結局、自分で5時間ほどかけて書き直し、テストも自分の基準以上に整い、エラー処理も自分でやるよりましな水準まで仕上げた。関連研究もある https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
    • すでにこのテーマで何度か書いたことがある。LLMがベンチマークの点数を追いかけるのは、プログラミングツールとしては方向違いだと思う。自分の経験ではかなり高い確率で間違うので、常に結果を点検しなければならず、LLMとのやり取りの時間が長くなる。しかも応答が遅いので、むしろ自分で手を動かした方が早いと感じることがよくある。自分が欲しいのは、ベンチマーク60%レベルでも1秒以内に即応するエージェントだ
    • LLMが自分の作業を本当に速くしてくれたのは、コードに対する高度なfind/replaceの概念に限られる。たとえばコード内の複数箇所にある「XXX関連ロジック」を何かに置き換えてほしい、というようなプロンプトにはかなりうまく答える。自分で探して一つずつ直す手間を大きく減らしてくれる。ただし、非常に大きなコードベースでは試したことがない
    • ケースバイケースだと思う。リファクタはIDEや言語サーバーが対応していればずっと速いが、それ以外ではLLMも役に立つ。たとえば昨日、URL正規化ロジックをMVPとして作ったが、顧客データにはさまざまな形式のURLが混在していて検証ケースが多かった。最もよくある顧客ケースをClaudeに入れて「最小被覆のテストケース」を作ってくれと頼んだら、5〜10秒で結果が出た。これを元にZedのOpusエージェント機能でテストファイルを作り、ケースを確認した後で不要な部分を整理し、ロジックも少し改善した。この方法は、一人で全部作るよりはるかに速かった
    • シニアの作業で40〜60%速くなるという話は、オンラインでもオフラインでもよく聞く。それでも、まだAIエージェントだけを信じて万事を任せられる段階ではない感じだ
  • 新人時代、ソフトウェアエンジニアとして速度改善で評判を得ていた頃のエピソードだ。当時はアルゴリズムの知識とコンパイラ出力を読む力の両方が重要だった時代で、CarmakやAbrashがスターになりつつあった。22歳のとき、大手多国籍企業の顧客ミーティングに初めて参加したが、そこで自社製品の速度が問題だと指摘された。その会社のVPが「1秒速くなることは、我々の年間利益に100万ドルを加えるのと同じだ」と直接言うのを聞き、完全に衝撃を受けた。速度をこんなふうに金額に結び付けるのを初めて目にした決定的な瞬間だった。20年経った今でも、キャリアのハイライトの一つだ。そして別のエンジニアがVPに「では0秒まで縮めたら無限に儲かるんですか」と冗談を言い、その場では誰も笑わなかったが、自分はかなり面白いと思った
    • 1秒から0秒へ、2秒から1秒へと縮めても、そのたびに100万ドルずつ増えるという話ではないのでは？ わざわざ無限の金が積み上がるという理屈になるのが不思議だ
    • 結局、本当に速くなったのか気になる
  • ブログ記事の最初の一文に共感して書く反応だ。ユーザーは開発者に「速く作ってくれ」とは直接言わないが、実際に速くなければ信用もしない。RustがRubyより遅かったら誰も興味を持たなかったはずだ。Rustが「C++より速い」と言うから注目される。HNでも「速い」という点さえあれば、みんな魅せられたように熱狂する。少しでも速いと言えばすぐ注目される
    • HNに書き込む少数のプログラマー層にしか通じない話だ。ほとんどの開発者や一般ユーザーは、遅いことをそこまで気にせず、UIが使いやすければいい。プロのデータサイエンティストですら、ものすごく速いコマンドより洗練されたGithub Desktopをよく使う
    • 結論が間違っている気がする。「速さ」は、同じ機能セットをより速く提供するときに強力な差別化要因になる、ということだ。人は「Xより速いX」だと群がるが、より多機能、より良いUX、より安い、より良いものへ移ることもあるし、遅くても選ばれる余地はある
    • 言語やランタイムでは速さが重要だが、フレームワークを使うときは機能、互換性など他の要素の方が重要だ。Electronのように遅くても多くの人が使う
    • 実際に、（特にWeb）アプリのかなりの部分が非常に遅い世界に私たちは住んでいる。ユーザーが何か操作してから反応が返るまで数秒かかるのは日常茶飯事だ。「速いのが最高」と言っても、現実は逆だ
    • HNユーザーが「速さ」を好むのは、今触れている大半のテクノロジーがあまりに遅く、しかも本質的にはもっと速くできると知っているからだ
  • 逆に、何かが「速すぎる」と、本当に動作したのか疑う現象もある。TurboTaxの事例では、実際の分析は1秒もかからないのに、わざと偽のローディング画面を見せたところ、人々はその方が信頼して好意的に受け取った。そのおかげで実際の処理時間はずっと短くても、「本当に確認したのか」という信頼のために遅く見せたという逸話だ
  • 速さはコスト面でも重要だ。クラウドで秒単位の課金をする構造では、すべての工程を最適化しなければ、安価な文字起こしサービスを提供することはできない。たとえば、自分が作ったイメージはオープンソースの次点より2.5倍も小さくなり、そのおかげでコールドブートが速くなり、コストが下がり、サービスも良くなった https://speechischeap.com
    • S3は遅いのか速いのか？ 実際には両方だ。単一リクエストで見れば遅いが、並列に複数リクエストを投げると速く感じられる。結局、「速さ」は時には生存に重要で、時には一つの美学でもある
    • 自分は逆に、コンシューマー向けハードウェアでサービスを動かしていて、クラウドよりずっと安く運用している。イメージサイズを心配する必要はない（ベアメタルの方が速い）。1分あたり2万分分の文字起こしも無料で提供中だ（リクエスト5秒制限ベース）。関連オープンソースやクロスプラットフォーム代替も開発している https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer 文字起こしサービスの変革に興味があれば連絡歓迎だ
    • PAPERのようなツールは（少なくともLinux基準では）インストール全体のサイズを2MB以内（キャッシュ込みでも）に収めてほしい。pipは10〜15MB、pipxはそれより大きく、uvは35MBだ。これより小さくするよう努力している
    • 速いからといって、必ずしも軽量で効率的という意味ではない。高価なハードウェアを大量投入して高速化している場合もよくある
  • 米国の銀行振込への不満記事を見るたび、いつも自分に言い聞かせることがある。英国やスイスなどでは銀行振込がほぼ即時に終わる。なぜ米国はこんなに遅いのか不思議だ
    • 米国の地方銀行には自前のプログラマーがほとんどおらず、「コアプロセッサ」に依存している。そのためシステム更新は非常に遅い。Faster ACHの導入にも何年もかかり、地方銀行ロビーは自分たちに不利だとして導入延期を主張した。詳しい説明がよくまとまったブログを勧めたい https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
    • ACHはスケジューリングとバッチ処理が遅さの原因だ。送金自体はすぐ終わっても、通常は深夜にまとめて処理する。このため米国ではVenmoやZelleが人気だ。スイスでもIBAN送金は遅く、リアルタイム決済はTWINTが主流だ（QRコードを読み取る方式）。英国のBACSも同じ理由で遅い
    • 米国には実際にリアルタイム送金システムが2つある。RTPとFedNowだ。参加銀行は徐々に増えている https://real-timepayments.com/Banks-Real-Time-Payments.html 以前は少額の手数料を払って、クレジットカードネットワーク経由で即時送金することもできた。ただし、クレジットカードは保証や返金ルールが異なり、不正発生時の銀行損失も大きい
    • これはむしろ消費者にとって良い面もある。たとえば、自動引き落としで残高のない口座から金が出ようとすると、銀行が何度もメールで知らせてくれる。そのおかげで、リアルタイムなら即問題になるところ、今は通知を受けて自分で対処する時間があり、延滞料や手数料を避けられることもある。即時送金ではないからこそ、銀行が知らせてくれて自分が対応する機会を得られる
    • patio11が関連内容を詳しく書いた記事がある https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
  • この記事は興味深く、考える材料をたくさん与えてくれた。速度が本当に体感されるのは、実際のスループットよりも「感じられる速さ」、つまりUIの応答性や入力遅延のような快適さだ。だから自分はRustよりGoを好むようになった。Goはコンパイル速度が十分に速く、まるで測る必要すらないと感じる。逆に、遅いものは実際のスループットが速くても嫌になる（Javaスタートアップのように）
    • GoとRustを比べても、コンパイル速度は本当に重要だと感じる。Rustのビルドは雑多なdependencyが多く、プロジェクト構造がJavaScriptに似てくる。Goは比較的dependencyがずっと少なく、その点がいい
    • 開発者がこういう議論をするのは良いが、本当に重要なのは「ユーザーにとってどの言語が速いか」だ
  • 「ソフトウェアで『速くしてください』とはほとんど言われない」という話とは逆に、自分が働いたほぼすべての会社で、ページの応答速度とレイテンシは最優先事項だった。スタートアップでも大企業でも、速度とレイテンシは重要な目標であり、製品がどれだけ速いか、ページがどれだけ早く表示されるか、妙な遅延がないかは常に重視されていた
    • 自分が経験した会社の大半（8社中6社）では、性能最適化のための時間がほとんど与えられず、いつもこっそりやっていた。レイテンシを測定して重要だと言っている会社ですら、実際には機能追加が優先されて後回しにされていた
    • 検索結果の速度には執着する一方で、ページレンダリングやユーザーに送るデータ量はそれほど気にしないケースが多かった
  • 複数の職場で繰り返し感じたことだが、たいていの人は速度の本当の価値を過小評価している。単に「同じワークフローを速くする」だけだと考えるからだ。たとえば、夜通し回す大規模実験を速くしても大した助けにならないと思われがちだが、もし劇的に高速化できれば、昼間にも何度も実験を回せるようになり、まったく別次元の生産性が生まれる
    • コンテキストスイッチのコストを人はものすごく過小評価している。あるコマンドを30秒から3秒に縮めても、1日に10回ならたった5分の短縮だと考えがちだが、実際には切り替えコストの方がはるかに大きい
    • CIパイプラインに何時間もかかるたびに、もし20分以内に終わっていたら、その都度細かなlint警告まで全部直していただろうと思う