連載記事の内容
第四回 根本原因を因果関係で検証してみる
根本原因を因果関係で検証してみる
前回、３つのUDEから作られた３つのクラウドから、実際に開発組織で起こっている状況を考えながら、一つのコア・クラウドを作ってみました。
もう一度、コア・クラウドを下に示します。
このクラウドでは、技術者を技術エリア毎に集め専門領域に特化させ、分業化することで、既存製品の開発を効率化させることを優先し、顧客満足や社員の育成の両立ということを犠牲にしていることを表しています。
短期の収益を向上させることと、顧客満足と社員の育成を両立させること、どちらも本来は捨ててはいけない考え方でありながら、行動がひとつしか取れないことで、片方しか達成できないジレンマを表していますが、このジレンマによって、最初に起きる組織内の悪い症状は何かを考えてみます。
ここで、もう一度、第一回目に挙げた15個のUDEを列挙してみます。
- 雑用に多くの時間が取られている
- 責任者が不明確になっている
- 手戻りが多発している
- 失敗を糾弾される
- 同じような失敗が繰り返される
- 製品全体を理解できる技術者が減少している
- 若手の離職率が上がっている
- 新たなコンセプト製品が長い間生まれていない
- ベテランの知識、ノウハウが会社に残っていかない
- 他の人の仕事内容、状況がわかっていない
- 日程遅れが常態化している
- 自主的なアイデアの試作や提案が出来ていない
- 若手が技術力の伸びを実感できない
- ノウハウが資料として残っていない
- 顧客の真の課題、潜在ニーズを把握できていない
技術者の効率活用を進めることで最初に起こりそうなのは、「製品全体を理解できる技術者が減少している」かなという気がします。
技術者を分業化して効率的に活用するために、いわゆるマトリクス組織にすることで、一旦、「他の技術領域のメンバーとコミュニケーションが希薄になる」ということや「製品全体を開発する状況を間近でみる機会が減少する」ということが起こってから、徐々に専門領域は詳しくても、全体の繋がりについて詳しくならない人が増えていくということが考えられます。
また、専門組織が細分化され、個々の技術領域を連結して製品全体を作り上げていくときに、専門領域間の連結箇所での問題が起こりやすくなっていきます。
つまり、技術領域内の技術革新は進むものの、領域間のインターフェースで問題が起きやすくなっていきます。
良く言われるのは、一人で全部を開発すれば問題は少ないけど、人を増やして仕事を分担すると、人の数だけインターフェースが発生し、そこで問題が起きやすくなるというのと同じことかと思います。
コア・クラウドのジレンマから、最初に起こる悪いことは、
- 他の技術領域のメンバーとコミュニケーションが希薄になる
- 製品全体を開発する状況を間近でみる機会が減少する
- 専門領域間の連結箇所での問題が起こりやすくなる
という３つの状況が起こると考えられます。
これらは、最初に挙げた15個のUDEには入っていませんが、追加の考え方として捉えます。
ここまでの所を、悪い症状の因果関係で図示してみます。矢印の元から先に向けて因果関係として結んでいきます。
コア・クラウドのジレンマから、３つの症状が起き、そのうちの２つ「他の技術領域のメンバーとコミュニケーションが希薄になる」と「製品全体を開発する状況を間近でみる機会が減少する」という症状から、「製品全体を理解できる技術者が減少している」というUDEに、連鎖的に繋がるという考えです。
図で、黄色い背景の四角で書かれているのが、元々挙げたUDEで、白い背景の四角は追加した症状とします。また、２つの矢印に楕円が書かれているのは、２つの矢印のANDロジック、つまり両方が成り立つことで、矢印先の結果が生まれるということを示しています。
このような考え方で、上の図を更に拡張していきます。
コア・クラウドのジレンマから派生していく負の連鎖で、どんな問題が繋がっていくのかを見ていくわけです。
色々と検討した結果、下図のような連鎖が出来上がりました。
第一回に挙げた15個のUDEがすべて図に表れています。
黄色い背景の四角が、元々挙げたUDEで、白い背景の四角は追加した症状になります。
15個のUDEのうち、13個については、コアクラウドのジレンマからの連鎖で繋がっていることがわかります。
しかしながら、※印のついた２つのUDE、「顧客の真の課題、潜在ニーズを把握できていない」と「ノウハウが資料として残っていない」については、他のUDEとの関係はあるものの、下からの矢印で繋がっていず、つまり、コア・クラウドからの連鎖として、起こっていないことがわかります。
これら２つのUDEは、それが出発点となって、他の症状を引き起こしていることになります。
すべてのUDEが、コア・クラウドのジレンマからの連鎖、つまり因果関係で繋がっているとすると、コア・クラウドを解決することができれば、すべてのUDEが解決できる可能性があることを示すことになります。
しかし、今回検討した図では、２つのUDEが連鎖とは関係なく、発生していることになり、つまり、すべてのUDEを解決するためには、コア・クラウドとこれら２つのUDEを解決することで、すべての問題が解決できるかもしれないということになります。
また、図の左下に、ピンクの背景の四角があります。「機種ラインナップの効率的開発が求められる」という記述がありますが、これは、「専門組織の力が強くなる」という症状が起きるための前提条件になります。
逆にこの前提条件がなければ、コア・クラウドのジレンマ自体も起きない可能性があり、コア・クラウドを解決するための糸口と考えることもできるわけです。
このコア・クラウドのジレンマから始まったUDEやその他の症状の連鎖を因果関係でつないだ図のことを、TOC（制約の理論）では、現状ツリー（CRT）と呼びます。
そして、これが開発組織における問題の構造ということができるのです。
開発組織に限らず、たくさんの問題は複雑に絡んでいるのですが、多くの場合、その根本の問題は少数であることを示しています。
現状ツリーは、細かいところまで掘り下げると、もっと複雑な図になることもあります。
論理的に追いかけると、上手に表れていない条件や症状の連鎖を見つけることも出来るかもしれません。
大事なことは、連鎖の元になるものが漏れなくつかめているかということです。
今回の検討では、コア・クラウドと、２つのUDEが出発点になって、すべての悪い症状が繋がっているという結論になりました。
この状況、つまり悪い症状が３つの根本問題からの連鎖で説明できることを、組織内で同意できるかどうか、現場とマネージメントとで、納得できるかどうかが大切です。
この連鎖の状況を、まずは組織内で共有し、深い議論をしてみましょう。
次回は、この現状ツリーから、開発組織を改革するための解決策をどうやって見つけていくかについてお話ししたいと思います。
では、次回もお楽しみに。
＞＞最終回「コア・クラウドのロジックをリーン開発手法」へ進む
※ 筆者がメーカー企業在籍時に経験したこと、コンサルとして企業支援した実体験をもとに、TOCのフレームワークを使った製品開発組織の組織改革をストーリーにしました。
実体験ベースなのでかなりリアルな物語になっています。今回の記事では解決策まではご説明できていませんが、本の中では解決策を事例として紹介しています。
ぜひ、書籍の方も参照ください。詳しくは「製品開発組織の常識をぶち壊せ！！」出版のご案内を参照ください。
TOCを使った組織問題の解決手法
今すぐ確認する
この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！
