ハクソク

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

速い

299日前原文(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社（ほとんどがテックとファイナンスのミックス）では、パフォーマンス最適化のための時間を確保するのにいつも苦労してた。だから、だいたい自分でこっそりやってたんだ。レイテンシを測定して重要だと言っている会社でも、通常は新しい機能を追加する方が優先されてた。

これは面白いね。考えさせられる。記事がもう少し考えさせてくれるのが好きだ。自分自身でもそうだと感じてる。RustからGoに戻ったのは、主に反復速度の利点のため。だけど「速さ」を「クイック」に置き換えたいかな。生のスループットよりも「体感速度」を重視してるから。だから、エディタの入力レイテンシーとかが重要なんだよね。何かが「速く感じる」(例えばGoのコンパイル)と、測定する必要すら感じないことが多い。逆に「遅く感じる」(例えばJavaの起動)と、実際には速い部分があっても、使うのが楽しくなくなる。

└

GoとRustについても同じ気持ち。コンパイル速度は大事だよね。それに、RustのプロジェクトはJavaScriptのプロジェクトみたいに、依存関係がめっちゃ多いし。Goのプロジェクトは依存関係が少ない傾向がある。

└

開発者がGoがRustよりもコンパイルが速いかどうかについて意見を持つのはいいけど、実際の問題は「ユーザーにとってどっちが速いの？」ってことだよね。

いろんな仕事で何度も気づいたのは、みんなスピードの利点を過小評価してるってこと。彼らは同じワークフローを速くすることを想像するけど、違うワークフローをすることを考えない。例えば、一晩中大きなバッチで実験をしているとき、その速度を上げてもあまり役に立たないように思える。でも、十分な改善があれば、日中にいくつかのバッチの実験を実行できるようになって、ずっと生産的になる。

└

数時間かかるCIパイプラインを見ながら、CIが20分で回せたらどれだけ小さなlint警告を直すか考えてる。

アメリカの銀行振込の話が出るたびに、自分に思い出させる必要がある。イギリスでは、銀行振込はすぐに簡単にできる（お金がほぼ瞬時に移動する感じ）。アメリカでそんなに遅い理由を教えてくれたら嬉しい。

└

ACHの場合、遅くなるのはスケジューリングとバッチ処理なんだ。転送自体は瞬時に行われるはずだけど、銀行が大体真夜中に送信することが多いんだよね。だから、VenmoやZelleが人気なんだ。銀行振込も、処理される前に変更やキャンセルができるのがいいよね。スイスでも同じだよ。IBAN振込をリクエストすると、決して瞬時にはならない。そこでの速い支払いの解決策はTWINTっていうもので、ほぼすべてのPOS端末で使える（表示されたQRコードの写真を撮るだけ）。BACSも決済プロセスのせいで「遅い」って感じだね。

└

「コミュニティバンクはほとんどプログラマーを雇っていなくて、いわゆる“コアプロセッサー”に依存している…これがアメリカの金融システムのアップグレードが遅い最大の理由だ。Faster ACHの導入を調整するのに何年もかかったし、コミュニティバンクのロビーは、自分たちが競争で不利にならないようにするために、これを遅らせることに大声で賛成していた。」素晴らしいブログ「Bits About Money」から: https://www.bitsaboutmoney.com/archive/community-banking-and...

└

イギリスには速くなければならないって法律があるんじゃないの？

└

アメリカには実際にリアルタイム決済システムが2つあって、RTPとFedNowがあるんだ。参加している銀行の数も急速に増えてるよ。 https://real-timepayments.com/Banks-Real-Time-Payments.html その前は、即時送金はできたけど、クレジットカードネットワークを通してたから手数料がかかってたんだ。クレジットカードネットワークは手数料を取るし、クレジットカード取引には異なる保証や取り消しがあるから（例えば、詐欺のケースでは銀行にとってコストがかかる）。

└

patio11がここで少し書いてたよ： https://www.bitsaboutmoney.com/archive/the-long-shadow-of-ch...

面白い話を一つ！ソフトウェアエンジニアとしてのキャリア初期、僕は物事を速くすることで評判になったんだ。あの頃はアルゴリズムの知識がコンパイラの出力を確認する能力と同じくらい重要で、毎回新しいインテルのプロセッサが出るたびに期待が高まって、カーマックとアブラッシュが急速に有名になっていた時代だった。そんな中、22歳の僕が大手多国籍企業の顧客会議に突然招待されたんだ。何を期待していいかわからずに行ったら、彼らはうちの製品のスピードに不満を持っていた。彼らのVPが言ったんだ、「ここでの1秒の節約が年間100万ドルの利益を生む」と。正直、驚いたよ。その瞬間、スピードにお金の価値をつけるなんて夢にも思わなかったから。今から20年以上経っても、キャリアの中でのトップ5のハイライトの一つだね。P.S. ブログの最初の文に対する反応として言及しておくけど、著者が言ってる通り、こういうことはめったに起こらないよね。P.P.S. 部屋にはもう一人エンジニアがいて、冗談でVPに「じゃあ、0秒で実行できるようにしたら、無限にお金が入るってこと？」って聞いたんだ。彼らは笑わなかったけど、僕は結構面白いと思ったよ。ヘイ、ダグ！ :)

