37signals プロダクト開発フレームワーク

無駄なく、官僚主義なく、燃え尽きることなく収益性の高いソフトウェア製品を構築するための完全なシステム。37signals は 15 年以上をかけて、その手法を 3 冊の本に凝縮しました。Getting Real（2006）は「少なく作る」の精神を確立し、Rework（2010）は従来のビジネス通念に挑戦し、Shape Up（2019）はすべてを反復可能な開発プロセスに落とし込みました。これら 3 つは、哲学であり、マインドセットであり、意味のある仕事を予測可能なペースで出荷する小さなチームの方法論を形成しています。

目次

• コアプリンシパル
• スコアリング
• 1. 少なく作る、競合をうならせる
• 2. 仕事の形成
• 3. ベット決定とサイクル
• 4. 小さなチームと実行
• 5. 自分の立場を持つソフトウェアと明確なコミュニケーション
• よくある間違い
• クイック診断
• リファレンスファイル
• さらに読む
• 著者について

コアプリンシパル

少なく作る。 最高のプロダクトは機能が最も多いものではなく、少ない数のことを異常に上手くやるものです。シンプルさは出発点ではなく、到達地点です。

基礎： 従来のプロダクト開発は足す。37signals の流儀は引く。Getting Real は言う：半完成した製品ではなく、完成度 50% の製品を作れ。Rework は言う：デフォルトではほぼすべてに「ノー」と言え。Shape Up は言う：時間を固定し、スコープを柔軟にしろ。3 つはすべて同じ真理に収束する—制約は素晴らしい仕事への障害ではなく、素晴らしい仕事を可能にするものだ。6 週間、3 人、形成されたピッチがあれば、間違ったものを作る余裕はない。必ず本質的なバージョンを見つけなければならない。それが利点だ。

スコアリング

目標：10/10。 プロダクト開発計画、機能スコープ、チームプロセス、またはプロダクト戦略をレビューしたり作成したりするとき、37signals の原則への準拠度に基づいて 0-10 で評価します。10/10 は、固定時間サイクル、形成されたワーク、小規模自律チーム、無慈悲なスコープ削減、自分の立場を持つデフォルト、明確で誠実なコミュニケーションを意味します。スコアが低いほど、機能の肥大化、プロセスオーバーヘッド、または決定の先延ばしを示します。常に現在のスコアと 10/10 に到達するために必要な具体的な改善を提供してください。

• 9-10: 固定時間サイクル、形成されたピッチ、小さなチーム、バックログなし、自分の立場を持つデフォルト、明確なコピー
• 7-8: ほぼ形成されたワークと小さなチームだが、スコープクリープまたは不要なプロセスオーバーヘッドがある
• 5-6: 混在—形成は起こるがバックログが残存、チームが大きすぎる、または優先順位が決定に取って代わる
• 3-4: 重いプロセス（スタンドアップ、スプリント、ストーリーポイント）に時々のシンプルさ努力
• 0-2: 機能工場化、長期ロードマップ、大規模チーム、推定儀式、形成なし

1. 少なく作る、競合をうならせる

コアコンセプト： 意図的な省略を通じた競争優位。少ない機能、少ない優先順位、少ない可動部分。競合と機能ごとに競うのではなく、少なくする—ただしより上手くやる。自分自身が必要とするソフトウェアを作り、深く理解している問題を解く。

機能する理由： 追加するすべての機能に保守コスト、ユーザーへの認知コスト、機会費用がある。ほとんどの機能はユーザーの一部に使われるだけだが、チーム全体が永遠に保守する。少なく作ることで、プロダクトは焦点を保ち、コードベースは管理可能で、チームは小さく保たれる。また、本当に重要なもの—価値の 80% をもたらす機能の 20%—を特定するよう自分たちに強います。

重要な洞察：

