開発組織における問題の構造化（第一回）

これまで様々な製造企業の開発部門とお仕事をさせていただき、それぞれの組織問題をいっしょに解析し、課題解決のお手伝いをしてきましたが、どうやら多くの開発組織が同じような問題を抱えていて、その根本の原因にも多くの共通性が見られることがわかってきました。

弊社では、問題解決のためのフレームワークとしてTOC（制約の理論）の思考プロセスをしばしば活用します。

今回、多くの製造業における製品開発組織で共通する組織問題を取り上げて、TOC（制約の理論）のフレームワークを使って問題を構造化して捉えることで、問題の根本原因を解読して、解決策に結び付けていくプロセスを共有していきたいと思います。

5回にわたる連載記事にしています。

最後までお楽しみください。

連載記事の内容

第一回　組織問題を悪い症状（UDE）として捉える

第二回　対立解消図（クラウド）の作り方

第三回　問題の根本（コア・クラウド）を見つける

第四回　根本原因を因果関係で検証してみる

第五回　コア・クラウドのロジックを壊すリーン開発手法

組織問題は連鎖して起きているから構造化が必要

TOC（制約理論）の話に進む前に、なぜ組織問題を構造化する必要があるかについてお話しします。

例えば、「品質問題が多発している」という問題があったとします。

ここで陥ちやすい間違いは、「それは品質チェック体制が甘いからだろう」と決めつけてしまい、

例えば「ではチャック体制を強化しよう」というソリューションが実行されてしまうのですが、これで問題の本質は解決されるでしょうか？

下図をご覧ください。

「品質問題が多発している」のは、実は様々な要因があって、様々な要因が連鎖することで起きているからなのです。

品質チェック体制が甘いというのは、あくまで複数ある原因のうちの一つであるということを見逃してはいけないのです。

そのためのキーワードは、「それは何故ですか？」ということです。

そうすると、「品質問題が多発する」のは「設計者がシステムを完全に理解していない」からという原因もあるかもしれません。

そしてさらに、ではなぜ「設計者がシステムを完全に理解していない」のかを考えます。

そうやって、すべての組織問題の因果関係を辿っていくことで、組織の根本問題を発見することができるのです。

また、「品質問題が多発している」とそのことが更に組織のどんな影響があるのかも考えておくことがとても大切です。

下図は、「品質問題が多発している」ことがさらに別の問題に連鎖していく様子を示しています。

品質問題から日程、リーソースの問題、コストの問題などに連鎖して、最終的には会社の収益に影響が出る様子がわかります。

この構図を明確にしていくためのキーワードは、「だからどうなる？」ということなのです。

このように問題は複雑に絡み合っているケースがほとんどであって、一つひとつの組織問題は単独で起きているわけではなく、それぞれが因果関係で繋がっているのです。

矢印の先を追いかけていくと、問題の影響範囲がどこまで広がっていくかを知ることができ、矢印の元を辿っていくと、問題の根本原因を見つけることができます。

これが問題の構造化が必要で重要である理由なのです。

TOC（制約理論）の思考プロセスを使うことで、組織問題を構造化することができます。

TOCの利点を生かし、戦略思考で問題を解決する

イスラエルの物理学者、ゴールドラット博士が生み出した制約の理論（Theory Of Constraints ; TOC)は、組織問題解決のためのフレームワークを提供してくれます。

元々は工場の生産性を改善するツールとして生まれたのですが、その後、生産工場だけではなく、企業のあらゆる組織にも適用できることがわかり、さらに新たな事業を立て直す、あるいは新しい事業を起こすような場面でも活用できることがわかっています。

なぜ弊社でTOC（制約の理論）を活用するのかといえば、私自身がTOCに惚れ込んでいるからなのですが、どんな所が気に入っているかというと、次の５つの点が挙げられると思います。

ボトルネックを見つけて攻める考え方で短期間に成果を出せる
論理的思考力を強化し、組織の思い込みを排除してくれる
全体のスループットを上げる全体最適の考え方
解決策の障害や副作用に先回りして手を打っていく考え方
戦略思考との相性が良く、戦略立案の強い分析ツールになる

1～4については、TOC（制約の理論）を学ばれている方ならご理解いただけると思いますが、５については、弊社がクライアント企業とお仕事をする中で、気づくことが出来たTOCの利点だと思っています。

戦略は、競争に勝つために「高い目標」を立て、自社の現状や競合、ビジネスにおいては顧客の動向もしっかりと分析することで、目標と現状のギャップを埋めるための策略だと考えていますが、世の中には戦略を間違って捉えているケースも少なくなく、弊社は経験上、正しい戦略の重要性を強く認識しています。

そこで、開発組織の組織改革に従来から言われている戦略を立てる手法と、TOC（制約の理論）の考え方を加え、更に弊社が進めるリーン製品開発などの開発手法をベストプラクティスとして、解決策のアイデアを出すヒントとして活用し、戦略的なアプローチでクライアント企業の組織改革を進めるようにしています。

下図は、弊社の組織改革を進める概念図になります。

今回の連載記事では、組織の問題を解析するところにフォーカスして説明していきます。

正しい戦略を立てるには、客観的で思い込みのない正しい分析をする必要があります。

また、起きている現象に目を奪われることなく、根本の問題、つまりボトルネックを見つけて、そこに集中的に手を打っていくという考え方に注目いただき、組織問題解決のヒントにしていただけたら嬉しい限りです。

もう一つだけ言っておきたいことは、組織問題の真の原因は、実は当事者だけでは見つけにくいということなのです。

自分たちのやり方を長い間、疑うことなく続けていたこと、そして他社のやり方、特に成功している事例を知らないことがその根本的な原因です。

