オープンソース コミュニティでリーダーシップを構築する

オープンソース コミュニティに溶け込むには、時間と労力を要し、また、製品開発への新しいアプローチを施行することが必要となります。従来のプロプライエタリ製品の開発は、機密性と管理の階層を必要としますが、オープンソース開発は、オープンであることが必要であり、意見の一致を重要視します。役職や地位ではなく、コードの貢献こそがオープンソース プロジェクト内での影響力と技術的方向性を決定付けるのです。

オープンソース プロジェクトは、独自のルール、慣習、ツール、そしてプロセスを持つ、多様かつ地理的に分散されたコミュニティで開発されます。端的に言うと、各コミュニティには独自の文化がありますし、オープンソースに影響力を発揮するために必要とされる信頼を確立し、協働の仕方を学び、文化を理解するには時間がかかるものです。

本ガイドは、ある組織が関与し、商業的に依存しているオープンソース プロジェクト内で、リーダーシップと影響力を構築するための方法を説明します。本ガイドを通じて、リーダーシップの文化とプロジェクト内での役割、決定がどのように下されるか、組織がリーダーシップを構築できるかを学び、そしてオープンソース コミュニティで良いリーダーになるためのヒントを得てください。

内容

1. オープンソース プロジェクトでリーダーシップを構築する理由
2. オープンソースのリーダーシップ文化
3. リーダーになるには
4. 結論

ガイド一覧 »
GitHub上で貢献する »

オープンソース文化は、協働的ではありますが、アップストリームの貢献は、オープンソース プロジェクトを進展させる第一歩に過ぎません。そのプロジェクトが、企業・組織の製品にとって必要不可欠な場合、プロジェクトの方向性を主導し、影響を与える上で積極的な役割を担うことも重要です。

オープンソース プロジェクトが、競合他社も巻き込んだ協働活動による価値の創出を繰り返し生み出していることは、まぎれもない事実であり、多くのオープンソース プロジェクトの成果物がデファクトになっていることで証明されています。このようなプロジェクトにおける方向性に関して発言権がないということが、競争上の優位性を失うことにつながることは明白です。これこそ、オープンソース プロジェクトでのリーダーシップを構築、維持することが、企業の戦略と目標のカギとなる理由です。ただし、この実現は、机をドンと叩いて主張したり、金銭的な影響力を振り回したりすれば成し得るほど簡単なことではありません。

企業がオープンソース コミュニティにおけるリーダーシップの仕組みについて考える時、会社内のリーダーシップと同じように働くと考えると思いますが、そうではありません。

企業・組織がオープンソースでのリーダーシップ獲得を目指すべき理由

企業 VS オープンソース リーダーシップ

オープンソース プロジェクトでリーダーシップを獲得することが、商業世界における企業自身の成功に欠かせないものである中で、全く違った新しいアプローチを製品開発に取り入れることは、しばしば直感に反するものであり、始めは落ち着かないかもしれません。

従来のプロプライエタリな開発は機密性と管理階層を必要とします。これと比較すると、オープンソース開発では、役職や地位は意味を持たず、オープン性とコンセンサスが重要視されます。

コードの貢献こそが、オープンソース プロジェクト内での影響力と技術的方向性を決めるものです。つまり、コードでの貢献は、ごまかしが効きません。コードは、本質的でかつ本当の意味で、プロジェクトを何らかの方法で真に進展させるものでなければなりません。

初めは、アップストリームに貢献し協働することが、自社の資産を持ち出しているように感じられるかもしれません。しかし、その感情は、オープンソースの現実に基づくものというより、一般的な考え方、行動を大きく変化させるときの不安感から来る痛みによるものであり、イノベーションを起こすためには特に必要となるものです。

オープンソース リーダーシップの考え方には、以下の項目に関して考えることが含まれます。

• 「制御力」ではなく、「影響力」
• 「露出」ではなく、クラウド ソーシングの1つの方法としての「リーダーが実現したいアイディアを公開し、それに賛同する人が資金を出すという意味での透明性」
• 集団・グループを「統制する」ではなく、「リードする」