• 自分たちが必要な問題を最初に解く—有価値なものを作る最確な方法は自分たちが必要とするものを作ること
• 半完成した製品は不完全な製品より良い—多くのことを悪くやるより少ないことを上手くやる
• 制約を受け入れる—限定的な時間、資金、人材は創意工夫な解決策を強いる
• キュレーター、貯蔵者ではなくあれ—あなたの仕事は良いアイデアに「ノー」と言い、素晴らしいアイデアが息を吸う余地を作ること
• 小さな決定を作る—大きな決定は作るのも戻すのも難しい、小さなものはモメンタムを作る
• 競合をうならせる—彼らがスイスアーミーナイフを作る間、あなたはステーキナイフを作る
• ソフトウェアが少ないほど、保守する、テストする、説明する、そして間違いが起こる余地も少ない
• 変わらないものに焦点を当てる—速度、シンプルさ、信頼性、易用性は決して時代遅れにならない

プロダクト応用：

文脈	応用	例
機能優先順位付け	デフォルト回答は「ノー」	顧客がレポートダッシュボードをリクエスト、代わりにユースケースの 90% をカバーする CSV エクスポートを出荷
**MVP スコープ	痛いところまで切り、さらに切る	バージョン 1 からユーザーアカウントを完全に削除、メールベースのマジックリンクを代わりに使用
競争戦略	上をいくではなく下をいく	競合は 50 個の統合を持つ、あなたは完璧に機能する 3 つを出荷
優先順位排除	理に適ったデフォルトを選ぶ	12 個の通知設定ではなく、1 つの思慮深いデフォルトとオフスイッチで出荷
制約採用	制約を創意工夫の燃料に使う	3 人チームと 6 週間は、動作する最もシンプルなバージョンを見つけることを強制

倫理的境界： 少なく作ることはユーザーに奉仕する必要があり、開発時間を節約するだけではない。複雑さを削減し、アクセシビリティや安全性ではなく。「少ない」は焦点を絞ったこと、放置することではない。

参照：references/build-less.md

2. 仕事の形成

コアコンセプト： 仕事がチームに渡される前に、形成されなければならない。形成とは、仕事を荒い（動く余地がある）、解かれた（主要要素が把握されている）、そして限定的（スコープ限界が食欲で定義されている）にすることを意味する。形成は、素のアイデアとチームプロジェクトの間の重要なステップです。プロダクトと技術的景観の両方を理解している上級者によって行われます。

機能する理由： 素のアイデアはあまりにあいまい—チームは何を作るかを把握するのに時間を浪費する。詳細な仕様は固すぎる—チームはクリエイティブな問題解決の余地なしで ticket-taker になる。形成は甘い蜜を見つける：最大の未知数を削除するのに十分な定義、チームが実装をデザインする自由に十分に。食欲（この問題はどれくらいの時間の価値があるか？）は従来の推定（この解決策はどのくらい時間がかかるか？）に置き換わり、ダイナミクスをオープンエンドな commitment から限定的な投資に反転させます。

重要な洞察：

• 食欲 vs. 推定—解決策がどのくらい時間がかかるかではなく、問題がどのくらいの時間の価値があるかから始める
• Breadboarding は場所、affordance、接続線を使ってフローをマップ—視覚的デザインではなく、構造だけ
• Fat marker スケッチは視覚的詳細についての bikeshedding を防ぐ抽象レベルで描かれる
• ワイヤーフレームはあまりにも具体的すぎて早い—概念が検証される前にピクセルレベルのフィードバックを招く
• 形成されたピッチは 5 つの要素を持つ：問題、食欲、解決策、ウサギ穴、そして no-go
• ウサギ穴はスコープを爆発させる可能性がある既知のリスク—構築の間ではなく、ピッチで対処
• No-go は解決策が何を含まないかを明確に定義—限界を見える化することでスコープ クリープを防止
• Shaper はビルドチームでもマネジメントでもない—両世界をつなぐ上級者

プロダクト応用：

