この記事の要約
- レバレッジポイントはシステム内で小さな変化が大きな影響を生む介入点。環境学者ドネラ・メドウズが1997年に短縮版を発表し、1999年に完全版として体系化12段階で整理しされた
- メドウズは、システムへの介入において注意の90〜99%がパラメータ（数値）調整に向けられていると指摘。プロダクトマネジメントでも、数値調整や機能追加といった表層的な施策に多くの時間が割かれがちですが、フィードバックループ、情報フロー、ルール、目標、パラダイムといった深い層への介入こそが、持続的なプロダクトグロースを生む可能性あり
- 本記事では、レバレッジポイントの12段階を解説し、PdMが「浅い対症療法」から「深い構造変革」へシフトするための具体的な方法を紹介
なぜ「数値をいじっても」プロダクトは変わらないのか？
「課金率を1%上げれば売上が改善する」「リテンション率を5ポイント改善すれば…」。プロダクト開発現場の日々会議では、こうしたパラメータ（数値）調整の議論が往々にして発生します。ただ、数ヶ月後には元の状態に戻り、根本的な改善には至らない。
この現象には、システム思考の観点から説明可能です。システム科学者のドネラ・メドウズ（Donella Meadows）は、1997年に短縮版が発表され1999年に完全版が出版された論文「Leverage Points: Places to Intervene in a System」で、「人々は直感的にレバレッジポイントがどこにあるか知っているが、ほとんどの場合、それを逆向きに使っている」と指摘しました。
https://donellameadows.org/wp-content/userfiles/Leverage_Points.pdf
メドウズによれば、パラメータ調整は最も影響力の低いレバレッジポイントであるにもかかわらず、注意の90〜99%がそこに向けられています。一方で、情報フローの構造、システムのルール、フィードバックループの強度、そして最も強力な「システムの目標」や「パラダイム」といった深い層への介入は、ほとんど試みられていません。
プロダクトマネジメントの文脈でも同じです。機能の追加や削除、価格変更、UI調整といった表層的な対応に追われ、「なぜその機能が必要なのか」「プロダクトが解決すべき本質的な課題は何か」という根本に立ち返る機会を失ってしまいます。
レバレッジポイントとは何か — システム思考の核心概念
レバレッジポイント（Leverage Point）とは、複雑なシステム内で「小さな変化が大きな影響を生む場所」を指す概念です。メドウズはこれを「企業、経済、生態系、都市といった複雑なシステムにおいて、一つのことへのわずかなシフトが、すべてに大きな変化をもたらす場所」と定義しています[1]。
このアイデアは1990年代初頭のNAFTA（北米自由貿易協定）会議での経験から生まれたそう。メドウズは、巨大な新システムが提案されているにもかかわらず、それを管理するメカニズムが極めて不十分であることに気づいたのです。そこで彼女は、システムへの介入ポイントを影響力の順に整理し、12段階のレバレッジポイントを提唱しました[2]。
4つのカテゴリーへの簡略化
後の研究者たちは、メドウズの12段階を4つの領域に集約しています[3]：
| カテゴリー | 説明 | 影響力 |
|---|---|---|
| パラメータ | 税率、価格、在庫量などの数値的調整 | 低い（浅いレバレッジ） |
| フィードバック | システム内の相互作用、強化ループと調整ループ | 中程度 |
| デザイン | 情報フロー、ルール、権力構造、自己組織化能力 | 高い |
| 意図（Intent） | 規範、価値観、目標、パラダイム | 最も高い（深いレバレッジ） |
この4層構造は、PdMが日々の意思決定でどこに時間を使うべきかを示唆しています。表層的なパラメータ調整だけでは、システムの根本的な挙動は変わりません。
12のレバレッジポイント — 影響力の階層を理解する
次に、メドウズが提示した12のレバレッジポイントを影響力の小さい順（12位）から大きい順（1位）まで見ていきましょう。それぞれ、PdMの実務でどう現れるかを具体例とともに解説します[1]。
【低影響層】パラメータ領域
12位：パラメータ（数値）の変更
プロダクトマネジメントでの例：
- 「月額料金を980円から880円に下げる」
- 「プッシュ通知を1日2回から3回に増やす」
- 「無料トライアル期間を7日から14日に延長する」
- 「ボタンの色を青から緑に変える」
なぜ影響力が低いのか：
これらの変更は確かに短期的な数値改善をもたらすかもしれません。でも、「なぜユーザーがそのプロダクトを使うのか」「なぜ離脱するのか」という根本原因には触れていません。価格を下げても、プロダクトが課題を解決していなければ、結局使われなくなります。
メドウズは「パラメータを変更しても、システムが慢性的に停滞している場合、それをキックスタートすることはめったにない」と述べています。数字をいじっても、システムの構造は変わらないからです。
11位：バッファ（安定化ストック）の大きさ
プロダクトマネジメントでの例：
- サーバーの冗長性を高めて、負荷スパイクに耐えられるようにする
- 開発チームのリソース余裕を持たせて、急な仕様変更に対応できるようにする
- 顧客サポートの人員を増やして、問い合わせ急増に備える
なぜ影響力が低いのか：
バッファは短期的な安定性を提供しますが、システムの根本的な挙動は変えません。サーバーを増強しても、プロダクトの価値提供の仕方は変わらない。また、バッファが大きすぎると逆に柔軟性を失い、コストが増大します。
10位：物理的構造
プロダクトマネジメントでの例：
- データベースのスキーマ設計（一度決めると変更が困難）
- アプリのアーキテクチャ（モノリスかマイクロサービスか）
- 組織構造（機能別組織かプロダクト別組織か）
なぜ影響力が低いのか：
物理的構造は一度構築されると変更に膨大なコストがかかります。そのため、レバレッジポイントは「最初の設計段階」にあります。でも、すでに構築されたシステムにおいては、構造変更は現実的ではない。だから「影響力が低い」のではなく、「変更が困難」という意味で低位に位置づけられています。
【中影響層】フィードバック領域
9位：遅延の長さ
プロダクトマネジメントでの例：
- A/Bテストの結果が出るまでに3週間かかる → 意思決定が遅れる
- ユーザーがサポートに問い合わせてから返信までに3日かかる → ユーザーは既に離脱している
- 機能リリースから効果測定まで1ヶ月かかる → その間に状況が変わっている
なぜ遅延が問題なのか：
フィードバックループの応答が遅すぎると、システムは「振動」します。つまり、行き過ぎた対応をして、また逆に行き過ぎて、という繰り返しになります。例えば、サーバー負荷の情報が1時間遅れで届くシステムでは、既に負荷が下がっているのにサーバーを増強してしまい、今度は過剰になる、という事態が起きます。
8位：負のフィードバックループの強度
負のフィードバックループとは：
「目標と現状のギャップを縮める」仕組みのことです。エアコンの温度調整のように、設定温度より高ければ冷やし、低ければ温めるという是正メカニズム。
プロダクトマネジメントでの例：
- 弱いループ：「月次レポートでユーザー満足度を見て、半年後に改善施策を打つ」→ 遅すぎて効果が薄い
- 強いループ：「毎週ユーザーインタビューを行い、翌週には改善をリリースする」→ 素早く是正できる
なぜ強度が重要なのか：
フィードバックループが弱いと、問題が拡大してから気づきます。市場における「価格調整機能」も負のフィードバックループです。価格が高すぎれば需要が減り、安すぎれば需要が増える。この調整が速く正確に働くほど、市場は安定します。
7位：正のフィードバックループのゲイン
正のフィードバックループとは：
「雪だるま式に増幅する」仕組みのことです。ネットワーク効果や口コミ拡散がこれに当たります。
プロダクトマネジメントでの例：
- 良い例：Slackの「チームメンバーが増えるほど価値が高まる」→ 自然と広がる
- 悪い例：「バグが放置される → ユーザーが離脱 → 開発リソースが減る → さらにバグが増える」→ 負のスパイラル
なぜゲインの調整が重要なのか：
正のフィードバックループは、放置すると暴走します。成長が加速しすぎてシステムが崩壊するか、衰退が加速して立て直せなくなるか。だから、このループの「増幅率（ゲイン）」を適切に制御することが重要です。
【高影響層】デザイン領域
6位：情報フローの構造
プロダクトマネジメントでの例：
- before：ユーザーの不満はサポートチケットにしか記録されず、開発チームは見ない
- after：全社Slackに毎日「ユーザーの声」が流れ、全員が目にする → 開発の優先順位が自然と変わる
米国のToxic Release Inventoryが好例です。1986年、政府が工場に排出物の公開を義務付けただけで、罰則なしに1990年までに排出量が40%減少しました[1]。企業が公開情報による「社会的圧力」を感じたためです。
なぜ情報フローが強力なのか：
「誰が何を知っているか」が変わると、人々の行動が自然と変わります。情報の非対称性がなくなれば、意思決定の質が上がります。メドウズは「欠けている情報を追加することは、物理的インフラを再構築するよりも簡単で強力な介入」と指摘しています。
5位：システムのルール
プロダクトマネジメントでの例：
- ルールA：「すべての新機能は役員承認が必要」→ リリースが遅くなる
- ルールB：「影響範囲が小さい機能はPdMの裁量でリリース可能」→ 実験的な試行が増える
あるいは：
- ルールA：「エンジニアは『リリースした機能の数』で評価される」→ 小さな機能を量産する
- ルールB：「エンジニアは『ユーザーが達成した成果』で評価される」→ 本質的な価値に集中する
なぜルールが強力なのか：
ルールは、システム内のすべてのプレイヤーの行動を規定します。メドウズは「ルールを決める権力こそが真の力」と述べています。ルールを変えれば、誰も指示しなくても、全員の行動が変わります。
4位：自己組織化能力
プロダクトマネジメントでの例：
- チームが自律的に新しい開発プロセスを生み出す文化
- ユーザーコミュニティが自発的にプロダクトの新しい使い方を発明する
- 組織が外部環境の変化に応じて、自然と構造を変えていく
なぜ自己組織化が強力なのか：
システムが自ら進化できれば、どんな変化にも対応できます。生物の進化や技術革新が典型例です。自己組織化能力が高いシステムは、予測不可能な環境でも生き残れます。
【最高影響層】意図領域
3位：システムの目標
プロダクトマネジメントでの例：
- 目標A：「MAU（月間アクティブユーザー数）を最大化する」→ とにかく滞在時間を伸ばす機能を作る
- 目標B：「ユーザーが目標を達成するまでの時間を最小化する」→ 早く解決できる機能を作る
この目標の違いは、すべての意思決定を変えます。目標Aなら「もっと見たくなる」機能を、目標Bなら「もっと早く終わる」機能を開発します。
なぜ目標が最強クラスなのか：
目標を変えれば、すべてのフィードバックループ、ルール、情報フローがそれに従って再編されます。企業の「本当の目標」は、言葉ではなく行動に現れます。「顧客第一」と言いながら、実際の目標が「短期的な売上最大化」なら、すべての施策がそちらに向かいます。
2位：パラダイム（思考体系）
プロダクトマネジメントでの例：
- パラダイムA：「機能が多いほど価値が高い」→ 機能追加競争になる
- パラダイムB：「シンプルさこそが最大の価値」→ 削ぎ落とすことに価値を置く
あるいは：
- パラダイムA：「すべてデータで証明しなければならない」→ 測定できるものだけを重視
- パラダイムB：「データとユーザーの声を統合して判断する」→ 数字に現れない文脈も重視
なぜパラダイムが最強なのか：
パラダイムは、システムを生み出す根本的な前提です。「成長は善である」「自然は資源である」といった社会全体の暗黙の了解がパラダイムです。パラダイムが変われば、目標も、ルールも、情報フローも、すべてが変わります。だから最も強力ですが、最も変更が困難です。
メドウズは「パラダイムを変える方法は、古いパラダイムの矛盾や失敗を繰り返し指摘し、新しいパラダイムから自信を持って語り、新しいパラダイムを持つ人々を公の場に配置すること」だと述べています[1]。
1位：パラダイムを超越する力
これは何か：
どのパラダイムも「真実」ではないと理解し、柔軟に視点を変えられる能力です。「データドリブンが正しい」「ユーザードリブンが正しい」ではなく、「どちらも一つの見方に過ぎない」と理解した上で、状況に応じて最適なアプローチを選べる力。
メドウズは「この領域で熟達した人々は、中毒を断ち、喜びに満ち、帝国を倒し、宗教を創設する」と表現しています。つまり、既存の枠組みに囚われず、全く新しい視点を持てる人々です。
実務での意味：
僕たちPdMにとっては、「自分の思考の前提を常に疑う」ということです。「この判断は、どんな前提に基づいているのか？」「その前提は本当に正しいのか？」と問い続ける姿勢が、この最高位のレバレッジポイントです。
PdMが陥る「パラメータの罠」— なぜ数値調整で消耗するのか
システムへの介入において、最も影響力の低い「パラメータ調整」に多くの注意が向けられがちです。プロダクトマネジメントの現場でも同様の傾向が見られます。
典型的なパターン
- 「課金ボタンの色を変えてコンバージョン率を0.5%上げよう」
- 「プッシュ通知の頻度を週2回から3回に増やそう」
- 「価格を10%下げて新規獲得を増やそう」
- 「機能Aを削除して機能Bを追加しよう」
これらは確かに短期的な改善をもたらすかもしれません。でも、システムの根本的な挙動を変えることはできません。なぜなら、これらはすべて「パラメータ（12位）」や「物理的構造（10位）」レベルの介入だからです。
改めてですが、メドウズは「パラメータを変更しても、システムが慢性的に停滞している場合、それをキックスタートすることはめったにない。激しく変動している場合も、安定化させることはできない」と警告しています[1]。
なぜパラメータに執着するのか
パラメーターに執着する理由は明確で、パラメータは目に見えやすく、測定可能で、変更が容易かつ上司への説明もしやすいからです。「KPIを5%改善しました」という報告は明確な数字で示せます。
一方、「情報フローの構造を変えました」「システムの目標を再定義しました」といった深いレバレッジポイントへの介入は、効果の測定が難しく、時間もかかります。そのため、組織は「測定しやすいが影響力の低い」施策に偏ってしまいます。
これは測定至上主義の典型的な罠です。
プロダクトマネジメントにおける深いレバレッジポイントの活用
では、PdMはどのように深いレバレッジポイントを活用すべきでしょうか。具体的な実践方法を見ていきます。
情報フローの構造を変える（6位）
プロダクト開発において、「誰がどの情報にアクセスできるか」は極めて重要です。
実践例1：ユーザーの声を全社に公開する
Slackの#customer-feedbackチャンネルに、毎日のユーザーインタビューのハイライトやサポートチケットの傾向を流します。これだけで、エンジニアやデザイナーがユーザーの痛みを肌で感じるようになり、機能提案の質が向上する可能性があります。
これは「欠けている情報を追加する」という情報フロー変更の典型例です。Toxic Release Inventoryと同様、罰則なしに行動変容を促すアプローチになります。
実践例2：ダッシュボードを民主化する
KPIダッシュボードへのアクセスを一部のリーダーだけでなく、全メンバーに開放します。情報の非対称性がなくなることで、各メンバーが自律的に意思決定できる環境を作れます。
ユーザーリサーチの知見をリサーチデータベースとして蓄積し、誰でもアクセスできる状態にすることも、同じ発想です。
システムのルールを変える（5位）
プロダクト開発の「ルール」とは、意思決定の基準や評価制度、承認プロセスなどを指します。
実践例1：承認プロセスを簡略化する
新機能リリースに役員承認が必須だった場合、このルールを「影響範囲が小さい機能はPdMの裁量でリリース可能」に変更することで、リリース速度が向上する可能性があります。
これは「ルールの変更」という高いレバレッジポイントへの介入です。
実践例2：評価軸を見直す
エンジニアやPdMの評価を「リリースした機能の数」から「ユーザーが達成した成果」に変更すれば、チーム全体の行動が変わる可能性があります。不要な機能開発が減り、本当に必要な価値に集中できる環境を作れます。
システムの目標を変える（3位）
強力なレバレッジポイントの一つです。プロダクトが「何のために存在するのか」を再定義します。
実践例：指標の背後にある本質的な目的を問い直す
多くのプロダクトは「MAU（月間アクティブユーザー数）」や「セッション数」を目標に掲げます。でも、これらは手段であって目的ではありません。
例えば、「ユーザーの滞在時間を最大化する」と「ユーザーの目標達成を支援する」では、目標が異なります。この目標の違いは機能開発の方向性を根本から変えます。前者は「滞在時間を伸ばす機能」を生み、後者は「早く目標を達成できる機能」を生む可能性があります。
プロダクトのコンセプトを見直し、本質的な目標を再設定することは、すべてのフィードバックループ、ルール、情報フローを再編する力を持ちます。
パラダイムを変える（2位）
これは最も困難ですが強力なレバレッジポイントです。組織やチームの根本的な前提を問い直します。
実践例1：「機能は多いほど良い」を問い直す
多くの組織には「機能が多いプロダクトは価値が高い」という暗黙の前提があります。このパラダイムを「シンプルさこそが価値」に転換できれば、プロダクト開発の優先順位が変わる可能性があります。削ぎ落とすことで、本質的な価値に集中できます。
実践例2：「データドリブン」と「ユーザードリブン」の統合
「すべてデータで証明する」というパラダイムと、「ユーザーの声とデータを統合する」というアプローチでは、意思決定の質が変わります。数字では見えない文脈や感情を重視することで、本質的なインサイトが得られる可能性があります。
メドウズは「パラダイムを変える方法は、古いパラダイムの矛盾や失敗を繰り返し指摘し、新しいパラダイムから自信を持って語り、新しいパラダイムを持つ人々を公の場に配置すること」だと述べています[1]。
「浅い介入」から「深い介入」へシフトする実践ステップ
では、どうすれば日々のプロダクト開発で深いレバレッジポイントを意識できるようになるのでしょうか。
ステップ1：現在の介入レベルを診断する
まず、自分やチームが今どのレベルのレバレッジポイントに時間を使っているか確認しましょう。
質問
- 「先週の会議で議論したトピックの80%以上が、数値や機能の話だったか？」→ Yes ならパラメータ領域に偏っています
- 「ユーザーへの情報提供の仕組みや、チーム内の情報共有の設計について議論したか？」→ No なら情報フロー（6位）を見落としています
- 「プロダクトの目標が『売上』『MAU』といった手段レベルで止まっていないか？」→ Yes ならシステムの目標（3位）を再定義すべきです
ステップ2：深いレバレッジポイントへの介入を設計する
現状の課題に対して、複数のレバレッジポイントからアプローチを考えます。
例：「リテンション率が低い」という課題
| レバレッジポイント | 施策例 | 影響力 |
|---|---|---|
| パラメータ（12位） | プッシュ通知の頻度を増やす | 低い |
| 情報フロー（6位） | ユーザーに進捗や成果を可視化する機能を追加 | 高い |
| ルール（5位） | 「継続利用したユーザーだけが得られる特典」を設ける | 高い |
| 目標（3位） | 「滞在時間最大化」から「ユーザーの目標達成支援」に目標を変える | 最も高い |
このように、同じ課題でも複数のレベルからアプローチできます。深いレバレッジポイントほど、持続的で根本的な改善をもたらす可能性があります。
ステップ3：チームでレバレッジポイントの言語を共有する
チーム全体でこの概念を共有することで、意思決定の質が変わります。
「この施策はどのレバレッジポイントに作用するのか？」という問いを会議に持ち込むだけで、表層的な議論から深い戦略議論へシフトする可能性があります。
また、後輩へのレビューでも「この提案はパラメータレベルだけど、情報フローやルールのレベルで考えるとどうなる？」と問いかけることで、構造的思考を育てられます。
レバレッジポイント思考を実践する上での留意点
留意点1：「測定できるもの」への偏重
パラメータは数値化しやすいため、測定・評価が容易です。一方、パラダイムや目標の変更は、短期的な数値では測りにくい側面があります。
でも、「測定しやすい」と「重要である」は別物です。深いレバレッジポイントへの介入は、長期的には大きな影響をもたらす可能性があります。
留意点2：短期的な成果へのプレッシャー
四半期ごとのKPI達成プレッシャーが強い組織では、パラメータ調整に走りがちです。でも、短期的な数字改善だけを追い続けると、システムの根本的な課題は放置される可能性があります。
リーダーは、チームに「深いレバレッジポイントへの投資時間」を確保させることを検討すべきです。
留意点3：複雑さへの対応
情報フローやフィードバックループ、パラダイムといった概念は、パラメータよりも複雑で理解しにくい側面があります。そのため、多くの人は「とりあえず数字をいじる」方に傾きがちです。
でも、複雑なシステムには構造的な思考が必要です。レバレッジポイント思考は、その複雑さに向き合うためのフレームワークになります。
今日から実践できるアクション
- 自分の時間配分を可視化する
今週1週間、自分がどのレバレッジポイントに時間を使ったか記録しましょう。「パラメータ調整」「情報フロー設計」「目標再定義」など、カテゴリーごとに時間を集計します。もしパラメータに80%以上の時間を使っているなら、意図的に深いレバレッジポイントに時間を割り当ててみてください。 - プロダクトの目標を問い直す
あなたのプロダクトは「何のために存在するのか？」を改めて問いましょう。「売上」「MAU」といった手段レベルではなく、「ユーザーのどんな課題を解決するのか？」という本質的な目標を言語化します。この目標をチーム全体で共有し、すべての意思決定の基準にしてみてください。 - 情報の非対称性を減らす施策を一つ実行する
チーム内、または組織内で「情報を持っている人と持っていない人」がいる状況を一つ特定し、それを解消する仕組みを作ります。例：毎週のユーザーインタビューハイライトを全社Slackに流す、KPIダッシュボードへのアクセス権を全メンバーに開放する、など。 - 次の企画書に「レバレッジポイント」の項目を追加する
新機能や施策を提案する際、「この施策はどのレバレッジポイントに作用するのか？」を明記します。複数のレバレッジポイントから検討した上で、最も影響力が高そうな施策を選択してください。 - チームでレバレッジポイントの勉強会を開く
メドウズの論文や本記事を題材に、30分のミニ勉強会を開催します。過去のプロダクト施策を振り返り、「あの施策はどのレバレッジポイントだったか？」「もっと深いレバレッジポイントからアプローチできなかったか？」を議論しましょう。
Q&A
Q1：深いレバレッジポイントへの介入は時間がかかりますが、四半期目標はどうすればいいですか？
A：短期施策と長期施策のポートフォリオを組むことを検討しましょう。全体の70%はパラメータ〜フィードバック領域の短期施策、30%は情報フロー〜目標領域の長期施策に割り当てるといったアプローチが考えられます。深いレバレッジポイントへの投資は、複利のように後から効いてくる可能性があります。
Q2：パラメータ調整は無駄なんですか？
A：無駄ではありません。ただし、それ「だけ」では根本的な改善にならない可能性があるという認識が重要です。パラメータ調整は、深いレバレッジポイントへの介入と組み合わせることで真価を発揮する可能性があります。例えば、プロダクトの目標（3位）を再定義した上で、それに沿ったパラメータ調整（12位）を行えば、両者が相乗効果を生む可能性があります。
Q3：レバレッジポイントの優先順位はどう決めるべきですか？
A：「現状の課題の根本原因がどこにあるか」で決めることをお勧めします。もし課題が「情報の非対称性」なら情報フロー（6位）を、「誤ったインセンティブ設計」ならルール（5位）を、「プロダクトの方向性自体のズレ」なら目標（3位）を優先するといったアプローチが考えられます。深ければ良いわけではなく、課題の本質に合ったレバレッジポイントを選ぶことが重要です。
Q4：組織が「数字で示せ」という文化の場合、どうすればいいですか？
A：深いレバレッジポイントへの介入も、事後的には数値で効果を示せる可能性があります。例えば「情報フローの改善」を実施した後、「リリース速度が向上した」「エンジニアのユーザー理解度が向上した」といった形で成果を可視化することが考えられます。最初から数値化できなくても、実施後に測定すれば説得力が増す可能性があります。
Q5：レバレッジポイント思考は、スタートアップと大企業で違いはありますか？
A：違いがあると考えられます。スタートアップは「パラダイム（2位）」や「目標（3位）」を比較的自由に設定できる可能性がありますが、大企業は既存のパラダイムが強固で変更が困難な場合があります。一方、大企業は「情報フロー（6位）」や「ルール（5位）」に既に多くの仕組みがあるため、それらを改善することで効果を得やすい可能性があります。自分の組織の状況に合わせて、変えやすいレバレッジポイントから手をつけるのが現実的です。
参考情報
主要参考文献
- [1] Meadows, D. (1999). Leverage Points: Places to Intervene in a System. Sustainability Institute. PDF
- [2] Wikipedia. “Twelve leverage points”. Link
- [3] Abson, D. J., et al. (2017). “Leverage points for sustainability transformation.” Ambio, 46(1), 30-39. Link
- [4] Fischer, J., & Riechers, M. (2019). “A leverage points perspective on sustainability.” People and Nature, 1(1), 115-120. Link
- [5] LSA Global. “Strategic Leverage Points for Growth and Execution Success”. Link
関連する実践手法
- Swannell, R. (2021). “A Leverage Points Framework for Systems-shifting product management”. Link
- Chu, B. (2018). “Applying Leverage as a Product Manager”. The Black Box of Product Management. Link
発展的な学習リソース
- Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing. (システム思考の入門書として最適)
- Senge, P. M. (1990). The Fifth Discipline: The Art and Practice of the Learning Organization. (組織におけるシステム思考の古典)
コメント