熱血クラシック音楽コメディ

「のだめ」が面白い。原作の漫画もドラマもだ。
別に、主人公の名字が私と同じだから言う訳でも無いが。

この漫画・ドラマ、全体的に面白いのだが、特に面白いと思うことが２つある。

一つは、「熱血もの」だということだ。
漫画の｢のだめ｣もドラマも熱血ものだ。一見ドタバタコメディのように見せかけて、実はスポ根ならぬ音楽根性ものが「のだめ」の正体だ。

正直、こんなに真剣に音楽に取り組んでいるキャンパスライフがあるとは知らなかった。
私は、音楽、特にクラシック音楽に関しては全く知識が無い。音楽学校／大学に足を踏み入れた事すら無く、恥ずかしい限りである。

音楽に対する知識が無く、「のだめ」が、どれほど真実に忠実であるかどうか語ることはできないが、ドラマや漫画で見る限り、素晴らしいというか、羨ましい学生生活が伝わってくる。

音楽に関してウンチクを述べる事はできないので、キャンパスライフの方に話題を振る。

音楽大学には敷地内に足を踏み入れた事の無い私だが、理学系／工学系大学なら数限り無く入ったことがある。学生時代に私自身が通った大学もそうだが、今現在も大学に行くことが多い。

その工学系の大学にもキャンパスライフはある。
もちろん、学生の中には遊びほうけている者も居るし、むしろその方が多数派だ。

だが、確実に、千秋真一のように、その分野に対して真剣に取り組む姿がある。

例えば、ロボットを作ったり、缶サットやキューブサットを作ったり、人力飛行機やロケットを作ったりと様々である。モノ作りに限らず、理論の構築や実験、式の展開、論文書きに真剣に取り組んで居る。

どうも、一般的には、理学部／工学部は、堅苦しくて暗いと言うイメージがある。しかし、本当はモノ作りや理論の構築だって、ロマンや情熱や感動にあふれて居るのだ。

誰か、そう言った理学部／工学部の本当の姿を、「のだめ」のように分かりやすく、面白く伝えてくれないかなあ・・
まあ、まるで無い訳じゃ無くて、映画「ロボコン」とかＴＶドラマ「ロケット・ボーイズ」とかあったか・・・・　受けなかったが。

「のだめ」で、面白いと思う、もう一つは「指揮者」を題材にしていることだ。

今までの漫画やドラマなら、確実に「演奏者」の方を主人公にしたと思う。スポ根もので、野球ならピッチャーやバッター、ボクシングならボクサーを主人公にするようにだ。今までなら、間違っても丹下段平を主人公にはしないだろう。
ところが「のだめ」では、実質上の主人公である千秋真一は「指揮者」を目指して居る。

繰り返しになるが、私には音楽の知識が無い。だが、その私でもクラシック音楽における「指揮者」の存在は、以前から興味があった。

大人数のオーケストラは、音を出すことが目的の「音楽」のために編成されて居る。そのオーケストラの一員なのに、全く「音」を出さないメンバーが居ること自体、特異だと思う。だが、それ以上に「音」を出さない指揮者がオーケストラの中で中で一番偉そうにしているのだから、おかしいじゃないか。少なくとも音楽の素人としては、そう思ってしまう。

もちろん、ちゃんと音楽が分かって居る人にとっては、指揮者の存在の理由も重要性も当然のことだろう。
これ以上の突っ込みは、音楽の知識が無い私には無理なので、またしても話題を別の方向に振る。

私の仕事のひとつは、新しいアイデアの実現を「設計」する事だ。

設計の極く初期の段階で、色々な専門家が集まって討論をし、アイデアを出し合って、大まかなコンセプトを作り上げて行くことがある。
この時、討論の進行役をコンダクターつまり指揮者と呼ぶことがある。

コンダクターと言う呼び方は、あまり一般的でなくデレクターとかアーキティクトとか色々な言い方が混在して居る。が、私は昔からコンダクターと言う呼び方が気に入って居て、よく使って居る。

色々な専門家が集まる討論会をセッションと呼ぶ。もちろん、セッションには討論会の意味もあるが、演奏会の意味もある。セッションと言うと JAZZ や JAM セッションを思い浮かべるが、クラシックセッションと言う使い方もあるそうだ。
そう言えば、電子機器や光学機器などをインスツルメンツと言う時もある。この辺の名前を付けた人は、よほど音楽に引っかけたかったんだなあ。

セッションは、オーケストラほど大編成でなく、せいぜいが 10 人までの専門家が集まって行う。

コンダクターの役割は、クラシックオーケストラの指揮者と同じで、演奏しないことだ。