文脈	応用	例
機能デザイン	モックアップの前に breadboard	「ユーザーがチームメートを招待」を Settings → Invite form → Email sent → Accept link → Dashboard としてマップ
スコープ定義	食欲を最初に設定	「これは 6 週間ではなく 2 週間の食欲問題」—適切な解決策をシェイプ
チーム説明	仕様ではなく形成されたピッチを渡す	ピッチには問題、食欲、荒い解決策、ウサギ穴、no-go が含まれる
デザイン忠実度	Fat marker、ピクセルパーフェクトではない	厚いブラシでタブレットにスケッチして抽象を高く保つ
リスク管理	ウサギ穴を事前に呼び出す	「権限モデルは複雑になる可能性がある—v1 では owner/member に限定」

倫理的境界： 形成は正直に仕事を限定する必要があります。チームに圧力をかけるために非現実的に小さい食欲を定義しないでください。食欲は希望される締切ではなく、問題の本物の価値を反映する必要があります。

参照：references/shaping-work.md

3. ベット決定とサイクル

コアコンセプト： バックログと長期ロードマップをベット決定テーブルで置き換えます。上級ステークホルダーは形成されたピッチをレビューし、次の 6 週間サイクルで構築する価値のあるものにベットします。仕事が 6 週間以内に完了しないなら、自動的に続かない—サーキットブレーカーが殺す。サイクル間の 2 週間のクールダウン期間はチームに呼吸の余地を与える。

機能する理由： バックログは永遠に成長し、進捗の幻想を作り、焦点を薄める。ベット決定テーブルは実際の優先順位付けを強制する：6 週間サイクルの限定的なスロットで、形成されたピッチのほんの少しを拾うことしかできない。サーキットブレーカーは士気を低下させ新しいベットをブロックするゾンビプロジェクトを防ぐ。クールダウン期間はチームがバグを修正し、アイデアを探索し、回復する—継続的なスプリントが作る燃え尽きを防ぐ。

重要な洞察：

• バックログは良い意図の墓地—廃止する、アイデアが重要なら戻ってくるだろう
• ベット決定テーブルは各クールダウンの終わりに次のサイクルのために仕事を選ぶために会合
• 6 週間サイクルは有意義な仕事に十分長く、緊迫感を保つのに十分短い
• サーキットブレーカーは交渉の余地なし：6 週間以内に完了しなかったら出荷しない、次のサイクルで再評価
• クールダウン（2 週間）はバグ、探索、小さな改善のための非構造化時間
• 一度に 1 サイクル計画—長期ロードマップは虚偽の commitment を作り、応答性を低減
• 「ノー」と言うことがデフォルト—ほとんどのピッチはベットされない、それは健全
• 変数スコープは、チームが固定の締切に hit するために本質的でないスコープを削減することを意味する、その逆ではない

プロダクト応用：

文脈	応用	例
ロードマップ置換	各サイクルのベット決定テーブル	12 ヶ月ロードマップの代わりに、6 週間ごとに 3-4 個の形成されたピッチを拾う
**プロジェクトスコープ	6 週間最大	複数月プロジェクトではなく、独立した 6 週間ベットに大きなイニシアティブを分割
リスク管理	サーキットブレーカーはゾンビを殺す	機能が 6 週間後 70%？出荷しない。次のサイクルでまだ重要なら再形成と再ベット
キャパシティプラニング	クールダウン期間	サイクル間の 2 週間で技術債、バグ修正、チーム回復
ステークホルダー管理	ベット決定が accountability を作る	上級者がピッチに信頼をベット—見えないバックログシャッフルなし

倫理的境界： サーキットブレーカーは誠実に適用される必要があります。政治的に不便なプロジェクトを殺すために使用しないでください。6 週間制限を使用して持続不可能な圧力を作らないでください。ポイントは焦点、速度ではない。

参照：references/betting-cycles.md

4. 小さなチームと実行

