【ブログVol.70】シンプルとは本当はどういうことなのか?

2016年8月25日
/ / /
Comments Closed
Share

Photo taken from underneath the silver "Bean" at Chicago Millenium Park shows abstract reflections in the sculpture.

ゴールドラット博士は、どんな組織もそもそもシンプルでなければならないと仮定しました。この信念は、TOCの4本柱の1本で、私の考えでは最も重要なものです。しかし、それを人間の組織に当てはめようとすると、さらに新しい複雑な理論と正面から衝突します。

注意:この記事では、目標(ゴール)があって顧客になにか製品やサービスを提供する組織だけを取り上げます

そもそものシンプルさは、実務的な効果のない、単なる哲学的概念にすぎないのか?

ゴールドラット博士から私への最も実務的なアドバイスのひとつは、次のようなものでした:

もし あなたが見ている状況が、あなたにとって複雑すぎると思われるなら:

あなたが見ているのは小さすぎるサブシステムだ。
シンプルさを知るには、もっと大きなシステムを見なさい。

これは非常に直感に反したアドバイスですよね。あなたが複雑なものを見つけたとして、もっと複雑なものを探そうという気になりますか? ところがどっこい、より大きなシステムを分析する方が、何が重要か、特に何が重要でないかが見えるので、実は状況がスッキリするのです。生産現場はスケジューリングするには非常に複雑に見えるかもしれません。しかし、実際の需要だけを計画に入れて、確定した需要と予測の需要を区別して初めて、どこが本当の制約か分かるし、そうなって初めて、制約の最大活用とそれへの従属の仕方が明確に見えてくるのです。

「シンプルさ」という言葉は意味を明確にしておく必要があります。また、「複雑さ」という言葉には、次のように2つの異なる定義があり、その真反対の「シンプルさ」の意味は、そこからも明らかになります。

  1. 部分的に相互依存する沢山の変数が結果に影響を及ぼす。
  2. 特定の変数の値の動きや変化の結果を予測するのが難しい。

2番目の定義は、我々がなぜ複雑さに苦しむかを示しています。一方、最初の定義は、その難しさの原因らしきものを述べています。

「部分的な依存」は変数間の相互作用を複雑にします。変数が互いに完全に依存しているなら、それらが組み合わさった結果を予測する式を書けます。一方、変数が完全に独立なら、やはりトータルの影響を計算するのは容易です。それに対して、完全ではなく部分的な依存が支配的だとなると結果を予測するのは困難です。

独立、完全依存、部分依存の変数、それぞれ例を挙げておきます:

  1. 同種リソースのいくつかのユニット。ユニットは互いに独立。
  2. どこかで問題が起きる都度ライン全体が止まる生産ライン。ラインは、確実に最も遅い工程のペースに合わせて動き、どの工程も、ライン内の他の工程すべてに完全依存している。
  3. 様々なワークセンターがあって、その間に十分な空間を持つ通常の生産現場。どのワークセンターも、処理に必要な材料を供給する先行のワークセンターに部分的に依存している。

この複雑さに加えて、どの変数も大きな変動にさらされると、あちこち複雑さに圧倒されてしまいます。

本当に組織のパフォーマンスが予測不能になるの?

そういう状態を「カオス」と呼ぼうが「カオス寸前」と呼ぼうが構いませんが、要は、顧客はそんなひどいパフォーマンスにはとても我慢できないということです。10月1日午後2時に届く約束だったのに、届くのが10月22日午前6時30分になったら、私はとても我慢できない

内部がカオスに瀕していて、顧客には許容時間内に納入するなんてできますか?

合格レベルの信頼性を獲得するには、組織は十分シンプルにしないといけません。複雑そうに見えた最初の印象は間違いです。なぜなら、シンプルになると、部分的な依存が抑え込まれて、納入のパフォーマンスへの影響が限定的になるからです。キャパシティに余裕を持たせ、リードタイムを少し長くすれば、部分的な依存が減少します。TOCでは、バッファとバッファ管理を使ってより効果的にシンプルにします。それによって我々が得る恩恵は、十分高い確度の納期遵守だけなく、早期納入に喜んで高いお金を払ってくれる市場セグメントに対して短納期を約束できるようになることです。

