数ヶ月前、システムソフトウェアの分野でかなり大きく活発なコミュニティを抱えるOSSプロジェクトのメンテナーからメールをもらった。何年もプロジェクトを維持し続けるのが辛い、精神的にあまりにも消耗する、という内容だった。彼は私にアドバイスを求めていた。自分がアドバイスできる立場にあるのかはわからないが、この件について自分が考えていることをブログに書くと返事をした。そこから数週間が経ち、何度か書き始めては中断した。考えを十分に整理する時間が取れなかったからだ。ようやく今、自分自身を分析して答えを見つけられた気がしている。自分の弱さや苦悩、そして長期間にわたってネガティブな側面も含む作業を続けるとき、誰の心にも否応なく忍び寄ってくる自由への渇望の中に。オープンソースプロジェクトの維持には大きな喜びや楽しさもある。この10年は私の職業人生の中でも確かに記憶に残るものだ。もっとも、最高の10年というわけではないが（起業していた頃の方が結局は楽しかった）。ただここではネガティブな面に絞って書く。もちろんそれだけではないし、そこには多くの良いこともあるということは忘れないでほしい。

洪水

私は速く動くこと、速く考えること、競争に勝つために時間を制することといった考え方を信じていない。ソーシャルネットワークやチャット、メール、ぎっしり詰まったスケジュールのせいで、常に集中を欠いた世界に生きているのが好きではない。だからプロジェクトの初期、まだ時間に余裕があった頃にRedisについてメールをもらうと、相手が本当に伝えようとしていることに集中できた。話題になっているRedisの該当部分を思い出し、じっくり考えたうえで、自分の本心から返事をすることができた。どんな仕事であれ、人は本来こう働くべきだと思っている。

ソフトウェアプロジェクトがRedisほど人気になり、しかも新しいソーシャルツールによって個人間のやり取りが極めて手軽になり、さらにあなた自身がユーザーのために「そこにいる」姿勢を貫いていると、作者のもとに届くメッセージ、issue、プルリクエスト、提案の数は指数関数的に増えていく。一方で、少なくともRedisの場合はそうだったが、これは多くのプロジェクトに共通する問題だと思うが、そうしたコミュニティからのインプットを適切に扱えるほど高度なスキルを持った人の数は、ごくゆっくりとしか増えない。そこで明らかな渋滞が生まれる。多くの人はこれを間違った方法で解決しようとする。現実的に対処するという名のもとにだ。こちらから質問して2週間返信がなければissueを閉じる。説明が不十分なissueはすべて閉じる。そういった「受信箱ゼロ」を目指すやり方だ。現実には、コミュニティからのフィードバックを本当によく処理するには、必要なだけ時間をかけなければならない。そうしなければ、未解決のissueが少ないふりをしているだけになる。各サブシステムごとにコアレベルのエキスパートをフルタイムで雇えるほどのリソースがあれば解決するだろうが、現実的ではない。

では結局どうなるか。何に目を通し、何を無視するかを、どんどん優先順位付けするようになる。そして多くの事柄や人を無視することに、自分は最低だと感じる。一方でコントリビューターからは、あなたが人の提供してくれるものを気にかけていないと思われてしまう。複雑な状況だ。たいてい行き着く先は、致命的な問題にだけ対応し、新しいものは切り捨てるという姿勢だ。新しいものはまだコアに入っていないし、コードベースをさらに大きくして、さらに多くのPRやissueを抱えたい者などいない。しかもたいていは自分の普段のプログラミングスタイルよりも複雑に入り組んだ書き方をされている。複雑さは増すばかりで、そこで致命的なバグが起きたときに原因を追うのは至難の業だ。

役割の変容

上で述べた「洪水」問題の結果として、気づけば仕事内容自体が変わってしまう。Redisが人気を得たのは、私がソフトウェアを設計し、書くことができたからだったはずだ。なのに今、私の仕事のほとんどはissueやプルリクエストに目を通すことだ。しかも、受け取るコントリビューションの多くは、自分ならもっとうまく書けると感じてしまう。もちろん中には私より優れたプログラマによる、私以上のクオリティのものもある。だが数の論理として、*大半*は平均的な出来で、投稿した人にとっての目先の問題を解決するためだけに書かれたものだ。一方で、私がRedisを設計するときは、Redis全体として考える。何年もこのソフトウェアを書き続けてきたからだ。つまり、あなたが得意だったことをする時間がなくなってしまう。その結果、自然な流れで生まれるような大きな新機能も減っていく。私はどうしたか。時々、数週間にわたってissueやPRを見るのをやめる。コードを書いたり設計したりするためだ。それこそが私が本当に愛し、楽しめる仕事だからだ。しかしそうすると、今度は心理的により大きなプレッシャーがのしかかる。自分が愛し、得意とすることをするために、最低の気分を味わわなければならないのだ。

