Europace

Europaceでオープンソースの慣行を取り入れる

事例紹介：出典は 『Adopting Inner Source』に収録されたIsabel Drost-Frommの章・記事（2018年7月）

はじめに

Europaceはドイツのベルリンを拠点とする中規模のフィンテック企業です。同社は2017年に正式なInnerSourceプログラムを開始し、その1年後に記事で学びを共有しました。

この1年間でEuropaceは、InnerSourceのプロセスや慣行を適用した領域で、開発期間の明らかな改善、コード品質の向上、チーム間の協働の増加が見られたと報告しました。また、新しいプロセスによって開発者のプロジェクトへの責任意識が高まり、チームをまたぐメンタリングの文化が育ったことも確認されました。

InnerSourceの目標

2015年、Europaceは従来とは異なる組織・ガバナンスモデルの検討を始めました。その目的は、「分散型の自己組織化」の文化を生む全社的な新しい枠組みを構築することでした（ここにリンクを入れられます…）。この新しい構造では、最も専門性の高い従業員に責任と意思決定を移すことになります。

この使命は、「…Europaceの従業員はそれぞれの分野の専門家であり、正しい判断を十分に行えるという…基本的な信念」に基づいていました。

（参照を付けるべきでしょうか？記事の88ページ）

こうした背景の下、InnerSourceは、このビジョンを進めるための包括的なモデルと有用な指針の両方を提供しました。

オープンソースのベストプラクティスを取り入れるInnerSourceには、成長する企業が抱える次のような課題を解決する可能性もありました。

開発チーム間で開発のサイロ化が進んでいること。
技術的な相互依存と、それに伴う開発の優先順位付けの難しさ。
プロジェクトのドキュメントが少ないために生じる情報の欠落と「プロジェクトの記憶」の喪失。
リモートワークを円滑にするため、非同期のコミュニケーションと意思決定に移行する必要性。

InnerSource：Europaceでの最初の1年

従業員の賛同と参加を得る

InnerSourceの担当職を設ける

まず、InnerSourceの取り組みを調整する専任の役割が設けられました。新たなInnerSourceコーディネーターが持つオープンソースとApache Software Foundationでの経験は、EuropaceのInnerSource導入における理解、伝達、実践、問題解決に非常に役立ちました。

関係構築の戦略的重要性

次の段階では、Europaceのさまざまな関係者に働きかけ、参加の利点について話し合いました。個別の非公式なランチに招待するという方法が取られました。これらの対話は、懸念や潜在的な障害を見つけるうえで特に有効でした。

共通の課題が分かると、関心のある人々が学びを共有できる非公式なグループランチが設けられました。その後、情報交換と問題解決を行う月例のランチ円卓会議へと発展しました。

「メタレベル」でのTrusted Committerの役割

初期段階では、InnerSourceに熱心な人々が、コミュニケーションや意思決定の記録に関する新しいプロセスへの移行を同僚に対して支援しました。チームのメンタリング、質問への回答、同僚へのInnerSourceの普及を行う人々もいました。この中核グループは、InnerSourceプログラムのTrusted Committerになるよう招かれました。

Trusted Committerの地位を与えることは、InnerSourceの推進者やメンターの努力を公に認めることにつながりました。また、社内で誰がプログラムを推進しているかを明確にしました。

新しいプロセスとツール

コミュニケーションと意思決定の透明性を高める

Europaceでは、開発や製品に関する意思決定の経緯をたどることが課題となっていました。コミュニケーションと意思決定を文書で記録する必要性が認識されていました。

InnerSourceの推進者は同僚を積極的に励まし、口頭での意思決定への依存から、Slack、GitHubの議論、その他の記録が残る媒体の利用へ移るために率先して行動しました。

協働を円滑にするためにタスクの透明性を高める

それまでは主にTrelloのボードやJIRAで計画を立てていました。しかし、チームは閲覧と書き込みの権限を自部門に限定することが多く、チーム間の協働の障害となっていました。

GitHubでは標準で情報が公開されるため、GitHubへの移行により、すべてのチームが「…課題、プルリクエストでのやり取り、コードを横断して」検索しやすくなりました。

InnerSourceリポジトリ：手本を示し、安心して失敗できる場を作る

InnerSourceプログラムには、透明性の手本を示すこと、コミュニティに質問できる場を提供すること、集めた関連ドキュメントを管理することが求められました。

このプログラムは「インフラ基盤型」のInnerSourceプログラムに従いました（脚注が必要）。

