Microsoftのエンジニアが語るOSSメンテナーの選び方

The Linux Foundationが開催した「Open Source Leadership Summit」は、どちらかと言えば技術のトピックよりもセキュリティや組織の作り方、ガバナンスなどに関するセッションが多いという特徴がある。エグゼクティブディレクターのJim Zemlinが繰り返し強調したように「エンジニアと経営者などの他のステークホルダーが出会う場所」であって欲しいという目的にはっきりと沿った形のセッションが多く設定されていた。

今回のレポートでは、最近オープンソースソフトウェアに積極的に関わっていこうとするMicrosoftの姿勢が現れたセッションである「Maintaining Maintainer：Managing Open Source Mairainers in a World of Business Priorities and Community Demand」を紹介する。

このタイトルを直訳すると「メンテナーを維持するには？：オープンソースソフトウェアのメンテナーをビジネスの優先順位とコミュニティからの要求に従って管理する方法」とでも言えるだろうか。つまり企業の中でビジネスに直結するソフトウェアの開発を行うエンジニアではなく、「世界のどこにいるのか分からないエンジニアと協力しあって、オープンソースソフトウェアを開発するにはどうするべきか？」という非常に本質的かつ現実的なトピックを、自身の経験を元に語ったものであった。

プレゼンテーションを行うMicrosoftのMaggie Pint氏

LinkedInのProfileによれば、Pint氏がMicrosoftに入社したのは2016年、その前に6年ほどWebシステムの開発やSQLデベロッパーであったということは、オープンソースに関わるようになったのはMicrosoftに入社してから、ということだろうか。もしもそれが正しいのであれば、Microsoftのオープンソースに積極的な姿勢のひとつの表れかもしれない。

Pint氏は「そもそもメンテナーとは何か？」という問いかけからプレゼンテーションを始めた。またオープンソースプロジェクトにおいて必要な人的要素として「メンテナー」、「エキスパート」そして「プログラムオフィス」という単語を使うことで、単にエンジニア個人の資質に注目するのではなく、他のエンジニアや管理職の役割にも注目しなければいけないことを示唆したといえる。

ここでメンテナーはオープンソースのコードを書き、パッチをレビューするエンジニア、エキスパートはそのソフトウェアが果たす役割における専門家、つまりミドルウェアであれば必要要件や競合製品などに精通しているエンジニアを意味する。そしてプログラムオフィスは、ここでの文脈では「企業の中でオープンソースに関わるエンジニアなどをサポートする部門」ということだ。

ビジネスの価値観とオープンソースプロジェクトは親和性が低い

このスライドでは「オープンソースのメンテナーとビジネスの価値について議論すると、だいたい悪い方向に行ってしまう」「オープンソースコミュニティと戦うことは不可能」という、ビジネスサイドの人間には悪夢のようなことが書かれている。しかしそれを「良い方向に導くことは可能だ」というのが、Pint氏の最初の結論だ。

ではどうやってそれを行うか？　に関して、特に人物に注目して解説が行われた。

ここからは「私の個人的な経験に基づいてるんだけど……」という前置き付きのトークで、過去にとても良いチームの一員となったにも関わらず、オープンソースのメンテナーの仕事とチームの一員として結果を出さなければいけないことが両立できなくなり、結果的に自分がそのチームから抜けたことを紹介した。そしてメンテナーとして、そのような事態を避けるためにメンテナーをどう選ぶべきか、メンテナーの上司はどう対処するべきか、雇う際に注意するべきことは何か、などについて解説を行なった。

2つのタイプ：HuggerとExpert

ここで注目したいのは、メンテナーになりたがるエンジニアには2種のタイプがあるという分析だ。そのタイプとはひとつがHugger（これはHugをする人という意味）、そしてもうひとつがExpertだという。このHuggerとExpertは、ソフトウェアやコミュニティに対して興味を持っている点は共通している。Huggerはどちらかと言えば社交的でエバンジェリストに向いているが、あまり専門的な知識は持っていない。一方Expertは、技術やそのソフトウェアの領域に関する深い専門知識や経験を持っているが、あまり社交的ではなくエバンジェリストには向かないといったところだろうか。

