改善を成功に導くカギ　その弐の一

　前に書いた記事『改善が失敗する理由　その弐』では、全社的取り組みは成功しづらいので、以下のような取り組み手順を先に示させていただいています。

　○ 全社的ではなく一部の部署（最小単位の組織）でテストする。
　○ 社内や組織内で一番忙しい部署でテストをする。
　○ 改善を担当するメンバーは他部署から集める。

　小規模単位でテストを行うメリットも同様にまとめています。

　※ 一部の部署で始めることで自社に合っているかの検証と確認ができる
　※ 投資額や導入にかかるコストを抑えられる
　※ 上手く行かないと判断したらすぐにやめられる
　※ 忙しい部署でやるので、改善成果が出た時の効果・成果が大きい
　※ 経験済みのメンバーが揃うので、部門・全社的に広げやすい
　※ 社内に助け合いの気風が生まれてくる

　しかしなぜ、このような手順を踏まねばならないのか。

　ただ単純に成功しないという理由だけでは、説明不足な部分もあると思います。

　そこで今回は、この方法を採用する方が論理的に正しいという形で解説したいと思います。

どの組織も『フラクタル』な構造を持っている

　『フラクタル』というキーワードを初めて聞かれる方もいらっしゃるでしょう。

　『フラクタル』とは？

形の適宜な一部を取ってもそれが全体と似ている成り立ちをしていること。自己相似的。
　　　Google検索 OxfordLanguagesより引用

　と定義されています。

　そして企業や組織もこの『フラクタルな構造』を持っているところが多いのです。

　特に企業や組織の『制約条件（ボトルネック）』となっている部署は、その傾向を非常に強く持っています。

　なぜなら、企業や組織の『つながり』と『バラつき』の歪みが集まった箇所が、制約条件でありボトルネックだと言えるからです。

　フラクタル（相似形）の構造を持っていると言うことは、最小単位で実験して出た結果・成果を、そのまま全社的に展開できると言うことです。

　だから『制約条件』と特定した最小単位の部署でテストを行うのです。

複雑さを人は恐れる

　もう一つの理由は、人間は複雑さに対して『恐れ』や『嫌悪感』を持っているからです。

　よく言われることですが「複雑な問題は分解して考える」という考え方があります。

　ただ、この考え方は本当に正しいのでしょうか？

　複雑な問題を分解して考えて、本当に問題解決に導けるのでしょうか？

　【ザ・ゴール】の中で主人公のアレックス・ロゴは、工場の中に『つながり』と『バラつき』があることを発見します。

　工場内の全ての工程は、横につながっており、また各工程の持っているリソースはバラついているという、ごくごく当たり前のことなのですが、この『つながり』と『バラつき』があるからこそ、制約条件（ボトルネック）が生まれることに気がつくのです。

　つまり『つながり』と『バラつき』がある企業や組織を、複雑だからといってバラバラに分解して、個別に対応して良いのでしょうか？

　それでは、いつまで経っても本当の問題に到達できず、個別最適に終始してしまうのではないでしょうか。

　この複雑さに対する恐れをできるだけ抑えるために、手の中に納められる範囲（最小単位の組織）でテストを行うのです。

　人が多すぎたり、工程の数が多すぎたりすると、それに伴って『つながり』と『バラつき』が増えていきます。

　そうすると、目の前に起こる事態はどんどん複雑に見えてきます。

　すると人は、その複雑さに対する『恐れ』や『嫌悪感』から、複雑な事態を分解したくなってしまうのです。

　逆に単位が小さければ、今度は分解しようにも分解することが出来なくなります。

　だから組織や企業の最小単位の大きさでテストを行うのです。

今はやらない部署をあえて作る

　そして最後の理由は、改善している部署と、改善をやっていない部署を作って、改善している効果を明確にするためです。

　全ての部署で改善を行えば、その改善の効果が本当に出ているのかが、見えなくなる時があります。

　それに、何度もお伝えしているように、制約条件に集中しなければなりません。

　有限であるリソースを使い潰してしまうことのないように、今はやらない部署を作って、今やらなければならない部署に集中することが大事です。

　やることに集中するということは、逆に言えばやらないことを決めるということでもあります。

　やらないことを決めてやることに集中する。

　そのために、あえてやらない部署を作って、改善する部署と比較して成果を確認するのです。

　そしてその改善結果を使って、次にやらなかった部署の改善を行っていくのです。

　ということで、文字数的にも区切りが良いところ（2,000文字前後）まで来ましたので、本日はここまでにさせていただきます。

　次回は、今回お伝えした『複雑さに対する恐れ』をもう少し詳しく掘り下げていきたいと思います。

　この複雑さに対する恐れこそが、多くの改善を止めたり、停滞させている最大の原因だと言えるのです。

　逆に言えば、この複雑さに対する恐れを取り払うことが出来れば、改善活動は一気に進めることも可能になりますので、是非ご覧いただければと思います。