インナーソースとは？
インナーソースとは、企業がより効果的にコラボレーションするためにオープンソースのアプローチと文化を採用するソフトウェア開発戦略です。
インナーソースは、作業とコラボレーションを効果的に行うためにオープンソースで使われているプロセスを採用するというもので、高パフォーマンスを実現している開発チームやエンジニアリングチームで特に人気が増しています。チームでインナーソースを行う場合、プロプライエタリソフトウェアを開発し、デベロッパーからプロダクトマネージャーに至るまで全員がソースコードにコントリビュートできるようチーム間で内部的に作業を公開します。
インナーソースとは、オープンソースの内容をプロプライエタリコードに適用するソフトウェア開発戦略です。インナーソースは内部で使用するソフトウェアを保持しつつ、組織内でオープンソースの文化を確立するのに役立ちます。チームはインナーソースを使用することで可視性を高めながらコラボレーションを強化し、サイロ化を解消できます。
組織内の内部プロジェクトのデフォルトをオープンに設定すると、チームの既存のソリューションの再利用が可能になり、冗長性が最小限に抑えられ、チームコラボレーションが強化されてすべての人材の才能を活用することができます。インナーソースのメリットを享受し、大規模なオープンソースプロジェクトから学ぶことで、あらゆる規模の組織が最新のソフトウェア開発方法を継続的に取り入れることができます。
大規模な組織や企業では、開発チームがさまざまな部署やタイムゾーンに分散していることは珍しくありません。その場合、複数のデベロッパーが同じ部署の戦略を利用できない可能性があります。そんな時もインナーソースを使用すれば、オープンソースプロジェクトで成功が証明されている同一のワークフローモデルと適合させることができます。
PayPalの事例は、「オープンソース」の「オープン」が実際には1つの組織のチーム内のみであっても、オープンソース開発の手法がいかに効率的で収益性の高い事業を生み出すかを実証しています。ボッシュ、オートデスク、ブルームバーグ、サンディスクといったインナーソースを採用している先進企業は、オープンソースで使用されているシステムと同じく無駄を排除した安価なシステムを使用して複雑なプロジェクトを完了し、革新的な製品を生み出しています。
大規模な組織も、大規模なオープンソースプロジェクトも、その本質は変わりません。どちらも何人ものコントリビューター、さまざまなツール、異なる指示や戦略など、数多くのパーツで構成されています。一方で、従来の企業モデルにおいて組織は上層部の指示に従って機能します。組織の効率性は、マネージャーが大量の情報を追跡できるかどうかにも左右されます。
情報の豊富さは管理上のボトルネックにつながることも多く、少なくない数のプロジェクトが見落とされていても不思議ではありません。プロジェクトが複雑になったりチームの数が増えたりすると、忘れられてしまうタスクも増える可能性があります。オープンソースのプロジェクトでは、時間の経過とともにコンポーネントが放置されることを避けるため、開発関連情報は文書化され、チェックプロセスを組み込み管理されます。
企業にとって最も重要となるオープンソースのワークフローは次のとおりです。
- 表示レベル
- フォーク
- プル/マージリクエスト
- テスト
- 継続的インテグレーション
- 文書化
- イシュートラッカー
ソフトウェア開発にオープンソースの考え方を採用すると、組織はギャップを埋め、サイロを解消し、より強固で緊密なソフトウェア開発ライフサイクルを実現できるようになります。それだけでなく、デベロッパーの利用体験の強化、開発手法の合理化、透明性のあるコラボレーション文化への道も開かれます。
このアプローチはデベロッパーの開発速度を向上させるだけでなく、さまざまな開発プロジェクトでコアチームメンバー間の緊密なコラボレーションを促進するものでもあります。
インナーソースを使用する組織は、一般的に次のようなオープンソース開発のメリットを享受しています。
- 高品質のコード：ユニットテスト、コードカバレッジ、継続的インテグレーションにより、チームはライフサイクルの早期段階でコード品質を向上できます。- 包括的な文書化：コメントだけでなく、あまり形式的でないディスカッションにおいても、コードがより適切に文書化されます。そのため、信頼できる唯一の情報源を確立でき、透明性を向上し、知識を共有できます。
- 効果的なコードの再利用：コードとアーキテクチャをチームや組織全体で共有し、アクセスしやすい形で利用できます。
- より充実したコラボレーション：コードレビュー時に摩擦が少ないため、より充実したコミュニケーションを取れるようになり、コントリビューション件数が増加します。
- 健全な環境：サイロは分解され、デベロッパーの仕事への満足度に加えて定着率と採用率も向上します。
ここでは、大規模組織で発生しがちな問題とインナーソースでの解決方法を紹介します。
| 課題 | 解決策 |
|---|---|
| コミュニケーション：大規模な組織では、1つのチームが共通の目標に向かって取り組むことは稀です。多くの場合、チームメンバーは、独自の構造とリーダーシップを持つ複数の断絶されたチームにサイロ化される傾向があります。コミュニケーションの方法や用語はチームによって異なり、サイロ間でのコミュニケーションや知識の共有は最小限で、効率的ではありません。 | オープンソースシステムは、大規模な参加と貢献を可能にします。コミュニケーションラインは直接的で、プロジェクトに関わる全員が見ることができます。コミュニケーションの階層は通常フラットで、不要なノイズを排除し、ステークホルダーとコントリビュートを結びつけます。 |
| 発見：部門間のコミュニケーション、透明性、コラボレーションが欠けているためにソフトウェアソリューションが異なる部門で何度も作成され、無駄な労力が多く消費されます。多くの場合、ソリューションがすでに作成されているかどうかを確認する手順は存在しません。 | オープンソースプロジェクトの利点は、透明性が基盤となっていることにあります。プロジェクトにアクセスできるチームメンバーは誰でも、直面している問題の解決策が存在するかどうかを検索できます。 作業を始める前に検索しないメンバーがいる場合も、完全な表示レベルが付与されている他のプロジェクトコントリビューターが既存のソリューションを特定できます。オープンソースプロジェクトが既存のソリューションを発見できるようにするため、無駄に同じ作業を繰り返す必要がなくなります。 |
| 非効率なプロセス：ほとんどの商業環境では、アクセス権を付与されるチームメンバーを決定する組織構造が存在します。ソリューションの存在に気づいているチームメンバーがいても、管理者にプロジェクトへのアクセス権をリクエストする必要があるため、開発者や管理者は重要なタスクに十分に集中できません。 オープンソースプロジェクトでは、プロジェクトでの作業や閲覧ができるフルアクセス権がチームメンバーに付与されます。こうした表示レベルとアクセス権がすでに提供されているため、管理作業が軽減され、アクセス権リクエスト関連の対応が必要なくなります。 | |
| 変更を加える：従来の商業環境では、チームに付与されているプロジェクトのアクセス権が読み取り専用の場合、編集や機能を追加するには権限を持つ別の誰かに依頼する必要があります。変更を依頼する担当者が多忙、または変更の必要性がないと思われた場合、コントリビューターには他に取れる手段がありません。アプリを担当するチームは、アプリの納期を守って適切に機能することを保証するのが仕事であり、アプリのメンテナンスが最優先事項です。新機能を追加することで別のチームが恩恵を受けるかもしれない場合でも、アプリケーションの変更リクエストでアプリケーションの安定性が妨げられる可能性があるため、アクセス権の付与にはリスクが伴います。開発者が必要な変更を加えるためのアクセス権を得られない場合、チームは独自のコードベースやアプリケーションを構築して問題を解決することになりますが、これでは今後も別の誰かが何度も同じ問題に直面する可能性があります。これにより、同じ問題を解決するために数多くの異なるアプリが作成されるという状況が生まれてしまいます。 | チームがオープンソースプロジェクトに変更を加える際に、承認を得る必要はありません。コントリビュートで追加された変更をシステムにテストさせ、機能性と妥当性を確認できます。たとえば、チームがコードベースからフォークしたり、変更を加えたり、マージリクエストを作成したりすると、他の開発者が検証したり、質問したり、テストしたりできます。マージリクエストを受け入れる担当者は追加の作業を自分で行う必要がなく、機能もすでにテストされているため、ワークロードが軽減されます。さらにレポートジェネレーターが8つのコードベースではなく1つのコードベースをサポートするだけでよいため、全体的な負荷が軽減されるというメリットもあります。 |
現在ではほぼすべてのチームがさまざまなタイムゾーンで共同作業しており、複数の部署がある組織では、インナーソースを活用してより効率的なワークフローを作成できます。チーム間で発生していた情報のサイロ化が解消され、組織全体でより効果的なコラボレーションを促進できます。また、インナーソースを使用すると開発者のオンボーディングが迅速になり、チームメンバーがソフトウェアをオープンソースコミュニティにコントリビュートできるようになります。
インナーソースをプロジェクトに導入することで、従来の開発アプローチから、よりダイナミックで、包括的かつ効率的な開発ワークフローが実現します。
GitLabがソフトウェア開発を効率化する方法について詳しく見る
