誤ったデータベース決定の15倍コスト：意思決定タイミングの教訓

3つの本番システムにおけるデータベース決定のコストを測定しました。蓄積されたデータとスキーマ依存関係により、移行コストは3年間で15倍に膨れ上がりました。

TL;DR

ほとんどのエンジニアは意思決定のタイミングを逆転させています。可逆的な選択（どのAPIクライアントライブラリを使うか）には何日も悩む一方で、不可逆的な決定（スプリントプランニング中のデータベーススキーマ設計）は数分で下してしまいます。Ray DalioとJeff Bezosは、異なる角度から同じフレームワークを説明しています。可逆的な決定は素早く行うべきです。なぜなら、遅延のコストは不完全さのコストを上回るからです。不可逆的な決定には、そのリスクに見合った分析が必要です。私はこの教訓を、初期のスキーマ設計の手抜きが6桁ドルの移行コストに膨らんだ3つのシステムを通じて、身をもって学びました。

私に教訓を与えた移行作業

ZipRecruiterでの最初の年、前任チームが初期開発を加速するために非正規化スキーマを選んだシステムを引き継ぎました。当時の判断としては理にかなっていました。まず素早くリリースし、正規化は後で行う、と。しかし「後で」は決してやって来ませんでした。

2年目には、3つのサービスがその非正規化構造に依存していました。3年目には、スキーマに14ヶ月分の本番データが蓄積され、非正規化レイアウトを前提とした外部キー関係が築かれ、構造変更で壊れるレポートクエリが6つ存在していました。

1ヶ月目の移行コストはおよそエンジニア2日分だったでしょう。12ヶ月目には2週間。36ヶ月目の見積もりは、3ヶ月間の専任エンジニアリング作業に加え、ダウンタイムを避けるためのデュアルライト・ロジックを伴うローリングデプロイメントでした。これが15倍の倍率です。問題自体が難しくなったのではなく、蓄積された依存関係によって影響範囲が月ごとに拡大したのです。¹

フレームワーク

可逆的な決定：数分で決める

プロトタイプ用のフロントエンドフレームワークの選択。変数命名規則の決定。ステージング環境のクラウドリージョン選択。最初に書くブログ記事の選択。

これらには共通の特徴があります。方針を変更するコストは、いつ変更しても概ね同じです。遅延は成果を向上させることなく時間を浪費するだけです。²

私の判定基準： 来週この決定を取り消す場合、1日未満の作業で済むなら、今すぐ決めます。

このサイトを構築する際、ReactよりHTMXを約10分で選びました。もしHTMXが間違いだったとしても、サーバーレンダリングテンプレートを使った個人サイトでフレームワークを切り替えるのは週末で済んだでしょう。取り消しコストが低いということは、分析よりもスピードが重要であることを意味します。

不可逆的な決定：数日かけて決める

顧客データ用のデータベースエンジンの選択。外部システムが依存するAPIコントラクトの定義。86個のフックがその上に構築されるフックアーキテクチャの選択。

これらは複利的に効いてきます。取り消しのコストは時間とともに、しばしば指数関数的に増大します。³

私の判定基準： この決定を取り消すコストが6ヶ月ごとに倍増するなら、リスクに見合った分析を投入します。

私の.claude/フックアーキテクチャは、正しく行われた不可逆的な決定の好例です。フックのライフサイクルモデル（PreToolUse、PostToolUse、Stopなど6種類）の設計に2週間費やしてから、最初のフックを書き始めました。その設計は現在、gitセーフティ、再帰制御、フィロソフィーの適用、品質ゲート、オブザーバビリティにまたがる86個のフックをサポートしています。この時点でライフサイクルモデルを変更するには、すべてのフックを書き直す必要があります。事前の分析は何倍もの見返りをもたらしました。⁴

正しかった決定と間違った決定：5つの事例

正解：Tailwindの代わりにプレーンCSSを選択

種類： 可逆的。 所要時間： 20分。