コアコンセプト： 3 人チーム（1 人のデザイナー、1-2 人のプログラマー）は形成されたワークで自律的に動作する。日次スタンドアップなし、pm も hovering、ステータス会議なし。チームは限界を持つ形成されたピッチを受け取り、タスクを自分たちで見つけ出す。進捗は hill charts で追跡される、burndown charts やパーセント完了メトリクスではなく。

機能する理由： 小さなチームはコミュニケーションオーバーヘッドがほぼゼロなので速く動く。3 人は会話ができる、10 人は会議が必要。形成されたピッチからチームが自分たちのタスクを発見するとき、他の誰かが書いたリストを実行するのではなく、問題の本物の理解を開発する。Hill charts は仕事がどこに立っているかの真実を示す—uphill phase（事柄を把握）は不確実性について誠実で、downhill phase（既知のワークを実行）は本物の進捗を示す。

重要な洞察：

• 3 人チームはワークユニット—1 人のデザイナーと 1-2 人のプログラマー
• チームはタスクリストを読むのではなく形成されたピッチを探索することでタスクを見つける
• Hill charts は 2 つのフェーズを持つ：uphill（不確実性、把握）と downhill（確実性、実行）
• スコープはタスクを置き換える—関連する仕事をグループ化して hill 上で独立して移動できる名前付きスコープ
• 会議は有毒—デフォルトで非同期通信を使う、会議を呼ぶ代わりに書き上げ
• Get real：ワイヤーフレームと lorem ipsum ではなく、本物の HTML と本物のデータで早期に作成
• 今すぐ launch、後で iterate—スライドデッキの理論的計画より手で使うソフトウェア
• デザインとプログラミングを初日から統合—handoff なし、「design phase」その後「dev phase」なし

プロダクト応用：

文脈	応用	例
チーム構造	3 人最大	6 週間ベットに 1 人のデザイナー + 2 人のプログラマー、PM ロールは不要
進捗追跡	Hill charts、burndown ではない	「User Invitations」は uphill（権限について把握中）、「Email Templates」は downhill（実行中）
コミュニケーション	非同期優先、書き上げ	30 分の会議の代わりに 5 分の Loom またはライトアップされた update を投稿
デザインプロセス	初日でブラウザーで本物を get する	5 日目の Figma モックアップではなく、2 日目にブラウザーで動作するプロトタイプを構築
タスク発見	従うのではなく team が探索	チームに形成されたピッチを与える、彼らは自分たちでスコープに分割

倫理的境界： 小さなチームはオーバーワークされたチームを意味してはいけない。自律性は、スコープが本物で管理可能であることが必要。3 人チームが一貫して 6 週間の締切に hit するためにオーバータイムで働いているなら、問題は形成にあり、チームにはない。

参照：references/small-teams-execution.md

5. 自分の立場を持つソフトウェアと明確なコミュニケーション

コアコンセプト： 素晴らしいソフトウェアはユーザーのために選択肢を作り、優先順位に埋めない。すべての優先順位はチームが作出できなかった—またはしなかった決定。明確で誠実な copywriting は同じ哲学を反映：あなたが意味することを言い、buzzwords をスキップし、ユーザーの時間を尊重。あなたが知るすべてをオープンに教える。

機能する理由： あまりにも多くの優先順位を持つソフトウェアは意見を持たないソフトウェア。ユーザーは 47 の設定を望まない、箱から出すとすぐに上手くいくソフトウェアを望む。ユーザーのための決定を作るとき（理に適ったデフォルトを拾う）、認知負荷を減らし、より首尾一貫した経験を作る。同じがコミュニケーションに適用：明確なコピーは信頼を構築し、marketing-speak は erode。そしてあなたのメソッドをオープンに教える（37signals が本とブログでするように）あなたの価値を共有する顧客を引き付ける。

重要な洞察：