設計のための討論会なのに、コンダクターは設計自体や解析・計算などはしない。私が主催する、つまりコンダクターを務めるセッションに参加したことがある人なら判ると思うが（このブログを読んで居る人の中にもきっと居るはずだ）、私は専門家同士のインターフェースを取って居るだけだ。違う分野の専門家同士だと、専門用語が通じない時があるので、やさしい言葉に通訳する。

冗談を連発して滑らかにコミュニケーションが進むようにし、課題となる問題点を明確にし、その解決を方法を色んな視点から検討できるようにしている。方向性のイメージが伝わるように、たまに簡単な解析などをやってみたりもするが、本質は専門家に任せる。

専門家は、概ねソリスト（独奏家）が多い。
大編成のオーケストラに慣れて居ない場合が多いし、多分野の専門家と同時に討論すること自体に有効性を認めない事すらある。

だが、ソロ演奏では味わえないオーケストラ演奏ならではの醍醐味がある。

ある分野で完全に行き詰まって居た問題が、他の専門家の一寸したアドバイスで解決する事がある。それが連鎖的に広がると、それまで全く存在も予想できなかった新規コンセプトやシステムが誕生する瞬間がある。

「降臨」して来たとすら思える感動の瞬間だ。

偉そうな事を言ってはみたが、セッションを開ける機会は少ないし、本当に感動できる瞬間など滅多にあるものではない。せいぜいが、１年に１度あるかないかの極めて稀な出来事だ。

「のだめ」の作品中で、「身震いするほど感動する演奏ができることは本当に稀」と誰かが言ったが、まさにその通りだ。

だが、本当にあるんだよ。
設計のセッションでも「身震いするほど感動」が訪れることが。

システムエンジニアリング（その６）要求分析

前回の「システムエンジニアリング（その５）」で、さらりと書いて、ちゃんと説明をしなかった事がある。
「要求をスペックで置き換えてはいけない」についてだ。
今回は、この事について説明しようと思う。

ユーザーから、「要求」を聞き、その要求に合せたモノを作らないと良いモノが作れないと言うことは、前まで何回も書いたし、同意してもらえると思う。
そこで、「良いモノ作り」には「良い要求が必要」と言う事になる。
ここまでは良いのだが、「良いモノが作れないのは、良い要求が無いからだ！」とか「良い要求を俺にくれ！」と言い出すエンジニアが居るが、それは間違いだ。
「良い要求」が無いのなら、作れば良い。「良い要求」は、努力しなくても天から降ってくるようなものではなく、ユーザーとなり得る人と協力し、作り上げるものだ。

そもそも、ユーザーが、最初から明確な要求を持ってやって来ることなど、ほとんど無い。
既に同じようなモノが市場に出回って居れば、話は別だが、全くの新規モノの開発や飛躍的な改良の時は、ユーザーは曖昧模糊としたイメージを持って居るに過ぎない。

「ユーザーの持つ曖昧模糊とした要求のイメージ」を、はっきりさせ、「具体性を持つ明確な要求」にして、モノ作りに活かせるようにするのは、「システムエンジニア」の役目であり、責任だ。

ここで、「ユーザーの曖昧模糊としたイメージに、具体性を持たせ、明確な要求」にする時に、「要求をスペックで置き換えてはいけない」のである。多くのエンジニアは、この間違いをおかしがちだし、また、間違いだと気付いて居ない場合すら多い。

何故、「スペック」に置き換えてはいけないかと言うと、「スペックが決まると言う事」は、その「前提となるハードウェアやソフトウエアの構成が決まっている」事を意味するからだ。その「ハードウェアやソフトウエアの構成」すなわち「システム」の決定が明文化されて居る場合もあるが、多くの場合「暗黙の了承」と言う形で決まってしまっている。
暗黙であろうと明文化されていようと、予め「ハードウェアやソフトウエアの構成」が決まっていると、後の開発を助けるどころか、間違った方向に突き進む場合がある。前回の「桶とポンプ」が、その良い例になって居ると思う。

要求は、「システム」から分離した形で明確にしなければならない。

前回の要求は、次のような文だった。
「毎日、水を運ぶので、できるだけ多い量の水を井戸から家に運びたい。」
この文の中には、「桶」と言う言葉は出てこないし、また、暗黙の内にも「桶」を連想させる部分は無いようにしていた。

だが、その一方で、「ユーザーの持つ曖昧模糊としたイメージ」を明確にするために、「具体的なシステムの構成とスペック及び使用方法（運用）」の例示が必要になる場合が多い。私の経験では、「ユーザーのイメージ」の明確化のためには、程度の差はあれ「具体的な例示」が、ほぼ１００％必要になると言える。

まるで、矛盾するようだが、「要求は、具体的なシステムから分離」する一方、「要求の明確化のためには、システムの具体化」が必要になる。

