37signals-way

37signalsの製品開発フレームワーク

肥大化、官僚主義、燃え尽きることなく、収益性の高いソフトウェアを開発するためのシステムです。3冊の書籍、『Getting Real』（作るものを減らす）、『Rework』（まずは断る）、『Shape Up』（期間を固定し、スコープに柔軟性を持たせる）から要点をまとめています。これを使って仕事を形作り、6週間のサイクルに賭け、小規模で自律的なチームを運営し、予測可能なペースでリリースしましょう。

中核となる原則

作るものを減らしましょう。 優れた製品は、より少ないことを卓越した品質で実現します。シンプルさは目指す先であり、出発点ではありません。従来の開発は機能を追加しますが、37signalsのやり方は削ぎ落とします。製品の半分を作り（中途半端な製品を作るのではなく）、まずは断り、期間を固定してスコープに柔軟性を持たせます。制約があるからこそ、優れた仕事が可能になります。6週間、3人、そして形作られた提案があれば、本質的な形を見つけざるを得なくなります。

スコアリング

目標：10/10。 この原則に照らして、製品計画、機能のスコープ、チームのプロセスを0〜10で評価します。現在のスコアと、10/10に到達するために必要な具体的変更を報告してください。

• 9-10： 期間固定のサイクル、形作られた提案、小規模なチーム、バックログなし、明確な見解を持ったデフォルト、明快な文言
• 7-8： 仕事の大半は形作られ、チームも小規模ですが、スコープの拡大やプロセス上の負担が多少あります
• 5-6： ある程度は仕事を形作っていますが、バックログが残っている、チームが大きすぎる、または意思決定の代わりに好みが使われています
• 3-4： 複雑なプロセス（スタンドアップ、スプリント、ストーリーポイント）があり、ときおりシンプルさを追求しています
• 0-2： 機能量産工場：長期ロードマップ、大規模チーム、見積もりの儀式、仕事を形作るプロセスなし

1. 作るものを減らし、競合より機能を絞る

中核となる概念： 意図的に省くことで勝ちます。機能、選択肢、可動部分を減らし、それぞれを競合より優れた品質で実現します。自分自身が必要とするソフトウェアを作り、深く理解している問題を解決しましょう。

効果がある理由： すべての機能には、保守、認知、機会に関するコストが伴い、それらは永続します。その恩恵を受けるのは通常、ユーザーの一部にすぎません。作るものを減らせば、製品の焦点を保ち、コードベースを管理しやすくし、チームを小規模に維持できます。

主な知見：

• 中途半端な製品より、製品の半分のほうが優れています。多くのことを粗雑に行うより、少数のことをうまく行いましょう
• ため込む人ではなく、キュレーターになりましょう。優れたアイデアを生かすために、良いアイデアは断りましょう
• 小さな決断をしましょう。大きな決断は難しく、覆すのも困難ですが、小さな決断は勢いを生みます
• 競合より機能を絞りましょう。相手にはスイスアーミーナイフを作らせ、自分たちはステーキナイフを作りましょう
• 変わらないもの、つまり速さ、シンプルさ、信頼性、使いやすさに焦点を当てましょう

製品への応用：

文脈	応用	例
機能の優先順位付け	まずは「いいえ」と答える	レポートダッシュボードを求められたら → ユースケースの90%をカバーするCSVエクスポートを提供する
MVPのスコープ設定	痛みを感じるまで削り、さらに削る	v1ではユーザーアカウントをなくし、メールのマジックリンクを使う
競争戦略	超えるのではなく、機能を絞る	競合に50のインテグレーションがあれば、完璧に動作する3つを提供する

何を削るかを決める際は、references/build-less.mdを参照してください。キュレーションの手法、「制約は機能である」という考え方、スコープを削減する具体例が載っています。

2. 仕事の形づくり

基本概念： 仕事がチームに届く前に、プロダクトと技術の両方に精通したシニアメンバーが、仕事を粗く（調整の余地を残し）、解決済みにし（主要な要素を決め）、範囲を限定します（アペタイトに基づいてスコープを絞ります）。

