ここ数日、2つのAPIをきちんと仕上げることに費やしている。モジュールに関する新しいAPIと、新しいRedisのデータ型だ。*何日も*と言ったら、本当に何日もだ。APIのためだけにだ。下書きを書き、データ構造や呼び出しを形作りながら実装を始め、そしてまたゼロからやり直して、より良い形で練り直す。設計と、ユーザーが直接触れる部分を良くするために。

なぜそこまでして、機能の提供を何週間も遅らせるのか。本当にそれほど重要なことなのか。プログラマはエンジニアなのだから、システム側が出しやすいAPIに適応すればいいだけではないのか。

この修辞的な問いにいちいち答える必要はあるだろうか。いや、今日ではもう必要ないはずだ。それ自体が大きな前進だ。

ここではもう、プログラマにもユーザーインターフェースがあるということ、そしてそのUIがシステムの印象を根底から変えてしまうほど重要だということは、暗黙の前提として共有されていると考えたい。データベースのクエリ言語、ライブラリの呼び出し、プログラミング言語、Unixのコマンドラインツール、これらすべてにUIとしての側面がある。毎日それらを使う人にとって、それらは何よりもまずUIなのだ。

では、これがすでに広く知られていることなら、なぜわざわざこの記事を書いているのか。グラフィカルなUIだけでなく、プログラマ向けに設計されたUIにおいても、シンプルさという概念がいかに重要かを強調したいからだ。シンプルなUIという解を見つけるために何度も何度も反復する行為は、完璧主義ではない。無益なナルシシズムでもない。それはむしろデザインという空間における探索なのだ。その空間は時として広大で、小さな違いが大きな差を生み、大きな違いが視点を根本から変えてしまうこともある。従うべき決まったルールはない。あるのは自分の感性だけだ。確かにベストプラクティスは存在するが、航海すべき海がデザインという*空間*であるとき、それらは頼れる羅針盤にはならない。

ではなぜ、プログラマが優れたシンプルなUIという特権を持つべきなのか。もちろん、よく作られ、扱いやすく、*しっくりくる*と感じられるものを使う喜びもある。しかし、より中心的な問題がある。M4マクロでSendmailを設定することを覚えたり、Apacheのバーチャルホストの設定に苦労したりすることは、本当の知識ではない。もしそのシステムがいつか使われなくなったら、手元に、いや脳の中に何が残るだろうか。何も残らない。それはアドホックな知識だ。ジャンクフードのようなものだ。微量栄養素のない、空っぽのカロリーに過ぎない。

プログラマにとっての微量栄養素とは、数十年にわたって残り続けるアイデアのことであり、アドホックなジャンクではない。私はジャンクを出荷したくない。だから出荷する前に、デザインを磨き込み続けるつもりだ。あなたもジャンクを受け入れるべきではない。あなたの脳は、汎用的な概念を学ぶために使うべきだ。とはいえ、ある程度は避けられない。どんなシステムにも、それを使うために学ばなければならない非汎用的な部分は存在する。そうであるなら、せめてそのアドホックな部分はシンプルなものにしよう。できれば、使っていて楽しいとさえ感じられるものに。