システム思考

「何をするとしても、バックログの欠陥数には大差ないだろう。」
マネージャーが我々に言いました。
これは私たちが働いていた、数百人の開発者が関わる15メガSLOCのCとC++で書かれたプロダクトでの話です。
何が起きているのでしょうか？
システム思考が役に立つかもしれません。

小さいグループでは、力の行使は素早く作用し、すぐ内々で理解されますが、大きいグループや大きなシステムでは、そう簡単にいきません。
Gerry Weinberg は、こういった状況下での2つの決定的な要因をこう示しています。

Weinberg-Brooksの法則: 間違ったシステムモデルに基づいて経営陣が行動を起こすことで、他のすべての原因を合わせた数よりも多くのソフトウェアプロジェクトが失敗している。

因果関係の誤謬: すべての事象には原因があり、それが何か特定できる。[Weinberg92]

これらは我々のメンタルモデルがシステムに影響を与えていることを示しています。
この話題は本節の後半で改めて検討します。

1つの問題は、メンタルモデルと仮定から生じる問題です。
もう1つの問題は、スクラムの大規模な採用、リーン思考、そしてアジャイルの原則が、開発グループに限定されていないという点から生じる問題です。

2つ目の問題は、製品管理、予算編成、ベータテスト、ローンチ、そしてガバナンスと人事に関する方針にぶつかります。したがって、大規模なアジャイル採用では、同僚と一緒になって、本格的に混乱しつつある大規模システムの、メンタルモデル、因果関係、フィードバックループ、および制御メカニズム（または制御しているとう錯覚）について効果的に推論できるようにすることが有効です。システム思考は、それらの推論ツールの1つです。

1958年、 Harvard Business Review が “Industrial Dynamics: A Major Breakthrough for Decision Makers,” （ Jay Forrester, MIT Sloan School professor著）を発行しました。
この論文はビジネス教育におけるシステム思考の動きを刺激し、MIT Sloan Management of Schoolはシステムダイナミクスで人々を教育することで有名になりました。システムダイナミクスはより一般的な用語ですが、システム思考の同義語として扱われることがあります。

MITはPeter Senge¹のような他のシステムダイナミクス志向の研究者も魅了しました。

Weinberg-Brookの法則に一致して、Forresterの調査は、ビジネスシステムの動的モデルを与えられ、アウトプットやパフォーマンスを改善するように頼まれた意思決定者が、多くの場合にそれらを悪化させたことを示しました[SKRRS94]。多くの人がシステムを根本的に改善する方法について弱い判断をしており、たいてい間違った「常識」を適用し、長期的なシステム改善をもたらさない「解決策」を実施しています。

大規模開発グループ（システム）の振る舞いがうまく理解されたり、導かれたりしないのはなぜでしょうか？
その答えは、部分的には、LeSSの原理 キューイング理論 で検討されているように、キューと変動要素を持つ確率論的なシステムの動作にあります。
そして、同じ答えが制御理論にもあります。製品開発グループのようなシステムは、複雑な正と負のフィードバックループと非線形の振る舞いを持っています。これらのシステムの振る舞いは私たちの直感に反します。
そして、人という小さな問題もあります。

まとめると、大規模システムの解明や指導に精通していない理由には、以下が含まれます（ただし、これらが全てではありません）。

• システムダイナミクス、フィードバックループ、非線形システムの挙動、職場のシステムにおける意図しない結果、に関する知識の欠如
• 問題の根本的な原因（およびその見つけ方）がわからない
  • 原因は1つではありません; システム思考では、複数の、間接的で、動的な原因が存在すると考えます。
• 暫定的な修正や現地の部門による決定が全体的なパフォーマンスを低下させるかどうかが分からない。またその根拠がわからない。
  
  
  
  

一言でいえば、システム思考が出来ていないからです² 。

これらの理由は、マネジメントとリーンでアジャイルな原則の大規模な採用との交差点で、必然的に発生します。
リーダーシップチームは混乱しつつあるシステムの一部です。もし彼らがシステム思考を適用しなければ、彼らはそれを本当に混乱させるかもしれません—そして良い方法ではありません！

システム思考の知見を要約したものとして、私たちは、The Fifth Disciplineに記述されている
[11 の‘原理’]が好きです。