時間

同じプロジェクトを長期間続けることには、少なくとも私にとって二つの問題がある。

一つ目は、Redisを始める前、私は*一度たりとも*平日毎日働くということをしたことがなかったということだ。一週間働いたら二週間休み、ひと月働いたらまた二ヶ月姿を消す。ずっとそうだった。創造的な仕事をするには、人は充電し、新しいエネルギーやアイデアを得る必要がある。ハイレベルなプログラミングは、とてつもなく創造的な仕事だ。Redis自体、最初の2年間、つまり最も速く進化した時期は、まさにそうやって作られた。自分が働きたいときだけ働いたときの生産性の合計は、毎日規則正しく働かされたときの生産性よりも大きいからだ。

ただ、私の仕事に対する倫理観は、自分一人で会社をやっていたときには、そうした極めて不規則なスケジュールを許容していた。Redisでお金をもらって働くようになってからは、その倫理観が以前のような働き方を許さなくなった。だから無理にでも普通のスケジュールで働くように自分を追い込んだ。これは私にとって、もう何年にもわたる大きな苦闘だ。しかも、そのせいで本来できるはずのことよりも成果が上がっていないと確信しているが、仕方のないことだ。この問題を解決する方法は見つかっていない。Redis Labsに昔の働き方に戻りたいと言えばいいのかもしれないが、それもうまくいかないだろう。今や私が「報告」すべき相手は会社ではなく、コミュニティなのだから。

もう一つの問題は、同じプロジェクトで長く働くこと自体が精神的に複雑なことだということだ。昔は半年ごとにプロジェクトを変えていた。今は10年間同じことを続けている。その点では、Redisの中にサブプロジェクトを作ることで正気を保とうとしてきた。あるときはCluster、あるときはdisk-storage（今は廃止された）、またあるときはHyperLogLogといった具合だ。いずれもプロジェクトに価値をもたらしつつ、単体で見れば別の事柄に取り組んでいる感覚を得られるものだ。だが結局は、issueやPRのページに戻り、毎日同じような問題に向き合わなければならない。「タイムアウトでレプリカが切断される」とか、そういうものだ。また一から調べ直すことになる。

恐れ

私は常に、プロジェクトの技術的なリーダーシップを失うことへの恐れを抱いてきた。自分がRedisを設計し進化させるのに十分な能力がないと思うからではない。自分のやり方が、1) かなりの数のユーザーが求めているもの、2) IT分野の大多数の人がソフトウェアとはこうあるべきだと信じているもの、と一致していないとわかっているからだ。だから私は、自分が良いと信じる設計や機能の集合、開発の速度（遅い）、プロジェクトの規模（最小限）といったものと、ユーザーの大多数から期待されているものとの間で、常にバランスを取り続けなければならなかった。幸い、Redisのやり方を完璧に理解してくれている一定割合のユーザーがいるので、時折、救われる言葉をもらうこともある。

摩擦

中にはどうしようもない嫌な奴もいる。どこにでもいる、自然なことだし、正直、プログラミングの世界は他の分野よりずっといい人が多いとさえ思っている。それでも、必ず一定の割合でとんでもない輩は現れる。人気のあるOSSプロジェクトのリーダーであれば、否が応でもそうした人々と向き合わなければならず、それはRedisの開発を通じて経験したことの中でも、最もストレスの溜まることの一つだった。

空しさ

ソフトウェアは素晴らしいが、何世紀も残る本を書くような偉大さには決してなり得ないと感じることがある。それ自体が素晴らしくないからではなく、ソフトウェアは同時に「役に立つ」ものでもあるがゆえに、より役に立つものが現れれば置き換えられてしまうからだ。他の活動をする時間も欲しいと思う。だから時々、自分がやっていることは結局すべて空しいのではないかと思う。私たちはシステムを設計し、書き、そして新しいシステムが現れる。ただソフトウェアを作り続けるだけで、「ソフトウェアにおける大きな思想」に留まるのでなければ、誰が新たな金字塔を打ち立てられるというのだろう。時々、自分には本来、大きな思想に取り組む能力があったのかもしれないのに、ソフトウェアについて考えるのではなく、ソフトウェアを書くことに集中したせいで、その可能性を活かせなかったのではないかと思う。これはいわばインポスター症候群の逆なので、自分のことを買い被りすぎなのかもしれない。謙虚であるべきなのはわかっているが、申し訳ない。

とはいえ、私は何年もの間、本当に愛することを仕事にでき、そこから友人や評価、お金も得ることができた。だから悪い取引だったと言うつもりはない。それでも、プロジェクトが人気になった途端に、なんとか持ちこたえるのに苦しんでいる人たちの気持ちは痛いほどわかる。このブログ記事は、そんな彼らに捧げたい。