Deep Dive into InnerSource Patterns Yuki Hattori (@yuhattor) VP of the InnerSource Commons Foundation Sr. Architect at GitHub

InnerSource Commons は、InnerSourceの実践者の世界 最⼤のコミュニティです。組織という枠の中でソフトウェア開発に オープンソースのベストプラクティスを活⽤するInnerSourceに関 するナレッジの創出と共有に特化しています。 2015年に設⽴された InnerSource Commons は、現在 750 以上の企業、学術機関、政府機関から3000⼈以上の個⼈を サポートしつないでいます。 Deep Dive into InnerSource Patterns The InnerSource Commons Foundation @yuhattor

No content

InnerSource のワーキンググループ InnerSource リソースの翻訳 InnerSource の勉強会開催 / 動画作成 Deep Dive into InnerSource Patterns InnerSource Commons Japan @yuhattor

“Applying the concepts and lessons of successful open source ecosystems to how a company develops software internally Deep Dive into InnerSource Patterns InnerSource is ... @yuhattor “成功したオープンソース‧エコシステムのコンセプトと学びを、 企業が社内でソフトウェアを開発する⽅法に適⽤する"

Deep Dive into InnerSource Patterns InnerSource の4つの原則 @yuhattor Openness - オープンなプロジェクト リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって⼗分にドキュメント化され発⾒できるように なっていなければなりません。 Transparency - 透明性 プロジェクト/リポジトリとその⽅向性未解決の機能要件機能要件の進捗ホストチームの意思決事項を透明にします。 Prioritized Mentorship - 優先的なメンターシップ Trusted Committer によるホストチームからゲストチームへの優先的なメンターシップにより、ゲストチームの コントリビューター は、ホストチーム のプロジェクト/リポジトリについて⼗分理解し、成功裏に変更できるようにレベルアップされます。 Voluntary Code Contribution - ⾃発的なコードコントリビューション ゲストチームとホストのチームの両⽅からInnerSourceに参加することが、彼らの⾃由意志に基づいて⾏われること

Deep Dive into InnerSource Patterns InnerSource を実現する 4 ポイント @yuhattor 3 発⾒可能性 パートナーチームがコードベース、ドキュメント、およびその他の関連資料を すべて検索し、事前のドメイン知識なしでプロジェクトを探索すること 実⾏可能性 パートナーチームがソースコードを迅速かつ簡単にコンパイルおよび実⾏できる、または別プロジェ クトの⼀部としてソースコードを簡単に使⽤できること。カプセル化されており、即実⾏できる。 貢献性 パートナーチームが問題を簡単に報告し、質問し、新しい機能を提案し、障壁なく前向きな ⽅法でコミットをアップストリームにすること 継続性 すべてのチームがコードをメンテナンスし続けること

Deep Dive into InnerSource Patterns InnerSource をドライブするということは @yuhattor • コラボレーションを妨げたり、 遅らせたりする障壁を取り除く/減らす • オープン/協⼒的な⾏動を奨励する • 客観的な尺度で現状を評価し、伝える • ステータスと進捗状況を測定するための データを提供する • ⽂化的変化を促進する • ⼈の働き⽅を決める • 新しい統制プロセスの追加 • 活動を抑制する • コードベースのキュレーション • 新しいツールを⾃前で構築 以下である。 以下でない。

Deep Dive into InnerSource Patterns InnerSource をドライブするということは @yuhattor • 特定の⽬的のための、複雑なソリューション • 貢献 = 気晴らし • ⾃分のコード • ⾞輪の再発明 • 製品 = コード • よりシンプルなモジュール式コンポーネント • 貢献 = コラボレーションとコミュニティへの投資 • 私たちのコード • 再利⽤し構築 • 製品 != コード かつての運⽤ インナーソースの狙い Product Product Product Product Product Product Product Product 最⼤化を狙う 少ない共有部分

