dipテックブログPublicationへの投稿
📝

【アーキテクチャカンファレンス2025】不確実性に抗う「オプション」の経済学 — Gregor Hohpeと『Tidy First?』の実践

Taira__
に公開
Go
アーキテクチャ
Tidy First?
アーキテクチャカンファレンス2025
gregorhohpe
tech

はじめに

先日開催されたArchitecture Conference 2025に参加してきました。
特に印象的だったのが、Gregor Hohpe氏によるキーノートセッション 「Architectural Thinking: Leading Teams Toward Better Decisions(アーキテクト思考 ― チームでより良い技術的意思決定を導くリーダーシップ)」 です。

このセッションのテーマは、アーキテクト思考によってチームの「意思決定」の質をどう高めるか。
その中で不確実性に対する重要な戦略として語られたのが 「オプション(選択肢)」 でした。

  • オプションとは意思決定を先延ばしするツール

この言葉は、アーキテクチャ論として非常に納得感があるものです。
しかし、現場のエンジニアとしては、もう一歩踏み込んで考えたくなります。
「なんとなく概念はわかった。では、日々のコードレベルでどうやってその『オプション』を作り出せば良いのか？」と。。。

その具体的な「How」に対する答えが、実はKent Beck氏の著書『Tidy First? ―個人で実践する経験主義的ソフトウェア設計』にありました。
本書は「整頓」というミクロな実践を扱っていますが、その第3部(理論)では、コードの構造がいかにして経済的な「オプション」を生み出すかが語られています。

本記事ではオプションという概念を『Tidy First』の実践的なアプローチを通じて噛み砕き、日々のコーディングにどう活かせるかを考えてみたいと思います。

「オプション」の経済学

『Tidy First』の第3部(理論)では、なぜコードを整頓するのか、その理由を「経済性」の観点から説明しています。
まずは、ソフトウェアが持つ「価値」の定義から見直してみましょう。

ソフトウェアが持つ２つの価値

第23章「構造と振る舞い」において、ソフトウェアには２つの価値があると述べられています。

  1. 振る舞い(Behavior)
    • 「今日ソフトウェアが行うこと」。給与計算や決済処理など、ユーザーに見える機能。
    • ビジネスの世界では「明日の1ドルより今日の1ドル」という時間価値に相当する。
  2. 構造(Structure)
    • 「明日ソフトウェアに行わせることができそうな新しいこと」。つまり変更のしやすさです。
    • 変更しやすい「良い構造」を維持することは、将来の様々なビジネス要求に低コストで応えられる 「選択肢（オプション）」 を保有することであり、それ自体が大きな経済的価値を持つ。

私たち開発者は、目にみえる「振る舞い(機能)」に追われがちです。
しかし、不確実な未来において真に価値を持つのは、実は後者の「構造(オプション)」なのです。

不確実性とオプション価値

第26章では、金融理論を用いてこの「オプション」の価値が説明されています。
金融におけるオプションとは、「将来ある価格で買う/売る権利」のことです。

これをソフトウェア開発に置き換えると、「次にどのような振る舞いを実装できるかという選択肢」と言い換えられます。

ここで重要なのが、「不確実性が高い(カオスな)状況ほど、オプションの価値は高まる」 という点です。
もし未来が完全に予測できるなら、最初から最適な機能を作り込めば良いので、オプション(選択肢)は不要です。
しかし、現実のソフトウェア開発では、将来何が必要になるか誰にもわかりません。

だからこそ、「今は決めずに、後で決めることができる」 という権利(オプション)を持っておくこと自体が大きな価値になるのです。

AIに例え話を生成させてみたら非常にわかりやすかったので紹介します

オプションとは「すぐに決め打ちするのではなく、後から選べる選択肢をできるだけ多く、長く持っておくこと自体に価値がある」という考え方です。

例え話：旅行の計画で考えてみよう！ ✈️

夏休みに沖縄旅行を計画しているとします。でも、あなたはこうも考えています。

  • 「沖縄は最高だけど、もし台風が来たらどうしよう…？」
  • 「最近、北海道の特集をテレビで見たけど、あっちも涼しくて良さそうだな…」
  • 「直前になって、急に友達からキャンプに誘われるかもしれない…」

この状況が、ソフトウェア開発における「不確実性」です。将来、何が最適かなんて誰にも分かりません。

ここで、あなたはどう行動しますか？

パターン１：「えいや！」で沖縄に決めてしまう

これは、一番最初に思いついた選択肢に飛びつくのと同じです。

沖縄行きの飛行機とホテルを、キャンセル不可の一番安いプランで予約してしまいました。

  • メリット: 早く決めたのでスッキリする。料金が少し安い。
  • デメリット: もし台風が来たら、旅行は台無しでお金も戻ってきません。もっと魅力的な北海道のプランを見つけても、もう変更できません。つまり、変化にとても弱いのです。

