ITアーキテクトとしての役割は多くあります。果たすべき責任も負います。

その中でも重要な責任として「説明責任(Accountability)」があります。

ここでいう説明責任というのは、アーキテクチャを設計する上での「決定」から生じた結果に対して、その理由を明確にして説明する事です。

なのですが、この設計方針や設計を決定した理由が不明確なままになっているドキュメントが非常に多い。わたしが見せていただく設計書には「決定事項」と「パラメータ」しか記述がありません。設計方針の記載もなければ、なぜその決定をしたのかという説明が一切ないのです。

また、その設計を行ったメンバーも残っておらず「どうしてこの構成になったのですか」について無言になってしまうのです。

このような事にならないよう、事後、将来に「どうしてこのような設計となったか」を明確に説明するための情報を残しておかなければなりません。

それが「Architectural Decisions(アーキテクチャ上の決定)」です。これを表現するものとして、有名なのは「joelparkerhenderson/architecture-decision-record: Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation」でしょうか。Github でその手法やテンプレートのサンプルが公開されています。AWS (Using architectural decision records to streamline technical decision-making for a software development project - AWS Prescriptive Guidance) や Google (アーキテクチャ決定レコードの概要  |  Cloud アーキテクチャ センター  |  Google Cloud) でも ADR について説明されています。

何を使うにせよ、このような記録を準備しておく事は重要だと理解いただければ幸いです。

過去、私が携わった ADR としてのサンプルを載せておきます。