ベストプラクティス

所有権を昇格させる。プロジェクトチームの各メンバーには、ADR を作成して所有する権限を与えられる必要があります。このプラクティスにより、アーキテクチャの研究作業がチームメンバー間で分散され、ソリューションアーキテクトやチームリーダーからの作業がオフロードされます。また、意思決定プロセスにおける当事者意識も育まれます。これにより、チームはそれらの決定を組織の上位レベルから押し付けられた決定として扱うのではなく、より迅速に受け入れられるようになります。

ADR 履歴を保存する。ADR には変更履歴が必要であり、各変更には所有者が設定されている必要があります。ADR 所有者が ADR を更新したら、古い ADR のステータスを置き換え済みに変更する必要があります。変更内容を新しい ADR の変更履歴に記録し、古い ADR は決定ログに残しておきます。

定期的なレビュー会議を予定する。新しい (未開発の) プロジェクトに取り組んでいる場合、ADR プロセスは最初はかなり厳しいものになる可能性があります。毎日の簡単なミーティングの前後に、ADR に関するディスカッションとレビューミーティングを定期的に行うことをお勧めします。このアプローチでは、定義した ADR は 2～3 回のスプリントで安定し、少ないミーティングで強固な基盤を構築できます。

ADR を一元的な場所に集約する。各プロジェクトメンバーは ADR のコレクションにアクセスできる必要があります。ADR は 1 か所に保存し、プロジェクトドキュメントのメインページで参照することをお勧めします。ADR の保存には次の 2 つの方法がよく使用されます。

• ADR のバージョン管理が容易になる Git リポジトリ

• チームメンバー全員が ADR にアクセスできるようになる Wiki ページ

非準拠コードに対処する。ADR プロセスでは、準拠していないレガシーコードの問題は解決されません。確立された ADR をサポートしていないレガシーコードがある場合は、新しい変更を加えながら古いコードベースやアーティファクトを徐々に更新することも、チームが技術的負債タスクを作成してコードを明示的にリファクタリングすることもできます。