Architecture Decision Record

Active theme: Light

← ドキュメント

ADR のためのチームワークのアドバイス

チームで決定記録の使用を検討しているなら、多くのチームと協力する中で私たちが学んだアドバイスを紹介します。

「何を」義務づけるのではなく、「なぜ」を一緒に話し合うことで、チームメイトを導く機会があります。たとえば、決定記録は、チームがより賢く考え、より良く伝え合うための方法です。事後に強制される書類作成の要件にすぎないなら、決定記録に価値はありません。

チームによっては、略語の「ADR」よりも「decisions(決定)」という名前をはるかに好みます。あるチームがディレクトリ名として「decisions」を使うと、電球が点灯したかのように、チームはベンダーの決定、計画の決定、スケジュールの決定など、そのディレクトリにより多くの情報を入れ始めます。これらすべての種類の情報に同じテンプレートを使用できます。私たちは、人々は略語(「ADR」)よりも言葉(「決定」)の方が速く学べること、「記録(record)」という単語を取り除くと作業中の文書を書く動機が高まること、そして一部の開発者や一部のマネージャーは「アーキテクチャ」という言葉を好まないことを仮説として立てています。

理論的には、不変性が理想的です。実際には、私たちのチームでは可変性の方がうまくいっています。既存の ADR に、日付スタンプと、その情報が決定後に届いたという注記を付けて、新しい情報を挿入します。この種のアプローチは、私たち全員が更新できる「生きた文書」につながります。典型的な更新は、新しいチームメイトのおかげで、あるいは新しい提供サービスのおかげで、あるいは私たちの利用の実世界での結果から、あるいはベンダーの機能、料金プラン、ライセンス契約などの事後のサードパーティによる変更の後に、情報を得たときです。