採用情報 - クリアコード

クリアコードではプログラミングを楽しむソフトウェア開発者と「クリアコードをいい感じにする人」をそれぞれ1名募集しています。ソフトウェア開発者の採用情報はこのページで説明します。「クリアコードをいい感じにする人」の採用情報は「クリアコードをいい感じにする人」の採用情報ページで説明します。

ソフトウェア開発者は「パッチ採用」という選考プロセスを用います。

パッチ採用

クリアコードはフリーソフトウェアを活用してソフトウェアを開発しています。

私達クリアコードのメンバーが業務でも使っている開発スタイルはフリーソフトウェアの開発の中で学んできたことです。私達はこの開発スタイルでお客さんの問題を解決するソフトウェアを開発しています。

私達は、クリアコードの開発スタイルを優れたものだと考えており、新しく一緒にソフトウェアを開発する人とも同じ開発スタイルで開発したいと考えています。しかし、これまで行なってきた面接とペアプログラミングによる選考プロセスでは、クリアコードの開発スタイルにあうかどうかを判断することが困難だとわかりました。ここの「判断する」は、私達だけが判断するという意味ではなく、私達と応募者がそれぞれ判断するという意味です。判断することが難しい理由は後述します。

そのため、私達も応募者もクリアコードの開発スタイルで一緒にソフトウェアを開発していけるかどうかを判断できる選考プロセスを考えました。それが「パッチ採用」と呼んでいる選考プロセスです。

注意

選考プロセスを説明する前にあらかじめ注意点に触れておきます。この選考プロセスでは、応募者は従来の就職活動とは違う活動をする必要があります。例えば、面接対策よりもよいコードを書くことや他の開発者との円滑なやりとりに注力する必要があります。これは応募者にとって大きな負担となる可能性があります。

応募する際は本当に就職候補の会社としてクリアコードを検討してもよいのかを十分に考慮してください。

選考プロセス

パッチ採用は以下のような選考プロセスです。

応募者: プログラミングが楽しいことを再度自分で確認する。
応募者: 会社説明会に応募する。
クリアコード: 応募者に会社説明をする。
応募者: クリアコードに興味があれば、クリアコードのメンバーがコミット権を持っているフリーソフトウェアの開発に参加する。具体的には、パッチを送り、パッチに関してやりとりをする。
（クリアコード・応募者: 定期的に一緒に開発してどう感じているかをお互いにフィードバックする。「定期的」の期間は相談して決める。例えば、「1ヶ月に1回」など。）
応募者: 開発に参加した結果、「自分は応募資格（後述）を満たした」と判断する。
応募者: クリアコードに応募する。
クリアコード: 応募者と面接し、一緒にフリーソフトウェアを開発した経験から、業務でも一緒に楽しく開発していけそうかを話し合う。
クリアコード: クリアコードが一緒に楽しく開発できそうだと判断したら応募者に待遇を提示する。
応募者: 提示された待遇でクリアコードで一緒に楽しく開発できそうだと判断したら就職する。

「パッチ採用」の名前は、開発に参加するところでパッチを送ることに由来しています。

採用を検討する段階では、応募者が新卒かどうかや、学歴、前職などは重視しません。一緒に開発した経験を重視します。

「応募資格」は以下のいずれかです。

クリアコードのメンバーからコミット権をもらっていること
コミット権をもらっていなくても、クリアコードの開発スタイルを実践できていると自己判断していること

どちらのケースも、応募者がクリアコードの開発スタイルを実践できていると認められたかどうかが基準となります。前者はクリアコードのメンバーが認めたケースで、後者は応募者自身で認めたケースです。どちらが認めたケースでも応募可能です。ただし、応募資格を満たしたとしても必ずしも就職できるとは限らないことに注意してください。クリアコードが就職しない方がよいと判断する場合もありますし、応募者が判断する場合もあります。

なお、選考プロセス中で開発した成果はクリアコードに就職するかしないかに関わらず自由に利用可能です。これは開発対象のソフトウェアがフリーソフトウェアだからです。

パッチ採用で開発スタイル全体を確認できるか

パッチ採用は、これまでの選考プロセスでは判断することが難しかった「お互いに開発スタイルを確認する」を実現することが目的です。本当に確認できるのかを検討してみましょう。

