DHHとRails：慣習がウェブアプリをより早く出荷させた仕組み

なぜRailsはそれ以前より速く感じられたのか

Rails以前、ウェブアプリを作るときは長い「セットアップ税」がかかることが多かった。フォルダ構成を決め（または作り）、URLがコードにどうマップするかを決め、データベース接続を手で配線し、同じ接着コードを何度も書いた。そうした作業は機能を出荷しないが、日数を消費した。

もう一つの足かせは決定疲労だった。ファイル命名、ビジネスロジックの置き場、テストの整理方法といった小さな選択も何度も再交渉しなければならない。これがチームや成長するコードベースに広がると、速度は会議やドキュメント、不揃いなパターンの中で失われていく。

アイデア：選択肢を減らして進捗を増やす

Railsが普及させたのは単純な約束だ：「よくあるやり方に従えば、すべてを設定する必要はない」。これが平たく言うところの「設定より規約」である。

フレームワークにすべての設定を逐一指定させる代わりに、Railsは妥当なデフォルトを仮定する：

• モデル、ビュー、コントローラの予測可能な配置
• 自動的にコードとデータベースのテーブルを結びつける標準的な命名
• 手動の配線を必要としない一般的なURLパターン

フレームワークが既に「あなたの意図」を理解していると、冗長なボイラープレートを書く量が減り、画面が動くところまで早くたどり着ける。

実際に速く感じられた理由

速度は単にコード行数を減らすことだけではない。規約は反復のスピードそのものを変えた：

• より速いスタート：新しいプロジェクトや機能が構造を持った状態で始まる。
• スムーズなチーム作業：見慣れない箇所に飛び込んでも、開発者はどこを見ればいいかがわかる。
• 短い反復ループ：変更がしやすく、アプリが馴染みのある形で整理され続ける。

この記事はその実務的な影響に焦点を当てる—Railsの規約がアイデアから動く機能までの道のりをどう短くしたか。目的は誰かやあるフレームワークを持ち上げることではなく、良いデフォルトがプロダクト作りの摩擦をどう取り除くかを示すことだ。

DHHとRuby on Railsの起源

David Heinemeier Hansson（通称DHH）はRuby on Railsの作成者だ。彼は37signals（現在のBasecamp）で働きながらRailsを作り、2004年にオープンソースとして公開した。この年表は重要で、Railsは白板上の理論から設計されたわけではなく、実際のプロダクトを出荷する日常の圧力によって形作られた。

ホワイトボードではなく実アプリから抽出

RailsはBasecampを構築するための社内フレームワークとして始まった。どのようにウェブフレームワークが「あるべきか」という大きな理論から始めたのではなく、DHHは何度も役立った部分を取り出した：リクエストのルーティング、コードの整理、データベースとのやり取り、HTMLのレンダリング、そして一般的なウェブパターンの処理。

プロダクションのニーズから生まれたため、Railsは定型作業の摩擦を取り除くことに集中した。すべての人にとって万能であろうとしたのではなく、よくあるケースを速くすることを目指していた。

「意見を持つフレームワーク」が意味するもの

Railsはよく「オピニオン化された（意見を持つ）」と表現される。平たく言えば、Railsは構造やデフォルトについてあなたに代わって決定を下す—つまり何をするかを選ぶ手間を減らす。

例えば、それはチームを次のように誘導する：

• 標準的なフォルダレイアウトと命名規則
• データと関係性をモデル化する一貫した方法
• コントローラ、ビュー、ルートの予測可能なパターン

これらの意見は、何かを作る前に行う選択の数を減らす。初期の決定が少ないほど、最初のバージョンを早く作り、反復も速くなる。

コミュニティ効果：共有されたデフォルトと語彙

Railsはコードを公開しただけでなく、ウェブアプリについての共通の話し方を作った。何千ものチームが同じ規約に従うことで、「models」「migrations」「scaffolds」「RESTful routes」といった共通語彙と移転可能なスキルが生まれる。これによりオンボーディング時間が短縮され、助けを見つけやすくなり、「どうやる？」が「Railsには標準がある」に変わる。

設定より規約をシンプルに説明すると

Railsが広めたのは単純な考えだ：一般的なケースに対しては、フレームワークが正しく推測してくれるべきで、あなたがすべてを綴る必要はない。コードの整理方法、コンポーネントの接続方法、データのデータベースへのマッピングに対する妥当なデフォルトが与えられ、異常なケースだけを設定すればいい。

