DHHとは何者か？Ruby on Rails作者の経歴・設計思想・2026年の現在地

DHHは、David Heinemeier Hansson（デイヴィッド・ハイネマイヤー・ハンソン）というひとりの開発者を指す略称です。Ruby on Railsを書いた人物であり、Basecampを運営する37signalsのCTOであり、ル・マン24時間レースでクラス優勝したドライバーでもあります。この記事では、経歴のような人物情報だけで終わらせず、彼が実際に書いたコードの作法、自社インフラで動かした金額、そして2025年以降に起きているRailsのガバナンス論争までを、公式ドキュメント・GitHub API・手元のRails 8.1.3.1での実測から整理します。

まとめ：DHHの要点

先に結論だけ押さえておきます。

• 人物：1979年10月15日コペンハーゲン生まれ。37signalsのパートナー兼CTOで、Railsコアチームには2003年から名前を連ねています。
• 代表作：Ruby on Rails（2004年7月公開）。以降もTurbo、Kamal、Thruster、Omarchyと、自社で使う道具をそのまま公開し続けています。
• 設計思想：Rails Doctrineの9本柱。実務でいちばん効くのは「Convention over Configuration」と「The menu is omakase」の2つです。
• コードの作法：コントローラにはRESTの標準アクション以外を足さず、足したくなったらコントローラを新設する。Rails 8の認証ジェネレータはこの作法をそのまま出力します。
• 現在地：2025年9月にRailsのハードフォークを求める公開書簡が出て、実際にフォークプロジェクト「Amiko」が動いています。ただし2026年8月時点でリリース版はまだ1本もありません。Rails本体の開発は継続中で、最新は2026年7月29日の8.1.3.1です。

ここから、それぞれの根拠を順に見ていきます。

DHHの経歴とRailsコアでの立ち位置

本名はDavid Heinemeier Hansson。英語版Wikipediaの記述では1979年10月15日にデンマークのコペンハーゲンで生まれ、37signalsでは「partner and chief technology officer」を務めています。Railsの公式サイトが掲載しているCoreチーム一覧では、Davidが先頭に並び「Since 2003」と記されています。Rails 1.0どころか、フレームワークが世に出る前からの関与という意味です。

受賞歴は開発者としてのものとレーサーとしてのものが混ざっています。

• 2005年：OSCONでGoogleとO’Reillyによる「Best Hacker of the Year 2005」を受賞
• 2006年：Rails 1.0でJolt Award（product excellence）を受賞
• 2012年：ALMS（American Le Mans Series）のRookie of the yearに選出
• 2014年：ル・マン24時間レースで総合17位、GTE Amクラス優勝

ル・マンには2013年（LMP2クラス2位）と2016年（GTE Amクラス3位）にも入賞しています。プログラマとしての知名度が先にあるため副業の余興と受け取られがちですが、クラス優勝はプロのカテゴリでの結果です。経営者としては、Basecamp共同創業者のジェイソン・フリードとの共著『Rework』『It Doesn’t Have to Be Crazy at Work』でも知られています。発信は個人サイトのdhh.dkと、自社サービスHEY上のブログworld.hey.com/dhhの2か所が中心です。

DHHが世に出した主要プロダクトと公開時期

Railsだけの人ではありません。公開時期で並べると、20年以上にわたって「自社が困ったので作った道具」を公開し続けているのが分かります。Rails以外の初出日はGitHubのリポジトリ作成日です。

いずれもBasecampやHEYの運用で必要になったものを切り出した、いわゆる抽出（extraction）です。Rails自体がBasecampから抽出されて生まれた経緯と同じ作り方を、20年間繰り返しています。個々の仕組みはHotwireとは？TurboとStimulusでJavaScriptを減らす仕組みを解説とThrusterとは？Rails 8のHTTP/2プロキシ設定とKamal 2との役割分担で扱いました。Omarchyは2025年6月の公開から1年強で24,534スター（2026年8月12日時点）に達し、Omarchyとは？Rails開発者DHHが作った「おまかせ」Arch Linux環境｜Mac移行・日本語化で導入手順を解説しています。

Rails Doctrineの9本柱と、現場の判断を変える2本

DHHの思想は公式サイトのThe Rails Doctrineとして明文化されています。柱は9本です。

• Optimize for programmer happiness（プログラマの幸福度を最適化する）
• Convention over Configuration（設定より規約）
• The menu is omakase（メニューはおまかせ）
• No one paradigm（単一のパラダイムに寄らない）
• Exalt beautiful code（美しいコードを称える）
• Provide sharp knives（よく切れる刃物を渡す）
• Value integrated systems（統合されたシステムを重んじる。後述するクラウド脱出やKamalは、この柱をインフラまで延長したものです）
• Progress over stability（安定より前進）
• Push up a big tent（大きなテントを張る）