• 今日の問題は昨日の「解決策」が生み出す。
• 強く押せば押すほど、システムも強く押し返す。
• 振る舞いは良くなる前に悪くなる。
• 安直な脱出法は出戻りになる。
• 治療により元の病気よりも悪くなる場合がある。
• 「早く」は遅くなる。
• 原因と結果は、時空間で密接に関連しない。
• 小さな変化で大きな結果をもたらす事が出来る。しかし、最大のレバレッジを得られる領域は、たいてい、全くの不明瞭である。
• あなたはケーキを持っているし食べることも出来る。ただし、一気にではない。
• 象を2つに分けても、二匹のちいさな象にはならない。
• 責めを負うべきものなどない

トヨタの社内モットーは“良い品、良い考え” です。
システム思考はこの考えを手伝う道具の集合です。

• システムダイナミクスに目を向ける—開発組織は、人と、微妙なフィードバックループや意図しない結果を伴うポリシーによるシステムです。
  • ワークショップで作成された因果関係ループ図を使ってシステムを見て改良することができます
• メンタルモデルに目を向ける— 最適ではない決定の背後にある1つの理由は、誤った仮定と誤った推論です。
  • 因果ループ図と5つの何故がこれらを説明します。
• 個別最適に目を向ける—最適ではない決定のもう1つの原因は部分最適です。リーン思考におけるシステムレベルの目標である 高い士気と高い品質で迅速に価値を提供する ためのグローバル最適化ではなく、個人または部門の観点から「最善」の決定を行います。
  
  
  
  

本節は、システム思考における以下の分野を中心に構成されています。
（1）システムダイナミクス
（2）メンタルモデル
（3）根本原因
（4）局所最適化

システムダイナミクスに目を向ける: イントロダクション

静的複雑度　と　動的複雑度

私たちの多くは、特にエンジニアリングとファイナンスの分野において、静的な細部の複雑さ を習得するための教育を受けています。—情報（要求、財務など）分析と管理のための学習、複雑な構造を単純化するための要素分解、などなど。
これらはつまり、静的要素、情報、または構造的性質の複雑さです。

大規模なソフトウェアシステムは、どうして、欠陥に時間をかければかけるほど、さらに劣化する傾向があるのでしょうか。
アメリカがイラクに侵入したらどうなるでしょうか。
これらの疑問の背後にあるダイナミクスを見ることは、ダイナミクスの複雑さの分析を含みます。

静的詳細教育とは対照的に、私たちの多くは、動的な複雑さ³、特に職場の複雑さを分析することについての正式な教育を受けていません。 Forresterは、複雑なシステムにこの「常識」はあてはまらないことを実証し、フロー図で可視化された動的システムモデルを使用すれば、より優れたシステムダイナミクス思想家になるよう正式に教育することが可能であることを示しました[Forrester61]。

フロー図には、材料、財務、および情報の流れ、ストック（現金や不良数などの数量を含む変数）、意思決定と方針の影響、および因果関係が含まれます。よくある単純化の例は、因果関係とシステム内のフィードバックループに焦点を当てた因果ループ図です[Sterman00]。

似たような表記法がいろいろあります。 それらはすべてストック（変数）、因果関係、そして遅延を示しています。これは効果図と呼ばれます。[Weinberg92]において、これは効果図と呼ばれます。

図式化の第一法則：対話のためのモデル

システムダイナミクスを学ぶツールの1つは、因果ループ図です。チームメイトと、オーバーオールレトロスペクティブの時間にホワイトボードへスケッチしたものが理想です。先へ進む前に、図式化の第一法則をみてみましょう。

図式化の主な価値は、作成過程の議論にあります。
—私たちは、対話のためにモデル作成をします。

グループが集まって、因果関係ループ図をホワイトボードにスケッチするとき（これは、図式化で一番重要な、思考と議論のための活動である Valtech India）、一番の価値は図式化によって得られる対話と共有理解です。
見やすい図による可視化は、具体的で明確なアイデア—人々が持つメンタルモデル—を作るために重要です。なぜなら、言葉だけでは曖昧で、誤解を招きうるからです。
ただし、図式自体は、議論を通して得られた学びや理解の修正のあとについてくるものに過ぎません。

具体的なモデリングのヒント：付箋に変数を書き出し、定義することから始めます。 付箋には「ベロシティ」や「欠陥数」などが書かれるでしょう。これらをホワイトボードに貼り付けます。次に、付箋間の因果関係線をスケッチします。モデリングセッション中には、たくさんの書き換え、消去、再描画が行われるでしょう（されるべきです）。 ここで最も意味のある成果は理解です。加えて、ホワイトボードスケッチのデジタル写真を撮りたいという参加者もでてくるでしょう。