核心の考え：まずデフォルト、次に例外

「設定より規約」とは、Railsが典型的なウェブアプリ（ユーザー、ページ、フォーム、データベーステーブル）を想定し、それぞれに標準的なやり方を提供することを意味する。規約に従えば、構成要素は最小限のセットアップで「自然に揃う」。

これは設定中心のアプローチと異なる。設定中心では、最初のステップがしばしば設定の網を作ることになる：余分なファイル、マニフェスト、あるいは無限のフラグでアプリがすでに暗黙に示すことを記述することに時間を使う。概念的には、構築を始める前にフレームワークに望みを伝える時間が増える。

Railsがあなたのために決める簡単な例

Railsは予測可能な命名と配置で部品を自動的に接続する：

• Article というモデルがあれば、Railsは articles というデータベーステーブルを期待する。
• ArticlesController というコントローラは記事に関連するURLとアクションにマップされる。
• ファイルは app/models/article.rb や app/controllers/articles_controller.rb のような慣れた場所に置かれる。

Railsがどこを見て何と呼ぶかを知っているので、繰り返しの配線を避けられる。仕組みを書くのではなく、機能を書くのだ。

トレードオフ

代償は初期の自由度が少ないことだ：カスタム構造や通常と異なる命名を望む場合は、追加の設定が必要になり（期待に逆らって泳ぐことになる）、手間が増える。利点は速度と一貫性だ—特に複数人が同じコードベースで作業し、共有パターンに依存する場合に有効だ。

RailsのMVCと予測可能な構造の力

RailsはMVCを広い層に普及させたが、それは新しく発明したからではなく、自然に感じられるようにしたからだ。MVCは三つの責任として考えると分かりやすい：

• モデル：アプリのビジネスオブジェクト。データ（多くはデータベース経由）を保持し、バリデーションや価格ロジック、状態変更などの規則を持つ。
• ビュー：ユーザーが見るもの。データをHTML（またはJSON）に変換するテンプレートで、振る舞いよりプレゼンに集中する。
• コントローラ：交通整理役。リクエストを受け取り、必要なものをモデルから取り出し、どのビュー（またはレスポンス）を返すかを決める。

最小限のセットアップでRailsがそれらをつなぐ方法

速度向上は、これらの層を自動的に接続するRailsの規約から来る。PostsController を作れば、Railsは app/controllers/posts_controller.rb に置くことを期待する。Post モデルは app/models/post.rb にある。コントローラのビューは自然に app/views/posts/ に置かれる。

名前と場所が予測可能なため、Railsは多くのことを推測できる：ルートはコントローラアクションにマップし、コントローラアクションはデフォルトで一致するビューをレンダリングし、モデルは慣例的な命名でデータベーステーブルにマップする。振る舞いを上書きすることはできるが、最初からすべてを交渉する必要はない。

予測可能な構造はチームの乗数効果になる

すべてのRailsアプリが似たように整理されていると、オンボーディングが速くなる。仲間はどこにバリデーションがあるか、テンプレートはどこに置くべきか、機能がどう形作られているかを知っている。これにより「このコードはどこ？」という時間が減り、「変更を出荷する」時間が増える。

「fat model, skinny controller」（どこで破綻するか）

一般的な指針は fat model, skinny controller：コントローラをシンプルに保ち、再利用可能なルールをモデルに移す。これはエンドポイントごとのコピペを避けるのに役立つ。

限界として、すべての業務ワークフローが単一のActive Recordモデルに属するわけではない。アプリが大きくなると、モデルがゴミ箱にならないようにサービスオブジェクトやフォームオブジェクトを導入して、モデルの肥大化を防ぎつつコントローラを簡潔に保つことがよくある。

スキャフォールディング：アイデアから数分で動くCRUDへ

Railsのスキャフォールディングは、機能の作業ベースラインを素早く作るためのショートカットだ。１つのコマンドで、Railsはモデル、データベースマイグレーション、コントローラアクション、ルート、基本的なビューを生成してCreate/Read/Update/Delete（CRUD）の動作する部分を作る。結果はスライドやモックではなく、実際にクリックできるアプリの一部だ。

スキャフォールドが実際に提供するもの