9本すべてが日々の実装に効くわけではありません。設計レビューの結論を実際に変えるのは、2本目の「Convention over Configuration」と3本目の「The menu is omakase」です。前者はテーブル名やファイル配置を規約に合わせておけば設定を書かなくて済むという話で、規約から外れた瞬間にコード量が増えるという逆向きの圧力としても働きます。後者は「フレームワークが標準構成を選んでおくので、選定に時間を使わずに済む」という設計判断で、Rails 8がSolid Queueや認証機能を標準搭載した理由もここにあります。

一方「Provide sharp knives」は扱いに注意が要ります。Railsはmethod_missingやモンキーパッチのような、切れ味は鋭いが自分の指も切る道具を封じません。8本目の「Progress over stability」と合わせると、Railsは後方互換より前進を選ぶフレームワークだと明言していることになります。長期保守を前提にRailsを採用するなら、メジャー更新に追随する工数を最初から見積もりに入れておくべきです。

DHH流のコントローラ設計：RESTの標準アクションで押し切る作法

「DHH流」と呼ばれる設計作法の中心にあるのが、コントローラをRESTの標準アクションだけで構成するという徹底です。旧来のRails解説では「ルーティングの書き方」として紹介されがちですが、本質はルーティングではなくコントローラの分割方針にあります。

「アクションを足したくなったらコントローラを新設する」本人の言葉

出典はポッドキャストFull Stack Radioの第32回「DHH – Building Basecamp 3 like a Porsche 911」（2015年12月22日公開）です。この回でDHHはこう述べています。

「Whenever I have the inclination that I want to add a method on a controller that’s not part of the default five or whatever REST actions that we have by default, make a new controller!」（標準のRESTアクション以外のメソッドをコントローラに足したくなったら、そのたびに新しいコントローラを作れ）

さらに「Every single time I’ve regretted the state of my controllers, it’s been because I’ve had too few of them.」（コントローラの状態を後悔したときは決まって、コントローラが少なすぎたときだ）とも語っています。多くの開発者が「コントローラが増えすぎるのは設計が悪い兆候」と考えるのとは正反対の立場を、彼は明確に取っています。

memberアクション版とDHH流のroutes出力比較（Rails 8.1.3.1で実行）

差が実際にどう出るのかは、ルーティングを走らせれば数字で分かります。以下はactionpack 8.1.3.1でActionDispatch::Routing::RouteSetを評価したときの生成ルートです。まずresourcesだけを書いた素の状態から。

resources :messages
# => 7アクション・8ルート
GET     /messages              messages#index
POST    /messages              messages#create
GET     /messages/new          messages#new
GET     /messages/:id/edit     messages#edit
GET     /messages/:id          messages#show
PATCH   /messages/:id          messages#update
PUT     /messages/:id          messages#update
DELETE  /messages/:id          messages#destroy

アクションはindex・show・new・create・edit・update・destroyの7つですが、ルートは8本です。updateだけがPATCHとPUTの2本に割り当てられるためで、「7アクション7ルート」と説明している資料は数え方を間違えています。

ここに「記事を公開する」機能を足すとします。素直に書けばmemberでカスタムアクションを追加する方法になります。

resources :messages do
  member { post :publish; post :unpublish }
end
# => 10ルート。MessagesController は 9アクションに膨らむ
POST    /messages/:id/publish        messages#publish
POST    /messages/:id/unpublish      messages#unpublish
（以下、素の8ルートが続く）

DHH流は同じ機能を、専用コントローラのcreate/destroyに割り当てます。

resources :messages do
  resource :publication, only: [:create, :destroy], module: :messages
end
# => 同じく10ルート。ただし MessagesController は7アクションのまま
DELETE  /messages/:message_id/publication    messages/publications#destroy
POST    /messages/:message_id/publication    messages/publications#create
（以下、素の8ルートが続く）

ルート総数は10本で同じです。変わるのはコントローラあたりのアクション数で、前者はMessagesControllerが9アクションを抱え、後者は7アクションのMessagesControllerと2アクションのMessages::PublicationsControllerに分かれます。「公開を取り消す」がunpublishという独自動詞ではなくdestroyになる点が要点で、フィルタやテストの置き場所が標準アクションの規約に乗ります。

Rails 8の認証ジェネレータが書き出す resource :session

この作法はDHH個人の趣味にとどまらず、フレームワークの標準出力になっています。railties 8.1.3.1に含まれる認証ジェネレータの実装で、routes.rbへ書き込まれる行は次の2つだけです。

