Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

HDD（仮説駆動開発）

HDD（Hypothesis-Driven Development、仮説駆動開発） は、新しいアイデア・製品・機能の開発を「検証すべき仮説の集合」として捉え、実験を通じて仮説を採択・棄却しながら進める開発手法。要件やバックログ項目を「正しいと決まっているもの」ではなく仮説として扱う点が特徴。

出典・提唱の経緯

用語としての初出は、Jeffrey L. TaylorがDr. Dobb’s（Dr. Dobb’s Journal）に寄稿した記事 Hypothesis-Driven Development（2011年1月13日）と見られる。（drdobbs.comは閉鎖済みのためリンクはWayback Machineのアーカイブ）

Taylorは記事の冒頭でこう述べている。

Looking back over the last several decades in software development, I see several trends converging in Hypothesis-Driven Development (HDD). A hypothesis is just a theory before it’s tested. A hypothesis like a theory should have both explanatory and predictive value. HDD both unifies existing practice and suggests additional areas where the scientific method can be used in product and software development.

Jeffrey L. Taylor, “Hypothesis-Driven Development”, Dr. Dobb’s, 2011-01-13

Taylorの整理では、HDDはゼロからの発明というより、当時すでに存在していた複数の潮流が合流したものとして位置づけられている。

  • テストがプロジェクト終盤だけでなく、ユニットテスト→TDD→BDDという流れでコーディング以前の工程まで広がってきたこと

  • Customer Development（Steve Blank）やLean Startupが、コードを書く前に顧客・課題についての仮説を検証すること

  • Agile開発がステークホルダー間の壁を壊しつつあること

  • リーン生産方式・カンバンに由来するJust-In-Time的な考え方

  • チームがより多様なスキル（対人スキルなど）を持つようになったこと

  • オープンソース（“The Cathedral and the Bazaar”）の広がり

その後、Barry O’Reilly（ブログ記事、2013年10月21日）が「We Believe / Will Result In / We Will Know」というユーザーストーリー形式のテンプレート（後述）を示して実務に広め、Jez Humble・Joanne Molesky・O’Reillyの共著 Lean Enterprise: How High Performance Organizations Innovate at Scale（O’Reilly Media, 2015）で体系的に解説された。現在実務で「HDD」として参照される定義・事例の多くは、Taylorの原論文よりもO’Reilly以降の実務的なテンプレートを指していることが多い。

Thoughtworks Technology Radar でも継続的に取り上げられており、“Hypothesis-driven development” や派生の “Hypothesis-driven legacy renovation” が掲載されている。

なお、思想的な源流にはEric RiesのLean Startup（Build-Measure-Learnループ。書籍化は2011年9月）やSteve BlankのCustomer Development（The Four Steps to the Epiphany, 2005）がある。Taylorの記事はLean Startup書籍の刊行より前に書かれているが、記事中でLean StartupやCustomer Developmentの概念（当時すでにブログ等で広まっていたもの）を明示的に参照しており、これらの実践を「HDD」という名前で統合・命名した最初期の例と考えられる。

HDDの方法

Jeffrey L. Taylorの記事における方法

HDD in Action

  • QA（品質保証）は「仕様という仮説」に対するテストであり、エンドユーザーは「現実に対する仮説」をテストする。だからこそ早期にプロトタイプ等をユーザーに見せて検証すべき

  • Unit Testing → TDD → BDDと、テストがコーディングより前の工程へ移動してきた

  • Customer Developmentの顧客インタビューには技術者も同席すべき（対人スキルが必要）

  • 市場・顧客・利用パターン・コードの振る舞いに関する仮説はすべて書き出し、日付を付け、関係者に可視化する

Getting Started with HDD

  1. 仮説出し：ブレインストーミングで仮説を洗い出し、すべて記録する

  2. 仮説の整理：検証コストと検証しないコストを見積り、優先順位を付ける（検証が高コストすぎる仮説も明文化だけはしておく）

  3. 定性検証：関係者・見込み顧客への聞き取り（数十人規模）

  4. 定量検証：アンケートなど（数百人規模）。ワイヤーフレームやモックアップによるユーザビリティテストも併用

  5. リスク最小化と学習最大化を両立する簡便なテストを使う（雑なポップアップや簡素なアンケートで十分なことも多い）

Staying Hypothesis Driven

  • コードはテスト・プロファイル・変更がしやすい形で書く

  • 本番環境のモニタリング（CPU使用率やトランザクションレートなど）自体もリアルタイムな仮説検証の手段になる

  • 一度正しかった仮説も、市場や技術の変化によって後に反証されうる

  • 反証された仮説への対応がピボットや軌道修正になる

HDDのユーザーストーリー・テンプレート

Barry O’Reillyの記事における方法。

バックログの項目（ユーザーストーリー）を、次のテンプレートで仮説として記述する。

We believe <that doing/building this>
Will result in <this outcome>
We will know we have succeeded when <we see this measurable signal>

例：ホテル予約サイト

We believe that increasing the size of hotel images on the booking page
Will result in improved customer engagement and conversion
We will have confidence to proceed when we see a 5% increase in bookings

仮説として扱うプロセス

Barry O’Reillyの記事での科学的方法の8ステップ

  1. 観察を行う

  2. 仮説を立てる

  3. 仮説を検証する実験を設計する

  4. 成功の指標を定義する

  5. 実験を実施する

  6. 結果を分析する

  7. 仮説を採択または棄却する

  8. 必要なら新しい仮説を立てて再検証する

Connor Mullen, Hypothesis-Driven Development, 2020

Continuous Deliveryとの関係

Thoughtworksは、Continuous DeliveryとHDDを組み合わせることで「動くソフトウェア」と「検証された学び（validated learning）」を進捗の主要な指標にできると述べている。

By combining Continuous Delivery and Hypothesis-Driven Development we can now define working software and validated learning as the primary measures of progress.

How to Implement Hypothesis-Driven Development | Thoughtworks

実務では、A/Bテストや機能フラグ（LaunchDarkly、Optimizelyなど）を使い、仮説ごとに小さくリリース・計測して検証することが多い。

参考

ソフトウェア工学
BDD（振る舞い駆動開発）
ソフトウェア工学
設計（Design）