効果がある理由： 生のアイデアはチームの時間を無駄にし、詳細な仕様書はチームをチケット処理係にしてしまいます。形づくりによって、デザインの自由度を残しながら最大の不確実要素を取り除きます。また、「どれだけの時間をかける価値があるか？」というアペタイトによって、「どれくらいかかるか？」という見積もりに代えます。つまり、期限の定まらない約束ではなく、投資範囲を限定します。

重要な洞察：

• 形づくられた提案には、問題、アペタイト、解決策、落とし穴、やらないことの5つの要素があります
• ブレッドボードで、場所、そこでできること、接続を表現します。視覚的なデザインをせずに構造を示せます
• 太いマーカーで描くスケッチは抽象度を高く保ちます。ワイヤーフレームでは、コンセプトの妥当性が確認される前に、ピクセル単位のフィードバックを招いてしまいます
• スコープを膨らませるリスクとなる落とし穴は、構築中ではなく提案の段階で対処します
• やらないことを明示して境界を見えるようにし、スコープクリープを未然に防ぎます

プロダクトへの応用：

文脈	応用	例
機能設計	モックアップの前にブレッドボードを作成	「チームメイトを招待する」：設定 → 招待フォーム → メール送信 → 招待承認リンク → ダッシュボード
スコープの定義	まずアペタイトを設定	「6週間ではなく、2週間をかける価値がある問題」として、適切な解決策を絞り込みます
リスク管理	落とし穴を事前に明示	「権限の扱いが複雑になる可能性があります。v1ではオーナーとメンバーに限定します」

倫理的な境界： 問題に実際に見合う価値を反映したアペタイトを設定します。チームに圧力をかけるために、決して意図的に小さく設定してはいけません。

提案を作成する際は、references/shaping-work.mdを参照してください。5要素から成る提案形式、ブレッドボードの作成例、太いマーカーのルール、落とし穴のパターン表、良い例・悪い例の「やらないこと」、6段階の形づくり手順について説明しています。

3. ベッティングとサイクル

基本概念： バックログやロードマップをベッティングテーブルに置き換えます。シニアのステークホルダーが形づくられた提案に賭け、6週間のサイクルに組み入れます。サイクルの間には2週間のクールダウン期間を設けます。未完了の仕事にはサーキットブレーカーが適用され、自動的に継続することはありません。

効果がある理由： バックログは際限なく増え、進捗があるという錯覚を生み、集中を妨げます。サイクルの枠を限ることで、真の優先順位付けが必要になります。サーキットブレーカーはゾンビプロジェクトを終わらせ、クールダウン期間は休みなくスプリントを続けることによる燃え尽きを防ぎます。

重要な洞察：

• バックログをなくします。アイデアが重要なら、また戻ってきます
• 6週間あれば意味のある仕事に取り組め、締め切りも意識できる長さです
• スコープは柔軟にします。固定の締め切りに間に合わせるために、チームは必須でないスコープを削ります。逆は決してありません
• 一度に計画するサイクルは1つだけにします。長期ロードマップは古びた約束です
• ほとんどの提案には賭けません。それが健全な状態です

プロダクトへの応用：

文脈	応用	例
ロードマップの置き換え	各サイクルで賭ける	12か月のロードマップの代わりに、6週間ごとに形づくられた提案を3～4件選びます
リスク管理	サーキットブレーカーでゾンビを終わらせる	6週目に70％完了？リリースはしません。それでも重要なら、形づくり直して再び賭けます
キャパシティ計画	サイクル間にクールダウンを設ける	バグ、技術的負債、探索、回復のための2週間

倫理的な境界： サーキットブレーカーは誠実に適用します。ゾンビを終わらせるために使い、政治的に不都合なプロジェクトを終わらせるためには使いません。目的は集中であり、持続不可能な圧力をかけることではありません。

ベッティングテーブルを運用したりサイクルを計画したりする際は、references/betting-cycles.mdを参照してください。テーブルでの意思決定方法、6週間と2週間のリズムの組み立て方、サーキットブレーカーの適用方法、バックログに反対する理由について説明しています。

