このプロジェクトの真のターニングポイントは、Harry Hochheiser がクライアント機の SMTP ポートにメールを転送するための書きかけの コードを送ってきてくれたときだった。ぼくはほとんど即座に、 この機能を信頼できる形で実装できたら、ほかの配信モードはほとんど 時代遅れ同然になるなと気がついた。

　何週間にもわたって、ぼくは fetchmail にいろいろ追加する形でいじってきていた。 でもその間、インターフェースのデザインが使えなくはないけれど、 ちょっと野暮ったいなと感じだしていた —— エレガントじゃないし、 貧弱なオプションがそこらじゅうにぶらさがってるし。 とってきたメールをメールボックスファイルや標準出力にダンプするオプションが ことさら気に入らなかったけれど、その理由が自分でもわからなかった。

　SMTP 転送について考えてみたときに気がついたのは、popclient はいろいろやろうとしすぎてるということだった。これはメール配送エージェント （MTA）とローカル配信エージェント（MDA）の両方をこなすよう設計されていた。 SMTP 転送があれば、MDA の仕事からは足を洗って、メールのローカル配信は ほかのソフトにまかせればいい。ちょうど sendmail がやってるように。

　メール配信エージェントのややこしい設定なんか、しなくたっていいじゃないか。 メールボックスをロックして追加なんて、しなくていいじゃないか。 ポート 25 は、TCP/IP サポートのあるプラットホームなら、 まずまちがいなくそこにあるんだから。特にこうすれば、 とってきたメールは確実に、ふつうの送り手から送られてきた SMTP メールのように見えるはずなんだ。 それがもともとぼくたちの求めているものだろう。

　ここにはいくつか教訓がある。まず、この SMTP 転送のアイデアは、 ぼくがリーヌスのやりかたを意識的に真似ようとした最大の見返りだった。 あるユーザがすばらしいアイデアを提供してくれた —— ぼくは単に、 その意義を理解すればよかっただけ。

11. いいアイデアを思いつく次善の策は、 ユーザからのいいアイデアを認識することである。 時にはどっちが次善かわからなかったりする。

　おもしろいことに、もし自分が他人に負うところがいかに大きいかについて、 完全かつ謙虚なくらいに正直でいたら、世の中はその発明が全部あなた自身のもので、 単に自分の天才ぶりについて謙遜しているだけだと見なしてくれる。 これがリーヌスの場合にどんなにうまくいってるか、みんなもごらんの通り！

　（1997 年 8 月にこの論文を Perl の会議で発表したとき、最前列に Larry Wall がいた。ぼくがこの直前のくだりにさしかかるとかれが野次をとばした。 キリスト復活論者スタイルで、「そうだそうだ、言ってやれ、兄弟！」と。 全聴衆が笑った。みんなこれが、Perl 発明者にとってもうまくいったのを 知っていたからだ。）

　そしてその同じ精神でプロジェクトを運営してほんの数週間もしないうちに、 ユーザたちからだけでなく、それを伝え聞いたほかの人たちからも、 同じような賞賛のメールが届くようになった。そういうメールはいくつかとってある。 いつか、自分の人生なんて何の価値もなかったんじゃないかと思うようになったら、 またそれを読みかえそうっと:-)。

　でもここには、もっと本質的で政治的でない教訓があと 2 つある。 これはあらゆるデザインに一般化して言えることだ。

12. 自分の問題のとらえかたがそもそも間違っていたと 認識することで、 もっとも衝撃的で革新的な解決策が生まれることはよくある。

　ぼくは popclient を、MTA/MDA の複合物として開発し、 いろんな気の利いたローカル配信モードをくっつけたものにしようとし続けていた。 これは解決すべき問題をまちがえていたんだ。Fetchmail の設計は、純粋な MTA として最初から考え直す必要があった。通常の SMTP を話すインターネットメールパスの一部として。

　開発で壁にぶちあたったとき —— 次のパッチ以降何をしたらいいか、 すごく悩んでしまうとき —— というのは、自分が最終的な回答に たどりついたのかな、と考えるべきときではなく、むしろ自分が正しい質問を しているのかな、と考え直してみるべきときであることが多い。 ひょっとして、問題をとらえなおしてみる必要があるのかもしれない。

