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

InnerSource Patterns: 基本原則ガイダンスの文書化

InnerSource Patterns: 基本原則ガイダンスの文書化

概要
パターンの著者: Isabel Drost-Fromm / Georg Grütter
スピーカー/翻訳: Yuki Hattori | LinkedIn | Twitter | GitHub
YouTube: 基本原則ガイダンスの文書化
Doc: 基本原則ガイダンスの文書化

「InnerSource Patterns: 基本原則ガイダンスの文書化」
「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープンソースのバックグラウンドがない人々にはうまく機能しません。
解決策として、インナーソースの最も重要な原則を文書化し広く公開します。

リンク
InnerSource Patterns: English 🇬🇧| 日本語 🇯🇵
Website: innersourcecommons.org
Slack: Invite Link | 🇯🇵#jp-general
Twitter: @InnerSourceJP (日本) | @InnerSourceOrg (公式)

Yuki Hattori

January 13, 2023
Tweet

More Decks by Yuki Hattori

Other Decks in Technology

Transcript

  1. ソリューション 組織内でインナーソースの取り組みを推進する人は、オープンソースの深いバックグランドを持たず、イン ナーソースを直感的に理解できていないチームや個人を支援する必要があります。 以下の2 つの分野を文書化することで、チームや個人に対して明確な情報を提供する必要があります。 1. 目的: なぜ組織はインナーソースを採用するのか? 2. 原則:

    どのインナーソースの原則は、これらの課題に対処するのに役立つのか? 以下のセクションでは、この2 つの詳細について説明します。あなたの組織が目的と原則を文書化するため に、このセクションはよい出発点になるでしょう。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 7
  2. 5. 書面によるアドバイスを永続的で検索可能なアーカイブに蓄積でき るようにする プロジェクトのすべてのコミュニケーション、特に決定事項やその決定に至るまでの議論はアーカイブされ る必要があります。また、コミュニケーションは安定したURL で参照できるようにする必要があり、過去の コミュニケーションも、簡単に検索できる形で保存される必要があります。 ただし、2 つの注意点があります。 1.

    これは構造化された文書に取って代わるものではありません。しかし一方で、構造化されたドキュメン トを収集するための出発点として機能もします。 2. すべてを文書化し、組織全体がアクセスできるようにするというルールには例外があります。人に関す る議論やセキュリティに関する議論は機密事項であり、人前で行うべきではありません。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 15
  3. 事例: GitHub (3) 原則の例 機能負債を抱えるようなMVP (Minimum Viable Product )は避ける。顧客からのフィードバックを得るた めにMVP

    を出荷することは構いませんが、コントリビュートするチームはその機能セットを完成させる ことを約束しなければなりません。例えば、以下のようなことです。 MVP を越えて、ほとんどの顧客を満足させるソリューションにするためのコミットメント 新機能の管理を完全にサポートすること API のみを提供するのではなく UI と API の両方のインタフェースを提供する(またはその逆) 本番環境へのデプロイまで、またそれ以降も機能作業をサポートする インクリメンタルなロールアウトの連携 顧客からの( 機能やバグに関する) フィードバックに対応するための時間をプランニングする 正しい方法で機能を構築する( 技術的負債を作らない) プロダクトチームおよびエンジニアリングチームとの要件およびソリューションの合意 適切なアーキテクチャと設計 クラウドおよびローカルの本番環境でサポートされている バグの修正とドキュメントの更新 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 21
  4. 事例: GitHub (4) エンゲージメント エンゲージメントモデルを使用するのは、チームが責任範囲外の領域に機能を提供するときに、チームが実 行できる具体的な手順を示すためです。 GitHub の一般的なエンゲージメントモデルは以下です。 プロダクトオーナーから、機能のセッティングとロールアウトプランの承認を得る エンジニアリングオーナー(

    通常、エンジニアリングマネージャーとディレクター) から、非機能要件( テ レメトリ、テストカバレッジ、マルチ環境テストとサポート) への対応を含むエンジニアリング設計の承 認を得る 新規または変更された要件のレビューとともに、コードレビューを実施する。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 22
  5. 事例: Robert Bosch のインナーソース原則 Bosch のインナーソースイニシアチブBIOS は以下の原則を持ちます オープン性: BIOS コミュニティへの参入障壁を低くします。

    透明性: 徹底的に透明性を高め、仕事上の成果物、コミュニケ ーション、意思決定を社内の全社員と共有します 自発性: BIOS コミュニティに参加し、コントリビュートするか どうかの判断は、各人に任されています。社員は上司に言われ たからではなく、自発的な動機で BIOS に参画すべきです 自己決定: BIOS コミュニティは、何に取り組むか、いつ取り組 むか、どのようなツールやプロセスを使って取り組むかを自由 に選択することができます 功績至上主義: BIOS プロジェクトメンバーには、その功績に基 づいて、つまりコントリビューションの質と量に基づいて権力 が付与されます InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 23
  6. InnerSource についてもっと知る InnerSource Commons: https://innersourcecommons.org Join our Slack community: https://innersourcecommons.org/slack

    InnerSource Patterns: https://patterns.innersourcecommons.org Twitter: @InnerSourceOrg 日本語 Slack チャンネル: #jp-general 日本語 Twitter: @InnerSourceJP InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 25