U理論、と聞いて「ん？！ UFOか何かについての理論？」と思う人もいるでしょう。いやいや、そんなSFチックなものではありません。この理論は、マサチューセッツ工科大学のオットー・シャーマー博士が提唱する「過去の延長線上にはないイノベーションを起こすための原理と実践手法を明示した理論」なのです。

U理論を日本に初めて紹介したのが、『人と組織の問題を劇的に解決する U理論入門』（PHP研究所）の著書も持つ、社団法人プレゼンシングインスティチュートコミュニティジャパン理事の中土井僚氏。その中土井氏に対して、サイボウズ・ラボのエンジニアで、日本最年少で博士号を取得した俊英・西尾泰和が「U理論をエンジニアがどのように役立てられるか？」という観点から迫るのが今回の対談です。 前編ではまずU理論がどんなもので、イノベーションが起きるまでにはどんなプロセスをたどるのかを、具体的なシーンも交えながら解説していきます。これを読めば、あなたもイノベーションを起こすためのヒントをつかめるかも？！

今回の対談では、主にエンジニアの方をターゲットとして、U理論がどのような理論であり、どのようにすれば個人としての生き方や、開発者の学び方に生かしていけるのかをお伝えできる内容にしたいと思っています。 まずは、U理論とはどのようなものであるか、中土井さんから改めてご説明いただけますか？ といっても、完全に説明しようとしたら何時間あっても足りないので、あくまで簡単に（笑）

わかりました。U理論というのは、マサチューセッツ工科大学の上級講師であるオットー・シャーマー博士が提唱している理論で、ひと言で言うと「イノベーションを実現するプロセスを、原理として明示している理論」です。

イノベーションとは何かというと、過去の延長線上にないものを生み出すこと。それを、個人だけでなく、集団・組織・社会でも可能にするプロセスを明らかにしているのです。

一個人においては、インスピレーショナルなアイデアとしてまったく新しいものを生み出すこととなるし、集団・組織・社会では、今抱えている課題に対して、従来のやり方ではなく、まったく新しい解決策を生み出すことを実現します。それも、指示命令形でなく、チーム一枚岩となってイノベーションを起こすことが、どうしたら可能になるかを示しています。

中土井僚 同志社大学法学部政治学科卒業後、アンダーセンコンサルティング（現・アクセンチュア）に入社。コンサルタントとしてITを活用した業務プロセス改革や顧客戦略プロジェクトなどの組織・人材設計を行う。その後、組織・人材開発業界に転身し、2005年独立。現在、組織変革ファシリテーターとして、U理論をベースにしたマインドセット転換による人と組織の永続的な行動変容を支援する“組織進化プロセスコンサルティング”を行う。リーダーシップ・プロデューサーとして「自分らしさとリーダーシップの統合と、共創造（コ・クリエイション）の実現」をテーマに、U理論をベースとしたマインドセット転換によるその人にあったあり方(Being)のシフトと影響力の飛躍的な拡大の支援を行う。また、リーダーシップ・プロデュースの一環として組織変革ファシリテーターとしても活動し、過去に手掛けた組織変革プロジェクトは50社以上に及ぶ。オーセンティックワークス株式会社代表取締役。社団法人プレゼンシングインスティチュートコミュニティジャパン理事。 著作に『人と組織の問題を劇的に解決するＵ理論入門』がある

「過去の延長線上にないものをどう作るか」が、U理論で解決したい問いなんですね？

そうですね。多くの人は、そういうイノベ―ショナルな経験を持っていると思います。例えば、ホンダの「ワイガヤ」とか、アーティストが自分を追い込んでモノを生み出すとか。ただ、イノベーションが起きるプロセスというのは、これまで抽象的にしか語られてこなかった。U理論では、そのプロセスがどのようなものなのかを明示しているんです。

イノベーションが起こる過程での、共通したバックボーンを言語化したのがU理論なんですね。オットー博士は、イノベーションが起きるプロセスを明示することで、究極的には何を目指したのでしょう？

オットー博士は、社会的問題にすごく関心が高いんです。例えば、地球温暖化とか飢餓とか。そういう問題は、局所的な対処だけでは解決できません。グローバルにつながっているからです。

例えば、コンゴに少年兵がいるという問題がありますよね？ なぜ少年兵がいるかというと、そこにレアメタルの鉱山をめぐる争いが一因にあるからです。じゃあ何故レアメタルをめぐる争いがあるかというと、それが携帯電話などに欠かせないという経済的なバックボーンがあるから。こういう問題は、局所的な対処では解決できず、しかも過去の延長線上のやり方では解決できない。

地球温暖化もそうです。地球に住む人類全体がステークホルダーであるという問題は、有史以来ないんですよ。そういう問題の解決策は、今までのやり方の延長線上にはない。

地球規模で大きく複雑に絡み合っている問題を、今までにまったくないやり方で解決するための方法論を確立する必要がある。それが、オットー博士がU理論で目指したことなんですね？

そのとおりです。アインシュタインの言葉で、「今日われわれの直面する重要な問題は、その問題を作った時と同じ思考レベルで解決することはできない」というものがあります。その思考レベルをどう超えていくのか？という道を照らしているのがU理論であると認識しています。