4. 少人数チームと実行

中核となる考え方： 3人（デザイナー1人、プログラマー1〜2人）のチームは、形を整えた企画を自律的に進めます。朝会も、あれこれ口を出すプロジェクトマネージャーもいません。自分たちでタスクを見つけ、ヒルチャートで進捗を追跡します。

うまくいく理由： 3人なら会話ができますが、10人では会議が必要です。形を整えた企画から自分たちでタスクを見つけるチームは、問題への深い理解を身につけます。ヒルチャートは現状を正確に示します。上り坂はまだ模索中、下り坂は把握済みの作業を実行中ということです。

主な知見：

• タスクの代わりにスコープを使います。関連する作業を名前付きのまとまりに分け、それぞれ独立してヒルチャート上を進めます。
• 会議は有害です。その代わりに、文章にまとめましょう。
• 実物を作りましょう。5日目のFigmaモックアップより、2日目に実データで動くHTMLを作るほうが効果的です。
• 今すぐリリースし、後で改善しましょう。計画書より、ユーザーの手元にあるソフトウェアのほうが価値があります。
• デザインとプログラミングは初日から一体で進めます。引き継ぎの段階はありません。

プロダクトへの応用：

状況	応用	例
チーム構成	最大3人、PMなし	6週間の取り組みごとに、デザイナー1人とプログラマー2人
進捗の追跡	バーンダウンではなくヒルチャート	「招待」は上り坂（権限が不明確）、「メールテンプレート」は下り坂（実行中）
コミュニケーション	非同期を優先し、文章にまとめる	30分の会議ではなく、書面での最新情報や5分の動画

倫理的な境界： 自律性を実現するには、スコープが本当に無理のないものでなければなりません。チームが6週間の期限に間に合わせるために恒常的に残業しているなら、チームではなく、スコープの整え方を改善しましょう。

チームが開発の途中にある場合は、references/small-teams-execution.md を参照してください。ヒルチャートの読み方と更新、スコープの分割、非同期コミュニケーションの規範、実際に動くHTMLで形にする方法を説明しています。

5. 明確な選択をするソフトウェアと、明快なコミュニケーション

中核となる考え方： 優れたソフトウェアは、ユーザーを設定項目で圧倒するのではなく、選択を行います。設定項目を追加するたびに、チームができなかった、またはしなかった判断をユーザーに委ねることになります。同じ誠実さは文章にも当てはまります。言いたいことを率直に述べ、流行語を避け、自分たちの知識を惜しみなく教えましょう。

うまくいく理由： 設定項目を増やすたびに、設計、テスト、サポートが必要なプロダクトの状態が増え、適切な判断に必要な背景を持たないユーザーに判断を押しつけることになります。妥当なデフォルト設定は認知負荷を減らし、一貫性を生み出します。明快な文章はマーケティング調の表現が損なう信頼を築き、惜しみなく教えることで、自分たちの価値観に共感する顧客を引きつけます。

主な知見：

• 最適なデフォルトを選んでリリースし、ほとんどのユーザーに合わないことがデータで示された場合にのみ見直します。
• エピサイクル（以前の機能が生んだ問題を修正する機能）は、複雑さを積み重ねます。
• 優れた機能リクエストにも、「今は対応しない」は妥当で健全な回答です。
• 競合以上に教えましょう。副産物（書籍、記事、ツール）を販売しましょう。
• インターフェースの文言は最良のマーケティングです。ラベルやエラーメッセージの一つひとつが、信頼を築くことも損なうこともあります。

プロダクトへの応用：

状況	応用	例
機能リクエスト	まずは対応しない。期待を持たせる約束はしない	「ご提案ありがとうございます。現時点では、対応する予定はありません。」
UIの文言	平易な言葉を使う	「ファイルを保存しました」。 「アセットはクラウドに正常に永続化されました」ではなく
エラーメッセージ	正直で役立つ内容にする	「メールを送信できませんでした。アドレスを確認して、もう一度お試しください。」
設定項目	なくし、デフォルトを選ぶ	ブラウザーからタイムゾーンを検出し、適切なテーマを1つ提供する
マーケティング	誠実な位置づけをする	「Basecampはすべての人に向いているわけではありません。どんな人に向いているのか、向いていないのかをご紹介します。」

