最終更新: 2026/06/22 18:56
commonid: rq-096-design-principles-documentationtype: researchstatus: active

RQ-096 Synthesis: 設計原則の記載ベストプラクティス

調査方法: deep-research スキル（Claude 単体の Web 調査ハーネス）。5 アングル並列検索 → 出典付き主張を突合。3 ベンダー（OpenAI/Gemini/Claude）突合ではない点に留意。 スコープ: 設計原則を「どう書くか」。どの原則を採用すべきかは対象外。 注意: 多くの一次ソース（opengroup.org / aws / gov.uk 等）が fetch 時 403 のため、引用は検索抽出ベース。テンプレート・5 基準・Y-statement 等は複数ソースで一致し確度高。逐語引用は原典で要確認。

エグゼクティブサマリー（5 つの要点）

  1. 正準テンプレートは TOGAF の4フィールド: Name / Statement / Rationale / Implications。Statement=不変の規則本体（通常1文）、Rationale=ビジネス価値の「なぜ」、Implications=順守のためのタスク・コスト・影響。(TOGAF ch.20)
  2. 良い原則かの判定は2つのテストが決定的: ①測定可能か（Yes→要件/標準、No→原則）②逆もまた成り立つか（reversibility）（反対の原則も別組織で妥当なら本物。「使いやすくする」は反対が無意味＝陳腐）。(Michalsons / Clearleft)
  3. 原則はトレードオフを言い切る。「X over Y（Y にも価値はあるが X を優先）」が最良の型。アジャイル宣言・Spotify・ThoughtWorks が採用。論争にならない原則は指針にならない。(Agile Manifesto / Hohpe)
  4. 個数は10未満、理想は数個。認知容量（5〜7）の制約。Dieter Rams 10 が実質上限。Spotify は6→3へ削減した実例あり。(Ashridge / Spotify)
  5. 小規模チームは TOGAF の重い様式を避け、軽量2系統を使う: ①命令形タイトル＋一文の理由（GOV.UK / GitLab）②「X over Y」トレードオフ対（Spotify / Pragmatic）。arc42 も固定様式を課さない。(GOV.UK / arc42 §8)

設問別分析

Q1. 原則エントリの構成要素

  • TOGAF 4フィールド（正準・最小）: Name（技術名を入れず本質を表す覚えやすい名）/ Statement（不変の規則・通常1文）/ Rationale（ビジネス価値の「なぜ」・対立解消の指針）/ Implications（タスク・コスト・帰結）。Rationale と Implications は必須で、決定を正当化するために存在する。(TOGAF ch.20)
  • 拡張ガバナンス属性（任意）: ID / status / owner / priority / source / date。これらは TOGAF の最小4には含まれない。(itarch.info)
  • arc42 は固定様式を課さない。原則は §8 Crosscutting Concepts に自由形式で置き、「全項目を埋めようとするな」。(arc42 §8)
  • AWS WAF: 命令形の短いタイトル＋説明段落（例「Perform operations as code」「Make frequent, small, reversible changes」）。各原則を**ベストプラクティス（検証可能な手順）**と対にして操作可能にする。(AWS WAF)
  • 「例 / 反例（do-don't）」は TOGAF・arc42 のいずれでも正式フィールドではない（コミュニティの非公式助言にとどまる）。

Q2. 原則 vs 要件 vs ルール/標準 vs ADR の区別

  • 原則 = 決定を導く宣言文。決定そのものではない。耐久的な「長期の一般規則」。(workingsoftware / TOGAF)
  • 階層: 価値観 → 原則（広い方針）→ ポリシー（高位の必須意図）→ 標準（必須・具体・測定可能な MUST/SHOULD）→ 手順/ガイドライン。位置が分類器。(cloudadvisor)
  • 標準は測定可能。「ポリシー順守のための必須・具体要件＝理想を測定可能な基準に変える」。→ 測定可能なら標準/要件、価値判断なら原則。(Michalsons)
  • ADR は決定の記録。「AD＝アーキ的に重要な要件に対する正当化された設計選択」。要件＝入力、ADR＝出力（選択＋理由）。原則は決定を導くが決定ではない。(adr.github.io)
  • Y-statement（決定の型）: 「In the context of … facing … we decided for … and neglected … to achieve … accepting that …」。却下案と受容コストを明示すれば ADR、しなければ原則。(Zimmermann)
  • トレードオフ・テスト（Hohpe）: 複数の妥当な選択肢の中から選んだなら ADR。唯一の選択肢なら要件/制約。(Hohpe)

