Zoteroが5年かけて生まれた理由——AI時代に問う「 durable software」の価値
The Slow Formation of Durable Software
Zoteroの生みの親であるDan Cohen氏が、20周年を記念してその誕生秘話を振り返る。2006年のリリースまでに5年を要したZoteroは、歴史学者たちが大きなテーブルを囲んで交わした会話から生まれた。もし当時AIがあったとしても、何を作りたいのか明確でなかったため、プロンプトを書くことはできなかっただろうと氏は指摘。AIで瞬時にソフトウェアが作れる時代だからこそ、時間をかけた共同作業が生む「耐久性のあるソフトウェア」の重要性を説く。
もしAIが2000年代初頭に存在していたとしても、我々はZoteroの構想を加速させることはできなかっただろう。なぜなら、我々は自分たちが何を望んでいるのか正確にはわかっていなかったからだ。
HNでの議論
106- nickledave
みんなが気になってるだろうから書いておくと：
この記事はZoteroについてだよ。
アカデミックじゃない人はZoteroを知らないかもしれない。
使ってて本当に気持ちいい。すべてのアプリがこうであってほしい。
僕は本も含めて全部これで読んでる。今読んでるのはhttps://teachyourselfcs.com/のやつだ。
それに投稿のスナップショットを取るのも素晴らしくうまい。HackerNewsの投稿を拾ってマークアップするのにいつも使ってる。
しかもデバイス間で自動的に同期してくれて、ADDの収集癖のある僕でも、ウェブ上に大量のファイルを汗一つかかずに保存できる。
要するに、このソフトはただ動くだけでなく、ちゃんとよく動く。
だからZoteroの中の人がソフトウェア開発について語るときは、耳を傾ける価値がある。
それに歴史も交えた楽しい記事だ。この記事をZoteroに保存してから読むべきだよ。
- adamddev1
> しかし、その遅い形成のおかげで、ソフトウェアは儚いものではなく耐久性のあるものになり、その上に築ける強固な基盤ができた。
エージェント開発は大量に高速で生み出せるから素晴らしいと言う人がいる。しかし、だからといってそのどれもが本当に優れていて信頼できるとは限らない。
本当に洞察に富み堅牢なものは指数関数的に多く使われるようになり、余分な開発時間の線形コストは費用対効果の方程式の中で（漸近的に）取るに足らないものになる。
- _fw
顧客獲得と売上・成長に責任を持つ者として、これは非常に重要な点だ：
> 「…Zoteroの構想を加速することはできなかった。なぜなら、自分たちが何を求めているのか正確にわかっていなかったから、LLMに coherent なプロンプトを書くことができなかったのだ。」
驚くほど多くのソフトウェア製品、おそらく今日のビジネスでさえ、問題を探している解決策だ。
それが許されることもあるが、いつもではない。そして問題を探している解決策であるためには、成功したいなら他のすべてをほぼ完璧にしなければならない。
Zoteroが人々の求めるものに注意を払い、それを提供し、市場志向だったことは、その成功の大きな部分を占めていることは明らかだ。
人々が欲しがるものを作る方が、自分が作ったものを欲しがらせるよりもずっと簡単だ。
- ORDINAND_PIZZA
良いものは種のようなものから育つから時間がかかる。その種が成長するにつれて、局所的・全体的な文脈を理解していく。好奇心旺盛で忍耐強い世話人は、多くの時間をかけてそれを見つめ、理解し、小さな植物に安定した基盤を与える正しい方法を見つけようとする。注意と関心を持って育てば、木に成長し、あらゆる昆虫や動物、あらゆる生命を引き寄せるかもしれない。
速さは質を殺す。何か良いものを速く作ることは文字通り不可能だ。
私たちはこれを知っているし、それはソフトウェアにも当てはまる。より速く作れるようになっても、作り手の信じられないほどの注意、忍耐、喜びがなければ、決して良いもの（あるいは素晴らしいもの）にはならない。
質への近道はない。何か良いものを作るには常に多くの時間がかかる。
- sdevonoes
> 今日、ソフトウェアはAIによってほぼ瞬時に、大規模ユーザー向けにも自分向けにも、あらゆる目的のために、あるいは特に真剣な目的もなく作ることができる。
私はこれは真実だとは思わない。私は約1,000人のエンジニアがいる企業で中規模から大規模の機能に取り組んでいる。これらの機能は通常、自分のドメイン内の作業が50％、依存するドメインの作業が50％を占める。そのようなドメインとの事前の調整なしには何も進められない。議論、トレードオフ、設計文書、承認委員会などがある。AIはあらゆるステップで助けになる（実際になっている）が、よく練られたプロンプトで全てを解決できる魔法の杖ではない。
経験の浅い人の手に渡ると、AIは物事を遅くする（例：行き先のないAI生成の機械的で長ったらしいSlackメッセージ、Jiraチケットに書かれたことを実装するだけのPR…しかし調整のないJiraチケットは無価値だ、など）。
- kstenerud
> もしAIが2000年代初頭に存在していたら、Zoteroの構想を加速することはできなかっただろう。なぜなら、自分たちが何を求めているのか正確にわかっていなかったから、LLMに coherent なプロンプトを書くことができなかったのだ。代わりに、Zoteroがどうあるべきかという明確なビジョンを発展させるには、多大な時間と協力が必要だった。
AIはこれを妨げない。実際、その一部を加速するのに役立つ。
彼は典型的な大規模プロジェクトのライフサイクルを説明している：
- 状況を調査する
- ユーザーリサーチ（既存ソフトウェアをどう使っているか、何に不満があるかなど）
- ブレインストーミング
- 初期のアイデアとプロトタイプ
- 洗練、ユーザーフィードバック
- ビジョンと高レベルプロセス設計の固め
- 技術の選択
- 設計とアーキテクチャ
- フェーズの計画
- フェーズの構築、そしてユーザーによるテスト
LLMはリサーチとプロトタイプが得意だ。設計が固まれば、コーディングも得意だ。ユーザーフィードバックを抽出するのも得意だ。
- Krei-se
偉大な芸術家がスキルを磨くのに多くの時間を費やすのは、誰も欲しいと知らなかった結果がスキルとそこから生まれる新しい可能性から生まれるからだ。
だからソフトウェア開発者として今は、システム設計をひっくり返して方向性なしで開発し、すべてを自分が鍛えられる最高のものにするのに最適な時期かもしれない。
驚くべき機能や他では見つからないものが、そこから多かれ少なかれ自然に生まれてくる。
確かに、それにはある種の自由と金儲けのプレッシャーがないことが前提だが、ここで言及されている5年間も同じだ。
- peterbell_nyc
私は優れたソフトウェアが大好きで、優れたソフトウェアは構築されるのではなく進化するものだという意見に同意する。v0.1を作る目的は、何が間違っていてv0.2で修正すべきかを見つけることだ。
同時に、ループには大きく分けて3つの動きがある：
- 考える/議論する（それは何をすべきか）
- 作る（それをそうさせる）
- 使う（それが実際にそうすべきことかどうかを見る）
そしてもちろん、時間、金、忍耐、意志などが尽きるまで繰り返す。あるソフトウェアには終着点がある——本当にすべきことを正確にやる。ほとんどの場合、常にそこを目指している。
LLMは間違いなく2を加速し、1と3の加速にも役立つ可能性がある。そうなればサイクルタイムは短縮できる。望むものを得るのに100ターンかかるかもしれないが、AIを使えばその100ターンの実時間が変わらないとは思えない。