システムダイナミクスに目を向ける： 因果関係ループ図

因果的ループ図は、大規模開発で起こっていることのダイナミクスを見るのを助けるための手段として、LeSSの紹介で定期的に使われています。この理由1つとっても、因果関係ループ図を理解する価値があります。そしてより有用にするために、ホワイトボードで仲間と一緒に行うことをお勧めします。
会話をするために図式化を行うのです。
タイミングとしては、オーバーオールレトロスペクティブが良いでしょう。

このヒントの実用的な面は、あなたが思っているよりも重要です。
「システム思考家になろう」と提案するのは漠然としていてインパクトがありません。しかし、あなたと4人の仲間が大きなホワイトボードの前に一緒に立ち、因果関係のループ図を一緒にスケッチする習慣をつければ、 「システム思考家になること」と「システム思考を行うこと」を結び付ける具体的なインパクトある実践となります。

次の例は、本に書かれているだけだと不毛に見えます。しかし、あなたが他の人とホワイトボードの前にいて、活発な会話中に図がスケッチされていたと想像してください。
これこそ、私たちが「考える」システム思考を提案している理由です。

表記法と具体例

因果関係ループ図はたくさんの要素を含みます。
以下のような有用な部品が、シナリオの中で考慮されます。

• 変数
• 因果関係
• 逆効果
• 制約
• 目標
• 反応、その場しのぎの反応
• 相互作用
• 極端な効果
• 遅延
• 正のフィードバックループ

以下の単純化されたシナリオは特定の組織向けです。 これは一般化ではありません。

変数—因果関係ループ図には、ソフトウェア機能のベロシティ（納入率）や欠陥数などの変数（または在庫）が含まれます。 変数は測定可能な量を持ちます。

因果関係—ある要素が他の要素に影響を与える可能性があります。たとえば、ベロシティが増加すると、欠陥数が増加します。 つまり、新しいコードが増えれば、欠陥も増えるのです。

さあ、Weinberg-Brook’の法則と因果関係の誤謬に取り組む時が来ました。
ダイアグラムをスケッチするのは簡単です。何かを洞察力によってモデル化すれば良いのです。
たとえば、開発者数とベロシティの関係を考えてみましょう。

因果関係の本質が実際は明白になっていないにもかかわらず、結論に論理飛躍してしまうことがよくあります。
例えば、「開発者が増えるとベロシティが上がる」などと。
開発の終盤に人を追加すると、ベロシティが「低下」する可能性があります（「Brooksの法則」の一要素[Brooks 95]）。あるいは、ひどいプログラマーがベロシティを低下させるかもしれません。別の論理では、ひどい開発者を削除することで速度を向上させることができると主張することもできます。

反対方向の作用—因果関係の影響は同じ方向でも反対方向でも起こりえます。 Aが上がるとBが上がる、またはその逆です。 反対方向の作用は下図で「O」がついた線で示されています。 問題が発生するとシステムに負荷がかかり、ベロシティが低下すると考えられます。これは、人々がバグの修正や運用対処に時間をかけるためです。

制約 {：style = “color：＃1997C0”} —無料で働く人々を見つけることができない限り、開発者の数は資金供給上の制約があります。
制約は因果関係ではありません。 現金供給が増えるにつれて、開発者の数が増えるわけではありません。

目標と反応 {：style = “color：＃1997C0”} — 人、部署、システムにはベロシティ向上などの目標があります。 目標は、目標達成に向けた反応（または行動）を強いるプレッシャーを生み出すことがよくあります。 しかし、因果関係の誤謬とWeinberg-Brooksの法則があるので、どのような行動が役立つのかを推測することに慎重になるべきです。 目標と目標達成のためのプレッシャーについて以下に示します。

報酬を持つ目標は行動するプレッシャーを生み出すだけでなく、行動し達成しているように見せるというプレッシャーを生み出します。これは報酬によって生じる測定機能不全が原因です。 そして人々は、システムを改善するのではなく、報酬を得るように動機付けられているので、測定機能障害は報酬の大きさ（知覚される価値）に比例することがあります[Austin96]。報酬が実際にシステムパフォーマンスを低下させる可能性があることに注意してください。 視覚的には、システムダイナミクスは次のようになります。

