技術選定と意思決定

技術の判断は、半年後には「なぜこれを選んだのか」誰も覚えていないことがよくあります。そこで、選択肢・判断基準・トレードオフ（何かを得る代わりに何かをあきらめること）をADR（Architecture Decision Record：意思決定の記録）に短く残します。リポジトリの docs/adr/ に Markdown で置くのが一般的です。

# ADR-0012: ジョブのキューに○○を採用する
状態: 承認（2026-10-01）  ※提案中／承認／廃止（ADR-00xx で置き換え）

## 背景
何が問題で、なぜ今決める必要があるか。制約（期限・予算・人数）。

## 選択肢
1. A … 長所 / 短所
2. B … 長所 / 短所
3. 何もしない … 長所 / 短所

## 決定
B を採用する。決め手は○○。

## 結果（トレードオフ）
得るもの・あきらめるもの・新たに必要になる作業。
見直す条件（例：1日のジョブ数が 100万件を超えたら再検討）。

書き方のこつは、1ページに収めること、「何もしない」も選択肢に入れること、見直す条件を書くことです。決定が変わったら古い ADR は書き換えず、新しい ADR を作って「置き換え」と記録します。経緯が残るからです。

技術選定の判断基準

技術選定では、要件を先に書き、候補を2〜3つに絞って、同じ基準で比べます。性能や機能だけでなく、チームが扱えるか・運用を誰が持つか・やめるときの手間まで見ます。

よくある失敗は、結論を先に決めてから比較表を作ることと、「流行っているから」で選ぶことです。候補ごとに小さく試し（PoC：概念実証）、数字で確かめた結果を ADR に残します。

決定には、やり直しやすいものとやり直しにくいものがあります。Amazon の経営者の手紙で「一方通行のドア」「双方向のドア」と表現されたことで知られる考え方です。やり直しやすい決定まで会議で決めると、チームの速さが落ちます。

決め方も、決定の重さで選びます。

意見が割れたときは「決めないこと」が一番のコストになることが多いです。期限と決める人を先に宣言しておきます。

設計レビューは、作り始める前に設計の穴を見つける場です。機能が動くかだけでなく、非機能要件（性能・可用性・セキュリティ・運用のしやすさなど、「何をするか」以外の品質の要件）まで問いを投げます。設計書（デザインドキュメント）はレビューの2〜3日前に共有し、当日は質問と判断に時間を使います。

EM の役割は、全部に自分で答えることではなく、抜けている観点を問い、結論を出す期限と決める人をはっきりさせることです。批判するのは設計であって人ではない、という前提をそろえ、新しいメンバーにも発言の機会をつくります。決まったことは ADR に残します。

設計書（デザインドキュメント）の書き方

設計書（デザインドキュメント）は、作る前に「何を・なぜ・どう作るか」を書いて、関係者に読んでもらうための文書です。長さより、判断に必要なことが書いてあるかが大事です。目安は数ページで、図を1〜2枚入れます。

「未解決の論点」を最後に書いておくと、レビュー会で何を決めればよいかがはっきりします。決まったことのうち、後から理由を知りたくなりそうなものは ADR にも残します。

設計レビューの観点