デザイン思考とシステム思考の融合

　本連載で語る本質的なことは、デザイン思考とシステム思考の融合です。ここでいうデザイン思考とは、いままさに流行しているデザイン思考の具体的な手法のことではありません。wikipediaで冒頭に書かれている言葉を借りて言うと「デザイナーがデザインを行う過程で用いる特有の認知的活動を指す言葉」のニュアンスで使っています。

　これを私なりの解釈で表現すると、 「デザイン思考＝直観的かつ感性的な発想を重視する思考法」となります。

　一方、システム思考とは、システム工学から発展した考え方でありますが、もう少し平たくいうと、「システム思考＝論理的な構造を重視する思考法」となります。この「システム」という言葉はコンピュータシステムという意味ではありません。それは部分であり、ここでの「システム」とは人間を含めたシステムのことなのです。

　私は、メソドロジストとして長年手法開発を行ってきましたが、現代における最大の課題の一つとして、複雑多様化した社会やビジネスをまとめてより良い方向へ導くための考え方を確立すべきという思いがあり、そのための手法を作ってきました。良い方向とは、人が幸せに生きがいを感じながら生活したり、仕事したり、そんな世界です。

　このようなことを実現するためには、デザイン思考（感性的）で価値を描き、システム思考（論理的）でその価値を実現するためのシステムを考えるという二つの思考法が必要とされると思うようになりました。

　デザイン思考だけでは魅力的な社会やビジネスを描けたとしても、どう実現するかが分かりません。また、システム思考だけでは、実現方法は構造として示せても、その実現方法が、どのようなより良い社会なのか、新たな価値を生みだすビジネスなのかというところに行き着かないのです。なぜならシステム思考では、いま存在するモノ（例えばユーザからの要求）を対象に実現のための構造を作り上げます。しかし、社会やビジネスが大きく変化している現代においては、新しい価値観、新しいビジネス要素を創造するというフワフワしているもののカタチを作ることが必須となります。

　この２つの思考法を一人の人が持ったりチームで持ったりするためには、とてもシンプルで本質的な手法が必要となります。なぜなら、この２つの思考を単純に考えると右脳的、左脳的であり、それを両方鍛えることは今まであまりやられてこなかったし、そのような手法はこの世に存在せずデザイン思考かシステム思考どちらかの手法なのです。

　今まさにこの２つの思考法を身につけた人材が必要とされているのです。なぜならば、デザイン思考とシステム思考がバラバラの部門で行われる程非効率なものとなり、イノベーションも起こせません。ビジネススピードが問われる昨今、このデザイン思考とシステム思考を一人あるいはチームで行い、それらの思考をお互いにフィードバックする仕組みが必要とされるのです。それが、本書の第一回で説明する、「表現」と「活動」ということなります。「デザイン思考＝表現」、「システム思考＝活動（活動に行く着くまでの論理展開）」ということになります。

オブジェクト指向開発への疑問

　私は、ソフトウェアエンジニアとしてIT業界に27歳で飛び込みました。それまでは経理の仕事をしていました。その仕事の中でコンピュータと出会い少しプログラムをかじったことで、そこから大きな勘違いをしてしまいエンジニアになれるのではと思ってIT業界に飛び込んでしまいました。（結果的には良かったのですが…）

　それからがめちゃくちゃ大変で20歳の先輩たちについていけるようプログラムの仕事をしつつ猛勉強でソフトウェア工学を独学で学び、当時先端的な技術だったスティーブジョブズのNEXTというパーソナルワークステーションを借金して買いこみ最新のソフトウェアエンジニアリングを学んでいきました。このように突貫工事でシステム思考（論理思考）を鎧として身につけて、なんとなく人前で話ができるエンジニアになったわけです。しかし、そもそも私自身、本当は論理的な側面だけで物事を考えることは苦手で、人の心の領域にある曖昧なものや、突拍子もない発想、カタチがハッキリしないものに興味を示してしまうのです。また、元々ド素人だったコンピュータに対して、これは本当に人の役に立つのだろうか、このシステマチックにやっていることがビジネスにどう役立つのだろうかという自問自答の連続でした。そのため30歳を過ぎたころからシステム思考の根底にあるソフトウェア工学に疑問を感じてしまいました。

　そしてなんとなくですが、もう少し人の心を工学として取り扱う何かを探求したいと思うようになりました。これは私のビジネスエンジニアリングという学問を作りたいという考えに繋がります。それはちょうど私がソフトウェア開発の方法論（オブジェクト指向開発方法論Drop）を開発し始めた1994年くらいの話です。もともと、自分で開発方法論を作ろうと思ったのは欧米から来ていた当時大流行していたオブジェクト指向開発方法論（ソフトウェアを人間が理解できるモノを単位に設計開発するための手法）に対して疑問を感じていたからです。ここでまた自分で作った方が良いものができるという二回目の勘違いを起こしてしまったのですが、その後が悲惨で、どうもがいても自分の考えを手法に落とすことができず、結局仕事をしつつですが完成したかなと思うまでに５年くらい歳月がかかりました。

　実は、この方法論を作る過程でも自分の中のシステム思考に限界を感じました。それは、ある程度方法論が書けるようになった頃のことです。論理的に書けば書くほど僕の考える良いやり方から遠のいてしまうという現象です。手法的に考え出した方は一見すると教育的にも使えるし、良い方法に見えるものです。しかし、あまりにもアマチュア向けで実際のビジネスでは使えない単純なことでも多大な時間を要するやり方になってしまうのです。

　私は、もっとプロフェッショナルが使う手法を作りたかったのです。
私は、この現象を「論理的美の虚像」と名付けました。その心は、論理的な美だけを求めると虚像を追いかけることになるということです。

　そして、これを適切に排除しつつ手法を洗練化することに意欲を燃やしました。それは自分なりに考えたどり着いたのが感性的な発想を組み込むやり方でした。人が感じるものや感じたことをカタチにするということでした。