TOC(制約の理論)とは何か?製品開発にTOCを適用するとはどういうことか?

1984年にアメリカで出版された「ザ・ゴール」によってTOC(制約の理論)は瞬く間に全米へそして全米から世界に広まった。(日本語版が出版されたのは17年後)最初は生産現場での問題解決手法として使われていたものが、徐々に企業内の様々な場面で使われるようになり、日本でもTOCは多くの企業で活用されるようになった。改めてTOCとは何か?製品開発でも適用できるというのはどういうことなのかを解説していきます。

 

リーン製品開発やジョブ理論などを使って製品開発組織の改革支援をしてきた経験の中で、改革戦略にTOC(制約の理論)の思考プロセスを導入し、実践してきた経験から、TOCの考え方を改めて見直ししつつ、製品開発組織での適用について解説していく。

 

 

TOCとは?


Amazonで見る

イスラエルの物理学者であったエリヤフ・ゴールドラット博士が開発したと言われるTOC(制約の理論)は、もともと生産工場でのスケジューリングをするためのソフトウェアを開発したことから生まれたのだそうです。

ゴールドラット博士が開発したソフトウェアを多くの人にわかりやすく説明できるように書いた小説「ザ・ゴール」が大ヒットしたことで、TOCが世界に広まっていきました。

TOCの基本概念は、すべての企業における共通の目的は、「現在から将来にかけて儲け続けること」と定義し、その企業のゴール達成を妨げる制約、あるいはボトルネックを集中的に改善することで、企業全体の業績、つまりスループットを向上させるように企業システムを改善していくということです。

すごくわかりやすい例でいうと、下図のような工場のラインがあって、各工程の生産能力がバラバラだとすると、その工場全体の生産能力は一番能力の低い工程(例でいうと工程3)で制限されてしまいます。

 

 

工程の一つ一つを頑張って改善して個々の能力を上げようとしても、工程3の能力が変わらなければ工場全体の能力は変わりません。

企業の誤った改善活動は、全体のスループットを見ずに、個々の部分最適に労力を使うことだというのが、TOCでの最初の教えになります。

この例はあまりにも単純化しているので理解できない人はいないと思いますが、実際の企業でどうなのかというと、例ほど単純ではないにしろ、企業内の組織と組織の間は、工場以外でも作業や機能がつながっています。

つまりすべての企業活動にも工場と同じようにインプットからアウトプットがあって、そのスループットは制約、つまりボトルネックによって制限されている可能性があるわけです。

そうすると、全体を見て改善していかないと、個々の組織の改善だけをやっていても意味がないということになります。

TOCには素晴らしい考え方がたくさんあるのですが、中でも最も私自身が好きなことは、制約条件、つまりボトルネックを正確に掴んで改善できれば、比較的すぐに効果が表れるということです。

ただし、TOCによる改善活動は継続することが大切でもあります。