パターン２：「選べる権利」を買っておく

これが 「オプションを持つ」 という考え方です。

あなたは、少しだけ追加料金を払って、「キャンセル無料」のプランで沖縄と北海道の両方のホテルを予約しておきます。

これが元の文章でいう 「ポートフォリオに振る舞いを多く持つ」 状態です。あなたは「沖縄に行く」という選択肢と「北海道に行く」という選択肢の両方を手に入れたのです。

この「キャンセル無料プラン」こそが、将来 「沖縄か北海道かを選ぶ権利（オプション）」 そのものです。

この考え方のすごいところは以下の通りです。

  • ① 選択肢があるだけで価値がある

    出発直前の天気予報を見て、「よし、台風を避けて北海道にしよう！」と最高の選択ができます。どちらか一方に決めていたら、これは不可能でした。「次にどうするか選べる」こと自体が、あなたの旅行の満足度を上げる価値になっています。

  • ② 選択肢が多いほど、もっと価値がある

    もし「京都の川床もいいな…」と思ったら、京都のキャンセル無料プランも予約しておきます。選択肢（ポートフォリオ）が増えれば増えるほど、その時のベストな解を選べる可能性が高まり、価値が創造されます。

  • ③ ギリギリまで決めなくていい

    どの旅行先が最高かなんて、出発する直前まで分かりません。でも、オプションさえ持っていれば、焦って決める必要はありません。状況がはっきりするまで、一番価値のある選択がどれかを見極める時間があります。

  • ④ 不確実なときほど、オプションは輝く！ (これが最重要)

    もし、夏休みの天気が毎年完璧に予報できるなら、わざわざキャンセル無料プランを選ぶ必要はありません。一番天気の良い場所に決め打ちすればいいだけです。
    しかし、実際は天気がどうなるか分からない（不確実性が高い）からこそ、「直前まで変更できる」というオプションの価値が爆発的に高まるのです。

変化を恐れるのではなく、変化が起きたときにこそ価値を発揮できる「オプション」をたくさん持っておくことが大切であるという考え方です。

オプションの実体は「変更コストの低さ」

では、どうすればその「オプション」を手にできるのでしょうか？
ここで重要になるのが、第30章で語られる 「コンスタンチンの等価性」　です。

Cost(ソフトウェア) ≒ Cost(変更) ≒ Coupling (結合)

ソフトウェア全体の変更コストは、大きな変更のコストの合算とほぼ等しい

ソフトウェアのコストは、その生涯を通じて発生する「変更コスト」とほぼ等しく、その変更コストの正体は「結合」であるという理論です。

つまり、オプションを行使するためには、「結合」を減らして「変更コスト」を低く保つ必要があります。
もし変更コストが高すぎれば、「後で変更する」という選択肢すら選べないからです。

Go言語における「結合」と「オプション」

では、具体的にどうコードを書けば「オプション」が手に入るのか？ 第1部のテクニックを使って解説します。

Before:暗黙的な依存

以下は、第10章「明示的なパラメーター」で指摘されているアンチパターンです。
コンストラクタ（NewCreateUserUseCase）の引数がなく、内部で勝手に具体的なMySQLUserRepository を生成しています。

type CreateUserUseCase struct {
    repo *MySQLUserRepository 
}

// 引数がないので、何に依存しているか外から分からない（暗黙的）
func NewCreateUserUseCase() *CreateUserUseCase {
    // ここで勝手に具象型を作っている！これが「見えない結合」です。
    repo := NewMySQLUserRepository() 
    return &CreateUserUseCase{repo: repo}
}

何が起きるか

  • テストで詰む
    • ユニットテストを書こうとした時、本物のDB接続を持つ *MySQLUserRepository しか渡せず、モックに差し替えることができません。

この状態では、テスト時にモックに差し替えることも、将来DBをFirestoreに移行することもできません。
「高速にテストを回す」「技術選定を後回しにする」というオプションが、この時点ですでに失われています。

After：抽象型（interface）に依存する

  1. 内部で NewMySQLUserRepository()を呼ぶのをやめ、外から渡すようにした（DIパターンの適用）
  2. その渡す型を具体型からインターフェースに変えた（抽象化）

実体を外部から渡すようにし（決定を遅延させ）、かつ抽象(インターフェース)に依存させます

// 1. 抽象（インターフェース）を定義 
// 呼び出し側が必要とする振る舞いだけを定義します
type UserRepository interface {
    Save(ctx context.Context, user *User) error
    FindByID(ctx context.Context, id string) (*User, error)
}

type CreateUserUseCase struct {
    repo UserRepository // 抽象（インターフェース）に依存させる
}