これらすべてのダイナミクスが報酬の導入によって追加されていることは非常に興味深いことですが、それでもこのモデルの上部と下部の間に必要な関連はありません。
実際に取り組んだところで、ベロシティが向上する保証はないのです。

報酬システムを削除することは、機能障害に対する根本的な解決策です。 もう1つの（より小規模な）表面対策は、リーンシンキング 現地現物（実際の現場を物理的に見に行く）の原則と管理者の行いです。

手っ取り早い対応（Quick-fix）—ベロシティ向上という目標に対する、困難で遅い解決策の1つは、優れた開発者を雇うこと、既存のスタッフの指導と教育を増やすこと、そして質の悪い開発者を排除することです。 代替案はQuick-fixと呼ばれ、迅速かつ少ない労力で目標を達成することが期待される反応です。 Quick-fixが短期的、長期的、両方の側面でうまく機能し、システムが本当に強化されることもあります。 そうでない場合もあります。「急がば回れ」という場合です。
たとえば、開発者の数を増やすと機能の速度が上がると人々は信じているとします。 すると彼らはそれによってより多くの開発者を雇うことが速度問題を最も早く、そして容易に解決すると期待するでしょう。 「QF」はQuick-fixを示します。

相互作用の効果 {：style = “color：＃1997C0”} —雇用には現金供給の制約があります。 困難で遅い解決策の1つは、より多くの現金を得ることです。 より迅速な解決策は、非常に安価な開発者を雇うことです。 この場合、資金供給のレベルは、他の因果関係との相互作用効果を持ちます。 資金不足は雇用率を高める圧力があるとき、非常に安価な開発者の雇用率を上げる傾向があります。

資金供給から非常に安価な開発者の雇用率に直接（反対の）因果関係を描くことができますが、これは現金の減少が非常に安い開発者のより多くの雇用につながることを意味してしまいます。 これは私たちが言いたいことではありません。 むしろ、相互作用の効果を示したいのです。その効果Aは効果Bに影響を与えます。これは、因果関係リンクが別の因果関係リンクに入ることを示すことによって行われます。
具体例： 資金供給から「非常に安い開発者の採用率へ至るQFの線」への因果関係：

極端な効果 {：style = “color：＃1997C0”} —私たちは優れたスキルを持った非常に安価な開発者と、ひどいスキルの非常に高価な開発者と仕事をしてきました。しかし、一般的には、安い開発者の集合から開発者を雇うとき、雇われる開発者の平均スキルレベルは低くなる傾向があります。 このモデルでは、非常に安い労働力を雇ったことが低スキル開発者の数に与える影響は、平均よりもはるかに大きい効果であることを示したいと思います。

モデルで極端な効果を示すには、太い線を使用します。

遅延 {：style = “color：＃1997C0”} —ソフトウェア開発における雇用の問題の1つは、プログラマの差異が軽度であることの誤謬 — （生産性、コード品質などの点から見た）プログラマの差異は比較的小さいという誤った考えです。 しかし、研究上は、上位4分の1は、下位4分の1より、平均4倍の差があることが示唆されています[Prechelt00]。
また重要なこととして、COCOMOモデルは、大規模な縦断的研究に基づいて、開発担当者の能力が生産性にとってはるかに重要な要素であることを示しています[Boehm00]。
そして、平均して、非常に低スキルのプログラマーは、質の悪いコード（貧弱なデザイン）とより多くの欠陥を作成し、システムに新たな足枷を生み出します。

しかし、これらの作用が及ぼす効果はすぐには明らかになりません。
たとえば、多くの弱いプログラマーを雇ってから、ますます多くの悪いコードやデザインの影響が感じられるようになるまでには、比較的長い時間がかかります。 同様に、（プログラマによる差異の強い影響による）ベロシティの減少はすぐには現れません。

モデル内でこれらの遅延効果を表示するには、効果の線を通る二重線を使用します。

遅延は、システム内の教育または是正力に興味深い影響を及ぼします。 影響や意図しない結果が大きく遅延して発生すると、その影響（痛みや増加）を感じず、AがBにどんな影響を与えたか、あるいはもっと微妙にAに影響を受けたBがAにどんな影響を与えたかがわからなくなります。