U理論という呼び名は、イノベーションの起きる過程がUの字を描くことからついているんですよね。

ええ。私たちがこれまで慣れ親しんできたのは、計画を立て（Plan）、行動し（Do）、結果を振り返って評価し（Check）、改善措置を実行し（Action）、計画にフィードバックするという、いわゆるPDCAサイクルですよね。オットー博士はこれを「過去からの学習」と位置づけています。これに対し、U理論による学習は、「出現する未来からの学習」。
すなわち、「『今、この瞬間』に立ち現れようとしている未来を感じ取って、行動を創り出す」というものです。
オットー博士は、「出現する未来」から学び、イノベーションを創り出すには大きく3つのプロセスがあるとし、そのプロセスをUのモデルで表現しています。
3つのプロセスとは1. センシング（ただ、ひたすら観察する）、2. プレゼンシング（一歩下がって、内省する。内なる「知」が現れるに任せる）、3. クリエイティング（素早く、即興的に行動に移す）です。Uの形は、1のセンシングから2のプレゼンシングの状態にたどり着いた時に未来が出現し、そこから得た直感やインスピレーションに形を与えることでイノベーションが現実化していくということを表しています。

3つのプロセスは、さらに7つのステップに詳細化されるのですよね。

そうです。

1. ダウンローディング（過去の経験によって培われた枠組みを再現する）
2. シーイング（観る＝判断を保留し、現実を新鮮な目で観る）
3. センシング（感じ取る＝場から感じ取る）
4. プレゼンシング（ソースにつながる）
5. クリスタライジング（結晶化＝ビジョンや意図を明確化する）
6. プロトタイピング（実行、実験によって未来を探索する）
7.パフォーミング（実践＝新しいやり方、仕組み、習慣として実体化する）です。
さらに、ステップ1から4に対応する意識のレイヤーが、レベル1から4まであります。

先ほど、オットー博士はU理論により、地球規模で複雑に絡み合っている問題をこれまでにまったくなかったやり方で解決することを目指している、というお話がありましたが、エンジニアというのはともすれば、世界全体の大きな問題より、自分の周りの小さな問題だけにフォーカスする傾向があるように思います。
大きい問題に対処することを先にするか、身近な小さい問題からスタートするか。エンジニアは小さい問題からスタートする傾向にありますが、U理論とは逆のアプローチなのでしょうか？

どちらかからスタートするかというのではなく、過去の延長線ではない第3の道を生み出せるかということなんです。テーゼとアンチテーゼがあって、アウフヘーベンによりそれを超えたものを創り出すという弁証法的なセンスに近いと思います。

つまり、2つの選択肢のどちらかを取るというのはすでに過去の延長である。そうではなく、両方解決する別の方法があるんじゃないか、というのがU理論の発想なんですね？

おっしゃるとおり、両方解決する別の方法が見つかることもありますし、結果、どちらかの選択肢を取るという結論であったとしても、まったく別の展開が生まれうる選択となることが起こりえます。例えば、ソーシャルエンジニアという言葉はあるんでしょうか？ 社会的な問題を解決するというところからエンジニアリングをとらえるという意味で。

それはとても大事だと思いますが、大部分のエンジニアにはそういう発想はないでしょうね。

西尾泰和　サイボウズ・ラボのエンジニア。個人やチームの生産性をどうすれば高めることができるかを研究し、未来のグループウェアの研究開発をしている。プログラミング言語の多様性と進化にも強い関心があり、昨年出版した「コーディングを支える技術」はベストセラー、重版を経て、先日韓国語版が出版された。

今のエンジニアは小さいところだけを見ているかもしれないけれども、まったく違う観点でエンジニアリングをとらえると、新しいスタンスが生まれるかもしれません。

社会に変化を起こす、という意味では、オープンソース活動が近いかもしれません。オープンソース活動が起きた当時、何故それが必要だったかというと、企業がソースコードの再配布の権利を持っていて、ユーザーがそれを改善・再配布できなかったからなんです。そこでソースコードを再配布できるライセンスで公開し、それに手を加える人は同じライセンスで公開し続けなくてはならないとした。これはエンジニアによって社会変革が起きた1つの例なのかなと。

確かにソフトウエア開発の世界で、オープンソースというのはU理論が持っている発想に近いものがあると思います。エンジニアリングでありながら、アーティスティックな発想があったのでしょう。

単純に効率的なプログラミングを追求するだけでなく、「こういうやり方をしたらもっと社会がいい方向に動くのではないか？」という発想から「未来が出現」し、プレゼンシングからクリスタライジングが起きていった、ということですかね。

そのとおりだと思います。

「未来が出現する」瞬間というのは、いったいどのような状態なのでしょう？

例えば、複雑なシステムを考える時は頭が混乱しますよね？ それが、寝ている間とか、シャワーを浴びている時に、ふと問題を解決するアルゴリズムを思いついたりする。わかりやすく言うと、そういう状態が「未来が出現した」瞬間ではないかと思います。

とすると、U理論というのは、「閃いた！」「エウレカ！」という状態を、いかに作り出すかという方法論なんでしょうか。

