TOCとCCPM
先日、『ザ・ゴール』などで有名な TOC(Theory Of Constraints)のコンサルタントの方とお話をさせていただく機会がありました。
私は元々 TOC の「思考プロセス」に興味があり、独学でこれを学び、6〜7年ほど実務で活用しています。
ただ独学なので、専門家からのアドバイスで改善すべきところが多かろうと考え、お話を伺わせていただいた次第です。
お話を伺った感想としては…新しい地平が開けたような気がします。
というのは、CCPM(Critical Chain Project Management)という、TOC の理論を活用したプロジェクトマネジメント手法について、多くの知識を得ることができたからです。
現在のプロジェクトでの問題を解決できる、多くのヒントを教えていただくことができました。
今回は、覚えている範囲で、得られたヒントをまとめていこうと思います。
1.「ヒト」よりも「コト」を解決せよ
ネガティブな問題が発生した場合、つい我々は問題の原因を「ヒト」に求めがちです。
ですが、問題の原因を「ヒト」に求めてしまうと、その「ヒト」を責めて終わりになってしまい、真の問題を解決することに思考が至らなくなってしまうことがあります。
大概の問題は、1・2個の根本原因から派生しています。
問題だと思われる「ヒト」も、その根本原因に飲み込まれている被害者であることが少なくありません。
なので、その根本原因(コト)を解決することに集中すべき、とのことです。
TOCの根底にある考え方として、人は善意に基づいて行動しているという前提、物事・問題の根底はシンプルであるという前提に立つことが大事であるとのこと。 確かに、みんな問題を起こそうという悪意で動いている訳ではないし、問題を紐解くと、簡単な事象が複雑に絡み合っていることが多い。
プレジデントのDeNAの社長のインタビューで、ネガティブな状況に遭遇したらヒトではなくコトにフォーカスする方が良いですよと書かれていて、我が意を得たりな気分になりました。確かにあの人がイヤという意見だけだと、思考がそこで止まってしまって、問題を解決出来なくなってしまうんですよね。
問題を突き詰めていって、やっぱりヒトに問題がある場合は、そこを解決するしか無いんでしょうね。 ただ、そのヒトが嫌という方向ではなく、その人がいることが問題の根底であるという「コト」を解決していこう、という方向に持っていけると、話を変えられるのかな?と思ふ。
2.仕分けした問題はつなげよう
クリティカルシンキングなどでは、問題を仕分けするテクニックを多く教えてくれます。
ですが、それらの問題の間にある関係やつながりについては、あまり深く考えない傾向があります。
一方で TOC では、大概の問題は1・2個の根本原因から派生していると考え、
派生している問題間のつながりから根本原因を考えていこうとします。
また、目標を実現するための手順についても、課題やタスク間のつながりから考えていこうとします。
物事をつなげること、関連を考えることが大事ということです。
問題を仕訳したりアイデアを出したらそこで終わり、という人をたまに見かけるけれども、本当に重要なのはそれらをいかにつなげられるかなのではないか? 問題の関係を見つけることで前後関係が見え、さらにそれらに共通の原因を見つけられるかも。 それを消せれば、関連する問題を消せるでしょ?
3.進捗は残り時間で管理せよ
詳しい話を下記のツイートにほとんど書いてしまいましたが、「今の進捗率は何%?」と聞くよりも、「あと何日かかる?」と聞いた方が、問題の早期発見とメンバーのやる気を引き出せるようです。
進捗管理の際、進捗率で報告を求めると、90%までは順調にいくのに、残り10%から進まなくなることってよくありますよね。 そういう場合は、「あと何日でできる?」と聞くようにするとよいそうです。 曖昧基準で状況を取り繕うことよりも、問題解決に意識を向けさせられるから。
あと、10日かかると言われたものを5日に縮めて欲しい場合は、「5日でやって欲しいんだけど何を手伝えばいいかな?」と言ってあげるとよろしいとのこと。短くやる方法に意識が向くことと、ヘルプが得られるという安心感から、抱えている問題を積極的に出してくれるようになるのだとか。
4.質問で交渉を動かせ
システム開発のコンサルティングや要件定義などで、ユーザが何を考えて情報を提示すれば分からずに、話が進まなくなることって多いですよね。
こういうケースでは、質問で交渉相手に考える癖をつけさせて、話をスムーズに持っていくという考え方があるそうです。
例えば、「XXXの機能は必要かな〜?」とのユーザからの問いかけに、必ず「それを使うユーザは何人ですか?」などと質問するようにするのです。
これを繰り返すと、ユーザは質問に慣れてきて、「XXXの機能は100人使うな」などと自分で考えてくれるようになってくるはずです。
そうなると、「この機能は使用ユーザが1〜2人だから、無理して機能化しないで運用でカバーしよう」とユーザが自ら考え、
必ずしも優先度が高くない機能を自主的に取り下げ、話がスムーズにいくようになるかも知れません。
今回の例は極端かも知れませんが、質問で相手に考える癖をつけさせてリードしていくというテクニックは、活用できるところが多いと思います。
相手に思ったように動いてもらうために、質問で考え方を誘導していくのもありだとか。例えば、要件定義で必ず「その機能を使う人数と時間は?」と聞くようにすれば、ユーザもそれに回答することが癖になり、ゆくゆくは自ずから余計な要望を出さなくなるなど。 聞き方ひとつにも工夫の余地があるのね。
以上、覚えている範囲で思いつくままに書き出してみました。
世の中、考え方一つで改善できることはまだまだ沢山ありそうです。
TOC と CCPM について理解を深め、今抱えている問題を1つ1つ解決していこうと、改めて思った次第です。
参考書籍
- 作者: エリヤフ・ゴールドラット,三本木亮
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2001/05/18
- メディア: ペーパーバック
- 購入: 32人 クリック: 373回
- この商品を含むブログ (391件) を見る
- 作者: エリヤフ・ゴールドラット,三本木亮
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2002/02/23
- メディア: 単行本(ソフトカバー)
- 購入: 16人 クリック: 148回
- この商品を含むブログ (151件) を見る
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
- 作者: エリヤフゴールドラット,三本木亮
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2003/10/31
- メディア: 単行本(ソフトカバー)
- 購入: 12人 クリック: 142回
- この商品を含むブログ (117件) を見る
- 作者: エリヤフ・ゴールドラット,三本木亮
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2002/10/11
- メディア: 単行本
- 購入: 5人 クリック: 56回
- この商品を含むブログ (86件) を見る