Architecture Decision Record
← 決定記録テンプレート

{ここにタイトルを入力}

!!! info

**ステータス**: { Proposed | Under Review | Accepted |  Rejected | Superseded | Deprecated }

**更新日**: {YYYY-MM-DD}

概要

{これは ADR の「エグゼクティブサマリー」または「エレベーターピッチ」です。簡潔な 数文(通常は 2〜4 文)で、この ADR が扱う中核的な問題、疑問、または機会を明確に 述べます。行われた決定、または焦点となる領域についても簡単に示唆します。目的は、 読者が文書全体を読まなくても、この ADR が何についてのものかを素早く理解し、 自分に関連があるかどうかを判断できるようにすることです。技術論文の要旨、または 主要トピックのごく短い導入のようなものと考えてください。}

推進要因

{このセクションでは、なぜこの決定を今行うのかを説明します。このアーキテクチャ 上の決定を必要とする主な動機、ニーズ、または問題を明確に述べます。根底にある 理由と圧力について考えてください。}

  • {例: 私たちは、...を必要とする新機能/新能力を開発している}

  • {例: パフォーマンス、アクセシビリティを改善し、負債を解消する必要がある...}

  • {例: ユーザーからのフィードバックによると...}

  • {例: 現在のアプローチには次の制限がある...}

選択肢

{ここでは、検討している異なる選択肢を列挙します。事実に徹し、意見は避けてください。 分析は次のセクションで扱います。簡潔な説明と、関連する文書や例へのリンクを含めます。

最終的に選ばれなかったとしても、検討したすべての重要な代替案を含めてください。 目的は、評価に入る前に、読者に各代替案について明確で偏りのない理解を与える ことです。}

{選択肢 1 のタイトル}

{選択肢を説明し、概要を示し、事実を列挙し、リンクを提供します。}

{選択肢 n のタイトル}

...

選択肢の分析

{ここでは、選択肢セクションで提示した各選択肢を批判的に評価します。各選択肢に ついて、その利点、欠点、その他の関連する考慮事項やトレードオフについて、バランスの 取れた見方を提供します。具体的に述べ、可能な場合は推進要因に結び付けてください。

次のような側面を検討してください:

  • コスト(開発、運用、ライセンス)

  • 複雑さ(実装、保守、学習曲線)

  • リスク(技術、運用、セキュリティ)

  • アーキテクチャ原則または既存標準との整合性

  • パフォーマンス、スケーラビリティ、ユーザビリティ、保守性、 セキュリティなどへの影響

必要なだけ、長所/短所/その他の記述を含めてください。 }

{選択肢 1 の評価}

  • 長所: {この選択肢の具体的な利点または便益。}

  • 短所: {この選択肢に関連する具体的な欠点、リスク、またはコスト。}

  • その他: {厳密には長所でも短所でもない関連する点。}

{選択肢 n の評価}

...

推奨事項

{ここでは、最終的な決定を明確に述べ、選択された選択肢を明示的に名前で挙げます。 なぜこの選択肢が選ばれたのかを詳細に説明します。選択された選択肢が推進要因に どのように最もよく対処し、主要な要件を満たす、または述べられた問題を解決するのかを 明確に述べる必要があります。}

結果

{このセクションは任意です。}

{決定が行われた今、肯定的および否定的の両方で、期待される成果と影響は何ですか? この決定を行うことで、どのような既知の制限、コスト、またはリスクが受け入れられて いますか? この決定は、異なるステークホルダー、他のシステム、開発プラクティス、 運用手順、またはユーザーエクスペリエンスにどのような影響を与えますか?}

  • 長所: {この決定から期待される具体的な肯定的成果または便益。}

  • 短所: {この決定の結果として受け入れられる具体的な欠点、コスト、またはリスク。 }

  • その他: {厳密には長所でも短所でもない結果。}

確認

{このセクションは任意です。}

{この決定の実装がどのように検証され、継続的な準拠がどのように確保されるかを概説 します。これにより、決定が単なる理論ではなく、積極的に実践され監視されることを 示すのに役立ちます。

決定が正しく実装されたことをどのように確認しますか?(例: コードレビュー、特定の テスト、デモンストレーション、ピアレビュー)

この決定への準拠は、時間の経過とともにどのように維持されますか?(例: 自動チェック、 定期監査、チームガイドラインの更新、トレーニング)

決定が意図した肯定的な成果を達成していることを示す特定のメトリクスや指標はありますか? (例: パフォーマンスベンチマーク、採用率、特定のエラーの減少、ユーザーフィードバックスコア)

誰がこれを監督する責任を負い、決定が守られなかった場合はどうなりますか?}

詳細情報

{このセクションは任意です。}

{このセクションは、決定を裏付ける、コンテキストを追加する、または将来の行動の指針となる 補足情報を提供するために使用します。他の決定やリソースへのリンクもここに表示される 場合があります。

意思決定プロセスに誰が関与したか、そして合意がどのように(あるいは達成されたかどうか) 形成されたかを簡単に記すこともできます。また、将来この決定の再評価を促す可能性の ある期間や特定のイベントを提案することもできます。}