■ すごい会議のための最高の手引書 『この「聞く技術」で道は開ける』 
問題の正しい対処の仕方を知っていて、一人で実践する分にはうまく行くのに、皆にそれをやってもらおうとした途端にうまくいかなかった経験はないだろうか？
たとえばプログラムでもいい。セオリーとしてどのようにすべきか、きっとあなたは知っている。ファウラーのリファクタリングも読んだし、デマルコのデッドラインも読んだ。もちろん達人プログラマーだって読んだし、デザパタ本だって読んでいる。コードコンプリートもライティング ソリッドコードも読んだんだ。楽々ERDレッスンも読んだ。何をすべきかは知っている。
ところが、それを組織でやろうとしたときになぜだかうまくいかない。そして「やっぱり会社や組織の問題かなー」などと考えながら、角谷さんのプレゼンを羨ましげに眺めるんだ。
TIME TO THINK の根底に流れるものを一言で言い表すとしたら、「人は自分で考え答えを出せる、と相手の可能性を徹底的に信じぬく姿勢」だ。自ら考え導き出した答えは自然とその人をドライブする。だから、自分はそのためのサポートに徹しよう。それが TIME TO THINK の幹になっている。
正しいことを決めてそれを発表、実行させる「御上の通達方式」はある種楽な方法だ。「正しいこと」を脳みそに汗かき考え抜く過程はしんどいが、あとは実行されなきゃ「他人が無能だった（方向性は正しかったのに！）」と言い張ればいい。まして、その考え抜く過程を手抜きして省いてしまえば、こんなに楽な方法はない。「○○が正しい（はずだ！）」という仮説を立てた時点で検証をせずに思い込みで突っ走るんだ。
でも、この方式はそれほど効果を生んでないように見える。そりゃ、皆他人から言われただけのことをやるのに１２０％、２００％の力を出そうとはしないもの。
TIME TO THINK 方式は、そんなコントロールする立場の人に我慢を強いる。ひたすら我慢を強いる。答えは相手の中から出てこないと意味がない。仮に同じ結論にたどり着くとしても、相手の中から答えが生まれるというプロセスこそがその人を動かす原動力になる。
だから、待つ。課題に対して、必要条件を満たす答えが見つかるまでとことん待つ。出てきた答えが必要条件を満たすなら、たとえ自分が知っているセオリーどおりの答えでなくても本人の中から生まれた答えを優先する。
言葉で言うのは簡単だけど、これを実行するにはとんでもない忍耐力がいると思う。有能な人ほどそうだろう。それでも一人でできない仕事をやり遂げるには知っておいて損のない考え方だ。
TIME TO THINK は一緒に働く人全員を答えを出す力のあるパートナーとして尊重し、可能性を信じる。そして、その考える過程を通じて全員が課題を克服していくことにコミットしていく。精神的なところを大事にしつつも単なる理想論に終わらず、非常に実践的なマネジメント手法になっていて興味深い。
