📕

創業初期のスタートアップで「開発スピードを殺さずに」ADRを運用する技術

に公開
アーキテクチャ
スタートアップ
技術的負債
ADR
idea

🎧 この記事のテーマについて、AI同士で対話させたPodcastも作りました。 🎧
Spotify

はじめに

「なぜ、このライブラリを選定したのか？」
「なぜ、ここは正規化せずにJSON型で保存することにしたのか？」

創業初期のスタートアップにおいて、こうした文脈（コンテキスト）はしばしば、特定の誰かの頭の中にしか存在しません。そして、メンバーが増え始めたタイミングで、その「誰か」は質問攻めに遭うことになります。

Architecture Decision Records (ADR) は、こうした技術的な意思決定を記録するための素晴らしいツールです。しかし、教科書通りのフォーマットをそのまま少人数のチームに持ち込むと、大抵は失敗します。「書くのが面倒」「誰も読まない」「スピード感が落ちる」といった理由で形骸化するのです。

この記事では、リソースの限られたスタートアップ開発組織において、いかに開発スピードを落とさずに、かつ将来の負債とならないようなADR運用を行うかについて、実務的な観点から掘り下げます。

この記事で触れること：

  • テンプレートを極限まで削ぎ落とした「3要素ADR」
  • 技術的負債を「正当化」するための借用書としての活用法
  • 経営陣を巻き込むためのツール選定と、過去の決定を捨てる勇気

1. テンプレートを極限まで削ぎ落とす

ADRを導入しようと思ったとき、多くの人はまず madr などの有名なテンプレートを探しに行きます。しかし、そこには「Status」「Context」「Decision」「Consequences」「Pros/Cons」「Options Considered」……と、多くの項目が並んでいます。

創業期の数人のチームで、これを毎回埋めるのは正直なところ苦痛です。空欄を埋める作業自体が目的化し、「面倒だから記録しない」という本末転倒な事態を招きます。

そこで提案したいのが、項目を以下の3つだけに絞る 「超軽量ADR」 です。

必要な3要素

  1. Context（文脈）: どのような課題があり、どのような制約条件（時間、予算、スキルセット）があったか。
  2. Decision（決定）: 結局、何を選んだのか。
  3. Consequences（結果・影響）: その決定により、何が得られ、何を犠牲にしたか。

コードで見る進化

たとえば、「認証基盤の選定」を例に考えてみます。教科書通りに書こうとすると長くなりがちですが、3要素に絞ると以下のようになります。

# ADR-001: 認証基盤としてAuth0を採用する

## Context
サービスのMVP（Minimum Viable Product）リリースまで残り1ヶ月。認証機能の実装工数は極力削りたい。
また、将来的にエンタープライズ向けのSSO対応が見込まれるが、現状のメンバーに認証周りの深い知見を持つエンジニアがいない。

## Decision
自前実装やFirebase Authではなく、Auth0を採用する。

## Consequences
- ユーザー管理画面の実装コストがゼロになった。
- 将来のSSO対応への道筋がついた。
- ただし、MAUが増えた際のランニングコストは自前実装やFirebaseより高くなるリスクがある（シリーズA以降で再検討が必要になる可能性）。

これくらいの分量であれば、Slackに投稿する感覚や、Pull RequestのDescriptionを書く延長で記述できます。

特に重要なのが 「Consequences（結果・影響）」 です。ここにはメリットだけでなく、「何を犠牲にしたか（トレードオフ）」 を必ず書くようにします。上記の例で言えば、「コストが高くなるリスク」を明記している点が肝です。これが書いてあるだけで、将来チームにジョインしたエンジニアは「当時のチームはコスト高を知った上で、開発スピードを優先したんだな」と理解でき、無用な「なんでこんな構成にしたんだ」という批判を防げます。

2. 技術的負債の「借用書」として使う

PMF（Product Market Fit）前のフェーズでは、スケーラビリティや保守性を意図的に犠牲にしてでも、機能リリースのスピードを優先すべき場面があります。いわゆる「クソコード」や「突貫工事」が必要な瞬間です。

しかし、単に汚いコードを書くだけでは、それはただの「負債」です。ADRを使って、これを 「戦略的な借金」 に変えます。

「あえて」汚く書くことを正当化する

