« Scrumの入門資料リンク | トップページ | Stackoverflowの日本版Qiita~知識の共有が自己の知識を成長させる »

2014/02/28

TOCの思考プロセスの使い道~プロマネの説明責任に応用する

ゴールドラット博士の論理思考プロセス―TOCで最強の会社を創り出せ!」を読んで、TOCの思考プロセスをプロマネの説明責任に適用できそうな気がした。
ラフなメモ書き。

【1】背景
【1-1】プロジェクトマネージャの仕事のほとんどは、利害関係者の間で発生する課題の解決、ないし利害関係者への調整だ。

例えば、顧客は、システムのこの要件は納期までにリリースされないと困る。
しかし、開発チームは、その要件は実現可能性が難しく、納期までに間に合わない、と言って、対立が生じる。

あるいは、テスト工程で一挙に問題が噴出し、要件漏れ、設計漏れ、単体テスト漏れなどの障害が多発し、何が問題なのか、という構造も見えなくなる時もある。

プロジェクトにまつわる色んな問題は、どんな構造を持っているのか?
利害関係者同士で対立が発生した時、どのように解決するのか? あるいは調整するのか?

【1-2】自分自身の体験としてはPMOのような役割でプロジェクト支援に入った時に、いつも気になることがある。
それは、利害関係者ごとに問題の観点が違うので、それを解きほぐし、本来の問題とゴールを導いて、納得してもらうのに、ものすごくパワーがかかること。

例えば、部課長であれば、プロジェクトが黒字になるように仕事してくれ。
プロジェクトリーダーならば、納期までに無事にリリースしたい。
新しい技術が好きなプログラマならば、新しい技術を試したり、自分の華麗なコーディングを見せつけたい。
新人プログラマならば、先輩のように、自分も早くアウトプットを出して、能力があるのを見せたい。
皆の立場で、プロジェクトに対する意識は全く違う。

最近、TOCの論理思考プロセスの対立解消図でこんな一節があった。
「対立は現実には存在しない。認識の中にだけ存在する」

まさにそうで、利害関係者の頭にある現実が衝突しているだけ。
彼らの頭にある前提条件を崩せば、対立は消える。
そのために、いかに彼らを説得し、世界観を変えてもらうか、にすごくパワーが要る。

説明のロジックとして、対立解消図が使えないか、色々探っている。

【2】TOCの思考プロセスには、5つのツールがある。

【2-1】現状分析ツリー

現状分析ツリーは、現状の問題点から原因をツリー構造で深掘りしていく手法。
原因と結果のロジックを突き詰めて深掘りしていく。
個人的印象としては、ロジカルシンキングで問題を深掘りしていくのに似ている。

以下の記事が詳しい。

要求工学 第27回:論理思考プロセスと現状分析ツリー(要求工学:Requirements Engineering)

思考プロセス入門(3) 現状問題構造ツリーの作成方法 | TOC | 飯塚革新コンサルティング

問題認識の手法4―現状分析2: サラヒン ~ サラリーマンによるサラリーマンのための仕事のヒント

問題解決の7ステップ1: サラヒン ~ サラリーマンによるサラリーマンのための仕事のヒント

現状分析ツリーで面白い点は「問題は2つの原因を持っている」という特有の考え方があるらしい。


(引用開始)
この思考プロセスで目からウロコが落ちたのは、

 ・問題は単独では発生しない
 ・問題は2つの原因を持っている

というところ。
これからすっかりTOCの信者になりました。
(引用終了)

(引用開始)
このTOCを学ぶ前までは、すごく単純に

 原因 → 問題

のような図式で考えてました。つまり、ある問題にはたった一つの原因がある。
(中略)
ところが、多くの業務をする上でのプロセスというのは、非常に複雑なので、このプログラムのような単純な要因になるものではありません。その時に、

 ある事象とある行為が重なると問題が起きる
 ある行為とある行為が重なると問題が起きる

という考え方が、TOCにはあります。
(引用終了)

現状分析ツリーでは、問題を引き起こす原因が2つ以上あった場合、OR条件、AND条件、増幅条件の3つで表現する。
OR条件は、原因がそれぞれ独立している。
AND条件は、複数の原因が同時に発生して、初めて問題が現れることを意味する。
増幅条件は、複数の原因が加算されて増幅されることを意味する。

これらの原因には微妙な違いがあるので注意。

現状分析ツリーでは、「もし~(原因)~ならば~(問題)~になる」と読む。
その内容で、なにかおかしいと感じたら、論理に破綻が生じているので直す。