スキャフォールドは「退屈だが必要な」部分をつなぎ、素早く学習を始められるようにする：

• あなたが選んだフィールドを持つデータベース対応のリソース
• レコードを作成・編集するフォーム
• レコードの一覧表示や閲覧ページ
• 慣例的なルートとコントローラアクション

初期段階でプロダクトの反復がセットアップ作業で止まることが多いが、スキャフォールディングはそれを回避し、実際のものから学ぶことを可能にする。

スキャフォールドは学習のためのものであり完成品ではない

スキャフォールディングはプロトタイプ生成器として捉えるのが良い。デフォルトのビューは素朴でUXは最小限、コードは一般的な仮定のままになっている。これは欠点ではなく長所で、スキャフォールドを出発点として扱い、これをそのままの「デザイン」にしないよう促す。

健全なワークフローの一例：

1. リソースをスキャフォールドしてエンドツーエンドのループを動かす。
2. 内部でも誰かに触ってもらいフローを検証する。
3. リファクタリング：バリデーション、権限、UI、ビジネスルールを調整する。

注意点：速度は責任をなくさない

生成されたコードはレビューが必要だ。テストを追加し、認可を厳しくし、エラーハンドリングを改善する必要がある。スキャフォールドのページは実用的なので、本当のUX作業（文言、レイアウト、アクセシビリティ、エッジケース）に時間を割く計画が必要だ。スキャフォールディングは最初の草案を加速するが、工学的判断を置き換えるものではない。

ジェネレータとマイグレーション：ワークフローに組み込まれた反復

Railsは理論的に規約を導入しただけでなく、ジェネレータ、マイグレーション、命名ルールを通じて日常作業にそれらを組み込んだ。その結束性が、チームがコードベースをばらばらの一時的決定の山にせずに迅速に反復できる大きな理由だ。

ジェネレータ、マイグレーション、規約を一つのシステムとして

Railsのジェネレータは単に「ファイルを作る」だけではない。期待される場所に期待される名前で期待されるファイルを作る—app/models にモデル、app/controllers にコントローラ、テストは正しいフォルダに、そして重要なのはデータベース構造を更新するマイグレーションを作る。

Railsが User といった命名に依存することで、生成された部品は最小限の追加配線で接続される傾向がある。どこに置くか、何と呼ぶかを決める時間が減り、機能を形作る時間が増える。

マイグレーションは変更を製品の普通の一部にする

マイグレーションはデータベーススキーマをアプリケーションとともに進化するものとして扱う。「データベースは完了、さてコードを書く」という発想の代わりに、Railsは継続的なリズムを奨励する：機能を作り、スキーマを調整し、実際の利用から学び、改善する。

各マイグレーションは小さくタイムスタンプ付きのステップであり、レビュー可能でバージョン管理でき、環境間で再現できる。これによりフィールド追加や制約調整、新しいテーブル導入といった反復的な変更が時間の経過とともにずっと安全になる。

ワークフローの例：フィールドを追加して検証して出荷する

例えばユーザーに role を追加したいとする：

1. 変更を生成：rails g migration AddRoleToUsers role:string
2. 実行：rails db:migrate
3. モデルを更新：User にバリデーション（場合によってはenum）を追加。
4. フォームとビューを調整し、テストを更新してデプロイ。

これが短いループだ：スキーマ変更とアプリケーション変更が一緒に進むので「どのカラムがあるか分からない」やデータのない状態を前提にしたコードが生まれることを避けられる。

規律が重要

速度を持続可能にするためにはマイグレーションをきれいに保つ必要がある：出荷済みの古いマイグレーションを編集しない、可能な限り可逆的な変更を書く、スキーマ変更を本番のコードとしてレビューするなど。Railsは反復を容易にするが、チームは一貫性を守って安全性を保つ。

デフォルトでDRY：ボイラープレートを減らし機能に集中する

「Don’t repeat yourself（DRY）」は一つの知識についてアプリが一つの明確な真実の源を持つべきという単純な考えだ。ウェブアプリでは同じ概念がルート、コントローラロジック、ビュー、データベースクエリなど複数箇所で繰り返されるときに冗長性が忍び込む。

具体的なDRY例：Posts機能

基本的なブログの Post レコードを作るとき、DRYでなければ show、edit、update、destroy に同じ「IDでポストを探す」コードをコピーしてしまうかもしれない。Railsは次のように一つの共通メソッドにまとめることを促す：