そうは言っても、バッファを使うということは、予​​測可能性には限界があるということです!

いくら本質はシンプルだと言っても、本当に正確な予測ができると言ってるわけではありません! 要するに、我々が予測できる範囲を決めるということです。CCPM(Critical Chain Project Management:クリティカルチェーン・プロジェクトマネージメント)によるプロジェクトの計画で2017年6月に完了すると予測した場合、それは実際には遅くとも2017年6月に終わるということです。それ以前に終わる可能性もあり、そうあって欲しいと思うのが普通ですが、2017年6月には終わるという予測で十分なのです。

ですから、シンプルとは、許容可能な範囲で結果が予測できるということです!

シンプルさは、そのソリューションを1フレーズで書けるということなのか? 果たして、たった1フレーズのCCPMで、起き得る結果を判断できる能力を顧客に与えるのに十分かどうか、私は疑わしいと思います。明らかにTOCの知識体系を1フレーズで述べるのは我々には無理です。

考え方を広めるにおけるシンプルさは、その考え方がよく深く理解されることです。これは、我々がマーケティングメッセージを考える際に用いる「予測可能性」の意味です。我々は、読者、視聴者あるいは観客がどう理解するか予測できる!  しかしここでも、解釈にはある一定の幅があるのは我慢しないといけません。

では、ソリューション自体の細部はどうか? ソリューションのインプリメントは必然的に簡単なのか?

簡単とシンプルは同じではありません。考え方はシンプルでも、そのインプリメントには障害が伴うかもしれません。通常、その障害は予測可能ですが、それを克服するのは難しいかもしれません。ですから、インプリメントがシンプルかつ容易なのが非常に望ましいが、必ずしも完全にそうできるとは限りません。

TOCをずっとやってきた私たちは、シンプルさの有り難さはよく分かっていますが、それを達成するのは私たちにも非常にチャレンジングです。本当に良いソリューションの要件は、シンプル実行可能性(実際に実行可能)そして有効性(目的・目標の達成)です。

難しさを示す例:

簡易DBR(S-DBR:Simplified-DBR)は、製造における信頼性の高い納入を目的としたシンプルで効果的なソリューションです。しかし、バッファ管理が正しく機能する前提として、我々は正味のタッチタイムが製造リードタイムの​​10%未満であることを仮定しました。そこがややこしいところです! そこで、タッチタイムが10%以上の製造環境向けにソリューションが開発されてきました。それは、バッファ管理に必要な情報を複雑にしましたが、有効に機能しています。

私の物理学史の教授であったSambursky教授が私たちに教えてくれたことを思い出しました:

「古代ギリシャ以来、科学者たちは、常に、すべてを説明するひとつの式を探し求めた。彼らはいつもそういう式を持ってきて、何か新しい現象を発見するとその式に当てはめてみたが、そのとおりの振る舞いをしなかった。それで、その式を現象に合うよう修正した。ところが、その式に矛盾するさらに沢山の新しい現象が現れて、式は非常に扱い難いものになり始めて、終に新しい現象の振る舞いを予測できなくなった。するとまた、新しい理論が現れて新しいシンプルな式をもたらし、再びそのサイクルが回り始めた。」

TOCは基本的にはシンプルです。元々ある根本のシンプルさを暴き出して、シンプルなソリューション、シンプルなメッセージ、そして容易なインプリメンテーションを提供しようと必死で努力しています。しかし、我々は、これまでしばしば、ある特定の前提が当てはまらない環境に対応しようと、何かを追加しなければなりませんでした。私が思うには、これが組織を経営する最も実用的で効果的な方法です。

新しいもっとシンプルで効果的な方法が現れるまでは…


関連記事:

TOCとソフトウェア - その価値の探究

TOCの境界 「TOCではないもの」とは一体何なのだろう?

マネージャーは組織のことになるとなぜ自分のこととは違う判断をするのだろうか?


著者: エリ・シュラーゲンハイム
飽くなき挑戦心こそが私の人生をより興味深いものにしてくれます。私は組織が不確実性を無視しているのを見ると心配でたまりませんし、またそのようなリーダーに盲目的に従っている人々を理解することができません。

この記事の原文: What Simplicity truly means?

全ての記事: http://japan-toc-association.org/blog/

Share

Comments are closed.