システムズエンジニアリングの超々上流を目指して

―システムデザイン・マネジメント学の射程―

「超上流工程」IPA/SEC主催セミナー（2011年7月12日）にて講演

慶應義塾大学大学院システムデザイン・マネジメント研究科

前野　隆司

超々上流とは何か？

慶應義塾大学大学院システムデザイン・マネジメント研究科委員長の前野隆司と申します。どうぞよろしくお願いいたします。

今、狼より紹介がありましたように、われわれの大学院は2008年に設立され、今年４年目を迎えています。私も、世界に２つと無い新しいコンセプトの大学院から世界を変える潮流を作るんだ、という志で設立前から参画しました。2011年の４月に創立の中心人物であった狼前委員長が定年を迎えたので、私が委員長を引き継ぎました。

今日の講演のタイトルは、「システムズエンジニアリングの超々上流を目指して」です。今日のお題である「超上流」に対して少し挑戦的に、「超々上流」と名付けてみました。

　まず、「超々上流」とはどういうことなのか、お話ししましょう。

　今日は、我々SDM（システムデザイン・マネジメント研究科）から４人の教員が来まして、システムズエンジニアリングの基本についてお話しする予定です。われわれシステムデザイン・マネジメント研究科が教育・研究していることのベースはシステムズエンジニアリングなんですが、SDMでは、工学を超えて、あらゆる学問を統合するんだという心意気で教育・研究を行っています。

システムズエンジニアリング、あるいはソフトウエアエンジニアリングの分野では、今、超上流が重要だと言われています。このため、今日の全体的な話は超上流の話なのですが、せっかくの機会なので、私は、その上はあるのか、というお話をしたいと思います。

「超上流」というのはソフトウエアエンジニアリングだけではなく経営まで含むコンセプトなのだから、それよりさらに上のレベルの「超々上流」なんてあるのか、と思われる方もおられるかもしれませんが、「超々上流」とは「超上流」を超えるということです。会社を経営して利益を得るというのは人間の一つの活動ですが、たとえば、私たちは、同時に、幸せに生きていこうとします。社員として仕事をするとともに、生活者として生きていく。

この例のように、経営も超えた所、つまり工学的に良いシステムを作るだけではなくて、私たちの生活はどうあるべきか、哲学的にどうあるべきか、アートとしてどうあるべきか、そういうあらゆる学問が関わる問いを含めた場を、超々上流と呼びましょうということなんです。

システムデザイン・マネジメント学の射程

サブタイトルに「システムデザイン・マネジメント学の射程」と書きました。射程の中心はシステムズエンジニアリング、ないしは、狼の話した戦略的システムズエンジニアリングです。しかし、「超々上流」の場合は、以上の理由により、射程は、あらゆる学問になります。

われわれの研究科の学生の半分は文系学生で、半分は社会人学生です。例えば、年金問題を解決するにはどういう政策提言をすべきかというような文系の問題を研究している学生もいますし、それから、実は私は、幸せの研究をしているんです。人間が幸せになるためにはどのような技術開発や営利活動をすべきか。どういう生き方をしていけば幸せになれるのか。幸福と欲望と共感はシステムとしてどのような関係にあるのか。人をシステムとして見て、つまりシステムズエンジニアリングで人間の人生というのを見ていくと、どうなるべきか。そういうことを大まじめにやっています。

私の話は、今日の全体のお話から少し逸脱するように見えるかもしれませんが、私がお伝えしたいことは、システムズエンジニアリングを超えたシステムデザイン・マネジメント学の射程は、要するに、超々上流を目指すところまで広がっている、ということです。私の後の話はもっと具体的な話になりますが、SDMでは、具体的なこともやりつつ、私の話のように非常に広いこともやろうとしているということをお感じいただければと思います。　

実は皆さんが仕事をされる際には、仕事の成果を出すために仕事をしているという側面と同時に、皆さんが生きて行くために仕事をしているという面もあります。つまり、第三人称的で客観的な仕事と、第一人称的で主観的な自分が、実は同時に存在しています。そういう話をしたいと思います。