before_action :set_post, only: %i[show edit update destroy]

def set_post
  @post = Post.find(params[:id])
end

これがDRYの実践だ：例えば Post.friendly.find に切り替えると、その変更はすべてのアクションに反映される。

Railsの規約がルート、コントローラ、ビューにまたがる重複を削る仕組み

Railsの規約により、異なる層が命名や構造で「合意」するためDRYが容易になる。RESTfulルート（resources :posts）を使うと、Railsは標準的なアクションを持つ PostsController を期待し、ビューは app/views/posts/show.html.erb のような予測可能なパスを探す。

こうした部品が整合するので接着コードが減る。link_to @post.title, @post のようなリンクヘルパーは、Railsがモデルインスタンスから適切なルートを推論できるため機能する。部分テンプレートの命名規約（render @posts）は各アイテムに対して posts/_post を自動的に選べることがある。

DRYのやりすぎは害になることも

DRYを行き過ぎると可読性を損なう：過度な抽象化、メタプログラミング、あるいは「すべてを処理する一つのメソッド」は行数を減らせても理解を難しくする。ビューやビジネスロジックでは少しの繰り返しが最も明確な選択であることもある。目標は保守性であり、最小文字数ではない。

ハッピーパス：デフォルトがプロダクトの反復を加速する理由

Railsは「ハッピーパス」を最適化することで有名だ：典型的なデータベース駆動のウェブアプリを作る最も一般的な方法を想定している。ユーザー、フォーム、バリデーション、CRUD画面、ルート、メール、バックグラウンドジョブ、リレーショナルデータベースを仮定し、それらのフローを滑らかで予測可能にする。

ハッピーパス開発を平たく言うと

ハッピーパス開発とは、通常のやり方を行う時間が大半であり、フレームワークと格闘しないことだ。Order というモデルを名付ければ、Railsは orders テーブルを期待し、ファイルの場所を知り、コントローラ・ビュー・ルートがどのように整合するかを推測できる。すべてを証明するのではなく、よく整った道に従うのだ。

決定疲労を取り除くデフォルト

新しいプロジェクトは初期に無数の決定を迫られる：フォルダ構成、命名、設定スタイル、テストのセットアップ、フォームの扱い、ビジネスロジックの置き場。Railsはこれらの多くにあらかじめ答えを用意する。

これが重要なのは、決定疲労が実在するからだ：小さな選択を重ねるほど動きが遅くなり、仲間があなたのやったことを予測しにくくなる。Railsのデフォルトは十分に良い出発点を作るので、すぐに機能を構築し始め、必要になったときだけカスタマイズすればいい。

より速い実験、より短いフィードバックループ

プロダクトのイテレーションは、より多く（かつ良い）実験を回すことだ：小さな変更を出してユーザーの行動を観察し、素早く調整する。Railsは次のことを容易にすることでそのリズムを支援する：

• 新しい概念をモデル化してアプリに素早く繋げる
• バリデーションやエラーメッセージを余計な配線なしで追加する
• 動作するエンドポイントとページをアプリの残りと一貫して作る

ビルド時間が短ければフィードバックループが短くなり、速度が学習につながる。

ハッピーパスが壊れるとき

Railsのデフォルトは問題がユニークな場合には制約に感じられることがある：専門性の高いドメイン、極端なスケール要件、厳しい規制要件、非標準のデータ保存やワークフローなど。このような場合、規約を曲げるために費やす時間が得る利益を上回ることがある。大事なのはデフォルトが助けているか、意図的にその道から外れるべきかを見極めることだ。

チームの速度：共有された規約が調整コストを下げる

Railsは個々の開発者の速度を上げただけでなく、チーム全体の速度も高めた。「Railsのやり方」とは実際には共有された期待のセットであり：ファイルがどこにあるか、クラスがどう命名されるか、リクエストがコントローラからビューへどう流れるか、データがどうモデル化されるか。多くのプロジェクトが同じパターンに従うと、仲間は構造を解読する時間が減り、機能の出荷に時間を使える。

日常で見る「Railsのやり方」

規約は小さな繰り返しの決定に表れる：