プロプライエタリからオープンソースの考え方・文化への移行を成功させるには、時間と努力、それを実行することのメリットについて定期的に再検討することを必要とします。Samsung Electronics社のR&D担当バイスプレジデント兼オープンソース グループ長であるIbrahim Haddad氏は、この理解を進み易くするため、以下のチャートを作成しました。

ガバナンスの概要

オープンソース コミュニティにおけるガバナンス ガイドラインは、項目が少ないことがほとんどではあるものの、厳格に執行されています。行動規範またはコミュニティ ガイドラインは、そのコミュニティ固有のものですが、一般的に許容でき期待される行動と許容できない行動を取り扱う手順、そしてその他のインシデントの取り扱いについて言及しています。ガバナンス ポリシーは、オープンソース プロジェクトのポリシー、構造とロードマップの管理に関する詳細を規定します。メンテナンス ポリシーは、通常、ソフトウェア更新など、その他のプロジェクトに関する決定について規定します。

しかし、プロジェクトやコミュニティ レベルのガバナンスは、ガバナンス ポリシーや問題の全体を表すものではありません。また、オープンソース ソフトウェアが商業的な利益のため、またはその他の組織により使用する、貢献する、再配布または製造される場合にも、そのようなガバナンスが存在します。つまり、オープンソース ガバナンスは必然的に、より広範なITガバナンスの取り組みの一部であると言えます。

企業は、オープンソースの消費方法にまつわる複数のプロセス、コミュニティにおけるアップストリームの貢献をするための方法に一貫性がないこと、オープンソース プロジェクトが社内で作成される際の違いなど、企業が同じような種々の問題を経験する傾向にあります。上記のような問題に対しては、標準的なガバナンス対策を構築すれば、混乱を和らげることができます。

それぞれの企業が、実際の取り組みに最も合うよう、自社のオープンソースに対するガバナンス ポリシーとプロセスの具体的な内容を検討することが最善です。これは、実際にコミュニティ レベルでガバナンスが最も効果的に発揮される方法とよく似ています。ただし、企業・組織内でのすべてのオープンソース活動で、同一のプロセスを繰り返すことができるわけではないことに注意してください。

一貫性のあるガバナンス計画は、オープンソースのライセンスとセキュリティの問題だけでなく、大きなバージョン間の歪曲も防ぎます。「オープンソースの消費についての一貫性のあるガバナンスモデルは、コンプライアンスの保証に役立ち、私たちが何かを出荷する際には、正しいライセンスへのコンプライアンスが実践されていると確信することができます。」

文化の概要

組織の社内文化をオープンソースの考え方に変えることが急務ですが、それは、社外にあるオープンソース コミュニティを見失うことなく、またそこから切り離さずに達成する必要があります。

それは、口で言うほど簡単なことではありません。争いや反対がよく発生しますが、それらの解決策として、コミュニティのコンセンサスに依存する多数の選択肢の中から1つを選ぶことが解になります。

Yahuda氏はこう解説しています。
「オープンソース コミュニティには、さまざまな企業に勤める人が集っており、多くの領域では共通の目的や成果を持っていますが、一部の領域では、それぞれの主張や相反する目的を持っているかもしれません」

たとえば、何か作業をするために必要な新しい機能を望む開発者がいますが、安定性を求め新しい機能を望んでいない別のグループもいます。

「新機能が安定性や拡張性を悪化させるかもしれません。それについて紛争が起きるか、少なくとも緊張が生じるでしょう」とYehuda氏は述べています。

1人の人が決断する責任を持っている訳ではないので、プロジェクトがいずれか1つの方向に前進するよう問題を解決することは容易ではないものの、その代わり、コミュニティとして決定することになります。

そのリーダーシップを構築し維持することは、個別の開発者の目標であると同時に会社のミッションでもあります。

