InnerSource Patterns: 共通要件

概要
パターンの著者: Robert Hanmer
スピーカー/翻訳: Yuki Hattori | LinkedIn | Twitter | GitHub
YouTube: 共通要件
Doc: 共通要件

「InnerSource Patterns: 共通要件」
共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。
共有リポジトリにある共通コードは、それを使いたいすべてのプロジェクトのニーズを満たしていません。

この問題を解決するには、2つの側面があり、並行して行う必要があります。

* あるプロジェクトの要件を満たすコードが、他のプロジェクトのニーズも満たすように、プロジェクトの要件を調整する
* コードをリファクタリングして、多くの使用プロジェクトが要件に同意できるような小さな断片にする。

さらに、サプライヤーに要件の解明を助けてほしい顧客を活用します。 コンポーネントを変更するのではなく、顧客との交渉中に要件の調整を行い、顧客の要件に影響を与えます。
上記の例では、サプライヤーは両方の顧客が同じことを望んでいることを認識できるように支援し、同じ形式で結果を受け入れることに同意すれば、すべての人の労力(およびお金)を節約できます。

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

Transcript

1. 共通要件 InnerSource Patterns Speaker: Yuki Hattori (@yuhattor) Pattern Author: Robert Hanmer
2. 概要 共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしてい ません。これは、要件の調整とリファクタリングによって解決されます。 InnerSource Patterns: 共通要件 @yuhattor 2
3. 問題 共有リポジトリにある共通コードは、それを使いたいすべてのプロジェクトのニーズを満たしていません。 InnerSource Patterns: 共通要件 @yuhattor 3
4. 状況 すべてのプロジェクトがアクセスする共有リポジトリがあり、多くのプロジェクトが共通のコードを使 おうとしています。 誰かが( またはどこかのプロジェクトが) 最初にコードを書き、リポジトリにコントリビュートしまし た。 共通コードは、どのプロジェクトにおいても、成果物全体のうちのわずかな割合になります。 各プロジェクトには、それぞれ独自の納期、成果物があり、別の顧客がいます。 このパターンは、これらの状況のいずれにも当てはまります。 強いコードへのオーナーシップ: つまり、共有リポジトリへのすべての変更は、リポジトリの所有者によって承認されなけれ ばなりません。 弱いコードオーナーシップ: つまり、誰も本当にコードを所有していません。 慈善のスポンサーがいない: つまり、インナーソースの方法で共通コードを整理するためのリソースを提供する組織や幹部が いません。 InnerSource Patterns: 共通要件 @yuhattor 4
5. 組織に働く力学 プロジェクトには、様々なニーズがあり、顧客のニーズは似ているが同じではない 顧客によってニーズの表現や重みが異なる場合があり、それに伴いコードの再利用ができなくなる 多くの顧客はサプライヤーに必要なものを知るための手助けを望んでおり、同社のシステムエンジニア がその要件を作成している コードの再利用は、会社の時間とお金を節約するための重要な目標である InnerSource Patterns: 共通要件 @yuhattor 5
6. ソリューション この問題を解決するには、2 つの側面があり、並行して行う必要が あります。 あるプロジェクトの要件を満たすコードが、他のプロジェクト のニーズも満たすように、プロジェクトの要件を調整する コードをリファクタリングして、多くの使用プロジェクトが要 件に同意できるような小さな断片にする。 さらに、サプライヤーに要件の解明を助けてほしい顧客を活用しま す。 コンポーネントを変更するのではなく、顧客との交渉中に要件 の調整を行い、顧客の要件に影響を与えます。 上記の例では、サプライヤーは両方の顧客が同じことを望んでいる ことを認識できるように支援し、同じ形式で結果を受け入れること に同意すれば、すべての人の労力( およびお金) を節約できます。 InnerSource Patterns: 共通要件 @yuhattor 6
7. 結果の状況 これには、要件の変更について顧客と交渉する必要がある場合があります。そして、変更には要件を調整す るために営業チームと製品マネージャーの関与が必要になる場合もあります。また、顧客は変更の同意の代 わりに、割引などのインセンティブが必要になる場合があります。 これに関連する課題( 新しいパターンの可能性) として、インナーソースを採用しているとある企業で報告され ている「循環型ストーリーライティングの試行」があります。( 次のページ) InnerSource Patterns: 共通要件 @yuhattor 7
8. 結果の状況 - 循環型ストーリーライティングの試行 開発者は、ある方法で問題を解決するためにストーリーを書きます。 プログラムマネージャーはそのストーリーを自分たちのニーズをよりよく表現するために書き直しま す。しかし、開発者のもとに戻ってきたときには、開発者はそれが自分たちが最初にやりたかったこと だと認識しておらず、そのため実装に躊躇してしまいます。 このパターンの解決策は、開発者やプログラムマネージャーの陣営だけでなく、プロジェクト全体でス トーリーの修正が理解されるように、プランニングの際により多くの人を巻き込むことが挙げられま す。 InnerSource Patterns: 共通要件 @yuhattor 8
9. 事例 大手通信事業者 InnerSource Patterns: 共通要件 @yuhattor 9
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: 共通要件 @yuhattor 10