そうですね。今まではそれを、「行動」でやっていたと思うんです。私も会社に勤めていた時、上司によく「死ぬ気でやれ！」と言われていました。結果が出ていないのは死ぬ気でやっていないからだと、精神論で片付けられていた。でもそれって結局、行動の話にすぎないんですよ。
U理論が新しいのは、意識状態として閃きが起きやすい状態とはどういうものなのか、どうすればその状態に至れるのかを提示している点だと思います。

それがレベル1からレベル4までの意識のレイヤーですね。そこを詳しく解説してもらえますか？

わかりました。
「レベル1」は、ダウンローディングのレイヤーで、入ってきた情報に対して、既存の考え方そのままで反応している状態。 「レベル2」は、シーイングのレイヤーで、目の前のものに釘付けになっている状態です。 「レベル3」は、センシングのレイヤーで、過去の経験によって培われた枠組みが崩壊して、枠組みを超えた側から今の自分や状況が見えている状態。
自分の目玉でなく、他人の目玉で物事を見ている状態ですね。いわゆる「目からウロコが落ちる」という状態とも近いと思います。 「レベル4」は、プレゼンシンングのレイヤーで、まさに「未来と出会う瞬間」。最高の未来の可能性のソース（源）につながり、それを今に持ち込めるようになる状態です。

レベル1とレベル2の状態を、例を挙げて説明してもらえますか？

例えば、プログラマーがデバッグをしている時に、「何の問題もない」というのはレベル1の状態ですよね。自分の頭にある枠組みだけを通して、思い込みだけで判断している。

はい。

レベル2になると、ちゃんと見て、バグの兆候に気づけているわけです。あれ、なんかいつもと違うな？ おかしいな？と。

優れたエンジニアほど、兆候を見逃さない傾向にありますよね。普段より処理に時間がかかっているなとか、クリックの反応がちょっともっさりしているなとか。

そうですね。いわゆるセンス・オブ・ワンダーというか、気づく力というか。それがレベル2です。

なるほど、そういうことですね。 レベル1からレベル2への移行は、エンジニアと営業との争いで説明するとわかりやすいかもしれませんね。営業からいつまでにこういうものを作ってほしいといわれるけど、エンジニア側はこんな日程でクオリティの高いものを作れるわけがないだろうと怒る、みたいなシーンで。

ああ、確かに。レベル1の状態だと、エンジニアは「営業の連中はお客の都合ばかり聞きやがって。もっと仕切れよ！」みたいに、自分の想定で決めつけているわけです。

ええ。

それがレベル2になると、実際に営業と対峙して、この納期だとこの機能を落とさないといけないよね、と事実ベースで話している状態。ただ、そこには共感はありません。 続いて、レベル3は、実際に営業といっしょにお客様のところに行ってみて、横暴な態度を取られた時に、「ああ、こんな思いを営業の人はしていたんだな。だからあんな困った顔をしていたんだな」と思っている状態です。

共感がありますね。

ええ。レベル3に入ると、2つのことが起こります。1つは、開かれた心にアクセスして、相手を許す気持ちが出てくる。 もう1つは、強烈にモヤモヤするんです。ショックを受けて、葛藤に陥る。

「営業の気持ちはわかる。でも、自分の立場も譲り難い」という葛藤ですね。

そうです。その葛藤から一歩進めたら、レベル4に入ります。

レベル4に入るとどんなことが起きるんですか？

ほとんどのケースでは「腹をくくる」という状態になりますね。そこから「出現する未来」とつながることが起きる。ただ、答えが出ないまま、レベル1の思考停止のレイヤーに戻ることもあります。

なるほど。

レベル3の状態って、何回もそこに辿り着く経験をすると入りやすくなるんですよ。例えば、システム開発でよく「ユーザーの視点に立て」と言われると思いますが、頭で考えているうちは無理。自分の中にユーザーの目玉ができて、ユーザーのうれしいと思うことが自分のことのようにわかるのがレベル3の状態です。優れたエンジニアは当たり前のようにユーザーの視点に立てる。それはレベル3の状態にどれだけ入れたことがあるかで決まると思います。

お話を聞いていて、今、気づいたことがあります。僕は昨年、『コーディングを支える技術 成り立ちから学ぶプログラミング作法』（技術評論社）という本を書いたんです。その本で何が言いたかったかというと、「プログラミング言語にはその言語を作った人がいる」ということだったんですよ。

おお！ 鋭いですね。

エンジニアは、プログラミング言語について天から降ってきたとでも考えがちですが、そもそも、その言語というのは、開発者が何か解決したいことや、やりたいことがあったから作られたわけです。だから、開発者がなぜその言語を作ったのかをきちんと理解すれば、より良いプログラムが書ける。 言語を使う人が、言語開発者の視点を獲得する。それがレベル3に入ったということなんですね。

おっしゃるとおりです。その視点から見たら、見えるものがまったく違うと思います。

＜編集部より＞ 今後『続・エンジニアの学び方』シリーズでは、西尾によるU理論解説の掲載を予定しています。本対談についての疑問点は西尾まで、お気軽にお寄せください