InnerSource Gathering TOKYO 2024
ACS事業部 亀崎です。2024年8月8日に開催された InnerSource Gathering Tokyo 2024 に参加してきました。
皆様はInnerSourceというのをご存知でしょうか。 組織内を見回すと、同じようなことを複数のチームで開発していることはありませんでしょうか。そうした「車輪の再発明」をしないように、組織内で共用できたらいいと思いませんか？
そうした組織内の共用を推進しようとするのがInnerSourceです。
実は過去なんどが本ブログでもInner Sourceに言及した記事がありました。
そうしたInnerSourceを推進しているのがInnerSource Commonsであり、InnerSource Gatheringは「InnerSource Gatheringsは、ソフトウェア開発において組織の壁を越えたコラボレーションを実現するための秘訣を探るイベント」です。
イベントは本当にさまざまなことを学ぶよい場となりました。本当はそこで得られたすべての知見をご紹介したいのですが、ここではその中で１つだけご紹介しいます。
Linux Foundationが実践する「コラボラティブ・プロジェクト管理」
InnerSource Commonsではインナーソースを以下のように定義しています。
組織という限られた環境において、ソフトウェア開発におけるオープンソースの原則とプラクティスを活用すること
オープンソースのコミュニティといえば、Linux Foundationをイメージする方も多いと思います。OSSプロジェクトを多数運営しているLinux Foundationがどのような考えでプロジェクトを運営しているかを知ることはとても役に立つはずです。
OSSはなにかを開発すればOK、というわけではなく、そこに参加する開発者のために「コラボラティブなプロジェクト管理」をしていくことが重要です。
Linux FoundationではOSSのプロジェクト管理のポイントは５つあるそうです。
- プロジェクトガバナンスモデル
- 開発インフラ
- コミュニティ（人）
- マーケティング
- データ
以下で個別に内容をご紹介します。
プロジェクトガバナンスモデル
プロジェクトガバナンスモデルは、「技術的観点から正しい判断がされる運営」を実現するものです。 プロジェクト運営は次の３つから構成されているそうです。
- Governing Board
- Technical Steering Committee
- Projects ...
ポイントとしてはビジネス的な方向性を司る組織のGovering Boardと、技術的な方向性を定めるTechnical Stering Committeeを分離していることにあります。開発者が、開発者の観点で技術的に正しいと思われる方向に最速で進んでいくために、この二者を切り離し、独立して技術的な判断ができるようになると考えられています。
開発インフラ
開発インフラとしては、参加しやすく、貢献しやすい環境構築を行っているとのこと。 WebサイトやSource Code Repository、Mailing List、IRC（Chat）、Bug and feature trackingは必須、これにくわえてWikiやForumを用意することが推奨されていました。これらを駆使して、コミュニティ開発者にとって「快適な」開発環境を整えることがより多くのコミュニティ参加者と開発貢献を獲得するのにとても重要とされています。
コミュニティ（人）
成果が出るコミュニティは、参加が容易で働きやすい、とされています。そうしたより多くの参加者を集め、その仲間から多くの貢献を引き出すためには以下の点が重要になります。
- 容易な参加 とにかく参加のハードルを極力下げる必要があります。
- 透明性の高い運営 技術的な議論はMLなどパブリックな場所で行うことなど、外から見える形にすることが重要
- 整備された開発プロセス 参加者がどのように修正すればよいか、リリースサイクルやマージプロセスなどが明確になっていることが成果を引き出すのには重要
マーケティング
コミュニティは、いかに多くの仲間を集めるかが重要です。ロゴやウェブサイトを作成することはもちろんSNSなどによる情報発信なども必要です。さらに、そのプロジェクトのメインテナーにはイベントに積極的に参加してもらい、多くの参加者と話す機会を提供するといったことも重要になります。
データ
大きなプロジェクトでも、実は貢献の多くは少数の開発者が行っていることが多いです。たとえばKubernetesやLinuxのプロジェクトでも開発貢献者は5,000人を超えますが、実は大半の貢献は100人に満たない開発者から生み出されています。
こうしたデータを捉え、生産性の高い人、影響力の大きい人、縁の下で実はめちゃくちゃ働く人、といった開発者を特定し、その個人の活躍を支援し、成果を讚えることも必要になります。
まとめ
こうしてみてみると、イベントなどで行われていることが「あーこれはこういう意図があるのか」と思う要素ばかりです。 自分自身はそれほどOSSには貢献できている身ではありませんが、イベントなどを参加するとき、どういった活動しているのかとかメインテナの方と話したいとか、そうしたことを期待していました。まさにプロジェクトを進めるにあたって「こうしたら開発者が参加しやすい、参加しようと思う」活動に引き寄せられていたんだなと感じます。
InnerSourceの場合、組織内での活動となるためにオープンソースコミュニティでは重要とされていない課題などが出てきますが、それでも多くの参加者をまきこむ運用というのはとても参考になると思います。
そしてもう１つGatheringに参加してわかったこと。実はInnerSource Gathering Tokyoはオンラインでも視聴できたそうですが、実はQ&Aなどは非公開。現地参加の方のみそれを聞くことができるという特権があります。これももしかすると、現地参加を促す一つの運営テクニックか？？とも思いました。 もちろんQ&Aだけではなく、懇親会などを通じて多くの意見交換ができたので、イベントは現地参加が本当におすすめです。
最後に、そんなインナーソースの取り組み方の書籍をご紹介して終わりたいと思います。
インナーソースパターンブック
patterns.innersourcecommons.org
それでは。どこかでお会いできる日を楽しみにしています。