このサイトではTailwindの代わりにカスタムプロパティを使ったプレーンCSSを選びました。もし間違いだったとしても、週末でTailwindに移行できたでしょう。決定には20分かかりました。フレームワークの生産性よりもCSSの基礎を学ぶことを重視したのです。2年経った今、プレーンCSSを選んで良かったと思っています。なぜなら、すべての最適化（完璧なLighthouseスコアの達成）においてCSSが実際に何をしているかの理解が必要だったからです。ただし、この決定はどちらに転んでも大きな問題にはなりませんでした。

正解：フックアーキテクチャ設計への投資

種類： 不可逆的。 所要時間： 2週間。

86個のフックがこのライフサイクルモデルに依存しています。事前設計に費やしたすべての時間に見合う価値がありました。

失敗：ブログコンテンツスキーマの拙速な設計

種類： 不可逆的。 所要時間： 30分。

ブログ投稿のContentMetaデータクラスを1回のセッションで定義しました。title、slug、date、description、tags、author、publishedです。category、series、hero_image、scripts、stylesは含めませんでした。後から追加するたびに、パーサーの修正、メタデータを参照するすべてのテンプレートの更新、そしてブログパイプライン全体の再テストが必要になりました。3ヶ月間の5回の追加にかかったトータルの時間は、最初にスキーマを慎重に設計していた場合よりも多くなりました。

失敗：ブログ記事の順番に悩みすぎた

種類： 可逆的。 所要時間： プランニングセッションで2時間。

どのブログ記事を最初に書くかを決めるのに2時間費やしました。順番は完全に可逆的でした。何でもいいから書き始めて、学んだことに基づいて後から並べ替えるべきでした。

正解：コンセンサス閾値の慎重な設計

種類： 不可逆的。 所要時間： 1週間。

私の審議システムは、タスクに応じたコンセンサス閾値を使用しています。セキュリティ決定は85%、機能は80%、リファクタリングは65%、ドキュメントは50%です。これを誤ると、正当な作業がブロックされるか（閾値が高すぎる場合）、危険な変更が承認されてしまいます（閾値が低すぎる場合）。コミットする前に、各閾値を実際のタスク履歴に対してテストしました。

よくある逆転現象

エンジニアはAPIクライアントライブラリの選定（可逆的、低い切り替えコスト）に何日も費やす一方で、データベーススキーマはスプリントプランニングのミーティングで設計してしまいます（不可逆的、高い移行コスト）。

マネージャーも同じことをします。プロジェクト管理ツールの評価（可逆的）に何週間もかける一方で、チーム再編は一晩で行います（不可逆的、高い人的コスト）。⁵

この逆転が起こるのは、可逆的な決定はその瞬間には重大に感じられ（チームがライブラリの選択を評価するかもしれない）、不可逆的な決定は抽象的に感じられる（移行は3年先の話だ）からです。この感覚はまさに逆なのです。

あらゆる決定の前に問うべき2つの質問

1. 6ヶ月後の取り消しコストはどれくらいか？ 答えが「些細なもの」なら、今すぐ決めます。
2. 遅延によって利用可能な情報は改善されるか？ 待っても新しいデータが得られないなら、今すぐ決めます。

両方の条件が待つことを支持する場合にのみ熟慮すべきです。つまり、取り消しが高コストかつ時間の経過とともにより良い情報が得られる場合です。⁶ それ以外はすべて即座に決めます。

重要なポイント

エンジニア向け： - プロトタイプの技術スタック選択は可逆的です。ミーティングではなく数分で決めましょう - データベーススキーマとAPIコントラクトは規模が大きくなると不可逆的です。どれだけ多くのシステムがその決定に依存するかに比例して、事前の分析に投資しましょう - 意思決定のコストを追跡しましょう。15倍の移行コスト倍率を測定したことで、事前投資の評価方法が変わりました

マネージャー向け： - ツールやプロセスの変更は通常可逆的です。素早くパイロットし、反復しましょう - チーム構成や採用の意思決定は取り消しコストが高いです。それに見合った時間をかけて検討しましょう - チームがライブラリ選定に1週間費やしている場合、取り消しコストがその審議時間を正当化するかを問いましょう

参考文献