InnerSource Pattern: 30日の保証期間

概要
パターンの著者: Cedric Williams
スピーカー/翻訳: Yuki Hattori | LinkedIn | Twitter | GitHub
YouTube: 30日の保証期間
Doc: 30日の保証期間

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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

10. 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
    

    View Slide