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

連載記事の内容

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

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

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

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

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

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

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

ということになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

※ 筆者がメーカー企業在籍時に経験したこと、コンサルとして企業支援した実体験をもとに、TOCのフレームワークを使った製品開発組織の組織改革をストーリーにしました。

実体験ベースなのでかなりリアルな物語になっています。今回の記事では解決策まではご説明できていませんが、本の中では解決策を事例として紹介しています。

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

参考記事：

「ザ・ゴール２」から学んだ思考プロセス

ベストプラクティスを研究し、インジェクションを生み出す

インジェクションはアイデア次第なのですが、もっとも有効な方法は、製品開発におけるベストプラクティスから学び、取り入れられることを積極的に取り入れるということです。

弊社で推奨しているのは、トヨタのリーン製品開発、及び新たなマーケティング手法として注目されるジョブ理論を取り入れて成功している事例を学び、手法を形だけ真似るのではなく、手法の本質を理解してエッセンスを取り入れることです。

リーン製品開発の３つの重要要素である

チーフエンジニア制
セットベース開発
A3報告書

それぞれの狙いや実践のポイント、またそれぞれが連携して目指しているものを深く理解した上で、インジェクションとして取り入れて、問題解決につながるかを検証していきます。

また、ジョブ理論は、製品視点を排除して100%顧客視点でモノゴトを考える新しいマーケティング手法ですが、この手法そのものを学ぶことも大事ですが、そもそも開発技術者が製品企画を行うことについて、そのメリット・デメリットを考えるところに、インジェクションとしての可能性が出てきます。

トヨタのチーフエンジニア制は、技術開発だけでなく、マーケティング、設計、製造調達、サービス、営業までを一気通貫で管理するスーパーマンとしてのチーフエンジニアを考えると同時に、そもそもトヨタでは開発のプロジェクトリーダーが製品企画を行っているという点を注目してみると、今までの製品企画は企画専門の部門の仕事だという固定概念を打ち壊すことが出来るようになります。

インジェクションは、そんなことは無理だとか、出来ないとかという思い込みを排除しなければ、良いアイデアになりません。

リーン製品開発手法やジョブ理論に限らず、世の中で採用し成功しているベストプラクティスを学ぶことで、良いインジェクションを生み出していきましょう。

第一回でお話ししたように、弊社では、TOC（制約の理論）のフレームワークを使って開発組織の問題を構造化し、根本課題を発見し、リーン製品開発手法をベストプラクティスとして捉え、そこからの学びを組織課題解決のソリューションとして導入していく方法をクライアント企業と一緒に進めています。

弊社のアプローチについては、別記事「リーン開発、ジョブ理論とTOCによる製品開発の組織改革戦略」で更に詳細に説明しています。

参照ください。

関連記事：

トヨタ式リーン製品開発とは

無償配布：「連鎖式組織改革法」のプレゼン資料

トヨタの組織力から学び、TOC（制約の理論）の戦略アプローチを採用した弊社独自の手法！！

「連鎖式組織改革法」のpdf版をご希望の方に無料で進呈しています。

50年勝ち続けられる組織を作る

効率化、チェックリストなしで実践できる組織改革の仕組み

この方法があればトヨタのような強い組織が作れる！！

無料にてPDFをダウンロードできます。下記フォームよりお申込みください。

「連鎖式組織改革法（pdf）」無料ダウンロード

問題解決までの道のり

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

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

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

さらにインジェクションを導くのに、世の中のベストプラクティスを学ぶこともお話しし、弊社ではリーン製品開発手法を活用しているということもお話ししました。

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

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

TOCのフレームワークでは、まず、「何を変えるか」を特定するのが、上記の１、２のステップになり、「何に変えるか」が、３、４、５のステップとなります。

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

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

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

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

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

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

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

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

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

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

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

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