入社してはや5年目になりました。 入社した当初に入社エントリーを書いていなかったので、今更ですがクリアコードに入社した理由と、入社後に私がどう変化したかを紹介しようと思います。 入社当時の気持ちを思い出しながら書いていきます。
この記事を書いた理由は、クリアコードに興味を持ってもらって、一緒に働く仲間を増やしたいからです！ 現在、クリアコードでは一緒に働く人を募集中なので、この記事を読んでクリアコードに興味を持った人はぜひ、入社を検討してみてください！
入社前
もう既に5年以上前なのでおぼろげなのですが、入社前の私は以下のような感じでした。
- フリーソフトウェアについてはなんとなく知ってる。フリーソフトウェア = GPLっていうライセンスで配られているソフトウェアという認識。
- プロプライエタリなソフトウェアの開発をしていたので、GPLは混入してはいけないもの、GPLのソフトウェアは使ってはいけないという意識が強かった。
- フリーソフトウェアの開発は技術力がすごい必要で、気軽に参加できるようなものじゃない。
- 英語を書くのも読むのも苦手で、自分の英語でコミュニケーションをとるなんてできない。
このような状態で、なぜクリアコードに入ろうと思ったのか不思議ですが。。。
クリアコードに応募してみる
当時の私は（今もですが。。。）技術力不足に悩んでいました。 仕事上の様々な課題に対し、数ある選択肢の中でよりベターな選択肢を思いつくことが年々できなくなってきていたためです。 その場その場を乗り切ることを目的としていた開発が多かったため、技術的な積み重ねがなく、思いつく選択肢はその場しのぎのものだけになっていました。
この状態では、いずれ限界が来ることがわかっていたため、自分の技術力を向上させられる環境にいる必要があると感じました。 技術力を向上させるにはどうしたらよいか？当時の私はこう思いました「とにかくコードを書いたらいいんではないか？」と。
ということで、「コードをたくさん書ける」という観点で会社を検索し始めました。 インターネットで検索しているうちに、「クリアコード」という会社を見つけました。 そこには、以下のようなことが書いてあったと記憶しています。
「求められる経験・資質：プログラミングが楽しいこと」
これをみて、「コードをたくさん書けそうだな」と思ったのと
「クリアコードは社員の健康を大事にしています。」
という一文を見て、「社員を大事にしてくれそうだ」と思ったのが応募のきっかけでした。 「プログラミングが楽しいこと」というのも大いに響いたのですが、「クリアコードは社員の健康を大事にしています。」の方が決め手だったと思います。
パッチ採用という採用方法はやったことがなく、自信も全く無かったのですが、まぁやれるだけやってみようと思い会社説明会の依頼を送ったのでした。
今の事務所は埼玉県所沢市ですが、当時は東京都豊島区の大塚駅近くにありました。 会社説明会の日に、ちょうど事務所のエレベーターが点検中で動いていなくて事務所にたどり着けず右往左往していたのを覚えています。 （非常口から入りました。）
会社説明会で、会社の理念である「フリーソフトウェアの推進と稼ぐの両立」について説明してもらいました。 「自由」であることをとても大事にしていて、今まで「不自由」なのが当たり前だった私は「おぉ。。。世界観が全く違うな。」と思ったのでした。
まったく世界観が違う場所に行くのに不安はなかったのか？と聞かれそうですが、あんまり不安はなかったのです。 なぜなら、余計な知識がない分、かえって色々なことを吸収しやすいのではないかと思っていたのと、「この人は会社の理念に合わなそうだな」と判断されれば落とすだろうと思っていためです。
パッチ採用
会社説明会のときに、何を一緒に開発するかを決めてパッチ採用を開始しました。
そういえば、公開されているソフトウェアにパッチを送ったりIssueを立てたりするのはこの時が初めてでした。 パッチ採用のやり方は、フリーソフトウェアの開発と同じです。
取り組む問題を選択して、原因を調査、特定して修正、テストし、パッチを送る。 送ったパッチをレビューしてもらい、レビューの指摘を修正して、最終的にマージしてもらう。
のような感じです。 以下の点に注意しながら進めていきました。Issue上でのやり取りの他にメールでもやり取りしていました。
- 文字だけのやり取りなので、なるべく自分の考えていることを表明するようにした。
- 説明はなるべく具体的に。
- 作業進捗についても定期的に報告する。
働きながらパッチ採用していたので、時間の捻出が難しかったのを覚えています。 基本的に土日に作業することになるのですが、土日も出勤することがあったので作業時間が確保できなかったり、前週の作業を思い出すのに時間がかかって思うように進まなかったりしました。
そういった場合は、黙って何もしないのではなく、土日も出勤なので今週は時間取れませんとかそういった報告をメールでするようにしていた気がします。 何もアクションしないと、何をしているのか全くわからないからです。
このような形で、進捗を報告したり、わからないところを相談したりしてパッチ採用を進めていきました。 最終的に私の変更はマージされ、入社もできました。
パッチ採用の様子は以下の Pull Request で見れます。
入社
入社してからは、びっくりすることが多かったです。 以下は、びっくりしたことのリストです。
ライフステージの変化に合わせた働き方ができる。
入社してからはGroongaの開発、サポートを担当することになったのですが、Groongaチームの一人である須藤さん(社長)は、育児のためリモートワーク中心で週1回しか会社に来ていませんでした。
今でこそ、世間的にもフルリモート推進！な雰囲気ですが、当時は今と違って出社が基本！な世の中だったので、「そういう働き方もできるのか！」と驚きました。 社員のライフステージの変化に合わせて働き方を選択できるということなので、「働きやすい環境なんだなぁ。」と思いました。
成果は基本的に公開する。
入社前は非公開が基本だったので戸惑いました。説明会で説明されていたはずですが、「え？公開しちゃっていいの？ほんとに？」と思うことが多かったです。
登壇経験者が多い。
当時はイベントや勉強会で発表するなんていうのは、もう雲の上の人たちがやるものだと思っていましたが、クリアコードの人たちは何気ない感じで(何気なくないかもしれませんが、私から見るとそんな感じでした。)何かしらイベントで発表していて「おぉ。。。なにやらすごいところに来てしまった。。。」と思ったのでした。
技術にとても強い。
わからないことは、たいてい誰かが知っているか、誰かが調べ方を知っているか、調べて教えてくれることに驚きました。 「すごい人ばっかりだ！」と思ったのでした。
わからないことは気軽に聞いて良い。
自分では思いつかないやり方や、どう解決していいかわからない問題に対して、相談することでより良い結果にできます。 なので、クリアコードでは相談することを推奨しています。 わからないことは自分で調べて解決が基本だったので、びっくりしました。
発見した問題はアップストリームで修正する。
理念 > 開発スタイル にも書いてあるのですが、クリアコードでは問題を見つけたら開発元にフィードバックして同じ問題にぶつかる人を少なくするようにしています。 今までは、既存のソフトウェアに問題を見つけたら自分の作っているソフトウェア内で回避するようにしていましたが、クリアコードでは既存のソフトウェアを修正できないかを考えます。
また、業務時間中に既存のソフトウェアを修正して良いことになっています。（むしろ、そうしてくださいと言われます。） このようにすることで、別の作業で同じ既存ソフトウェアを使うことになったときに以前と同じ問題に遭遇することがなくなりますし、同じ問題で困っている人を助けることにもなるので、自分の作っているソフトウェア内で問題を回避するよりもメリットが多くなります。
自分の作っているソフトウェアで問題を回避するのが当たり前だった私は、ここでもびっくりするのでした。
現在
入社直後は上記のように、様々な驚きがあったわけなのですが、現在ではどのように変化したのかを記載してみます。 クリアコードに入社するとこんなふうに変わるという一例として参考にしてもらえればと思います。
成果を公開できるように進めるようになった。
「どうやったら成果を公開できるか」を考えて、提案を行うことが多くなりました。
成果を公開できるようにすると、案件で必要になった機能をGroongaの公式リポジトリーに取り込むことができます。 そうすると、あるお客さんで必要な機能が別のお客さんでも使えたり、Groongaがより便利になって新しいユーザーを増やすことができます。 一方、非公開の場合は、特定のお客さん向けにパッケージを作ったり、パッチを当てる必要ができてしまい、メンテナンスコストがかさみます。 これは、お客さんにとっても、クリアコードにとっても嬉しくありません。
入社直後は「成果は非公開にする」と考えていましたが、最近は上記のように公開したほうがメリットが大きいので「成果はなるべく公開する」と考えるようになりました。
ある程度、英語でやり取りできるようになった。
英語で問い合わせが来ることもあるので、そういった問い合わせに回答する時は英語で回答します。 また、GitHub上でのやり取りも基本的に英語で行っています。あと、Groongaは毎月リリースするのですが、リリースノートも英語で書きます。 入社前と比べると英語を使う頻度が大幅に増えました。
英語はとても苦手なので、回答を作るのにも時間がかかりますが、なんとか意思疎通はできています。 このあたりは、慣れだと思うようになりました。なので、英語が苦手でも書いてるうちになんとかなります。
また、最近では英語に堪能な方（クリアコードで働いて知ったことと思ったこと）が入社されたので、自分の英語に自信が無い時はその方に聞けば大丈夫です。
イベントや勉強会で発表するようになった。
前述の通り成果は公開するので、せっかく頑張って作ったものを広く知ってもらいたいと思うようになりました。 イベントで発表するのは、初めてでしたがなんとかなりました。まず、やってみるというのも大事だと思いました。 また、クリアコードでは、外部のイベントでの発表を歓迎していて、外部のイベントで発表するとそれが評価されます。
まったく発表経験がなくても練習や資料のレビューなどは、クリアコードの人はみんなやってくれるのでその点も安心できる点です。 外部のイベントでの発表の一部は以下のURLから見ることができます。
昔より相談するようになった。
今でも、相談するのが遅いとかはあるのですが、入社直後と比べたら周りに相談するようになったと思います。 相談したほうが問題も早く解決でき、より良い提案ができるので、迷ったり悩んだりした時は周りに相談するようになりました。
また、クリアコードではチームで問題解決することも大事にしています。なので、クリアコードでは、周りに相談して問題を解決するのは良いことです。
問題をアップストリームで修正するようになった。
作業中に発見した問題は、アップストリームに報告するようになりました。最初はやり方がよくわからなかったのですが、そのあたりは周りに聞くと教えてくれるので問題ありませんでした。また、一番最初は報告するのが少々怖かったのですが、数回報告すると慣れてきて報告することに抵抗がなくなります。
また、報告後にコメントをもらったがどう対処していいかわからない。ということもありましたが、その時も周りに相談すると、みんな経験豊富で「こういう時はこうするといいよ」と教えてくれたので、その後の対処も問題なく行えました。 今では「既存のソフトウェアの問題だなぁ」と思ったら、そのソフトウェアの問題の報告方法を調べて報告することが普通になっています。
あと、typoの修正等ちょっとした問題を修正するだけでも喜ばれることが多いので、「小さな問題でもちゃんとした貢献になるんだ」という発見がありました。 なので今では、ちょっとした問題でも修正してパッチを送るようになりました。
まとめ
入社して少し時間が経っているので、入社前と入社後の変化を中心に書いてみました。 入社前と全く感覚が異なるところに来ましたが、この記事で記載してきた通りなんとかなっています。
「フリーソフトウェアについてあまり知らないけど、興味はある！」というような方でも問題ありませんので、興味のある方はぜひ会社説明に申し込んでみてください！