私が懇意にさせていただいている、ある経営コンサルティング会社の社長さんがおられます。先日、この方がこういうことをおっしゃっていたんです。「日本のSE、システムズエンジニア、あるいはソフトウエアのエンジニアは、顧客要求の枠内の仕事をするだけで、その仕事をなぜなんのためにやるかという視点が全く足りない。だからソフトウエア技術者にコンサルティングして、どうやればいいか、超上流のコンサルティングをやったんだ。でも全然駄目だった。しょうがないので、そういうことはソフトウエア技術者に任せないで、経営コンサルが自分でやることにした。今はコンサルが入って行って、超上流はやってあげるんだ。」とおっしゃっていました。こんなことを言うと「何を」と反感を感じられるソフトウエア技術者の方も多いかもしれませんが、こんな見方をしている方が実際におられるということなんです。

ソフトウエア技術者には任せられない！？

私達の研究科の学生には、ソフトウエア出身の人もおられますし、経営コンサルタントをやりつつ学生をしているという人いますし、経営者や他分野の人もいろいろとおられます。そんな中で一つ思うことは、業種によって言葉の定義が違うということです。ソフトウエア業界は、言葉の定義が狭く、それに引きずられるのか、仕事の範囲も狭くなる傾向があると感じます。

システムの定義、システムズエンジニアリング、あるいはSEという言葉の定義、それからシステムアーキテクティングという言葉の定義、あるいは要求定義、要件定義という言葉の意味、これらが、ソフトウエアエンジニアリングの方と、その他のエンジニアリングの方、経営者の方、あるいは異分野の文系の仕事をしている方、それらの間で違うのです。

ソフトウエア分野の方々の頭が固いとは言いませんが、業界の言葉の定義がそもそも狭い。言葉が狭いとそれに影響を受けます。

話はそれますが、一般に、官僚は縦割りで駄目だと言われます。ところが、官僚の方と会ってみると、非常に広い視点で考えておられる方が、実は多い。官僚が駄目なのではなく、官僚組織が駄目なのです。組織が縦割りになっていて、その中で考えなければ官僚の仕事ができないようになっているから、頭のいい官僚の方はそれに合わせて働く。そうすると、縦割りの考え方をせざるを得ない。

個人として官僚の方と話してみると、国のために非常に広い視野で考えているのに、官僚組織の枠に入るとそのとたんに狭くなるのです。私の研究室には現役官僚の学生もソフトウエアエンジニアの学生もいるんですが、官僚の学生のある意味での視野の狭さと、ソフトウエア業界の方の別の意味でのある枠に入っている感じには、共通点を感じます。だから、こんな話をしているわけです。

システムとは？

では、定義についてみてみましょう。まず「システム」という言葉。日本ではよく、情報システムあるいはソフトウエアシステムのことをシステムと言います。それに対して、狼が申しましたように、システムズエンジニアリングでは、「ある目標を達成するために、その構成要素間が関係しあうもの」であれば、宇宙ステーションもシステムですし、宇宙ステーションを運用するオペレーティングシステム全体もシステムですし、それを国家間で連携して運用しようとする時には国際政治も含めてシステムです。要するに、システムという言葉の定義は、その対象に応じて、あらゆるものにまで拡張できるというのが、システムズエンジニアリングでの定義です。

実はシステムズエンジニアリングでのシステムの定義は限定されています。システムズエンジニアリングでは「ある目的を達成するために」作られたものをシステムと呼ぶ、というように明確に定義しています。これは役に立つことを目指すエンジニアリングだからです。

一方、例えば社会学、社会心理学、哲学の分野では、ある目的を達成しなくても、要素が関係しあっていればシステムであるとみなします。たとえば、社会学では、目的もなく自然発生的に出来上がった、例えば漫画のコミュニティのようなものも社会システムとみなします。このように、システムという言葉の定義は分野によってかなり異なります。

アーキテクティングとは？

