コア・クラウドのロジックを壊すインジェクション

前回は、コア・クラウドのジレンマから問題(UDE)が連鎖的に起こっている様子を現状ツリーとして表すところまでやりました。

第一回に挙げた15個の問題(UDE)が、一つのコア・クラウドと、二つの始点となるUDEから連鎖して起こっていることを検証できたわけです。

最終回である今回は、コア・クラウドに着目し、コア・クラウドの対立をどのようなアプローチで解消していくかを説明していきます。

このコア・クラウドの対立関係は、様々な組織内の事情で成り立っています。
この関係が示すことは、

  • Bの「短期の収益向上を優先する」ために、様々な問題を我慢しなければならない。
  • 多くの問題が存在することで、Cの「顧客満足と社員育成の両立を図る」ことが犠牲になっている。

ということになります。

また、このコア・クラウドの対立関係を成り立たせている背景には、いくつかの事情、仮定が存在し、クラウドの論理を示す矢印ごとにその仮定があると考えます。
その仮定は、企業ごとに異なるかもしれませんが、例として挙げてみると、A-B間のロジックで、「企業の価値を高める」ためには、「短期の収益向上を優先しなければならない」、何故ならば、「全社の収益が思うように伸びていない」からである。

このように、クラウドの論理の繋がりを成立させるための、なぜならば...という仮定をそれぞれ出して行きます。
今回のコア・クラウドのロジックを補完する仮定、前提条件を書き入れたものが下図になります。

赤い地肌のBOXに書き入れたものが、クラウドの矢印を補完する仮定ロジックなりますが、上図の仮定はあくまでサンプルで、会社ごとに状況は異なってきます。

クラウドのロジックを壊して、問題を解決していくアプローチの中で、この仮定も使っていくことになるので、良く考えて仮定を整理してください。

問題に対する解決策(ソリューション)を考えるということは、そのためにどんな施策を打つのか、つまりどんな行動をとるのかと考えるのが普通かと思います。もちろん、最終的には解決するために何か行動を起こさなければならないので、行動を考えること自体が間違いではありません。

しかし、TOC(制約の理論)では、問題の構造化の次のステップは、どんな状態にするのか、ということを考えます。
つまり、解決策(ソリューション)としても、施策や行動ではなく、どんな”状態”にすることで、様々な問題が変化(解決)していくかを考えていくわけです。

なぜ、すぐに施策や行動を考えないかと言うと、問題→解決するための行動とすると、対処療法になったり、すぐに出来ることを考えてしまって、大きな進歩になりづらい、ということもあると私は考えています。

すぐに解決のための行動を決めるのではなく、まずは、大きく変化するために、遠くにあるかもしれないゴール(目標)を決めてから、現状とゴール(目標)との差をしっかりと認識して、一歩一歩進んでいくようなプランにすることが重要であると考えるからです。

TOCでは、ゴール(目標)を設定するために、この段階での解決策を”インジェクション”という名前で、解決された”状態”とはどんな状態かを考えて、そしてゴール(目標)を決めていきます。

第四回で、多くの製品開発の状態を現状ツリーという形で表現しました。これが問題を構造化して捉えるということになり、TOCでは、まず、「何を変化させるか」という問いかけに対する答えになります。

そしてTOCの次のステップは、「何に変化させるか」ということで、これを”未来ツリー”という形で表現します。
今回の連載記事では、未来ツリーまでは作りません。理由は、現状ツリーは複数の企業間で共通性が考えられますが、未来ツリーは、企業ごとの事情、環境が大きく異なることから、共通に議論するのが難しいからです。

この最終回では、しかしながら、作った現状ツリーから、どのように未来ツリー(言い換えると問題に対する解決策を意識したゴール設定)を作っていくかを説明しておきます。

現状ツリーは、組織内の問題(UDE)が、コア・クラウドを起点にして負の連鎖で問題が繋がっていることを示しました。

これに対して、未来ツリーは、コア・クラウドのロジックを壊す理想の状態(インジェクション)を起点に、問題(UDE)が解決された状態が、今度は正の(ポジティブな)連鎖でどうつながっていくかを示していきます。

組織の中で起きている悪い症状をUDE(Undesirabe Effect)という定義をしましたが、このUDEの反対、つまり望ましい症状をDE(Desirable Effect)と定義します。
すると、未来ツリーは、下図のような形になります。

現状ツリーと形は似ています。ただ、未来ツリーは、インジェクションを起点に、良いことが連鎖していく様子を表します。

インジェクションは、クラウドから作り出していきます。
今回の事例では、ひとつのコア・クラウドと、2つのUDEが起点となっているので、コア・クラウドと、2つのUDEのクラウド、合計3つのクラウドを手掛かりにインジェクションをひねり出していきます。

インジェクションは、機械的に生まれるものではありません。アイデア勝負です。

以下は、あくまでもインジェクションをひねり出すためのアプローチ方法を示すものです。

 

 

インジェクションはクラウドのロジックを壊す、つまり論理性を突き崩すためのものになります。そして、ロジックを壊すには、いくつかの考え方があります。

  1. Dという行動をとってもCというニーズが満たされるためにどうするか?
  2. D’という行動をとってもBというニーズが満たされるためにどうするか?
  3. DとD’が奪い合っている資源(人、モノ、金など)を上手に活用して両立させられないか?
  4. BとCの2つのニーズを同時に満たす第三の行動はないか?
  5. 仮定の存在を無効にするか、変化させることで対立を解消できないか?