// 2. パラメータを明示的にし、インターフェースで受け取る 
func NewCreateUserUseCase(repo UserRepository) *CreateUserUseCase {
    return &CreateUserUseCase{repo: repo}
}

何が起きるのか

  • 依存先がインターフェースになったことで、「本番ではMySQL」「テストではMock」「将来はFirestore」 という選択肢（オプション）が手に入る
func TestCreateUser(t *testing.T) {
    // インターフェース満たしていれば何でもいいのでMockを渡せる
    mockRepo := &MockUserRepository{}
    uc := NewCreateUserUseCase(mockRepo)
}

一見すると単なるDI（依存性の注入）の話に見えますが、経済的な視点で見ると意味合いが変わります。
この「整頓」という小さなコストを払うことで、将来発生するかもしれない「DB移行」や「テスト環境構築」という巨大なコストを回避する権利（オプション） を安価に購入したことになるのです。

なぜ「整頓」がアーキテクチャになるのか？

先ほどのGo言語の例で行ったのは、単なる「リファクタリング」や「お掃除」に見えるかもしれません。
しかし、『Tidy First?』の理論を照らし合わせると、これが Gregor Hohpe 氏の語る「アーキテクチャ」そのものであることが分かります。

  1. コストの正体
    Cost(ソフトウェア) ≒ Cost(変更) ≒ Coupling (結合)
    ソフトウェアの生涯コストのほとんどは「変更コスト」であり、そのコストを跳ね上げる主犯は「結合」であるという法則です。

先ほどの Before（暗黙的な依存）のコードは、結合が見えない状態でした。
結合が見えないということは、変更時のコスト予測が不可能（無限大）であることを意味します。
パラメータを明示的にし、インターフェースを切るという「整頓」は、結合をコントロール可能な状態（疎結合）にする行為です。
つまり、コードを綺麗にしたのではなく、「将来発生する莫大な変更コストを、今のうちに削減した」 のです

  1. 可逆性への投資
    第28章「可逆的な構造変更」では、変更の性質について語られています。

ダサい髪型は伸びるが、
ダサいタトゥーは一生もの

構造の変更は一般的に可逆的である。

「オプションを持つ」とは、高コストな「不可逆な決定」を避け、低コストな「可逆的な決定」を積み重ねることで実現されます。

日々の開発でインターフェースを定義するという小さなコスト（可逆的な投資）を払い続けることで、将来「DBを完全に置き換える」という大きな判断（不可逆な決定）が必要になったとき、慌てずに対応できる状態を作る。 これこそが、コードレベルで行う「意思決定の先延ばし（タイムトラベル）」 の実装となるのです。

まとめ

Architecture Conference 2025でGregor Hohpe氏の語っていたオプションに関して、「Tidy First?」に学ぶ、コードベース観点でのオプションの捉え方を解説してみました。

この二つは、抽象度が違うだけで、本質的には同じことを語っています。
巨大な不確実性に立ち向かうための武器は、必ずしも派手で複雑なアーキテクチャ図だけではありません。
日々のコードを整理し、疎結合に保つという、泥臭い「整頓」こそが武器になり得るのです。

まずは手元のコードの依存関係を解消することから始めてみませんか？ それは単なる掃除ではなく、不確実な未来に対して 「オプション(選択肢)」 を確保するための、最もリターンの高い投資活動なのです。

最後に、「Tidy First?」の続編となる「Tidy Together?」が2026年1月に出版されるとのこと。 個人の整頓がチームの戦略にどう繋がっていくのか今後の展開も楽しみです。

［番外編］

技術的な話はここまでにして、当日の写真を何枚か。
コレオグラフィー

  • Keynoteのセッション内容をリアルタイムで図解してセッションが終わると1枚のグラフィックレコードが完成するらしい。すげぇ、、！！

い
Gregor Hohpe氏によるキーノートセッション:
アーキテクト思考 ― チームでより良い技術的意思決定を導くリーダーシップより

  • 地動説(左)と天動説(右)。それぞれの視点でモデル化すると複雑性が異なる

う

  • アーキテクチャは描くものではなくスケッチするのだ
    • 綺麗な図面を作ることが目的ではない
    • 粗くても良いので思考を進めるためにスケッチを使うべき

他にもPMやビジネスサイドとアーキテクチャの関係について、イニシャルDの拓海を例にとり、良いドライバーはエンジンルームについて詳しくなる必要があるみたいな話も。(ペントハウスとエンジンルームを繋げよう的な)

アーキテクチャカンファレンスすごく楽しいイベントで色々と刺激を受けました！また来年も参加できたら良いな〜

dipテックブログ
dipテックブログPublication

ディップ株式会社のテックブログです。

Discussion