ADRを「技術的負債の借用書」として定義してみましょう。記述すべきは以下の点です。

  • なぜ今はその負債を受け入れるのか（例：来週の展示会デモに間に合わせるため）
  • どのような条件下で返済を開始すべきか（例：ユーザー数が1000人を超えたら、またはデモ終了後即時）

仮に、「パフォーマンスに問題が出そうなN+1問題を放置してリリースする」という決定をしたとします。コード上にコメントを残すのも良いですが、ADRとして以下のように宣言することで、チームの共通認識になります。

Decision: 一覧取得APIにおけるN+1問題は、現状の想定データ量（最大50件）ではレイテンシへの影響が軽微であるため、解消せずにリリースする。
Consequences: 実装工数を2日短縮できた。ただしデータ量が1000件を超えるとレスポンスが悪化するため、そのタイミングでEager Loadingへの書き換えを行う。

こうしておくことで、将来そのコードを見た人は「当時の開発者が無能だったわけではなく、意図的に後回しにしたのだ」と分かります。これは、創業メンバーのメンタルヘルスを守る上でも意外と重要です。

3. 運用フロー：NotionとGitHubの使い分け

エンジニアだけであれば、MarkdownファイルをGitリポジトリで管理する（Madrなどの手法）のが最も自然です。しかし、スタートアップの初期意思決定には、非エンジニアである経営陣（CEOやPM）が深く関わることが多々あります。

「GitHubのPull Requestを見てください」と言っても、彼らにとってはハードルが高いものです。そこで、「議論はNotion、履歴はGit」 というハイブリッドな運用が有効です。

運用フローの例

  1. Notionでドラフト作成: 議論の場としてNotion（あるいはGoogle Docsなど）を使う。コメント機能でCEOやPMとワイワイ議論し、合意形成を図る。
  2. GitHubへCommit: 決定した内容だけをMarkdownに落とし込み、リポジトリにコミットする。
  3. Notionからリンク: Notionのページには「決定事項はこちら」としてGitHubのパーマリンクを貼るか、アーカイブ化する。

あるいは、極端な話、初期フェーズであればGitHub管理への固執を捨てて、Notionデータベースで完結させても良いでしょう。重要なのは「Gitで管理すること」ではなく、「決定の履歴と文脈が検索可能な状態で残っていること」です。

また、こうして蓄積されたADRは、最強のオンボーディング資料になります。新入社員は、過去のADRを読み返すことで、「なぜこの技術スタックなのか」「会社の技術文化はどう変遷してきたか」を追体験（脳内ダンプのインストール）できるからです。

4. 「Superseded」：決定を覆す勇気

最後に、ADRのステータス管理についてです。スタートアップにおいて、半年前の常識は今日の非常識です。前提条件は頻繁に変わります。

過去に書いたADRを神聖視してはいけません。むしろ、状況が変わったら積極的にステータスを Superseded（置換済み・廃止） に更新する儀式を行いましょう。

サンクコストバイアスとの戦い

「せっかくADRまで書いて導入した技術だから……」と固執するのは危険です。ピボットによって事業ドメインが変われば、最適な技術も変わります。

ADRに Superseded ステータスを付与し、新しいADRへのリンクを貼る。この「決定を捨てるプロセス」自体を可視化することで、組織全体に「間違っていたら直せばいい」「変化を恐れない」というマインドセットを根付かせることができます。

たとえば、「マイクロサービス構成にする」というADRがあったとしても、チーム規模に対してオーバーヘッドが大きすぎると分かった時点で、潔く「モノリスに戻す」というADRを書き、前のADRを Superseded にする。この履歴こそが、組織の学習記録となります。

まとめ

創業初期のスタートアップにおけるADRは、重厚なドキュメント管理システムではありません。それは、「未来の自分たち」や「新しく入ってくる仲間」への手紙のようなものです。

  1. 3要素（Context, Decision, Consequences） だけに絞って書く。
  2. 技術的負債を受け入れる際の 「借用書」 として使う。
  3. ツールにこだわらず、経営陣も巻き込める場所 で議論する。
  4. 状況が変われば、過去の決定を 恐れずに上書き（Supersede） する。

もし、あなたのチームで「なんでこうなってるんだっけ？」という会話が今週一度でもあったなら、まずはその答えを数行のテキストファイルに残すところから始めてみてください。フォーマットなんて、後からどうとでもなりますから。

Discussion