優れたオープンソース開発者を雇うには
※本稿は『The Business and Economics of Linux and Open Source』からの抜粋である。
オープンソースは、人的資産と組織の開発成果についての見方を根本的に変える活動である。この章では、企業がオープンソース開発者を雇うときに雇用プロセスをどのように変更すべきかと、採用候補者に求めるべき資質、そして通常この雇用プロセスに関連付けられる知的所有権条項について解説する。さらに、組織の拡張版としてのコミュニティの概念と、組織間の境界の管理方法についても取り上げる。この章の目標は、企業側の人々に次の3点を理解してもらうことである。
- より良い採用・雇用プロセスの実現方法
- 従業員、企業、コミュニティ間における知的所有権の管理方法
- 企業内のコミュニティリーダーへの接し方
開発者コミュニティから人材を雇って共同作業をすることは別のプロセスだが、それによって、候補者がどのような人物で、どんなスキルを持っているかをごく早い段階で知ることができる。
雇用ポリシー
Linuxコミュニティで長く活動し、オープンソースとフリーソフトウェアに関して強力な信念を持っているエンジニアを採用するときには、採用プロセスの時点で、エンジニア側からの新しい要求にぶつかることになるだろう。このような採用候補者は、オープンソースプロジェクトに深く関わろうとする企業で働くことに胸を躍らせていると思われるが、それと同時に、これから自分が携わるのはオープンソースプロジェクトだけだと明確に期待しているかもしれない。企業側としては、既存の従業員と新しい従業員をきちんと管理するための一連の明確な雇用ポリシーを作り上げる必要がある。これらのポリシーでは、次の要素を考慮しなければならない。
- プロジェクト — まず、新規または既存の従業員に担当させるプロジェクトをオープンソースプロジェクトだけに制限できるかを考える。コミュニティとの蜜月関係を末永く続けていくつもりの大企業ならば、そうしてもよいだろう。しかし、従業員をプロプライエタリプロジェクトに関わらせようとするならば、そのポリシーを明確にしておく必要がある。
- 著作権の所在 — 本書で何度も述べてきたとおり、オープンソースでの貢献に関しても著作権の問題は存在する。そのため、従業員の貢献についての著作権は誰が持つのか（企業か、従業員本人か、それとも両者か）を雇用ポリシーで定めておく必要がある。ほとんどの場合は、必要が生じたときに二重ライセンスを実装できるようにするために、企業側が著作権（または認可ライセンス）を持つべきである。ただしApacheやSAMBAのように、貢献についての著作権を企業が保持できないケースもある（これらのプロジェクトでは、企業が著作権を持つことを禁止するポリシーを定めている）。
- プライベートな時間と勤務時間 — 多くのエンジニアは、自分の余暇をオープンソースプロジェクトに当てることになるだろう。企業の仕事と従業員の趣味との境界線を明確に引ける場合もあれば、そうでない場合もあるだろう。また、趣味として始めたプロジェクトが企業関連のプロジェクトに発展する可能性もある。そのため、従業員が自分のプライベートな時間中にオープンソースプロジェクトにいつどのように参加できるかを明確に定義しなければならない。さらに、従業員に対して開示規則を定める必要がある。ただし、従業員に対する制約が地方の雇用法で制限されている場合もある。
- ライバル企業との協力 — 企業の人事ポリシーでは、従業員がライバル企業と協力することを制限する場合が多い。しかしオープンソースの根本的なメリットを考えると、開発成果とコストを（反トラスト法の制限内で）ライバル企業と共有するのが最善の方策になるケースもある。そのようなケースでは、開発プロジェクト内で従業員がライバル企業に積極的に関わることもあり得る。
これらの要素をカバーするポリシーとガイドラインを定めておけば、オープンソースプロジェクトに取り組み、オープンソース畑の人材を活用できるはずである。
参加ポリシー
従業員に対して、企業の経営目標が何であるかを明確にする必要がある。従業員の中には、利益を上げるために事業を行っているのだということを忘れている人もいる。たとえ直接的な収入を生み出さないプロジェクトに従事しているとしても、企業全体の目的は（サポート、サービス、ハードウェアなどの分野を通じて）利益を出すことにあるのだという点を理解していなければならない。企業のビジネスモデルをきちんと伝えておけば、従業員をコミュニティに対して最も効率的な方法で参加させることができ、オープンソースとプロプライエタリソフトウェアの間に境界線を引かなければならないときに適切な判断を下させることができる。
さらに、コミュニティへの態度も定めておく必要がある。参加させる従業員に関してプロジェクトが持たなければならない認可ライセンスは何か？ Linuxカーネルプロジェクトに携わる場合は、プロプライエタリカーネルモジュールとオープンソースカーネルモジュールに対してどのようなポリシーを定めるか？といったことを検討しなければならない。つまり、この章で紹介した要素と本書の他の部分で示した要素に基づいて、従業員とコミュニティに関する包括的なオープンソースポリシー／戦略を定義し、企業側が期待する行動規範とコミュニティへの関与の仕方を明示する必要がある。
適切な人材の採用
従業員の採用プロセスでは、その人が企業の新しい従業員にふさわしいかどうかを評価しなければならない。以降では、採用候補者について検討すべきいくつかの評価基準について説明する。このリストは、一般的な採用プロセスの評価基準に代わるものではない。採用プロセスにおいては、これらの点を補足的な評価基準として検討すべきである。
−技術分野
Linuxカーネル、ファイルシステム、Webサーバ、デバイスサーバ、ネットワーキングスタックといった技術にはそれぞれのサブコミュニティがある。大きなコミュニティについてはよく知らない採用候補者でも、特定の技術領域については最も詳しい開発者であるかもしれない。そのため、Linuxコミュニティやオープンソースコミュニティでの評価にはあまりこだわらず、目的とするサブコミュニティ内で高い評価を得ている人物を探すべきである。サブコミュニティのメンバに話を聞き、その採用候補者がどんな人物かを調べてみるとよい。
−コミュニティホーム
プロジェクトには必ずメンテナンス担当者がいる。メンテナンス担当者は、ソースベースに対する貢献を受け入れまたは拒否し、適切な公開時期を決定する役割を担う。メンテナンス担当者と貢献者との意見の相違から新しいコミュニティが生まれることもあり、これは分岐（forking）と呼ばれる（あまり頻繁に起きることではない）。これはオープンソースプロセスの最も健全な部分と言える。しかし、プロジェクト間の競争が望ましい結果にならないケースもある（Linuxカーネルなど）。優秀なメンテナンス担当者というものは、衝突を解決し、すべての開発エネルギーをあるプロジェクトの特定の技術領域に集中させることに関しては折り紙付きの実力を持っている。企業が特定のプロジェクトのメンテナンス担当者を雇うことも可能である。その場合は、その人物に企業の仕事を行わせる必要性と、その人物のコミュニティに対する責任とを比較検討する必要がある。もしもそのメンテナンス担当者／従業員が、オープンソースコミュニティにとっては有利だが企業にとっては不利な決定を下した場合、企業はそれを受け入れられるのか？という点を考えねばならない。企業がメンテナンス担当者を雇ったからと言って、企業がそのプロジェクトを管理できるようになるわけではない。Linuxカーネルのメンテナンス担当者はあくまでLinus Torvaldsであり、彼の現在の雇い主ではないということに注意してほしい。
−メンテナンス担当者か貢献者か
ここまでの説明でおわかりのとおり、ほとんどのオープンソースプロジェクトは1人のメンテナンス担当者と貢献者コミュニティによって構成されている。企業側は、新たに人材を雇おうとしている役割について明確に理解していなければならない。リーダーは数人いれば十分であり、優秀な貢献者をいかに多く集められるかがプロジェクト成功の鍵になる。さまざまな技術領域で貢献を行った経験のある人物を採用すれば、大きなプラスになるだろう。彼らはさまざまなコミュニティがどのように運営されているかをよく知っており、さまざまなメンテナンス担当者のやり方に触れている。また、これらの貢献者が過去に携わっていたいずれかのプロジェクトのメンテナンス担当者に話を聞き、彼らの貢献の品質と価値について調べてみるのもよいだろう。
リーダー的な役割を務める人物を雇いたいならば、以前にオープンソースプロジェクトの維持管理経験のある人を探す。さらに、次のようなリーダー的性質を備えているかどうかをテストする。
- 主要貢献者のことを認め、信用しているか
- 貢献者間の衝突をどのような方法で解決するか
- 衝突を解決できずに生まれたプロジェクトと対立関係になったことはあるか。それは正しい結果だったのか
- 主要貢献者を自分のプロジェクトに誘致できたことはあるか
- リリースプロセスを展開したことはあるか
- プロジェクトの公開を決定するときにどんなプロセスを使用するか
- 自分の実装よりも優れた貢献の例を挙げることができるか
メンテナンス担当者とは、技術的なスキルと、他の開発者とうまく交流しながらプロジェクトの発展を先導できる能力とを兼ね備えた特別な人物である。
−コミュニティ内での信望と評価
コミュニティ内の議題を制御する能力は、そのプロジェクトに対してどれだけ積極的に関与し、実際にどれだけ多くの貢献を行っているかによって左右される。制御権はメンテナンス担当者の手にあるのだということを思い出してほしい。プロジェクトのメンテナンス担当者は、プロジェクトの運営にあたって、貢献者の知名度とその貢献の品質を考慮する。したがって、採用候補者がそのコミュニティの中で信望と評価を得ているかどうかを検討すべきである。信望と評価の程度を調べるには、その候補者がコミュニティで行ったオンラインインタラクション（メーリングリスト、アーカイブなど）を見るとよい。
−オンラインインタラクション
採用候補者の参加コミュニティについて調査し、自社のニーズに合致しているという感触を得た後は、少々時間を取って、その人物がオンラインで他人とどのような対話の仕方をするかを調べてみるとよい。オンラインでの対話は、これからの対人コミュニケーションの主要手段である。採用候補者には、タイムゾーンや文化の異なる相手に対してうまく影響力を行使できる能力が求められる。たとえば次の点を調べるとよい。
- メールアーカイブを要求するか直接見に行って、やり取りを閲覧する。候補者の対話スタイルを調べて、企業風土に合っているか、貢献を受け入れるのに効果的かを検討する
- 候補者がオンラインで使用しているペンネームを調べる。SlashDotなどの投稿サイトのアーカイブを調査し、候補者がペンネームの陰に隠れて他人を侮辱していないか、いきなり激昂するようなところはないかを確認する
- 候補者自らが有益で魅力的なトピックについての論争を開始しているか、それとも他人の始めた論争に口を出しているだけか、そしてその意見は建設的なものか、という点を確認する
採用候補者の信望を測るには、その候補者に忠告を求める人がどのくらいいるかを調べればよい。また、その候補者の貢献が他のメンテナンス担当者にどのくらい積極的に受け入れられているかを調べるという方法もある。コミュニティ内で信望を集めている人物ならば、その人物の貢献は実質的に何の論争もなく受け入れられるはずである。
−貢献
さらに、さまざまなオープンソースプロジェクトで実際に行った貢献についての詳細リストを要求するとよい。もっとも、ライバル企業出身の候補者の場合は、プロプライエタリ製品への貢献に関する情報を得るのは不可能だろう。オープンソースの美点は、すべてのものがオープンに公開されていることだ。そのため、実際に雇ってみる前に、候補者の貢献の量、品質、技術力を調べることができる。上司や他の従業員に協力を頼めば、過去の貢献についての分析を行い、必要なフィードバックを得ることができるだろう。
貢献のスタイルについても検討すべきである。採用候補者は、具体的な問題の解決やパッチ作成といった戦術的な貢献を行っているのか、それともアーキテクチャや設計の問題に取り組んでいるのかを調べておく。この貢献のスタイルは、採用しようとしているポストのニーズに合致していなければならず、さらに未来のリーダー候補の層を厚くするものでなければならない。たとえば、サポート役としての人材を採用したい場合は、問題を発見して、その問題をシステム全体に悪影響を及ぼさずに修正できる能力を持った人物が適任である。しかし、いずれメンテナンス担当者となり、アーキテクチャの発展方向を定めるような人材がほしい場合には、優れたアイデアとそうでないものを見極める実績を持った人物を探す必要がある。
−地理的条件
オープンソースコミュニティに携わった経験がある人は、さまざまな地域、タイムゾーン、文化の人々と共同作業を行うことができるだろう。採用担当者にとって難しいのは、人材獲得の手をどこまで伸ばすかと、採用決定後にその人物がどこに居住するかである。
世界のあちこちから有能な人材を雇ってチームに合流させることができれば、企業にとっては大きなメリットになる。しかし、その方法を取る場合は、1箇所に集まって作業ができるチームのメリットと比較検討する必要がある。私の経験から言えば、最も望ましい方法は、1つのプロジェクトについては必要不可欠な人員を1箇所にまとめて配置することである。あちこちの地域にプロジェクトを分散させるべきではない。その上で、この中心チームを支援する立場として、離れた地域に済む専門的な優秀な人材を加えればよい。この方法のもう1つのメリットは、中心チームが外部のコミュニティメンバと共同作業をするときに、遠隔地の企業メンバとの関係を、実質的にコミュニティメンバとの関係と同じように管理できることだ。
自社にとって重大な意味を持つオープンソースプロジェクトに貢献したいと考えている場合は、そのコミュニティの主要メンバが行う定期的な対面ミーティング（しばしば「hackfest」と呼ばれる）に資金を提供するという方法がある。これを業務関連の業界イベントにからめて企画できれば、多数の開発者に業界を知ってもらうことができ、お互いに知己を得て、大きな発展が見られる可能性がある。飛行機代、ホテル代、食事代など、普通の従業員に認められるすべての出張経費を企業側で負担することを考えてみよう。一般的に、コミュニティの参加者たちは倹約家が多く、企業に無駄な出費を求めることよりも開発をすることの方に関心を抱いている。企業が目指すべき目標は、チームが求めるすべての設備を提供し、開発上の難しい課題を切り抜けさせることである。こうすれば、1箇所への集中と結果的なコラボレーションによって有意義な成果が生まれると思われる。
ホップカウント
コミュニティは主に影響力によって動かされている。影響力の頂点はプロジェクトのメンテナンス担当者である。大規模なプロジェクトでは、メンテナンス担当者と主要貢献者たちの間に非公式の信頼階層が形成されている。当然ながら、いつでもプロジェクトのメンテナンス担当者を採用できると考えるのは非現実的である。採用プロセスにおいては、この信頼階層を見つけ出して分析し、採用候補者と最終的な権力者（つまりメンテナンス担当者）との間に開発者が何人いるかを数えてみる。この作業は「ホップカウント」と呼ばれ、ネットワークトラフィックルーティングのそれと同様の意味を持つ。ホップが少なければ少ないほど、候補者はメンテナンス担当者に近いことになる。
チームの編成
チームの編成方法は、企業がオープンソースプロジェクトにおいて果たそうとする役割によって大きく左右される。企業バザールの概念から学んだように、企業が非常に大規模なオープンソースプロジェクトを編成し、そのチームを管理することは可能である。しかし一般的には、もっと小規模なプロジェクトに従事することになるだろう。多くの場合、企業はオープンソースプロジェクトの数多くの貢献者の中の一員になる。
前章で説明した相互利益の問題により、企業は開発者がオープンソースプロジェクト関連の外部プロジェクトに貢献し続けられるよう尽力しなければならない。
開発チームを編成するときには、「ゲート付きコミュニティ」という特殊なケースも考慮することになる。場合によっては、プロプライエタリプロジェクト、オープンソースプロジェクト、ゲート付きコミュニティ内のプロジェクトという3種類のプロジェクトを組み合わせた状況になるかもしれない。それぞれの境界に関して知的所有権と開発者の職務を明確に定義した詳細なプロセスを定めるかどうかは、企業の考え方次第である。
まとめ
オープンソースプロジェクトと非オープンソースプロジェクトを組み合わせたチームを編成、構築、管理することは、普通のエンジニアチームを管理することとは話が異なる。エンジニアたちは、コミュニティへの忠誠心と企業への忠誠心の間で複雑な悩みを抱えることになるだろう。多くの開発者はいずれこの板ばさみの苦悩にうまく折り合いを付け、それほど悩まずに済むようになるだろうが、企業側はこの悩みに気付かなければならない。この章では、採用および管理プロセスの一環として考慮すべき要素と、企業ポリシーを展開する上で考慮すべき要素について紹介した。
