対立解消図(クラウド)の作り方

第二回目は、まずTOCのクラウド(対立解消図)の説明から始めていきます。

第一回でお話ししたように、組織の中で起こる問題は人間の行動によって起こされると考えます。

そして人間の行動は、組織の評価基準で決まってきます。これは人事考課の基準と考えてもいいと思いますが、組織として成果を上げていくときに、組織長が掲げる目標や、直接的に組織長から指示のあった行動目標を目指して人々は行動します。これを”評価基準”、あるいは行動の”目的”とします。

さらに、この評価基準は、もっと上位、経営層のレベルが考える組織の方針から生まれてきます。

トップが考える”方針”があって、その方針に沿った形で、中間管理職が掲げる中間目標、あるいは評価基準が複数出来てきます。

そして人々は、複数ある評価基準のいくつかを請け負って、あるいは選んで行動を起こします。

この辺りの会社の仕組みから生まれる悪い循環は、実は社内にいると気づきにくいものです。

なざなら、このような行動の連鎖は当たり前のことと認識されているからです。

もっとやっかいなのは、組織間にまたがって異なる中間目標によって、異なる行動が生まれることかもしれません。

いずれにしても、組織内では当たり前になっていたとしても、改めて客観的にこのジレンマを読み解いていくことで、問題の本質的改善に繋げます。

そのためのツールの一つが対立解消図、あるいはクラウドということになります。

クラウド(対立解消図)は、以下のようなA、B、C、D、D’の5つの箱に適切な文章(言葉ではなく述語を含む文章)を入れることで完成させます。

 

 

作り方は、まず、UDEを引き起こしている”行動”をDに入れます。

次に、D’には、Dと反対の行動、あるいは本来取るべき行動を入れます。ここで大事なことは、DとD’は組織内で両立しないということです。

DとD’を入れたら、次にDとD’それぞれの目的を考えます。その行動の目的は、行動を起こすのはなぜか、あるいは前述のように人々の評価基準になって、その行動を起こさせている事柄は何かを考えて、適切な文章を入れてみます。
Dに対してはBを、D’に対してはCを入れます。

クラウドで最も大事なのは、このBとCの異なる評価基準をどう見つけるかで、この2つの評価基準によって組織内でジレンマが発生していることを捉えようとします。

最後にAですが、これはBとCの共通の目的です。BとCが中間マネージャの組織目的だとすると、Aは経営トップの大目標、あるいはトップ方針ということになると思います。
つまり、BとCよりもAの方が、抽象度が高くなる、あるいは高い視点からみたものになります。

クラウド作成は、慣れないとなかなか難しいかもしれません。
A→B→D、あるいはA→C→D’で、抽象度の高いレベルから中間、そして最後は具体的行動と言う形で視点が異なる捉え方をします。
さらに、もともとのクラウドの狙いは、問題を起こしている組織内のジレンマを的確に、シンプルに、そして思い込みを排除して捉えることであり、国語力、文章表現力が必須になってきます。

さて、それでは前回挙げたUDE(悪い症状)を例にとって、クラウドを作ってみましょう。

「責任者が不明確になっている。」というUDEについて考えてみます。

皆さんも一緒に考えてみましょう。どんな状況が想定されてこのUDEが挙げられるかです。

開発プロジェクトは、本来、一つの開発チームで、一人の強力な推進リーダーの元で進んでいるのが理想ではないでしょうか?
ここで、異論のある方ももしかしたらいらっしゃるかもしれませんが、まず、この状態を出発点にして考えてみます。

この強力な推進リーダーは、プロジェクトの対象になっている製品について、幅広い知識を持っています。
リーダー自身の専門分野だけではなく、専門外の技術などについても意見を言ったり、決断をしたりしなければなりません。
リーダー以外のメンバーは、リーダーを信頼するし、悩みごとなどをすべてリーダーに相談します。
つまり、すべての情報はリーダーに集まります。

また、このようなリーダーの日々の仕事は、すべてのメンバーから見える状態になっています。
なので、メンバーは、他のメンバーが何をやっているのか、どんなことで悩んでいるのかを自然に知っていることになります。
これが、ある意味、うまく行っている状態とします。