実際には、どうするのか？
実践編は、後半に続く・・・

システムエンジニアリング（その５） 問題の抽象化 「評価」

一人の人間が把握できない程の大規模なシステムを作るためには、「問題の構造」を抽象化を行うことが重要なことは、システムエンジニアリング（その４）で説明した通りだ。付け加えるなら、大規模なシステムだけでなく小規模なシステムでも「問題の構造の抽象化」は有効な手段である。

さて、「問題の構造の抽象化」は、次の二つの側面を持つ。
（１）問題の構造化
　システムを分割し、問題の構造を構築する。
（２）評価
　「問題の構造」を評価する。

この内、（１）は、本来、システム内に存在する問題を拾い上げ、それらの関連を考慮することだ。しかし、詳細な「問題の構造」は、具体的な機器構成の検討を必要とする場合がある。
（２）は、「問題の構造」を評価するのだが、数値化するのが望ましい。この「評価」の結果を用いて、システム設計をコントロールするのだ。

如何にも「システム設計」らしい「機器構成の検討」は面白そうなので、一般的に、（１）を優先してやってしまう傾向になる。しかし、「問題の構造の抽象化」の最終的な目的である「評価」を理解せずに「機器構成の検討」を行うと無駄になることが多い。無駄どころか、マイナスの結果になることすらある。
ここは、はやる気持ちを抑えて、まずは「評価」について検討しよう。

さて、「評価」だが、システムエンジニアリング（その３）に登場した「バランスの悪い桶」を再登場させ、これを使って説明しよう。

まず、やってはいけない事は、「一部の要素のみを評価の対象にすること」である。
当たり前のようだが、陥り易い間違いだ。例えば、自動車なら「エンジンのパワーのみ」とか「サスペンションの形式のみ」に注目することだ。図の「桶」の例では、最も短いＢの板の長さを評価の対象とすることになる。
確かに、Ｂの板の長さを長くすると、それに桶に入る水の量は比例して増える。だが、それは、Ｂの板がＤの板の長さになるまでの間の話であり、それを超えると効果が無くなる。にも拘らず、「Ｂの板の長さのみを評価の対象」とした場合は、延々とＢの長さを長くし続けようと改良を加え、他の板よりも遥かに長くなり、さらにバランスの悪い桶になるというのは、既にシステムエンジニアリング（その３）で説明した通りだ。

次に陥りがちな間違いは、「速ければ速いほど良い」とか「大きければ大きいほど良い」と言った節操の無い「評価」だ。
「桶」の例なら、「桶の中に入る水の量」のみで評価する事だ。この場合、「桶の量」をドンドン増やすように改良が続けられ、やがて、桶は家よりも山よりも何よりも大きくなって行く。本来、この桶が何の目的で使われるかを明確にしておかないと、とんでもない大きさに桶が成長してしまう。例えば、この「桶」は、人が運ぶものだとすると、桶が重くなり過ぎ、人が運べないほどになると全く意味をなさないものになってしまう。
最初に、「桶」が、どのような使われ方をするのかをイメージすることが大事だ。

この図のように、家の外にある井戸から家まで水を運ぶための「桶」を考えよう。
実際に「桶を使う人」＝「ユーザー」から、何が望みかを聞く。

「毎日、水を運ぶので、できるだけ多い量の水を井戸から家に運びたい。」
これが「ユーザー」の望み、堅い言葉で言うと、「要求」である。

陥り易い間違いが、「要求をスペックで置き換える」ことだ。
例えば、「ＸＸリットルの水の入る桶」と言う言い方が、「スペック」である。またまた、車の例えで言えば、「６人家族でキャンピングを楽しみたい」が「要求」で、「２５００ｃｃ級のミニバン」が「スペック」である。

次に、「運べる水の量」を検討する。まず、「水を含めた桶の質量」と「一日当たりの運べる回数」の関係を調べる。実際に使う人＝「ユーザー」に桶と同じ形状の色々な重りを運んでもらい、図の右上のようなグラフが得る。重すぎると運べないし、重さがゼロでも、ある程度以上の回数を運ぶことができない。だから、グラフのように右下がりのグラフになる（直線になるかどうかは極めて怪しい）。

また、「水を含めた桶の質量」と「一回に桶で運べる水の量」は左下のグラフになる。

「桶の効率」を
（桶の効率）＝（桶に入る水の量）÷｛（桶自体の重さ）＋（桶に入る水の量）｝
とすると、グラフの赤い線は、「バランスの悪い桶」の長さがバラバラのような「効率の悪い桶」であり、グラフの青い線は、板の長さが一定で無駄な部分が無い「効率の良い桶」だ。

