-
-
- ソフトウェアエンジニア
- 技術者/エンジニアリングに興味がある人
- オブジェクト指向プログラミングに関心がある人
- U理論に興味を持つビジネスパーソン
- 技術革新に興味を持つ個人
-
-
この記事を読むことで、読者はまずオブジェクト指向プログラミングがプログラムの考え方にどのような変革をもたらしたのかについて理解を深められます。特に、物事を手続きやプロセスとして捉える従来の方法から、オブジェクトつまりものにフォーカスすることで、プログラミングのスケーラビリティや効率が向上することの発想の転換についての驚きが語られています。
さらに、U理論に関連して、未来のビジョンを持つことだけでなく、そのビジョンに基づいて実際に未来を構築するプロセスが強調されており、イノベーションの瞬間についての考え方が紹介されています。オットー博士が提唱する「未来が出現する」瞬間と、その概念がエンジニアリングや社会発展にどのように応用されてきたかも詳しく論じられています。
具体的な例として、企業間で知識が流通するようなソフトウェアの開発が未来を創造する一歩であり、そのプロセスがU理論のプレゼンシングからクリスタライジングへの移行の一部であることが示されています。アラン・ケイの言葉に基づき、未来を予測するのではなく、自らがその未来を発明するという考えも確認され、自分たちが未来の変化を引き金として引けることに関しての理解が深まります。
-
-
tech
「出現する未来」の引き金を、自分で引くために──U理論・中土井 僚(3)/西尾 泰和の「続・エンジニアの学び方」
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第24回(これまでの連載一覧)。U理論の伝道師、中土井 僚さんにお話を伺うシリーズ(3)です。
本連載は、「WEB+DB PRESS Vol.80」(2014年4月24日発売)に掲載された「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部)
文:西尾 泰和
イラスト:歌工房中土井さんとの対談(前編、後編)のフォローアップ記事の第3回です(第1回、第2回)。
今回は、中土井さんがオブジェクト指向に出会ったときの話、そしてそれがU理論のどの部分に対応しているのかを伺っていきます。
私は、エンジニアとしてはシステム開発をちょこっとやっただけなんで、そんなに詳しくはないんですけど、例えばオブジェクト指向とか考えた人ってすごいなって思うんですよ。
どの辺ですごいと思われたんですか。
まずウォーターフォール式なシステム開発が主流だった中で、プログラムでどうやって現実世界を表現するかって考えたときに、「プロセス」の集まりだと捉えるのは人間の思考にはそっていると思うんですよね。
そうですね。
ところが、オブジェクト指向、つまり、世の中は「オブジェクト」の集まりだ、プログラムはオブジェクトの振る舞いだ、って考え方の人が世の中にいるんだって知ったとき、私、最初は理解できなかったんですよ。私はちょうどCOBOLからC、C++に変わるころから、そのあとJavaが出てくるころまでシステムに関わってたんですけど、最初オブジェクト指向言語がよく分からなくて。
なるほど。
オブジェクト指向言語でプログラミングしているだけで、結果ウォーターフォール的にプログラミングする人が当時まだ結構いたわけですよ。だから全部くっついちゃってて全然拡張性がない、みたいな。そのときにオブジェクト指向に関する本を読んで、パラダイムがシフトしたのを覚えてるんですよ。
見え方が切り替わった、と?
うん、完全に切り替わりましたね、世の中の見方が変わったのを覚えてるんです。元々Smalltalkとか作った人たちが、そういうふうに世の中を見てるんだってことに驚きましたよね。
プログラムというのは「手続き」で「『何をやれ』って命令が順番に並んでるもの」だという考えが主流だった時代に、「操作される『もの』があるんだ、それにフォーカスしよう」「『もの』という切り口でプログラムを切り分けたらもっとうまくいくんじゃないか」って考えた人がいたと。その発想の転換に驚いたと。
イノベーションが起きる瞬間、生まれ始める瞬間のことをオットー博士は「未来が出現する」って言ってるんですけど、私はその「未来が出現する」っていうのって、未来のビジョンが出てくるだけではなく、そのビジョンを元に実際に未来を作っていくっていう感じがするんです。「あ、こういうふうにプログラミングの世界を捉えたら、よりスケーラビリティがあるんじゃないか」っていうふうに思った人がいて、それが現実になっていくっていう。
「こういう切り口で捉えることで、プログラミングがもっと楽になるんじゃないか」と考えた人がいて、そういうことができる言語を作ってみたら、それがすごく受け入れられて世界が実際に変わっていった、と。
そうです、それで世界がこうなった。「オープンソースっていう考え方があったらいいんじゃないか」っていうふうに思った人の考えが、実際にそういう未来を作った。そういう、未来になった。変化が起きたあと、未来から遡ってみたら「あのときのことがこうなって、ああなって、こうなったんだよね」って言える。ジョブズが言ってるように、振り返ったらドットは繋がってるんだけども……。
事前には何が繋がるかは分からないですよね。
そう、でも、それを思いついた人は、ものすごい確信を持ってるんですよ。それが未来として実現する、起きることが分かってる、ぐらいの確信を持ってる。それを「未来が出現する」っていう表現にしているところがすごく面白い。
なるほど。
エンジニアの人たちが手続きとして効率よくプログラミングできるかどうかが重要なのではなくて、「こういうプログラミングができたら、こういうシステムが作れたら、なんかすごいことが起きるんじゃないか?」っていうインスピレーションが湧くかどうかの話なんですよ。
具体例で考えてみると、私の会社は社内のコミュニケーションに関するソフトウェアを作って売っているわけなので「このソフトウェアにどういう機能をつけたら、社会がもっといい方向に動くだろうか?」と考えるわけです。例えば「社内に閉じるのではなく、社外の人も使えるようにしたら、会社の境界が情報の境界ではなくなり、異なる企業間を知識が流通する社会が来るのではないか?」みたいなインスピレーション、これが「出現する未来」の最初の一歩、プレゼンシングからクリスタライジングへの移行ステップだと。
そうですね。
◆ ◆ ◆ オブジェクト指向という言葉を生み出しSmalltalkを設計したアラン・ケイは「未来を予測する最善の方法は、それを発明することだ」「未来はただそこにあるのではない。未来は我々が決めるものであり、宇宙の既知の法則に違反しない範囲で望んだ方向に向かわせることができる」などの言葉も残してますね。
「出現する未来」という言葉は「自分と無関係に出現する」というニュアンスで受け取られてしまうことも多いです。しかし、U理論をよく読んでいると、むしろ「自分が変化のきっかけになりうる」という点が強調されているように思います。そういう意味では「出現する未来」は「私が引き金を引く未来」なのですね。
この記事の読者にはソフトウェアエンジニアも多いかと思います。ソフトウェアエンジニアには、「ソフトウェアを作って公開する」という引き金の引き方ができるわけですよね。この能力を活用して、楽しい未来が出現させられるといいなと思います。(つづく)
「これを知りたい!」や「これはどう思うか?」などのご質問、ご相談を受け付けています。筆者、または担当編集の風穴まで、お気軽にお寄せください。(編集部)
謝辞:
◎Web+DB Press編集部(技術評論社)のご厚意により、本連載のタイトルを「続・エンジニアの学び方」とさせていただきました。ありがとうございました。
この記事を、以下のライセンスで提供します:CC BY-SA
これ以外のライセンスをご希望の場合は、お問い合わせください。タグ一覧
- U理論
- 続・エンジニアの学び方
SNSシェア
- シェア
- Tweet