で、私自身が感じる、最近の多くの企業では、専門組織を中心にしたプロジェクト体制を取っています。
技術者の専門分野を明確化し、専門分野の技術を企業の製品群で共通化し、かつ効率的に専門技術を製品に展開することが目的なのだと思われます。

マトリクス組織などと呼ばれることもありますが、専門分野ごとに分かれた専門チームが、複数の製品機種を効率的に開発することが出来るので、製品開発を効率化することと、製品間でバラバラなものが出来ないような狙いもあるかもしれません。

ひとつの製品を担当するチーム(これを縦組織という)と、専門分野をまとめる組織(これを横組織という)が出来て、縦と横をうまくコントロールしようというのがマトリクス組織なのですが、ここに、縦組織のリーダーと横組織のリーダーが生まれます。

マトリクス組織が生まれたばかりのころには、まだ縦組織の方が強い傾向があり、縦組織のリーダーのメンバーへの影響力は強力で、製品開発もうまく行っていたのだと思いますが、マトリクス組織が長く続くと、メンバーの専門組織への帰属意識は徐々に高まり、メンバーは縦組織リーダーよりも横組織リーダーとの距離が縮まり、縦組織リーダーへの情報が途絶えていきます。
さらに、他のチームメンバーも、専門組織内のメンバーの行動は見えるのですが、他の専門組織のメンバー、つまり同じ製品を開発している他の専門技術者の動向が徐々に見えなくなっていきます。

専門組織は複数あるので、いわゆるリーダーと言われる人の人数は増えていきます。そして、メンバーの専門組織への帰属意識が縦組織への帰属意識よりも高くなると、縦組織リーダーの影響力が衰退していきます。

影響力が小さくなって、情報も持たなくなった縦組織リーダーに対して、横組織リーダーは影響力を増し、製品プロジェクトへの発言力も増していきます。
しかし、横組織のリーダーは、開発対象となる製品に対しては責任がありません。また、専門分野に固執していく傾向を示して、製品を立ち上げて成功させるという目的と違う発言をしていきます。

並行して縦組織リーダーの力量が低下していきます。異なる技術分野のメンバーからのリアルタイムで真剣な情報が入ってこなくなることによって、縦組織リーダーが名実とも弱っていくわけです。

異なる方向を向いた中途半端なたくさんの横組織リーダーと、弱体化した縦組織リーダーの一体誰に責任があって、その責任を全うしてくれるのか、という問題が浮き彫りになったというのが、この「責任者が不明確になっている。」というUDEの本質ではないかと考えてみます。

ここにあるジレンマは何でしょうか?

私は、複数の機種を効率的に開発するためにマトリクス組織を加速したことが問題を起こしたのではないかと考えます。
つまり、機能別組織(横組織)を強化することで複数機種開発を効率化することと、機種別の組織力(縦組織)を維持することで、個々の機種を最良に開発しようとすることが対立した結果起こったのではないかと考えられるのではないでしょうか。

そして、複数機種を効率的に開発することも、一つ一つの機種をしっかりと開発することも、どちらも”良い製品を開発し続ける”という共通に目的のもとで起こったことなのではないかということです。

この2つの目的自体が対立しているのではなく、2つの目的はあくまで同時に達成したいのに、それぞれの目的で全く異なる行動をとる必要に迫られてジレンマが起きるという構造です。

これをクラウドで表現すると、下図のようになります。

 

 

機能別組織(横組織)を強化することと、機種別組織力(縦組織)を維持することが、ジレンマとなって、「責任者が不明確になっている」というUDEを引き起こしていると考えます。

トップから見ると、とにかく良い製品を継続して開発して会社の利益を上げたいという大方針を持ち、その下の中間レベルのマネージャーは、トップの意向を受けて、効率的に同時に複数の機種を開発できる体制にして、収益に貢献したいと考えて機能別組織を強化していきますが、個々の機種の品質を重視するという目的を犠牲にして、かつ小さな責任者が乱立して、本当の責任者が不明確になっていくというUDEが起こっているわけです。