「１日に運べる水の総量」は、右下のグラフになる。このグラフは、先の二つのグラフを掛け合わせたものだ。グラフの中央部の山の頂点が、最も「１日に運べる水の総量」が多いところだ。同じ山の頂点でも、赤い線より青い線の方が、量が多い。つまり、「効率の良い桶」が良いことになる。

このように右下のグラフの頂点を目指すように「評価」することが良いことが分る。
すなわち、
・「桶の効率を良くする」
・「その上で、１日に運べる水の総量を最大にする桶の大きさにする」
に、ブレークダウンできる。

ところが、上記のようなブレークダウンをすると、間違った最適化を行う可能性が出てくる。

図の左上の「バランスの悪い桶」は、先の「ブレークダウン」で評価して、改良すると、右上のようになる。これは一見すると、正しい改良のように見える。
ところが、「一部の板の長さを長いままにし、それに別の板を通す」ことで、右下のように「持ちやすい桶」になる。こうすると、「桶の効率」は、むしろ悪化するが、持ちやすいので、「一日当たりの運べる回数」は増え、最終的に「１日に運べる水の総量」は増える可能性もある。

単純に「桶の効率」だけを追求すると、右下のような「持ちやすい桶」を見付ける事はできない。このように、右上への最適化を近視眼的な「局所最適化」と言い、右下への最適化を「大局的最適化」と言う。「評価」をあまりにも抽象化し過ぎて、本質を見失うと「局所最適化」に陥り、「大局的最適化」ができない事が多い。
「評価」は、「要求」の本質に合わせて、柔軟に変化させる必要がある。最近のシステムエンジニアリングでは、このように「実どのような使われ方をするのか」だけではなく、「故障したとき、どうやって修理するか」「不要になった時、どう廃棄するか」までをイメージすることが、重要だと言われている。

ところで、ユーザーの要求が
「毎日、水を運ぶので、できるだけ多い量の水を井戸から家に運びたい。」
の場合、図の右下のような「持ちやすい桶」が最適設計であろうか？
私は、そうは思わない。
「毎日、できるだけ多い量の水を井戸から家に運びたいのなら、井戸から家までホースか管を引いて、ポンプで水を汲み上げた方が良い」と提言するだろう（電気が使えれば、電動ポンプで、そうでなければ、足踏み式ポンプで）。

「そんなのインチキだ。」と言われそうだが、ユーザーの要求を分析すれば、ポンプの方が良いに決まっている。仮に「桶作りの専門家」であっても、「桶以外の解決方法」があれば、提言できなければ、本物の「システムエンジニア」ではない。「桶」はあくまで手段であり、目的ではない。誰かが言ったが、「宇宙で書き物をしたければ、スペースペンを開発するより鉛筆を使った方が早い」のだ。

今回の最後の陥りやすい間違いは、「手段を目的化する」だ。

システムエンジニアリング（その４） 超人にならなくていい

モノ作りで日本が得意な分野は、カメラ、ウォークマン、バイク、自動車。これらは、世界のトップクラスだ。ところが、それより大きなモノ作りは決して得意とは言えない。何故だろう。

日本がモノ作りで得意とされるものは、みんなコンパクトでイメージし易いものだ。モノ作りに参加して居る人達が、同じイメージを共有できれば、良いものが作れる。

前回は、「バランスの悪い桶」を例に「バランスの良い設計」の説明をしたが、「桶のイラスト」を一見すれば、問題が把握できる。だが、桶が見えずに「手探り状態」の場合、「バランスの良い設計」が困難になる。
「桶のイラスト」のように、「どの板を長くすると良くなる」とか「どの板は短くしても良い」とか「長さを揃えた方が良い」とか、それぞれの要素が、どのように結び付いて居るかを「問題の構造」と言う。良いモノ作りのためには、「問題の構造」を把握することが必要だ。

或る説によると、日本のモノ作りは、部品数が１０万点を超ると苦手になると言う。その説が本当かどうかは知らないが、バイクの部品数が８０００～１万、車が１万～４万だと聞くと、なんとなくそうかと思ってしまう。ちなみにロケットの部品数は約３０万だそうだ。

とすると、「１０万より少ない部品数なら、問題の構造の把握ができ、バランスの良い設計ができる」なのかもしれない。

私は、単純に部品数で決まるとは思えっていない。部品数では１０万を超ても、日本の得意なモノがあるからだ。例えば、システムとしての「鉄道」である。１５両の一編成だけでも、車の部品数の何倍も有るだろうし、その上、同じ線路の上を走って居る他の車両まで考えると、とてつもない部品数となる。ただし、鉄道の場合は同じような車両が何台もある。部品の数は多くても、その種類は余り多くは無いのだと思う。