└

で、速くなった？

└

RE: P.P.S... ああ、そのユーモア大好き。実際、めっちゃ面白かった。

└

「じゃあ、0秒で実行できるようにしたら、無限にお金が稼げるってこと？」よくわからない。1秒から0秒にするのって、2秒から1秒にするのと同じだけ年間利益が増えるんじゃないの？つまり、100万ドル。

速さは安いってことでもあるよね。特にクラウドコンピューティングの世界では、秒単位でお金を払うから。僕が他のサービスよりも安くて利益を出せるトランスクリプションサービスを作れたのは、すべての小さなことを最適化したからなんだ。例えば、昨日知ったんだけど、僕が作った画像のサイズが次のオープンソースのバリアントよりも2.5倍小さいんだ。これでコールドブートが速くなって、コストが下がるし（より良いサービスを提供できる）。[1] https://speechischeap.com

└

あなたのCSS、壊れてるよ、念のため。

└

S3は遅いの？それとも速いの？どっちもだと思う。遅いシステム（私のも含めて）で、速くなるために遅くなるクラスのシステムを表してる。S3は単一リクエストのレベルでは「遅い」。でも、必要なだけのリクエストを並行して処理するレベルでは速い。「速い」ことは時には重要で、しばしば美的な要素でもある。

└

開発やメンテナンスのコストではそうじゃないよ。

YComに感謝したいのは、HNのインターフェースをめちゃくちゃにせず、速さを保ってくれたこと。Slashdotが自滅したときのことをはっきり覚えてる。あの時は、コメントをスキャンして価値のあるものを見つけるのがすごく簡単だったのに、「モダンUI」とかいうクソみたいな理由で、デザイナーを雇うために完全に改悪されて、ホワイトスペースが増えてコメントをざっと見るのがほぼ不可能になった。3日くらい試してみたけど、すぐに諦めちゃった。それまでは毎日Slashdotを読んでたのに。

└

情報の密度と識別のしやすさは、「エンゲージメント」の真逆だよね。エンゲージメントって、サイトに滞在する時間を測る指標を追い求めてることが多いし。欲しいものを見つけて読めれば、ページで迷って5秒余分に過ごすこともないから、広告主のために統計を盛ることができる。バカなページがそんな風に読み込まれて、うっかり何かをクリックして「コンバージョン」を与えちゃうと、ボーナスポイントだね。残念ながら、金銭的なインセンティブは、ほとんどいつも人を騙してやりたくないことをさせる方向に向かってるよね。

└

それが完全にxhtmlになった時かな？

これに付け加えると、だからこそ僕は全ての生徒にタッチタイピングを学ぶべきだって言ってるんだ。レッスンごとに最低10分はやってほしい。これが本当にコンピュータとのやり取りを変えるし、タッチタイピングを身につけることで、考える速さでタイピングできるようになるから、スクリプトを自動化したり、ちょっとしたbashの技を使ったりするアプローチが変わるんだよね。今の時代、すごく評価されてないスキルだと思う。