Deep Dive into InnerSource Patterns InnerSource プログラムオフィス @yuhattor 3 役割 InnerSourceプログラムオフィスは、InnerSourceを有効にす るための⼿段と環境を提供します。 プログラムオフィスは開発を促進しますが、開発部⾨やゲート キーパーではありません。 タスク • InnerSource ⽅針の共有 • 指導の実施 • インセンティブモデルの開発 • システムのアドバイザリー • ⽀援活動を組織化する • 適切なツーリングの確保

Deep Dive into InnerSource Patterns InnerSource アンチパターン @yuhattor ISPO の⽅針 対象プロジェクトの選定 マインドセット • ⾮継続的なプロジェクト • ⾃社の開発者がいない • 特定⽬的の複雑なソリューション • コードのエンドユーザーが開発者意外 • ⼈の働き⽅を決める • 新しい統制プロセスを追加 • コードベースのキュレーション • 新しいツールを⾃前で構築 • 新タイプのリポジトリを作成 • ⾃分のコードは⾃分のもの • 貢献は「気晴らし」である • ⾞輪の再発明 • 製品 = コード

Deep Dive into InnerSource Patterns メンテナーへの道のり @yuhattor 🧑🧑🧒🧒 📣 🛠 ユーザー コントリビューター メンテナー

Deep Dive into InnerSource Patterns プラクティス集 - InnerSource Patterns @yuhattor ソフトウェアライフサイクル全体で参加型システムを作成し、デザインドキュメントを公開して早期のディスカッションを促進する。 30⽇の保証期間 社内兼業コントリビューター インナーソースライセンス インナーソースベースドキュメント インナーソースポータル インナーソースデザインドキュメント 基本原則ガイダンスの⽂書化 トラステッドコミッター コントリビューターが30⽇間のサポート付きでバグ修正や機能提案をすることで、両チームの信頼を向上させる。 ボランティアではなく、組織内で正式な契約と合意をすることによって、InnerSourceへの貢献を促す。 組織内でソースコードを共有するための法的枠組みを提供し、新たなコラボレーションオプションを提供する。 InnerSourceプロジェクト情報をインデックス化し、コントリビューターが興味を持つプロジェクトを発⾒しやすくする。 継続的なコントリビューターの仕事を認識し、報酬を与える⽅法を定義する 標準的なプロジェクトドキュメントを提供し、新規コントリビューターに⾃⼰サービスプロセスを提供する。 InnerSourceの主要原則を⽂書化し、広く公開する。 パターン名 パターンの概要

Deep Dive into InnerSource Patterns コラボレーション

概要 インナーソースコントリビューターへの効果的な感謝と認知 シナリオ 感謝の表現⽅法が不明確 忙しさで感謝を忘れがち コミュニティの維持・発展が必要 ポイント 公開の場での感謝表明 マネージャーへの個別連絡 誠実で適格な感謝 コミュニティの活性化 継続的な関与の促進 Deep Dive into InnerSource Patterns コントリビューションの功労を称える @yuhattor

概要 標準的なドキュメント形式による新規コントリビューターの ⽀援 シナリオ プロジェクトの⽬的や貢献⽅法が不明確 セルフサービスのドキュメントが不⾜ 基本的な質問への対応に時間を要する ポイント README.mdでの基本情報提供 CONTRIBUTING.mdでの貢献⼿順説明 プロジェクトミッションの明確化 コミュニケーションチャネルの明⽰ トラステッドコミッターの役割説明 Deep Dive into InnerSource Patterns スタンダード・ベース・ドキュメンテーション @yuhattor

概要 イシュートラッカーを進捗管理だけでなく、コミュニケーションツールとして活⽤ シナリオ 多くのチームが依存するコンポーネントの開発 イシューの⽂脈が限定的 ⾮同期コミュニケーションの必要性 ポイント バグ・機能・アイデアを別イシューで管理 質問やブレーンストーミングにも活⽤ タグやカテゴリーで⽬的を区別 テンプレートを活⽤して情報を整理 ⽂書によるコミュニケーションを重視 Deep Dive into InnerSource Patterns イシュートラッカーの使い⽅を多様化する @yuhattor