必ずしも部品数が１０万を超ると難しくなるかは微妙だ。しかし、この「１０万」と言う数字は、一人の人間が一つ一つの部品まで把握する限界なのではないかと思う。

「１０万」と言う数字だけでは、それを把握できるかどうか分らないと思うが、分かりやすい数字を例にしてみよう。
例えば、小学校や中学校で覚えた教育漢字は1006文字である。これは義務教育を受けた人なら誰でも全て覚えていることになる（筈だが、最近ワープロのせいか、危ない）。
常用漢字は1945文字。この程度は、すぐには書けなくても見れば区別が付くだろう。
逆に多い方では、広辞苑の項目数は２３万語。多分知らない言葉がイッパイあるのだろう。同じ岩波書店の一般的な国語辞典は６万３千語。（別に岩波書店に義理は無いが、比較のために同じ出版社の辞典にした）
「広辞苑の言葉を全て覚えてるのは無理」だが、「国語辞典の言葉の半分くらいは既に知って居るんじゃないか？」と言う気にならないか？
「国語辞典の半分の言葉」なら、３万。ちょうど、自動車の部品数に等しい。
ロケットの部品数は、広辞苑を超る。

つまり、部品数が少なければ、一人の人間で覚え切れる範囲になり、モノ作りの対象である「モノ自体」に精通できる。その結果、「問題の構造」を把握でき、「バランスの良い設計」が可能になる。

「良いモノ作り」のためには「バランスの良い設計が必須」で、そのために「問題の構造」の把握が必要。
「問題の構造」の把握のために、「モノ自体」に精通することが大切だ。
「より良いもの」、「より高性能なもの」「より高機能なもの」「より複雑なもの」「より大規模なもの」を作るためには、精進して「モノ自体」に精通できるように努力する事が大事だ。

と、当然のように思う。
だが、ここに大きな落とし穴がある。

「何故、欧米では日本人が苦手とする巨大システムの開発が可能なのか？」
その答えがない。

「欧米人は、把握できる部品数が、日本人よりも多い」のか？
そんな事は無いだろう。人種により把握できる部品数の上限に差はあるかどうか知らないが、たぶん、有意な差は無いだろう。

では、何が、日本人と欧米人の差だろうか？

日本人の場合、さっき書いたように
『「より良いもの」、「より高性能なもの」「より高機能なもの」「より複雑なもの」「より大規模なもの」を作るためには、精進して「モノ自体」に精通できるように努力する事が大事だ。』
と、本当に精進・努力をする。
部品数が、１万、２万の内は良い。確かに精進・努力をすれば、それに応じて「より良いもの」を作ることができた。
ところが、部品数が１０万を越え、一人の人間で把握できなくなると、「より良いもの」が作れなくなる。これは、精進・努力が足りないのだと反省し、さらに精進・努力を繰り返す。だが、一向に事態は好転しない・・・

では、欧米人は、どうだろう。
彼らは、あっさり精進・努力を諦めてしまう。
「諦めるなんて、情けない」等と思ってはいけない。彼らは「諦める」代りに、もっと大きな事を受け入れるのだ。
「自分が有限の能力しかない人間であること」を受け入れるのだ。

日本人は、極めて諦めが悪いというか、プライドが高いというか、「自分が有限の能力しかない人間であること」と言う当たり前のことを受け入ることができない。だから、何でも精進・努力さえすれば、物事が解決すると考えてしまう。それは或る意味、人間を超る超人になろうという無駄な努力に似ている。

だが、発想を変え、「自分が有限の能力しかない人間であること」を受け入れれば、違うアプローチが生まれる。

もう一度、良く考えてみよう。
(1) 「良いモノ作り」のためには「バランスの良い設計が必須」・・これは本当だ、たぶん。
(2) そのために「問題の構造」の把握が必要・・これも本当だ、たぶん。
(3) 「問題の構造」の把握のために、「モノ自体」に精通することが大切だ。・・これは必ずしも、そうではない！！

「問題の構造の把握」に有効な方法の一つが「モノ自体に精通すること」であることは事実だ。
だが、必ずしも「モノ自体に精通すること」が「問題の構造の把握」に有効な唯一の方法である訳ではない。

要は「問題の構造の把握」さえできれば良いのだ。必ずしも「モノ自体に精通する」必要は無い。

何らかの方法で「問題の構造」を抽象化し、それを「把握」する。それにより、「個人の有限の能力」の限界を遥かに超ることが可能となる。

貴方は、どうする？
プライドから、「自分が有限の能力しかない人間であること」を受け入れるのを拒み続けるか？
それとも、それを受け入れ、「個人の有限の能力の限界を遥かに超ること」を可能とするか？

もちろん、問題は、如何にして「問題の構造」を抽象化するかなんだが・・・