それから、曲者なのが「アーキテクティング」という言葉です。システムズエンジニアリング、あるいはソフトウエアエンジニアリングではアーキテクティングという言葉を使います。また、アーキテクトという職種があります。アーキテクティング、アーキテクトという言葉は、もともとは建築分野の言葉です。SDMには建築業界の学生もいるんですが、以前、面白いことがありました。建築出身の人が「アーキテクティングって何ですか。良く分からない」と言うんです。「建築＝アーキテクチャ」なのに、ですよ。つまり、建築業界では、建築自体がアーキテクチャだから、あたりまえすぎて、その定義について考えたこともない、というわけです。

アーキテクティングというのは、基本的に「まずコンセプトを具体化し、物理的、情報的な機能を形のある要素に割り当て、オブジェクト間のインターフェース構造の定義を行う」ということです。要するに、建築家がやるように、まず、何も無い所からコンセプトを作り上げるという非常に創造的でクリエーティブな作業が前半にあります。次に、そのコンセプトを具体的に、どこをどのソフトで実現するかとか、誰がどのように分担してマネジメントして行くかといったような要素に割り当てて行きます。さらに、インターフェースを定義したり、細かい所をつなげていく。これが、アーキテクティングです。

システミックとシステマティックとは？

そして、その前半が「システミック・フェーズ」、後半が「システマティック・フェーズ」です。システマティックとシステミックとは何でしょうか。私達SDMでは、「木を見て森も見る」ように、「システムとして考え」ましょうと言います。「システムとして考える」という言葉を英語で言うと、「システミックに考える」「システマティックに考える」の２つがあります。

違いは何かと言いますと、システマティックというのは、システムを要素に分解して、きちんと漏れなく重なりなく、ちゃんと作って行きましょうということです。つまり要素還元です。系統的に、規則正しく、整然と、計画的に、偶発的ではなく、きちんとシステム全体を要素に分けて行きましょうということ、それがシステマティックです。

それに対してシステミックとは、組織の、系統の、体系の、全身の、全身性の、全体に渡る、という意味です。ちょっと分かりにくいかもしれませんが、英英辞典によると、「システムとして関連する全体としての」とあります。近い言葉にholisticという言葉があります。要するに、全体として、ということです。

つまり、「システマティック」はシステムを要素にどんどんどんどん細かく分けていってきちんと作りましょうという意味であるのに対し、「システミック」は細かく分けて行ったのでは見えない全体をきちんと捉まえましょうという意味です。

ところが、日本ではシステミックという言葉をあまり使わない。これは、まさに、「システミックに全体としてものごとを為す」という点が、日本では抜け落ちがちであるということを表していると思います。

残念ながらよく言われることですが、クリエーティブな製品は欧米で作られ、日本では上手に改良される。まさに、システミックなフェーズ、すなわち、新しいコンセプトをクリエイトする、ゼロからクリエイトする、非常にクリエーティブなフェーズ、これが日本に欠けている。日本は、コンセプトが出来た後でそれをいかにしてきちんと作って行くかというシステマティックなフェーズの方だけが得意です。

つまり、アーキテクティングという行為は、本来は建築の、中でも建築意匠の、非常にシステミックな現象を扱うクリエーティブな行為である、なのに、システムズエンジニアリング、あるいはソフトウエアエンジニアリングとして日本に輸入された時に、システマティックなフェーズのみが重視されたために、いかにきちんと作るかという方に重心が移ってしまったということなんです。しかし、コンセプトを具体化するためには要求を理解しクリエーティブに物を作らなければいけませんから、まさに超上流、超々上流につながるわけです。

もう一度整理しますと、アーキテクティングの前半はシステミックなフェーズ、後半がシステマティックなフェーズ。言い換えると、前半は基本的にはWhy（なぜ）を追求するフェーズ、後半はWhat（何を）、How（どのように）を分解していくフェーズです。

後半のシステマティックなフェーズは、細かく全体を分解して、ちゃんと運用できるようにしていく、あるいはちゃんと作れるようにしていくというフェーズです。それに対し、前半のシステミックなフェーズは、「要求分析」を含みます。背景は何なのか、わが社にとっての経営としての価値は何なのか、顧客要求は何なのか、このように、Why（なぜ作るのか）を考えるフェーズ、超上流のフェーズなのです。

