👏

Spec-tech-moneyデシジョンログの、フォーマットをまとめて、サンプルを2つほど生成してみて

に公開
自動生成
idea

Spec-Tech-Money デシジョンログ（STMログ）

「なぜその決定が（現時点で）合理的か」を、3つの要素（Spec/Tech/Money）のバランスで説明し、特に「将来の変更可能性（可逆性）」を意識的に記録する

フォーマット（テンプレート）

基本情報

  • ID: [一意のID、例: STM-001]
  • 日付: [意思決定した日付: YYYY-MM-DD]
  • ステータス: [提案中 | 承認 | 棄却 | 変更済(→STM-XXX)]
  • 決定者: [意思決定を行ったチームまたは個人]

1. Spec（ニーズ・課題・仕様）

[S-1] フォーカスするニーズ

我々は何の課題を解決しようとしているのか？ 顧客の誰のどんな要求か？

[S-2] 制約・要求事項

満たすべき必須要件は何か？ スピード、品質、セキュリティ等の優先順位は？

[S-3] 不確実性（Spec面）

このニーズは本当に正しいか？ 将来変わる可能性はどれくらいか？

2. Money（費用対効果・ビジネス合理性）

[M-1] 費用（Cost）

初期開発コスト、運用コスト、ライセンス費用、トレーニング費用など

[M-2] 効果（Benefit / ROI）

売上貢献、コスト削減、リードタイム短縮、[S-1]の課題解決度など

[M-3] 不確実性（Money面）

予算の制約は？ [M-2]の効果見積もりの確度は？

3. Tech（技術・アーキテクチャ）

[T-1] 検討した選択肢（と棄却理由）

A案: [案の概要]

  • 棄却理由: [Spec/Tech/Moneyの観点でなぜ不採用か]

B案: [案の概要]

  • 棄却理由: […]

[T-2] 採用する選択肢

C案: [案の概要]

[T-3] 採用理由（STMのバランス）

なぜC案が、現状のS/T/Mのバランスにおいて最適と判断したか

4. 可逆性（Decision Type）

[R-1] 決定タイプ

  • 不可逆（One-Way Door）
  • 可逆（Two-Way Door）
  • 中間

[R-2] 可逆性の判断理由

なぜそう判断したか？ ロックインの度合いは？

[R-3] 将来の変更トリガー（もし可逆なら）

もし将来変更するとしたら、何をキッカケに判断するか？

  • 例: ユーザー数がX人を超えたら、特定の機能要求が出たら、など

[R-4] ピボット戦略（変更の余地）

将来、棄却したA案やB案に移行するための「仕込み」や「残している余地」は何か？

サンプル1: 認証基盤（ピボット可能なSaaS選定）

基本情報

  • ID: STM-001
  • 日付: 2025-10-18
  • ステータス: 承認
  • 決定者: プロダクトチーム

1. Spec（ニーズ・課題・仕様）

[S-1] フォーカスするニーズ

MVP（Minimum Viable Product）を最速で市場投入し、コア機能のPMF（プロダクトマーケットフィット）検証を行いたい。ユーザー認証（サインアップ、ログイン）機能が必須。

[S-2] 制約・要求事項

  • 最優先: 市場投入速度（Time to Market）
  • 必須: ソーシャルログイン（Google, Apple）
  • 将来: 2要素認証、SAML連携の可能性あり

[S-3] 不確実性（Spec面）

高い。 PMF検証前であり、将来的にエンタープライズ向け機能（SAML等）が本当に必要になるか不明。コア機能が受け入れられなければ、サービス自体ピボットする可能性がある。

2. Money（費用対効果・ビジネス合理性）

[M-1] 費用（Cost）

初期開発リソース（エンジニア2名）はコア機能開発に集中させたい。認証機能に工数を割きたくない。

[M-2] 効果（Benefit / ROI）

認証開発工数を（A案比で）1人月削減し、MVPリリースを2週間早める。

[M-3] 不確実性（Money面）

高い。 シードステージであり、ランウェイ（資金余命）は残り12ヶ月。コスト（特に初期コスト）は最小限に抑える必要がある。

3. Tech（技術・アーキテクチャ）

[T-1] 検討した選択肢（と棄却理由）

A案: 認証機能のフルスクラッチ開発（ライブラリ使用）

  • 棄却理由: [S-2]の速度を満たせない。[M-1]の観点で開発リソースを割けない。セキュリティ担保の工数も別途必要になる。

B案: オープンソース（Keycloak等）のセルフホスト

  • 棄却理由: [M-1]の観点で、運用・保守コストが継続的にかかる。速度面でも[A案]よりは早いが[C案]に劣る。

[T-2] 採用する選択肢

C案: 認証SaaS（Auth0, Firebase Authなど）の導入

[T-3] 採用理由（STMのバランス）

[S-1][S-2]の「市場投入速度」を最優先するため。[M-1]の開発リソースをコア機能に集中できる。[M-3]の予算観点でも、無料枠〜低価格帯でスタートできるため、PMF検証フェーズに最適。

4. 可逆性（Decision Type）

[R-1] 決定タイプ