# railties-8.1.3.1/lib/rails/generators/rails/authentication/authentication_generator.rb
route "resources :passwords, param: :token"
route "resource :session"

生成されるSessionsControllerのテンプレートが定義しているメソッドはnew・create・destroyの3つ、PasswordsControllerはnew・create・edit・updateの4つで、どちらもRESTの標準アクションだけです。resource :sessionが単数形である点にも意味があり、セッションは「ログイン中の自分」というIDを持たない単一リソースとして扱われます。ログインはSessionsController#create、ログアウトはSessionsController#destroyであって、loginやlogoutというアクションは存在しません。bin/rails generate authenticationを叩いた開発者は、意識せずDHH流のコントローラ分割を受け取っていることになります。

この作法が向かないケースもはっきりしています。外部システムからのWebhook受信のように、リソースに対応づけにくいエンドポイントを無理やり名詞に読み替えると、かえって命名が不自然になります。コントローラ数の増加そのものを恐れる必要はありませんが、共通処理をconcernへ逃がし始めたときは設計を疑ってください。この境界はRailsのConcernはアンチパターンか？正しい使い方と乱用を避ける代替設計で詳しく扱っています。

クラウド脱出の実額と、そこから生まれたKamal・Thruster

DHHが2020年代に最も広く影響を与えたのは、フレームワークではなくインフラの主張かもしれません。37signalsはクラウドから自社ハードウェアへ移る「cloud exit」を実行し、その金額を公開しています。

クラウド脱出で実際に減った金額（2023年9月時点）

2023年9月15日付の本人の記事「Our cloud exit has already yielded $1m/year in savings」によると、S3を除いたクラウド支出が月額$180,000から$80,000未満へ、率にして60%下がりました。年間では約$1mの削減にあたります。移行のために購入したハードウェアは約$500,000で、当時の削減ペースなら半年以内に投資を回収できる計算だと書かれています。

同記事は、移行が完了した時点での最終的な削減額を年$2m規模と見込んでいます。ここで注意したいのは前提条件です。37signalsはAurora/RDSやOpenSearchといった高額なマネージドサービスを使っていた側であり、DHH自身が「あなたの環境はそこまで高くないかもしれない」と但し書きを添えています。削減率をそのまま自社に当てはめられる数字ではありません。

Kamal・ThrusterがRails 8の既定構成に入るまで

この主張が単なる評論で終わらなかったのは、移行に必要な道具を自分たちで書いて公開したからです。任意のサーバへコンテナを配るデプロイツールがKamal（2023年1月初出、v2.0.0が2024年9月26日）、その前段でHTTP/2終端とアセット配信を担う薄いプロキシがThruster（2024年1月初出）です。この2つは2024年11月7日リリースのRails 8から、新規アプリの既定構成に入りました。rails newが生成するGemfileのテンプレートにはkamalとthrusterが最初から書き込まれ、外すには--skip-kamal／--skip-thrusterを明示する必要があります。「クラウドを出る」という主張と「出るための道具」がセットで提供されている点が、他のクラウド批判との決定的な違いです。

ただし、これを一般化して自社にそのまま当てはめるのは危険です。37signalsはトラフィックが読める自社プロダクトを持ち、専任のインフラ運用者を抱え、データベースの物理運用を引き受ける覚悟があります。負荷が季節や施策で数倍に振れるサービス、インフラ担当が兼務1名の組織では、削減額よりも障害対応の人件費と機会損失が上回ります。cloud exitは技術的な正しさの問題ではなく、運用体制を先に確認すべき経営判断です。

2025年以降のガバナンス論争と、Rails採用の判断

2026年時点でDHHを調べると、技術の話と並んでコミュニティの対立が目に入ります。事実関係を時系列で整理します。

2025年9月、DHHが個人ブログに掲載した2本の記事を問題視した開発者たちが、「Plan Vert」と題した公開書簡をGitHubに公開しました（リポジトリ作成は2025年9月22日）。書簡はRailsコアチームとRubyコミュニティに対し、DHHとの関係を断つこと、Railsを別名でハードフォークすること、現代的な行動規範とガバナンスを整備することの3点を求めています。署名は151件に達し、READMEは2026年7月20日にも更新されています。同時期にRuby CentralがRubyGemsの管理権限を維持者へ事前相談なく変更した件も重なり、議論はDHH個人の言動だけでなくエコシステム全体の統治構造へ広がりました。