要求（要件）とは？

次に、要求定義（要件定義）について考えてみましょう。要求（要件）は英語ではrequirement。要求定義はrequirement definitionです。私は、誤訳とまではいいませんが、あまりいい訳ではないと思っています。Requirementを英和辞典で引くと、要求、必要な物、必需品、必要条件。英英辞典だと、Something that you need or want. Something that you must have in order to do something else．何かをするためにあなたにとって必要な何かがrequirementなんです。英語でrequirementと言うと必要な物というニュアンスですよね。ところが、それを要求あるいは要件と和訳した途端に、あたかも、顧客がいて、その人が「これを作れ」と要求しているというかのようなニュアンスになってしまっています。

本当は、英語の定義を見るとわかるように、他人が要求したからrequirementなのではなく、あなたが何を必要とするのか、ないしは、システムにとって何が必要なのかをあなたが定義するのがrequirement definitionなのです。

ですから、私は、「要求定義」と言わずに、「必要条件定義」と訳した方がいいのではないかと思っていますが、既に言葉として定着していますから、しかたないですね。要求定義という言葉に対し、「顧客の要求なのだ」あるいは「作るための要件なのだ」というイメージを持ちすぎず、「必要条件という意味なのに、日本語ではたまたま要求、要件と呼ぶのだ」と理解した方がいいのではないかと思います。

つまり、「要求」は「顧客の要求」には限らない。超々上流とは、顧客の要求のみならずあらゆる要求を考慮しようということです。この点をもう少し掘り下げて考えてみましょう。

要求には顧客要求以外にこれだけいろいろな種類があるんだというお話をしたいと思います。

顧客の潜在的な要求とは？

私は、機械系出身ですが、脳科学もやっていまして、「心はなぜ存在するんだろう」というような研究も行っています。そこでキーになるのは意識と無意識なんです。私達は意識を持っていて、意識の上で、うれしい、悲しいといった感情を感じます。しかし、本当は、意識は無意識に操られているものに過ぎないのではないか、というのが私の理論「受動意識仮説」です。色々な本に書いていますので、ご興味のある方はぜひお読みください（『脳はなぜ「心」を作ったのか―「私」の謎を解く受動意識仮説』（筑摩文庫、2010年）など）。

今日は、その話は置いておきましょう。述べたい事は何かと言いますと、実は顧客の要求には、顧客の無意識的な要求があるということです。顧客に聞いても分からないから、創造的に想像すべき要求があるということです。例えば、私は医療ロボットの研究をやっていたことがあります。腹腔鏡下手術を行うお医者さんは、腹腔鏡用鉗子という非常に使いにくい器具を使いこなしています。そこで、医師の方に、「これをロボット技術で抜本的に改良しましょうか」と問うと、「いや、この先っちょがちょっと使いにくいからこれの角度を増やしてくれ」のようなことをおっしゃる。「ちょっと改良してくれ」というような要求しかしてこないんです。「遠隔医療ロボットを作って遠隔手術した方が便利なんじゃないんですか」と聞いても、お医者さんは「いやいや、ロボットなんか危険で使えないから、とにかくこの鉗子を少しだけ改良してくれればいいんだ、変なロボットなんか作らなくてもいいんだ」とおっしゃる。顧客であるお医者さんは医療の専門家で、その使いにくい鉗子を10年かけてやっと使いこなしたら名医といわれているわけです。それを無意識のうちに奪われたくないと思っているといったら言い過ぎかもしれないですが、抜本的な見直しという大きな視野から見た改良には思い及ばない。ロボット技術で鉗子を遠隔操作すれば使いやすくなることは、われわれロボット学者から見れば明らかなはずなのに、お医者さんにいくら言っても「いや、そんなものはいらない。そんなものがあっても危ないし、使い方が分からないから、やはり今までのやつを改良してちょっと使いやすくしてくれればいいんだ」と、おっしゃる。これがお医者さんの意識的要求なんです。