Oathのアプローチは、所属する開発者達が潜在的に争いに発展しそうな状況に直面した場合に、会社の支援を求めるよう指示することでした。

「私達は、相談を活発に行い、状況とそれに対する最善のアプローチについて社内での話し合いを持ち、開発者がお互いにコミュニティでの議論の状況と解決策を共有するようにしています」とYahuda氏は述べています。

また、リーダーシップは、企業ではなく個人に依存するということを理解することが重要です。
よって、個々の開発者が自分の雇用主からの援助と支援を受けているにもかかわらず、雇用主はその開発者が離職を選択した場合、影響力を失うリスクがあるのです。

これは、企業・組織から複数の人員がアップストリームの貢献をしていく、ということを意味します。このようなアイデアに対するよくある反応として、他の企業も恩恵を受けるオープンソース プロジェクトに自社の多くの人的資源が拘束される、というリスクがあります。しかし、それらの人員の時間をうまく調整すれば、そのようなことはありません。

「3～4名の他の開発者とアップストリームへの貢献をするために使われる開発者の負担が共有されているため、1人当たりの時間が減ります。このことは、エンジニアリング管理に取ってより好ましい状態だと言えます」とMartin氏は述べています。

仕事の負荷のバランスを取ることで、主要な役割を担う開発者が退社して会社が影響力を失うリスクも減らすことができます。コミュニティ内でのリーダーシップ構築に積極的に参加しようとする開発者自身にとっても、結果的に自分のキャリアと収益力を高められるため、これは魅力的なプランです。このプランでは、より多くの開発者が先導的な役割を得ます。

さらに、企業はオープンソース文化に移行し、イノベーションと成功の速度を向上させ、オープンソース コミュニティとのつながりをさらに深めてリーダーシップを構築することにより開発者にとっての魅力が増すため、インナーソーシングを通じて、社内でオープンソースの実践と理念を取り入れることができます。

インナーソーシングは、オープンソースの共同開発で使用されている理念・実践と同じものを社内の全社横断的プロジェクトで採用することを指す用語です。

まとめると、リーダーシップを構築・維持する、という目標を掲げている場合、文化はたくさんの意味合いと多くのレベルで必要不可欠なものであり、故に重要プロジェクトではコントロール対策も欠かせません。

すべてにおいて、1%ルールに留意することを忘れないでください。「90%は流れに身を任せ受け身で参加します。これがユーザーコミュニティです。9%は積極的に参加してバグを報告し、公に質問に対して回答します。私達は、この9%の人々を『貢献者』と呼びます。残りの1%は、プロジェクトを指揮またはコントロールする手助けをする人で、『メンテナー』或いは『リーダー』です」とIntel社/YoctoプロジェクトのJeff Osier-Mixon氏は述べています。

それぞれのプロジェクトはユニークなものなので、プロジェクトごとに適応させましょう。

共同プロジェクトにおけるリーダーシップの役割

共同プロジェクトにおけるリーダーシップの役割は、企業での役割や構造に類似しているように見えますが、特定のコミュニティガイドラインとガバナンスポリシーによって、全てのプロジェクトが異なっており、構造化され、管理されています。役割の定義方法やプロジェクトの構造、管理方法については、マニュアルを読んだり、リアルタイムチャット、プライベートチャットのためにIRC(Internet Relay Chat)に参加したり、メーリングリストを購読するなど、してください。どのように役割が定義され、プロジェクトがどのように構造化され、管理されるかについてのガイダンスを提供します。

また、リーダーシップの役割の一般的な種類は、以下のような内容です。

技術的リーダーシップ

• コミットする人／メンテナー
•  TAB/TSCメンバー
•  TSC議長／主任アーキテクト
• 文書／テクニカル ライター – 「これは特別なケースのメンテナーです」

ガバナンスでのリーダーシップ

• エグゼクティブ ディレクター
• 委員会／準委員会
• 役員会メンバー／メンバー代表者

運用上のリーダーシップ

• プロジェクト マネージャー
• コミュニティ マネージャーと賛同者