概要 コントリビューションを受け⼊れる際の信頼関係を構築する ための保証期間制度 シナリオ チームが他チームからのコントリビューションに抵抗があ る コードの品質や保守性への不安がある バグ修正のサポートが得られるか不安 ポイント コントリビュートしたコードに30⽇間の保証期間を設ける 保証期間中はバグ修正のサポートを提供 明確なコントリビューションガイダンスを提供 チーム間の信頼関係を構築 エスカレーションの軽減につながる Deep Dive into InnerSource Patterns 30⽇の保証期間 @yuhattor

概要 標準的なコミュニケーションツールの設定と⽂書化による透明性の確保 シナリオ プロジェクトチームとの連絡が困難 アドホックなコミュニケーション 情報が分散し検索困難 ポイント 公開された検索可能なチャネル トピック中⼼のコミュニケーション イシュートラッカーの活⽤ ⾮同期コミュニケーションの重視 READMEでの⽂書化 Deep Dive into InnerSource Patterns コミュニケーションツーリング @yuhattor

Deep Dive into InnerSource Patterns アーキテクチャ / デザイン

概要 DevOps環境での共有コードベースの責任分担の明確化 シナリオ サービスダウン時の責任が不明確 チーム間のエスカレーションパスが異なる セキュリティや規制の制約が異なる ポイント ソースコードとデプロイメントの分離 共有コードのライブラリ化 独⽴した環境での展開 明確なエスカレーションチェーン 運⽤の標準化促進 Deep Dive into InnerSource Patterns サービス対ライブラリ @yuhattor

概要 チーム横断的な意思決定プロセスを透明化し、関係者全員が 参加できる仕組みを構築 シナリオ 複数チームで共有されているプロジェクト ⼤規模な横断的変更が必要 ⾮同期での意思決定が求められる ポイント RFCテンプレートとプロセスの導⼊ 意思決定プロセスの⺠主化 オープンな⾮同期コミュニケーション 決定事項の記録と参照が可能 経験豊富なエンジニアの影響⼒拡⼤ Deep Dive into InnerSource Patterns RFCを⽤いたチーム横断的な意思決定の透明化 @yuhattor

概要 複数プロジェクトのニーズを満たす共通コードの要件調整と リファクタリング シナリオ 共有コードが全プロジェクトのニーズを満たさない プロジェクト間で要件が異なる コードの再利⽤が困難 顧客ごとに異なる表現⽅法 ポイント プロジェクト要件の調整 コードの適切な分割 顧客との要件交渉 共通部分の特定 再利⽤性の向上 Deep Dive into InnerSource Patterns 共通要件 @yuhattor

概要 拡張機構を通じてプロジェクトの能⼒を効率的にスケールア ップする⽅法 シナリオ コントリビューションの急増 レビュー負荷の増⼤ メンテナンスの困難 リリースの遅延 ポイント 簡単な拡張作成 疎結合アーキテクチャ 依存関係の管理 テスト戦略の確⽴ 発⾒性と利便性の向上 Deep Dive into InnerSource Patterns 持続可能な成⻑のためのエクステンション @yuhattor

Deep Dive into InnerSource Patterns メンテナンス

概要 プロジェクトの価値を⾼め、コントリビューターを⽀援する 信頼された貢献者の役割 シナリオ プロジェクトのスケーリングが必要 頻繁な貢献者への報酬が不明確 チーム間の貢献認識の仕組みが不⾜ メンテナーの負担が増⼤ ポイント 役割と責任の明確な定義 公式な認定プロセス 継続的なサポートと関係維持 コミュニティ内での可視性向上 キャリア開発機会の提供 Deep Dive into InnerSource Patterns トラステッドコミッター @yuhattor

概要 プロジェクトの基本的な項⽬を専⾨に担当するチームの設⽴ シナリオ プロジェクトが複雑で貢献が困難 技術的負債が蓄積 プロジェクトの採⽤が遅い 明確なオーナーシップが不在 ポイント 健全なエコシステムの維持 インフラとドキュメントの整備 トラステッドコミッターとしての役割 利⽤と貢献の促進 メトリクスによる成果測定 Deep Dive into InnerSource Patterns コアチーム @yuhattor

