tech
過去の延長線上にない第3の道を生み出す──U理論・中土井 僚さん（2）
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第23回（これまでの連載一覧）。U理論の伝道師、中土井 僚さんにお話を伺うシリーズ（2）です。
本連載は、「WEB+DB PRESS Vol.80」（2014年4月24日発売）に掲載された「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部）
中土井さんとの対談の前編の「地球規模で大きく複雑に絡み合っている問題を、今までにまったくないやり方で解決するための方法論を確立する必要がある。それが、オットー博士がU理論で目指したことなんですね？」の後の部分が分かりにくいという意見がありましたので、言葉を補って解説します。
なるほど。ところで、僕も含めてエンジニアって「世界全体」みたいな大きな問題を語ることは避けて、自分がコントロールできる小さい問題にフォーカスしようとする傾向があると思うんです。U理論はどちらかというと逆ということなんでしょうか？
すごくいいポイントです。結局それってジレンマなんですよね。ジレンマには、テーゼとアンチテーゼがある。「大きな問題にきちんと向き合って対策を打たなければ、本当に大切な変化は起こせないし、結果的に後々自分の身に影響を及ぼすだけだ」というテーゼと、「大きな問題の解決には時間も労力もかかるし抽象度が高くなりすぎる傾向がある。それよりもむしろ、部分を積み上げて改良を重ねるほうがいい」というアンチテーゼがある。この対立を超えたものを作り出していかないとジレンマは解決できない。
テーゼとアンチテーゼの対立を乗り越えるっていうと、弁証法のアウフヘーベンですか？
オットー博士はアウフヘーベンとは言ってないんですけど、エッセンスは近いと思っています。過去の延長線上じゃない第3の道が生み出せるかどうかが大事。「どちらか」って言ってること自体がもう過去の延長線上だから。
なるほど。「Xか、not Xか、それが問題だ」っていう問題設定の時点ですでに過去にとらわれて視野が狭くなっている、と。両方を同時に解決する別の解決法があるのではないか、それはどうやったら作れるんだろうか、っていうのがU理論の目指してることなんですね？
そうです。
この連載の「エンジニアの学び方」というテーマに戻って考えると、「自分がどうやって学ぶか」っていう小さな問題も解決しつつ、世界に対して有益なことができないかという大きな問題解決も同時にできる道があるのではないか、それを見つけていこう、という方向性なんですね。
例えば……「ソーシャルエンジニア」っていう言葉ってありますか？
具体的にどういうイメージですか？
ソーシャル・アントレプレナー（社会起業家）みたいに、「社会的な問題を解決する」っていう観点からエンジニアリングを捉えてるエンジニアです。
ああ、それはすごく重要だと思うんですけれども、僕は「社会活動もエンジニアリングである」と考えているエンジニアは少ないのではないかなと思います（著者注：英語のsocial engineeringという言葉には社会工学という意味のほかに、人間の脆弱性をつくセキュリティ上の攻撃の意味もあり、日本語では後者のほうがメジャーであるため）。
今エンジニアは小さな問題にフォーカスしているのかもしれないけど、社会起業家が生まれてきたように、今後まったく違う観点でエンジニアリングを捉えて仕事をする「社会技術者」が生まれてくるのかもしれないですね。
実際、昔のすごいエンジニア、つまりハッカーと呼ばれている人には、社会に対してどういうハックをしたら社会を良い方向に変えられるかを考えた人もいます。例えば具体的な例としたら……オープンソース活動って分かりますか？（著者注：最初の対談記事を公開後、読者から「フリーソフトウェア運動」と呼ぶほうが適切とご指摘いただきました）
分かります分かります。
当時、プログラムのソースコードの権利は会社が持っていて、ユーザーが改善していくことができない状況だったんですね。でも一部の人が自分の書いたプログラムのソースコードを公開し、それに「これを改変して使ってもいいが、その改変したソースコードもこのソースコードと同一のライセンスで公開しなければいけない」という再帰的なライセンスを掛けた。そうすると、そのプログラムが有用であるほど広く使われ、それに対して修正をする人も多くなり、修正されたソースコードが公開され、その結果プログラムがさらに有用になる、というサイクルが回るようになった。これは、エンジニアが社会に対して小さな修正をしパッチを当てたことで、変化が起こり、変化がどんどん連鎖して、結果として社会に大きな変革が起きたという例なのかなと。
それはU理論が持ってる発想に近かったんだと思うんですよね。ソフトウェアの世界って、インターネットがあるおかげで簡単に地域を超えたり、物理的な制約を超えたりしやすいので、自由な発想で過去の延長線上ではないものが生み出されやすいのではないでしょうか？ だからエンジニアリングでありながらアーティスティックなものって結構あるのではないかと思います。そういうことをできる人とできない人の差があるのがひとつのポイントでしょうね。
「こういうライセンスでソースコードを公開したら、社会に変化が起こるはずだ」という着想を得る人と得ない人がいるっていうことですね。
社会問題という大きな問題は、ついつい「自分には関係ないことだ」と避けてしまいがちです。大きな問題に目をつぶって小さな問題にフォーカスするのではなく、小さな問題をないがしろにして大きな問題のことだけ考えるのでもなく、両方を解決する方法はないか考えよう、という視点は目からうろこでした。
エンジニアとしてソフトウェア製品を開発するというのは、目の前のバグを潰すという小さな問題解決と、ソフトウェア製品を提供することで顧客の問題を解決するという大きな問題解決の両輪なのですよね。顧客の問題を解決しないソフトウェアじゃ、バグをいくら取っても、誰もそのソフトウェアを買ってくれないわけです。
ところで、この連載では、筆者の「自分の学び方を改善したい」という小さな問題を解決しつつ、「学び方について学びたい」という皆さんにコンテンツをお送りしているわけですが、楽しんでいただけているでしょうか？ 読者の皆さんから頂いた質問にお答えするために、テーマ特化でインタビューを行ったりして、筆者は結構学びを得ています。疑問、質問などぜひお気兼ねなくご連絡ください。（つづく）
「これを知りたい！」や「これはどう思うか？」などのご質問、ご相談を受け付けています。筆者、または担当編集の風穴まで、お気軽にお寄せください。（編集部）
謝辞：
◎Web+DB Press編集部（技術評論社）のご厚意により、本連載のタイトルを「続・エンジニアの学び方」とさせていただきました。ありがとうございました。
SNSシェア