顧客が気付いていない無意識的な要求、潜在的な要求は、顧客自身には分からない場合があるということです。逆に言うと、顧客に聞けば分かる程度の要求を満たしている製品ばかり作っていても、抜本的なイノベーションは起こせない。残念ながら、アメリカのあのシリコンバレーの企業、例えばステラモータースのスポーツカーの電気自動車や、アップルの製品のような、斬新な製品は作れない。先ほどの手術ロボットの件も、シリコンバレーのベンチャー企業が、一億円もする手術ロボットを世に出したことで、決着がつきました。便利で使いやすく、安全な手術用ロボットを見た医師たちは、手のひらを返したように、これは使いやすくてすばらしい、と喜びました。医師たちは気づいていなかったけれども、無意識的、潜在的には、欲しかった訳です。私も、医師の意識的要求ばかり聞いていないで、シリコンバレーの企業のように、本当に必要なものは何なのかを考え、実際に作って、使ってもらって、納得してもらえばよかったんですが、後の祭りでした。

まさに要求という呼び方が悪いと思いませんか？　要求と言わずに必要条件と呼んでみると、顧客の意識的必要条件以外に、顧客が気付いていない製品の必要条件という視点に当然行き当たります。

それから陥りがちなのは、要求と呼んだせいで、相手はお客さんだというイメージにとらわれすぎてしまうという点です。そうではなく、顧客以外の要求が極めて重要です。たとえば、環境の問題、安全の問題、あるいは想定外の時にどう対処するかという問題、お医者さんにとって本当にいい医療とは何かという問題、というように要求（必要条件）は顧客要求以外にも多々あります。地球環境にとっての必要条件、商売敵の人たちに勝つための必要条件、そういうふうに、要するに顧客以外のステークホルダーを、他社や製造元、さらには、地球環境や、日本はこれからどうあるべきかという点や、あるいは日本という枠にとらわれずに中国とのビジネスとどうやって行くべきかという点など、あらゆる必要条件にまで視野を広げて考えていくべきです。

自己と他者の関係とは？

それから、自己と他者の話をしましょう。ここまで話してきたことは、意識と無意識、顧客と顧客以外の要求があるということでした。それに対して、ここでは「自己」について考えてみましょう。「自己」を考慮に入れるのは、近代科学から見ると反則だと言われるかも知れません。科学は客観的であるべきなので、主観と客観は区別しましょうというのが科学的な立場です。ですから、働く私の生き方なんていう主題は取りあえず置いておいて、対象とする製品について考えましょうというのが、それに対応した一般的な立場だと思います。

しかし、それは、近代西洋のデカルトから始まった考え方に過ぎません。近代はデカルトからカントまでだと言われますが、要するに近代とは、物事を分解して、自分と他人、正しいものと間違ったもの、西洋と東洋、そのように分けて行くことによって理解しましょうと考えた時代です。自己という主観的な主体は排除して客観性を担保するのが科学であり、モノ作りでもあるというのが従来の考え方だと思うんです。この次の時代がポストモダン（近代の後）という時代なのですが、このような哲学やシステム論の歴史の話は今日は置いておきましょう。

今日、超上流の最初のお話、森下さんのお話の中で、丸が４つ、つながっている図がありましたね。一番下がソフトウエアで、一番上が経営でした。経営には実は自分を含んでいるんです。つまり、近代科学を超越している。

私の図でいうと、中央の線よりも左側が対象で、右側が自分です。自分がシステムに入るというのは変な気がするかもしれませんが、科学ではなくビジネスでは当然入る訳です。「あなたは何のために仕事していますか」と聞かれた時に、「会社をもうけさせるためだよ」と答えますか？「自己実現のためだ」と言う人もいるでしょうし、「収入を得て生きて行くためだ」という方もおられるでしょう。そういう主観的な自分が一方にいて、客観的な製品やサービスが他方にある、というのがビジネスシステムなのです。

超々上流は科学を超える