システムエンジニアリング（その３）

イラストは、良く「バランスの取れた設計」の説明に用いられる例である。
水を入れる「桶」だが、板の長さがバラバラだ。この桶に溜まる水の量は、最も短い板の長さによって決まる。中の水位が、最も短い板の長さを超えたら水は溜まらなくなるからだ。

この桶を改善し、溜まる水の量を増やす方法は、簡単だ。最も短い板を長くすれば良い。
「バランスの良い設計」にすることも簡単だ。すべての板の長さを同じに切り揃えれば良い。（別に長すぎる板を切らなくても良いのでは？・と言う意見もあるかもしれない。だが、長すぎる板は重くなるし、持ち運びなどで邪魔になるから、同じ長さに切り揃えるのが最も効率的でバランスが良い）

実際の設計では、「改善する方法」も「バランスが良い設計にする方法」も、この例ほど簡単ではない。
一言で「バランスの良い設計」と言うが、どういう状態が「バランスの良いかどうか」分からない場合が大半だ。

イラストを見れば、一目で、「どうすれば改善できるか」「どういう状態がバランスの良い設計か」分かる。
仮に、この絵のような状態であることが見えないとしよう。その場合、手探りで、状態を調べるしか方法は無い。

そこで、次のような実験を行ってみる。
まず、取り敢えず、あふれるまで水を入れて、量を測る。次に、水を入れて抜き、桶を分解した後、Ａの板の長さを少し変えて、再び、組み立てる。同じようにあふれるまで水を入れて、量を測ると、水の量に変化は無い。
次に、Ｂの板の長さを、少し変えて、同じことを試す。今度は、Ｂの板の長さを変えた分だけ、水の量が変化はすることが分かる。
Ｃ、Ｄ、Ｅの板にも、同様のことを繰り返し、これらの板の長さを変えても、水の量は変化しないことが分かった。

以上の事から、次のことが導かれる。
「桶に溜まる水の量は、Ｂの板の長さのみに依存し、ほぼ、Ｂの板の長さに比例する。Ａ及びＣ～Ｅの板の長さは、桶に溜まる水の量に影響しない。」

この結果、「桶の改善」イコール「Ｂの板を長くする」に置き換えられる。
Ｂをドンドン長くして、他の板より長くなっても、気が付かない。先のような実験を行うことが面倒だからだ。
Ｂの板を、いくら長くしても水の量が増えなくなっても、目標が「Ｂの板を長くする」にすり替えられて居るから、構わずドンドン長くする。Ｂの板が邪魔になり、重くなって桶自体が持てなくなって、初めて間違って居たことに気が付く。

笑い話では無く、このような事が本当に繰り返される。例えば、４０年くらい前の国産車は、明らかにエンジンの馬力が足りなかった。箱根の坂道さえろくに登らない。「馬力さえ上げれば、良い車になる」と国産メーカーはエンジンの馬力アップ競争になった。コンベンショナルなエンジンで、ほどほどの馬力がでるようになると、やれターボだのＤＯＨＣだのスーパーチャージャーだのインタークーラーだの付け加え始めた。サスペンションやタイヤの性能を超え、危険なほどエンジンの馬力が上がると、もはや「良い車」ではない。これが１５年くらい前まで続いた。

前回の「システムエンジニアリング（その２）」から読んで居る人は、「Ｂの板の長さのみ注目」が「要素技術偏重」で、「桶の水の量に注目」が「システムエンジニアリング」に当たることが分かると思う。

システムエンジニアリング（その２）では、「当たり前の要素技術の組み合わせで、新しいシステム」と言ったが、全く新しい試み（例えば「恒星間飛行」）のシステム設計の場合、取り敢えず「バランスの悪い桶」でも良いから、作って評価することが大切だ。実際には作れないなら、計算上でもバーチャル上で代用する。

その結果、「Ｂの板を既存の技術では足りないくらい長くする」事が必須であることを見つけてから、「Ｂの板を長くする研究」を始めるのである。また、時々再評価し、「Ｂの板が他の板を超えた」場合は「Ｂの板を長くする研究」より、「他の板を長くする研究」に比重を置き換える必要がある。
また、「Ｂの板を長くする」事は改善案として出やすいが、「Ａ及びＣ～Ｅの板の長さを短くする」と言う改善案は、なかなか実行されない。それなりに上手くいって居るものに、手を加えるのは恐いからだ。

「システムを良くするために、必要な要素技術を選び、研究する」のであって、「要素技術の改善が、システムを良くする」のではない。
ましてや、「要素技術の改善こそが全て」のではない。

システムエンジニアリング（その２）