• モデルは app/models、コントローラは app/controllers、ビューは app/views
• 命名が予測可能（PostsController は Post を管理）
• 一般的なアクションのための標準的なRESTfulルート（index、show、create など）
• フォーム、バリデーション、部分テンプレートの慣れたアプローチ

これらはいずれも単独では魔法ではないが、一緒になると「ここではどうやるの？」という会話の数を減らす。

速いオンボーディングと少ないハンドオフ

新しい開発者が参加するとき、Railsの規約は建物の案内表示のように働く：案内を受けずとも必要なものを見つけられる。これによりオンボーディング時間が短縮され、知識が一人に閉じるリスクが下がる。

コードレビューがよくなり、無駄な議論が減る

規約はコードレビューも改善する。レビュワーはフォルダ構成を議論するのではなく、プロダクトロジック、エッジケース、パフォーマンスに注力できる。デフォルトがあると、逸脱するときに理由を示す負担がかかる。

トレードオフ：順応が常に正しいとは限らない

裏返しとして、チームが慣習を習慣的に踏襲してしまう危険がある。異例を正当化するのは健康的だ—特に特殊なドメイン、スケーリングの制約、セキュリティ要件がある場合は—それでも出発点としてRailsのデフォルトを使うのがよい。

バッテリー同梱：統合されたツールがプロダクトを速く出す

Railsはウェブアプリを個別のパーツの寄せ集めではなく、全体のプロダクトとして扱うことで「バッテリー同梱」の評判を得た。ルーティング、テンプレート、バックグラウンド処理、メール、ファイルアップロード、セキュリティのデフォルト、テストといった要素を組み合わせる代わりに、Railsは初日から一緒に動く一貫したツールセットを提供する。

よくあるニーズに対する標準的な解決策

ほとんどのウェブプロダクトは初期に同じマイルストーンを踏む：ユーザーアカウント、フォーム、バリデーション、スキーマの変更、メール送信、エラー処理、信頼できるデプロイ。Railsはこれらの繰り返されるニーズに組み込まれたパターンと妥当なデフォルトで対応する。これによりチームはどのライブラリを選ぶかやその配線方法を悩む時間を減らし、機能の形づくりやUXの磨き込みに時間を使える。

「標準」な道が既に整っていると、出荷はアーキテクチャを毎回発明することではなく、アプリ固有の詳細—モデル、ルール、UI—を埋めることになる。

継ぎ目が少なく、接着コードも少ない

速度は単にツールがあることだけではなく、それらがどれだけうまく噛み合うかによって決まる。混ぜ合わせたセットアップでは、多くの労力が翻訳レイヤーに消える：あるライブラリの設定形式を別のものに合わせる、競合する規約を調整する、ログや計測、エラーハンドリングの重複を解消するなど。Railsはコンポーネントを共有規約で統合することでこうした摩擦を減らす。データ検証、永続化、ビューのレンダリングは一貫したルールに従い、エラーは予測可能に表れ、設定は慣れた場所に収まる。結果として「接着コード」が減り、一度きりの決定が出荷を遅らせ保守性を落とすことが少なくなる。

トレードオフ：フレームワーク全体への影響

密に統合されている反面、アップグレードの影響範囲は広くなることがある。Railsがデフォルトを変えたりアプローチを非推奨にしたとき、アプリの複数部分に注意が必要になる。日常の配達速度と一貫性が時折のアップグレード作業を上回る利益を生むため、多くのチームはこのコストを受け入れているが、計画しておくべき現実的な要因だ。

設定より規約が害になるとき

Railsの規約は近くにとどまれば速度の乗数効果をもたらす。しかし同じ規約は、アプリがフレームワークの想定外の形に曲げられ始めたときには足かせにもなり得る。

規約と戦っているサイン

いくつかの実用的な“煙のサイン”が早い段階で現れる：

• 既定値（オートローディング、語形変換、ルーティングパターン）を常に上書きしている。
• 新しいメンバーが地図なしには推測できないカスタムディレクトリルールを導入している。
• 重いメタプログラミングによりコアの振る舞いが追えなくなっている（「このメソッドはどこで定義されている？」が日常的な疑問になる）。
• 基本的な作業にプロジェクト固有の儀式を覚える必要がある。

こうなると、規約によって節約された時間はオンボーディング、デバッグ、コードレビューのコストとして返ってくることが多い。

パフォーマンスとスケーリング：現実的なトレードオフ