(参考:TOC-ICO

制約とは何か?

制約の理論では、3つの制約を考えていきます。

物理制約

企業内の能力などの制約です。「ザ・ゴール」の中でも出てくる工場内の機械の能力であったり、人や組織の能力などによる物理的な制約です。

市場制約

企業と外部との間にある制約で、企業システムの供給能力と市場要求との間にあるアンバランスなどの制約です。

方針制約

組織問題として起こりやすいのが、経営トップの大方針のもと、各部門の小方針や判断基準などとの間に起こるジレンマによる問題で、TOCではこれを方針制約と呼びます。

これら3つの制約は、それぞれが密接に関連していることもあります。

TOCでは、企業システムのスループットを制限してしまっているのは、1つかあるいはごく少数の制約であるということからスタートし、下記の5つの改善ステップによって継続的に企業システムを改善していきます。

  1. 制約条件を特定する
  2. 制約条件を徹底活用する方針を決める
  3. 制約条件以外を制約条件に合わせる
  4. 制約条件を強化する
  5. 制約が解消したら最初に戻る

問題の本質を捉えるロジカルシンキング -クラウド

TOCの企業システム改善のフレームワークは、思考プロセスとも呼ばれます。

TOCのフレームワークをうまく動かすためには、ロジカルシンキングが非常に重要です。

企業の中で起きていることは、ほとんどすべてが因果関係、つまりXXだから△△という関係でつながっています。

改善プロセスは、ある意味、この因果関係を読み解いていくことだと言えるかもしれません。

また、TOCのフレームワークの中で、クラウド(雲)というツール(下図)が使われます。

 

 

日本語では”対立解消図”と言われるのですが、組織内で起きている悪い症状(問題とも読み替えられる)がどういうメカニズムで起きているかを客観的にシンプルに、そして正確に、かつ思い込みを排除して捉えるツールです。

別記事で「対立解消図の作り方」を解説していますので、よろしければ参照ください。

TOCのフレームワークを使いこなすためには、このクラウドをしっかりと作れるようになる必要があります。

クラウドは、必要条件ロジックで成り立っていて、因果関係とはちょっと違うロジックで作成しますが、大事なことは私見を入れずに、あくまで客観的に問題を捉える思考力を持つことです。

慣れないと、解決策や自分の意見でクラウドを作ってしまい、本来の問題解決が出来なくなってしまいます。

クラウド作成は繰り返しの練習で上達できると思っています。

TOCの前提条件

TOCの素晴らしさは、人間臭いというか、組織現場をよく理解して考えられていると感じることです。

その中でも人々の思い込みに警鐘を鳴らす以下の4つの前提条件があります。

  1. 物事はそもそもシンプルである。
    しがらみや思い込みで問題を複雑にしてしまわないこと
  2. 組織問題は悪い人が起こしているのではない。
    犯人捜しではなく、前提条件を見直すことが大事
  3. 必ずWin-winの解決策がある。
    解決できないことを人のせいにしない
  4. 決してもうわかったとは言わない。
    改善に終わりはない

このほかに、前述した企業内のすべてのことが因果関係でつながっているというのもゴールドラット博士の考える前提条件です。

また、非常に面白いのは、組織内には「抵抗の6つの階層」というのがあって、問題解決を妨げているという考え方になっています。

  1. 対応しようとしている問題を、問題として認めない。
  2. ソリューションの方向性に同意できない。
  3. ソリューションが問題を解決するとは思わない。
  4. このソリューションは、もし実行するとマイナスの影響を引き起こしてしまう。
  5. 提案されているソリューションの実行を妨げる障害がある。
  6. その結果起こる未知のことへの恐怖感。

皆さんの会社にもありませんか?

戦略的アプローチ

TOCのフレームワークは、戦略的なアプローチをとります。

  1. 何を変えるか(現状の問題は何か)
  2. 何に変えるか(ゴールをどう設定するか)
  3. どのように変えるか(どうやって解決していくか)

という1,2,3のプロセスをきっちりと守り実行します。

 

 

3つのステップを守ることがなぜ重要かと言うと、戦略的でない行動では、問題が一つ起こると、すぐにソリューションを考えて実行してしまいます。

問題を特定せず、ゴールを決めずに導かれたソリューションは、場当たり的であったり、対処療法になったりして、根本的な問題解決にならないことがほとんどです。

TOCの考え方は、まさに戦略的な行動そのものであり、戦略立案とTOCとは非常に相性がいいのだと思っています。

 

参考記事:

開発組織における問題の構造化(第一回~第五回)

開発組織の良くある組織問題をTOCのプロセスを使って現状ツリーから未来ツリーを作っている過程を解説します。

 

 

製品開発にTOCを適用する

TOCは、もともとは生産工場のスケジューリングから始まり、生産工場の改善フレームワークとなり、さらに企業の様々な課題に対する改善システムへと進化していきました。

ゴールドラット博士は、最初の著書「ザ・ゴール」に続き、「ザ・ゴール2」、「チェンジ・ザ・ルール」、「クリティカルチェーン」及び「ザ・チョイス」などを出版し、TOCの生産以外での活用方法を示しています。

ザ・ゴール2」では、事業再生、あるいはビジネスモデルを転換することで、3つの企業を再生させることにTOCを使っています。

チェンジ・ザ・ルール」では、IT導入だけでは企業の収益が上がらないことを示しながら、ルールを変えるということでシステムのスループットを上げられることを示しています。

クリティカルチェーン」は、いわゆるプロジェクトマネージメントにTOCの考え方を入れて、CCPMというプロジェクト管理手法を提案しています。

ザ・チョイス」は、TOCの前提条件である「物事はシンプルである」、「必ずWin-winの解決策がある」などを事例を通し、また父と娘の対話を通して示してくれます。

 

弊社では、クライアント企業様とともに製品開発組織の課題解決にTOCを活用してきました。

その活動の中で、製品開発組織の課題にはある程度共通性があることもわかってきました。

その共通性について読み解いて、問題を構造化する(何を変えるか)というところを別記事「開発組織における問題の構造化」で解説しています。

製品開発組織改善の目標設定

TOCは、企業システムの全体スループットを上げることを目指した手法です。

また、企業の目的は「儲け続けること」だと言っています。

なので、製品開発組織の改善においても、究極的には企業の利益につながっていなければ意味がないことになります。

もちろん、製品開発組織だけで単独で利益を上げているわけではなく、利益を上げるための改善のポイントは様々なところに存在するのだと思います。

製品開発組織の改善をTOCで行うにあたって、製品開発組織の目標は、「利益を上げる」としても良いのですが、「利益を上げるために」なる2次的な目標を上げることも有効だと思います。

例えば、「顧客に新しい価値を届ける製品を継続的に開発する」ということとか「競合の半分の期間で商品をリリースできる」、「競合よりも常に30%低いコストの製品をリリース出来る」などでもいいかもしれません。

TOCのプロセスから言うと、起きている悪い現象を因果関係で結んでいき、因果関係の大元になるものが根本原因である可能性が高く、因果関係の結果を辿っていった先にある重要な問題が、最も解決したい事象、すなわち目標になるのかもしれません。

つまり、TOCのプロセスでは、現状の問題をすべて良くすることで生まれる世界(未来ツリー)を目標にするのですが、この未来ツリーで表現されることが企業の利益向上につながることかどうかを考えると、企業トップのやりたいことと一致してくるというわけです。

TOCのフレームワークは、企業の経営戦略や開発戦略と重ねて考えると非常にわかりやすくなります。

 

 

上図は、3C、SWOT分析などを使った戦略思考法にTOCのフレームワークを合体させ、戦略の基本方針を導く際にベストプラクティスとしてリーン製品開発手法やジョブ理論などからヒントを得ていくフレームワークを示しています。

経営目標、つまりトップの目標、究極的には儲け続けること、ということに繋がる目標設定とすることで、全体スループットに着目した改善になっていきます。

製品開発組織に特有の問題

製品開発組織に共通の存在する問題の例を挙げてみます。

  • 雑用に多くの時間が取られている
  • 責任者が不明確になっている
  • 手戻りが多発している
  • 失敗を糾弾される
  • 同じような失敗が繰り返される
  • 製品全体を理解できる技術者が減少している
  • 若手の離職率が上がっている
  • 新たなコンセプト製品が長い間生まれていない
  • ベテランの知識、ノウハウが会社に残っていかない
  • 他の人の仕事内容、状況がわかっていない
  • 日程遅れが常態化している
  • 自主的なアイデアの試作や提案が出来ていない
  • 若手が技術力の伸びを実感できない
  • ノウハウが資料として残っていない
  • 顧客の真の課題、潜在ニーズを把握できていない

いかがでしょうか?

あくまで例ではありますが、これまで一緒に仕事をさせていただいた多くの企業に共通して見られる好ましくない状況(UDE)です。

これらの製品開発組織の悪い状況、つまりUDEから組織のボトルネックを求めていく様子を別の連載記事「開発組織における問題の構造化(第一回~第五回)」で解説しています。

結論から言うと、下図のようなコア・クラウドが導かれて、これが組織のボトルネックという仮説が成り立ってきます。

 

 

このコアクラウドをどうやって解決していくか、という手掛かりとして、リーン製品開発手法やジョブ理論などを活用していくというのが弊社が勧める戦略的なアプローチということになります。

決して、手法をそのまま真似して実行するのではなく、問題の本質を捉えてその解決策として成功事例の本質的な意義を取り入れていくということです。

 

製品開発組織の改革支援について

弊社は、製品開発革新に特化したコンサルティングサービスを提供しています。

製品開発組織の改革を行う際に、クライアント企業様とまずは現状認識、ゴール設定を行った後、改革プランを作っていくというアプローチをとるのですが、まさにこれがTOCのアプローチであり、弊社でもTOCを活用してクライアント企業様の改革を支援していきます。

TOCに関してもジョナ認定を受けているので、TOCの実践を行うことは出来ますが、弊社以外のTOCプロフェショナルの複数の企業とのパートナーシップも結んでおり、必要に応じて製品開発革新コンサルとTOCコンサルのコラボレーションでクライアント企業様へ最適なソリューションを提供することも可能になっています。

まずは、お悩みなどをお聞かせください。

下記フォームより無料個別相談をお受けしています。