Deutsche Bahn
InnerSource Express：Deutsche Bahnのソフトウェア連携を推進する
概要
InnerSourceを効果的に導入すると、協働を促進し、透明性と効率を高めることで、企業に大きな価値をもたらすことができます。InnerSourceはソフトウェアコードに限定されず、協働や共同での責任が有益となるあらゆるコンテンツやプロセスに適用できます。
Deutsche Bahn（DB）では、InnerSourceが各子会社のソフトウェア開発の変革に重要な役割を果たしてきました。稼働中のGitリポジトリが50,000以上、GitLabユーザーが10,000人に上るDBは、チームや子会社間の協働を強化する機会を見いだしました。InnerSourceの導入により、DBは次の成果を実現しました。
- 協働の文化を形成し、事業部門と技術チームの連携を促進しました。
- コストを削減し、ソフトウェアコンポーネントの再利用とインフラの標準化を可能にしました。
- ソフトウェア品質を向上させ、共同でのフィードバックと課題追跡を活用しました。
- 透明性を向上させ、プロジェクト開発とガバナンスを改善しました。
背景
欧州最大級の鉄道事業者であるDBには、広範で複雑な技術エコシステムがあります。同社は数百の子会社でソフトウェア開発を管理しており、各社は独自のインフラ、契約、規制上の要件を持つ独立した組織として運営されています。従来、この構造は非効率、作業の重複、チーム間の協働の難しさにつながっていました。
これらの課題に対応するInnerSourceの可能性を認識したDBのITパートナー、DB Systelは、InnerSourceによる変革を開始しました。この取り組みには技術的な解決策だけでなく、オープンな姿勢、再利用、知識共有を促すための大きな文化的・組織的変化も含まれていました。
DBのInnerSourceへの取り組みは、1999年のJava導入に始まり、2002年には共有コンポーネントライブラリが作られました。2006年、経営陣はDB Systelの社内プロジェクトをInnerSourceとして公開するよう指示し、オープンな協働への正式な転換を示しました。2011年には6週間のワークショップを通じて取り組みが加速し、InnerSourceが大きく発展しました。2021年には体系的なガバナンスの必要性が認識され、組織全体での導入を推進するため、Architecture Guildの下にInnerSourceを担当するチームが設けられました。
解決すべき課題
1. グループ企業間でサイロ化した開発
課題：DBは約500の子会社からなり、それぞれが独立した法人として機能しています。そのため、規制や契約上の障壁により、組織内のチーム間でコードを共有することが難しくなっていました。
解決策：DBはDB Innersource License（DBISL）を策定し、DB内部でのソフトウェアの自由な利用、変更、再配布を法的に可能にしました。さらに、契約ツールキットを導入し、サービス契約にInnerSourceを円滑に組み込めるようにしました。
DBISLが協働を促した例として、DBContainerLibプロジェクトの実現があります。DBには独自のソフトウェア開発慣行を持つ子会社が多数あるため、標準化され、本番利用に対応したDockerイメージを共有することは以前は困難でした。DBISLの導入により、各子会社のチームはDBContainerLibを自由に利用、変更し、貢献できるようになりました。その結果、本番サービス向けに、一貫性のある高品質なベースイメージを確保できました。
2. InnerSourceプロジェクトの資金とインフラ
課題：多くのInnerSourceプロジェクトは現場の自発的な取り組みから自然に生まれましたが、コミュニティが保守するこれらのプロジェクトにインフラや資金を確保することは困難でした。
解決策：DBはInnerSource Hubを設立しました。これは中央で資金を提供するプラットフォームで、GitLabリポジトリ、CIパイプライン、アーティファクトリポジトリを備えています。開発者はインフラ費用を心配せずにInnerSourceプロジェクトへ貢献できるようになりました。
最後に記録された更新時点で、InnerSource HubはDBContainerLib、PipeShip、K8S Setupなど、コミュニティが保守する複数のInnerSourceプロジェクトをホストしています。中央で資金を提供するモデルによって、これらのプロジェクトのインフラ費用が減り、各チームが個別にCI/CDパイプラインやアーティファクトリポジトリを確保する必要がなくなりました。
3. 不確実性と文化的な抵抗
課題：技術面と法的な基盤が整っていても、多くの開発者は、経営陣が本当にInnerSourceを支持しているのか疑問を持ち、コードの共有をためらっていました。
解決策：この問題に対し、Architecture GuildはInnerSourceのアーキテクチャ原則を導入し、標準的な考え方を逆転させました。チームは今やInnerSourceを利用しない理由を説明する必要があります。このガバナンスモデルにより、開発者はInnerSourceが単に許可されているだけでなく、積極的に推奨されていると確信できました。
InnerSourceのアーキテクチャ原則の導入後、開発者はコードの共有に対する自信が高まったと述べています。当初、多くの人はコードを精査されることへの懸念からためらっていましたが、InnerSourceが標準となったことで、リポジトリを公開するチームが増えました。代表的な例はArchitecture Guild Micrositeです。ここではチームがドキュメントの改善に積極的に貢献し、知識ベースが継続的に進化しています。
基盤と実装
基礎的な課題を解決したDB Systelは、各チームがInnerSourceを利用しやすく、円滑に取り入れられるようにすることに注力しました。その取り組みには次のものが含まれます。
- 円滑な協働を実現するため、明確な貢献ガイドラインを整備すること。
- InnerSource Hubを通じて、中央で管理するインフラと資金を提供すること。
- チームの導入を支援し参加を促すため、InnerSourceの研修と普及活動を行うこと。
- 導入の指針として、オープンソースコミュニティのInnerSourceベストプラクティスを活用すること。
InnerSourceの実践：主要プロジェクト
DBにおける影響力の大きなInnerSourceの取り組みは、このアプローチの成功を示しています。
1. DBContainerLib
コミュニティが保守する、本番利用に対応したDockerイメージのコレクションです。
主な利点：
- コスト削減：各チームが独自のイメージを作成・保守する必要をなくします。
- 品質向上：さまざまな専門家の貢献がセキュリティとコンプライアンスを強化します。
- チーム間の協働：複数の子会社で利用され、協働を促進します。
DBContainerLibはDeutsche Bahnに欠かせないリソースとなり、Javaベースのイメージだけでも年間約700,000回ダウンロードされています。このプロジェクトは多くのチームで広く採用され、組織全体に標準化された高品質なコンテナアプリケーションをもたらしています。
2. PipeShip
プラットフォームチームが保守する、モジュール式のGitLab CI/CDパイプラインフレームワークです。
主な利点：
- 品質の向上：ユーザーのフィードバックがマージリクエストを通じて直接反映されます。
- 開発の迅速化：チームは問題をすぐに修正し、改善に貢献できます。
3. K8S Setup
Kubernetesの名前空間設定を簡素化する、HelmfileベースのInfrastructure as Codeプロジェクトです。
主な利点：
- 時間の節約：標準化されたテンプレートがKubernetesの導入を加速します。
- 透明性：フォークによって、チームは一貫性を保ちながらデプロイをカスタマイズできます。
K8S Setupの導入前、チームはKubernetesの名前空間設定に大きな遅延を抱えており、インフラの手動設定に何日もかかることが珍しくありませんでした。InnerSourceに基づくHelmfileのソリューションにより、新しい名前空間を数時間でデプロイできるようになり、DevOpsチームの導入作業の効率が大幅に向上しました。
4. Architecture Guild Microsite
「Docs as Code」のアプローチに従ったドキュメントリポジトリです。
主な利点：
- 透明性：チームは進化し続けるアーキテクチャのベストプラクティスを追跡し、貢献できます。
- 協働：オープンな参加がドキュメントの品質と正確性を高めます。
今後の計画
今後、DBは次のことを目指しています。
- InnerSourceへの参加をソフトウェアチーム以外にも広げ、業務プロセスやドキュメントを対象にすること。
- 持続可能な成長を確保するため、ガバナンス構造の改善を続けること。
- オープンソースへ移行できる追加のInnerSourceプロジェクトを特定すること。
Deutsche BahnでInnerSourceが進化し続ける中、同社は大規模な協働、透明性、イノベーションの文化を育むことに引き続き取り組んでいます。