決定の最終責任者 (Approver) の 役割 (role)人 (who) の対応を、履歴つきで記録する正典。ADRapprover_role は Scope (ADR-0049) 由来の 4 役割を指し、人は割り当て直せる。これにより、チーム化で担当者が変わっても過去 ADR の書き直しは要らない。

監査が「承認時点でその権限を持っていたこと」を立証するときは、ADR の 承認日時 (JST) と本表の期間 (開始日〜終了日) を照合する (CI が自動実行)。

役割割当 (現行 + 履歴)

rolewhoGitHub開始日終了日備考
corporate齋藤達希 ([email protected])t-saitoh-bizlp2026-06-12代表取締役。Corp 軸 (経営・全社規約) の最終責任者
platform齋藤達希 ([email protected])t-saitoh-bizlp2026-06-12Platform 軸 (基盤・横断技術) の最終責任者。現在は兼任
product齋藤達希 ([email protected])t-saitoh-bizlp2026-06-12Product 軸 (製品・機能) の最終責任者。現在は兼任
ops齋藤達希 ([email protected])t-saitoh-bizlp2026-06-12Ops 軸 (運用・保守) の最終責任者。現在は兼任

現状 (2026-06-12): 1 人法人のため 4 役割すべてを代表取締役が兼任する。役割と人を分けて記録するのは、将来の役割再割当 (Jr 採用・チーム化) を過去 ADR を触らずに行うため。

開始日の意味: ADR-0141 受理日 (2026-06-12) を全役割の初期割当開始日とする。これより前に受理された ADR の承認権限照合は、本表の corporate 行を遡及的に適用する (1 人法人で全役割兼任のため権限の実体は不変)。

更新手順

  • 役割の担当者が変わったら、旧行の 終了日 を記入し、新しい担当者の行を 開始日 つきで追加する (行は削除しない — 履歴を残す)。
  • GitHub 列は merge 者一致検査 (CI: adr-approver-merge-check・ADR-0141) が ADR の approver_who (メール) を merge 実行者 (GitHub login) と突合するための対応列。アカウントが変わる場合も行追加で履歴を残す。
  • 役割そのものの追加・廃止は Scope (ADR-0049) の見直しを伴うため、ADR で決める。
  • 本表は approver_who の正本ではなく、role → who の対応と有効期間の正本である。個々の ADR の承認者は各 ADR の frontmatter (approver_role / approver_who) が持つ。

関連

  • ADR-0141: 承認者体系 — 単一 Approver の frontmatter 構造化と受理 PR 層の機械検査
  • ADR-0049: Scope 分類軸の 4 層化 (approver_role の値域の出典)
  • 構造正典 検査の所有 (5 層モデル) §G-2: 下流ガバナンス 4 つの機械検査の所在 (承認者 = ④ 受理 PR 層)