🇯🇵 日本語

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

Title

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

Patlet

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

問題

インナーソースプロジェクトが健全であるためには、相当な数のコントリビューターが必要です。しかし、コントリビューターが増えると、例えば互いに互換性のない機能をプロジェクトに追加したり、アーキテクチャを不健全に肥大化させたりする可能性があります。 このような意見の相違や誤解をプロセスの後半で発見した場合、特にソフトウェアがすでに構築された後では、修正に非常にコストがかかってしまいます。このような意見の相違は、関係者全員のフラストレーションにつながり、プロジェクトにおけるコラボレーション文化の健全性を損なう可能性さえあります。 このような不一致が表面化する時によくあるケースとして、変更リクエストの作成者とプロジェクトのメンテナーが、提案された変更を行うべきであるということに本質的に同意していないために、非常に長い間オープンになっている変更リクエスト(プルリクエスト) が存在するなどがあります。

インナーソースプロジェクトでは、社内の複数のチームによってプロジェクトが維持されている場合、このような状況がより頻繁に発生します(共有オーナーシップ)。

ケーススタディ

プロジェクト、または複数のプロジェクトで構成されるアプリケーションは、多くの異なるチームによって維持され、各チームはプロジェクトまたはアプリケーションの異なる領域を所有し管理します。これらのチームは、お互いの領域にインナーソースの貢献をしますが、より大きな分野横断的な変更は、チームの技術リーダーが協力することによってのみ推進されるか、もしくはそもそもまったく発生しません。その結果、ほとんどのエンジニアは大規模で分野横断的な変更を行うことができなくなり、イノベーションとコラボレーションの機会が減少します。

ここで RFC のプロセスとテンプレートを導入することで、チームや個人は、透明性のある意思決定プロセスを通じて、大規模で横断的な変更を提案する権限を与えられ、チーム間で非同期的に協議が行われます。その結果、イノベーションが促進され、コラボレーションが緊密になり、知識がより広まることになります。このためには、あらゆるレベルのあらゆる分野から賛同を得ること、そして人々がオープンにアイデアを提案し、議論できるような心理的安全性の高い環境を整えることが必要です。

どのようなプロセスでもそうですが、これは継続的に改善されなければなりません。RFC のテンプレートやプロセスを変更して、包括的、協調的、かつ効果的なものにする必要があるかもしれません。

状況

  • インナーソースプロジェクトは多くのチームによって共有されています。

  • アーキテクトグループは十分な時間がなく、またすべてのケースで適切な判断を下すのに十分なドメイン固有の知識もないため、包括的な設計上の決定を常に中央の組織(アーキテクトグループなど)から行うことはできません。

  • あるプロジェクトの方向性については、さまざまなタイプのユーザーが意見を述べます。そのようなユーザーには開発者、プロダクトオーナー、プロダクトマネージャーなどがいます。

  • 参加者全員と頻繁に同期ミーティングを開くことが不可能なため、少なくとも部分的には非同期で意思決定を行う必要があります。

  • 決定事項を文書化したい、つまり口頭だけでなく文書で確認したいと感じています。

組織に働く力学

  • ほとんどの場合、関係者はかなり迅速に決定を下したいと思っています (例: 事前の設計時間はかなり限られています)

  • 関係者の多くにとって、(すでに実装されていない)物事を書き留めることは新しいスキルであることが多いです。

スケッチ

ソリューション

チーム横断的な意思決定プロセスの透明性を高めるために、RFC的なプロセスを採用します。(Requests for Commentsもご参照ください)

このソリューションの重要な要素は以下の通りです。

  • RFC を発行する場合(および発行しない場合)の説明

  • RFCドキュメントのテンプレート

    • RFC の作成者に、自分の提案を多角的に検討するよう促す必要があります。

    • ハイレベルでアクセスしやすい概要と、詳細で深い説明の両方を促す必要があります。

  • RFC を取り巻くよく知られた軽量なプロセス

    • RFC を公開し、すべての関係者と共有する方法 (例: Slack、メーリングリスト)

    • RFC に対するフィードバックをどのように収集するか

    • どのようにフィードバックを取り込むか

    • 結論や決定に向けて RFC をどのように進めるか (例: 関連する指名されたメンテナーが承認すること)

    • 適切なツールの選択 (例: 非エンジニアはソースコントロールツールにアクセスできないかもしれません)

  • RFC のテンプレートとプロセスを繰り返し使用することを約束すること