では実際にフォークは起きたのか。書簡を出したPlan-Vert organization自体には公開書簡しか置かれていませんが、フォークの実作業は別名・別ホストで進んでいます。プロジェクト名は「Amiko」で、コードはGitHubではなくCodebergに置かれています。2026年8月12日時点で公開されているのはガバナンス文書、ADR（設計判断の記録）、公式サイト、そしてexperimental-amiko-core（railtiesの実験的フォーク）を含む6リポジトリです。ただしタグもリリースも1本も切られていません。プロジェクトのガバナンス文書自身が「まだ初期段階で公式な体制はない」と認めており、計画はrailtiesから順に各gemをフォークして改名していく段取りです。

Rails側の開発は止まっていません。8.1.0が2025年10月22日、最新の8.1.3.1が2026年7月29日にリリースされています。運営面では2022年設立のRails Foundationがあり、Shopify、GitHub、1Password、Cookpad、37signalsなど10社がコアメンバーとして資金を出しています。

技術選定の観点では、いま動いているRailsアプリをこの論争だけを理由に他へ移す必要はないと考えます。リリース間隔もセキュリティ修正の提供も継続している一方、Amikoはリリース版を1本も出しておらず、移行先として評価できる段階に達していないためです。判断が分かれるとすれば、技術ではなく組織のスタンスの問題です。特定個人の発信を自社が支持しているとみなされたくないという理由でRailsを避ける選択はあり得ますが、それは可用性やロードマップの評価とは別軸なので、混ぜて議論しないほうが結論を誤りません。Amikoを選択肢に入れるなら、最初の安定版が出て、後方互換の方針とセキュリティ修正の提供体制が文書化された時点が判断のタイミングです。

よくある質問

DHHとは何者ですか？

デンマーク出身の開発者David Heinemeier Hanssonの略称です。1979年10月15日にコペンハーゲンで生まれ、WebアプリケーションフレームワークのRuby on Railsを作りました。現在はBasecampやHEYを提供する37signalsのパートナー兼CTOを務め、Railsのコアチームにも2003年から在籍しています。プログラマ以外の顔として、2014年のル・マン24時間レースでGTE Amクラス優勝を果たしたレーシングドライバーでもあります。

Railsの開発者は誰ですか？

Ruby on Railsを最初に書き、2004年7月にオープンソースとして公開したのがDHHです。自社プロダクトBasecampの開発から共通部分を抽出する形で生まれました。混同されやすいのがプログラミング言語Rubyの作者であるまつもとゆきひろ氏で、こちらはRailsが動く土台の言語を作った別人です。現在のRailsは、DHHを含むCoreチームと多数のコントリビュータによって開発が続けられています。

DHHのブログはどこで読めますか？

公式には2か所あります。個人サイトのdhh.dkと、自社サービスHEY上のブログworld.hey.com/dhhです。技術的な主張やクラウド脱出の会計など、一次情報として引用されることが多いのは後者です。加えてX（旧Twitter）の@dhhでも発信しています。日本語の要約記事を経由すると文脈が落ちることがあるため、金額や仕様を扱う内容は原文にあたることをおすすめします。

DHHが作ったのはRails以外に何がありますか？

JavaScriptを最小限に抑えて画面遷移を高速化するTurbo（Hotwire、2020年12月初出）、コンテナを任意のサーバへ配備するKamal（2023年1月初出）、Rails 8の新規アプリに既定で入るHTTP/2プロキシのThruster（2024年1月初出）、Arch Linuxベースの開発環境Omarchy（2025年6月初出）などがあります。いずれも37signalsの運用で必要になった道具をそのまま公開したもので、Rails本体と同じ「抽出」の作り方をしています。

「DHH」は他の意味で使われることもありますか？

3文字の略称なので、社名や団体名の略記としても使われます。実際「DHHコーポレート」のような社名のつもりで検索して、Railsの人物解説にたどり着くケースがあります。人物のほうを調べたいなら「DHH Rails」または「David Heinemeier Hansson」と入れれば確実に絞り込めます。逆にRuby on Rails関連の文書で単に「DHH」と書かれていれば、David Heinemeier Hansson本人か、彼が提唱した設計作法（DHH流のコントローラ分割など）を指していると読んで差し支えありません。

関連記事

• Omarchyとは？Rails開発者DHHが作った「おまかせ」Arch Linux環境｜Mac移行・日本語化
• Hotwireとは？TurboとStimulusでJavaScriptを減らす仕組みを解説
• Thrusterとは？Rails 8のHTTP/2プロキシ設定とKamal 2との役割分担
• RailsのConcernはアンチパターンか？正しい使い方と乱用を避ける代替設計
• Turboとは？Hotwire・Railsで使う高速化フレームワークの仕組みと導入方法