Q3. 実行可能で陳腐でない wording

  • reversibility テスト: 反対の原則も別文脈で妥当か？妥当でないなら陳腐。(Clearleft)
  • 立場を取る: 普遍的真理は決定を助けない。原則は意見的であるべき。(Modus/Eismann)
  • トレードオフ phrasing: 「prefer X over Y（コストを明記）」。原則はコストを理解すれば破ってよいもの。設計レビューの共通言語になる（「原則 X に反するが Y を買う、許容可能か？」）。(ThoughtWorks EA Playbook)
  • 個数: 10 未満、理想は2〜3でも可。(Ashridge)
  • 決定からの参照: ADR は適用される原則を明示し、原則と矛盾する場合はそれを記録（＝原則は破れるものとして扱う）。原則の採用自体も軽量 ADR で記録できる。(Fowler scaling)

Q4. フレームワーク比較

FW原則の様式特徴
TOGAFName/Statement/Rationale/Implications + 5基準最も規範的・重い。enterprise 向け
ISO/IEC/IEEE 42010様式は規定せず理由（却下案含む）と stakeholder concern への追跡を必須化
AWS WAF命令形タイトル＋説明（pillar 毎 ~5個）超圧縮・各原則にベストプラクティス対
arc42固定様式なし（§8 concept）原則=§8 / 制約=§2 / 品質=§10(Q42 9次元) と置き場を分離
GOV.UK / Spotify / ThoughtWorks命令形＋一段落 / 「X>Y」軽量・小規模向けの実例

TOGAF の良い原則5基準: Understandable（即理解・違反が判別可能）/ Robust（一貫した意思決定を支える精度）/ Complete / Consistent（矛盾しない）/ Stable（耐久的だが改訂手続きを持つ）。(TOGAF 8.1.1 ch.29)

成果物1: 推奨「設計原則エントリ」テンプレート（小規模チーム向け）

TOGAF を軽量化し、トレードオフ phrasing を取り込んだ型:

### <原則名>（覚えやすい短い名）
**Statement**: <1文の規則。可能なら「X over Y」で立場を言い切る>
**なぜ**: <ビジネス/設計上の価値・理由を1〜2文>
**含意**: <この原則を守ると何をすることになるか・コスト。任意>
（任意の属性: ID / status / 根拠ADR・要件）
  • 必須は 名前・Statement・なぜ の3つ。含意は重要な原則のみ。
  • Implications を全項目に書かない（GOV.UK 流の軽さ）。
  • 個数は 最大でも ~7、理想は3〜5。

成果物2: 分類チェックリスト（principle / requirement・standard / rule・policy / ADR）

問いYes の場合
測定可能・受入基準があるか？要件 / 標準
必須かつ具体的で、より上位から導かれるか？ポリシー / 標準
却下した代替案と受容するコストを明示するか？ADR（決定）
複数の妥当な選択肢から選んだ結果か？ADR（決定）
多くの決定に渡って持続し、他の文を生成/正当化するか？原則
反対の原則も別文脈で妥当か（reversibility）？妥当なら本物の原則。妥当でなければ陳腐＝削除

成果物3: 優先度（bizlp 文脈）

  • Must: ①原則と「実装ルール/要件」を分離（測定可能なものは SR へ）②各原則に「なぜ」を必ず添える ③個数を ~5 以内に抑える ④トレードオフは「X over Y」で言い切る
  • Should: 原則に ID を振り ADR から参照可能にする / 原則の改訂手続き（Stable 基準）を一行決めておく
  • Nice: status / owner 属性、reversibility テストを原則追加時のレビュー観点に組み込む

bizlp への適用メモ

  • 直近の DRP §4 再構成（「ゆずれない原則（構え）」と「実装ルール」の分離）は、本調査の Q2 分類テスト（測定可能＝要件、価値判断＝原則）と整合。40点閾値・Status権限を実装ルール側へ寄せた判断は妥当。
  • 中核原則「AI は決めない。人が決める」は reversibility テスト合格（反対「AI が決める」は別の立場として成立しうる＝陳腐でない）。
  • 改善余地: 各原則に 根拠 BR/ADR の ID 参照を付け、「X over Y」表現を一部採用（例「人間の最終判断 over 自動承認」）。

参考文献