RFCを用いたチーム横断的な意思決定の透明化
Title
RFCを用いたチーム横断的な意思決定の透明化
Patlet
高い参加率を達成し、関係者全員にとって最良の意思決定を行いたいインナーソースプロジェクトは、ソフトウェアのライフサイクル全体を通して参加型のシステムを構築する方法を見つける必要があります。内部のRFC(Requests for Comments)ドキュメントを公開することで、設計プロセスの早い段階から議論を行うことができ、関係者全員が高いコミットメントを持ってソリューションを構築できる可能性が高まります。
問題
インナーソースプロジェクトが健全であるためには、相当な数のコントリビューターが必要です。しかし、コントリビューターが増えると、例えば互いに互換性のない機能をプロジェクトに追加したり、アーキテクチャを不健全に肥大化させたりする可能性があります。 このような意見の相違や誤解をプロセスの後半で発見した場合、特にソフトウェアがすでに構築された後では、修正に非常にコストがかかってしまいます。このような意見の相違は、関係者全員のフラストレーションにつながり、プロジェクトにおけるコラボレーション文化の健全性を損なう可能性さえあります。 このような不一致が表面化する時によくあるケースとして、変更リクエストの作成者とプロジェクトのメンテナーが、提案された変更を行うべきであるということに本質的に同意していないために、非常に長い間オープンになっている変更リクエスト(プルリクエスト) が存在するなどがあります。
インナーソースプロジェクトでは、社内の複数のチームによってプロジェクトが維持されている場合、このような状況がより頻繁に発生します(共有オーナーシップ)。
ケーススタディ
プロジェクト、または複数のプロジェクトで構成されるアプリケーションは、多くの異なるチームによって維持され、各チームはプロジェクトまたはアプリケーションの異なる領域を所有し管理します。これらのチームは、お互いの領域にインナーソースの貢献をしますが、より大きな分野横断的な変更は、チームの技術リーダーが協力することによってのみ推進されるか、もしくはそもそもまったく発生しません。その結果、ほとんどのエンジニアは大規模で分野横断的な変更を行うことができなくなり、イノベーションとコラボレーションの機会が減少します。
ここで RFC のプロセスとテンプレートを導入することで、チームや個人は、透明性のある意思決定プロセスを通じて、大規模で横断的な変更を提案する権限を与えられ、チーム間で非同期的に協議が行われます。その結果、イノベーションが促進され、コラボレーションが緊密になり、知識がより広まることになります。このためには、あらゆるレベルのあらゆる分野から賛同を得ること、そして人々がオープンにアイデアを提案し、議論できるような心理的安全性の高い環境を整えることが必要です。
どのようなプロセスでもそうですが、これは継続的に改善されなければなりません。RFC のテンプレートやプロセスを変更して、包括的、協調的、かつ効果的なものにする必要があるかもしれません。
状況
インナーソースプロジェクトは多くのチームによって共有されています。
アーキテクトグループは十分な時間がなく、またすべてのケースで適切な判断を下すのに十分なドメイン固有の知識もないため、包括的な設計上の決定を常に中央の組織(アーキテクトグループなど)から行うことはできません。
あるプロジェクトの方向性については、さまざまなタイプのユーザーが意見を述べます。そのようなユーザーには開発者、プロダクトオーナー、プロダクトマネージャーなどがいます。
参加者全員と頻繁に同期ミーティングを開くことが不可能なため、少なくとも部分的には非同期で意思決定を行う必要があります。
決定事項を文書化したい、つまり口頭だけでなく文書で確認したいと感じています。
組織に働く力学
ほとんどの場合、関係者はかなり迅速に決定を下したいと思っています (例: 事前の設計時間はかなり限られています)
関係者の多くにとって、(すでに実装されていない)物事を書き留めることは新しいスキルであることが多いです。
スケッチ
ソリューション
このソリューションの重要な要素は以下の通りです。
RFC を発行する場合(および発行しない場合)の説明
RFCドキュメントのテンプレート
RFC の作成者に、自分の提案を多角的に検討するよう促す必要があります。
ハイレベルでアクセスしやすい概要と、詳細で深い説明の両方を促す必要があります。
RFC を取り巻くよく知られた軽量なプロセス
RFC を公開し、すべての関係者と共有する方法 (例: Slack、メーリングリスト)
RFC に対するフィードバックをどのように収集するか
どのようにフィードバックを取り込むか
結論や決定に向けて RFC をどのように進めるか (例: 関連する指名されたメンテナーが承認すること)
適切なツールの選択 (例: 非エンジニアはソースコントロールツールにアクセスできないかもしれません)
RFC のテンプレートとプロセスを繰り返し使用することを約束すること
Examples/Templates
結果の状況
RFC のようなプロセスを導入することで、チーム横断的な意思決定プロセスがより透明化され、すべての人の声を聞くことができるようになり、価値があることが証明されました。
観察できるポジティブな効果
多くのチームに影響を与える意思決定プロセスを民主化します(チームリーダーの負担を軽減)。
複数のチームや地域にまたがって機能するオープンな非同期コミュニケーション手法になります。
個人とチームが大規模な変化を起こせるようにします。
決定事項を記録し、その内容を参照することができます。
経験豊富なエンジニアが、ミーティングに出席する必要がなく、非同期かつリモートでソリューションに貢献できるため、その影響力を拡大することができます。
例えば、"システムテストとは何か" などのテスト用語を定義しておくことで、用語の整合性を図ることができます。
プロセスの整合性を図ります。 例えば時間外サポートのプロセスを明示するなどが挙げられます。
RFC を書くことで、著者が自分自身に挑戦することになり、思考がより明確になります。
一方で RFC のアプローチにはリスクも存在しますので、以下に注意も喚起したいと思います。
この方法はいつもうまくいくとは限りません。例えば、RFCを通じてすでになされた決定に対して異議を唱える人がいるかもしれません。しかし、意思決定のプロセスを文書化しておくことは、このようなシナリオでも有益です。ある決定がいつ、なぜなされたかを人々に示すことができるからです。
RFC は大きくなりすぎて扱いにくくなる可能性があります。これはしばしば、長いコメントスレッドやそれをめぐる議論に表れます。そのような状況では、ワーキンググループや直接のミーティングなど、同期的なコミュニケーションで RFC を補完することを決定することもあります。しかし、ミーティング中にすべての情報を共有するのではなく、ミーティングの前に RFC を読むことができるので、時間はいずれにせよ節約されていることになります。
理論的解釈
事例
ステータス
Structured
著者
Tom Sadler
Sebastian Spier
その他の呼び方
アーキテクチャの決定記録(ADR: Architecture Decision Record) - 意見を求め、合意を形成するための RFCです。決定と実装の詳細を記録するための ADR など、非常に異なる使い方をすることがあるため、必ずしも直接的な類例ではありません。
翻訳の履歴
2023-06-18 - 最終更新
最終更新
役に立ちましたか？