コミュニケーションのプロセスは前述のInnerSourceの原則を反映するよう設計され、InnerSourceの考え方に沿って、組織内ですでに利用できるツールが再利用されました。

GitHubリポジトリ「ep-innersource」で、InnerSourceプログラムのすべての作業と意思決定を記録しました。プログラム全般について話し合う専用のSlackチャンネルも作成されました。

GitHubリポジトリは、本番システムを停止させるリスクのない安全な環境で、プロセスや技術を試すための場にもなりました。

プルリクエストへの移行

Europaceの従業員の一部はすでにGitHubに慣れていましたが、技術的な相互依存に対応する方法として、チームはプルリクエストの利用を始めるよう促されました。

変更を希望するどのチームの貢献者にも、GitHub上のプルリクエストを通じてコードをダウンロードする権限が与えられました。機能を追加・変更した後、受け入れ側チームのTrusted Committerに承認を求めることができました。コードは主要なコードベースにマージされるか、さらなる修正を求められました。

数週間のうちに、協働のモデルとしてプルリクエストの利用が広がりました。

InnerSourceプロジェクトの責任意識を高める：Trusted Committer

Trusted Committerの役割（ここにISCの学習パスへのリンク）は、チーム間の協働を円滑にし、プロジェクトの記憶を保持し、長期的な責任意識を高めるために導入されました。

Trusted Committerは、貢献の障壁を下げながら製品品質を確保する役割を果たしました。また、コードや修正を提供したい開発者を指導する責任も担っていました。

貢献者は保守担当者の信頼を得ると、リポジトリへの書き込み権限を与えられました。

社内でInnerSourceの共通理解を育てる

当初、InnerSourceは企業のプロジェクトにオープンソースの原則を適用する方法として定義されていました。

しかし、プログラムが発展するにつれて、従業員がInnerSourceを実践する「方法」だけでなく、Europaceでの導入成功を支える原則や良い慣行も理解することが重要になりました。

InnerSourceプログラムは、次の共同作業を促すことで、チームの認識と知識を深めました。

InnerSourceに関する学びを会社の技術ブログに記録すること。
InnerSourceのパターンをInnerSource Commonsに提出すること。
EuropaceのためのInnerSourceの原則を作成すること。

すべてのInnerSourceプログラムと同様に、貢献やレビューの依頼はSlackチャンネルで周知されました。取り組みはGitHubにも掲載され、必要に応じてInnerSourceの責任者が重要な関係者に連絡し、レビューを依頼しました。

InnerSourceの成果

1年のうちに、Europaceで展開されたInnerSourceプロジェクトは、この協働モデルの利点を示しました。

GitHubへの移行と、主要なプラットフォームに意思決定を記録する全社的な取り組みにより、プロジェクトの透明性が高まり、情報の分断が減りました。
意思決定、アーキテクチャ設計の議論、ドキュメント、コードがGitHub上で近接して扱われるようになり、変更を追跡し理解しやすくなりました。そのため、事前のドキュメントに関する多くの形式的な要件が不要となり、プロジェクトマネージャーやUXデザイナーの関心も高まりました。
SlackやGitHubによる非同期の意思決定は、当初プロジェクトに参加していなかった従業員の関与を促しました。同じ場所にいることや対面会議に頼らず、従業員はチーム、時間、地理的な境界を越えて専門知識を共有できました。
Trusted Committerの役割は、開発者の責任意識を高めました。開発者のメンタリングがこのプロセスに組み込まれたため、従業員による価値ある貢献として認められるようになりました。
プルリクエストの利用により、経験豊かなメンバーが担当外のプロジェクトにも意見や支援を提供できるようになりました。また、プルリクエストとコードレビューによる安全網は、新しい開発者にも機会を与え、価値ある貢献を可能にしました。
プルリクエストの利用は、「…開発の高速化」にもつながりました。

コードの品質とコードレビューの品質が向上し、その改善は顕著でした。

結論

社内および複数のプロジェクトでInnerSourceの慣行を推進したことで、高品質なコードの開発、コードの再利用、プロジェクトの記憶の喪失や情報の分断といった既存の問題への対応における価値が示されました。一部のプロジェクトでのInnerSourceの利用は、プロジェクトだけでなく従業員にとってもチーム間の協働が有益であることを明らかにしました。新しい開発者は技能を伸ばす機会を得て、経験豊かな開発者はTrusted Committerやメンターとして認められました。

EuropaceのInnerSourceプログラムの第2段階では、規模の拡大とさらなる展開に関する新しい課題に取り組む予定でした。

それでも、Europaceの立場から見ると、初期の導入段階は非常に成功したと評価されました。