社内でOSSの開発文化を取り入れたいが、英語でどう設計書を書けばいいかわからない。グローバルチームに計画を共有しても、スコープやルールが伝わらず貢献が続かない。そんな悩みを抱えるエンジニアは多い。
インナーソース（InnerSource）は、OSSの開発手法を組織内部に適用するアプローチだ。コード共有・横断的なコントリビューション・ドキュメント主導の開発文化を社内に根づかせるために、英語の計画書が欠かせない。
この記事では、英語インナーソース計画書を4つのセクションで構成する方法を解説する。各セクションに日英フォーマットを用意しているので、そのまま流用できる。
英語で設計書を書くことで、海外拠点のエンジニアにもルールが伝わり、横断的なコントリビューションが加速する。
インナーソース計画書を英語で書く理由
インナーソース計画書を英語で作成する目的は、社内に散在するコードベースへの貢献障壁を下げることだ。
日本語のみの設計書では、海外拠点やグローバルチームのメンバーが計画の意図を把握できない。結果として、コントリビューションが特定チームに偏り、インナーソースの恩恵が広がらない。
英語で書く主なメリットは3つある。
- 横断コントリビューションの促進：全拠点のエンジニアが貢献ルールを理解できる
- ドキュメント標準化：
CONTRIBUTING.mdやREADME.mdとの整合が取りやすい - 外部OSSとの親和性：OSSコミュニティの用語と一致し、採用・育成コストが下がる
インナーソース計画書は4つのセクションで構成する。次のセクションから順に解説する。
Section 1：Scope & Governance（スコープとガバナンス）
最初のセクションでは、インナーソース化するリポジトリの対象範囲と意思決定の仕組みを定義する。
スコープが曖昧なまま進めると、どのコードベースが対象かわからず、貢献者が迷う。ガバナンスを明文化することで、Trusted Committer（信頼されたコミッター）とGuest Contributor（外部コントリビューター）の役割が明確になる。
Scope（対象範囲）の書き方
対象リポジトリと対象外リポジトリをリストアップする。
| 項目 | 英語表現 | 日本語訳 |
|---|---|---|
| 対象リポジトリ | Repositories in scope | 対象リポジトリ |
| 対象外リポジトリ | Repositories out of scope | 対象外リポジトリ |
| 対象チーム | Contributing teams | コントリビューティングチーム |
| 開始日 | Effective date | 発効日 |
英語テンプレート：
## Scope
### Repositories in Scope
- platform/api-gateway
- platform/shared-ui-components
- platform/logging-library
### Repositories Out of Scope
- product/customer-portal (proprietary)
- product/billing-service (compliance restricted)
### Contributing Teams
All engineering teams across all offices are eligible to contribute.日本語テンプレート：
## スコープ
### 対象リポジトリ
- platform/api-gateway
- platform/shared-ui-components
- platform/logging-library
### 対象外リポジトリ
- product/customer-portal（独自仕様のため除外）
- product/billing-service（コンプライアンス制約あり）
### 対象チーム
全拠点のエンジニアリングチームがコントリビューション可能。Governance（ガバナンス）の書き方
役割と意思決定プロセスを定義する。
| 役割 | 英語表現 | 責任 |
|---|---|---|
| リポジトリオーナー | Repository Owner | 方針策定・最終承認 |
| 信頼されたコミッター | Trusted Committer | PRレビュー・マージ権限 |
| 外部コントリビューター | Guest Contributor | 機能追加・バグ修正 |
| プロダクトオーナー | Product Owner | ロードマップ管理 |
英語テンプレート：
## Governance
### Roles and Responsibilities
| Role | Responsibility |
|------|---------------|
| Repository Owner | Define strategy, approve major changes |
| Trusted Committer | Review and merge pull requests, mentor contributors |
| Guest Contributor | Submit pull requests for features or bug fixes |
| Product Owner | Manage roadmap and prioritize backlog |
### Decision-Making Process
Major architecture changes require approval from the Repository Owner.
Day-to-day contributions follow the standard pull request process.Section 2：Repository Structure（リポジトリ構造）
2つ目のセクションでは、インナーソース対応リポジトリの標準構造を定義する。
OSSと同様に、リポジトリのルートに必要なファイルを揃えることで、貢献者がすぐにプロジェクトの目的とルールを把握できる。ドキュメント不足は貢献者離れの主な原因だ。
必須ファイル一覧
| ファイル | 目的 | 日本語訳 |
|---|---|---|
README.md | プロジェクト概要・使い方 | 読み方・使い方ガイド |
CONTRIBUTING.md | コントリビューション手順 | 貢献方法ガイド |
CODE_OF_CONDUCT.md | 行動規範 | 行動規範 |
CODEOWNERS | レビュー担当者の定義 | コードオーナー設定 |
CHANGELOG.md | 変更履歴 | 変更履歴 |
LICENSE | ライセンス（社内ライセンス） | ライセンス |
CONTRIBUTING.md の書き方
CONTRIBUTING.md はインナーソースの中核ドキュメントだ。貢献者が最初に読むファイルになる。
英語テンプレート：
## Contributing to [Repository Name]
Thank you for your interest in contributing!
### How to Contribute
1. Fork the repository and create a feature branch.
2. Follow the coding standards in [CODING_STANDARDS.md](./CODING_STANDARDS.md).
3. Write unit tests for all new functionality.
4. Submit a pull request with a clear description.
### Pull Request Requirements
- All CI checks must pass.
- At least one Trusted Committer must approve.
- No unresolved comments before merging.
### Getting Help
Open an issue or contact the Trusted Committer via [Slack channel: #innersource-support].日本語テンプレート：
## [リポジトリ名]へのコントリビューション
コントリビューションにご関心をいただきありがとうございます！
### コントリビューション手順
1. リポジトリをフォークしてフィーチャーブランチを作成する。
2. [CODING_STANDARDS.md](./CODING_STANDARDS.md)のコーディング規約に従う。
3. 新機能にはユニットテストを記述する。
4. 明確な説明とともにプルリクエストを提出する。
### プルリクエストの要件
- CIチェックがすべて通過していること。
- Trusted Committer が最低1名承認していること。
- 未解決のコメントがないこと。
### サポートの受け方
Issueを作成するか、[Slack: #innersource-support]でTrusted Committerに連絡する。コーディング規約の詳細については、英語コーディング規約の書き方も参照してほしい。
Section 3：Contribution Process（コントリビューションプロセス）
3つ目のセクションでは、Guest Contributorがコードを提出してマージされるまでの標準フローを定義する。
プロセスが不明確だと、PRの品質がばらつき、Trusted Committerのレビュー負荷が増大する。標準フローを文書化することで、誰でも一定品質のコントリビューションができる状態を作る。
コントリビューションフロー
| ステップ | アクション | 英語表現 |
|---|---|---|
| 1 | 課題の特定・起票 | Identify issue and create an issue ticket |
| 2 | Trusted Committerへの相談 | Consult with the Trusted Committer |
| 3 | フォーク・ブランチ作成 | Fork and create a feature branch |
| 4 | 実装・テスト作成 | Implement changes and write tests |
| 5 | プルリクエスト提出 | Submit a pull request |
| 6 | コードレビュー | Code review by Trusted Committer |
| 7 | 修正・再レビュー | Address review comments |
| 8 | マージ・デプロイ | Merge and deploy |
Issue テンプレートの書き方
コントリビューション前にIssueを起票することで、重複作業や方向性のズレを防ぐ。
英語テンプレート：
## Issue Title: [Feature Request / Bug Fix / Improvement]
### Summary
Describe the problem or enhancement in 2–3 sentences.
### Motivation
Explain why this change is needed and who benefits.
### Proposed Solution
Describe your approach at a high level.
### Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
### Affected Repositories
- platform/api-gateway日本語テンプレート：
## Issueタイトル：[機能追加 / バグ修正 / 改善]
### 概要
問題または改善点を2〜3文で記述する。
### 背景
この変更が必要な理由と、誰が恩恵を受けるかを説明する。
### 提案する解決策
アプローチを概要レベルで説明する。
### 受け入れ基準
- [ ] 基準1
- [ ] 基準2
### 対象リポジトリ
- platform/api-gatewayPull Request テンプレートの書き方
PRテンプレートを .github/PULL_REQUEST_TEMPLATE.md に配置することで、レビュー品質が向上する。
英語テンプレート：
## Description
What does this pull request do? Summarize in 2–3 sentences.
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Refactoring
- [ ] Documentation
## How to Test
1. Step 1
2. Step 2
## Checklist
- [ ] Code follows the coding standards
- [ ] Unit tests are added or updated
- [ ] CHANGELOG.md is updated
- [ ] No breaking changes (or breaking changes are documented)Section 4：Community & Communication（コミュニティとコミュニケーション）
4つ目のセクションでは、インナーソースコミュニティの育成と情報共有の仕組みを定義する。
コードとプロセスだけ整えても、コミュニティがなければインナーソースは続かない。Trusted Committerが孤立し、貢献者が増えないまま終わるケースが多い。コミュニティ設計を計画書に含めることが重要だ。
コミュニティ運営の構成要素
| 要素 | 英語表現 | 目的 |
|---|---|---|
| Slackチャンネル | Slack channels | 非同期コミュニケーション |
| 月次ミーティング | Monthly InnerSource sync | 進捗共有・課題議論 |
| ドキュメントポータル | Documentation portal | 設計書・ガイドの集約 |
| コントリビューター表彰 | Contributor recognition | 貢献文化の強化 |
| オンボーディングガイド | Onboarding guide | 新規貢献者の参入障壁低下 |
Communication Plan の書き方
英語テンプレート：
## Community & Communication Plan
### Slack Channels
| Channel | Purpose |
|---------|---------|
| #innersource-announce | Announcements from Repository Owners |
| #innersource-support | Q&A for Guest Contributors |
| #innersource-reviews | PR review requests and discussions |
### Monthly Sync Meeting
- Frequency: First Tuesday of every month
- Duration: 30 minutes
- Agenda:
1. Contribution metrics review (10 min)
2. Open issues and blockers (10 min)
3. Roadmap updates (10 min)
### Contributor Recognition
Top contributors are highlighted in the monthly newsletter
and recognized at the All-Hands meeting.日本語テンプレート：
## コミュニティとコミュニケーション計画
### Slackチャンネル
| チャンネル | 目的 |
|-----------|------|
| #innersource-announce | リポジトリオーナーからのアナウンス |
| #innersource-support | ゲストコントリビューター向けQ&A |
| #innersource-reviews | PRレビュー依頼と議論 |
### 月次同期ミーティング
- 頻度：毎月第1火曜日
- 所要時間：30分
- アジェンダ：
1. コントリビューション指標レビュー（10分）
2. 未解決Issueと課題（10分）
3. ロードマップ更新（10分）
### コントリビューター表彰
月次ニュースレターとAll-Handsミーティングで
優秀なコントリビューターを表彰する。メトリクスの定義
インナーソースの成果を定量化するため、KPIを設定する。
| メトリクス | 英語表現 | 測定方法 |
|---|---|---|
| 外部PRの数 | Number of guest PRs | GitHubのPR一覧 |
| マージ率 | PR merge rate | マージ数÷提出数 |
| レビュー所要時間 | Average review turnaround | PRオープンからマージまで |
| アクティブコントリビューター数 | Active contributors | 月間コミット者数 |
| ドキュメントカバレッジ | Documentation coverage | Wiki更新頻度 |
インナーソースで整備した技術標準は、プラットフォームエンジニアリングとも密接に連動する。英語プラットフォームエンジニアリング計画書の書き方も合わせて参照してほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
【英語インナーソース計画書】
組織名：
作成日：
作成者：
発効日：
■ 1. スコープとガバナンス
対象リポジトリ：
対象外リポジトリ：
対象チーム：全拠点のエンジニアリングチーム
役割 | 担当者 | 責任
----|--------|----
Repository Owner | | 方針策定・最終承認
Trusted Committer | | PRレビュー・マージ・メンタリング
Guest Contributor | | 機能追加・バグ修正のPR提出
Product Owner | | ロードマップ管理・バックログ優先度付け
■ 2. リポジトリ構造
ファイル | 目的 | ステータス
--------|------|----------
README.md | プロジェクト概要・使い方 |
CONTRIBUTING.md | コントリビューション手順 |
CODE_OF_CONDUCT.md | 行動規範 |
CODEOWNERS | レビュー担当者の定義 |
CHANGELOG.md | 変更履歴 |
LICENSE | 社内ライセンス |
■ 3. コントリビューションプロセス
ステップ | アクション | 担当
--------|-----------|----
1 | 課題の特定・Issue起票 | Guest Contributor
2 | Trusted Committerへの相談 | Guest Contributor
3 | フォーク・ブランチ作成 | Guest Contributor
4 | 実装・テスト作成 | Guest Contributor
5 | プルリクエスト提出 | Guest Contributor
6 | コードレビュー | Trusted Committer
7 | 修正・再レビュー | 両者
8 | マージ・デプロイ | Trusted Committer
PRチェックリスト：
□ コーディング規約に準拠している
□ ユニットテストを追加・更新している
□ CIチェックが全て通過している
□ CHANGELOG.mdを更新している
■ 4. コミュニティとコミュニケーション
チャンネル | 目的
----------|----
#innersource-announce | リポジトリオーナーからのアナウンス
#innersource-support | ゲストコントリビューター向けQ&A
#innersource-reviews | PRレビュー依頼と議論
KPIメトリクス | 目標値 | 現在値
------------|--------|------
外部PRの数（月間）| |
PRマージ率| |
平均レビュー所要時間| |
アクティブコントリビューター数| |英語版テンプレート（コピペOK）
[InnerSource Plan]
Organization:
Date:
Author:
Effective Date:
■ 1. Scope & Governance
Repositories in Scope:
Repositories Out of Scope:
Contributing Teams: All engineering teams across all offices
Role | Assignee | Responsibility
-----|----------|---------------
Repository Owner | | Define strategy, approve major changes
Trusted Committer | | Review and merge PRs, mentor contributors
Guest Contributor | | Submit PRs for features or bug fixes
Product Owner | | Manage roadmap and prioritize backlog
■ 2. Repository Structure
File | Purpose | Status
-----|---------|-------
README.md | Project overview and usage |
CONTRIBUTING.md | Contribution guidelines |
CODE_OF_CONDUCT.md | Community standards |
CODEOWNERS | Designated reviewers |
CHANGELOG.md | Version history |
LICENSE | Internal license |
■ 3. Contribution Process
Step | Action | Owner
-----|--------|------
1 | Identify issue and create an issue ticket | Guest Contributor
2 | Consult with the Trusted Committer | Guest Contributor
3 | Fork and create a feature branch | Guest Contributor
4 | Implement changes and write tests | Guest Contributor
5 | Submit a pull request | Guest Contributor
6 | Code review | Trusted Committer
7 | Address review comments | Both
8 | Merge and deploy | Trusted Committer
PR Checklist:
□ Code follows the coding standards
□ Unit tests are added or updated
□ All CI checks pass
□ CHANGELOG.md is updated
■ 4. Community & Communication
Channel | Purpose
--------|--------
#innersource-announce | Announcements from Repository Owners
#innersource-support | Q&A for Guest Contributors
#innersource-reviews | PR review requests and discussions
KPI Metric | Target | Current
-----------|--------|--------
Guest PRs per month | |
PR merge rate | |
Avg. review turnaround | |
Active contributors | |英語インナーソース計画書の全体構成まとめ
4つのセクションを組み合わせた全体構成は以下の通りだ。
| セクション | 英語表記 | 主な内容 |
|---|---|---|
| Section 1 | Scope & Governance | 対象リポジトリ・役割定義・意思決定 |
| Section 2 | Repository Structure | 必須ファイル・CONTRIBUTING.md |
| Section 3 | Contribution Process | Issue/PRテンプレート・フロー定義 |
| Section 4 | Community & Communication | Slack・月次ミーティング・KPI |
この4セクション構成で計画書を作成すれば、Trusted Committerと Guest Contributorの役割が明確になる。ドキュメント主導の貢献文化が社内に根づいていく。
インナーソース開発環境のセキュリティポリシーを強化するには、英語セキュリティロードマップ計画書の書き方と組み合わせることで、開発・運用・セキュリティの方針を一体的に管理できる。
まとめ：英語インナーソース計画書は4つのセクションで完成する
英語インナーソース計画書は、以下の4セクションで構成する。
- Scope & Governance：対象リポジトリと役割を定義する
- Repository Structure：
CONTRIBUTING.mdなど必須ファイルを整備する - Contribution Process：IssueとPRの標準テンプレートを用意する
- Community & Communication：Slackチャンネルと月次ミーティングで貢献文化を育てる
この構成で英語計画書を作成することで、全拠点のエンジニアがインナーソースに参加できる環境が整う。社内のコード共有が加速し、横断的なイノベーションが生まれやすくなる。
インナーソースで採用する技術の意思決定を可視化したい場合は、英語テックレーダー設計書の書き方と組み合わせることで、技術選定の根拠も英語で体系化できる。
コメント