株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
InnerSourceとは？オープンソースの力を組織内に取り込む
InnerSource（インナーソース）は、オープンソース開発の手法（コードの透明性、コントリビューションモデル、コミュニティ駆動の品質向上）を企業内のソフトウェア開発に適用するプラクティスです。2000年にティム・オライリーによって提唱され、PayPal、MicrosoftのDevOps Dojo、Bloomberg、Boschなどに実践例があります。
InnerSource Commonsは、組織内でのオープンな協働を広げる国際コミュニティとして、導入に役立つ知識の共有や実践者の交流を進めています。日本でも、東芝は2022年の技報でインナーソースのライセンスや流通ガイド等の整備を紹介しています。三菱電機の公式サイト掲載記事では、2025年4月にソースコードの共有・相互活用を推進する組織を新設したと紹介されています。
InnerSourceの本質は「コードの壁を壊す」ことです。部門やプロジェクトの境界を超えてソースコードを共有し、他チームのコードに対して改修提案（プルリクエスト）の形で貢献する文化を構築します。
InnerSourceが解決する5つの課題
| 課題 | InnerSourceなし | InnerSourceあり |
|---|---|---|
| コードの重複 | 同じ機能を複数チームが個別に実装 | 共通ライブラリを全社で再利用 |
| サイロ化 | チーム間でコードが見えない | 共有対象のコードを、権限を持つ社内の開発者が閲覧可能 |
| ボトルネック | 他チームの機能追加を待つ | 自分でPRを出して貢献できる |
| 品質のばらつき | チームごとに品質基準が異なる | オープンなレビューで品質が底上げ |
| 知識の属人化 | 特定メンバーだけがコードを理解 | コントリビューションで知識が分散 |
InnerSourceの3つの役割
1. Contributor（コントリビューター）
他チームのリポジトリに対してプルリクエスト（改修提案）を送る役割です。自分のチームが必要とする機能を、他チームのコードベースに直接貢献します。「依頼して待つ」のではなく「自分で作って提案する」文化の体現者です。
2. Trusted Committer（トラステッドコミッター）
各リポジトリで外部からのコントリビューションをレビュー・承認する責任者です。コードの品質とアーキテクチャの一貫性を守りながら、コントリビューターの参加を促進するゲートキーパーの役割を担います。Trusted Committerには、担当する責任の範囲を定め、必要な時間を確保します。業務時間の20〜30%を割り当てるのは計画例であり、一律の推奨値ではありません。レビュー件数や支援の負荷に応じて調整します。
3. Product Owner（プロダクトオーナー）
InnerSourceプロジェクトの方向性を決定し、コントリビューションの優先順位を管理します。外部からのコントリビューションをロードマップと整合させ、プロジェクトの持続可能性を確保します。
InnerSourceの主要プラクティス
1. コードの透明性（Code Transparency）
InnerSourceの対象にするコードを決め、参加する社内の開発者がアクセス・閲覧できるようにします。契約・知的財産・機密性に応じて共有対象と閲覧権限を定めます。GitHubやGitLabのリポジトリで管理し、「対象コードは権限を持つ参加者が見られるが、変更には承認が必要」というモデルを採用します。
2. コントリビューションガイドラインの整備
各リポジトリにCONTRIBUTING.mdを配置し、以下を明文化します。
- コントリビューションの受け入れ基準
- コーディング規約とテスト要件
- プルリクエストの提出プロセス
- レビューのSLA（何日以内にレビューするか）
- Trusted Committerの連絡先
3. ディスカバラビリティの確保
社内のどのリポジトリにどのような機能があるかを発見できる仕組みを構築します。社内コード検索（Sourcegraph等）、プロジェクトカタログ（Backstage等）、READMEの充実が鍵です。
4. 段階的なオープン化
いきなり全コードをオープンにするのではなく、段階的に進めます。
- ReadableOnly: 共有対象のコードを、定めた社内の範囲で閲覧可能にする（まず「見える化」）
- Contributable: 特定のリポジトリでコントリビューションを受け付け開始
- InnerSource Project: 正式なInnerSourceプロジェクトとして運用
InnerSource導入のステップ
ステップ1: パイロットプロジェクトの選定
社内で広く使われている共通ライブラリ、SDK、ツールからパイロットプロジェクトを選定します。「多くのチームが利用している」かつ「改善要望が溜まっている」プロジェクトが最適です。
ステップ2: Trusted Committerの任命
パイロットプロジェクトのTrusted Committerを任命し、コントリビューションの受け入れ体制を構築します。Trusted Committerの時間確保は重要な成功要因です。20〜30%という配分例を固定基準にせず、担当業務と実際のレビュー負荷に合わせて確保します。時間が確保されないとコントリビューションのレビューが滞り、文化が根付きません。
ステップ3: CONTRIBUTING.mdとドキュメントの整備
パイロットプロジェクトのCONTRIBUTING.md、README、アーキテクチャドキュメントを整備し、初めてのコントリビューターが迷わず参加できるようにします。
ステップ4: 最初のコントリビューションを促進する
「Good First Issue」ラベルを付けた簡単なタスクを用意し、他チームからの最初のコントリビューションを積極的に促します。最初の成功体験が文化定着の鍵です。成功したコントリビューションは社内で積極的に発信・称賛します。
ステップ5: 横展開と文化の定着
パイロットの成功事例を社内に共有し、対象プロジェクトを順次拡大します。InnerSourceの社内コミュニティ（Slackチャネル、定期ミートアップ等）を構築し、ベストプラクティスの共有と参加者同士のネットワーキングを促進します。
InnerSourceの効果測定
| KPI | 定義 | 改善方向 |
|---|---|---|
| クロスチームPR数 | 他チームから提出されたプルリクエスト数 | 増加 |
| コントリビューター数 | InnerSourceに参加した開発者の数 | 増加 |
| コード再利用率 | 共通ライブラリ/コンポーネントの利用率 | 向上 |
| PR レビュー時間 | PRが提出されてからレビュー完了までの時間 | 短縮（SLA内） |
| 重複コードの削減 | 同一機能の重複実装の数 | 削減 |
| 開発者満足度 | InnerSource活動の参加しやすさ・満足度を尋ねるアンケート | 向上 |
企業の導入事例
PayPal
PayPalはInnerSourceの実践事例として、2015年の公開書籍「Getting Started With InnerSource」で紹介されています。同書は、チーム間のコラボレーションを促進し、開発速度と品質が改善したと説明しています。
Microsoft
Microsoftは、DevOps Dojoの公式紹介で、GitHubを使った教材等のInnerSourceを説明しています。各領域のコンテンツを共同で作成・改善する取り組みであり、コード以外の知識共有にもInnerSourceを適用した事例です。
三菱電機（日本事例）
三菱電機の公式サイト掲載記事（2025年12月1日付）によると、同社は2025年4月に「オープンソース＆インナーソース共創推進部」を設立しました。ソースコードの共有・相互活用、知見の再利用、人材育成などを組織として推進する日本企業の事例です。
InnerSource導入の課題と対策
| 課題 | 内容 | 対策 |
|---|---|---|
| Trusted Committerの時間確保 | 業務で忙しくレビューが滞る | 業務負荷に応じた時間配分（20〜30%は計画例）を決め、マネジメントの承認を得る |
| 「コントリビューションは余計な仕事」という認識 | 自チームのKPIに反映されない | InnerSourceコントリビューションを評価制度に組み込む |
| コードの品質基準のばらつき | チームごとに基準が異なる | 全社統一のコーディング規約、CI/CDによる自動検査 |
| 知的財産/セキュリティの懸念 | 社内でもコードの公開に抵抗 | 閲覧範囲の段階的な拡大、セキュリティレビュープロセス |
| コントリビューションの品質 | 不十分なPRが送られてくる | CONTRIBUTING.mdの整備、テンプレートの提供、Good First Issue |
2026年のInnerSourceトレンド
AIコーディングアシスタントとの融合
開発現場でAI活用が一般化している中、InnerSourceのコントリビューションにもAIが活用されています。AIがコードの変更提案を自動生成し、Trusted Committerがレビュー・承認するワークフローが実用化されつつあります。
InnerSource + Platform Engineering
InnerSourceの共通ライブラリ・ツールをプラットフォームエンジニアリングのIDP（内部開発者プラットフォーム）と統合し、テンプレート、SDK、共通コンポーネントをセルフサービスで利用できる基盤の構築が進んでいます。
InnerSource Commons の成長
InnerSource Commonsは、InnerSourceのベストプラクティスを共有する国際コミュニティで、日本語の学習資料の提供や、InnerSource Gathering Tokyo 2025（2025年9月12日開催）の実施など、日本でも知識共有と交流の場を提供しています。
よくある質問（FAQ）
Q. InnerSourceとオープンソースの違いは何ですか？
オープンソースは「全世界に公開」ですが、InnerSourceは「社内（組織内）に限定して公開」する点が最大の違いです。コントリビューションモデル（PR、レビュー、マージのフロー）やコミュニティ運営の考え方はオープンソースと同じですが、アクセスは組織内に限定されます。知的財産の保護とオープンなコラボレーションを両立させるアプローチです。
Q. InnerSourceは何名規模の組織から有効ですか？
開発者30名・3チームといった人数やチーム数だけで、導入効果が決まるわけではありません。複数チームが共通のコンポーネントを利用している、または類似の機能を個別に実装しているケースがあれば、InnerSourceの導入価値があります。10名以下でも、扱うコードや権限が分かれていれば共有・貢献の仕組みが役立ちます。全員が同じコードを共同で扱えている場合は、仕組みを必要以上に増やさず運用できます。
Q. InnerSourceの導入にはどのくらい時間がかかりますか？
計画例として、開始から1〜2か月でパイロットを立ち上げ、2〜3か月で最初のクロスチームコントリビューションを目指し、6〜12か月で定着状況を見直す進め方があります。調査に基づく標準所要期間ではなく、体制やレビュー負荷に応じて調整する目標設定の例です。最も時間がかかるのは「コントリビューションが日常的に行われる文化」の醸成であり、技術的な仕組みよりもマインドセットの変化に投資してください。
まとめ：InnerSourceで「組織の壁」を超えた開発文化を構築する
InnerSourceは、コードの透明性とクロスチームコラボレーションを通じて、開発の重複排除、品質向上、知識共有を実現するプラクティスです。公開されている導入パターンや実践例も参考に、自社の共有範囲と参加体制に合わせてこのアプローチに取り組み、「部門の壁」を超えた開発文化を構築しましょう。
renueでは、InnerSourceの導入設計から開発文化の変革、プラットフォームエンジニアリングとの統合まで、企業の開発生産性向上を包括的に支援しています。InnerSource導入や開発文化の改善でお悩みの方は、ぜひお気軽にご相談ください。
株式会社renueでは、AI導入戦略の策定からDX推進のコンサルティングを提供しています。お気軽にご相談ください。