これまでの選考プロセスでは社長と応募者でペアプログラミングをしていました。ペアプログラミングの題材はクリアコードが開発に関わっているフリーソフトウェアの中から、クリアコードのメンバーと応募者で相談して選んでいました。ペアプログラミングをすることにより、クリアコード側は「この人はよいコードを書ける人だ」ということがわかります。このことから、「もっと大きな問題でもよいコードを書けるだろう」ということなどを想像できるようになります。しかし、これは開発スタイルの一部しか確認できておらず、他の開発スタイルは想像することになります。応募者は、クリアコードのメンバーが書いたコードを題材にするため、クリアコードのメンバーがどのようなコードを書いていたかがわかります。しかし、どのように開発しているかまではわかりません。

例えば、開発中に使用しているソフトウェアの問題を発見した場合は、そのソフトウェアへ問題を報告し、可能ならパッチを添えるのがクリアコードの開発スタイルです。問題を発見しても、手元で適当に回避しておいて問題を報告しない人とは一緒に開発できません。応募者が入社後に「こんなに徹底していると思わなかった」となるようでは応募する側がちゃんと確認できていなかったといえます。

このように、開発スタイルの一部しか確認できないため、開発スタイルを理解した上でお互いが判断する、ということができません。

一方、フリーソフトウェアを一緒に開発する場合は、開発の一部分を切り取ってペアプログラミングする場合とは違って開発そのものになります。そのため、一部から全体を想像する必要はありません。また、応募者がコードを書くだけではなく、クリアコードのメンバーもコードを書きます。そのため、クリアコードのメンバーが応募者のコードを確認するだけではなく、応募者もクリアコードのメンバーがちゃんとしたコードを書くのかどうかを確認できます。

これにより開発スタイル全体をお互いに確認できるため、適切な判断ができるようになると考えています。

パッチ採用をしたい理由

クリアコードはフリーソフトウェアの開発を大事にしている会社です。そのため、選考プロセスにもフリーソフトウェアの開発に由来する方法を持ち込めないかと考えました。なぜなら、その方法がクリアコードにとって自然だからです。

そう考えたとき、クリアコードのメンバーはパッチをやりとりするなど一緒に開発することで相手のことをわかっていくことを思い出しました。クリアコードで必要としている選考プロセスは相手のことをわかって一緒に開発していきたいかを確認するプロセスです。であれば、一緒に開発する方法を使うことがクリアコードにとって自然でとても大事なことではないかと考えたわけです。そして、フリーソフトウェアの開発では「コミット権」をもらうことが1つの信頼の目安になります。そこで、それを応募条件としました。

参考までに、フリーソフトウェアの開発で「コミット権」とはどういうものかを説明します。

フリーソフトウェアの開発では、その開発コミュニティ内で信頼されると「コミット権」という権利をもらえます。これはソースコードを自分で直接変更してもよいという権利です。フリーソフトウェアではソースコードはとても大事なものなので、これを直接変更してもよいということは、信頼の証となります。

通常、コミット権をもらえるくらい信頼されるには以下のようなプロセスになります。

問題を修正するパッチや機能を改良するパッチを送る
パッチやパッチが扱う領域について開発者とやりとりをする
↑を何度も繰り返す

開発者はパッチ提供者のコードやパッチ提供者のやりとりの中から、「この人はよいコードを書く人だな」、「この人とはコミュニケーションがとりやすいな」などといったことを感じ取っていき、「この人と一緒に開発したい」と思うと「コミット権いりませんか？」と声をかけます。パッチ提供者もこのやりとりの中で「この開発者とはコミュニケーションがとりやすいな」などといったことを感じ取っています。その上で「この開発者と一緒に開発したい」と思えばコミット権を受け取り、より積極的に開発に参加します。

このプロセスの中で、開発者もパッチ提供者もお互いに一緒に開発していけそうかどうかを判断していました。クリアコードでも同じように一緒に開発していけそうかどうかを判断したいと考えています。

採用プロセスにあまり期間を使えない応募者向けの対策

クリアコードは「継続的に一緒に開発をしていきたい」と思える人を採用したいと考えています。理由は、クリアコードは「作って終わり」の開発ではなく「作って改善していく」開発を重視しているからです。たとえ優秀でも「一時的にだけしか一緒に開発できない」人は採用しません。クリアコードの開発スタイルに合わないからです。

このように採用したい人かどうかを判断すると、長い付き合いになりそうな人を採用することになります。そのため、たとえ時間がかかるとしても、それが必要な時間であれば時間をかけてじっくり判断したいと考えています。もちろん、必要のない時間であれば、そんな時間はかけずに判断します。