Railsはスケールするが、パフォーマンス作業を魔法のように取り除くわけではない。規約に親和的なコードでもクエリ、キャッシュ、バックグラウンドジョブ、オブジェクト割当てを監視しなければ遅くなり得る。

規約が害になるのは、デフォルトが「常に最適」と仮定してしまう場合だ。例えば、素朴なActive Recordの使い方はN+1クエリを生み、デフォルトのキャッシュ戦略は最も重要なエンドポイントには一般的すぎることがある。スケーリングは測定してから意図的に調整する作業が必要だ。

速い反復は「技術的負債なし」ではない

Railsは素早く出荷して学ぶのを助けるが、速い変更は不整合を蓄積させる：モデルの肥大化、コールバックの連鎖、ビジネスロジックがコントローラに流出するなど。規約は摩擦を減らすが、自動的に境界を厳格に守ってくれるわけではない。

利益を失わずにカスタマイズする方法

意図的にカスタマイズする：

• 小さく可逆的な変更を最初に行い、早期にコア規約を書き換えない。
• リポジトリに短い「我々のRailsアプリの違いはここだ」というメモを残す。
• 境界を明確に保つ（サービスオブジェクト、コンサーン、ジョブ）ので、カスタマイズが全体に漏れ出さないようにする。

目標は柔軟性を確保しつつ「設定だらけ」にならないようにすることだ。

現代的な類似：規約と「バイブコーディング」的デフォルト

Railsは構造を標準化することでチームを加速させた：ものがどこにあるか、何と呼ばれるか、どう接続されるか。今日、同様の速度ダイナミクスはVibeコーディング系プラットフォーム（例：Koder.ai）のような方向でも現れている。ここでの“デフォルト”はフォルダ構成というより、チャットを通じて意図を動くアプリに変える点にある。

Koder.aiはRailsが最適化したのと同じ結果—アイデアから動く機能への短い道のり—を目指している。最初の実装を手で配線する代わりに、会話で望むものを説明するとプラットフォームが実際のアプリ（ウェブ、バックエンド、モバイル）を生成し、Railsのスキャフォールドの後で行うように振る舞い、権限、UXを洗練していける。フィードバックループを短く保ちながら反復できるのが狙いだ。

根底にある教訓は一貫している：初期の繰り返される決定を一度だけ（フレームワークやプラットフォームに）任せると、チームはそのデフォルトの上に構築してより速く動ける。

Railsで構築・反復するための実用的な示唆

Railsは、その規約をプロダクトチームのデフォルトなOSとして扱うと最も速い—すなわちチケットごとに毎回議論する提案群ではなく、勢いを保ちつつ意図的な例外に余地を残す運用をする、ということだ。

規約をうまく使うための経験則

まずはRailsの「期待される」選択（慣例的な命名、標準的なフォルダ構成、RESTfulルート、フォームやバリデーション、バックグラウンドジョブの組み込み方式）に寄りかかれ。

簡単な習慣として、「新しい仲間はこのコードがどこにあってどう振る舞うか予測できるか？」と問う。この答えがイエスなら、おそらく規約に近い運用をしており、将来的な変更コストは低い。

軽量な意思決定フレームワーク

測定可能な必要が出るまでは規約に従うべきだ。「測定可能」は次のようなものを指す：

• 再現・定量化できるパフォーマンスボトルネック
• 繰り返す開発者の痛み（バグやレビューが遅くなるパターン）
• Railsのデフォルト形では表現できない明確なプロダクト要件

これらのどれも指摘できないなら、Rails流を選ぶとよい。システムの理解性を保ち、反復を滑らかにする。

例外は小さく書き残す

どのチームもいくつかの意図的な逸脱を行う：カスタムサービスオブジェクト、代替フォームパターン、特定のルーティング規則、クエリに対する共通のやり方など。

それらを一ページの「チーム用プレイブック」としてリポジトリに残す。含める内容：

• 例外の内容
• いつ使うか（いつ使わないか）
• コードベースの具体例

これが例外の蔓延を防ぎ、新しく入った人が自信を持って出荷できるようにする。

本当の要点

規約は単なるコーディング好みではない。うまく使えばプロダクト戦略の道具となる：意思決定のオーバーヘッドを減らし、フィードバックループを短くし、チームが構造について議論するよりもユーザーから学ぶ時間を増やせる。