TEMPLATE.md

Architecture Decision Records:（タイトル）

「何」に対しての意思決定を行ったのかがわかるタイトルにする。

「マイクロサービスアーキテクチャ」といった概念であったり、「Kubernetes」といったプロダクト名であったり、「スクラムにおけるタイムボックスの長さ」といったプロジェクトにおける設定値であってもよい。

大事なことはあとから「このプロジェクトでこういう進め方をしているのはなぜだろうか」と見直したときに該当するADRがどれかわかることである。

複数の内容を含めると内容がブレるので簡潔なタイトルが決まらない場合は記述しようとしている単位を見直すと良いかもしれない。

Date - 日付

YYYY-MM-DD

意思決定を行った日付。 意思決定の開始日なのか、完了日なのかは統一されていればどちらでも良い。

日単位の正確さよりも「何年何月ごろに行われた意思決定なのか」ということが重要。

Context - 文脈

• 経緯：なぜこの意思決定が生まれたのか
  • 現状の課題
  • 期待している効果
  • など
• 観点：良し悪しを判断した観点
  • 採用した場合のメリット／デメリット
  • 開発スケジュールとの兼ね合い
  • 社内関連部署との関係性
  • 業界のトレンド
  • など
• 事情：採用状況を判断するために検討した事情
  • 経験者がいた
  • リモートワークによってコミュニケーションに変化がある
  • 経験の浅いメンバーが多い
  • メンバーの入れ替わりが激しい
  • など
• 参考情報：参考文献やWebサイトのURL

といった情報を記録する。もちろん網羅する必要はなく、各意思決定ごとに記録に残すべき内容は上記になくても記録するべきである。 記録内容は箇条書きで残すよりも文章として残したほうがよい。

建前を記録する必要はなく、意思決定に影響した雑多な事実を記述する。そうしなければ後から見返したときに「結局わからない」という状況になる。 たとえば「メンバーの学習が追いつかないため採用を見送った」といった対外的には格好がつかない理由であっても意思決定に影響しているのであれば記録するべき。

※組織文化的に対外的な体裁の整った記録を求められるようであれば、実施しても効果が出ないのでADRの記録をやめることを検討する。

Status - 採用状況

Accepted / Rejected / On holding

採用（Accepted）したのか、不採用（Rejected）だったのかを記録。

採用の場合は現在の開発に反映されているので詳細な情報はいらないが、不採用だった場合には不採用に至った理由を併記する。

決定を後回しにする場合は保留（On holding）として別の意思決定に移ると良い。

Decision - 決定事項

Acceptedになった場合の想定している運用や制約、再評価となる条件、想定している製品、採用時の温度感などを記述しておく。

「デプロイプロセスに初期から組み込む」「当初見積もり規模から2倍に膨れ上がった場合は再評価を行う」「テストランナーは○○の利用を想定」「試しに採用する」など。

Consequences - 結果

意思決定の結果を評価したタイミングで追記する。

• 期待した効果が得られたか得られなかったか
• 今後の採用に向けての注意点
• など