ソフトウェアのアーキテクトや設計者にとっての重要な決断の１つは、望んでいる変更をもたらすために、システムのどこに、どのように変更を入れるのか、ということである。レバレッジ・ポイント は、ミクロな変化がマクロな結果をもたらす場所である。企業は、適切なレバレッジ・ポイントにコンピュータ技術を戦略的に活用することによって、変わることができるシステムである。ITもまた、レバレッジ・ポイントで重要な変更をすることによって、変化できるシステムである。両方の場合とも、レバレッジ・ポイントを見出し、もたらす変化のタイプと価値を判定することが必要である。
Donella Meadows氏は、Thinking in Systems: A Primerの著者で、ピュリツァー賞にノミネートされ、 MacArthur Foundation から“genius” 賞を受けた。彼女の研究である、レバレッジ・ポイントは、今でも、システムの変化を実現しょうとしている人達にとって、古典的な参考文献と考えられている。 Donella Meadows 氏は、2001年に亡くなったが、レバレッジ・ポイントについての彼女の考えは、The Solutions Journalにまとめられている 。
レバレッジ・ポイントのこの考えは、システム分析にユニークなものではない－ 伝説に埋め込まれている：銀の弾丸、奇跡の解決策、魔法のパスワード、大きな障害を通り抜けるか飛び越えるための、ほとんど苦労の要らない方法である。 我々は、レバレッジ・ポイントが存在することを信じたいばかりでなく、我々は、それらがどこにあるのか、そしてどのように、そこに手を置けばいいのかを知りたい。レバレッジ・ポイントは、力が生まれるポイントである。
Meadows 氏が見出したレバレッジ・ポイントの12のカテゴリを効果が増す順番にリストすると、
- 12. 数字：助成金、税金そして標準のような定数とパラメータ
- 11. バッファ：流れに関連する在庫を安定させるサイズ
- 10. ストックとフロー構造：物理的システムと交差するノード
- 9. 遅延：システム変化の割合に関連する時間の長さ
- 8. バランスをとったフィードバック ループ：是正しようとする影響に関連したフィードバックの強さ
- 7. 強化したフィードバック ループ：駆動ループからの利得の強さ
- 6. 情報の流れ：情報にアクセスできるものとできないものの構造
- 5. ルール：報奨、罰則、制約
- 4. 自己組織化：システム構造に加える、変更する、あるいは、進化させる力
- 3. ゴール：システムの目的あるいは、機能
- 2. パラダイム：考え方からシステム－そのゴール、構造、ルール、遅延、パラメータ － が生まれる
- 1. パラダイムを超えること
経験のあるビジネス マネージャ、ソフトウェア アーキテクトそしてソフトウェア開発者は、自分たちの仕事の中で、これらのレバレッジ・ポイントを認識しているだろう － 特に「数字」。リーン ソフトウェア開発は、11、10、そして9について言いたいことがたくさんあるだろう－不要なあるいは、膨れ上がったバッファの中の無駄、「 ストックとフロー構造」の中のバリュー チェーン、そして押し付けがましい「遅延」に関連した無駄を排除することである。「情報の流れ」を最適化することは、よいビジネスとシステム アーキテクチャの設計に本質的なことである。
「自己組織化」をレバレッジ・ポイントとして理解することは、中心的な課題に繋がる－ そしてリストの4番目で、大変力強い課題－アジリティ、すなわち自己組織化するチーム。実際、アジリティの全体的概念は、2番目のレバレッジ・ポイント－「パラダイム」を活用する 試みと見ることができる。
パラダイムを変えることより、高いレバレッジ・ポイントが、まだある。それは、自分をパラダイムの領域から離し、柔軟であり続け、パラダイムがないのが「真実」だと認識し、 自分の世界観を快く変える人を含んで、一人ひとりは、人類の理解を遥かに超えた、巨大で驚くべき宇宙を非常に限られた理解しかしていない、ということを認識することです。それは、直感レベルでパラダイムが存在するというパラダイムを「理解する」こと、そして、それ自身がパラダイムであることがわかること、そしてその全体の認識を非常におかしく思うことである。それは、知識ではなく、仏教徒が悟りと呼ぶ世界に入っていくことである。
これは、不可思議に聞こえるが －「パラダイムを超えること」は、ソフトウェアの開発にとって無縁なものではない。 Kent Beck氏がeXtreme Programming Explained の第1版で、XPには、3つのステージがある、と書いた：そのまま、適応する、「超える」。
Meadows氏の研究の要約における別の重要な要素は、MITの Jay Forrester氏に由来する：
システムに深く関わっている人々は、しばしば直感的にどこにレバレッジ・ポイントがあるか知っている、大抵、彼らは、間違った方向に変更を入れる。間違った直感のクラシックな例は、...コンピュータ モデルが[認識したのは ]明らかなレバレッジ・ポイント：成長だった。...成長は、利益と共にコストを含む、そして我々は、よくコストを計算しない－ コストには、貧困と飢え、環境破壊などがある－ 我々は、成長で全ての問題を解決しようとしている！必要だったのは、ずっと緩やかな成長、違った種類の成長、そしてある場合にはゼロ成長あるいは、マイナス成長である。
ITやビジネスの世界により近い例は、コストのレバレッジ・ポイントである－「12－数字」の例である。コストは明らかにレバレッジ・ポイントであるが、余りにしばしば、ビジネスとITにおいて、間違った方法に力を入れられた－削減のみである。このことがあらゆる種類の問題の原因となった。もしおそらく、あることに対しては、コストを増やしていれば、そのような問題は、避けられたであろう。例えば、もっとスキルの高い開発者にもっと高い給料を払っていたなら、より少ない人数で充分だった事がわかったりする。
システムを設計している時、システムと活用できるレバレッジ・ポイントを理解することは、ソフトウェア アーキテクト、設計者そして開発者のすべてに、絶対必要なことである。