ただし、まだ考える要素はあります。
複数機種を効率的というのが、つまりラインナップを拡充することに注力していると言い換えられること、また、個々の機種の品質を重視するのいうのが、少し漠然としていて、チャレンジする開発ならこうせざるを得ないのでは、という見方もあるし、また、直接的に専門分野を超えた横のコミュニケーションを充実することがマトリクス組織にしない目的かもしれないなど、色々と考察も生まれます。

もっと、簡単にいうと、優秀なリーダーが育っていないだけで、もともとリーダーになる資質の人が少なかったなどという考えもあるかもしれません。
会社ごとの事情も異なるので、このクラウドしかない、ということではありませんが、新たなチャレンジや、一つの機種への集中、あるいは横のつながり強化などよりも、ラインナップ拡充、リスクの少ない製品開発を重視してきたことが、強いリーダーを作れない体質にしてしまったことも、原因になっていそうですね。

このように、UDEを出発点にして、問題の本質を深く考えていくことが重要で、まずは、一つのUDEに対して、一つのクラウドを作ってみることが出来ました。

 

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

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

 

クラウド作成の難しさ

クラウドを作る手順と作り方は上記で説明した通りなのですが、実は慣れないと中々難しくもあります。

間違いやすいポイントがいくつかあるので、お伝えしていきます。

最初に注意して欲しいのは、クラウドは起こっている事実を客観的に映し出すものという理解をしっかりしていただくことです。

つまり、自分の意見を反映するものではありません。

今起こっていることを鏡に映して見せるような感覚で作成します。

私自身も最初に嵌った一番多い間違いは、ソリューション的な発想をクラウドに入れてしまうことです。

DとD’が行動であることも忘れないようにしましょう。

そして、DとD’という行動を起こす目的がBとCであり、Aは更に上位の目的、BとCを包含する大きな目的です。

D→B→Aの順で具体的行動から、抽象度が上がっていくということも掴んでいただきたいポイントです。

 

クラウド作成のトレーニング方法を実例で解説します。

雑誌記事などを読んで、登場人物になり切った上で、直面する問題をUDEとして捉え、クラウド(対立解消図)を作成する問題集と、弊社セミナー受講生の実際の回答例、及び講師からのコメントを掲載しています。

クラウド作成トレーニングとして活用ください。

TOCのUDE、クラウド(対立解消図)で問題の本質を読み解くトレーニング

 

クラウドの検証

クラウドをしっかり作成することが、問題解決という結果に繋がります。

クラウドが正しく出来ていない、つまり現状を正確に、また客観的に捉えられていなければ、問題解決の糸口がつかめないことになります。

なので、クラウドが正しく出来ているかを作成後にチェックします。

チェックの仕方は、音読によって論理に違和感がないかをチェックする方法で行います。

クラウドは、必要条件ロジックでつながっています。

以下のように音読してチェックします。

Aであるためには、Bでなければならない。

Bであるためには、Dしなければならない。

Aであるためには、Cでなければならない。

Cであるためには、D’しなければならない。

DとD’は両立できない。

これを声に出して読み上げて、違和感を感じる部分があれば、それはクラウドが正しく出来ていない可能性があると考えます。

今回作成したクラウドを検証してみます。

良い製品を開発し続けるためには、複数機種を効率的に開発しなければならない。

複数機種を効率的に開発するためには、一人のリーダーに権限を集中してはならない。

良い製品を開発し続けるには、個々の機種の品質を高めなければならない。

個々の機種の品質を高めるためには、一人のリーダーに権限を集中しなければならない。

一人のリーダーに権限を集中しないことと、一人のリーダーに権限を集中することは両立しない。

どうでしょうか?

読み合せて、ロジックの繋がりに違和感がなければ、クラウドの構成は問題ないということになります。

 

参考図書:

クラウドの作り方をやさしく解説


Amazonで見る

 

次回は、さらに別のいくつかのUDEに対するクラウドを作り、すべてのUDEに共通するクラウドが書けないかを考えることで、すべての問題の根本原因を探っていきます。

>>第三回「問題の根本(コア・クラウド)を見つける」へ進む

<<第一回「組織問題をUDEとして捉える」へ戻る

 

 

 

TOCを使った組織問題の解決手法
今すぐ確認する

 

この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします!!