正のフィードバックループ—
負または正のフィードバックループ⁵と遅延は、物事がシステム内でより微妙になり始めるきっかけです—そしてシステムを理解するきっかけでもあります。
たとえば、どのようにしてより良いプログラマーになるのでしょうか。 一つには、偉大なプログラマーから指導を受け、偉大なコードの例をたくさん見ることです。しかし、熟練度の低い開発者が多数いるオフィスでは、優れたコード例はそう多く生成されていません。また、メンターとしての役割を果たすことができる、数少ない優れたプログラマーを引き寄せ、留めることもできません。彼らはどこか他のところで働きたがるでしょうから。

今や開発グループは自己補強的な下方スパイラル—一連の正のフィードバックループに入り始めています。 幸いなことに、減少傾向は現金の供給によって制約されます。
もっと偉大なプログラマー—すばらしいコードを作成し、他の人を指導することができる人—が去ったとします。
すると、参考にしたり学習したりするためのコードの質が低下しています。 低スキルのプログラマーの割合はさらに大きくなり、ベロシティはさらに低下します。 コードは煩雑になり、扱いにくくなり、冗長で迷路のようになり、機能を迅速に実装する能力が低下します。 ベロシティが低下しているので、安いプログラマをさらにたくさん雇うことへ、より多くのプレッシャーが発生します。 これらすべてがシステム内に複数の正のフィードパックループを生み出します。

ヒント：「偶数個」の「反対」の効果関係を持つサイクルを見つけることで、正のフィードバックループを見つけることができます。 上記のモデルにいくつか具体例があります。

結論

具体例としたシナリオは以上です—因果関係ループ図は職場のシステムに置ける多様なダイナミクスを視覚化できます。これらは、グループでホワイトボードを囲みながら作ることが多いです。

メンタルモデルに目を向ける

前述の因果関係ループ図は、人々の因果関係の精神的モデルを反映していますが、これは間違っている可能性があります。 興味深いのは、人々の因果関係のモデルは、システム内の適時性（遅れ）とフィードバックの質によって影響を受けるということです。

「メンタルモデル」は、私たちのメタ認知スキルを向上させることを意図していますです。メタ認知スキルとは、自身で仮定した内容や推論の連鎖を精査したり、疑問に思ったりするためのスキルです。 私達は、誤った論理の飛躍を引き起こして無いでしょうか？ また、同僚のメンタルモデルについて話し合うために他の人と協力する（責めるのではなく問かける）ことも意味します。

これらのメンタルモデルを知ることが最初のステップです。
変更することは、より難しい次のステップです。 その方法論はこのページの範囲を超えています、LeSSの採用を成功させるためには多くのグループの間でマインドセットの変化が必要となります。

システムダイナミクスの中で戦い抜くことが出来るメンタルモデル（信念、推論の連鎖など）をよく知るためのヒントは、モデリングワークショップで次の質問をして、答えをスケッチすることです。
「このモデルの背後にある仮定について話しましょう。 私たちをここに導いた事実や影響に関して、私たちは何を信じて、あるいは想定しているのでしょうか？」

答えはホワイトボード上で、モデルの中に書き込みます。

具体例： 急がば回れ

Quick-fix、遅延、正のフィードバックループ、およびメンタルモデルを踏まえて考えると、Quick-fixの結果として、短期的にはある変数に明らかな改善が見られるが、その後、まったく同じ変数が悪化していく点は興味深いことです。—「急がば回れ」。 これは職場で頻繁に見られる事象であり、弱点となりえます。そのため、これについては別のモデル化を行う価値があります。

Microsoft Wordの物語と 秘密の開発者ツールボックス：短期間の「改善」が長期的には「劣化」になる典型的な例は、Microsoft Word for Windowsの最初のリリースの話です[[Spolsky04]]（http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software） 。
Wordは望まれた時期の数年後にリリースされました。
なぜかというと、マネージャがスケジュールの遵守を目指し、開発者もスケジュール遵守を推進したためです。

この物語は、希望的観測がリーン思考における無駄の1つとみなされる理由を示しています。
この場合は、スケジュールに（見かけ上）合致しているとみなす希望的観測と、開発者の見積もりを（見積もりではなく）コミットメントとみなす希望的観測です。—これはシステムの劣化を推進する、よくある神話です。

[次のモデル]（＃figure-1）は、管理者が当初スケジュールに従うよう強要したとき何が起きたかと、短期的には速度改善につながるように見えた、開発のスピードダウンに対するQuick-fixが、長期的には開発を更にスピードダウンさせたのは何故かをまとめて描写しています。
スケジュール遵守のプレッシャーと秘密のツールボックスのダイナミクスを以下に示します。
これまでに展開されたダイナミクスのいくつかは意図的に省略しましたので、スケジュール遵守のプレッシャーと秘密のツールボックスに関する深いダイナミクスに着目してください。