リーダーシップの役割マトリクス

これらの役割は、歴史的な従来型の管理階層と同等の役割と似通ってはいますが、同じではありません。古いクローズド モデルの価値、プロセスと理念を新しいオープンソース モデルに単純に置き換えることはできません。多くの点で、2つのモデルは正反対或いは鏡に映ったイメージであると言えます。いずれにせよ、それらはあらゆる重要な点で異なっています。1つを選択するには、もう一方を拒否することになります。

オープンソースにおけるリーダーは、リラックスして透明性の確保に取り組み、プロジェクトを進める前にコンセンサスを得る必要があります。そのプロセスとリーダーシップのスタイルは、従来のビジネス構造に縋りつきたいと望む人々にとっては、神経を逆なでされるようなものです。

この劇的な文化の変化で、しばしば直面される不満に対して、「多くの企業は、抵抗が最小限になる道を選びます。これは素晴らしいことです。これをベースとして社内に展開していくことで、独自のやり方でやれるようになるだろう」

「問題は、長期的に見ると持続性と拡張性がないということです。なぜなら、コミュニティの他の部分から離れれば離れるほど、コミュニティから取り入れたい次の大きなアップグレードが行われたとき、より大きな困難に見舞われるからです」とMartin氏は述べています。

端的に言うと、オープンソースとはコミュニティによる取り組みであり、そのコミュニティから自分の仕事を引き離す行動は、いずれ企業・組織の不利益につながっていくということです。

協働的な環境でリーダーになるためには、相当の対人スキルと、あらゆる仕事を自分の地位に相応しくないと言って断らない意欲が必要です。

そして、もちろん、それはオープンソースにおける重要な技術的スキルと、それらを果敢に使いこなす大胆さを必要としますが、これらについてはあなたがそのコミュニティの状況を詳しく調べ、グループのダイナミクスを理解し、自分自身で割に合わない仕事を請け負ってからの話です。

言い換えると、リーダーになることは、グループの尊敬を勝ち取ることから始まります。あなたは、それを要求することはできません。自ら勝ち取らなくてはなりません。

あなたのスキルを証明し、リーダーシップを勝ち取るためにはどこから参入するべきか

プロジェクトは通常、委員会への参加方法、メンテナーのなり方、およびあらゆるレベルでの参加方法を文書化しています。それらの文書を見て、グループに馴染み始めるべき場所を見つけましょう。どこからでも、好きなところから始められますが、ただ列に割り込むことだけは避けましょう。

オープンソース カンファレンスも、コミュニティ内の他の開発者、リーダーシップに出会うすばらしい場を提供します。ネットワーキングだけでなく、そのようなイベントで発表することは、オープンソース コミュニティへのあなたの、そして自社の実績と貢献を共有するための注目すべき方法です。

Yehuda氏は、彼の会社であるOathでは、開発者のプレゼンテーション スキルを磨き、特定のプレゼンテーションを磨いてステージ上で成功するように支援している、と発言しています。練習することで完璧にプレゼンテーションできるようになるので、開発者がより多くのプレゼンテーションを行うほど、その能力が向上します。その結果として、オープンソース コミュニティにおいて、顔や名前、仕事が認識されるようになります。

しかしやはり、アップストリームの貢献が、コミュニティにおいてあなたの信任と評判を確立するのに最も効果を発揮します。自分のプロジェクトだけでなく、他の部分にも関心を持ち、バグを見つけたら修正し、コミュニティ全体の役に立つ貢献をしてください。

プロジェクトに参入する VS プロジェクトを作成する

プロジェクトへの参加は、リーダーシップ ポジションへの遠い道のりのように思えるかもしれません。確かに、時間はかかります。
しかし、これにはメリットもあります。コミュニティが既に行っている作業から恩恵を得ることができますし、自分のプロジェクトを開始する費用もかかりません。
リーダーシップを確立するという目的のために自分のプロジェクトを始めることは、あなたに多くをもたらしません。

