TOC（制約の理論）の思考プロセスでUDEを深堀すると問題の本質が見える
TOC（制約の理論）の思考プロセスは、様々な組織問題を解決するフレームワークです。TOCの思考プロセスを使って課題解決をするときに、まずは現状を正確に捉えるために組織内で起こっている悪い症状をUDE（Undesireble Effect；好ましくない状況）として捉えていきますが、このUDEを深掘りすることで、問題の本質が見えやすくなります。そして問題の本質を捉えることで、問題解決をシンプルで容易にしてくれます。
クライアント企業とともに、組織改革戦略にTOC（制約の理論）の思考プロセスを導入し実践してきた経験から、問題認識のための基本要素であるUDEについて、その取扱いとUDEから問題の本質を捉えるための考え方を解説し、問題の本質から問題解決の流れを確認していきます。
TOCのUDEを出発点にして、問題の本質を捉えるところが本記事の主目的ですが、そこから先の問題解決、組織改革について、弊社の「連鎖式組織改革法」に繋げるアプローチについて簡単に触れていきます。
本記事の内容
TOCのおさらい
TOC（制約の理論）は、イスラエルの物理学者であったエリヤフ・ゴールドラット博士が開発したと言われ、2001年に「ザ・ゴール」という本で日本に初めて紹介されました。
TOCは、最初は生産工場の生産能力を上げて収益を改善する方法として紹介され、また活用されますが、徐々に生産以外の企業内のすべての組織問題に応用できることで広まっていきます。
TOCの思考プロセスに関しては、別記事「TOCとは ～製品開発にも適用できる制約の理論」で解説していますので、詳しくはそちらを参照ください。
TOCの思考プロセスは、「何を変えるか」→「何に変えるか」→「どのように変えるか」という順序で組織改革を進めますが、この順番をしっかりと守って進めることが重要なのです。
まず、「何を変えるか」、つまり現状はどうなっていて何が問題なのか？そして根本の問題は何かということを突き止めていきます。
つまり、上図のように、起きている一つ一つの悪い症状は因果関係で連鎖していて、根本の原因を追究することが大事だとTOCでは考えます。
一つ一つの症状に手を打つような対症療法ではなく、根本治療が必要ということですね。
組織の問題も同じように、様々な悪い症状が連鎖していると考えます。
この一つ一つの悪い症状のことを、TOCではUDE（Undesirable Effect ; 好ましくない症状）と言います。
皆さんの組織でも、悪い症状、つまりUDE一つ一つに何か手を打とうとしていませんか？
それでは対症療法になってしまい、本当の問題解決に繋がっていない場合が多いというのがTOCからの戒めということになります。
TOCでは、根本問題を見つけて解決策を確実なものにしていきます。
そして組織課題の根本問題を見つけるため、まずはUDEを出し切るところから始めて、その後、UDEがどのように連鎖しているかを因果関係でつないだ現状ツリーで表していきます。
開発組織において現状を把握していく事例を下記の参考記事で説明していますので、そちらもぜひ参照ください。
UDEの作り方とチェック方法
UDEは明確な文章で表現します。
よくある間違いは、例えば「コミュニケーションの停滞」とか「売り上げの低下」などのように名詞句で表現してしまうことです。
曖昧さを排除するために、必ず文章で表現します。これが最初のルールです。
それ以外には以下のような注意点があります。
- 本当に悪いことなのか？
→一見悪いことのように聞こえるが、それは本当に悪いことなのか？ - 本当にそういう事実はあるのか？
→感覚的、感情的になって事実でないことを言っていないか？ - 解決策が出来ていないことを言っていないか？
→解決策ありきで言っていないか？ - 悪いことであっても絶対に解決できないことではないか？
→物理的に解決できないことを言っていないか？ - 複数の文章になっていないか？
→複数になっていればUDEを分ける
UDEを作成したら、文章になっているかということと上記の5項目、トータル6項目のチェックを行います。
トヨタのリーン製品開発手法の本質を捉え、
若手エンジニアのモチベーションによる改革を目指し、
トヨタの真似でない独自の世界観で
組織改革に挑む姿を描いています。
TOCで問題の連鎖を捉えています。
詳しくは、「製品開発組織の常識をぶち壊せ！！」出版のご案内を参照ください。
UDEを「だからどうなる？」「それは何故ですか？」で問い詰める
UDEを実際の例で見ていきましょう。
製品開発組織で共通的に挙げられる下記の15個のUDEを例にとります。
- 雑用に多くの時間が取られている
- 責任者が不明確になっている
- 手戻りが多発している
- 失敗を糾弾される
- 同じような失敗が繰り返される
- 製品全体を理解できる技術者が減少している
- 若手の離職率が上がっている
- 新たなコンセプト製品が長い間生まれていない
- ベテランの知識、ノウハウが会社に残っていかない
- 他の人の仕事内容、状況がわかっていない
- 日程遅れが常態化している
- 自主的なアイデアの試作や提案が出来ていない
- 若手が技術力の伸びを実感できない
- ノウハウが資料として残っていない
- 顧客の真の課題、潜在ニーズを把握できていない
例えば、「手戻りが発生する」というUDEが起きると、だからどうなる？で考えると例えば「日程遅れが常態化する」などに繋がっていきます。
上記15個のUDEのうちの２つが因果関係で繋がりました。
次に例えば「若手が技術力の伸びを実感できない」というUDEに、だからどうなる？と自問してみると、「モチベーションが下がる」という上記15個には含まれていない新たなUDEが出てきます。
さらに、「モチベーションが下がる」とどうなるかを考えると、例えば「若手の離職率が上がっている」に繋がります。
次に、本当に悪いことなのか、ちょっと疑問が残りそうな「他の人の仕事内容、状況がわかっていない」というUDEを考えてみます。
これだけでは、本当に悪いことかどうかわかりづらいので、では、こういう状態になると次にどうなるかを考えます。
「意思疎通がしづらくなる」ということがあるかもしれません。では、「意思疎通がしづらくなる」とその先どうなるかを考えると、「頻繁に打ち合わせが必要になる」ということが起きて、「雑用に多くの時間が取られる」に繋がり、その結果、「日程遅れが常態化する」に繋がります。
反対にあるUDEに対して、「それはなぜですか？」と問いかけてみます。
「若手が技術力の伸びを実感できない」のは何故なのか？を考えてみたときに、例えば「チャレンジングな仕事を与えてもらえない」や「ベテランからノウハウを伝授されない」などがあるかもしれません。さらになぜ「チャレンジングな仕事を与えてもらえないか」と考えたときに、「新たなコンセプト製品が企画されない」などがあるかもしれません。
このようにUDEから「それはなぜですか？」という問いかけによって、原因側を遡っていくことができるわけです。
原因側を「それは何故ですか？」で遡り、結果側を「だからどうなるのですか？」で広げていくことで、組織問題の因果関係を構造化していくことが出来ます。
このようにしてUDE同士の因果関係をすべて繋いで構造化したものが、現状ツリーということになり、現在の組織の状態、悪い症状が連鎖的に起こっている様子を見える化することが出来ることになります。（下図は現状ツリーの例）
因果関係で繋がった現状ツリーは、矢印の元が原因で、矢印の先が結果という繋がりになります。
この矢印の元を辿っていくと、すべての問題の根本原因になることになります。
上図の一番下のコアクラウドのジレンマというところが、すべての問題の出発点、すなわち根本問題ということになります。
TOCの基本的な考え方は、この矢印の大元の根本問題が組織のボトルネックであり、ここを強化することでほぼすべての問題（矢印が繋がっている問題であれば）を改善することが出来るということになるのです。
反対に、矢印の先は、問題が広がっていく様子を示すことになります。
例えば、単純に15個すべてのUDEが起きると、その結果どうなりますか？という問いには、「利益が落ちる」ということが考えられます。
様々な問題が重なり合って、最終的に利益が低下するという重大問題を引き起こすことを示しているわけです。
ここで念のための確認ですが、実際にその企業で利益低下が起きていなければ問題、つまりUDEにはならないのですが、逆に、これだけ悪い症状があって利益が落ちない、あるいは上がっているとしたら、それはそれでうらやましい限りですね。
別の見方をすると、根本問題の解決をすれば、上図とは逆の因果関係が起きて、最終的にはもっと利益が上がるようになるかもしれません。
さて、UDEに対して、「だからどうなる？」「それは何故ですか？」を自問していくと、UDE同士の連鎖を掴むことが出来、その結果
- 本当に悪いことは何かを突き止めることが出来る
- 負の連鎖を明確にすることが出来る
ということになり、課題解決のための現状認識を正確なものにすることが出来ます。
TOCの思考プロセスで課題解決をしていくときに、UDEの「だからどうなる？」「それは何故ですか？」での深堀りをぜひ実践してください。
UDEを客観的に解析するのがクラウド（対立解消図）
UDEは、組織内で起こっている悪い症状です。
簡単にいうと組織問題ということですが、それぞれのUDEがなぜ起こっているのか、UDEの背景は何かというのを解析するのがクラウド（対立解消図）ということになります。
TOC（制約の理論）では、組織問題、つまりUDEは人の行動が引き起こしていると考えます。
しかし、ここで誤解してはいけないのは、人が何か悪いことをして問題を起こしているのではない、ということです。
人の行動のジレンマ、つまり対立が問題を引き起こすと考えるわけです。
何の対立かというと、組織が目指す大きな目的があり、その大目的に向けて複数の中間目的があるときに、その複数の中間目的を達成するための行動が、両立しない、つまりどちらかを選択しなければならず、もう片方の行動と中間目的を諦めなければならない状況で、問題が起きると考えます。
どんなに良いことをしようと思っても、副作用というのは付き物ですよね。良い変化を起こす裏で、少しずつ悪いことが進行することがあります。組織問題というのは長い時間をかけて、このような副作用によって悪いことが起きていることが多いのです。
そして組織内に存在するジレンマ、つまり対立が問題を起こすということから、TOCでは対立解消図（クラウド）を使って問題を表現するわけです。
ここで一つクラウドによる対立構造の例をお話しします。
製品開発組織の問題を追及していき、問題（UDE)の因果関係、連鎖を現状ツリーで解析した結果、「個々のエンジニアの役割を専門組織ごとに分業化することで製品全体との繋がりが希薄になった」ことが根本問題と一つとわかったとします。
では、この根本問題の背景のジレンマは何かと考えます。
専門組織による分業化は、製品開発全体の生産性を上げるために行われることがあります。
つまり、経営者の視点でみて、効率を上げて収益を上げるために行っています。
ところが、組織としての生産性を上げる代償として、エンジニア個人個人の能力向上のチャンスを無くしてしまったのではないかとも考えられます。（実際は企業ごとの事情があります）
とすると、この根本問題（UDE )は、下記のようなクラウドで表現することが出来るというわけです。
問題の連鎖が正しく掴まれ、根本問題のジレンマが上記のクラウドのような対立が原因であるならば、このジレンマを解消することで、組織問題の多くが連鎖的に解決できるということになります。
上記のクラウドはあくまで例です。
個々の企業での実態を客観的に深く分析することで、ジレンマを明らかにしていきます。
ジレンマ、つまりクラウドの内容にメンバー間で合意が取れれば、このクラウドのロジックを解消する対応策を考えるというのがTOCの問題解決手順になります。
クラウドを的確に表現することが、問題の根本、つまり問題の本質を突き留めることに繋がるわけです。
とはいっても、クラウドを作るには少しコツが必要です。（思い込みが入ってしまう傾向がある）
もし、クラウド作成に興味があれば、クラウド（対立解消図）の作り方、演習方法については、「TOCのUDE、クラウド（対立解消図）で問題の本質を読み解くトレーニング」を参照ください。
製品開発組織の問題解決フレームワーク
さて、根本問題を突き止めて、根本問題の本質であるジレンマまで突き止められたら、次はどうするかという疑問が沸きますね。
弊社では、組織問題の本質追及から、問題解決の道すじを設計して実践して成果を挙げるまでを一貫して支援するノウハウを提供しています。
お話ししてきたように基本的にはTOC（制約の理論）のフレームワークを活用しながら、弊社が推奨する製品開発手法（リーン製品開発手法やジョブ理論などのマーケティング理論など）の活用を組み合わせた「連鎖式組織改革法」によって、勝ち続ける強い組織に変革することが出来ます。
連鎖式組織改革の流れは、TOCの流れと同じような流れにります。
- 組織の現状を正確に分析し、根本問題を洗い出す（本記事の主題）
- 根本問題の対策案を出し、対策案の正しさを検証する
- 目指すべきゴールと、ゴール達成までの組織の変化（連鎖）を設計する
- 変化の連鎖を検証し、障害や副作用を発見して解決策を加える
- 組織変化の連鎖に基づいて詳細計画を立てる
- 小さな仮説検証を積み上げて計画を実行する
連鎖式組織改革の流れは、まさに戦略的なアプローチと言えます。
現状→ゴールの設定と、そのギャップを埋める戦略アイデアを立てるのですが、この戦略アイデアをトヨタの成功事例、他で成功している手法や理論の本質を取り入れるという思考（真似でなく本質のみを取り込む）で成功確率を高めていきます。
上図のような戦略的アプローチの対局は、直感的アプローチというような考え方になると思います。
要するに起きている問題を表面的に捉えて、直感的な対策を打つということで、多くの場合、対症療法的であったり場当たり的な対策になり、目標達成が出来ないケースがほとんどだと経験的には考えています。
例えば、「品質問題が多発している」という問題に対して、直感的に「チェック体制を強化せよ」という手を打つことを決め、デザインレビューを強化する施策などが打たれます。
ところが、確かにデザインレビューは仕組み化され、問題発生は10%程度（例えばです）の減少が見られますが、組織内では何年経っても「品質問題が多発している」という状況が変わっているとは感じられない、などというのは良く起こることです。
「品質問題」の原因を「チェック体制」という一つに決めつけてしまったこと、「デザインレビュー強化」によってどんな変化（具体的な数値レベル）が起きるかが設計・検証されていないことが原因だと考えられます。
決めつけでなく、問題の本質を捉え、手を打った後の組織変化を詳細に設計し、さらに机上検証をすることと、手を打ったことによる成果を測定しながら小さなPDCAを回してゴール達成としていくという当たり前の手順を大事にして欲しいと思っています。
弊社の進める「連鎖式組織改革法」については、下記の資料が参考になると思います。
よろしければご活用ください。
無償配布：「連鎖式組織改革法」のプレゼン資料
トヨタの組織力から学び、TOC（制約の理論）の戦略アプローチを採用した弊社独自の手法！！
「連鎖式組織改革法」のpdf版をご希望の方に無料で進呈しています。
50年勝ち続けられる組織を作る
効率化、チェックリストなしで実践できる組織改革の仕組み
この方法があればトヨタのような強い組織が作れる！！
無料にてPDFをダウンロードできます。下記フォームよりお申込みください。
「連鎖式組織改革法（pdf）」無料ダウンロード
TOCとは ～製品開発にも適用できる制約の理論
＊＊＊TOCをやさしく解説します ＊＊＊
この記事を気に入ってくれたら、下の'いいね'ボタンをお願いします！！
