InnerSource Pattern: RFCを用いたチーム横断的な意思決定の透明化

概要
パターンの著者: Tom Sadler / Sebastian Spier
スピーカー/翻訳: Yuki Hattori | LinkedIn | Twitter | GitHub
YouTube: RFCを用いたチーム横断的な意思決定の透明化
Doc: RFCを用いたチーム横断的な意思決定の透明化

「InnerSource Pattern: RFCを用いたチーム横断的な意思決定の透明化」

* インナーソースプロジェクトで最良の意思決定を行い、参加率を高めるには、ソフトウェアライフサイクル全体で参加型のシステムを構築する方法を見つける必要があります。
* 内部のRFCドキュメントを公開することで、設計プロセスの早い段階から議論を行い、関係者全員が高いコミットメントでソリューションを構築できる可能性が高まります。

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

Transcript

1. RFC を用いたチーム横断的な意思決定の透明化 InnerSource Patterns Speaker: Yuki Hattori (@yuhattor) Pattern Authors: Tom Sadler Sebastian Spier
2. 概要 インナーソースプロジェクトで最良の意思決定を行い、参加率を高めるには、ソフトウェアライフサイ クル全体で参加型のシステムを構築する方法を見つける必要があります。 内部のRFC ドキュメントを公開することで、設計プロセスの早い段階から議論を行い、関係者全員が高 いコミットメントでソリューションを構築できる可能性が高まります。 InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 2
3. 問題 インナーソースプロジェクトが健全であるためには、相当な数のコントリビューターが必要です。 しかし、コントリビューターが増えると、互いに互換性のない機能をプロジェクトに追加したり、アー キテクチャを不健全に肥大化させる可能性があります。 プロセスの後半で意見の相違を発見した場合、修正に高いコストがかかります。 これは関係者のフラストレーションにつながり、プロジェクトのコラボレーション文化を損なう可能性 があります。 社内の複数のチームによって維持される場合、不一致の発生が頻繁になるかもしれません( 共有オーナー シップ) InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 3
4. ケーススタディ プロジェクトやアプリケーションは異なるチームによって維持され、各チームはそれぞれの異なる領域 を所有し管理します。 分野横断的な変更は、チームの技術リーダーが協力することによってのみ推進されるか、もしくはそも そも発生しないため、イノベーションやコラボレーションの機会が減少します。 RFC のプロセスを導入することで、大規模で横断的な変更を提案する権限を与えられ、イノベーション やコラボレーションが促進されます。 変更に必要な賛同やオープンなアイデア提案、議論をする環境が必要で、継続的に改善されなければな らない InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 4
5. 状況 インナーソースプロジェクトは多くのチームによって共有されています。 アーキテクトグループは十分な時間がなく、またすべてのケースで適切な判断を下すのに十分なドメイ ン固有の知識もないため、包括的な設計上の決定を常に中央の組織( アーキテクトグループなど) から行う ことはできません。 あるプロジェクトの方向性については、さまざまなタイプのユーザーが意見を述べます。そのようなユ ーザーには開発者、プロダクトオーナー、プロダクトマネージャーなどがいます。 参加者全員と頻繁に同期ミーティングを開くことが不可能なため、少なくとも部分的には非同期で意思 決定を行う必要があります。 決定事項を文書化したい、つまり口頭だけでなく文書で確認したいと感じています。 InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 5
6. 組織に働く力学 ほとんどの場合、関係者はかなり迅速に決定を下したいと思っています ( 例: 事前の設計時間はかなり限 られています) 関係者の多くにとって、( すでに実装されていない) 物事を書き留めることは新しいスキルであることが多 いです。 InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 6
7. スケッチ InnerSource Patterns: RFC を用いた チーム横断的な意思決定の透明化 @yuhattor 7
8. ソリューション チーム横断的な意思決定プロセスの透明性を高めるために、RFC 的なプロセスを採用します。(Requests for Comments もご参照ください) このソリューションの重要な要素は以下の通りです。 RFC を発行する場合( および発行しない場合) の説明 RFC ドキュメントのテンプレート RFC の作成者に、自分の提案を多角的に検討するよう促す必要があります。 ハイレベルでアクセスしやすい概要と、詳細で深い説明の両方を促す必要があります。 RFC を取り巻くよく知られた軽量なプロセス RFC を公開し、すべての関係者と共有する方法 RFC に対するフィードバックをどのように収集するか、またどのようにフィードバックを取り込むか 結論や決定に向けて RFC をどのように進めるか 適切なツールの選択 RFC のテンプレートとプロセスを繰り返し使用することを約束すること InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 8
9. Examples/Templates Rust は RFC テンプレートとプロセスの優れたオープンソース例であり、他の多くの RFC プロセスの基礎 となっています。 一般化された BBC iPlayer & Sounds RFC テンプレート ( 元々はRust テンプレートに基づいています) InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 9
10. 結果の状況 RFC のようなプロセスを導入することで、チーム横断的な意思決定プロセスがより透明化され、すべての人 の声を聞くことができるようになり、価値があることが証明されました。 以下は効果の一例です。 多くのチームに影響を与える意思決定プロセスを民主化します( チームリーダーの負担を軽減) 。 複数のチームや地域にまたがって機能するオープンな非同期コミュニケーション手法になります。 個人とチームが大規模な変化を起こせるようにします。 決定事項を記録し、その内容を参照することができます。 経験豊富なエンジニアが、ミーティングに出席する必要がなく、非同期かつリモートでソリューション に貢献できるため、その影響力を拡大することができます。 例えば、" システムテストとは何か" などのテスト用語を定義しておくことで、用語の整合性を図ること ができます。 プロセスの整合性を図ります。 例えば時間外サポートのプロセスを明示するなどが挙げられます。 RFC を書くことで、著者が自分自身に挑戦することになり、思考がより明確になります。 InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 10
11. その他 RFC は、長年にわたってオープンソースの世界でその効果が証明されてきました。これは、RFC が標準の開発 に役立ってきたインターネット全体にも当てはまるほか( 例: RFC の30 年を参照) 、コミュニティにおける透明 な意思決定を促進するためにこの方法を適応させてきたその他のオープンソースプロジェクト(RUST, ZeroMQ) にも当てはまります。 インナーソースの文脈では、Uber や Europace など、様々な企業が RFC のようなアプローチの経験を有して おり、共有しています。 また、純粋なソフトウェア設計の決定以外にかかる意思決定においても、透明性のある意思決定モデルは、 例えばオープンな組織に向けて取り組む際に効果的です。例として、Red Hat の Open Decision Framework (2016 年6 月7 日に公開) をご覧ください。 InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 11
12. 事例 BBC iPlayer & Sounds - ISC Fall Summit 2020 のプレゼンテーションをご参照ください - Using Internal RFCs to Enhance Collaboration Europace - Open Organization の項目で述べられています - Setting cross-team standards and best practices in the open. Uber - Gergely Orosz さんの記事をご覧ください Scaling Engineering Teams via RFCs: Writing Things Down. Google Design Docs - Malte Ubl さんの記事をご覧ください Design Docs at Google InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 12
13. その他の呼び方 デザインドキュメント アーキテクチャの決定記録(ADR: Architecture Decision Record) - 意見を求め、合意を形成するための RFC です。決定と実装の詳細を記録するための ADR など、非常に異なる使い方をすることがあるため、必ず しも直接的な類例ではありません。 InnerSource Patterns: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 13
14. 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: RFC を用いたチーム横断的な意思決定の透明化 @yuhattor 14