Martin氏は次のようにコメントしています。「もし、あなた達が砂場にいる唯一の子供のグループだったら、全員が同じ会社に勤めていたら、本当にあなた達はリーダーであると言えますか？それとも、単にそのプロジェクトで働いている関係者なのですか？」

もし、あなたが新たにプロジェクトを始めるのであれば、リーダーシップを確立するという理由以外の理由で実行しましょう。なぜなら、率直に言って、そのプロジェクトに誰も参加しないということがありえるからです。それは、あなたのプロジェクトが非常にすばらしいものではない、既に確立されたプロジェクトと競合する、などの場合が当てはまります。

技術的貢献

コードの寄付は、オープンソース コミュニティにとって重大な取り組みです。プロジェクトの構築は、まさに共同課題を掲げるということを意味します。多くの手があれば仕事は軽くなり、多くの貢献があればリスクは減少し、品質が高まります。これらが目標です。

鉄則は、あなたの貢献が自分だけに役立つものでなく、他者にとって有用であることを確認することです。ただし、有用性は大きな進展に限定されるものではありません。小さなバグの修正やその他の微調整も評価されるものです。重要なのは、あなたの貢献をその規模に関わらず、誰にでも役立つものにすることです。

Ibrahim Haddad氏も、貢献者が適切なコーディング スタイルに従い、プロジェクトの提案過程の範囲内で働き、文書と説明を提供し、フィードバックを聞いて、辛抱強く承認を待つよう勧めています。

人材の採用

オープンソース開発者が不足していることは、周知の事実です。オープンソース プロジェクトの採用が高まるばかりで、鈍化の兆しが見えないことを考えると、しばらくの間はこの状況が変わらない可能性が高いでしょう。これは、スキルのある開発者を見つけるのが困難であることだけでなく、彼らを引き留めることが難しいことも意味します。

2016年のCloud Foundry Reportにおいて、「米国だけで25万のソフトウェア開発者の就職口があり、技術スキルを必要とする空きポストが50万ある」ことが報告されました。さらにアナリストは、埋められない開発者のポスト数が「次の十年間で100万名分に達する」と予測しています。

オープンソース開発者の需要は、それよりも熾烈なものです。

それでも、オープンソース コミュニティで誰が指導者であり、誰かが定期的に参加しているスキルのある貢献者であるかを把握し、彼らを直接採用することができます。或いは、彼らに一緒に働きたいと思う開発者を推薦してもらうこともできます。

「メンテナー、または強力な貢献者を採用しようと計画しているなら、それらの人々の需要が高いこと、世界で最も仕事に柔軟性を持つ人々である、ということを念頭においてください。それは、彼らが会社を渡り歩いても、同じプロジェクトに取り組むことができることを意味します。何か変わることと言えば、彼らの給料の小切手に署名する会社名だけです」とMartin氏は述べています。

オープンソース開発者の採用活動に関するさらなる助言については、このガイド集の『オープンソース デベロッパーの採用』を参照してください。

人材の育成（最善策）

幸運なことに、オープンソースはとても熱心な需要があるため、開発者達は開発に携わる、またはオープンソースでの才能を洗練させる機会を積極的に探しています。Martin氏は、彼がこれまでにインタビューした開発者は全員、彼自身のオープンソース ブランドを構築する上で、会社がどのような支援をしてくれるか、と聞いてきたと言います。開発者がオープンソース コミュニティでリーダーシップを取るような人材に成長することを支援することは、最も活性化させる方法であり、採用価値のある武器となります。

自社のオープンソース活動の認知度を高めることは、結果的に開発者の採用にも役立ちます。一部の会社では、魅力を高めるためにオープンソースに関するトレーニングを提供していたりします。展示会で会社のオープンソース プロジェクトを発表すること、コミュニティでコードに貢献することは、自社の認知度を高める最善の方法です。自社の開発者に、他の開発者とのネットワークを作らせて、入社の勧誘を依頼することも、うまくいくことが多いようです。