この採用プロセスは、進め方によっては短く終わることも何ヶ月もかかることもありえるプロセスです。たとえば、平日は仕事をしていて休日の数時間だけしかフリーソフトウェアの開発をできない応募者は時間がかかる場合が多いでしょう。これは、クリアコードと応募者が一緒に開発する経験がなかなか増えないため、お互いが判断する材料を得るために時間がかかるからです。

このような場合の対策を1つ検討しています。実際に適用するかは応募者と相談することになります。できることならば、この対策を使わないで済むほうが望ましいと考えています。

この対策は「一定期間内に結論を出す」ことを実現するための対策です。この対策は次の通りです。ざっくり言うと「少し給与を払うので、一定期間まとまった時間を採用プロセスのために確保して、その期間内の活動で判断しよう」という方法です。

クリアコード: 応募者を試用期間付きの雇用契約を締結する。（例えば3ヶ月を試用期間とする。）
クリアコード・応募者: 試用期間内で一緒に開発する。
クリアコード・応募者: 試用期間が終わったらこれからも一緒に開発したいかを確認する。
クリアコード・応募者: 一緒に開発したいと思えたら雇用契約を継続する。
クリアコード・応募者: 試用期間の途中または試用期間後にどちらかまたは双方が一緒に開発したいと思えなかったらたら雇用契約を解除する。

ポイントは次の3点です。特に最後の点により「一定期間内に結論を出す」ことが実現できると考えています。最後の点をカバーするのがその他の点です。

雇用契約を結んでいるので、一緒に開発する期間はクリアコードが応募者に給与を支払う。（通常の採用プロセスでは支払わない。給与は低め。）
試用期間中は一緒に開発する。集中的に一緒に開発するため、判断する材料を得られるはず。
試用期間終了までに必ず結論をだす。（通常の採用プロセスでは結論を出すまでの期間を設定しない。給与は通常の水準になる。）

なお、クリアコードの通常の雇用契約ではいわゆる試用期間は設定しません。パッチ採用で十分判断できていると考えているからです。

プロジェクトリスト

パッチ採用ではクリアコードのメンバーが開発に関わっているフリーソフトウェア開発プロジェクトで一緒に開発をします。会社説明会時に興味のあるプロジェクトについて聞くので、プロジェクトリストを確認しておいてください。

募集要項

募集人数

数名

職種

ソフトウェア開発者（正社員）

応募資格

プログラミングが楽しいこと。
クリアコードの開発スタイルを実践できること。詳細は「パッチ採用」の説明を参照。

※新卒、中途は問いません。

待遇

経験・能力などを考慮し優遇

勤務地

東京都豊島区

福利厚生

各種社会保険完備
退職金制度
社宅制度
従業員持株制度
社内食事会（毎月肉の日）
社員旅行、開発合宿

応募方法

まずは会社説明会をお申し込みください。申込みにあたっては以下のような内容のメールを須藤（kou@clear-code.com）に送信してください。

To: kou@clear-code.com
Subject: 会社説明会参加希望

名前: ○○××
備考: （希望日時などがあれば）

業務内容

クリアコードでは主にフリーソフトウェアを活用したソフトウェア開発・開発支援・ユーザーサポートを行っています。現在の主な業務は以下のとおりです。

開発・ユーザーサポート：全文検索エンジンGroongaおよび関連ソフトウェアの開発およびユーザーサポート。
開発：Groongaを使った検索システムの開発。
開発・ユーザーサポート：Mozilla Firefox、Thunderbirdの企業導入、アドオン開発。
開発：milter managerおよびmilterの開発。
開発支援：お客さんが開発しているOSSの開発へ参加。たとえば、Fluentdの開発へ参加したりSMSさんのdaimonプロジェクトへ参加したりしています。
開発支援：お客さんのエンジニアがOSS開発に参加することを支援。たとえば、やり方を伝えたり相談にのったりバグレポートやパッチの内容をレビューします。

業務の特徴

開発では、有用な技術を幅広く活用することが多くあります。例えば、Ruby on RailsだけでRubyを活用するのではなく、手早く実用的なテストを開発するためにRubyを活用したり、アプリケーションにRubyを組み込んで柔軟性を実現したりします。流行の技術を追いかけるだけではなく、しっかりとした技術を身につけ、応用・活用したい方にはやりがいのある業務です。

また、クリアコードは成果をオープンにすることに積極的です。業務時間内に既存のフリーソフトウェアに開発成果をフィードバックしたり、業務で開発したソフトウェアをフリーソフトウェアとして公開することは「当たり前のこと」としています。またブログでは業務を通じて得たノウハウなどを公開しています。