クリアコードでアルバイトをしているおやまだです。このたび、二年間お世話になったクリアコードを離れることとなりました。はじめてのククログ記事が、お別れの記事となってしまいました。

この記事では、私がこの二年間で見てきたクリアコードの姿とそこから学んだことがらについて、ご紹介したいと思います。

フリーソフトウェアの会社

クリアコードで二年間働いて強く感じたのは「クリアコードはフリーソフトウェアの会社なんだ」ということです。

思い返せば、クリアコードとのはじまりもフリーソフトウェアでした。二年前、私の公開するフリーソフトウェアをみた社員の方が、うちに興味はないかと連絡をくれたのです。当時は採用プロセスにペアプログラミングがあり、私も社員の方と共に実際のフリーソフトウェアの機能拡張をおこないました。

驚いたのは、そこでおこなった機能拡張が実際のリポジトリにコミットされ、公開されたことです。フリーソフトウェアへ可能な限り貢献していこうという思いを感じ、ここで働いてみたいと改めて感じた記憶があります。

なお、現在ではこの採用プロセスをさらにおしすすめた「パッチ採用」と呼ばれる仕組みがとられているようです。

同じ問題にぶつかる人を少なくしたい

この記事を書くにあたり、クリアコードがどのような哲学で開発を進めているかを書いた「開発スタイル」を読みました。そして、驚きました。私自身が開発において無意識のうちに気をつけていることが書かれていたのです。「ああ、二年間ここで働いていたのだな」と、そのときはじめて実感しました。

一つ、印象に残った部分を引用します。

ソフトウェアを開発していると既存のソフトウェアの問題にぶつかることがあります。そんなときあなたならどうしますか？既存のソフトウェアの開発元に問題を報告するかもしれません。自分が開発しているソフトウェア内で問題を回避するかもしれません。

クリアコードの開発スタイルは「既存のソフトウェアの開発元に問題を報告し、可能なら問題を修正するパッチを添える」です。ソフトウェアの開発元のことをupstream（アップストリーム）と呼ぶこともあるため、「upstreamで直す」と呼ぶこともあります。

個人的な話になりますが、二年前の自分にはこれができていませんでした。そこそこプログラムが書けるようになり調子に乗っていたのでしょう。既存のソフトウェアに問題を見つけたならばTwitterで文句をいう。そして、問題が修正できそうであればソフトウェアをforkし、元の作者には連絡の一つもよこさない。そんなことが、よくありました。一言であらわすならば、他のソフトウェア開発者とのコミュニケーションを避けていました。

この二年間で、私は変わりました。既存のソフトウェアに問題を見つけた場合、TwitterではなくIssue Trackerへ問題を報告するよう心がけるようになりました。ソフトウェアをforkした場合も、可能であればオリジナルの作者に変更点を取り込んでもらえるようパッチやPull Requestを送ります。

クリアコードは間違いなく、この変化の一因でしょう。ひとつ、印象的なできごとがあります。入社当初、既存のソフトウェアに不可解な挙動を見つけたときのことです。当時、私は実力を認めてもらおうとやっきになり、いかに短い時間で美しく目的を達成するかをモットーとしていました。そんな考えの私ですから、不具合が手元で修正できたら、次の作業に移ります。すると、まもなくして社員の方から声がかかりました。

「なんでこれ、開発者の人に問題を報告しないの？」

それがいかにも不思議といった口調なので、だんだん私にも不思議に思えてくるのです。なぜ自分は、問題を報告しようとしなかったか。そこではじめて、自身の自分本位な姿が見えてきました。コードに名を残すことへ執着し、他人のことを考えずにコードを書いている。そんな自分が嫌で、私は変わっていったのでしょう。

「開発スタイル」から、もうひとつ印象的な部分を引用します。

それでも、クリアコードの開発スタイルでは既存のソフトウェアを修正する方向でどうにかできないかを考えます。なぜなら既存のソフトウェアで問題が修正された方がうれしい人が多いからです。同じ問題にぶつかる人を少なくしたいのです。

同じ問題にぶつかる人を少なくしたい。これは、私の開発哲学のいしずえとなっています。

メンテナンスを続けること

世のソフトウェア開発者の多くができていないことの一つに、ソフトウェアの継続的なメンテナンスがあるのではないかと常々思っています。

近頃、メンテナンスのされていないソフトウェアを目にする機会が増えました。GitHubなどにより、衆目に触れるコードの母数が増えたことが一因でしょう。私はそんなソフトウェアを見ると悲しい思いとなります。そして、自戒します。

恥ずかしながら、私も全てのソフトウェアのメンテナンスはできていません。興味を失ってしまったソフトウェアのメンテナンスは、どうしても苦痛に感じられてしまいます。周囲の開発者も、そういった人ばかりでした。これが開発者というものなのだと、そう思っていました。

クリアコードに来て、状況が一変しました。私と比べ何倍ものソフトウェアを抱える方々が、プライベートでそれらの一つ一つをこまめにメンテナンスしている。それでいて、苦痛に思っている様子もない。中には、十年近く開発が続けられているソフトウェアもあります。

そうした姿をみて、はっとしました。

クリアコード代表取締役の須藤さんは、過去のインタビュー記事（OOエンジニアの輪！～ 第 39 回 須藤 功平さんの巻 ～）で次のように述べています。

ゴールにたどり着くまでに、必要なライブラリが無かったら作っていって、たどり着くのがハッカーなんじゃないかと思うんです。出来上がったきれいな道を上手に通っていくんじゃなくて、通った後に道ができている感じです。

