BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース レバレッジ・ポイント:システムで介入すべき場所

レバレッジ・ポイント:システムで介入すべき場所

原文(投稿日:2010/07/29)へのリンク

ソフトウェアのアーキテクトや設計者にとっての重要な決断の1つは、望んでいる変更をもたらすために、システムのどこに、どのように変更を入れるのか、ということである。レバレッジ・ポイント は、ミクロな変化がマクロな結果をもたらす場所である。企業は、適切なレバレッジ・ポイントにコンピュータ技術を戦略的に活用することによって、変わることができるシステムである。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において、間違った方法に力を入れられた-削減のみである。このことがあらゆる種類の問題の原因となった。もしおそらく、あることに対しては、コストを増やしていれば、そのような問題は、避けられたであろう。例えば、もっとスキルの高い開発者にもっと高い給料を払っていたなら、より少ない人数で充分だった事がわかったりする。

 

システムを設計している時、システムと活用できるレバレッジ・ポイントを理解することは、ソフトウェア アーキテクト、設計者そして開発者のすべてに、絶対必要なことである。

この記事に星をつける

おすすめ度
スタイル

BT