目的

要望などから問題を定義しようと思っても、そもそもの要望の整理が体系化されていないことから、正しい問題の定義がなかなか困難であると感じていた。

正しくない問題に対して、解決策を実行しても新たな副作用を発生し、
さらに問題が大きくなりかねない。
そこでTOCの思考プロセスツリーを用いて、より精度の高い問題定義、
要求定義を実現できるようになりたい　という動機から以下の内容を残すにいたった。

前提知識

DEとUDE

DE(Desired Effect:好ましい結果、状態)、
UDE(UnDesired Effect:好ましくない結果、状態)、
などのTOCで使う用語の内容を前提として使用する。

TOC(制約理論)では、真因であるボトルネックにのみ対策を集中させることで、最小限の労力で最大限の効果である全体最適を目指している考え方です。

帰納法、演繹法、アブダクション

推論で使う３つの思考を使うことを前提とする。

帰納法

帰納法は、具体な個々の事実から
「こんな一般法則があるのでは？」というものを抽出するのに使う。

演繹法

演繹法は、既知の仮定に今ある事実を当てはめて、結果を予測したりすることに使う。
実際の結果が予測と異なれば、当てはめた仮定が違っていたということの検証もできる。

帰納法と演繹法の関係性

帰納法と演繹法はたがいに関係しあっている。
帰納法で明らかにした一般法則を仮定として演繹法を使う。

図でいうと以下のような感じです。

アブダクション

起きた現象から仮説を立てて、メカニズムを分析するのに使う。

大前提条件

組織内のどのスコープ内を対象とするのか？を明確にする。

たとえば、１つの事業全体なのか？　それとも組織全体なのか？
(※　１つの事業しか展開していない組織では、事業のスコープと組織全体のスコープが一致するが、ここでは１つの組織に1つ以上の事業が展開されているものとする。)

ここを明確にしない状態では、対象とするステークホルダーも明確にならない。

その際にいったん関心の強さや権限の強さといったものは無視する。
ただし、各ステークホルダーごとの視座の高さや、ステークホルダーの抜け漏れは後々重大な手戻りを発生させかねないので、
以下のようなフレームワークを用いて、観点の抜け漏れなどを予防することをお勧めする。

①UDE(好ましくない状態)を列挙する

UDEを一通り洗い出す

「こんな悪い状態を取り除きたい。そのためにこんな機能のものがほしい。」というものをステークホルダー全体的に聞き出す。

このとき当然UDEは、本来の自分たちの理想形の状態である
DEとのギャップから出ている不満であるため、ここで同時にDEも定義してしまう。

DEの定義

その際に「その悪い状態を取り除いた結果、どうなりたいの？」といった問いかけをすることでDEを明らかにする。

UDEとの差の激しいと思われる部分だけに絞り込んでしまうのは、ちょっと危険！！
今は許される小さなそのギャップが、後述のインジェクションを実行した結果、一気に大きくなったりすることもあるのと、
一時リスクを正しく把握するためにも、残しておくことを薦める。

※注意事項

この時、絶対に気を付けたいのが

「こんな機能のものが欲しい」という部分ではなく、その前提である「こんな悪い状態を取り除きたい。」という部分の方に着目する。

ITで多いことだが、ほしい機能だけが列挙されていて、
結局どうなりたいのか？　どんな痒さがあってそれを取り除きたいのか？　が明らかにされていないということが多々ある。
ようは、手段が目的化してしまっているケース。

目的は悪い状態のUDEから、良い状態DEになれることなんだから、
それを実現する機能ならなんだっていい。
その際にもともと「この機能がほしい」と言われていたもの以外の選択肢を考えて、より安くより短い期間で実現できそうなものを考えることが、質のいい要件定義へとつながっていく。

似たようなUDEをまとめる

このUDEの中で、自分たちでコントロールできるものとそうでないものとに分離して、コントロールできないものに関しては一旦除外して考える。

いまはコントロールできないものであっても、
今後組織の範囲を拡大した際などに、コントロールできる変数に代わる可能性があるため、いったんはしによけておく程度でいい。

その上で、似たようなUDEに関してはグルーピングしてしまう。
おおよその目安、どんなに多くても片手に収まる量でないと、
後々のコアな対立関係を発見するのに苦労する。
その方が本質を抑えられており、この後の工程がだいぶ楽になるからである。

②-a現状問題構造ツリー(CRT)を作成する

通常であれば、ここでCRTの作成に行き、UDEを生み出す原因分析を行う。
よく聞く「なぜ　なぜ分析」というものである。

これはUDEという、
最終結果から原因をアブダクションであぶり出していくので、
階層が深くなればなるほど、その置いた仮定の妥当性が落ちていく。
よって「これが真因ではなかろうか？」というものの的中率が低くなりやすい。

それに対して、TOCのクラウド手法では、

長いこと解決しない問題の裏には、根本原因になっている対立関係があり、それが解消していないから。

というところから考えるという思想がある。

これは複数の問題を発生させている、本当にかゆい原因は１つに収束されるという思想をベースにしています。

つまり、
従来の方法がトップの結果であるUDEからトップダウンで真因を明らかにするのに対して、
クラウド法では先に真因のあたりを付けて、それがトップのUDEを引き起こしていることを現状ツリー(CRT)で証明する　という全く異なる思考法である。

