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

連載記事の内容

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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