✅ 可逆（Two-Way Door）

[R-2] 可逆性の判断理由

認証SaaSは、ユーザーデータをエクスポートする手段が提供されていることが多い。また、認証処理はAPI経由で抽象化されるため、将来的に内製（A案）やセルフホスト（B案）に切り替える際も、影響範囲を認証部分に限定できる。

[R-3] 将来の変更トリガー

  • [S-3]の不確実性が解消され、エンタープライズ機能（SAML等）が必須となり、SaaSの利用料が[M-1]の内製コストを大幅に上回った場合
  • MAU（月間アクティブユーザー）が10万人を超えた場合

[R-4] ピボット戦略（変更の余地）

  • アプリケーション側では、認証SaaSのSDKに直接依存せず、自社定義の認証インターフェース（Facadeパターン） を介して利用する
  • これにより、将来SaaS（C案）から内製（A案）に切り替える際も、このインターフェースの具象クラスを差し替えるだけで対応可能にし、Tech的なロックインを最小限に留める

サンプル2: システムアーキテクチャ（モジュラーモノリス）

基本情報

  • ID: STM-002
  • 日付: 2025-10-18
  • ステータス: 承認
  • 決定者: CTO, 開発チーム

1. Spec（ニーズ・課題・仕様）

[S-1] フォーカスするニーズ

中規模ECプラットフォームの構築。初期フェーズでは「商品管理」「注文管理」「顧客管理」の3つのコア機能を提供する。

[S-2] 制約・要求事項

  • 初期開発のシンプルさと速度
  • 将来的に「物流連携」「ポイント機能」などドメインが複雑化する想定
  • 各機能（ドメイン）は、将来的に専任チームが担当する可能性がある

[S-3] 不確実性（Spec面）

中程度。 コアドメイン（商品・注文・顧客）は固まっているが、どの機能が将来的にスケールし、複雑化するかは現時点では予測困難。

2. Money（費用対効果・ビジネス合理性）

[M-1] 費用（Cost）

開発チームは5名。インフラ運用コスト（特に固定費）は最小限に抑えたい。

[M-2] 効果（Benefit / ROI）

まずはモノリシックな構成で迅速に機能をリリースし、市場からのフィードバックを得る。

[M-3] 不確実性（Money面）

事業がスケールした場合、インフラコストが増大する懸念はあるが、初期の低コストを優先する。

3. Tech（技術・アーキテクチャ）

[T-1] 検討した選択肢（と棄却理由）

A案: マイクロサービスアーキテクチャ

  • 棄却理由: [M-1]のチーム規模（5名）では、サービス分割・運用・監視のオーバーヘッドが大きすぎる。[T-3]の通り、まだ時期尚早。

B案: 単純なモノリス（密結合なスパゲッティコード）

  • 棄却理由: [S-2]の将来的なドメイン複雑化に対応できない。将来の分割コストが天文学的になる「不可逆な技術的負債」を生む。

[T-2] 採用する選択肢

C案: モジュラーモノリス（Modular Monolith）

単一のデプロイ単位だが、内部はドメイン（商品・注文・顧客）ごとにモジュールを明確に分割し、モジュール間の依存関係を厳格に管理する。

[T-3] 採用理由（STMのバランス）

[S-2]の「初期のシンプルさ」と[M-1]の「低コスト」を満たしつつ（モノリスの利点）、[S-2]の「将来の複雑化」にも備える（モジュールの利点）。[S-3]の「どの機能がスケールするか不確実」という状況に対し、最もバランスが良い。

4. 可逆性（Decision Type）

[R-1] 決定タイプ

✅ 可逆（Two-Way Door） ※ただし移行コスト中

[R-2] 可逆性の判断理由

C案（モジュラーモノリス）は、B案（単純モノリス）と異なり、ドメイン間の境界がコードレベルで明確に定義されている。

[R-3] 将来の変更トリガー

  • [S-3]の不確実性が解消され、特定のドメイン（例：「注文管理」）の開発速度が他ドメインのボトルネックになった場合
  • 「注文管理」チームが専任で組織され、他チームと独立したデプロイサイクルが必要になった場合

[R-4] ピボット戦略（変更の余地）

  • C案の設計（モジュール分割）により、将来A案（マイクロサービス）に移行する際、コストを最小限に抑える余地を残している
  • 具体的には: ボトルネックとなったモジュール（例：「注文管理」）だけを、定義されたインターフェース（API）を保ったまま、別サービスとして切り出すことが可能
  • これは、最初からA案を選ぶ[Tech]的なオーバーヘッドや、B案を選んで[Money]的に移行不能になるリスクを回避する、SpecとMoneyの観点からも合理的なTechの意思決定である

活用のポイント

  1. 3つの観点のバランス: Spec（何を）、Money（費用対効果）、Tech（どう実現）を常に意識
  2. 可逆性の明確化: 意思決定が後から変更可能か、コストはどの程度かを記録
  3. 将来への備え: 棄却した選択肢への「逃げ道」や「トリガー条件」を明記
  4. チーム共有: なぜその決定をしたのか、後から参照できる形で残す​​​​​​​​​​​​​​​​

Discussion