Opportunistは避けよう

またこれらとは別のタイプとして、Pint氏はOpportunist（日本語では「お調子者」と言ったところだろうか）を挙げる。社交的でSNSなどでは活発に活動しているが、ソフトウェアよりも自分の評判のほうを気にしているので、実質的にはメンテナーには向かないと語った。こういう人は雇わないほうが良いということだろう。

またエンジニア本人だけではなく、人事や経営層などに対する「オープンソースのメンテナーを雇う際の注意点」を解説した。特に人事にとって、向こう6ヶ月で何を結果として期待しているのかを書き出すこと、そしてHuggerなのか、Expertなのかを見極めることなどが大切であると紹介した。

ハイアリングマネージャーの注意点

そしてプログラムオフィスにおいては、採用するエンジニアがオープンソースソフトウェアに継続的にコントリビュートすることを可能にするポリシーが、明確に定義されているか、コントリビューションを行う対象となるオープンソースソフトウェアのCLA（Contributor License Agreement）が企業の活動に合っているかどうか、そして人事に対してオープンソースソフトウェアのIP（Intellectual Property＝知的財産）の意味を教育すること、などを挙げた。

プログラムオフィスの注意点

ここで出てくるCLAとは、例えばKubernetesにおいてコントリビュートするためには必ずサインをする必要のある契約書であり、Kubernetesプロジェクトでは厳密に運用されていることの表れである。

詳しくはこのURLを参照のこと。The Contributor License Agreement

Kubernetesがかなり厳密にガバナンスと運用を行っているのは有名だが、JavaScriptのメンテナーであるPint氏も同じフレームワークを応用して、エンジニアによる企業での仕事とオープンソースプロジェクトでの仕事に齟齬が生じないようにしていることは興味深いと言える。

そしてMicrosoftでのリーダーシップの基本を参照して、透明性を高め、エネルギーを生み出すことで成功が手に入ると解説した。この場合の透明性とは、エンジニアの仕事を曖昧にせずに明文化するという意味だろう。

次にGoogleが作った「80:20のルール」について、「これはIT業界では大きな迷信ですよね」と語ると、会場からは笑いが起こった。つまりここに集まった参加者にとっては、「80:20のルールは迷信に近い」という感覚が共有されたということだろう。ここでは、時間の配分で実際の仕事の切り分けが行えるわけではないということを力説した。つまり勤務時間の80％を企業での仕事に、20％を好きなこと、例えばオープンソースへの貢献（メンテナーとしての仕事）にというように分けるのではなく、エンジニアの仕事の中核に企業向けの仕事とオープンソースのメンテナーとしての仕事を明確に定義することなしに、企業内のエンジニアがメンテナーとして成功することはないだろうと語った。

「20％ルール」は迷信

結論として、メンテナーの仕事のコアの部分にビジネスに貢献する部分とオープンソースプロジェクトに貢献する部分の優先順位を明確にすること、そして結果についてもビジネス、オープンソースの両方に定量化できる基準を取り入れることなどを提案した。

最後に「エンジニアが嫌いなことは何か分かる？　それは退屈すること。だからどんなことでもいいから退屈なことはさせないで！」と語って、Pint氏自身もまたAzureのエンジニアかつJavaScriptのメンテナーとして働いているというリアリティに満ちたプレゼンテーションを終えた。

エンジニアの敵は退屈

Azureの話でも自身が貢献するMoment.jsの話ではなく、いかに企業内でオープンソースプロジェクトに貢献するべきか、その際に上司や人事は何をするべきか？　に関する考察はPint氏自身の経験に基づいた提案であり、リアリティが感じられるものであった。Microsoftが、オープンソースソフトウェアに対して真剣に取り組む姿勢が見えるプレゼンテーションであった。

なお、プレゼンテーションに使用されたスライドはここから参照できる。

Maintaining maintainers