• すべての優先順位はあなたがユーザーに押しつけている決定—最高のデフォルトを拾い出荷
• Marketing に聞こえるなら、書き直す—明確で誠実な言語が buzzword を上回る
• Epicycle（前の機能で作られた問題を修正するための機能を追加）は複雑さを複合
• ほとんどの機能リクエストに「ノー」と言う、良いものさえ—「not now」は有効で健全な回答
• 変わらないもの焦点：速度、シンプルさ、信頼性、易用性
• 競合を上回り教える—あなたの哲学、プロセス、知識をオープンに共有（本、ブログ投稿、ツール）
• あなたの by-product を販売—構築の間に学ぶこともは他の人に有価値（本、ブログ投稿、ツール）
• あなたのアプリインターフェース copy はあなたの最良のマーケティング—すべてのラベル、エラーメッセージ、確認は信頼を構築するチャンス

プロダクト応用：

文脈	応用	例
機能リクエスト	デフォルト回答は「ノー」	「提案ありがとう。今のところこれを計画していません。」—謝罪なし、promise なし
UI copy	平易な言語、buzzword なし	「Your asset has been successfully persisted to the cloud」ではなく「Your file is saved」
優先順位	削除、デフォルトを選ぶ	タイムゾーンセレクターを削除、ブラウザーから検出。テーマピッカー削除、1 つの良いテーマを出荷
エラーメッセージ	誠実で助けになる	「An unexpected error occurred」ではなく「We couldn't send that email. Check the address and try again.」
ドキュメンテーション	オープンに教える	あなたがどう構築するか、何を決定したか、なぜ—競合がそれを読んでも
マーケティング	誠実で、あなたの哲学を共有	「Basecamp は誰のためではない。誰のためで誰のためではないか。」

倫理的境界： 立場を持つことはユーザーのニーズを無視することを意味してはいけない。ユーザーが何に苦しむかを慎重に聞き、思慮深くキュレーション。立場を持つとは、あなたが見方を持つこと—フィードバックを無視することではない。

参照：references/opinionated-software.md、references/ux-ui-copy.md

よくある間違い

間違い	失敗する理由	修正
バックログを保持する	バックログは永遠に成長、進捗の幻想を作る、焦点を薄める	バックログを廃止、各サイクル形成されたピッチにベット
推定を作る食欲を設定する代わり	推定はアクセス可能な時間に成長し、時間をめぐる交渉を招く	食欲を始める：「この問題はどのくらいの時間の価値があるか？」
形成の前にピクセルパーフェクトモックアップ	あまりにも具体的すぎて早い、bikeshedding を招き創意工夫な探索を殺す	Breadboard と fat marker スケッチを正しい抽象レベルで使用
6 週間サイクルを延長	ゾンビプロジェクトは士気を低下させ、新しいベットをブロック、チームに締切は偽りを教える	サーキットブレーカー適用：6 週間以内に完了しなかったら出荷しない
優先順位の代わりに優先順位を追加	すべての優先順位は複雑を加える少数を奉仕するすべてのユーザーに、時間とともに複合	最高のデフォルトを拾い出荷、データが大多数のデフォルトが失敗したのを示す場合のみ再検討
日次スタンドアップとステータス会議	Maker flow を中断、reporting overhead を作る、チームを遅くする	Hill charts で可視性と非同期 update でコミュニケーションを使用
良い機能リクエストに「イエス」と言う	良い機能もまだ複雑さを加える、ほとんどはコアジョブに本質ではない	デフォルトで「ノー」、このサイクル最も重要なことだけにベット
1 サイクル以上先を計画	長期計画は古い commitment になる、学ぶものに応答性を低減	一度に 1 サイクル計画、新しい情報に応答的になる

クイック診断