主観と客観を切り分けるというのが科学的な考え方の基本なのですが、経営という問題、コンプライアンス、すなわち倫理のような問題、組織でプロジェクトをマネジメントするという考え方、これらを考えていくと、他者の構造と自己の構造は密接にかかわり合っています。おもしろいことに、自分の周りに人がいて、主観システムが広がっています。一方、製品の周りにものがあって客観的なシステムも広がっています。そして、両者が階層を超えて接している。そんな構造になっていると捉えるべきなのです。

つまり、超上流も考慮したシステム開発において要求について考える時には、主観側と客観側を同時にすべて考えていかなければならない。しかも、拡張して行くと、実は人生全て、宇宙全てを含んでしまいます。それが私の言う超々上流です。それでは、範囲が広すぎてやってられないじゃないかと思われるかもしれません。そこで、ビジネスとしては超上流までを切り取るべきかもしれませんが、根源的には、超々上流まで考えて、私達は、「何のために仕事をしているのか」という問いを徹底的に掘り下げて行くべきだと思います。つまり、要求という言葉の定義をどんどんどんどん広げて行くと、まさに哲学やアートなど、あらゆるものが含まれるということを申し上げたいわけです。

こういう抽象的な所まで話を広げるのは私だけで、次の講演からはもっとぐっと具体的な話になりますので、ご安心ください。

私達は、システムズエンジニアリングを中心にしながら、システムデザイン・マネジメント学という学問の研究と教育をやっています。システムデザイン・マネジメント学は、サイエンスからアートまで、自然科学から哲学思想まで、人類のあらゆる知恵を結集しなければ解決できないような全体の問題を解きたいという野望、志であるということです。

現代の大震災の問題ですとか、環境問題ですとか、世界のセキュリティの問題は、現在のグローバル社会では、もはや全てのものがつながっている。政治からモノ作りから軍事から、思想・宗教まで、あらゆるものがつながっていると考えないと解決できない。そういう意味では、私達それぞれは、仕事としては全体システムの中の要素を対象にする訳ですが、しかし、それぞれの仕事はこの巨大な世界というシステムのどこに位置づけられていて、今の仕事ではどこを切り取ってやっているのか、非常に巨大な視点から、ミクロの視点まで、縦横無尽に視点のサイズとフォーカスを行き来させるということが大事なのです。

How-Why Diagramは「幸福」につながる

ここに示した図はHow-Why Diagramという図です。中央の線の左側が客観的な対象で、右側が主観的な自分です。この線より下がシステマティック・フェーズで、上がシステミック・フェーズです。つまり、下側は、何をどのようにやって行くか、あるいはそれをどうプロジェクトマネッジメントして行くか、といったシステマティックな実際のビジネス。

上側は、私達が何かを行うとき、なぜ行うのか？を繰り返し聞いた場合だとお考えください。顧客の要求に合わせるためにシステムを作ったり、コストダウンや、他者に勝つなど、色々な理由が階層的に存在していますが、なぜやっているのかを聞き続けると、左上では商品の意義が次第に抽象化されていきます。右上では私たちの人生の意義が次第に抽象化された結果、究極的な理由、私は幸せになりたい、世界を幸福にしたい、という根源的な理由に到達する。

中には、「そうではない」と言う人もいます。私の知り合いの文学者で「自分は幸せになりたくない。幸せになると太宰治を楽しめなくなるので、幸せになりたくない」と言う人がいます。彼は特殊な場合で、普通はそうではないでしょう。多くの人は幸せになりたいのではないかと思います。また、製品を開発するという仕事の究極の意味は何なかのと問うと、人類の幸福や、地球・宇宙の永続のような、非常に抽象的なレベルに至るはずです。抽象的なレベルと具体的なレベルはつながっている。超上流というのは事業レベルに限定されますが、超々上流まで行くと、人生も含めて、あらゆる物事がつながっている。そういう視点を持つことが大事だというのが私のメッセージなのです。

