Slide 1

Slide 1 text

30 日の保証期間 InnerSource Patterns Speaker: Yuki Hattori (@yuhattor) Pattern Author: Cedric Williams

Slide 2

Slide 2 text

概要 30 日の保証期間プラクティスを利用すれば、自分のチーム以外からのコントリビューションを受け入れる際 に、コードを書いていないチームが責任を持つことに対する抵抗を軽減できます。このプラクティスを利用 すると、コードを受け取ったチームはコントリビュートしたチームに対してバグフィックスを提供すること を承諾することになります。その結果、両チーム間の信頼度が高まり、コントリビューションがより積極的 に受け入れられる可能性があります。 InnerSource Patterns: 30 日の保証期間 @yuhattor 2

Slide 3

Slide 3 text

問題 あるチームが、組織全体で使用されるコンポーネントを開発しています。 このチームはコントリビューショ ン( 機能への要求を含む) を受け入れることに抵抗したり、完全に拒否したりします。 この振る舞いは進行を妨げたり、エスカレーションによる頻繁な混乱につながります。 InnerSource Patterns: 30 日の保証期間 @yuhattor 3

Slide 4

Slide 4 text

状況 コントリビューションを受け入れる側のチームによって生み出されたコンポーネントを、コントリビュ ートした側のチームが使えるかどうか、それは他のチームが受け入れてくれるかに依存してしまいま す。 受け入れる側のチームが、コントリビュートされたコンポーネントや機能に対するリソース・知識・許 可を持っていないか、もしくは( それに加えて) それらのコンポーネントや機能を自分自身で書く意欲が ない場合があります。 InnerSource Patterns: 30 日の保証期間 @yuhattor 4

Slide 5

Slide 5 text

組織に働く力学 コントリビューションを受け入れる際には、過去の不正行為や不信感があり、コードの書き方の知識が ないことがあるため、疑念を持つことが自然である。 各チームは、自分たちのリーダーが目標を達成することを優先し、そのためには他のチームのコントリ ビューションを大きく書き換えることがある。 自分で書いていないコードに対する責任に抵抗があり、コントリビューションされたものは、高いメン テナンスコストを要する可能性がある。 受け手のチームは、コントリビューションを受け入れることで、自分たちのシステムの技術的負債が露 呈し、損害を被る恐れがある。 受け手のチームは、指導しても納得のいくコードが得られると思わないかもしれず、リスクを測定でき ないこともある。 InnerSource Patterns: 30 日の保証期間 @yuhattor 5

Slide 6

Slide 6 text

解決策 コントリビュートしたコードが本番稼動した時点から 30 日の保証 期間 を設けることで、受け入れた側とコントリビュートした側の双 方の不安に対処します。この保証期間中、コントリビュートしたチ ームは受け入れたチームにバグフィックスを提供することに同意し ます。 なお、保証期間は45 日、60 日、100 日のいずれでもかまいません。 この期間は、プロジェクトの制約、プロジェクトのソフトウェアラ イフサイクル、顧客との約束事項、その他の要因に基づいて変化さ れる可能性があります。 さらに、受け入れ側のチームとコントリビュートする側のチームの 期待値を明記した、明確なコントリビューションのガイドラインを 提供することも役に立ちます。 InnerSource Patterns: 30 日の保証期間 @yuhattor 6

Slide 7

Slide 7 text

結果の状況 受け入れ側のチームがコントリビューションを受け入れ、初期適応/ 修正の作業負担を分担することがで きます 透明性と公平性が高まります エスカレーションが重荷になりすぎないようになります InnerSource Patterns: 30 日の保証期間 @yuhattor 7

Slide 8

Slide 8 text

事例 これは PayPal で試みられ、成功したことが証明されています。 GitHub は社内でこのパターンを使っており、6 週間という修正された保証タイムラインを使っています。 Microsoft はこのパターンを原則として推奨しています。チームは自分たちのニーズと自信にマッチする よう具体的な時間目標を設定します。 InnerSource Patterns: 30 日の保証期間 @yuhattor 8

Slide 9

Slide 9 text

同種の例 複数の、功績至上主義的に任命されたトラステッドコミッターが責任を持つことで、依存するチームの 協力をコミュニティ化することで保証する。 InnerSource Patterns: 30 日の保証期間 @yuhattor 9

Slide 10

Slide 10 text

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: 30 日の保証期間 @yuhattor 10