Deep Dive into InnerSource Patterns インナーソース推進

概要 インナーソースの重要な原則と⽬的を明確に⽂書化し共有す る取り組み シナリオ オープンソース経験者以外への説明が困難 インナーソースの⽬的が不明確 チーム間で実践⽅法にばらつき 組織全体への展開が遅延 ポイント ⽬的と原則の明確な⽂書化 透明性と共有の重視 ⾮同期コミュニケーション 学習機会としての失敗の受容 トラステッドコミッターの報酬 Deep Dive into InnerSource Patterns 基本原則ガイダンスの⽂書化 @yuhattor

概要 期間限定の実験としてインナーソースを開始し、マネージャ ーの承認を得やすくする シナリオ 経営陣の投資への躊躇 ⻑期的コミットメントへの不安 既存の作業モデルからの逸脱 規制や法的制約の懸念 ポイント 明確な実験期間の設定 参加基準の定義 メトリクスによる効果測定 レビュー委員会の設⽴ 段階的な展開計画 Deep Dive into InnerSource Patterns 実験として始める @yuhattor

概要 インナーソースの取り組みを成功させるために、適切なスキ ルと経験を持つ専任のコミュニティリーダーを選任する シナリオ リーダーシップの経験不⾜ 時間の制約 コミュニケーション不⾜ コミュニティの成⻑停滞 ポイント オープンソース経験者の選任 100%の時間割り当て コミュニケーションスキル重視 功績⾄上主義の実践 経営陣との橋渡し Deep Dive into InnerSource Patterns 正式なコミュニティリーダー @yuhattor

概要 インナーソースプロジェクトの発⾒と宣伝を容易にするポー タルサイト シナリオ インナーソースプロジェクトの可視性が低い コントリビューターの発⾒が困難 プロジェクトの宣伝⼿段が限られている ポイント プロジェクトの検索と発⾒を容易に プロジェクト情報の⼀元管理 メタデータによる詳細な検索 オーナーによる情報管理 コミュニティの形成を促進 Deep Dive into InnerSource Patterns インナーソースポータル @yuhattor

概要 プロジェクトの活性度を数値化し、コントリビューターの発 ⾒を⽀援する指標 シナリオ アクティブなプロジェクトの発⾒が困難 新規プロジェクトの可視性が低い プロジェクトの活性度評価が不明確 多数のプロジェクトの管理が必要 ポイント GitHubメトリクスの活⽤ ⾃動スコア計算の実装 新規プロジェクトの優遇 ソフトKPIの考慮 定期的な更新と調整 Deep Dive into InnerSource Patterns リポジトリアクティビティスコア @yuhattor

概要 インナーソースプロジェクトのニーズを「ギグ」として掲載 し、スキルと時間要件を明⽰したマーケットプレイスを確⽴ シナリオ 貢献機会の発⾒が困難 時間コミットメントの不明確さ 専⾨的利点の理解不⾜ 貢献の追跡と報酬の課題 ポイント ギグベースのイントラネット構築 スキルと時間要件の明確化 ポイントベースの評価システム 透明性の確保 キャリア開発への活⽤ Deep Dive into InnerSource Patterns ギグマーケットプレイス @yuhattor

概要 組織内でのソースコード共有のための再利⽤可能な法的枠組み シナリオ 複数の法⼈間でのコード共有が必要 法的責任と会計処理の懸念 プロジェクトごとの契約作成が障壁 ポイント 汎⽤的なライセンス枠組みの提供 フリーソフトウェアの4つの⾃由を統合 法⼈間の権利と義務を明確化 コード共有の簡素化 コラボレーションの促進 Deep Dive into InnerSource Patterns インナーソースライセンス @yuhattor