ここで、よくある従来のなぜなぜ分析と、クラウド法を使った方法のメリットデメリットを表にする。

	メリット	デメリット
従来手法	簡単で直感的	・時間がかかる　・真因の妥当性が低い
クラウド法	本質に早くたどり着きやすい	コアクラウドを定義するのが難しい

②-b クラウド図を作成する

ここでは上記でグルーピングしてある程度まとまったUDEリストに対して、クラウド図を作成し、そのUDEを引き起こしていると思われる対立関係を明らかにする。
正式な書き方は特に意識することなく、紙とペンでグループワーク形式に行うことをお勧めします。

その際に、複数の個々のクラウド図からさらに一段階一般化して、
それらに共通するコアな対立を明らかにする。(帰納法)

この帰納法を使ったコアなクラウド図をつくるのは、
ここの対立関係を解消した所で、結局全体最適にはならないからだけでなく、
個別の対立を解消するだけにとどまり、コストの無駄遣いになりかねないからである。
帰納法を使ってより本質な対立関係を浮き彫りにし、
そこに潜んでいる【誤った仮定(バイアス)】を可視化する。

対立解消図の考え方については、長くなるので別記事にて記載する。

ここで対立を生んでいる仮定つまり、【思い込み】である
方針系制約を明らかにする。

③現状問題ツリーへ変換する

ここでは上記で可視化したコアな対立が、本当に真因といえるのか？

そのコアクラウドが多くのUDEを結果として誘発していることを現状問題ツリーで可視化し、ボトルネックであるということを証明する。

従来のアブダクションを使った、なぜなぜ分析とは違って、
ボトムアップに根本原因から表層で表れている、①で明らかにしたUDEへの因果関係を図示する。

その際には、演繹法を使っている。
原因と矢印の先の結果との間にどのような仮定を置いたのか？　ということも図に示す。

その際にクラウド図から90度回転したような図の構成になる。

このクラウド図は、

Aするためには、Bがなくてはならない。
Bするためには、Dしなくてはならない。
なぜなら、【置いている仮定】があるからだ。

というように必要条件ロジックで読むことになる。
(詳しくは、クラウドの記事にて)

これを十分条件ロジックに変えることで、
目的＋思い込みによって、表面上の行動を起こしており、
それが結果的に大量のUDEを生み出していることを示せればいい。
具体的には、Bかつ【BD間に潜む仮定】の結果、Dしている
といった具合です。

すべてのUDEに繋がらずとも、重要なかつ自分たちでコントロールできるようなUDEの多くに繋がるようであれば、
コアクラウド図上の対立が真因であると示したことになる。
結果的に、その対立を生み出す仮定が、組織に蔓延った根深い足かせとなる風土、つまり方針制約であるといえる。

ここまでが根本原因の発見フェーズである。

ただし、それぞれのステークホルダーが本心でUDEなどを話してくれたりするわけではない場合、なかなか上記のように理想形で問題の定義ができない場合もある。

④対立を解消する策を考える

次の流れとして、コアクラウド図で明らかにした崩せる仮定の
方針制約に対して、新たな解決策(インジェクション)を考える。

この時、考えられるインジェクションは複数あっていい。
その中から一番自分たちの組織的なケイパビリティにマッチしたものをチョイスしたらいい。

⑤インジェクションがDEを生み出すのか検証する

インジェクションの案を考えただけでは不十分である。
そのインジェクションがもともとUDEであったものを本当にDEにするのかを検証する。この図は未来構造ツリー(FRT)と呼ぶ。

図のようにインジェクションを実行した結果、ほとんどのUDEがDEになることを証明出来たら、そのインジェクションは実行すべき解決策であるということ。

インジェクションの結果起こる副作用への策を考える

しかしここで注意しておきたいことが、

インジェクションを単体で実行したら副作用が起きる可能性大

ということ。

インジェクションを実行前の状態+外部環境のセットによって、
何も起きていなかった場所に、インジェクションと環境条件がセットになって新たな副作用が発生してしまう。(下図のように)

それを事前に予測し、それに対する対抗策を事前に考えておく。

考えておくだけで実行に移すのかどうかは別の話！！

アジャイルっぽく進めるのであれば、
予測モデルだけ作成して、ステークホルダー同士で共通認識持っておいて、インジェクション実行後に、副作用が許容できない範囲で起こりそうなら、その時点で対抗策を実行する。　と考えてもいい。

これは丁度１回目のイテレーションで、インジェクションを要件として定義し実行。
副作用に対する策が必要だなと判断した段階で、
２回目のイテレーション計画に策を含めるといったようにする。

いずれにしても、すべてを予測することは不可能なので、
不確実性が高いなら高いほど、素早く小さく実行して学習して、
その中でも脅威を常に察知できるようにしておく。
そして、必要に応じて発生した副作用に対する策を実行する。

補足事項

TOCの現状ツリーや未来ツリーでは、抽象度を意識していないが、
匠メソッドのように
各ステークホルダーの関心のあるビューの抽象度ごとに管理した方が
メンテ性は増す。

その内容については次の記事で記載する。