Upgrade to Pro — share decks privately, control downloads, hide ads and more …

InnerSource Patterns - Japanese

InnerSource Patterns - Japanese

Yuki Hattori

February 20, 2025
Tweet

More Decks by Yuki Hattori

Other Decks in Technology

Transcript

  1. Deep Dive into InnerSource Patterns Yuki Hattori (@yuhattor) VP of

    the InnerSource Commons Foundation Sr. Architect at GitHub
  2. “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 “成功したオープンソース‧エコシステムのコンセプトと学びを、 企業が社内でソフトウェアを開発する⽅法に適⽤する"
  3. Deep Dive into InnerSource Patterns InnerSource の4つの原則 @yuhattor Openness -

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

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

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

    • 貢献 = 気晴らし • ⾃分のコード • ⾞輪の再発明 • 製品 = コード • よりシンプルなモジュール式コンポーネント • 貢献 = コラボレーションとコミュニティへの投資 • 私たちのコード • 再利⽤し構築 • 製品 != コード かつての運⽤ インナーソースの狙い Product Product Product Product Product Product Product Product 最⼤化を狙う 少ない共有部分
  7. Deep Dive into InnerSource Patterns InnerSource プログラムオフィス @yuhattor 3 役割

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

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

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

    プロジェクトミッションの明確化 コミュニケーションチャネルの明⽰ トラステッドコミッターの役割説明 Deep Dive into InnerSource Patterns スタンダード・ベース・ドキュメンテーション @yuhattor
  11. 概要 コントリビューションを受け⼊れる際の信頼関係を構築する ための保証期間制度 シナリオ チームが他チームからのコントリビューションに抵抗があ る コードの品質や保守性への不安がある バグ修正のサポートが得られるか不安 ポイント コントリビュートしたコードに30⽇間の保証期間を設ける

    保証期間中はバグ修正のサポートを提供 明確なコントリビューションガイダンスを提供 チーム間の信頼関係を構築 エスカレーションの軽減につながる Deep Dive into InnerSource Patterns 30⽇の保証期間 @yuhattor
  12. 概要 チーム横断的な意思決定プロセスを透明化し、関係者全員が 参加できる仕組みを構築 シナリオ 複数チームで共有されているプロジェクト ⼤規模な横断的変更が必要 ⾮同期での意思決定が求められる ポイント RFCテンプレートとプロセスの導⼊ 意思決定プロセスの⺠主化

    オープンな⾮同期コミュニケーション 決定事項の記録と参照が可能 経験豊富なエンジニアの影響⼒拡⼤ Deep Dive into InnerSource Patterns RFCを⽤いたチーム横断的な意思決定の透明化 @yuhattor
  13. 概要 拡張機構を通じてプロジェクトの能⼒を効率的にスケールア ップする⽅法 シナリオ コントリビューションの急増 レビュー負荷の増⼤ メンテナンスの困難 リリースの遅延 ポイント 簡単な拡張作成

    疎結合アーキテクチャ 依存関係の管理 テスト戦略の確⽴ 発⾒性と利便性の向上 Deep Dive into InnerSource Patterns 持続可能な成⻑のためのエクステンション @yuhattor
  14. 概要 インナーソースの重要な原則と⽬的を明確に⽂書化し共有す る取り組み シナリオ オープンソース経験者以外への説明が困難 インナーソースの⽬的が不明確 チーム間で実践⽅法にばらつき 組織全体への展開が遅延 ポイント ⽬的と原則の明確な⽂書化

    透明性と共有の重視 ⾮同期コミュニケーション 学習機会としての失敗の受容 トラステッドコミッターの報酬 Deep Dive into InnerSource Patterns 基本原則ガイダンスの⽂書化 @yuhattor
  15. 概要 インナーソースへの貢献を希望する社員と直属上司の間の正 式な契約による調整 シナリオ 中間管理職の抵抗 リソース配分の課題 業務時間の制約 部⾨間の利害対⽴ ポイント 正式な契約の締結

    作業時間の明確な割り当て 優先順位の明確化 中央資⾦による払い戻し パフォーマンス評価への反映 Deep Dive into InnerSource Patterns コントラクトコントリビューター @yuhattor
  16. 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