　というわけで、問題をとらえなおした。明らかに、 やるべき正しいことというのは：

• 汎用ドライバに SMTP 転送サポートをハックして入れ込む
• それをデフォルトモードにする
• やがてはその他の配信モードをすべてうっちゃる。特にファイルへの配信と標準出力への配信は始末する

ということだった。

　この 3 番目については、しばらくためらった。ながいこと popclient を使ってきて、他の配信メカニズムに頼っている古参ユーザたちを 怒らせるんじゃないかと思ったからだ。理論的には、かれらは即座に .forward ファイルか、sendmail 以外でもそれに相当する仕組みを使うことで、 同じ結果を得ることができる。でも実際問題としては、 この移行はえらく手間がかかることになるかもしれない。

　でも実際にやってみたら、利点のほうが大きく出てきた。 ドライバのコードのいちばんいやらしい部分が消えた。 設定もむちゃくちゃに簡単になった —— システム MDA やユーザの メールボックスを探し回ったりして悩むこともなくなったし、 下敷きになってる OS がファイルのロッキングをサポートしているか心配する 必要もない。

　さらに、メールをなくす唯一の方法も消え失せた。 もしファイルへの配信を指定してディスクがいっぱいになったら、 メールは消えてしまう。これは SMTP 転送では絶対に起きない。 SMTP のリスナーは、メッセージが配信できるか、少なくとも後の配信用に スプールできる場合にしか OK を返してよこさないからだ。

　さらに、速度も向上（もっともこれは一回走らせたくらいではわからないけれど）。 もうひとつバカにできないメリットとして、 man ページがすごくシンプルになった。

　あとで、ダイナミック SLIP がらみの珍しい状況を処理できるようにするため、 ユーザ指定のローカル MDA 経由の配信は復活させなきゃならなかった。 でも、これももっと簡単にこなす方法を見つけた。

　教訓は？　古びてきた機能は迷わず捨てること —— 有効性を下げずに捨てられる場合には。アントワーヌ・サンテグジュペリ （かれは児童書の古典を書いていないときには、飛行家で航空機設計家だった） 曰く：

1. 「完成」（デザイン上の）とは、 付け加えるものが何もなくなったときではなく、 むしろなにも取り去るものがなくなったとき。

　コードがどんどんよくなって、しかも同時に単純になってきたら、 それはもう絶対に自分が正しいのがわかる。そしてこの過程で、 fetchmail のデザインは、先祖の popclient とは別の独自のアイデンティティを 獲得してきた。

　そろそろ名前を変える頃だった。新しいデザインは、以前の popclient よりずっと sendmail の双子みたいな感じになってきていた。どっちも MTA だけれど、sendmail がプッシュして配信するのに対して、新しい popclient はプルして配信する。だから引き継いで2ヶ月したところで、 ぼくはこれを fetchmail と改名した。

　SMTP配信が fetchmail になったこのお話には、もっと一般的な教訓がある。 並列処理可能なのは、デバッグだけじゃない。開発と、（かなり驚く規模で） デザイン空間の開拓も並列処理ができるってことだ。 開発モードが高速なやりとりに基づくものになっていると、 開発と拡張はデバッグの特殊なケースになってくる —— つまり、 もとのソフトの機能やコンセプトにおける「見過ごしというバグ」 をなおすことになるわけ。

　もっと高次のデザインでも、自分の製品近くのデザイン空間を、 多くの共同開発者たちがランダムウォークしつついろいろ考えてくれていると、 とても役にたつことが多い。水たまりがドブに流れていくやりかたとか、 あるいはもっといいのは、アリが食物を見つけるやり方を考えてほしい。 基本的には、拡散による探索をして、その後で、スケーラブルな 通信メカニズムによって、探索の結果を取り尽くす。これは実にうまく機能するんだ。 そして Harry Hochheiser とぼくの場合と同じく、きみの周縁ライダーたちが、 近くの巨大な勝利を見つけてくることは十分にありえる。 自分では、近くばかり見過ぎていてちょっと気がつかなかったようなやつをね。