自社の課題をどうやって客観的に正確に捉えるか、これは実は企業にとって大きな課題だと思います。

連載を読んでいただいた後、問題解決の全体像についてご興味があれば、下記の記事も参考にしていただければと思います。

参考：リーン開発、ジョブ理論とTOCによる製品開発の組織改革戦略

では、問題の構造化、第一回を進めていきます。

参考図書：

TOC（制約の理論）の基本を紹介している名著

Amazonで見る

組織問題を悪い症状（UDE）として捉える

最初に、弊社がこれまでお仕事を一緒にしてきた、この解析の対象となる企業はどんな企業だったかについてお話しします。

業種でいうと、計測器メーカー、精密機器メーカー、家電メーカー、金属素材メーカー、医療機器メーカーなどが今回の解析の対象です。

共通しているのは、ある主力の製品群を持ち、主力製品で収益の大部分を稼いでいるものの、主力製品にばかり頼っていられず、主力製品を継続しながら新製品や新規事業を起こすことを考えている企業になります。

トヨタのリーン製品開発手法の本質を捉え、
若手エンジニアのモチベーションによる改革を目指し、
トヨタの真似でない独自の世界観で
組織改革に挑む姿を描いています。

詳しくは、「製品開発組織の常識をぶち壊せ！！」出版のご案内を参照ください。

TOCのフレームワークの基本として、まず最初に「何を変えるか」、つまり現状どんな状態になっていて、変化させなければならない状態を明確化していきます。

TOC思考プロセスが戦略思考だと私が考える理由は、この3ステップをしっかり守ることがTOCのプロセスであるからでもあります。

そして「何を変化させるか」、つまり現状認識をしっかりとやることが問題解決の最重要ポイントだと思います。

その現状認識のための最初の作業は、組織の中で実際に起こっている悪い症状、悪い状態を明らかにしていきます。

現場の人たち、ミドルマネージャ、経営層の人たちのそれぞれの想いとして、起きている現象を捉えていきます。
この段階で、階層間での認識ギャップが出てくることもありますが、大事なことは”事実”ベースで現象を捉えます。

この実際に起こっている悪い症状のことを、TOCではUndesirable Effect（UDE、ウーディと呼ぶ）と言います。

UDEは、ルールとして明確な文章、つまり誰々が、何々を、XXする、あるいはXXしている、のような文章として表します。
文章にする理由は、曖昧さを無くし、個人の思い込みをできるだけ排除するためです。

ただし、せっかく文章にしても、曖昧さが残ったり、思い込みが入り込む可能性は多々あります。
そこをセルフチェックする方法もあるのですが、ここでは詳細は省略します。

これまで複数の製造企業で、UDEを検討してきて、共通で挙がったUDEを以下に列挙します。

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

いかがですか？皆さんの組織と共通性はありますでしょうか？

まず、上記の15個のUDEについて考えていくことにします。

さて、上記のUDEは、一つ一つが組織問題と言うことが出来ると思います。
通常、多くの組織、多くの企業では、これらの問題点（UDE）一つ一つに対策を考えていって、手を打とうとします。

多くの企業の活動計画や、戦略書を見ると、課題リストのようなものが作られ、上記のような問題点がリスト化され、それぞれに対策案や施策と題して、やるべきことが書かれています。

私の経験でも、こんな資料をたくさん見てきましたが、この10個以上の問題に対する個々の施策が実行されて、10個の問題がある一定期間で解決された事例を私は一度も見たことがありません。

そう、絵に描いた餅になっているのです。

TOCの考え方は、これらの15個のUDE（問題）は、実は一つか二つ、つまり少数のコア問題から連鎖的に発生していると考えます。

言い換えると、少数（理想的には１つ）の根本原因があって、そこから多くの（場合によってはすべての）問題が発生していると考えるのです。

上図の例のように、背中が痛んだり、寒気がしたり、熱が出たり、それぞれの症状に個別に手を打っていくのは、対処療法になって真の解決に結びつきにくいと考え、それぞれの症状を総合して、真の原因が肺炎であると特定してから、そこに集中して手を打つことで結果的にすべての症状を抑えるというのがTOCの考え方になります。

もう少しわかりやすい例で説明します。

製品開発組織で、品質問題が多発しているとします。

組織として、品質問題を抑えなければいけないと考えて、例えば、設計レビューを強化しようというアイデアが上層部から上がり、実際に施策として展開されたとします。

これで本当に品質問題がなくなるのでしょうか？

品質問題が市場に出にくくなるという効果はあるかもしれませんが、品質問題を発生させているメカニズムにはまったく手を打っていませんよね。

これも結局は問題の本質を見ないで対症療法を施したに過ぎないということになります。

問題の本質を捉える、ということが問題を構造化する最大の目的です。

組織問題の本質を捉えるためには、挙がった複数のUDEから根本原因を見つけていくのですが、このとき、対立解消図（クラウド）というものを使います。

クラウド（対立解消図）は、個々の問題（UDE）が起こっている背景を、シンプルに的確に、そして思い込みを排除しながら問題の構図を表現するツールで、クラウドを作ることから問題解決の糸口を見つけていきます。

TOCでは、組織の問題はすべて人間の行動によって起きると考えます。

また、組織内の問題は、誰か犯人（あるいは悪人）がいて起こしているのではなく、組織活動を成り立たせているトップの方針があって、そのトップの方針のもとに複数の中間目的、言い換えるとトップ方針の達成度を評価するための評価基準が複数あって、その複数の評価基準に基づいた行動がまったく両立しない状態になり、どちらか片方の行動しかとりえないジレンマに陥ることで、問題が発生すると考えます。