質問	ノーなら	アクション
この仕事に固定時間制約はあるか？	スコープは無限に拡大する	開始前に 6 週間食欲を設定
仕事は形成されたか（荒い、解かれた、限定的）？	チームは mid-build でスコープ問題を発見する	ピッチを形成：問題、食欲、解決策、ウサギ穴、no-go を定義
2-3 人のチームはこれを実行できるか？	大きすぎる、分解が必要	各独立した scoped ピースが小さなチームに fit する独立した scoped ピースに分割
少なくとも 5 つのもについて「ノー」と言ったか？	おそらく構築しすぎ	ベット決定テーブルをレビューして無慈悲に削減
チームは自分たちのタスクを把握しているか？	Micromanaging、チームは empowered ではない	Task list ではなく形成されたピッチを hand off
Hill charts で進捗を追跡しているか？	False precision が本物の不確実性をマスク	Hill charts に switch：uphill（把握）vs downhill（実行）
このサイクル後のクールダウンはあるか？	チームは burn out、cleanup 時間なし	サイクル間 2 週間の非構造化時間をスケジュール
あなたのソフトウェアはこの機能について明確な立場を持つか？	優先順位を通じて決定を deferring	最高のデフォルトを拾い設定を削除

リファレンスファイル

• references/build-less.md — 少なくの哲学：競合を underdo、制約を embrace、キュレーション対蓄積、スコープ削減の芸術
• references/shaping-work.md — 形成プロセス：breadboarding、fat marker スケッチ、食欲設定、ピッチフォーマット、ウサギ穴の特定
• references/betting-cycles.md — 6 週間サイクル、ベット決定テーブル、サーキットブレーカー、クールダウン期間、なぜバックログは死ぬべきか
• references/small-teams-execution.md — 3 人チーム、hill charts、非同期通信、HTML での get real、launch-first thinking
• references/opinionated-software.md — デフォルト対優先順位、明確な copywriting、機能リクエストに「ノー」と言う、オープンに教える
• references/ux-ui-copy.md — 37signals の UX、UI デザイン、インターフェース copywriting への approach：browser-first デザイン、ビジュアルヒエラルキー、明確なコピールール、空状態、エラーメッセージ、anti-pattern
• references/case-studies.md — 37signals 原則を適用する 3 つのシナリオ：Shape Up を採用、機能 creep を抵抗、ステータス会議を hill charts で置換

さらに読む

• "Getting Real" Jason Fried と David Heinemeier Hansson による
• "Rework" Jason Fried と David Heinemeier Hansson による
• "Shape Up: Stop Running in Circles and Ship Work that Matters" Ryan Singer による
• "It Doesn't Have to Be Crazy at Work" Jason Fried と David Heinemeier Hansson による
• "Remote: Office Not Required" Jason Fried と David Heinemeier Hansson による

著者について

Jason Fried は 37signals の共同創設者兼 CEO で、Basecamp と HEY の背後にいる企業。1990 年代半ばからウェブベースのソフトウェアを構築してきて、穏やかな企業、リモートワーク、プロダクトシンプルさの著名な支持者。Fried は Getting Real、Rework、Remote、It Doesn't Have to Be Crazy at Work を共著。ベンチャーキャピタル、成長至上主義文化、ソフトウェアとビジネス両方の不要な複雑さに対する反逆的なスタンスで知られている。

David Heinemeier Hansson（DHH） は 37signals の共同創設者兼 CTO、そして Ruby on Rails の creator で、これまで作られた最も影響力のあるウェブアプリケーションフレームワークの 1 つ。Rails は Basecamp のコードベースから直接抽出された—37signals の哲学の教科書例は最初に本物のソフトウェアを構築して、次に再利用可能なツールを抽出。DHH は Getting Real、Rework、Remote、It Doesn't Have to Be Crazy at Work を共著。業界の正統性 microservices、TypeScript、クラウドコンピューティング、スタートアップ文化をめぐって正統性に挑戦することで知られている。

Ryan Singer は 37signals の前戦略責任者で、15 年以上プロダクト shaping と Shape Up になった開発プロセス refining に費やした。Basecamp でプロダクトワークをリード経験は、小さなチームを有効にするものと最大自律性のためにワークを構造化する方法に関する一意の洞察を与えた。Singer は Shape Up を自由なオンライン本（basecamp.com/shapeup）として wrote、後で印刷で発行、37signals が年のために慣行していた methodology を codifying。