ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja nb ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja en ja ja vi ja sv eu ja en en hu ja ja en en pl ja ja jbo hbs_lat en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja
応募者: 会社説明会に応募する。
クリアコード: 応募者に会社説明をする。
応募者: クリアコードに興味があれば、クリアコードのメンバーがコミット権を持っているフリーソフトウェアの開発に参加する。具体的には、パッチを送り、パッチに関してやりとりをする。
応募者: 開発に参加した結果、「自分は応募資格(後述)を満たした」と判断する。
応募者: クリアコードに応募する。
クリアコード: 応募者と面接し、一緒にフリーソフトウェアを開発した経験から、業務でも一緒に楽しく開発していけそうかを話し合う。
クリアコード: クリアコードが一緒に楽しく開発できそうだと判断したら応募者に処遇を提示する。
応募者: 提示された処遇でクリアコードで一緒に楽しく開発できそうだと判断したら就職する。
「パッチ採用」の名前は、開発に参加するところでパッチを送ることに由来しています。
内定を検討する段階では、応募者が新卒かどうかや、学歴、前職などは重視しません。一緒に開発した経験を重視します。
「応募資格」は以下のいずれかです。
クリアコードのメンバーからコミット権をもらっていること
コミット権をもらっていなくても、クリアコードの開発スタイルを実践できていると自己判断していること
どちらのケースも、応募者がクリアコードの開発スタイルを実践できていると認められたかどうかが基準となります。前者はクリアコードのメンバーが認めたケースで、後者は応募者自身で認めたケースです。どちらが認めたケースでも応募可能です。ただし、応募資格を満たしたとしても必ずしも就職できるとは限らないことに注意してください。クリアコードが就職しない方がよいと判断する場合もありますし、応募者が判断する場合もあります。
なお、選考プロセス中で開発した成果はクリアコードに就職するかしないかに関わらず自由に利用可能です。これは開発対象のソフトウェアがフリーソフトウェアだからです。
パッチ採用で開発スタイル全体を確認できるか
パッチ採用は、これまでの選考プロセスでは判断することが難しかった「お互いに開発スタイルを確認する」を実現することが目的です。本当に確認できるのかを検討してみましょう。
これまでの選考プロセスでは社長と応募者でペアプログラミングをしていました。ペアプログラミングの題材はクリアコードが開発に関わっているフリーソフトウェアの中から、クリアコードのメンバーと応募者で相談して選んでいました。ペアプログラミングをすることにより、クリアコード側は「この人はよいコードを書ける人だ」ということがわかります。このことから、「もっと大きな問題でもよいコードを書けるだろう」ということなどを想像できるようになります。しかし、これは開発スタイルの一部しか確認できておらず、他の開発スタイルは想像することになります。応募者は、クリアコードのメンバーが書いたコードを題材にするため、クリアコードのメンバーがどのようなコードを書いていたかがわかります。しかし、どのように開発し
例えば、開発中に使用しているソフトウェアの問題を発見した場合は、そのソフトウェアへ問題を報告し、可能ならパッチを添えるのがクリアコードの開発スタイルです。問題を発見しても、手元で適当に回避しておいて問題を報告しない人とは一緒に開発できません。応募者が入社後に「こんなに徹底していると思わなかった」となるようでは応募する側がちゃんと確認できていなかったといえます。
このように、開発スタイルの一部しか確認できないため、開発スタイルを理解した上でお互いが判断する、ということができません。
一方、フリーソフトウェアを一緒に開発する場合は、開発の一部分を切り取ってペアプログラミングする場合とは違って開発そのものになります。そのため、一部から全体を想像する必要はありません。また、応募者がコードを書くだけではなく、クリアコードのメンバーもコードを書きます。そのため、クリアコードのメンバーが応募者のコードを確認するだけではなく、応募者もクリアコードのメンバーがちゃんとしたコードを書くのかどうかを確認できます。
これにより開発スタイル全体をお互いに確認できるため、適切な判断ができるようになると考えています。
パッチ採用をしたい理由
クリアコードはフリーソフトウェアの開発を大事にしている会社です。そのため、選考プロセスにもフリーソフトウェアの開発に由来する方法を持ち込めないかと考えました。なぜなら、その方法がクリアコードにとって自然だからです。
そう考えたとき、クリアコードのメンバーはパッチをやりとりするなど一緒に開発することで相手のことをわかっていくことを思い出しました。クリアコードで必要としている選考プロセスは相手のことをわかって一緒に開発していきたいかを確認するプロセスです。であれば、一緒に開発する方法を使うことがクリアコードにとって自然でとても大事なことではないかと考えたわけです。そして、フリーソフトウェアの開発では「コミット権」をもらうことが1つの信頼の目安になります。そこで、それを応募条件としました。
参考までに、フリーソフトウェアの開発で「コミット権」とはどういうものかを説明します。
フリーソフトウェアの開発では、その開発コミュニティ内で信頼されると「コミット権」という権利をもらえます。これはソースコードを自分で直接変更してもよいという権利です。フリーソフトウェアではソースコードはとても大事なものなので、これを直接変更してもよいということは、信頼の証となります。
通常、コミット権をもらえるくらい信頼されるには以下のようなプロセスになります。
問題を修正するパッチや機能を改良するパッチを送る
パッチやパッチが扱う領域について開発者とやりとりをする
開発者はパッチ提供者のコードやパッチ提供者のやりとりの中から、「この人はよいコードを書く人だな」、「この人とはコミュニケーションがとりやすいな」などといったことを感じ取っていき、「この人と一緒に開発したい」と思うと「コミット権いりませんか?」と声をかけます。パッチ提供者もこのやりとりの中で「この開発者とはコミュニケーションがとりやすいな」などといったことを感じ取っています。その上で「この開発者と一緒に開発したい」と思えばコミット権を受け取り、より積極的に開発に参加します。
このプロセスの中で、開発者もパッチ提供者もお互いに一緒に開発していけそうかどうかを判断していました。クリアコードでも同じように一緒に開発していけそうかどうかを判断したいと考えています。
クリアコードの新しい選考プロセスとして考えた「パッチ採用」について紹介しました。このクリアコードらしい選考プロセスでクリアコードも応募者も納得できる選考ができると期待しています。
現在クリアコードではソフトウェア開発者を募集しています! フリーソフトウェア開発での開発の仕方をベースに、成果や知識を公開し共有しながら業務に携われます。
金融機関からの運転資金借入
2012年8月リリースまとめ
Apache Arrow
milter manager
ククログの記事はCC BY-SA 4.0とGFDLのデュアルライセンスで自由に利用できます。
クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。
クリアコードは「クリアコードをいい感じにする人」を1名募集しています。
クリアコードはフリーソフトウェア開発で培った技術力を提供しています。特にMozilla製品(Mozilla FirefoxとMozilla Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。