手っ取り早い解決策として、Microsoftの管理者たちは、Wordの開発者たちに元のスケジュールを守るように勧め、（将来的な報酬で）買収し、そして脅迫しました。 その結果、管理者の期待に反して、開発者は見かけ上機能を早く提供したことにするために、彼らの秘密の開発者ツールボックス —ダーティコードでなんとかする奥の手（テストなし、レビューなし、既知の問題の無視、コピーペーストプログラミング、貧弱なデザインなど）を引き出しました。おわかりのように、開発者たちもまた、自分たちの問題に対してQuick-fixで対応したのです。

この戦術は魔法のように働いたようです。 マネージャが開発者を圧迫すればするほど、開発者は秘密のツールボックスを多様するので、「機能」がより早く提供されました。これは「開発者を圧迫することは問題解決の助けになる」という信念を強化しました。 しかし、この見かけ上の加速は、実際には開発をスピードダウンするという遅延効果を持っていました（これについてはあとで検討します）。 経営陣は秘密のツールボックスの遅延効果をすぐには理解できず、またマネージャがソースコードを詳細に見たり、自分自身をマスタープログラマーにしたりすべきではないと考えていたので、彼らはこの力学から何も学びませんでした。

システムダイナミクスを詳しく調べると、長期的に見たときにこれらのスピードダウンが何故起きたのかと、最初のWord for Windowsリリースが何年も遅れていた理由がわかります。

当然、汚いコードがたくさんあると、開発はスピードダウンします。 さらに、開発者は増え続ける未解決の不具合のバグリストを無視し、代わりに新しい機能を生成します。 これは、欠陥の作成と修正の間に大きな遅延をもたらしました。 この遅延は、長期にわたるバグの複合的な悪影響（たとえば、回避策や相互影響など）のため、および開発者が関連するコードの詳細なコンテキストを長い間に忘れてしまい、そのコンテキスト—しかも汚くて厄介なコードに囲まれたコンテキストを、じっくりと再認識する必要があるために、欠陥修正の所要時間を大幅に増やします。

鋭い読者はまた、劣化サイクルを強化するいくつかの正のフィードバックループに気付くかもしれません。 これは、製品のリリースが意図したより何年も遅れた理由の1つです。

これらに対する解決策は、リーン思考における立ち止まって直すと現地現物の原則です。 まず問題があるときに解決を急がせるのではなく、管理者は人々がじっくりとシステムのダイナミクスと根本的な原因を認識するよう勧め、開発システムを改善するために、それらを修正するための手助けを行います。じっくり取り組むことで、トヨタ—リーン思考の達人—は、世界で最も仕事が早い会社の1つになりました。
第二に、管理者は、現場で何が起こっているのかを知るために実際の職場を見に行くことができます。 ソフトウェア開発の「現場」はコードです。これは、一流のマネージャはコードを頻繁に評価しているマスタープログラマであることを示唆しています。

マイクロソフトの人々は、リリース後まで状況を熟考しませんでした。 彼らがついにふりかえりを実施した結果、欠陥ゼロのポリシーに至りました。つまり、開発中のコードにある既知のバグを修正することが最優先でした。新しい機能のコードを書く前に、既存の欠陥リストをゼロに持っていく必要があったのです。

部分最適に目（と耳）を向ける

「全員が最善を尽くしていますが、システム全体のスループットは低下しています。 どうしてなんでしょう？」
これは、部分最適—個人または部門の意思決定者が、自部門の視点や自己利益のために行う最適化—のパラドックスです。決定を下す当事者は、最善の決定を下していると確信しています。しかし、「最善」はその部分に限った最適化であるため、実際にはシステム全体のスループットが最適化されません。 これは、「サイロ化」、誤解、恐怖、限られた情報、遅れたフィードバック、無知、キャリア思考、暴力、およびその他の一般的な組織学習障害の結果です。

30人程度の小さな製品グループは、多くの無駄や浪費に費やすような時間やお金を持っていません。
しかし、大規模な製品グループ、一元化されたプロセスおよびツールの集合、一元化された「プロジェクト管理オフィス」などを持つ大企業は、部分最適と無駄な営みを芸術的な形にまで高めているようです。 政府の官僚機構はもちろん典型的な例です。 そのため、あなたが大規模なアジャイル採用の案内人としての役割を果たす場合、部分最適に目を向け（または耳を傾け）、対処することは非常に重要です。