開発者を惹きつけるためのもう1つの重要なアプローチ方法は、実習期間を提案することです。開発者は、自分の評判・評価を築くことができる挑戦機会が多くある重要なプロジェクトに携わることを好みます。実習やメンターシップ プログラムの提供は、入社のきっかけとしての魅力を追加し、既に社内にいる人材も活用できる優れた方策です。

何よりもコミュニティの信頼を得ることで、オープンソース開発者、そして信頼できるオープンソース リーダーで働くことによってキャリアを前進させたい開発者にとって、自社の魅力を高めることができます。

「他の人と同様、商業的なモチベーションを持った開発者は、彼らの貢献の質と量を通して、プロジェクトでの影響力を獲得します」- GitHubのオープンソースガイド “Leadership and Governance” 従業員が貢献を開始したら？ (英文) より

戦略的な貢献

戦略的貢献は、リーダーシップを確立する上で重要です。このような貢献は、エコシステムを横断して共有されている大きな問題に対応する、或いはプロジェクトをコミュニティが設定しているゴールラインを超えて進める重要な進展を提供する傾向があります。
ただし、単にコードをリリースしてそれを放置することはできません。文書の提供、エコシステムの拡張、そのコードまたはツールセットをさらに進展させるためにパートナーシップを組むなど、たくさんの仕事があります。活動を続けること、認知度と信頼性を保つことがカギとなります。

技術以外の貢献と支援

技術的、戦略的、その他の貢献以外にも、コミュニティに貢献、支援して、結果的にリーダーシップ構築を推進する方法があります。

それらには、開発者の教育に貢献、支援することと、メンターシップの提供等が含まれます。技術的要素に支援を提供することは、リーダーシップ確立の成功をもたらすもう1つの方法です。

重要なのは、よく観察してコミュニティが技術的貢献以外に何を必要としているかを見極め、そのうちの一部に貢献するため、さらに力を入れることです。

要約すると、良いリーダーになること、影響力を獲得することには、時間と大きな努力を必要とします。

リーダーになるための具体的な方法には、以下が含まれます。

• オープンソース プロジェクトの文化、実践とツールに適応すること。プロジェクトになじみ、ルールとプロセスに従うよう努力しましょう。中心になるのはあなたではなく、プロジェクトであることを忘れないでください。
• 単調で辛い仕事を率先して行うこと。プロジェクトはスターだけではなく、縁の下の力持ちを必要としています。それに、仕事ができなければ、指揮する権利を勝ち取れません。あなたは仕事ができること、必要な仕事を進んでやることを、すばやくコミュニティに示しましょう。
• 寛大さを示すこと。プロジェクト全体に利益をもたらすようにコードで貢献しましょう。
• 合意を形成すること。真のリーダーは、合意を形成することができます。リーダーになる前でも、あなたがスタンドプレイをする人でも、暴君のような人でないことを証明するため、意見の一致に達する支援をしましょう。
• リーダーシップは変わっていくことを受け入れること。リーダーシップの役割が、人々を雇用する企業ではなく、人々とともに動くという事実を認識し、受け入れましょう。

これらのリソースは、TODO (Talk Openly, Develop Openly) グループとの協力により作成されました。TODOグループは、The Linux Foundation傘下のプロフェッショナル オープンソース プログラム ネットワーキング グループです。 このような包括的なガイドを作成するために時間を割き、豊富な知識を提供してくれたオープンソース プログラム マネージャーのみなさんに感謝します。TODOグループの参加企業は、Autodesk、Comcast、Dropbox、Facebook、Google、Intel、Microsoft、Netflix、Oath (Yahoo + AOL)、Red Hat、Salesforce、Samsung、およびVMwareです。詳細については、todogroup.orgを参照してください。

この資料は、Creative Commons Attribution ShareAlike 4.0 International License (CC BY-SA 4.0：クリエイティブ・コモンズ 表示 – 継承 4.0 国際ライセンス) の下でライセンスされています。