概要 インナーソースへの貢献を希望する社員と直属上司の間の正 式な契約による調整 シナリオ 中間管理職の抵抗 リソース配分の課題 業務時間の制約 部⾨間の利害対⽴ ポイント 正式な契約の締結 作業時間の明確な割り当て 優先順位の明確化 中央資⾦による払い戻し パフォーマンス評価への反映 Deep Dive into InnerSource Patterns コントラクトコントリビューター @yuhattor

Deep Dive into InnerSource Patterns 評価

概要 シニアマネージャーとインナーソースイニシアチブ間のイン ターフェースとしての委員会 シナリオ 伝統的な管理スタイルからの変⾰が必要 マイクロマネジメントのリスク プロジェクトの監視と制御が必要 資⾦提供の決定が必要 ポイント 定期的な委員会の開催 プロジェクト提案と状況報告 建設的なフィードバック 適切な⾃⼰組織化の許可 透明性のある意思決定 Deep Dive into InnerSource Patterns レビュー委員会 @yuhattor

概要 クロスチームプロジェクトの価値を定量的に評価するフレームワーク シナリオ 収益への直接的影響が⾒えにくい 価値が複数部⾨に分散 資⾦調達の正当性が必要 ポイント データ駆動型の評価⼿法 時間コストの定量化 最悪ケースの限界設定 価値の可視化 優先順位付けの基準提供 Deep Dive into InnerSource Patterns クロスチームプロジェクト評価 @yuhattor

概要 インナーソースの採⽤レベルを評価し、次のステップを発⾒ するための成熟度モデル シナリオ プロジェクト間で理解度に差がある 次のステップが不明確 ベストプラクティスの認識不⾜ 組織全体での標準化が必要 ポイント 透明性の評価 コラボレーションの成熟度 コミュニティの発展 ガバナンスの確⽴ 役割の明確化 Deep Dive into InnerSource Patterns 成熟度モデル @yuhattor

Deep Dive into InnerSource Patterns Microsoft の InnerSource フレームワーク @yuhattor 3 1. 発⾒ 2. デザイン 3. 開発 4. デプロイ 5. メンテナンス • PMが新機能のリクエストを持ち 込む • PMが要件の検証（顧客インタ ビュー、既存のバックログに対す る機能の検証）を⾏い、 InnerSourcing のための機能の優 先順位を決定 • PMが要件ドキュメントを作成 • PMは、製品の⼀貫性（ユーザー エクスペリエンス、ルック＆ フィール、製品ロードマップの整 合性など）を確保するための要件 をレビューします。 • Dev/PM が要件をレビューし、 設計ソリューションを議論しま す。 • PMは、必要に応じてさらなる 顧客検証を実施します。 • Dev は、作業を開始する前に、 サポートしている開発者と設計 計画を議論します。 • 開発者は、開発チームの延⻑ 線上で働きます (すなわち、該 当プロダクトのコードベース で機能を構築、PR をチェック、 機能をテスト、バグバッシュ をホスト、デモ、ドキュメン トの作成を⾏います)。 • Dev は必要に応じてガイダン スを提供し、ブロッカーを取 り除きますます。 • PMが機能を有効にする前にコ ミュニティに新機能のリリー スを送信します。 • 顧客に影響を与える機能は、 混乱を防ぐために Feature Flag を⽤います。 • コードは通常、プルリクエス トを完了してから 4 時間以内 に本番環境にデプロイされま す。 • インナーソース中は、開 発者が開発した機能を⽀ 援したり、デバッグした りします。 • 最終的には、開発チーム が製品の責任者となり、 開発終了後も機能のメン テナンスを⾏います。 • Weekly PM シンク • Weekly Dev/PM シンク PM toolkit • インタビューのテンプレート • サンプル要件テンプレート • 製品ビジョン - スライド7 • 機能バックログ PM toolkit • 新機能リリーステンプレート 早めに、オープンに、書⾯でコミュニケーションをとる 貢献者をチームの ⼀員として扱う ⽂書化して実験を簡単に ex: 共通の要件 ex: 30⽇間保証 メンターシップ 貢献の Recognition Best Practices

Deep Dive into InnerSource Patterns Thank you! @yuhattor 3