ある人に、「斬新なコンセプト」を描いたイメージを見せた時の反応が印象的だった。その「斬新なコンセプト」には、新規性のある「要素技術」は一切使っておらず、「20年以上前からある陳腐な技術」の寄せ合わせで、全く新しいコンセプトを作ったのである。

その時、その人は、こう言った。
「こんな事が判らなかったなんて、昔の人は馬鹿だったんですね。」

「当たり前の要素技術の組み合わせなら、今度のような組合せを、昔の人も当然見つけられる筈だ。それなのに、見つけられなかったのなら、昔の人は馬鹿だ。」と言う訳か。

この反応に呆れるというより、「ああ、またか」と言う感情の方が強い。ただ、元になる考え方は同じだが、反応自体は人によって微妙に異なる。

主な反応は「何か新しい（要素技術の）ブレークスルーがあったんだろう？」「設計思想とか、パラダイムシフトを起こす要因は何なんだ？」「そう言ったものが無ければ信じられない！」

反応の傾向を整理すると、大体、次のようになる。
(1)「昔の人は馬鹿だった」
(2)「何か新しい要素がある筈だ。説明しろ」
(3)「(上の2つに当てはまらないなら)信用できない」

流石に(1)を露骨に言う人も少なく、(2)と(3)で議論が進む。相手に信用されなければ仕方が無いので、(2)の理由付けになるものを探すのだが、所詮後付けの屁理屈な言い訳である。
本当に要素技術に新規性が無い時は、「そんなもの信じられない。例え本当であっても新しいものでは無いに決まっている」と投げられる。だから、必死になって「後付けの屁理屈な言い訳」を探す。

冗談ではなく、本当に上記のような事が、新規研究や開発の予算獲得の度に繰り返されるのだ。そして、やっと認められた「後付けの屁理屈な言い訳」も所詮後付け、論理性を欠いたモノ。後になって、大変な事になる場合も多い。

これらの考えの元になっている「当り前の要素技術の組合せでは、画期的なシステムを作れない」と言う思い込みを改めないと問題は解決しない。

前回の記事「システムエンジニアリング」にも書いたように

「単純なモノの組合せでも、その可能性は実質上無限にある」

なのである。

前回の記事では、その理由を囲碁や将棋の例を用いて、「千年を超る歴史を持つであろうに、名人達は常に新しい戦術を編み出し続ける。最新のコンピュータを用いても、解析はおろか、人間に勝つことすら不可能だ」と説明した。

この囲碁や将棋の例は、技術の場合に、とても良く当てはまる。

まず、第一に「単純なモノ＝当たり前の要素技術の組合せでも、新規性のあるモノは常に創造可能である」ことだ。
次に、第二に「現在の名人が新しい戦術を考え出したからと言って、その戦術を思い付かなかった過去の名人達が馬鹿だとは言えない」ことだ。「当たり前の要素技術の組合せでも、新規性のあるモノで新しい組合せを作ったからと言って、過去の研究者・技術者が馬鹿だとは言えない」のである。

そして、第三に「最新のコンピュータを用いても、人間に勝つことすら不可能だ」である。この事は技術にも当てはまる。例え当たり前の要素技術の組合せでも「最新のコンピュータを用いても、人間より良い組合せを見つけることは不可能だ」。少なくとも現在のコンピュータでは無理だし、ここ数年ではあり得ないだろう。私の予想では、20年は難しいと思う。

現状では、人間こそベストの組合せを得られる唯一の存在だが、一人で考えるより二人の方が良いアイデアが浮かぶ。「三人よれば文殊の知恵」とは言ったもので、二人より三人が良い。私の経験では、５人から７人がベストで、上限は１２人だ。それ以上だとまとまらない。
このメンバーが一堂に会して、ワイワイと議論しアイデアを出し合うのは生産的で楽しい。要は「ブレーンストーミング」である。

「ブレーンストーミング」をやる時、重要なのは「場所」と「ホワイトボード」だ。一同が介して、リラックスし自由に議論できる「場所」が必要だ。その場所に「ホワイトボード」を３から５枚、置いておくと議論の活性化に役に立つ。

最近では、ブレーンストーミングの席にコンピュータや液晶プロジェクターを持ち込んで、即興で解析し結果をプロジェクターに表示をしながら議論を進める「コンカレント・エンジニアリング」と言う手法もある。「ブレーンストーミング」の場合、議論は定性的に成りがちだが、コンピュータで解析すれば、定量的な議論になる。コンピュータで単独で新しい組合せを見つけることは不可能だが、解析ツールとしては有効だ。
（注意：「コンカレント・エンジニアリング」の本来の意味は「コンピュータを持ち込んだブレーンストーミング」ではなく、「統合的なシステム検討と要素技術的な検討を同時に進める」と言う設計／検討の思想・方法論である。）