現状分析ツリーの使い道は、問題の症状と原因の構造を明確にすること。
それは、問題が起きている現状のスナップショット。
根本原因を突き止めることで、問題を引き起こす制約条件を見つけることができる。

普通は、悪循環の構造を持つ問題が発生したら、その構造を壊すような変化を与えることが解決の糸口。
つまり、故意に変化を起こすことが解決方法の一つ。

問題の構造を壊さなければ、現状は何も変わらないから。
その時に、制約条件を突き止めることが出来れば、その部分をいじることで、変化を起こすことができる。

【2-2】クラウド(対立解消図)

例えば、対立している状況では、2つの選択肢のどちらかを選ばなくてはいけないが、どちらの選択肢も全ての利害関係者を納得させられない。
あるいは、対立が隠れており、そのために現場が停滞している状況もある。
後者は、問題が認識されているにもかかわらず、どうやっても解決できず、無力感が漂う状況などがある。

普通は、対立した状況では、妥協ないし、どちらかの選択肢を選択してWin-Loseの関係にする場合が多い。

このような対立の状況から、Win-Winの解決策を可能にするのがクラウド。

クラウドの別名は対立解消図。
ある目的(ゴール)に対し、利害関係者が相反する要求を出し、対立を起こしている構造を明確にする。

クラウドでは、ゴール←2つの要件←2つの前提条件 という構造で表し、2つの前提条件が対立しているように表示する。

クラウドによる解決方法は、どちらか又は両方の前提条件を崩し、別の解決方法(インジェクション)で要求を満たすようにする。

対立の解消は、プロマネの調整技法としてとても重要だ。
利害関係者との調整とは、妥協とトレードオフが一般的で、誰かに不満を残す。
クラウドを使えば、相手の前提条件を崩し、新たな解決策を提示して、Win-Winの関係を実現する事が可能。
プロジェクトマネジメント手法として、クラウドは重要な技法の一つ。

【2-3】未来現実ツリー

未来実現ツリーは、リスク対策に使う。

未来実現ツリーは、実施したい変革方法に対し、その影響結果をツリー構造で書いていく。
すると、良い影響もあれば、予期しない結果や、好ましくない結果が出てくる時もある。
つまり、今から実施する対策のシミュレーションとして使える。

【2-4】前提条件ツリー

前提条件ツリーは、PERT図そのものだ。

前提条件ツリーは、目標(ゴール)に対して、中間目標をツリー構造でブレイクダウンしていく。
すると、目標を実現するためのネットワーク図になる。
これがPERT図に相当する。

【2-5】移行ツリー

移行ツリーは、前提条件ツリーで図示したPERT図を具体的な作業手順のツリーへ詳細化したもの。

【3】TOCの思考プロセスが使える状況

上記の思考プロセスを使う状況は下記があげられるだろう。

・「現状分析ツリー」で、問題の構造を把握する or 問題の構造を説明する
・「クラウド(対立解消図)」で、利害関係者の対立を解消し、別の案を提示する
・「未来実現ツリー」をリスク対策の検証に使う
・「前提条件ツリー」「移行ツリー」でプロジェクトの概要スケジュールを作る

つまり、プロマネがやるべき仕事において、これらのツールはとても有効だ。
顧客や上司、開発チームのメンバーに対し、以下のような説明をする時が多い。

現状の問題の構造はこういうものだ。だから、この構造の背後にあるこの制約条件を壊してみよう。

2つの意見の対立は実はこういう構造を持っているが、実は、この前提条件は正しくなくて、このように考えれば、こんなアイデアで解決できる。

この対策を実施すると、こういう好ましい効果が得られるが、副作用として、このような不都合な結果も出てくるから、注意しよう。

この目標に対して、中間目標(マイルストーン)はこれこれであり、それぞれはいつまでに終わらせないといけないのが分かるよ、と。

こういう説明を論理的に行い、理解してもらうことで、人は初めて動く。
特に、IT業界のように能力の高い専門家集団の場合は、威圧的に一方的に指示を出せばメンバーが動くわけではない。
むしろ、論理的に説明して納得してもらって、メンバーの能力を引き出せるのだ。

まだ実際の経験が足りないので、以上のアイデアを試してみる。

|

« Scrumの入門資料リンク | トップページ | Stackoverflowの日本版Qiita~知識の共有が自己の知識を成長させる »

プロジェクトファシリテーション」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

モデリング」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« Scrumの入門資料リンク | トップページ | Stackoverflowの日本版Qiita~知識の共有が自己の知識を成長させる »