インジェクションは、繰り返しますが、施策や行動ではなく、”状態”です。
多くの人が、最初はこれが理解できなくて、取るべき行動を考えてしまいますが、そうではなくて、もしかするとちょっと遠い(実現は難しいかもしれない)と思うものでも構わないので、こうなったらいいなあ、という気持ちも込めて、ひねり出します。

ただ単に願望を考えるのではありません。その状態にすることで、クラウドのロジック、つまり対立構造が無効になることが確認できなければ、インジェクションとして意味がありません。

インジェクションは、少し時間をかけて、深く考えていきます。
インジェクションは、良い事ばかりではないかもしれません。

  • インジェクションの状態にするのに、大きな障害がある。
  • インジェクションの状態にすると、副作用が起きてしまう。
  • そもそも無理に決まってる。

実は、この3つの考えが、気持ちの中に潜在的に入り込んで(思い込み)、アイデアがストップしてしまいがちになるので、インジェクションのアイデアを出すときに、障害や副作用、何で無理だと思うかどうかなども、いっしょに書き出しておきます。

インジェクションは一つだけとは限りません。いくつかのインジェクションを組み合わせて、一つのクラウドのロジックを壊すことができるという場合もあります。

今回の記事のテーマ、製品開発組織の問題を構造化する、ということから導き出したコア・クラウドから、インジェクション(解決された状態)を考えるのは、まさに経営改革に直結するくらい大きな課題です。

インジェクションは、それ自体が、経営目標になるはずです。
3年間の中期経営計画策定などにも活用できるはずです。

インジェクションは、正の(ポジティブな)連鎖を考えるための起点になりますが、インジェクションを経営目標とすれば、この正の連鎖を実際に起こすための日々の活動をPDCAを回しながら実施していくことになります。
また、ローマは一日にして成らずの例えのように、正のスパイラルループを使って、少しずつ変化させて、成果も少しずつ刈り取りながら、数年後の大変化を起こしていくことを想像しながら、インジェクションをひねり出していくことが大切です。

インジェクションを実際に作り出すためのお手伝いを、弊社ではいくつかのクライアントさんと実施してきています。
インジェクションから、詳細な経営計画、組織の戦略策定につなげていくことに関しては、個別にご相談いただきたいと思います。

問題解決までの道のり

今回の5回にわたる連載記事「製品開発組織における問題の構造化」では、現状の組織内の問題が、どんな根本原因で、それがどんな連鎖で起こっているかを導く流れをメインで説明してきました。

つまり第三回で示したコア・クラウドが、たくさんの問題の根本原因になる対立構図を示し、第四回で示した現状ツリーが、その根本原因からどんな連鎖で多数の問題が起こっているかを突き止めた図であるということです。

そして、最終回の今回は、コア・クラウドからインジェクション(解決された状態)を導く方法を説明しました。

ここから、実際に解決すつための行動計画を作っていくまでを、TOCの流れに沿って簡単に示して、今回の連載記事を締めくくりたいと思います。

  1. コア・クラウドを特定する(第三回まで)
  2. 現状ツリーで問題を構造化する(第四回)
  3. インジェクションをひねり出す
  4. インジェクションから未来ツリーを作る
  5. インジェクションの副作用を考慮して未来ツリーを修正する
  6. 障害を乗り越えてインジェクションを実現するためのステップ(中間目的)を設定する
  7. 中間目的を一歩ずつ達成していくための行動計画(移行ツリー)を作る

TOCのフレームワークでは、まず、「何を変えるか」を特定するのが、上記の1、2のステップになり、「何に変えるか」が、3、4、5のステップとなります。

今回、記事の中では触れていませんが、「何を変えるか」「何に変えるか」をやって、その次に「どうのように変えるか」ということに進むのがTOCの考え方で、この部分が6、7のステップとなります。

7まで進むことで、問題解決のための詳細な行動計画が出来上がるということになります。

TOCのフレームワークは、問題に対して、その場しのぎの対策に飛びつくことを避け、しっかりと現状を認識し(「何を変えるか」)、高いレベルでの達成すべきゴールを設定し(「何に変えるか」)、そして具体的で、障害や副作用なども十分に考慮した計画を立てます。

そして、このフレームワークを通して、下記に示す組織内の6つの抵抗を克服します。

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

いかがですか?皆さんの会社にも、このような上層部や部門間での抵抗はありませんか?
これらを意識して、他者を説得していくこともTOCのフレームワークの大きな狙いなのです。

さて、5回にわたる連載にお付き合いいただき誠にありがとうございます。

問題解決のフレームワークとして、TOC(制約の理論)のフレームワークを活用し、特に「何を変えるか」というフェーズで、UDE、クラウド、現状ツリーというものを使って、製品開発組織の問題を構造として捉えるところをやってみました。
あくまで、私どもが見てきた企業における共通の問題を見つけようという試みでやってみたことです。

共通の問題という点で、記事を読んでいただいた皆様からも、ご意見を頂戴できれば大変うれしいです。

また、問題の構造化が出来た後に、「何に変えるか」「どのように変えるか」というアプローチについて、大まかな流れを説明してきました。

もし、今回の問題の捉え方について、ご賛同いただけ、更に問題解決をいっしょにやってみたいという企業経営者の方がいらっしゃいましたら、ぜひ弊社としてご協力させていただきたいと考えております。

まずは、下の「お問い合わせボタン」よりお問い合わせください。

 

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

第一回「組織問題を悪い症状として捉える」へ戻る