Examples/Templates

結果の状況

RFC のようなプロセスを導入することで、チーム横断的な意思決定プロセスがより透明化され、すべての人の声を聞くことができるようになり、価値があることが証明されました。

観察できるポジティブな効果

  • 多くのチームに影響を与える意思決定プロセスを民主化します(チームリーダーの負担を軽減)。

  • 複数のチームや地域にまたがって機能するオープンな非同期コミュニケーション手法になります。

  • 個人とチームが大規模な変化を起こせるようにします。

  • 決定事項を記録し、その内容を参照することができます。

  • 経験豊富なエンジニアが、ミーティングに出席する必要がなく、非同期かつリモートでソリューションに貢献できるため、その影響力を拡大することができます。

  • 例えば、"システムテストとは何か" などのテスト用語を定義しておくことで、用語の整合性を図ることができます。

  • プロセスの整合性を図ります。 例えば時間外サポートのプロセスを明示するなどが挙げられます。

  • RFC を書くことで、著者が自分自身に挑戦することになり、思考がより明確になります。

一方で RFC のアプローチにはリスクも存在しますので、以下に注意も喚起したいと思います。

  • この方法はいつもうまくいくとは限りません。例えば、RFCを通じてすでになされた決定に対して異議を唱える人がいるかもしれません。しかし、意思決定のプロセスを文書化しておくことは、このようなシナリオでも有益です。ある決定がいつ、なぜなされたかを人々に示すことができるからです。

  • 設計案 (アーキテクチャ、プロトコルなど) を前もって書き上げることは、ウォーターフォールのような設計の要素があり、多くの開発チームが好む反復的なアジャイルの開発アプローチには適さない場合があります。アジャイルマニュフェストに存在する「括的なドキュメントよりも、動くソフトウェアを」という項目は覚えておいてください。RFC プロセスは可能な限り軽量であるべきです。

  • RFC は大きくなりすぎて扱いにくくなる可能性があります。これはしばしば、長いコメントスレッドやそれをめぐる議論に表れます。そのような状況では、ワーキンググループや直接のミーティングなど、同期的なコミュニケーションで RFC を補完することを決定することもあります。しかし、ミーティング中にすべての情報を共有するのではなく、ミーティングの前に RFC を読むことができるので、時間はいずれにせよ節約されていることになります。

理論的解釈

RFCは、長年にわたってオープンソースの世界でその効果が証明されてきました。これは、RFCが標準の開発に役立ってきたインターネット全体にも当てはまるほか(例: RFCの30年を参照)、コミュニティにおける透明な意思決定を促進するためにこの方法を適応させてきたその他のオープンソースプロジェクト(RUST, ZeroMQ)にも当てはまります。

インナーソースの文脈では、Uber や Europace など、様々な企業が RFC のようなアプローチの経験を有しており、共有しています。

また、純粋なソフトウェア設計の決定以外にかかる意思決定においても、透明性のある意思決定モデルは、例えばオープンな組織に向けて取り組む際に効果的です。例として、Red Hatの Open Decision Framework (2016年6月7日に公開)をご覧ください。

事例

ステータス

Structured

著者

  • Tom Sadler

  • Sebastian Spier

その他の呼び方

  • デザインとキュメント

  • アーキテクチャの決定記録(ADR: Architecture Decision Record) - 意見を求め、合意を形成するための RFCです。決定と実装の詳細を記録するための ADR など、非常に異なる使い方をすることがあるため、必ずしも直接的な類例ではありません。

翻訳の履歴

前へ30日の保証期間次へイシュートラッカーの使い方を多様化する

最終更新