たとえば、法務部門および企業のセキュリティ部門は、それぞれの観点から非常に重要と思われるポリシーを整備しています。 知的財産（IP）の喪失を防ぐ目的で、法務部は
「壁に情報を貼り出してはいけません」
と宣言しています。
また、コスト削減の圧力に対応して、施設管理者は次のように述べています。
「壁が汚れたり傷つけられたりしよう、注意しましょう」
したがって、彼らはリーン思考、ビジュアルマネジメント（通常は壁で行われる）の慣行を中止し、有名なイノベーション活動である、グループでのホワイトボード作業を妨げています。

（実際には疑わしいのですが、）法務部門は知的財産の喪失を減らすことに成功することができ、施設管理者は壁をきれいに保つことに成功するでしょう。—その代償に、製品開発グループはイノベーションや協調を妨られますが。
イノベーションや迅速な価値提供のためのツールは許可されていないため、最終的に、保護する価値のあるIPは次第に少なくなっていますが、弁護士は「IPを確実に保護する」というエグゼクティブチームの任務を果たすことに成功しました。 施設警察も壁を綺麗に保ちました。 彼らは最善を尽くしたのです。

以下は、壁を使ったビジュアルマネジメントを許可していない組織の施設警察が送付した実際の電子メールの引用です。 これを推進する部分最適とメンタルモデルを認識できますか。

*個人用パーティションの中は自由にできます。 ただし、パーティションよりも明らかに高いもの、またはオフィス環境の調和を損なうものは制限されています。

ソフトウェアツールを他の人たちのために選ぶ中央集権化されたグループにおける局所的最適化を見てみましょう。 一般的な考え方では、顧客に価値を届けるスループットの高速化という大局的なゴールを達成できるツールより、
想定されるコストを最小限に抑えるのに最適なツール（不思議なことに、無料のオープンソースツールを推奨することはめったにありません）、
何か複雑なことをするのに最適なツール、
特定の専門職が使うのに最適なツール（たとえ皆がそのツールを使わなければいけないとしても）、などが選ばれます。

スクラムまたはアジャイルの原則の大規模な採用では、「はい、しかし…」という問題の大部分は、
「はい、しかし…経営報告についてはどうですか？」
のような局所的な最適化の典型例です。
もっと一般的には、「はい、でも… <特別な場合>はどうですか？」です。 それから、ポリシーと施策は、すばやい価値提供に向けた最適化という主目的よりも、むしろ報告自体を目的としたもの、または他の何らかの副次的な目的にあわせたものに歪められます。 時には、**極端な場合や稀な場合に対する局所的な最適化**すら見られます。

たとえば、企業向けに統一ツールを選択する責任を負う人は、複雑でまれなケースのシナリオを提示し、それに合うツールを選択します。95パーセントのケースにおけるスピードと利便性のための最適化を行う代わりに、5パーセントのケースに対する部分最適化を行うのです。

他の局所的な最適化は新しい働き方の無知によるものです。これは大規模製品グループで特に一般的です。たとえば私たちは、ヨーロッパの大規模ネットワーキング製品グループがスクラムを採用し、継続的に製品を統合、構築、および自動テストするCIシステムと組み合わせた継続的統合（CI）の実践に取り組むことを支援しました。

しばらくして、外部の従来の管理者が何が起こっているのかを調べ、統合の方法を変えるべきだと勧めてきました—人間の統合管理者が全てのソフトウェアを手動で統合するための明文化された統合計画がない点、そしてもちろん統合管理者もいなかったからです。
彼らは、（もはや必要とされなくなった）統合マネージャの仕事を中心に「最適化」したいと考えました。 彼らは、自分たちの昔ながらの仕事のモデル全体がCIで排除されたことを理解できませんでした。

このストーリーは、大規模な確立された製品のすべての部門で繰り返されます。手動テスト、独立したアーキテクチャー部門、コンポーネントチームなど、既存の作業方法に関する部分最適化です。大規模スクラムを企業レベルで導入しようとしているコーチには、対処すべき同様の部分最適化思考の山があります。

リーン思考とアジャイルな手法では、焦点は大局的なシステム目標にあります：高品質と高い士気で迅速に価値を提供する—全体最適化です。
この目標に照らして決定を検討するようにしてください。 「全体を最適化する」文化を築くためには、次の質問ですべての決定と方針に挑戦してください。

