目次
はじめに
こんにちは、フォースタートアップス株式会社エンジニアの野尻（@jsotakebmx）です。ヒューマンキャピタル支援システム（社内プロダクト）の開発を担当しています。
最初に断っておくと、この記事は完全に自戒です。 誰かの意思決定を指しているわけではなく、自分自身が「トレードオフ」という言葉をちゃんと使えているのか？を振り返った記録になります。
エンジニアをやっていると「トレードオフ」という言葉をよく使います。
技術選定、設計判断、スケジュールと品質のバランスをとるときなど…あらゆる場面で口にする機会があると思います。
実際私もそうです。意思決定の文脈でトレードオフという考え方をよく使いますし、ADR（Architecture Decision Record）を書くときも「トレードオフを踏まえた上で〜」という構成にすることが多いです。
ただ、最近「あれ、これって本当にトレードオフだったっけ？ただの妥協にトレードオフって名前をつけてないか？」と思い直すようになってきました。
この記事では、自分の経験を振り返りながら「トレードオフだと思っていたものが、本当にトレードオフだったのか？」を見つめ直してみたいと思います。
トレードオフが成立する条件
そもそも開発分野におけるトレードオフとは何かを改めて整理すると、私は「AとBの両方を最大化できないという構造的な制約の中で、意図的にどちらを優先するか選択すること」だと考えています。
個人的に考えるポイントは3つあります。
- 構造的な制約がある — AとBの両立が不可能である
- 意図的な選択がある — なんとなくではなく、判断している
- 犠牲の言語化ができる — 選ばなかった側の代償を説明できる
この3つが揃って初めてトレードオフと呼べるのではないかと思っている一方で、3つが揃っていたとしても永続するとは限らず、揃っているように見えて実は揃っていないこともあると思います。
改めて自分自身の経験を振り返ると、このトレードオフの成立根拠が消えてしまうパターンが3つありました。
賞味期限切れ
私のチームでは、「リリース速度を優先してテストの網羅性は犠牲にする」という意思決定がされてきました。フロントエンドのコアなビジネスロジック周りにはテストがあるものの、バックエンドにはほとんどありません。 この判断自体は、当時のコンテキストではトレードオフとして一定成立していたと思います。
限られたリソースの中で、テストを書く時間を実装に充てる。速度と品質保証の間で意図的に速度を選んでいる。構造的な制約、意図的な選択、犠牲の認識の3つの条件はある程度満たしていました。
ただ、ここで改めて「そのトレードオフ、今も成り立っているのか？」ということを問い直す必要があると感じています。
テストを書かないことで得られる「速度」は、本当に今も得られているのか。実感としては、むしろ逆のことが起きている気がしています。
テストがないことでリグレッションの検知が難しく、手動確認のコストも膨らみます。開発の後半になるほど保守性の悪化が効いてきて実装そのものが遅れたり、リリース後にバグが見つかれば、その対応で新規開発が止まります。
「テストを書かないことでスピードが上がる」はずだったのに、テストを書かないことでスピードが落ちている局面が出てきていると感じます。
さらに言えば、AI駆動の開発が当たり前になりつつある今、「テストを書く = 時間がかかる」という前提自体が一部揺らいでいるようにも感じています。テスト生成の補助が効く場面も増えてきた中で、「テストを書くコスト」と「テストを書かないコスト」のバランスは、判断した当時と同じなのか...
判断した瞬間は正しかった（あるいは少なくとも合理的だった）としても、前提が変われば結論も変わります。
一度下した判断を「確定したトレードオフ」として誰も見直さなければ、前提が変わっているのに結論だけが残る、「賞味期限切れ」の状態になってしまいます。
お腹を壊す前に、コンスタントに「賞味期限」を確認し新鮮な状態に戻してあげましょう。
情報の非対称
技術選定でADRを書くとき、複数の技術についてA vs Bの形式で整理することがあります。
実際私自身もADRを書くときは、トレードオフの体裁を取ることが多く、A/Bのメリット・デメリットを並べて、総合的に判断するように心がけています。
ただ、（当たり前かもしれませんが）形式だけ取っていてもあまり意味はありません。 たとえば、自分が知見のある技術Aについては5つのメリットと1つのデメリットが書いてあるのに、あまり触ったことのない技術Bについてはメリット1つ・デメリット2つ書かれているのでは、 情報量に明らかな差があります。
この状態で「比較した結果、Aを選びました」と言っても、それは結論が先にあって比較はそれを正当化するための装置になっている可能性があると思います。 トレードオフのフォーマットを借りた一種の確証バイアスとも言えるかもしれません。
誤解のないように書いておくと、知見のある技術を選ぶこと自体はかなり合理的だと思います。チーム/個人の習熟度は十分な判断軸ですし、未知の技術に賭けるリスクを避けることも妥当な選択です。 問題は、その構造を正直に書いているかどうかに尽きると考えています。
「技術的にAが優れているから選んだ」と書くのと、「Aの方がチームに知見があり、Bを十分に評価するコストを今は払えないからAを選んだ」と書くのでは、同じ結論でも誠実さが全然違いますよね。
後者は誠実な判断ですが、前者は（意図せずとも）妥協を隠してしまっていると言えるかもしれません。
制約の見落とし
そもそもトレードオフの比較対象にならないものを、比較対象として扱ってしまうケースです。
たとえば、レコメンド機能の開発を考えてみます。「ルールベースのレコメンドにするか、個人情報をAI解析してパーソナライズするか」という比較があったとします。レコメンド精度やユーザー体験を軸に比較すれば、AI解析の方が優れているように見えるかもしれません。
しかし、サービス規約で「個人情報を二次利用しません」と規定しているのであれば、AI解析という選択肢は最初から取れません。精度とコストの「トレードオフ」に見えていたものは、制約を見落としたまま存在しない選択肢を比較していただけです。
（もし、AI解析に興味があっても）技術的な興味はグッと堪えて、「その選択肢はビジネス上の制約としてそもそも選べるのか？」を最初に確認する必要があるなぁと感じています。
「消えるよ」🎾
3つのパターンを並べてみると、共通点が見えてきます。
| パターン | 実態 | 問題 |
|---|---|---|
| 賞味期限切れ | 前提が変わったのに判断が残っている | 再検討の欠如 |
| 情報の非対称 | 結論ありきの比較 | フェアな評価の欠如 |
| 制約の見落とし | 要件を満たさない案の採択 | ビジネス要件との不整合 |
いずれも、ちゃんと見つめ直すとトレードオフとして成立していない（あるいは成立しなくなっている）ことに気づきます。前提が変わっていたり、比較がフェアでなかったり、そもそも選択肢じゃなかったり...
ただ、根拠が消えること自体は悪いことではなく、むしろ健全です。問題なのは、消えるべき根拠が消えずに残り続けて、意思決定の拠り所として引用され続けることだと思います。
自戒としてのチェックリスト
最後に、自分が意思決定をするときに確認したいことをまとめておきます。
「これはトレードオフか？」を判定する3つの問い
- その判断の「前提」は、今も変わっていないか？
- 前提が変わっているなら、結論だけ残っていても意味がない。トレードオフには賞味期限がある。
- 選ばなかった側を、同じ熱量で説明できるか？
- できないなら、情報が足りていないか、結論ありきになっている可能性がある。
- 比較している軸は、達成すべきゴールに紐づいているか？
- ビジネス要件と関係ない観点で優劣をつけていないか。技術的な面白さとビジネス上の正しさは別物。
まとめ
「トレードオフ」は便利な言葉です。使った瞬間に意思決定が合理的に見えるし、犠牲を伴っている感じが出るので説得力もあります。だからこそ、妥協や前提の変化を覆い隠す言葉としても機能してしまいがちです。
自分がこれまでトレードオフだと思っていたものの中に、実は賞味期限が切れていたり、比較がフェアでなかったり、そもそも成立していなかったものが混ざっていなかったか... 正直なところ、ゼロではないと思います。
「うーん、これはトレードオフ！ 😀」と言ってしまいそうな時、その判断が本当にトレードオフとして成立しているのか、一拍置いて考える。そんな自戒でした。