機能リクエストへの回答や設定項目の削除については、references/opinionated-software.md を参照してください。インターフェースの文言、空の状態、エラーメッセージを書く際は、references/ux-ui-copy.md を参照してください。

よくある間違い

間違い	うまくいかない理由	修正方法
バックログを維持する	いつまでも増え続け、進捗しているという誤った感覚が生まれ、集中力が分散します	廃止し、各サイクルで形にしたピッチに賭けます
アペタイトを設定せず、見積もりをする	見積もりは時間いっぱいまで膨らみ、交渉を招きます	「この問題にどれだけの時間をかける価値がありますか？」と尋ねます
シェイピングの前にピクセル単位で完璧なモックアップを作る	早い段階で具体的になりすぎ、些末な議論を招きます	まずブレッドボードと太いマーカーで描いたスケッチを使います
6週間のサイクルを延長する	ゾンビプロジェクトによって、チームは締め切りが形だけのものだと学んでしまいます	サーキットブレーカーを設けます。終わっていなければ出荷しません
判断する代わりに設定項目を追加する	一部のユーザーに対応するために、すべてのユーザーに複雑さをもたらします	最適なデフォルトを選び、そのまま出荷します
毎日の朝会や進捗会議を行う	作り手の集中を中断し、報告の負担を生みます	可視化にはヒルチャートを使い、進捗共有は非同期で行います
良い機能リクエストに応える	良い機能であっても、必須ではない複雑さが加わります	まず断ることを基本とし、このサイクルで重要なものだけに賭けます
複数のサイクルを先まで計画する	古くなった約束により、対応力が低下します	一度に1サイクルずつ計画します

簡易診断

質問	いいえの場合	対応
この作業には固定の時間的制約がありますか？	スコープが際限なく拡大します	まず6週間（またはそれ以下）のアペタイトを設定します
作業はシェイピングされていますか（大まかで、解決策があり、範囲が限定されていますか）？	構築の途中でスコープの問題が表面化します	問題、アペタイト、解決策、寄り道、対象外を定義します
2〜3人のチームで対応できますか？	大きすぎます	独立した6週間の賭けに分割します
今サイクルで少なくとも5つのことにノーと言いましたか？	作りすぎています	ベッティングテーブルで容赦なく削ります
チームが自分たちのタスクを決めていますか？	マイクロマネジメントが生じ、チームに権限がありません	タスクリストではなく、シェイピング済みのピッチを引き渡します
ヒルチャートで進捗を追跡していますか？	見せかけの精密さが不確実性を覆い隠します	上り坂（模索中）と下り坂（実行中）に切り替えます
このサイクルの後にクールダウン期間がありますか？	燃え尽きや、片付けの時間不足につながります	サイクルの間に、予定を入れない2週間を設けます
そのソフトウェアには、この点について明確な方針がありますか？	設定項目を通じて、ユーザーに判断を委ねることになります	最適なデフォルトを選び、設定項目を削除します

従うべきモデルが必要な場合は、references/case-studies.md を参照してください。Shape Up の導入、機能の肥大化への抵抗、ステータス会議のヒルチャートへの置き換えなど、最初から最後までの実例を掲載しています。

さらに読む

• "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（Basecamp、HEY）の共同創業者兼CEOであり、落ち着いた企業文化と製品のシンプルさを提唱する第一人者です。David Heinemeier Hansson（DHH） は37signalsの共同創業者で、Basecampのコードベースから生まれたRuby on Railsの開発者です。2人は共に Getting Real、Rework、Remote、It Doesn't Have to Be Crazy at Work を執筆しました。Ryan Singer は37signalsで15年以上にわたり製品のシェイピングに携わり、その手法を Shape Up に体系化しました。