この図（図8：『思考脳力のつくり方―仕事と人生を革新する四つの思考法』（前野隆司、角川oneテーマ21、2010年））は、システムの階層性を図にしたものです。まず、要素に分けて考えるということがある。その周りに、システムとして考えるということがある。しかし、システムとして考えても考えられないこともある。つまり近代を超えたポストモダンという時代において、ポストモダン的に考えるべきことが、その外側にある。最後に、考えるということも超えて、holisticに全体を捉えるというフェーズがある。システムズエンジニアリングを超えて、思想・哲学のレベルまで、あらゆることをシステムとしてつなぐことが必要なんじゃないかということなんです。今日は、この、システムの階層性の話について詳しくは述べませんが、ご興味のある方は、拙著『思考脳力のつくり方―仕事と人生を革新する四つの思考法』（角川oneテーマ21、2010年）をお読み頂ければ幸いです。

超々上流はあらゆる問題をシステムとして接続する

システムの階層性の話をしましたが、話を元に戻しましょう。申し上げたかった事は、要するにrequirement（要求）とは何かを考えるときに、要求という訳語が良くないということです。本当は、必要条件と言った方が適切です。顧客の意識下にある要求と無意識の要求、それから顧客と顧客以外、そして対象とするシステムと対象ではなく自分というシステム、そのように要求を整理して考えていくと、思考が適切に広がって行きます。

この考え方がどこで必要かというと、抜本的な意味での問題の整理です。超上流になったところで経営という観点が出てきます。もはやエンジニアリングだけではだめです。さらに、超々上流になると、交渉術とか、哲学とか、アートとか、そういうものを含まなければ解けない領域を含まざるを得なくなってきます。そんな時に、全人生、全宇宙、全仕事を含む巨大な視点と、現実的な視点とを、縦横無尽に行き来させるためには、全体のシステムとしてのつながりをきちんと理解しておく必要がある。部分システムしか理解していないと、上のレイヤーが問題になったときに対処できない。

そういうわけで私の話はかなり広い所までいきました。私達が研究・教育しているシステムズデザイン・マネジメント学は、今申し上げた哲学までを射程に含む広い学問ですが、一方、基本的には目的を定義し、スコープを明確にしてきちんと解いて行くのがシステムズエンジニアリングです。

それに対して、Systems of Systemsという考え方があります。目的が明確なシステムが複数集まって何か機能を果たしている場合、Systems of Systemsと呼ぼう、という考え方が、システムズエンジニアリングからもフロンティアとして出てきています。

別のシステムの学問としてSoft Systems Methodologyというのもあります。ここでのソフトはソフトウエアという意味ではありません。「柔軟な」という意味でして、社会や組織といった、目的や定義があいまいな対象を扱う時にどういう指針を与えるかを考える学問です。

システムデザイン・マネジメント学はあらゆる問題の解決を目指す

つまり、われわれの学問は、システムズエンジニアリングという最も確実なシステム開発に向かう学問以外にも、Soft Systems Methodologyのような学問、今日私が少し述べた哲学・思想的な話まで、システムに関するあらゆる学問を含みます。

慶應義塾大学大学院システムデザイン・マネジメント研究科は、社会人の方も受け入れる大学院ですので、部下の方や、あるいはご自身も、ご興味があればぜひご入学頂ければと思います。学生の年齢は、20代から60代くらいまで広がっています。半分弱は新卒学生ですが、プロのエンジニアもいますし、コンサルタント、経営者、弁護士、医師、教員など、あらゆる職種の人が、複雑に絡み合っていて一つの学問だけでは解けないような複合的な問題を解こうとして集まっています。前にも述べましたように、文系も理系もいます。学生として来ていただくのも大歓迎ですし、何か課題を持ち込んでいただいて、SDM研究所で一緒に課題を解決するというような活動もできます。ぜひ、教育、研究、社会活動あるいは御社の課題解決、ないしは、あなたの人生の課題解決など、あらゆる問題に対して新たにデザインを行いたいという方、いっしょに課題を解決しましょう。いつでもお気軽にご連絡頂ければ幸いです。今日は、たいへん多くの方にご清聴いただきまして、どうもありがとうございました。これからも、どうぞよろしくお願いいたします。