この決定または方針は、外部の顧客に迅速に価値を提供することに焦点を合わせているのか、それとも部門、個人、内部方針/慣行、またはレアケースの利益に焦点を当てているのか

LeSSでは、プロダクトオーナーは、持続可能なペースと高い技術品質を維持しながら、（Sprintの最後に）潜在的に出荷可能な製品を作り上げ、望ましい影響を最大化し顧客を喜ばせる高価値目標を選択する責任があります。
その明確な目標は、システムを局所的な最適化ではなくグローバルな最適化に向けることを意味します。

結論

自分自身でシステム思考の実践者になることに加えて、他の人にもこのトピックについてもっと学ぶことを勧めてください。 システム思考の実践者であることと実際にシステム思考をしていることが職場で結びつくように、ホワイトボードで同僚と因果関係ループ図を描くことを試みることをお勧めします。

参考図書

• W. Edwards Deming’s Out of the Crisis は間違いなく最もよく知られているシステム思想家と品質の専門家によるマスターワークです。 それは控えめな目標、「この本の目的はアメリカの経営のスタイルの変革です。それは基礎から全く新しい構造を必要とします」で始まります。また、Demingは深遠な知識システムを提唱します。（1）システムがあることを感謝する。（2）共通原因と特殊原因の変動を理解する（待ち行列理論は変動に関連する）。（3）知識の限界と推論の誤りを理解する。（4）信頼できる心理学および社会調査の結果を知って、行動または動機付けに関連する政策が「常識」に基づかないようにする。この本は、数字や数値目標による管理の排除、主観による管理の排除、新しいリーダーシップなどを含む、有名な「管理のための14のポイント」を中心にしています。」
• Jay Forrester’s Industrial Dynamics はシステムダイナミクスに関する古典的なテキストです。 1960年代初頭に書かれましたが、それは今日出版されたものと遜色ありません。 因果関係のモデル化だけにとどまらず、システム内の情報、資金、およびマテリアルのフローと在庫もモデル化します。 この本には正式な数学的モデリングが含まれていますが、これはシステムのダイナミクスを理解するために必須ではありません。
• Weinberg’s Quality Software Management: Systems Thinking と An Introduction to General Systems Thinking も有用です。システム開発の経験が豊富なコンサルタントの観点から書かれています。
  
  
• Senge’s The Fifth Disciplineは、システム思考（第5の分野）を適用するリーダーシップの必要性と、持続可能な素晴らしい企業のためのその他の重要な分野を提唱する古典的なものです。その他には、（1）個人的な習熟度、（2）自分の信念と誤った推論への反省、（3）意味のある共有ビジョンの定義とコミュニケーション、（4）チームが学ぶ能力を持つリーダーが含まれます。本の中で提示されている「アーキタイプ」の概念を—少なくとも最初の数年間は—無視することをお勧めします。これは学習補助として意図されていましたが、基本的[5]なシステムダイナミクスモデリングを学び、適用する営みから人々をそらしてしまう場合があります。 「アーキタイプ」は、本来のシステムダイナミクスの一部ではありません。
  
  
• The Fifth Discipline Fieldbookは多くの実務家やコンサルタントの観点から書かれた、詳細な資料です。
  
• Argyris, Putnam, McLain, Schönによる、組織学習についての文献。 「二重ループ学習」 と 「主張と質問による対話」 を含む重要なコンサート。 Action Science と Organizational Learning を含む古典です。
  
• Society for Organizational Learningを通じて利用可能な出版物やリソース

---

脚注:

1. Sengeは、システムの思考と学習を行う組織に関する「The Fifth Discipline」を、Harvard Business Reviewで、「過去75年間の重要な経営本の1つ」と命名しました。[Senge94]参照。




2. もう一つの理由は、実際よりももっと多くの制御が可能だと思ってしまうことです。 複雑性科学は、準カオス的な社会システムの予測と制御に対する根本的な限界を示唆しています[Stacey07]。これは、本文で言及しない、かなり複雑でやっかいな問題です。




3. マクロ経済学、心理学、社会学、および生物学は、数ある中の例外です。




4. 「基本」とは、簡単で簡単に解決できるという意味ではありません。 たとえば、「動機」と「品質」は基本的な要素ですが、簡単なことではありません。




5. 本書では、このシステムダイナミクスにおける意味ではなく、日常会話におけるフィードバックと同じ意味でフィードバックループを使用することがあります。