でも最近はあんまりハッカーにならなくていいなと思ってるんです。(なぜかというと)メンテナンスし続けるハッカーはあんまりいない気がするんですよ。

新しいのを作って、みんなにすごいって言われて、じゃぁ、次また新しいネタを思いついたからまたすごい勢いで作って、と繰り返していくので、ハッカーの人って作った後にすぐどっかいっちゃうんですよね。

私はちゃんと続けてメンテナンスすることとか、続けていくことも大事だと思ってるんで、(どこかに行ってしまうような)ハッカーになりたくないなっていうことに、最近ようやく気づきました。

そして「開発スタイル」には、次のようにあります。

フリーソフトウェアの開発において、開発者自身が楽しいとか嬉しいと感じることはとても大事なことです。楽しいことがモチベーションだった開発者は、楽しいと感じられなくなるとそのソフトウェアの開発から手を引きます。手を引いた開発者はまた別のソフトウェアを楽しく開発するかもしれません。ある開発者が手を引いたソフトウェアでも、別の開発者が参加して楽しく開発することがあります。

メンテナンスされなくなったソフトウェアは、危険です。いつ爆発するかわからない問題を抱えていても、それを取り除いてくれる人がいない。そして、環境の変化と共に動作しなくなっていく。かつて輝きを放っていたソフトウェアがそのような姿になっていくのを見るのは、悲しいことです。

では、そのようなソフトウェアを減らすにはどうしたらよいでしょうか。もっともよいのは、自分がソフトウェアのメンテナンスを続ける人になることでしょう。しかし、モチベーションを失ってしまった場合、これは一筋縄ではいきません。そんなとき、どうすればよいでしょうか。

クリアコードで二年間働き、その問いに対する私なりの答えが一つ見えてきました。それは、いつでも他の人がソフトウェアのメンテナンスを継続できるようにしておくこと、というものです。自分がソフトウェアの開発をやめたとき、他の人がすぐにそのソフトウェアのメンテナンスを引き継いで開発できるようにしておくこと。このためにできることは、たくさんあると思います。ドキュメントをきっちりと書いておくこと、ライセンスを明記しておくこと、そして読みやすくきれいなコードを書くこと。もっとも重要なのは、その意識をもってソフトウェアの開発に取り組むことでしょう。

できることならメンテナンスを続け、それが無理なら他の人がメンテナンスできるような状態にしておくこと。これを、開発者としての心構えにしていきたいものだと思います。

きれいなコード

きれいなコードは、メンテナンスしやすい。クリアコードで既存のソースコードをいじることの多かった私は、この二年間でその事実を身をもって感じました。

きれいなコードを書くこと

この記事をご覧になっている方々の多くは「クリアコード」という社名の由来をご存知のことかと思います。Clear Code。きれいで、見通しのよいコード。その名を冠するクリアコードでは、開発時にめいめいがきれいなコードを書けるよう、いくつもの仕組みが働いています。

例えば、コミットメールと呼ばれるシステム。誰かがコミットをおこなえば、そのコミット情報がdiffとともに全ての開発者にメールで送信されます。メールを受け取った開発者は、気が向けばdiffを読み、そのなかに気になる点があれば指摘をおこなう。ここククログでもたびたび紹介されているので、おなじみでしょう。

そんなクリアコードで二年を過ごし、私のきれいなコードに対する意識は変化しました。クリアコードに入る前、私の考えるきれいなコードとは、インデントがそろい、代入記号がalignされ、関数が一画面におさまるようなコードに他なりませんでした。クリアコードに入って二年、コミットメールやGitHubのコメント経由で数多の指摘を頂いて、少なくともこの考えは変わっています。

きれいなコードを語ること

一方で、きれいなコードとはなにかと問われたときに、クリアな答えを述べる自信はいまだにありません。きれいなコードの書き方を人に伝えることができず、もどかしい思いをすることが数多くあります。

原因を考えてみました。おそらく、その一端は私が代表取締役の須藤さんを「きれいなコードの導師（guru）」だと認識してしまったことにあるのだと思います。きれいなコードに関する哲学を持ち、その哲学を他の人々へ伝えようと努力されている、導師。そんな須藤さんの教えが絶対だと思ってしまった。

私はこの二年間で、ほとんど他の人の書いたコードに口を挟みませんでした。そもそもアルバイトなので自分の関わるプロジェクト以外のコミット情報がわからなかったというのもありますが、もしそうでなかったとしても、状況は変わらなかったでしょう。どちらにせよ、考えることは同じです。

「このコード、ちょっと気になるな。でも私が黙っていても、たぶん須藤さんが指摘してくれるかなぁ。おそらく、もっとよい表現方法で」

もっと、コードの書き方に口を挟むべきでした。的確でなくとも、間違っていても、よかった。それらをきっかけにして議論が生まれれば、お互いに気づくこともあったでしょう。いま、クリアコードを離れるにあたって、このことを心残りに思います。

そこで、これは宿題だと考えることにしました。きれいなコードの書き方について議論をふっかける人間になること。それを、新天地で心がけていきたいと思うようになりました。そして、この記事を書いて思いは強まり、それは決意へと変化しています。クリアコードの名に恥じぬように、と。

おわりに

この記事では、いちアルバイトである私がこの二年間で見てきたクリアコードの姿と学んだことについて、ご紹介しました。

私にとって、クリアコードは、フリーソフトウェアの会社で、ソフトウェアのメンテナンスに力を注ぐ方々がたくさんいて、そして人一倍きれいなコードにうるさい人々のいる場所でした。そんな職場で働かせてもらった二年間は、私の開発者人生の糧となることかと思います。クリアコードの皆さん、充実した二年間を本当にありがとうございました。