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
   

   View Slide

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

   View Slide

3. 問題
   インナーソースプロジェクトが健全であるためには、相当な数のコントリビューターが必要です。
   しかし、コントリビューターが増えると、互いに互換性のない機能をプロジェクトに追加したり、アー
   キテクチャを不健全に肥大化させる可能性があります。
   プロセスの後半で意見の相違を発見した場合、修正に高いコストがかかります。
   これは関係者のフラストレーションにつながり、プロジェクトのコラボレーション文化を損なう可能性
   があります。
   社内の複数のチームによって維持される場合、不一致の発生が頻繁になるかもしれません(
   共有オーナー
   シップ)
   InnerSource Patterns: RFC
   を用いたチーム横断的な意思決定の透明化
   @yuhattor
   3
   

   View Slide

4. ケーススタディ
   プロジェクトやアプリケーションは異なるチームによって維持され、各チームはそれぞれの異なる領域
   を所有し管理します。
   分野横断的な変更は、チームの技術リーダーが協力することによってのみ推進されるか、もしくはそも
   そも発生しないため、イノベーションやコラボレーションの機会が減少します。
   RFC
   のプロセスを導入することで、大規模で横断的な変更を提案する権限を与えられ、イノベーション
   やコラボレーションが促進されます。
   変更に必要な賛同やオープンなアイデア提案、議論をする環境が必要で、継続的に改善されなければな
   らない
   InnerSource Patterns: RFC
   を用いたチーム横断的な意思決定の透明化
   @yuhattor
   4
   

   View Slide

5. 状況
   インナーソースプロジェクトは多くのチームによって共有されています。
   アーキテクトグループは十分な時間がなく、またすべてのケースで適切な判断を下すのに十分なドメイ
   ン固有の知識もないため、包括的な設計上の決定を常に中央の組織(
   アーキテクトグループなど)
   から行う
   ことはできません。
   あるプロジェクトの方向性については、さまざまなタイプのユーザーが意見を述べます。そのようなユ
   ーザーには開発者、プロダクトオーナー、プロダクトマネージャーなどがいます。
   参加者全員と頻繁に同期ミーティングを開くことが不可能なため、少なくとも部分的には非同期で意思
   決定を行う必要があります。
   決定事項を文書化したい、つまり口頭だけでなく文書で確認したいと感じています。
   InnerSource Patterns: RFC
   を用いたチーム横断的な意思決定の透明化
   @yuhattor
   5
   

   View Slide

6. 組織に働く力学
   ほとんどの場合、関係者はかなり迅速に決定を下したいと思っています (
   例:
   事前の設計時間はかなり限
   られています)
   関係者の多くにとって、(
   すでに実装されていない)
   物事を書き留めることは新しいスキルであることが多
   いです。
   InnerSource Patterns: RFC
   を用いたチーム横断的な意思決定の透明化
   @yuhattor
   6
   

   View Slide

7. スケッチ
   InnerSource Patterns: RFC
   を用いた
   チーム横断的な意思決定の透明化
   @yuhattor
   7
   

   View Slide

8. ソリューション
   チーム横断的な意思決定プロセスの透明性を高めるために、RFC
   的なプロセスを採用します。(Requests for
   Comments
   もご参照ください)
   このソリューションの重要な要素は以下の通りです。
   RFC
   を発行する場合(
   および発行しない場合)
   の説明
   RFC
   ドキュメントのテンプレート
   RFC
   の作成者に、自分の提案を多角的に検討するよう促す必要があります。
   ハイレベルでアクセスしやすい概要と、詳細で深い説明の両方を促す必要があります。
   RFC
   を取り巻くよく知られた軽量なプロセス
   RFC
   を公開し、すべての関係者と共有する方法
   RFC
   に対するフィードバックをどのように収集するか、またどのようにフィードバックを取り込むか
   結論や決定に向けて RFC
   をどのように進めるか
   適切なツールの選択
   RFC
   のテンプレートとプロセスを繰り返し使用することを約束すること
   InnerSource Patterns: RFC
   を用いたチーム横断的な意思決定の透明化
   @yuhattor
   8
   

   View Slide

9. Examples/Templates
   Rust
   は RFC
   テンプレートとプロセスの優れたオープンソース例であり、他の多くの RFC
   プロセスの基礎
   となっています。
   一般化された BBC iPlayer & Sounds RFC
   テンプレート (
   元々はRust
   テンプレートに基づいています)
   InnerSource Patterns: RFC
   を用いたチーム横断的な意思決定の透明化
   @yuhattor
   9
   

   View Slide

10. 結果の状況
    RFC
    のようなプロセスを導入することで、チーム横断的な意思決定プロセスがより透明化され、すべての人
    の声を聞くことができるようになり、価値があることが証明されました。 以下は効果の一例です。
    多くのチームに影響を与える意思決定プロセスを民主化します(
    チームリーダーの負担を軽減)
    。
    複数のチームや地域にまたがって機能するオープンな非同期コミュニケーション手法になります。
    個人とチームが大規模な変化を起こせるようにします。
    決定事項を記録し、その内容を参照することができます。
    経験豊富なエンジニアが、ミーティングに出席する必要がなく、非同期かつリモートでソリューション
    に貢献できるため、その影響力を拡大することができます。
    例えば、"
    システムテストとは何か"
    などのテスト用語を定義しておくことで、用語の整合性を図ること
    ができます。
    プロセスの整合性を図ります。 例えば時間外サポートのプロセスを明示するなどが挙げられます。
    RFC
    を書くことで、著者が自分自身に挑戦することになり、思考がより明確になります。
    InnerSource Patterns: RFC
    を用いたチーム横断的な意思決定の透明化
    @yuhattor
    10
    

    View Slide

11. その他
    RFC
    は、長年にわたってオープンソースの世界でその効果が証明されてきました。これは、RFC
    が標準の開発
    に役立ってきたインターネット全体にも当てはまるほか(
    例: RFC
    の30
    年を参照)
    、コミュニティにおける透明
    な意思決定を促進するためにこの方法を適応させてきたその他のオープンソースプロジェクト(RUST, ZeroMQ)
    にも当てはまります。
    インナーソースの文脈では、Uber
    や Europace
    など、様々な企業が RFC
    のようなアプローチの経験を有して
    おり、共有しています。
    また、純粋なソフトウェア設計の決定以外にかかる意思決定においても、透明性のある意思決定モデルは、
    例えばオープンな組織に向けて取り組む際に効果的です。例として、Red Hat
    の Open Decision Framework
    (2016
    年6
    月7
    日に公開)
    をご覧ください。
    InnerSource Patterns: RFC
    を用いたチーム横断的な意思決定の透明化
    @yuhattor
    11
    

    View Slide

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
    

    View Slide

13. その他の呼び方
    デザインドキュメント
    アーキテクチャの決定記録(ADR: Architecture Decision Record) -
    意見を求め、合意を形成するための RFC
    です。決定と実装の詳細を記録するための ADR
    など、非常に異なる使い方をすることがあるため、必ず
    しも直接的な類例ではありません。
    InnerSource Patterns: RFC
    を用いたチーム横断的な意思決定の透明化
    @yuhattor
    13
    

    View Slide

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
    

    View Slide