さて、長々と「当たり前の要素技術の組合せでも、新規性のあるモノは常に創造可能である」ことを説明した。

しかし、「それじゃ、当たり前の要素技術の組合せじゃ、所詮、その技術の限界を超られないだろう。本当に画期的な新規システムは、いつまで経っても生まれないじゃないか！！」と言う反論が聞こえて来そうだ。

言い換えれば「スペースシャトルやH-IIAロケットと言った今ある技術を幾らいじったところで恒星間飛行はできないだろう！」と言う意見だ。

もちろん、そうだ。
しかし、闇雲に「要素技術の開発」を進めれば良いと言うものではない。やはり「システム・エンジニアリング」の考え方が必要になる。

この事については、また次の機会に書き込む。

システム・エンジニアリング

囲碁や将棋のルールって、意外と単純だ。
将棋の場合、駒の種類や動き方も、そんなに多くない。囲碁に至っては、白と黒の石しかないし、動くこともできない。ただ、相手の石を囲んだら取ることができる、それだけのルールだ。

ルールが簡単だからと言って、囲碁や将棋がゲームとして単純だと思ったら大間違い。奥の深いゲームで、もう千年を超える歴史を持つであろうに、いまだに新しい定石や戦術が生み出され続けて居る。
単純なルールなのに、その組合せは天文学的な数になり、実質上無限にあると言っても過言ではない。だから、囲碁や将棋の名人達は常に新しい戦術を、その中に見つけることができる。最新のコンピュータをもっても、囲碁や将棋の全てを解析することどころか、人間に勝つことすら、まだ何十年も不可能だろう。

ブロック型の玩具も、そうだ。囲碁や将棋ほどの歴史は無いが、単純な形状のブロックの組合せは、やはり無限だ。

「単純なモノの組合せでも、その可能性は実質上無限にある」
まずは、これを理解して欲しい。

「当り前じゃないか！？」と思った人も多いだろう。しかし、この当り前のことが、「技術」に対して理解して居ない人が、日本人には余りにも多い。

技術的なモノ、例えば「自動車」の場合、「駒」に当たるのは「エンジン」「タイヤ」「サスペンション」などの部品、「自動車」自体が「ゲームとしての囲碁や将棋」だ。

新しい「自動車」のモデルが発表された時、常に話題になるのが、「最高馬力のエンジン」とか「新方式のサスペンション」を「採用したかして無いか」ではないだろうか？
それどころか、「当り前のエンジン」と「当り前のサスペンション」の組合せでは「新しい自動車と呼べない」とすら、思っては居ないだろうか？

「当り前のエンジン」と「当り前のサスペンション」の組合せだって、数限り無くある。その中に「画期的に新しい自動車」もあるはずだ。
それなのに、何故「エンジン」や「サスペンション」と言った「部分」にのみ注目するのか？

「囲碁や将棋」に例えるなら、「エンジン」や「サスペンション」を変えることは、「石や駒のルールや動き」を変えることと同じだ。「絶対に取られない石」とか「盤の何処にでも飛べる駒」を作っても、「ゲームとしての囲碁や将棋」が良くなるとは思えない。むしろ、ぶち壊しになる可能性の方が大きいだろう。

「エンジン」や「サスペンション」のように、「石や駒」に当たる部分を「要素技術」と言うのだが、明らかに日本は「要素技術偏重」だ。
「ゲームとしての囲碁や将棋」に当たる部分を「システム」と言い、これを如何に良く開発するかを扱うのが「システム・エンジニアリング」である。
日本で「システム・エンジニア」と言うと、「コンピュータやソフトウエアのメンテ屋さん」と言うイメージがあるが、そうではない。

「当り前の要素技術の組合せ」で「画期的なシステムを作る」と言う考え方は、「システム・エンジニア」の中の「システム・アーキテクチャー設計」と言う分野に当たる。

「画期的なシステム」が「当り前の要素技術の組合せ」で作れるなら、それで良い。無理に「新しい要素技術を開発」する必要など全く無い。「当り前の要素技術の組合せ」を熟考した末、どうしても足りない部分だけを取り出し、そこを「新しい要素技術の開発」すれば良い。

この話をすると、多くの人は「そんな古い技術の組合せばかり考えて居ても、当り前の事しかできないだろう。つまらない。面白くない。行き詰まりだ。」と言う印象を口にする。

私は全く逆で、「恒星間宇宙船の開発と言った飛躍的な進歩には、システム・アーキテクチャー設計以外の解決方法は無い」とすら思って居る。

さて、このギャップは、どうしたものだろう。

この説明をすると、もっともっと文章が長くなりそうだ。いずれ、この場で説明すると思うが、時間もかかるので、順を追って、徐々に書き込んでいきたいと思う。