面白いことを発見してそれを面白がる

自律分散は生命のモデル、そしてオーケストレーション

公式ブログには、やっぱりあまり好き勝手なことは書けない。非公式とはいえ、できる限りの客観性を持たせたいと思う。

しかしこちらには好きなことを書いてしまおう。「自律分散が好きだ！」

最近のネットワーク設計の現場では、SDN潮流の一環として、集中制御への見直しが起こっている。確かに、これまでは分散制御が少し行き過ぎて、そのためのControl Planeが複雑化しつつあった、ということは事実だ。また、可視化や自動化のためには、集中的な観測や制御が必要である。私自身が設計する場合も、必要なところ、可能なところには、集中制御的な要素を取り入れる場合が多くなるだろう。

でも基本的には自律分散が好きだ。なぜなら、それは生命のモデルだから。成長、進化、堅牢、存続の基礎になるモデルだから。

 我々が熱いものに触ったとき、脳が熱いと判断して、手を引っ込めるのではない。手を引っ込めるのが先であり、脳はそれを後追いで認知しているだけである。生物においては、そうやって、それぞれの部分がかなり自律的に動作している。脳が後追いなのは、このような単純な反応だけではない。高度な脳機能と考えられる「意識」でさえも、脳が能動的につくりだしているものではないという説がある。脳は、各所での自律判断を総合して、整合性を取るために、あたかも自ら意識しているように認識しているに過ぎない。（この辺は、ベンジャミン・リベット「マインド・タイム」[1] 、ダニエル・デネットの「解明される意識」[2]、そして我らが前野隆司先生の「受動意識仮説」[3]に詳しい。 

このモデルは、社会や組織のあり方にも通じる。

少し前だが、TVで、宅配ピザのフランチャイズ店がどのように品質を確保するかを取り上げていた。急速に成長するフランチャイズ。人材確保もバイトなどに頼らざるを得ない。そのような中、ピザという商品をすばやくおいしく提供できなければ、お客は離れてしまう。 

A社の戦略はこうだ。情報技術を駆使し、全店舗に遠隔カメラと通信手段を設置する。そして調理開始から提供までを、センターから細かく監視し、必要に応じてリアルタイムで指示をする。

それに対し、B社は、バイトも含む社員に、徹底的に教育を施すという。具体的なピザのつくり方は勿論、おいしいピザとは何か、お客様を満足させるとはどういうことか、について。

まだどちらのピザも食べたことが無いのだけれど、B社のやりかたの方が圧倒的に好きだ。必要な教育、方向付けを行った上で、その時々の判断は、各人に任せる。

先日の「DJポリス」の話もそうだ。普通だったら「立ち止まらないで下さい」、「押し合わないで下さい」とか言うところであろう。それを、「みなさんは12人目の選手です。チームワークをお願いします」と呼びかけたのだから、揮っている。一方的に命令するのでなく、各人の自律性と良識を呼び覚ます。

オーケストラの指揮も然りである。良い指揮者は、「ここは（音量を）小さく」とか「大きく」とかはあまり言わない。どこを目指すのか、どこを音楽的高揚の頂点とし、どのようにそこに到達するか、といったポイントを、演奏者と共有する。具体的な奏法は各演奏者の感性に託されることにより、演奏者は生き生きと演奏できる。

「生命や組織のモデルは技術システムのモデルとは異なる」、という指摘もあるだろう。尤もな指摘であり、私も、この点に関して十分な説明ができていない。しかし、ネットワークシステムに関して言うと、システム間の接続、システム外部との接続が必要であり、そのため不確定性が高い、ということは言える。そして、不確定性が高いシステムには、多様性や自己組織化といった生命モデルがよく適応できる。

 

ところで、最近SDNの文脈で、「コントローラ」とか「オーケストレーション」という言葉がよく使われる。使い分けている場合もあれば、混然と同義のように使われる場合もある。私としては、本来の意味合いを踏襲し、「オーケストレーション」は構成要素の自律性を尊重した方法、「コントロール」は構成要素を統制する方法、と使い分けるべきではないかと思っている。

 

[1] 「解明される意識」、ダニエル・C・デネット、青土社 (1997)

[2] 「マインドタイム 脳と意識の時間」、ベンジャミン・リベット、岩波書店(2005)

[3] 「脳はなぜ「心」を作ったのかー「私」の謎を解く受動意識仮説」、前野隆司、筑摩書房(2004)

「アーキテクティング」が私の生涯のテーマである、ということに気づく

 

最近、所属する組織が「公式ブログ」なるものを始めて、書いてみないかと言われた。「公式ブログ」とはいえ、書く内容はあくまでも「非公式」な個人見解であり、所属組織の見解とは一切関係ない、という注意書き付きである。（一体どこが公式?!）しかしこのパラドキシカルな感じが気に入ったので、引き受けてみることにした。

しかし、そうすると２つの問題が発生する。まず「何を書くか」。次に「このBlogをどうするか」。

「何を書くか」についてはしばらく悩んだ。悩んだ末に、私の興味は一貫として「アーキテクティング」にある、ということに気づかされた。

 これまであまり意識してこなかったが、振り返ってみれば「アーキテクチャ的に考えること」が、私の成長の源泉になっていたと思う。学業でも、音楽の修行でも、仕事（プログラマ→SE→スーパーエンジニア(?!)を目指し中）の場でも、人間としても。母校の大学院（Keio - Systems Design Management研究科）の門を叩いたのも、この興味による。

「アーキテクチャ的に考える」とは、簡単に言ってしまうと、その対象を構成している要素だけでなく、要素同士および要素と環境との相互作用・ダイナミクス、つながり方も併せて捉えることである。「メタ思考」とか「システム思考」とか言う言葉にも近いかもしれないけれど、より具体的な構造設計にも応用できる点が異なる。

 「アーキテクチャ的に考える」ことは、しかしながら、良いことばかりではない。一つのことを徹底的に掘り下げたり、追究することには向いていない。だからアカデミックな研究には向いていないと思う。あくまでも深く追究しないといけないときに、ついつい相補概念や相反概念を持ち出して、掘り下げる勢いを打ち消してしまったり、「そもそも」今やっていることがどんな意味を持つか、ということに思いを馳せて、所詮一時凌ぎに過ぎない、とやる気をそいでしまったり。（ここには心底気をつけないといけない。人間の一生なんて束の間だし、現世のすべてのことは、言ってしまえば「一時凌ぎに過ぎない」。それでも、何かをすることに意味はある。）

 そのため、過度な相対化や行き過ぎたメタ化には常に注意しなければならないが、そこにさえ気をつけておけば、これは強力な思考のフレームワークである。仕事は勿論、子育て、人間関係、組織や音楽といった、あらゆる対象に応用可能で、さまざまな局面を統合する方法にもなりうる。このBlogも、仕事・家庭・音楽のことを分けずに書いて来たが、「アーキテクティング」という観点により統合可能だったのだ、と改めて思う。

という訳で、「公式ブログ」の方には、「アーキテクティング」話題の中でも仕事に直結する「ネットワークアーキテクチャ」について書いて行こうと思っている。

こちらのBlogは、もともと更新頻度も少ないのですが、その他の、音楽や社会や生活に関わるアーキテクティング話題や、「公式ブログ」には書ききれなかった技術ネタを書くつもりです。今後ともどうぞよろしくお願いします。

Design Pattern BoF @ Janog31 !

 

　整然と区画整理され舗装された新興住宅地などの道路を歩くよりも、例えば山林などで、もともと設計された訳でもないのに、皆が皆そこを歩くものだから自然に地均しされた、というような道を歩く方がわくわくするのはなぜだろう。そういう道って、迷いそうな岐路には誰かが矢印をつけておいてくれたり、見晴らしのよいところには、「ここで休憩するといいよ」とばかりベンチが置かれたりして、何だか温かい気持ちになる。思わず、行き交う人が微笑んだり声をかけたりして、人々が生き生きとする。

------

　我々が何かを設計しようとするとき、基本的には、目的と境界条件を定め、その目的のために手段を最適化するように計画し管理する。しかしネットワークの場合、設計思想や振る舞いの違うシステム同士をつなげるため、予測しないことが起こり易い。ましてやインターネット。多様な自律組織の集合体であり、境界条件など設定することができない。特定の組織がネットワーク全体を制御したり計画管理するようなことはしない。だから明日何が起こるかわからないし、IPv6化などは未だに困難を極めているし、セキュリティ脅威や経路の問題は常に起こっている。そもそも、国際紛争や経済危機、地球温暖化や核問題など、世界中に多くの問題がある中、これだけ地球規模のシステムが動いていること自体が奇跡的のようにも思える。それでも地球は回っている。インターネットは動いている。

　アーキテクチャ設計手法としては、ZachmanのフレームワークやDoDAF, MoDAF(*), IEEE1220, ISO15288など世の中にたくさんあるけれども、どれもインターネットに適用することはできない。アーキテクチャを設計するためには、まずはシステムの範囲を定め、目的と要件を定義するところが出発点になるためである。

　(*) MoDAFは、DoDAFのOperational View, System View, Technical Viewの3つのViewpointに加え、Acquisition View, Strategic Viewを加えているので、システムの範囲は外に開かれている、と言えるかもしれない。しかし、その判断を行う設計者がいる、という点で、インターネットにはそぐわない。

　ではインターネットに関することについては、我々は為す術無く、起こる問題に場当たり的に対処するしかないのだろうか。そんなときに出会ったのが"The Art of System Architecting"[1]であり、そこに参照されていた"Pattern Language"[2][3]だった。

　「これらのパターンは、決して一度に全部を「設計」したり「建設」することはできない。だが、１つ１つの行為の積み重ねが、常にこれらの包括的なパターンの創造や生成につながるようにすれば、息の長い漸進的な成長により、これらのパターンを備えたコミュニティが、何年もかかって、徐々に、しかも確実に生まれてくるであろう。」[2]

　このパターンの記述を、Janogがやったらすごいのではないか、と思った。でも、プログラム応募してみても、私の説明能力、表現能力も低く、こんな抽象的な提案が通る筈も無い。それでも一度、2010年のJanog26のLightening Talk枠で発表させて戴いたこともあった。また、IA研ワークショップでは、設計原理の一つに「集合知」を加えることを主旨とした論文も出した。しかし一部の個人が何をしようがしまいが、そもそもJanogというコミュニティは、自然に知を共有したり、共に何かを創造するコミュニティである。別にパターン記述にこだわる必要もないのだろう、という気持ちになっていた。（実際、私の興味はコミュニティにおける知の生成であり、パターン記述方法自体にこだわりがある訳ではない。）

　そのような中、ささけんさんが、半ばむりやり、半ば強引にBoFを企画して下さった。えええ?!!、参加者の方の注意を惹くプロジェクタもなく、本会議終了後のわさわさとした会場で、こんな議論できるでしょうか。無理でしょう。と思った。しかしびっくり。けんさんのモデレーションも素晴らしく、参加して下さった方のご意見も一つ一つ大変貴重なもので、さらにポストイットを使ったクイックワークショップまでできた。素晴らしく内容の濃いものだった（事後資料）。けんさん、運営委員のみなさま、そして集まって下さった皆様、ありがとうございます！！

　やっぱりインターネットって愉しい。Janogというコミュニティはすばらしい。ここはやはりAlexanderが「学習のネットワーク(Network of Learning)というパターンで述べていることを引用したい[2]。

「教えることを重視する社会では、子供や学生ーまた大人でさえーが受動的になり、自分で考えたり行動できなくなる。教えることではなく、学ぶことを重視する社会になってはじめて、創造的で活動的な個人が育つ。」

　創造的で活動的な、生き生きとした人々とそのコミュニティ。技術者が共に学ぶ。迷いそうな岐路には矢印をつけておいたり、危険な場所があればそこにマーキングしたり、景色のよいところにはさりげなくベンチを置いたり、そんな活動ができたらいいな。

　これからどのように進むか。全くわからないけれども、何かあったら、ハッシュタグ #janog_dp でtweetしてみて下さい。そういえばtwitterは、bottom up活動を可能にするメディアですね。電子Post Itみたいに使ってみよう。Brain Stormingの鉄則どおり、「どんなことでもよい」「自由奔放に発想する」「批判をしない」「質よりも量」で行きましょう。

[1] "Art of System Engineering", Mark W.Maier, CRC Press
[2] 「パタン・ランゲージー環境設計の手引き」、C.アレグザンダー、鹿島出版会
[3] 「時を超えた建設の道」、C.アレグザンダー、鹿島出版会
　
　

原典版か編曲版か ーおまけ

　前エントリーのおまけ。版の選択はもう少しゆっくり考えることにするが、この際、カデンツァにちょっといたずらをしてしまおうかな。

　今年は巳年なので、巳年ヴァージョン！！（日本人にしか通じないですね。いや、日本人でも気付かないかな..。アホですね。失礼しました！）

アーキテクチャ的転回 ー 対立でなく、「いいとこ取り」でもなく (2)

　前のエントリーで、「対立でもなく、「いいとこ取り」でもない、第三の調停手法が、これからのアーキテクティング手法の一つの重要な要素になると思う。」と書いた。

　対立概念を調停する方法としては、まずは、つなひきのように両者のバランスや配分を探る方法、そして弁証法における正反合（二つの判断・立場を統合してより高い判断に至る）のようなものが考えられる。「いいとこ取り」というのは、ちょっと安易な感じを否めないものの、実現可能であれば、正反合の「合」に至るアウフヘーベンの一つと捉えられる。

　しかしこれらは、二元論的な捉え方を出発点としているという点で、予め何らかの制約を課してしまっているのはないだろうか。

　そこで、まず考えたのが、そもそもその二項対立に至る背景（権力、流行などによる構造）を発見し、それを脱構築することにより、新たな地平を拓く可能性である。（自分でも忘れていた程昔の話だが、この初期段階の考えは、2004年のInterOpにおけるJanog Special Sessionで発表させて戴いていた..。）

　そして気づいたのは、二項が対立し、その両者には多大なる齟齬があるにも関わらず、二元論には還元すべきでない（またはできない）関係の存在である。例えば、心と身体、（光における）波と粒子、利他と利己、マクロとミクロ、など。拮抗したり、矛盾したり、決して同時には観測し得なかったりするのに、確かにそこにある、といったもの。物理学者ニールス・ボーアの言うところの「相補性」にも通じるかもしれない。

　郡司ペギオ幸夫は、砂山のパラドクスを例に取り、このような関係に「内包（概念を全体として規定する属性）と外延（概念の具体的事例・対象）が同値でないことによるパラドクス」を見出し、「内包・外延の動的双対性」をモデル化する研究を行っている。郡司は「内包と外延の齟齬それ自体が両者を媒介し、その脆弱な境界をもってシステムを維持する」と言う。

　SDN文脈におけるアーキテクチャ議論の一つである、「集中か分散か」は、まさに、この「二元論に還元すべきではない関係」に相当すると思う。あるシステムにおいて、内包＝システム全体を規定する何か（理念とか、アルゴリズムとか）、外延＝システムを構成する要素、とすると、「集中か分散か」は、そのシステムを全体を規定する何かが、専ら中央に集中しているか、各構成要素にもそれが存在するか、という議論になる。ここには対立も正反合もない。例えば、生物システムや組織などを考えると顕著である。一見大脳が集中制御しているように思える人間も、実は各神経がかなり自律的に作用しているし、優れた組織では、社長や役員だけでなく、組織を構成するメンバー一人一人が理念や文化を共有する。このように、動きを持つシステムに、内包か外延か、という問いは無意味である。それなのに二元論的に捉えるから、「集中がよいか分散がよいか」、「トップダウンとボトムアップ、どちらが優れているか」という議論が、時代を経て何度も繰り返されることになるのはないか。

　郡司の言う「動的双対性」は難解だが、共感する部分が多い。私の考えるアーキテクティング手法と接続させ、検証してみたいと考えている。

原典版か編曲版か

　チャイコフスキーの「ロココの主題による変奏曲(Op.33)」を弾く（かもしれない）ことになったが、悩ましい問題が一つある。版の問題だ。

　どんな曲を弾く場合も、アーキテキュレーションの考え方一つとっても大分曲想が変わるため、版の選択は問題になる。でもこの曲の場合はアーティキュレーション云々の問題をはるかに越えている。チャイコフスキーがこの曲を捧げた親友でありチェリストであるフィッツェンハーゲンが、変奏の曲順を大幅に変更し、かつ終曲をカットし、コーダを書き替える、という大改造を行ったというのだ。（この辺は、Wikipediaに詳しく書かれている。）

　当時出版社がその編曲版を出版したために、長らくこちらの版が標準版になっていた。ロストロポービッチ、ヨーヨーマなどの名演奏もこの版によるものである。これはこれで素晴らしい。物寂しげでどこか懐かしいmoll（短調）のヴァリエーションを後半に持って来て、その後一気に盛り上がってコーダを迎える。チェロを輝かしく聴かせるという演奏効果を考えても、若干冗長な感じをスリムにしているところも、編曲版はよくできているように感じる。いや、こちらの方が聴き覚えがあるため、親しみがあるだけなのかもしれない。

　この曲を課題曲としているチャイコフスキーコンクールでは、第12回（2002年）から原典版を指定しているそうだから、これから勉強する若いチェリストは、原典版をさらうのだろう。やはり、作曲者の意図を忠実に再現するためには、原典版を選ぶべきだろうか。スティーヴン・イッサーリスは、結構強く、「編曲版はナンセンスでり、冒涜(sacrilege)」とまで言っている。

　一方、実際の演奏会では、最近でもフィッツェンハーゲン版が演奏される機会もまだ多いようだ。昨年来日もしたタチアナ・ヴァリシエヴァの演奏もフィッツェンハーゲン版だ。その他もいろいろ検索したが、編曲版での演奏の方が多い様子である。確かに、作曲家の意図が一番であるが、演奏者にとっては演奏効果も重要な問題である。例えば、ショパンの「序奏と華麗なるポロネーズ(Op.3)」をオリジナル版で弾く人はあまりいない。オリジナル版ではピアノの輝かしさに対してチェロはオブリガード的であり、腕に覚えのあるチェリストにはそれでは物足りないため、演奏会では、フォイアマン版、ジャンドロン版などが取り上げられる。（私はこれらは弾けませんけれども。）

　さて、原曲版か、編曲版か。私の廻りには結構原典主義の人も多いのだが、極端な原典主義はどうしても疑問に感じてしまう。原典版にだってどのみち記譜ミス、写譜ミスはあり得る。作曲者の意図が完全に譜面に表れているか、と言えば、そうではないこともある。また、優れた演奏家が曲を深く研究して校訂したことを、そんなに無碍に否定する必要も無いだろう、という気もする。勿論、校訂はあくまでも、ある第三者によるある前提に基づいた解釈に過ぎないので、それを過信するのは、当然よいことではない。要するに、絶対に正しいというものは無い。その場その場で判断するしかない。

　うーん、迷う。両方弾けるようにすればよいのだろうが、ソロ曲なので暗譜しなくてはならない。複数の版が頭にあったら絶対混乱するから、やはり早いうちの選択が必要である。

　まぁでも一番の問題は、この難曲を手の内に入れられるか、ということなので、まずは基礎をきちんとさらうことに専念しよう。。。

アーキテクチャ的転回 ー 対立でなく、「いいとこ取り」でもなく

　今年のネットワーク領域に起こったことを総括すると、やはりSDNというものに翻弄された年、と言えるだろう。

　翻弄された、というのは受け身的で情けない感じもするが、実感をありのままに書くとそうなる。SDNはこれまでのネットワークの担い手とは別のコミュニティから発せられた様々な問いから端を発しているからだ。「コマンド設定？何それ？」「ネットワーク開通？何それ？何でそんなに時間がかかるの？」「何でプログラムから呼べないの？」「機器ヴェンダへの依存度がこんなに高くていいの？」「コンピュータプログラムは抽象化により進化してきたのに、ネットワークって全然抽象化が進んでいないのでは？」…

　これらの問いにはナイーヴなものもあるし、若干誤解もあるが、そのように捉えられる様態になっていたのは事実である。そして、この問いを受けて立つネットワーク業界や個々の関係者の反応も様々である。この反応の違いや時間的推移も興味深いが、概ね、この問いを歓迎し、これまでのネットワーク設計・運用のよい面、悪い面、そしてこれからのネットワークのあり方を再考する好機と捉えていると思う。私もその一人であり、アーキテクチャ的転回の機会を得た巡り合わせに感謝し、よいケーススタディを実践したいと考えている。

　このようなアーキテクチャ的転回は、過去にも大小合わせて何回か起こっている。Mainframe Computing -> Client/Server -> Web2.0, p2p, Grid -> Cloud Computing..。インフラに絞ってみても、電話主体のアクセス網-> IP NGNという転回があった。前者の転回は、ほぼ、直前のアーキテクチャに対する対立・アンチテーゼという形を取るが、後者の、電話からNGNへという転回は、よく「いいとこ取り」という言い方をされた。iP NGNは、信頼性、計画性などといった電話網のよいところと、柔軟性、オープン性などのIPのよいところの、両者を併せ持つネットワークを目指した、と言う。

　これまでのアーキテクチャ的転回と同様、SDNも、アーキテクチャ設計に関して、いくつかの対立軸で捉えることができる。

 

　A) 自律分散制御 ー B) 集中制御

　A) ハードウェア ー B) ソフトウェア

　A) 物理 ー B) 仮想

　…

　SDNは、これらA)-B)の対立軸で考えた場合、比較的、B)寄りの考え方がメインになる。しかし、現実のアーキテクチャ実践としては、A)を対立させ、排除する、というよりは、最善の共存方法を探る、ということになるだろう。スケール・堅牢性、適応性という点においては、自律分散がどうしても優れている。また、ハードウェアとソフトウェアは時と状況に応じた補完関係にあるに過ぎず、仮想といっても物理リソースあってのものだ、ということもわかっている。

　では、どのようにしたら、最善の共存ができるだろうか。

　私はここで、「いいとこ取り」というものに異を唱えたい。「いいとこ取り」って、確かに、目標やスローガンとしてはよいのかもしれないが、現実に実装可能どうかは相当疑わしい。ある方式を選択する、ということは、基本的にその方式の良い面も悪い面も採択することである。その上で、何らかの別の手段により、悪い面を緩和するしかない。対立する方法論のそれぞれ良いところだけ取るというのは、原理的に不可能に近く、ややもすれば、両者の良い点を打ち消し合うだけという、中途半端なものになってしまう可能性が高い。

　対立でもなく、「いいとこ取り」でもない、第三の調停手法が、これからのアーキテクティング手法の一つの重要な要素になると思う。それは何か。ちょっと長くなりそうなので、次回に書く。

　最後になりましたが、皆様、良いお年を！！

アーキテクチャ変遷の本質 - MPLS Japan SDN Panel Session - (2)

...その(1)からの続き。

本質を探る、なんてことは、そんなに簡単なことではないし、1時間ちょっとのパネルディスカッションで達成できる筈も無い。

しかし、パネリストに恵まれ（当時は東芝CSR開発・MPLS標準化でも活躍された、MPLS Japan実行委員長である永見さん、Nicira Japanの黎明期メンバーである進藤さん、NECでOpenflowの先導をされている岩田さん、StaratosphereをIIJ浅羽さんと立ち上げられた天才プログラマ石黒さん、そしてつねにInnovativeであるSoftbank松嶋さんという布陣）、会場からの活発なご意見もあり、いくつかのことを悟った。

勿論それは、今という一時点での、個人的単眼的な見方に過ぎないが、メモしておく。

• まず、プレーヤーが変わったということ。現在の主役は、データセンター技術者である。だから、SDNは、データセンター技術者による「ネットワークの再定義」と捉えることもできる。そしてその「ネットワークの再定義」は、まだ始まったばかりである。

• do not re-invent the wheelという言葉がある。同じような目的を達するために既に使える技術が存在するのであれば、それを使え、という鉄則である。しかし、プレーヤーが変わったので、ある程度の調停期間が必要だろう。例えば、vlan spaceを拡張しながらl2 over l3 tunnelを実現する、というときに、STT, VXLANなどの他に、PBB+EVPN、SPBM、LISPなどの、多くの技術およびその組合わせが考えられる。また、別にL2にこだわらず、L3-L4もしくはそれ以上のオーヴァレイがあってもよい。今後、どこがTunnelの起点終点になるか、Networkへの要件は何か、などの詳細議論の中から、いくつかの方式に収斂して行くと思う。

• MPLS黎明期に、多くの技術が出現しては消滅して行った。今回のSDNの場合も、何かが消え何かが残るだろう。類似性を対比させたり、そこから学んだりすることは有用である。但し、あの時こうだったから今回もこうなる、というような予測はできない。勿論、共通点もあるだろう。しかしプレーヤーも違う。環境も違う。

• 集中制御か分散制御か、ソフトウェアかハードウェアか、垂直統合か水平統合か、といったアーキテクチャ議論は、重要であるが、ひとまず本質ではない。SDNは、どちらかというと集中寄り、ソフトウェアっぽい(by 進藤)、垂直統合寄り、であるが、これらの按配は、SDNにせよそうでないにせよ、そのときの技術条件や環境条件により、常に変動する。（但し、自律分散との按分に関して、現時点では、十分な考慮がなされているとは言えない。まだまだやることがある。）

• プレーヤーが違えば常識も違う。例えば、データセンター技術者に取ってはプログラムを書いて自動運用することは「当たり前」であり、「ネットワーク開通」のために、業務が待たされるなんてことは、「ありえない」。また、語彙も違う。ネットワーク技術者が「オープン」と言う時は、「オープンプロトコル」「オープンスタンダード」「相互接続性」などを指すが、データセンター技術者にとっての「オープン」は、「オープンソース」「オープンAPI」だったりする。特に、「オープンソース」はビジネスモデルまでも包含する語彙である。とにかく、言葉一つとっても、そのままでは会話が成立しない可能性が高い。相互理解、そして融合が必要。

私はあまり瞬発力がある方でなく、パネルの進行のときは、これらの気付きを上手く言語化できていなかった。しかし、今後やるべきことが少し見えて来た気がする。超ご多忙の中パネルに快くご参加下さったパネリストの皆様に、そして会場からコメントくださった方、そして実行委員の皆様に、感謝したい。ありがとうございます。

 

P.S.

ところで、このパネルがいけなかったのか、MPLS JapanでのSDN関連プログラムを、「おじさんのおじさんによるおじさんのためのSDN」とtweetしてくれた方がいた。15年前のMPLS黎明期の話なんて持ち出してしまって、申し訳なかった！でも、歳はあまり関係なく、重要なのは謙虚に学ぶこと、そして革新することとだと思う。謙虚に学ぶことを忘れて、単に自分の身につけて来た知識と経験に基づき偉そうにしているおじさん（おばさん）には、絶対に、なりたくない。

でも若者は血気盛んの方がいいよね。私もプログラマ時代に、頭の固い大人は信用できず、「don't trust over 30」などと、息巻いていたことを思い出しました。

アーキテクチャ変遷の本質 - MPLS Japan SDN Panel Session - (1)

 

今年のMPLS Japan 2012は、MPLSの名が冠されるカンファレンスであるにかかわらず、テーマの大半がSDN関連であり、やはりSDN熱が高いことを実感させられた。私はプログラム最後のパネルセッション "MPLS meets SDN -- よくある歴史の繰り返しか、新たなアーキテクチャ可能性か"を担当することになった。

MPLSは今ではかなり成熟した技術に入り、私は既にこのカンファレンスの実行委員を退いているが、しかし今年は、このMPLS Japanというカンファレンスで、どうしてもやっておきたいことがあった。それは、「アーキテクチャ変遷の本質を探る」、ということである。

現在の、このSDNへの市場の過熱ぶりは、ちょうど15年くらい前のMPLSが出始めたときの過熱ぶりによく似ている。1990年代半ば、インターネットの商用普及に伴い、IPトラフィックが急速に増大した。当時は可変長パケットをハードウェアでは処理できなかったため、固定長セル交換であるATMが高速化の鍵と見られていた。しかし、ATMはConnection Oriented型の通信方式であるため、Connection Less型のIPとはそのままでは融和しない。そこで、多くの新たな技術が提案された。LAN Emulation(ATM Forum)、Ipsilon(その後Nokiaに買収される) IP Switch、東芝CSR、IBM Aris、3Com(その後HP) Fast-IP、Cascade(その後Lucent) IP Navigator…、そしてCisco Tag Switching。

IPをConnection Oriented方式のATMに融和させるために、殆どの技術は"flow"に着目した。（IPはDatagram/Connection-Lessであるが、flowはConnection Orientedある。）しかし、flowではステートが細かいため、スケール上の懸念があった。そこで、トポロジーによるflowの多重を提唱したTag Swithchingが市場の賛同を得、Tag SwitchingをMPLS(Multi Protocol Label Switching)という名称で標準化することになり、1997年にIETFにおいてMPLS WGが発足した。市場は、新たな通信方式の可能性に沸き立っていた。

しかし、間もなく可変長パケットもASICで高速処理できるようになり、高速転送技術としてのATMの必要性は無くなった。そのためATMとの融合のための技術としての、MPLSの必要性も無くなった。しかし、MPLSではTunnel/Overlay・VRF（仮想ルーティングインスタンス）などのネットワーク仮想化、Traffic Engineeringを実現したため、L2/L3 VPN提供技術やバックボーン仮想化技術として普及し、現在に至る。

SDNは、IPに捉われないアーキテクチャを一から考える(clean slate)プロジェクトであるGENIに端を発している。そこでまず提唱された技術が、Control PlaneとData Planeを分離し、Data Planeを、高速で安価なCommodity Switchに処理させるというOpenflowであるが、これはLAN Emulation, Ipsilon…などのアーキテクチャに結構似ている。Commodity SwitchをATM Switchに置き換えれば、殆どdeja-vuな感じがする。その他にも、Openflowの"Reactive vs Proactive"議論は、MPLSの"flow driven vs topology driven"に似ているし、また、Nicira CTOのMartin Casadoも、MPLSが既に実現したこと（具体的には、コアとエッジの機能分解、ラベルによるend-hostアドレスのコアからの分離、明示的なpath setup)に学ぶべき、というような主旨の論文(http://yuba.stanford.edu/~casado/fabric.pdf) を書いている。

また、プログラマビリティ、集中制御の要求は、SDN以前にも脈々と存在していた。古くはIN(Intelligent Network)、最近でもMegaco, Soap, Parlay-xなどによるApplication Aware/Policy Aware Control。SDNが可能にする技術それぞれは、別に新しい物ではない。それどころか、あまり市場に受け入れられたとは言い難いものに近い感じがする。しかし、MPLSの時も、多くのhypeが起こり、多くの技術が忘れ去られたが、確かに、長く残った要素はある。

そこで、MPLSによるアーキテクチャ変遷とSDNを対比させることにより、現在の、SDNによるアーキテクチャ変遷の本質を探りたいと思ったのだ。

...その(2)に続く。

語り得ぬこと

　「語り得ぬものについては沈黙しなくてはならない。」これは前期ウィトゲンシュタイン^(*1)の、切ない、しかし真摯な論理的帰結である。

　

　言葉はあまりにも無力だ。例えば、感極まって、この気持ちを何とか伝えたい、という時に人間はどうするか。まず、絶句する。そして何とか口を開くと、「本当に」を連呼する。「本当にうれしいです。本当にみんなに感謝したい気持ちでいっぱいです。本当に、本当に、ありがとう。」これは自分でもそうだし、他の人もそうであることは観測的事実である。しかし冷静に考えると、「本当に」と言わないときの言葉は「本当」ではなかったのか、と突っ込まざるを得ない。「本当に」という言葉は、言葉全体への冒涜だ。「本当に」という言葉が存在していることが、言葉自体の信頼性を失墜させる。「正直なところ」とか、「まじ」とかも同罪。

　

　言葉はものごとを正しく伝えられない。正しく伝えられる手段は、厳密には数式だけだ。図表などの情報や、音、発信者の目・態度、などは多少の助けにはなるが、完全とは言えない。言葉はあまりにも柔軟であるため、意図的かそうでないかに関わらず、うそ、誇張、誤前提、ごまかし、間違い、勘違い…などが入り込む余地を排除できない。さらに、仮に、発信者側でこれらを全てを排除できたとしても、今度は受信者側の問題がある。受信者が受け取るときに誤解、曲解が入り込む余地は、常にある。こう考えると、もう絶望的と言わざるを得ない。^(*2)

　

　それでも、私たちは言葉を使ってしか、ものごとを伝えることができない。だから私はできるだけ真摯に言葉を使いたいと思っている。

　

　まず、なるべく「本当に」という言葉を使わない。あまりにも慣用句になってしまっているので、口をついて出てしまうこともあるが、メールなど書き言葉では、うっかり書いてしまった場合は消す。「本当に」だけでなく、「とても」とかいう強調のための言葉も不用意に使わないようにしなくてはならない。このような強調語は、強調しないときはそれほどでもないということになり、結果としてその言葉の価値を落とすことになるため。

　

　それから、「○○は□□だ。」と述べるときは、できるだけその前提条件・境界条件を示すようにする。当然といえば当然なのだが（特に論文や公的なプレゼンの場などでは）、実際にやろうとすると、これがまた難しい。何せ会話の場合は反射性やスピードが要求される。いちいち前提条件・境界条件を述べてたら、まどろっこしくて仕方ないし、相手にとっても迷惑だろう。それで最近多用する（ようになってしまった）のが「スキ」とか「キライ」とかいう言葉である。「これは良い」とか「あれは間違っている」とか言う代わりに、「これ結構好き」とか「あれはあまりスキじゃない」と言う。「これは良い」というためには、その背後にある前提と境界条件を列挙しなくてはならない。しかも、自分では当然で「言うまでもない」と思っていることが、かならずしも自分以外にとってはそうとは言えない。。。こんなことを考えると、「これは良い」などとはとても言えない。しかし、「これは好き」というのは、全く本人の勝手であるし、あくまでも主観的であるということを認めている、という点で、潔い。

　

　しかししかし、これではかなり変な人、というか、やなヤツだろうか。気づけば、「○○（適宜技術方式の名称を入れよ）は好きじゃないんだよねー。」とか「××（別の技術方式の名称を入れよ）は結構好きだ。」とか言っている。そのくせ、他の誰かが「○○は□□だ。」とか言うと、「え、"○○"ってどう定義してるの？」とか、「"□□"ってどういう前提？」などと突っ込む。これでは、前から私を知っている人だったらまだよいのかもしれないけれど（よくないか）、最近職場を変わったこともあり、多くの人から自己中でやなヤツと思われることだろう。

　

　あああ、ムズカしい！

　

^(*1) 後期ウィトゲンシュタインは、むしろ言語の生成的な側面に注目して行く。（「言語ゲーム」など）しかし前期ほどの明晰さはない。

　

^(*2) 逆に、むしろこれを利用する人達もいる。マーケットにおけるBuzz Wordはまさにそれである。What a "BDM" (Buzzword Driven Market) !!

　

もしかすると芸術家が一番すごい

神々しい、宇宙的、とでも形容するしか無いような音楽がある。

例えば、バッハのシャコンヌ、特にあの、突如D-durになった後の分散和音。モーツァルトのジュピター、シューベルトのピアノソナタ21番、ベートーヴェンのワルトシュタイン...。

そこには、人知を越え、さらには普遍性とかいうことさえも越えてしまうような何かがある。
人間ってすごい。世界は美しい。どんなにつらいことがあっても、これらの音楽があるだけで、この世に生を受けたことに感謝する気持ちになる。

地動説、万有引力、相対性理論など、いかなるすばらしい科学史上の功績も、ガリレオ、ニュートン、アインシュタインがこの世に生まれなかったとしても、きっと誰かが発見していただろう。しかし、シューベルトの音楽はシューベルトがいなかったら、存在しなかった。

だから、一人の人間が一生のうちになし得ること、という尺度で考えたら、芸術家が一番すごいのではないか。

で、何が言いたいか、というと、何でも市場原理に絡めとって芸術を消費の対象にする風潮はけしからん、ということでもなく（多少はあるかもしれないが）、保護してほしいということでもなく、どうせ生きるのならアーティスティックに生きよう、ということなんです。

アーティスティックに生きよう。

仮想化、特にネットワーク仮想化について

 

先日のエントリー「多様性のアーキテクティング」で、そのための中心的な方法論の一つとして「仮想化」をあげたが、そもそも仮想化とは何か、ということについて書いておかなくてはならない。

 

最近、コンピューティング領域での「仮想化」とは、「HypervisorやVMによるサーヴァの仮想化」を指すことが多いようである。しかし、それは仮想化のごく一部に過ぎない。

  

仮想化とは、レイヤ概念(layer of indirection)を設定し、下位のレイヤを上位レイヤが使いやすくするための抽象化を行うことである。だから、コンピュータもネットワークも、それら自体がまさに「仮想化」そのものである。「仮想化するかどうか」は問題ではない。問題は、どのように階層化モデルとレイヤを設定するか、抽象化のレヴェルと切り出し方の単位をどうするか、仮想化されたエンティティの割当と制御・管理をどうするか、などである。  

  

今、特にネットワーク領域における仮想化について、混乱があるかもしれないと思う。例えば、「ネットワーク仮想化企業」と称されるNicira社のNetwork Virtualization Platformでは、これまでのネットワークを「物理ネットワーク(Physical Network)」と位置づけ、それとは切り離した、論理的な仮想ネットワークを構成するという(*1)。

 

(*1)

http://www.datacentertalk.com/2012/02/nicira-network-virtualization-platform-decouples-physical-and-virtual-network-infrastructure/

  

しかし「物理ネットワーク」って一体何だ？「物理ネットワーク」なんてあり得ない！物理層だけでネットワークを構成するのでない限り、ネットワーク自体が仮想なのだ。例を挙げるまでもないが少し挙げるとLAG, multi-path, vlan,  overlay, tunnel, pseudo wire, logical interface, VPN, VRF, logical routing instance, multi-topology, map and encap....。Interface, Path, Topology, Nodeと言ったあらゆるネットワーク要素は既に仮想化されている。

  

現在の課題とされていることは、これらの仮想化要素を、いかに、オープンに、柔軟に、自由に、使えるようにするか、ということだろう。そしてそのための捉え方や要件は、誰が使うか(*2)によって異なる。

 

(*2) 

使うのはネットワーク運用者である。しかし、かつてネットワーク運用の目的は専らTransportやConnectivity提供であったが、今は、Contents Provider, Data Center/Cloud Provider (IaaS, PaaS, SaaS...), M2M provider, SNS, Game Providerなど、サーヴィス提供形態は様々であり、それに伴い、「ネットワーク運用」の意味も、ネットワーク運用者の属性も変わってきている。

  

「ネットワーク仮想化」と言うとき、そこに求められる本質は何か。それぞれの状況に応じた適切な抽象化の度合いや、切り出し方について、まだまだ議論する必要があると感じている。

 

Architecting the Diversity - 多様性のアーキテクティング

ここ暫くもやもやと考えていた「多様性のアーキテクティング」について、整理しておこうと思う。（最後に少しお知らせもあります...。）

1. 用語の定義
2. なぜ多様性が必要か
3. 多様性の問題点
4. 多様性のアーキテクティングとは

---------------------------------

1. 用語の定義

• 多様性：同様な目的を達成するための選択肢が複数存在する状態
• アーキテクティング：アーキテクチャ（システムや組織の構造）を設計すること

2. なぜ今多様性が必要か

• 現在我々を取り巻く環境は増々複雑多様化している。
• 現時点の顧客や主要マーケットの要望にしっかり対応し、競合の状況もよく分析し、新たな技術開発への投資も積極的に行っていても、想定外の"disruptive technology"が台頭してきたときに、対応できず失敗する。("The Innovator's Dilemma - When new technologies cause great firms to fail", Clayton M. Christensen) [*1]
• 多様性に打克つことができるのは多様性のみである。即ち、取り巻く環境が多様な場合、システムはそれ以上の多様性を内包している必要がある。(“Requisite variety and its implications for the control of complex systems”, W.R. Ashby)

3. 多様性の問題点

• 多様性が必要とはいえ、ただ只管多様化すればよいという訳ではない。
• 多様化により、必要なリソースとコストは増大する。リソース競合や不整合も起こる。
• 多様性の増大とは、即ちエントロピーの増大に他ならず（前述のW.R. Ashbyは、多様性を定義するにあたって、Shannonの「情報エントロピー」計算式を流用している）、必要以上に多様性が増大すると、複雑性も増大し、システムは破綻する。
• そのため、必要以上の多様性の増大を戒めるために、"Do not re-invent the wheel"ということわざもある。
• また、例えば人間組織の場合、同様な目的を持つ組織が複数存在すると、縄張り争いや足の引っ張り合いが起こる可能性もある。

4. 多様性のアーキテクティングとは

• システムが、できるだけシンプル・スケーラブルでありながら、必要な多様性を包含できるように、アーキテクチャ設計を行うこと
• 具体的な方法論としては、「仮想化(Virtualization)」と「適応的デザイン(Adaptive Design)」が中心となる。
• まず、限りのあるコストとリソースで多様性を実現するためには、それぞれの構成要素にリソースを占有させる訳にはいかない。リソースを仮想的かつダイナミックに割り当てる必要がある。
• また、仮想化とは「階層化して抽象化すること」であるから、機能を複数のレイヤに分割することにより、複雑性を縮減することができる。
• 必要以上の多様化を避けるため、随時状況を観測し、多様化のための「発散」が行き過ぎたら、「収束」に向かわせるような設計介入が必要であろう。「適応的デザイン」は、このために必要になる。
• レイヤの概念は、この「発散と収束のサイクル」の観点からも、有用性を発揮する可能性がある。各レイヤにおけるこのサイクルの位相が異なれば（＝あるレイヤが多様性を増大させていても、他のレイヤにおいて収束していれば）、全体としては破綻しない、ということが言えるかもしれない。 

 

[*1]　Cisco Systemsは、1999年にサンフランシスコで実施した通信事業者向けワークショップの記念品(?!)として、この本を参加者全員に配った。（私は当時主催者側であったが、余った本を貰って、今も大切に持っている。）このときは、当時の通信事業者の主流サーヴィスだった電話に対して、TCP/IPがdisruptive technologyであることを、この本に託して、メッセージアウトしたのだった。

あれから12年以上を経た今、今度は次のdisruptive technologyに備える局面を迎えている。Juniper NetworksのMike Beaselyは、先週のInterOp講演で、SDNをdisruptive technologyと見たて、"Accept the disruptive technology"と言った。SDNがどの程度"disruptive"であるか今はまだわからないし、disruptionはもっと上のレイヤで起こるような気もするが、いずれにせよ、disruptive technologyに対応するためには、多様性が必要であることは確かだ。

Juniper社は素晴らしい企業で今も大好きなのだが、一つのアジェンダを皆で一貫して、一枚岩的に実現しようとする機運がある。マーケットがある程度安定しているときは、その戦略が最大の効果を発揮するが、今のような転換期においては、多様性とダイナミズムに欠ける感じがしてならなかった。そこで、暫く悩んだ末、もう一度一からやり直すことにした。

 

...という訳で、6月26日から職場を変わり、新たな気持ちで頑張るつもりでおります。「多様性のアーキテクティング」をテーマに、様々なことに取り組んでみたいと思っています。Juniperにはいろいろな機会を与えて貰い、本当に感謝しています。職場が変わるとは言っても、一企業というよりは業界全体に貢献したいと本気で思っておりますので、今後ともどうぞ宜しくお願いいたします。

 

子育てネタが書きづらくなってきた

子育てネタが書きづらくなってきた。

ネタが尽きた訳ではない。二人のアホ娘ぶりにはさらに磨きがかかり、突っ込みどころ満載の生活を送っている。理屈をこねる力は立派なもので（人間は、まず論理的能力が専ら発達し、応用力や実践力がついてくるのはその後らしい）、私は「いいから早く寝なさい」などと、全く理論的でないことを口走る羽目になっている。

しかししかし。

Blogを始めた時に掲げた目標は、私の生活における３つの大きな柱である、仕事・音楽・子育てを、より高い次元で統合にしたいということだった。当時、テーマにより複数のBlogに分けるこが推奨されていたけれども、私はあえて一つのBlogにした。それぞれの大切な領域から得る知見を統合して、さらにそれを、各領域にフィードバックする、ということの繰り返しにより、人間として成長できるのではないかと思った。

実際は、生来の筆無精でなかなか筆は進まず、そんな大仰なことは達成できそうもないけれど、でも、子育てネタを書くのは、愛おしく、そしてとても愉しいことだった。

それなのに最近はどうも書きづらい。なぜか。

まずは何と言ってもプライヴァシーの問題。Blogは実名だし、SNSのように友達にだけに公開、という訳ではない。自分で書いたことは自分で責任を取る覚悟でいるが、子供は別人格である。そのプライヴァシーについては当然、親がどうこうできるものではない。

そしてもう一つの理由は、「ヤツら」もこのBlogを見ている可能性が高い、ということだ。勿論、面と向かってそんな話はしたことはないけれど、ディジタルネイティヴ世代の検索能力を舐めてはいけません。常日頃、「個人情報をネットに晒すな」、「（相手が特定できるメール等であっても）自分が完全に責任持てること以外は書くな」、と言っている手前、下手なことを書いたら全く示しがつかない。それに若干照れくさい。

子育てや家庭のことを通じて発見（再発見）することは多く、できればこれからも記録したいけれど、うーん、なかなか難しいなぁ。。。

 

 

SDNとネットワーク性能特性の関係

先週SantaClaraで開催されたOpen Networking Summitが大盛況だったこともあり，SDN (Software Defined Network), 即ちVirtualization, Programmability, Management (Orchestration)について再度考えている．（このBlogはその時々の思考を記述しておくために書いているが，自分の過去のエントリーは，恥ずかしいやら情けないやらで，あまり読み返す気がしない．しかし，状況が刻々と変わるとはいえ，ある程度意見に一貫性がなければ，技術者としての信頼性にもかかわる．そこで，数か月前の自分がこの件についてどう考えていたかを，仕方なく振り返った．前回の記事）

今の考えは，前回の記事から根本的に変わっていないけれど，集中管理か分散かの議論は，適用領域と捉え方を明確にしない限りは意味が無い（例えば自律分散システムの代表のようなルータであっても，Routing EngineがForwarding Engineの動作を決めている，という意味で，捉え方によっては集中システムである）し，そもそもちょっと斜に構えていて真の要望や意義を捉えきれていない，という意味で，やはり前回の投稿内容は少し情けないと言わざるを得ない．

今言えることは，まず，「ネットワークを再定義したい」という，市場の大きな波があることは確かである．これはとてもわくわくすることだ．一方，このことにより，ネットワークやシステム機器ヴェンダが無価値化する，という論調もある．これも，冷静に受け止める必要がある．実際，ある領域においては既に起こっていることだ．この擾乱期においては，これからのネットワークの在り方についての真の要望や意義を捉え，かつ，それを実現して行くことが重要と思う．

ところで，SDNで一つ疑問なのは，ネットワーク性能特性をアプリケーションソフトウェアがどの程度指定すべきか，という点である．

SDNのNetwork Programmabilityによって，ネットワークの自動化，オンデマンド化，最適化，シナリオ化が進むであろう．しかし，それは構成，トポロジー，エンカプスレーション，パス計算やパス決定，その他イヴェントと言った，ネットワークの一面を捉えたものに過ぎない．ネットワーク技術の進歩は，その性能特性の進歩である，と言えるにも関わらず，である．

帯域・伝送効率，スループット(pps)向上は勿論，各種コントロールプレーン，Leaky Bucket Modelに基づくpolicing, Queue Service Scheduler, Congestion Management,　Load balancing, 冗長，異経路化，Fast Convergence, Fast Protectionなどなどの技術は，ひとえに性能特性，SLA特性を上げるために開発されてきた．だから，一言でA地点からB地点への接続性と言っても，そのネットワークがどのような設計コンセプトでどのように構成されているかによって，得られる性能特性が全く異なる．また，ネットワークの性能特性は相対的なものでなく，数値を特定しているものも多い．帯域やppsのみならず，50msec以内の迂回時間，99.99%の稼働率，など．SDNでは，このような性能特性を，アプリケーションが活用すべきなのか．活用できるのか．

基本的に，ソフトウェアは，自身の性能の記述ができない．その性能は専らそのソフトウェアが実行される環境に依存するためである．したがって，その性能特性は，外側からベンチマーク試験等で計測するしかない．自分の性能を記述できないのに，性能指標をプログラムに取り込むことには無理があるかもしれない．

実際，例えば現在のOpenstack Quantumでは，指定するのはNetwork IDとPort程度で，とりあえずConnectivity確保とIsolationができればよいという感じ．確かに，そのネットワークの性能特性を抽象化されたセットにして，それを"Network ID"に紐づける，というのが，現実的な運用方法なのかもしれない．

一方，折角のProgrammabilityなのに，この程度の結合度でよいのか，という気もする．この程度であれば，別にProgrammableである必要はないのでは．（勿論，Programmabilityの目的は別のところにあるのかもしれないけれど．）

そこで，ネットワークを「環境」として捉えるのではなく，「オブジェクト」として捉えるのはどうだろう．「オブジェクト」であれば，性能指標もプロパティとして与えることができる可能性があるのではないか．実は以前，ネットワークのコネクティヴィティ／トランスポートをオブジェクトとして捉える提案を，論文にしたことがある．2007年のことだ．勿論，論の運びが学術的でなく，論理的根拠も実際の裏付けもなく，不採録になったが，目の付けどころは悪くなかったかもしれない．練り直して再チャレンジしようかなぁ．

見方・捉え方の違い

長年技術者をしていると，「えー，そんなアホな」という場面に遭遇することがある．そのような場合，「アホですか」とは言わずに，なんでそのような事態に立ち至ったかをまずは理解するようにしなくてはならない．自分の感覚からすればどんなにばかげているように見えても，それは単に見方・捉え方の違いに過ぎない，ということがよくあるからだ．

私も，「アホですか」と言われた（いや，実際にそう言われた訳ではなくても，あからさまにそういう雰囲気になった）ことは何度もある．

大分昔，KAME(BSD系IPv6 protocol stack)の開発者の一人に「何故IPv6に下位互換性を持たせなかったんですか？」と訊いたら，「へ？（アホですか）」，と呆れられ絶句された．「だってヘッダのアドレススペースが足りないんだよ？！いくつか互換性を提供するための技術はあるが(IPv4 mapped addressとかNAT-PTとか(当時)）根本解決にはならない．そもそもNATが蔓延しend-to-end原理が崩壊したIPv4なんかさっさとやめて，ネットワークを再構築した方がよい．」当時はこういう論調だった．

一方， これは2年前，Systems Engineeringの大家で，現在はNUS(シンガポール国立大学)でSystem Thinking, Critical Thinkingを教えられているJoseph Kasser教授に，インターネットにおいてIPv6がなかなか普及しない話をしたとき，「全く新たな価値をもたらすものでない限り，下位互換性を持たせなければ普及しないのは当然．（アホですか）」と言われ，ここでもそうですよねと引き下がらざるを得なかった．

立場，見方，捉え方，パースペクティヴの違いにより，そしてその時の状況により，現象の捉え方がこんなにも異なるのだ．

人間は，成長するに従い，ある見方・捉え方を身につけて行く．しかしそれは，同じコミュニティに属するごく親しい間柄でも，人によって異なることが多いし，ましてや広く普遍的なパースペクティヴというものは存在し難い．だから，何かを他者と一緒に成し遂げようとする場合は，できるだけ理にかなった仮説を提示し，それについて，言葉をつくし，場を共有して，相互理解を醸成する必要がある．これは，相手が一人ないし少数であれば対話であり，多数の場合は，このことこそが「リーダーシップ」というものなのだろう．

 

（おまけ）

私は職業柄0から数え始める習性がついてしまっているが，一般常識的には1から数えるのが普通だろう．そのため音楽の合奏練習で困ることがある．小節番号や練習番号がついている場合は問題ないのだが，「2番かっこの小節から2小節目」とか言われるとだめだ．脳が勝手に「2番かっこの小節」を0として，そこから1,2と数え，都合3小節目から弾き始めてしまう．先日も，うまくいかず雰囲気がぴりぴりしているときにやってしまって，「アホですか」状態になった．これも捉え方の違いではないかと思うが，勿論言い訳はできない．

一方，音程の表し方（ドとレは2度，ドとミは3度とかいうやつ）で，「同音なのに1度というのはおかしいのではないか．ドとドだったら0度，ドとレで1度なのでは」，という人がいるが，音程は，｢数」ではなくて「比」なので，同音は1度でよいのです．

 

Programmability, Virtualization, そしてCentral Control －Openflow考

• Programmability  --- コンピュータ言語を使って動作を記述できること
• Virtualization      --- 物理的なリソースに捉われない抽象化
• Central Control    --- 集中制御

Openflowはこれらの，各々は従来からあった概念を一つにまとめることにより，これまでのネットワークに対する新しい技術として，注目をあびることになった．何となく新しいものを求めていた人々が一気にここぞと群がる構図，そして，一見わかりやすいが本質を間違った解説の氾濫は，どうにもかたはらいたい感じがするけれど，エコシステムはこのようにして生成される，という側面もあるのだろう．（どんなに技術が優秀でも，エコシステムができないために普及しない，というものは山ほどあるので．）

ところで，ProgrammabilityとVirtualizationは，コンピューティング高度化に伴う，ネットワーク進化の自然な方向に思える（特にProgrammabilityについては，大分前からできるのに，運用慣習的に，今まであまりやらなかっただけだ）．しかしCentral Controlは，どうも私はあまり好きではない．集中制御に対する自律分散制御のよいところは，ボトルネックのないスケーラビリティ，障害時の自動回復，状況に対応する弾力性，などであるが，何といっても，「知が偏在する」，というシステムのあり方自体が好きだ．全知全能の神はいなくても，それぞれが限定合理性(*)の中で持ち場を果たすことにより，システム全体が機能し，さらに成長進化する．

現在なぜCentral Controlが見直されているか，というと，Virtualizationとの組合せによりScale outさせることができるため，Single Point of Bottleneckを克服できるようになったからだと思う．しかし根源的問いとして，「全知全能性」を達成できるのか，という問題が残る．

勿論，データマイニングによる統計の高度化は言を俟たない．これまでの，局所的な専門知識や技のようなものは，どんどん凌駕されて行くだろう．ネットワークのパス計算や決定も，統計的に最も合理的な判断により，集中的に行いたい，という要望が出てくるであろうことは理解できる．しかし，それでも，解けない問題はあるし(NP-Complete, NP-Hard)，当然間違えることもある．また，現実の実装を考えると，最適性よりも即応性が求められる場合もある．

なので，集中制御を導入した場合も，Last resortとしての自律分散は残す，というハイブリッドアプローチが求められると思う．（で，その場合は，「ネットワーク機器に機能はいらない→コモディティで価格破壊...」，ということにはなりませんよ．残念ながら:)）

(*) オリジナルはH.Simonだが，ここではStanford福田先生の論文を掲げたい．

http://www.panda.sys.t.u-tokyo.ac.jp/ohsawa/SysInPDF/002-Fukuda.pdf

 

"Carrier Grade" - 再定義が必要

通信事業者（キャリア）のシステムは「キャリアグレード」と呼ばれる。通信システムは、企業や社会の基幹を担うため、高い信頼性が求められる。その要請に応えるためのシステム特性が、「キャリアグレード」という言葉に集約される。

「キャリアグレード」の具体的条件としては、「High Availability(高可用性)」、「Guarantee(帯域・性能などの保証)」、「Predictability(予測可能性)」、（「Security(機密性・安全性)」、「Transparency(透過性)」、「Continuity(継続性)」などがあり、サーヴィスの性質により、これらの要素が適宜組み合わされ提供される。特に信頼性の観点からは、高可用性・性能保障・予測可能性が最重視されるので、ネットワークエンジニアは、可用性を保証するために必要なメディア特性、冗長度、検知・切り替え手法、また最繁時に予測されるトラフィック量、許容される遅延などから、必要な回線や設備を算出する。そのためにはシャノンの情報理論、そしてオペレーションズリサーチ（特に、信頼性工学、トラフィック理論、待ち行列理論）を駆使する必要があるから、これらは通信技術者の必修科目であった。DNAと言ってもよいかもしれない。

そんな中、1996年にNTT-Communicationsが開始したインターネットサーヴィス「OCN」は、「ベストエフォート」を強調して画期的だった。安価である代わりに「通信品質を保証しない」と宣言したのだ。脱「キャリアグレード」宣言(!!)である。

でもそんな画期的な宣言ができたのは、あくまでも代替的サーヴィスであったからであろう。1996年の時点では、基幹通信網としては専用線が主流だった。例えばATMメガリンクが開始されたのはOCNサーヴィス開始の翌年の1997年である。こちらの方は勿論「キャリアグレード」だった。

あれから15年の歳月が経過し、殆どの通信がIPになった今も、「キャリアグレード」は健在である。通信事業者がIPv4枯渇対策のために導入するNATは「キャリアグレード」だし、スイッチやルータには、いかなるモジュールや回線の故障時にもsub second（１秒未満）で切り替わることが求められる。

しかし、今、「キャリアグレード」の再定義が必要ではないだろうか。これまでの「キャリアグレード」を追求している限り、通信事業者は自らの首を絞めることになると思えてならない。以下、論拠を述べる。

---------------------------------------------------------

• トラフィック理論では、トラフィック生起率や処理時間はポアソン分布で近似できるとする。（事象は離散的ではあるが、集積されれば正規分布のように平均と分散で表現できる。）しかし、現在、実際に起こっている事象のいくつかは、べき乗分布に従うことがわかっている。べき乗分布の場合、「平均」という概念は無意味となり、トラフィック理論は使えない。

• 設備計画のためには、ある程度トラフィック量の推移を予測する必要がある。しかしスマートフォンの急成長など状況がめまぐるしく変わる現在、需要予測はほぼ不可能である。

• 可用性をある程度以上に向上するためには、経済的にもネットワーク設計的にも高いコストがかかる。

•  
  • 分散並列処理が可能でない場合、システムにはボトルネックが生じ、その可用性を上げるために冗長度を上げようとしても、収穫逓減になる。

•  
  • 分散並列処理が可能な場合は、「Consistency（一貫性）、Availability（可用性）、Tolerance to Network Partitions（耐分散性）の3つ全てを成立させることはできない」という、BrewerによるCAPの法則（*）に当てはまってしまう。即ち、分散処理系の場合、可用性か一貫性のどちらかを犠牲にしなければならない。ここでは可用性を上げる前提のため、一貫性をある程度妥協し、システム全体で何らかの補完をするような手立てが必要となる。（*）http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

• Ethernet Aggregationが主流の現在、回線信号断(LoS)では障害を検知できないので、sub secondで切り替えるためには、Continuity Checkをmsec単位で行う必要がある。（このこと自体がスケールネックになる可能性を持つ。）一方、殆どのトラフィックがTCP/IP、HTTPに収斂されている現在、許容通信断時間は変わってきているのではないか。例えそうでないとしても、ネットワークのある一部分を取り出し、そこでsub secondの切り替えに固執することは、あまり合理的とは言えない。

---------------------------------------------------------

東北の震災のときに、「キャリアグレード」である電話・携帯電話は不通になったが、無料のSNSは使えていた。（私事で恐縮だが、震災の日、世界中の同僚や友人からは次々と連絡が入るのに、子供たち(SNSやPCメールはまだ使っていない)と連絡が取れない、という状態が半日以上続いた。今思い返しても本当に切ない。）勿論、電話システムの場合は呼制御があるので、同列に比較することはできないことはわかっているが、それでも、「キャリアグレード」っていったい何なんだ、と思わざるを得ない。

しかも、安価なクラウドサーヴィスに、「キャリアグレード」は、このままでは対抗できない。クラウドサーヴィスは、必要に応じてスケールアウトでき、かつ、ノード障害時も他ノードに処理を引き継ぐことができる。一方、「キャリアグレード」なのに（いや、だからこそ?）、docomo sp mode障害のような事故は起こる。通信事業者の報道発表資料で、「原因は通信設備故障、サーバふくそう」とか、「容量のさらなる増強をし今後に備える」という言明を聞くたびに、痛々しい気持ちになる。トラフィック需要なんかこれからも予測できないし、スケールネックを解消しなければ、どれだけ容量を増強しても、コストばかり嵩み、焼け石に水であろう。

「キャリアグレード」という概念自体は、通信事業者の社会的責任、コミットメントを表すものとして、有意義で価値のある概念だと思う。しかし、この概念が、従来の設計・計画・管理手法を踏襲し、局所最適を助長させるものとなってしまっているのではないだろうか。

 

今、「キャリアグレード」の再定義が必要だと強く思う。信頼性とは何か。どのようにしたら、現代の複雑多様な社会要請に応え、増えるトラフィックをさばき、企業活動や個人の生活を充実させることができるようなサーヴィスを提供することができるのか。根本に戻って考え直す必要がある。

 

 

 

 

楽器調整

年末の端境期に、ピアノ調律(年1回)と、チェロの調整(こちらは不定期だが年に1-2回)を行った。

音は純粋な物理現象だから、その調整にはもっと科学的・合理的な方法があってもよさそうなものだが、この現代においても、楽器の製作・調整は完全な属人技である。特に弦楽器なんて木に4本の弦が張ってあるだけのシンプルな構造なのに、何故こんなにも奥が深いのか。複雑多様な外的要因に対応するためには、相応の複雑多様性が必要（アシュビーの法則）なので、楽器の構造がシンプルであっても、その分それを扱う者には複雑多様性が求められるのかな。

このところずっと、発音を良くしたい、音の立ち上がりをシャープにしたいと思い、そのために、張りの強めの（そして値段も高めの...ラーセン-ソリストとか、エヴァ-ソリストとか...）弦を張り、弓の毛で弦をしっかり捉えようと右手をいろいろ工夫していたが、なかなか思うように行かなかった。そんなとき、弦楽器製作者の重野汎さんをご紹介戴いた。

初めて楽器を持って工房にお邪魔したときは、いきなり、「ちょっと弾いてみてください」と言われ、戸惑った。おずおず弾くのを腕組みして聴いていた重野さんは、楽器がもっと自然に響くようにと、駒と魂柱を作り直して下さった。弦についても、「最近は張りの強い弦が出ているけれども、もっと柔らかめな弦の方がよいのではないか。AD線はヤーガー、GC線はスピロコアでもタングステンでなく普通のクロームがよい。」重野さんの持論は、「全く無理なことをせずに、弓を自然に動かすだけで、音は立ち上がってくるし、響く」、というもので、彼のセッティングのおかげで、私の楽器も、そして弾き方も確かに変わった。（弾き方の方はまだまだだけれども。）「楽器が持つ方向、調整者、演奏者の求める方向の３つが全て同じ方向に向かったときに、よい音が出せる」とも仰る。音という自然現象に対峙する深い洞察、飽くことない音の追求により培われた技術と理論に、畏敬の念を覚える。

下記は、その他、具体的な諸注意。

• 調弦により駒が微妙にネック側に傾くが、そうなると弦にかかる重さが楽器にまっすぐに伝わらなくなり、音に影響してしまう。調弦のときは、必ず駒のテールピース側が楽器に対して直角になるように注意する。

• 弦の巻き方でも微妙に音が変わってしまうことがある。巻き始めの弦を弦自身で抑えるように巻くと安定する。

• 弓がすべってくると、普通は松脂が足りないのだと思い松脂をつける。それでも改善しなければ、弓の毛を交換する。しかし実際は、松脂のつけすぎや、松脂の成分が残っているために、音を出させにくくさせている可能性の方が大きい。余計な松脂は徹底的に取り去る。（重野さんは、歯ブラシで弓の毛を鋤いて(!)、松脂をまんべんなく落とす。こうすることにより、弓の毛が切れて少なくなるような状態にならない限りは、毛替えの必要も無いと仰る。）

弾き手の動作が、楽器本来が持つ自然な発音を邪魔する要因になる、ということを改めて認識する。江口さんがよく仰る「楽器が喜んでる・喜んでない」というのも、そういうことなんだな。

 

正門 (Masakado)「舟歌(Barcalore)」再び！

正門憲也作曲「管弦楽のための舟歌」を演奏することになった。（東京文化会館の50周年記念イヴェント。）都民響にとっては、60周年記念委嘱初演に続き再び、私にとっては、2009年に演奏した「弦楽のための舟歌第一番」に続き再び、である。「弦楽のための～」は山形県最上川舟歌を題材にしているが、「管弦楽のための～」は、日本最古の運河、埼玉県見沼通船堀の舟歌だそうだ。前者は光と水しぶきの描写がフランス音楽のようだったが、後者の方はもう少し日本的かな。雅楽のような響き。

同時代の音楽を演奏する、ということについては、多くの複雑な問題が（感情的なものまでも含めて）入り乱れる。（1)耳が馴れていないという問題、2)時の試練を経ていない問題、3)妬み・嫉み・やっかみ、4)その他もろもろ...）しかし、作曲家と演奏家の間に信頼関係があれば、即ち、作曲家が演奏家のことを想い、演奏家が作曲家に対して限りない尊敬と信頼を寄せるような場合は、その音を紡ぐことがこの上ない幸せになる。

正門先生の音楽的才覚と、脳内にある曲のイメージを、そのままコピーできたらどんなにかよいだろう、と思う。しかしそれはできないので、書き下ろされた譜面と指揮、そして若干の言葉による補足（蛇足？）を頼りに音楽をつくる。しかし、相変わらずの正門節。そしてリズム地獄。

リズム地獄には、変拍子（小節のたびに拍数が異なるためものすごい集中力が必要）、シンコペーション（本来弱拍の位置に強拍が来るため、気合をいれないと、譜面の拍子と実際の感覚に乖離が生じてくる）等いろいろあるが、それらはまだ全然よい方である。正門先生の作品には、譜面面は然程複雑でないのにリズム割りが各パートで異なる、というポリリズムが多用されており、これが非常に厄介。しかも特に合奏初期の状態では、他パートが正しいかどうかもわからないため、音をどこにどう入れればよいか、まったく渾沌としてしまう。2×3=1.5×4（6拍子を二分音符3つでカウントしているところに付点四分を４つ入れる）、2x3x2＝4x3（同6拍子の小節2連を大きな3拍子のヘミオラで。）いやこう書くとシンプルだが、実際は、さらにその１拍が3連、5連、6連や、3:1（いわゆる"タッカ"のリズム）などになっており、かつ拍の頭が休符だったりするので、ついて行くのが難儀である。ぐげー。先生は、「ここは多少ずれてもよい」、とか仰るが、一度ずれてない状態がどういう状態かを理解しないことには、どのくらいずれててよいのかもわからない。先生は頭に描いた音が出なくて、さぞもどかしいことだろう。同時に、渾沌を愉しんでいるようにも見える。とにもかくにも、作曲家とともに音を紡ぐことは、一期一会である。そして出てくる響きは、目前のリズム地獄とは別次元ののもの。美しい（うまくいけば）。

今回は、さらにアンコールとして、20年前の若かりし日の作品という「小組曲」から一楽章「直線的な踊り」も演奏する。（ネタバレか..、しかし読者数が限られているので大丈夫でしょう....。）こちらは、正門節全開の舟歌に比べると、習作的なところがあるだろうか。バルトーク、伊福部、キラールなどが想起される。しかし、すごくかっこいい。響きも圧巻。私には、「火の鳥（ストラヴィンスキー）」の凶悪な魔王の踊りとオーヴァラップして聴こえて仕方ない。夢にまで出てきて、まいった。

もしかすると、弦楽版と、管弦楽版の両方の正門舟歌を弾いたのは私が最初かもしれない。これは後世に自慢できるかな？いろいろな場所で先生のご指導を受けることができたため、脳内コピーはできないものの、コンテクストの共有度が高まり、大体言われることはすごくよくわかるようになった。後はできるだけよい演奏で再現したい。11月6日、13:00から、東京文化会館大ホール。もしよろしければいらしてください。なお、前プロはハイドンの94番交響曲「びっくり」。「清冽さ」が両者の共通点だが、構成の多様性は対極にある。多様性の高い構成は、まとまりにくいが、擾乱や不確定な事故に対しては耐性が強い、ということもよくわかる。:)

 

P.S.1 脳内コピー、近い将来*ある程度は*できるようになるのではないか、と考えている。（真剣に。仕事モード。）

P.S.2 なお、この後も11月19日（土）には奥多摩の水と緑のふれあい館におけるコンサート（弦楽5重奏＋Ob： チラシ（高校生になる娘が作ってくれた））、12月10日（土）の特別演奏会、と本番が続きます。師匠からの厳しい課題もいくつか。さらわなくては。

 

 

 

 

 

技術の「融合」を考える MPLS-TPのケース

技術変遷の過程では、相補的対立的な概念や技術が生まれる。例えば、

• Circuit vs Packet
• Intelligent vs Stupid
• 集中 vs 分散
• Control vs Open
• Top down vs Bottom up
• ATM vs Ethernet
• Connection oriented vs Connection-less
• IP vs other Networking Protocol (SNA, Appletalk, IPX, etc.)
• ...

それらは、時代の流れにより、どちらかが凌駕したり（*1）、共存しながら勢力変化を繰り返したり（*2）、融合したり（*3）して、技術は次のステージへと変遷する。

(*1) L2としては、Ethernetがクライアントとしてもインフラとしても使われるようになり、ATMは縮退した。L3はIPに収斂し、他のプロトコル(SNA, Appletalk, IPX, etc...)は使われなくなった。

(*2) 集中と分散というアーキテクチャ概念は、形を変えながら、出現する。たとえば通信分野では、管理システムによるパス制御（集中）→自律的ルーティング（分散）→Openflowのような、Controllerによるパス制御（集中）...。コンピューティング分野でも、ホスト・端末/TSS（集中）→クライアントサーヴァー（分散）→クラウド（分散された集中）...。

(*3) MPLSは、Connection-Oriented概念とConnection-less概念を包含、融合した。

 

そしてここ数年では、CircuitとPacketの融合が起こっている。Ethernet over SONET/SDH、Circuit over MPLS、PacketとOptical(OTN)の統合、などなど。そして最近各所で最も話題になっているのが、MPLS-TP(MPLS Transport Profile)である。

MPLS-TPは、もともとITU-Tが、MPLSのConnection Oriented的な要素を利用して、伝送的特徴を持つパケットトランスポート技術を開発しようとしたことに端を発する。そこに、MPLSを開発したIETFが"待った"をかけた。「MPLSはひとつの統一的技術であるべき。他の標準化団体が独自に拡張することは好ましくない。」そして、ITU-TとIETFでの共同作業が開始され、MPLS-TPとして標準化されることになった。

私はこれまでこの技術にあまり関わっていないが、最近になって顧客からの要請も多く、我々のルータでも一部実装が行われつつある。今回チュートリアルの依頼を受けたことをきっかけに、ここ数日で集中的にキャッチアップし、勉強した。そして....、愕然とした。

相補対立的なものが融合するためには、お互いの技術の良さが共存でき、よい協調、よい使い分けができなくてなはならない。

しかしMPLS-TPの場合は、それどころか、それぞれの技術のよさを打ち消しあう。IPの弾力性（resiliency）、自律性（autonomy）を失うのみならず、回線交換の、決定論的な予測可能性（遅延・ゆらぎ・紛失が起こりえない）という特徴も失う。（MPLS-TPは統計多重である。）

MPLS-TPの主要な要件は、「IPへの非依存性」と、「伝送技術的なOAM」である。パスの疎通確認(Continuity Check)、トレース、ループバックに代表されるOAM制御は、伝送では、Framing Overheadに組み込まれている。IP/MPLSはそうではないので、別の方法で実装した。しかし機能面から見れば、既にある機能を、別の方法で実装することに他ならない。何か有益な機能が新たに追加される訳ではない。

そのため、同じ機能要件に対して複数の実装を許容すべきか、という議論が白熱している訳であるが、それよりも大きな問題は、「IPへの非依存性」という要求は、ルータ、というか、コンピューティングプラットフォームにとって非常に困難、という点である。これら装置は、プロセス間通信を行うためにも、普通にTCP(UDP)/IPを使う。IPに依存しない、となると、複雑かつ余計なステップが必要となり、非常にトリッキーな実装になってしまう。（Pseudo WireのOAMもIP非依存が求められるが、Pseudo Wireは、LSP上のアプリケーションだからよい。LSP自体のIP非依存というのが厄介なのだ。）

技術自体の良し悪しを論じるつもりはない。市場が決めることだ。そして、現在のMPLS-TPへの要求の高まりは、伝送技術に長けた勢力が統計多重を取り入れようとしている、ということだと理解できる。しかし、IPを技術の機軸に据えるIETFが手を出すべきではなかったのではないだろうか。それぞれの技術の良さを共存させ、よい使い分けを実現できるとは思えない。お互いの良さを打ち消しあい、疲弊するだけだ。混ぜるな危険。少なくとも、我々は手を出すべきではないと思った。

 

 

お受験の弊害?! - 「未知」を愉しむ

次女が私立中学校に入った。小学生を塾漬けにするなんて全く私の眼中になかったが、本人が周囲に影響されてか私立校を希望したのと、「両親共働き → 早々に帰宅されても家に人がいない → （本人はピアノとヴァイオリンを弾くが）近隣の公立中学校には吹奏楽部しかない →....」というのっぴきならない事情で、受験することになった。

弦楽・管弦楽の活動がある中学校は、なぜか（無駄に）偏差値が高めである。このことに気づいたのが小学5年の暮れだったので、「今からではかなり遅いと言わざるを得ない」と、さんざん苦言を呈された挙句何とか受験塾に入れてもらい、その後塾漬けの日々が始まった。平日は隔日夜9時までみっちりで、さらに宿題も出る。楽器を弾くために受験するのに、受験のために楽器も弾けない、というのは、まさに本末転倒である。そして土日は、試験とその結果によるクラス再編と席替えが毎週行われる、という日々。隣机の友さえライバルと意識付けられ、情操面の配慮などあったものではない。夏休みも、お正月も、連日狭いビルに閉じ込められてお勉強。しかし、目的が明確なときの人間は強い。半ばあきれながらも、遊びたい盛りの小学生なのに男の子も女の子もみんなよく頑張っている姿には感動するものがあった。こちらも身が引き締まる思いになったし、何よりも、代数を学ぶ前の鶴亀算、時計算、ニュートン算、旅人算などはすごく頭の体操になり、面白い。

で、何とか乗り切って今に至るわけであるが、その次女が、ことあるごとに、「そんなの教えて貰ってない」とか、「まだ習ってない」とかいう。長女はこれほどではなかったので、これはもしかしたら、常に解法のパターンを叩き込まれ続けた、お受験の弊害ではないだろうか。

「予め教えてもらえることなんてほんの一握り。自分の頭で考え自分で何とかしなさい。」と言うが、なかなか改まらない。今朝もまたそんな話になったので、「産まれたばかりの赤ちゃんのときは、何も知らないのに、毎日新しいことを楽しそうに覚えて行ってたよね。何でかな。」と言ってみた。そうしたら、「いつから、知らないことが楽しくなくなったんだろう」と真剣につぶやいていた。

自問自答することはよいことだ。赤ん坊のように、新たなことを知ること愉しんでほしい。そして、答えのないことを考えることを愉しんでほしい。そういえば、自分だって、新たな領域にチャレンジするときに知らないことが多いのは苦痛である。でもその状況を楽しもう。

 

 

「月光川の魚研究会」 －ものがたりを紡ぐといういこと

先日高校の同窓会があった。最初はあまり気乗りしなかった。今は時間がないし懐古の気分ではないのに、共通の話題といったら昔話くらいしかないではないか。しかし行ってみると、昔話はあまりしなかった。高校という時代を共にした仲間は、懐かしく、親しく、気心が知れているのだが、一方で、友人のことなんて何ひとつわかっていなかったということに気づかされた。考えてみれば当然かもしれない。何を専攻し、何を職業とする、など、自己を確立して行くのは、多くの場合高校卒業後のことなのだ。（私なんて、学生時代は終始ぼーーっとしていて、物心ついたのはつい最近(?!)だし。）

一人の級友と話した。最近本を出版したと言う。「わぁ、すごいね。どんな本？」と訊いても、あまりはっきり答えてくれない。昔からあまり自己アピールする人ではなかった。そういうところは変わらない。でも、後からその小説を送ってくれた。

「月光川の魚研究会」。なんだかよくわからないタイトルだ。でも、カヴァーの写真がとてもきれい。実は、ここ暫く時間が取れそうにないので夏休みにでも読もうと思ったのだが、手に取ったらどんどん惹きこまれ、一気に最後まで読んでしまった。

 

 

「月光川の魚研究会」とは、バーの名前らしい。そこにくるお客と迎えるバーテンダーにより儚く切ないものがたりが語られる。どこか懐かしい感じのするリズムのある文章、息を飲むほどうつくしい写真、そして音とともに紡がれる。（書物なのに、ところどころに挿入される音楽が心憎いほど、印象的な演出をしている。）

ものがたりを紡ぐ。...何気ない日常も、悲しい事件も、ちょっとしたすれ違いも、上質の語り手にかかると、こんなにも切なく心を動かす。私はこんなにすてきに物語を書くことはできないけれど、でも、ある事象とある事象をつなぎ、意味や流れを持たせる、関係性の有無を吟味する、ということは、常に行っている。だから、土台となる教養やさまざまな視点、そして控えめかもしれないけれど確固たる芯を以って語られるものがたりに、深く感動する。人間はなぜものがたりを紡ぐのか。

たぶん、ものがたりを紡ぐということは、生きる、ということと、同じことなのではないだろうか。よく生きる、ということは、自分の紡ぐものがたりを少しでもよいものにする、ということと等価である。基礎的な学問を身につける、仕事で周囲や社会の役に立つ、楽器を修行して少しでもよい音を出す、家庭の責任も果たす、などは、偏に、ものがたりをよくするための奮闘、なのかもしれない。

 

 

 

あれから3ヶ月 - 相補・対立のsynthesis

2011年3月11日から3ヶ月が経った。被災した方やその関係の方に謹んでお見舞いの気持ちを捧げる。

私自身は大した被害を受けた訳ではなく、もっと辛い思いをした人がたくさんおられ、そしてそれが現在も続いていることを考えると、誰かを励ますこともできず、何の役にも立たないような文章などを書くことに意味は無い。しかし、震災、特に原発事故に対する自分自身の無力感に正面から向き合うために、この3ヶ月ずっと考えていたことを記録しておきたい。

事故の直後は、パニックを抑制するためか、科学的立場からの被曝に関する言質が多くなされた。しかしその後、事態収束に向けての最低限の制御さえ思うようにできないことがわかるにつれ、反原発機運が高まった。

科学的アプローチは「ある前提の上に」のみ成り立つものなので、その前提自体がよくわからない場合は無力である。しかし、では人文的アプローチがよいか、というと、それだけではだめだ。サンデル先生の特別授業（そこでのジャパネット高田社長の真剣な面持ちがかっこよかった）は素晴らしいものだったし、最近の村上春樹のスピーチにも心を動かされる。このような、人間が生きる、ということに対する根源的な視点は、現在一番求められることであることは確かだ。しかし、やはり科学的アプローチがないと、その次の具体的な実装については踏み込めない。村上春樹は、今回の原発事故を、日本における二番目の核被害と言った。しかし、太平洋戦争は間違いだったとはっきり言えるのに対し、原発は間違いだったのか、ということに対して、まだ答えはない。（戦争も、その時代に生きていたら、間違いとは言えなかったかもしれない。）感情的・感覚的なものだけで判断するのは危険だ。

太陽光や風力、バイオマスなどの自然エネルギー、再生可能エネルギーはすばらしいものに思えるが、一方そんなにすばらしいものであれば、なぜもっと推進されてこなかったのだろう。これまでは何らかの要因で、十分に社会資本や叡智を集中してこなかった、ということか。ソフトバンクの孫社長が、「ADSLはISDNと干渉するので日本では普及できない」というそれまでの常識を覆し、日本のブロードバンドの低廉化と普及をもたらしたことは確かだ。今回も、孫さんの行動が自然エネルギー分野に大転換を起こせるかもしれない、という一縷の希望を抱かないわけではない。しかし、NTTやKDDIは当時、ISDNの次は光ファイバにするという道筋を描いていた。そして現在、実際そのとおりになった。だから、ADSLは、日本のアクセス通信史上の「一時的な寄り道」という見方もできる。孫さんのやったことは「ブロードバンド革命」と言われるが、見方を変えれば、二重投資の原因をつくった、ということもできる。今回の問題にしても、エネルギー密度と安全性は、かなりの部分トレードオフの関係にある。当面のエネルギー不足は避けられないので、様々な側面からの見直しが必須である。自然エネルギーへと舵を切れば万全ということにはならない。

夫の実家と親戚が南相馬市在住である。不便な生活を強いられ、また被曝への不安もかかえているにもかかわらず、気丈で、逆にこちらを心配してくれるような、思い遣り深い人たちだ。彼らのことを思うと、ただただ切ない。避難して欲しいと思うが、地元に仕事がある。何ができるだろうと考え続けても、なかなか答えは見つからない。一つ言えるのは、単に反原発に廻ればよいということではない、ということ。原子力はこんなにも制御不可能な技術だった。そういう技術に頼っていたこと、そして頼らせていた構造自体を、深く反省するところから始めなくてはならない。

今求められているのは、生きること自体や価値観の見直し、そして、科学的アプローチと人文的アプローチのsynthesis、原発を推進する立場とそうでない立場のsynthesisだと思う（synthesis:=統合・総合）。対立は重要だが、対立しているだけでは泥仕合になるだけだ。相補・対立する概念をsynthesizeして、初めて次の地平が見えてくるのではないか。

現代は「正答のない時代」である。「正答」はないので求めることはできない。現在起きていることとそうなった構造を見極め、それを乗り越えることにより、人間や組織・社会が成長するのだと思う。

トップレヴェルの演奏家は奏法を語らない

トップレヴェルの演奏家は、具体的な奏法について語らない。音楽も当然物理的運動であり、例えば弦楽器であれば、音程、弓にかける圧力（重み）、弓のスピード、弾く位置などで音色が決まる。だから、一流の演奏家が、「この曲のこの部分は、このくらいの弓圧で、弓幅は何cmくらい使って、指板寄りを弾く」、とかいうことを語ってくれたらどんなにか参考になるだろう、と思い、機会があるたびに調べていたが、そのような言説に遭遇できたことは一度としてない。最近ではプロの演奏家も音大生も、ブログやSNSで文章を山ほど書いているのに、である。稀に奏法に関する分析的な言説を発見することがあるが、評論家やアマチュアのものが多い。（例外はあると思う。）

演奏家は忙しくてそんな暇はないのか、もしくは分析や言語化が苦手なのだろうか、などと考えたこともあったが、そうではなかった。演奏家は、自分の身体を使って、明示的な教師または内なるイメージに従い、環境との相互作用をしながら、高度な「内部モデル」を獲得してきており、その「内部モデル」により、状況を予測・感知し適切な音を出す。しかも、その内部モデルは小脳にある、ということなので、意識は（そのままでは）関与できない。演奏家が（そのままでは）奏法を言語化できないのは当然である。一方、文章にする・言語化できる、というのは、大脳で理解している、ということであり、逆にそれでは、分析することができても、（そのままでは）演奏をすることはできない。

「内部モデル」は、生体システムの外にある環境モデルを内在化する、という点で、マイケル・ポランニーの「暗黙知」に完全に符合する。ポランニーに拠れば、「知」とは知覚の形成であり、実践的な知識と理論的知識の暗黙的統合である（暗黙的統合とは、「それが何かを特定できないまま統合している」、というゲシュタルト理論に由来する）。小脳の「内部モデル」は、40年余を経て、ポランニーの「暗黙知」を実証したことになるのではないだろうか。

また、認知の形成という点で、「アフォーダンス」理論との相対化もしたくなる。通常生体システムは、探索、試行、練習、努力、といったフィードバック誤差学習の繰り返しにより「内部モデル」を獲得するが、アフォーダンスは、環境の側が、生体による「内部モデル」の獲得をし易くするための特徴を持つ、ということになるだろうか。ポランニーの文脈では、主体の「より高位への志向」「（対象に対する）コミットメント」が必要なのに対し、アフォーダンスは、未熟練な主体に対しても効用があるため、人工物のデザイン（思わず身を預たくなるソファ、思わず押したくなるボタンなど）には有用や概念なのだろう。そういえば、小学校で使われるピアニカという楽器はアフォーダンス度が高いかもしれない。

「トップレヴェルの演奏家はなぜ具体的な奏法について語らないか。」この最初の問いに対して、ポランニーの言葉を引用したいと思う。「包括的存在を構成する個々の諸要素を事細かに吟味すれば、個々の諸要素の意味は拭い取られ、包括的存在についての概念は破壊されてしまう。」（マイケル・ポランニー、高橋勇夫訳、「暗黙知の次元」ちくま学芸文庫）

Recent books

　Blog更新の余裕がなくなったが、模索は続けている。

　あまりに放置しておくのもよくないかもしれないので、近況報告代わりに、最近の読書レポートを。テーマは「創造性」。

1.      “Patterns in Network Architecture – A Return to Fundamentals”, John Day, Prentice Hall 2008

著者は、インターネットプロトコルの黎明期に遡って基本に返り、見過ごされてきた「パターン」を抽出することによって、そのプロトコル要素とアーキテクチャの根本原理を再定義する。そのパターンとは、「階層性による抽象化」、「（ある階層内における）アドレシングとネーミング」、などと言った、基本的な法則のようなものだが、確かに、最近はこれらの基本を顧みずに機能を追加し、ネットワークを複雑化させてきてしまったところがあることに気付かされる。

 

ではなぜ見過ごしてきたか。著者は次の4つを挙げる。「初期の刷り込み」、「初期の成功」、「ムーアの法則」、「社会経済的圧力」。初期の成功は、その時の前提や条件を固定化してしまう。また、ムーアの法則に則った集積度向上のおかげで、インターネットはスケールアップとコストダウンの双方を実現して来たが、それは専らハードウェアの増強により行われたため、アーキテクチャの基本原理はほとんど顧慮されることがなかった。さらに、インターネットへの社会的経済的期待が高まったことも、基本に返ることを妨げてきた。

　徹底的に根源に立ち戻ることに拘るため、論調は哲学のようだ。例えば、アドレシングとネーミングの議論では、ゲーデル、ウィトゲンシュタイン、フレーゲが引用され、検証される。インターネットの現状や、IETFへの批判も含まれるため、本書の趣旨については賛否両論あると思うが、見過ごしていた、しかし無意識に自ら課していた条件に気付き、問題をより高次な次元から見直す、という点で創造的な書である。

2.       “The Art of System Architecting”, Mark W. Maier, Eberhardt Rechtin, CRC Press  2009

本書は、数少ないシステムアーキテクティングに関する本である。従来のシステム工学的方法論ではなかなか捉えられなかった領域、例えば「協調的システム」、「社会システム」のような、スコープや目的自体を定義しにくいもの、また、「Layered  Model」、「Agile  Development」のようなソフトウェアでの新たな開発手法に関しても、アーキテクティングという視点から、正面から対峙する。

 

工学書では理論に裏付けられた方法論が主になるが、それだけでは、スコープ定義や要素還元ができないシステムには適用できない。そのギャップを埋めるために本書が多用するのは、「ヒューリスティック（経験則）」である。本書では、システムアーキテクティングに関連する180を超える経験則を引用する。「よいアーキテクチャかどうかの検証は、それが永続するかどうかによって分かる。」「難しいところから着手しよう。」「現在成功している製品をつくったチームは、その製品を進化させるにはベストだが、新たな代替品をつくるためには向いていないことが多い。」、等など。

　経験則は、ユーモアに満ちているものも多く、また深く考えさせられる。また、これらの経験則をシステムアーキテクティングに応用するだけでなく、システムアーキテクティングで得た知見を、経験則としてさらに一般化、洗練化させて行くことができる。参考文献リストも興味深いものばかりだ。

 

3.      「生命記号論 – 宇宙の意味と表象」, ジェスパー・ホフマイヤー著, 松野孝一郎 + 高原美規訳、青土社 1999

 

現在の科学や論理では、自己言及の問題を解決できていない。従って、社会システムのように、厳密には客観的にはなり得ず、スコープも不明確で、要素還元できないようなシステムを扱う場合、たいていの場合、個々のケースに応じて、実践的な方法論的アプローチを取ることになる。

 

しかし、もっと汎用的な理論を立論することはできないものだろうか。生命は常に自らを創出する自己言及システムである。この生命現象から何らかの仕組みを抽出・理論化し、検証できれば、「客観的・科学的・数理的アプローチ」と、「実践的方法論的アプローチ」とのギャップを埋め、橋渡しすることができないか、と考えている。そのような中で出会ったのが「生命記号論」だ。

 

著者は、自己言及の問題を、前向きにとらえる。「私はこのパラドックスを喜ぶべき事態だと考えている。このパラドックスは、創造的精神と同じ源から湧いてくるのではないか。」（第4章「自我の発明」より引用）

　パラドックスは、メタ化・高次化により解消されるが、メタ化・高次化とは即ち「創造性」であり、そこには「創発性」も生まれる。また、そのような「創造性」「創発性」を記号論に結び付け、記述可能性を追求するこの本自体が、まさに「創造的」だと思った。

 

 

哲学 - 思考のフレームワークか、底知れない深淵か

ルータエンジニアとして、そして、インターネットコミュニティの一員として、「インターネットのこれから」を考えることは、いつの間にか私のライフワークになっている。で、最近は、少し哲学を勉強中。

その昔、少しだけ哲学少女だったことがあった。すぐに挫折したけれども。その後幾年月を経て、結局、倫理学（非帰結論的）はニーチェで終焉し、論理学はウィトゲンシュタインとゲーデルで終焉し、哲学は脱構築・ポストモダンで終焉した、と思っている。「絶対的な価値基準は無い。」「語りえぬものについては沈黙せねばならない。」「世界を記述できる一つの理論は無い。」理論としてはましに見える社会主義が終焉したことも、ある一つの理論により設計・計画されているシステムよりも、自由度が高くゆるやかなシステムの方が、複雑な世界に適応する能力が高い、ということを例証している。

ではなぜ今哲学か。まず、哲学者たちが必死に思索し記述してきた、根源的なものに対する視点と考え方は、思考のフレームワークとして極めて強力であり、それらを理解し内包することができれば、少しは「巨人の肩の上に乗る」ことができるのではないか。また、現在の問題意識は、やはり根幹まで戻らないと解けないような気がしているからである。

インターネットは、対象やステークホルダが複雑に絡み合い、かつ、常に変化しているので、予め「こうあるべき」という姿を定義することはほぼ不可能である。そして、その目的も、いつからかは自己目的化している。そのインターネットのこれからを考える、というのはどういうことなのか。対象が多様で巨大、かつ、自己（主体）と対象（客体）を明確に分けることができないような場合、自己とは一体何か、どのようにモデル化すればよいのだろうか。－これは、これまで哲学が散々やってきたことである。

哲学は終わっているかもしれないが、それでも、社会は廻っているし、インターネットは動いている。これはすごいことで、私はここに希望を持つ。新たなシステム論や科学哲学のようなものを整理し提示することによって、これからの方向性を考える助けにならないかと思っている。勿論、「思考のフレームワーク」なんて虫がよくて、単に底知れない深淵に沈むだけかもしれないが。

　「哲学は終わったが、しかし、遍在している。」(ジャック・デリダ)

正門憲也 「弦楽のための舟歌 」 - 多様性極まれり！

多様化・複雑化する○○。現代においては、○○には何でも当てはまるだろう。多様化・複雑化する { 社会 | 情報システム | 金融システム | 国際関係  | 対人関係 | コミュニケーション | 価値観....}。

この多様化、複雑化により、当然問題もたくさん起こっているのだが、驚くべきなのは、その割には単なる無秩序状態に陥るのではなく、新たな、たぶんより高度な秩序が、形成されて行く、ということだ。問題は山積み・噴出状態ではあれど、それでも社会は廻っているしインターネットは動いている。（この辺を自分なりに解き明かしたくて、今ちょっと勉強中。）

音楽芸術の世界でも同じような進化変遷をしている。今では古典として残っている名曲はほぼ全て、当時としては斬新な試みを行っており、それまでの秩序を少しずつ破壊しながら、新たな地平を切り拓いて行く。

弦楽合奏の次の演奏会で、我らが正門憲也先生の「弦楽のための舟歌」を取り上げる。私にとっては、初めて正門先生の曲に取り組むことになるが、これがもう本当にすごい。ひたすら涙。九の和音の連続、複合和音、複調...、いや和声の方はそれでもあまり問題がない（というより、かなり綺麗）。泣くほど苦労するのは各声部の流れとリズムである。当然ポリフォニー、時々ヘテロフォニーあり（微妙な各声部のずれ）、そしてポリリズム、しかも、各声部のリズムが既にかなり複雑なのに、各声部で違うリズムを刻む。さらに、追い打ちのように出てくるヘミオラ。しかも逆ヘミオラ。（逆ヘミオラという用語があるかどうかわからないけれど、例えば通常3拍の小節を2つまとめて計6拍と考え、そこを2拍ずつ大きな3拍子にする（足して割る）ことをヘミオラと言うと思いますが、正門先生の曲では、ゆっくりの3拍の中に4つ入れたり2つ入れたりする（割って足す）。ところで私、「ヘミオラ萌え」と自称するほどヘミオラ好きなんですけど、これがぴったり合わないと、欲求不満によるストレスになる。）　ああ、多様性極まれり！

これを指揮者なしでやろう、というのだから無謀である。正門先生は、練習の時は弾きながら小節番号や何拍目かを叫んでくださるが、本番ではそうも行くまい。たった15分8分の曲だけれども、マーラーのシンフォニーを全楽章弾いたくらい、神経を消耗する。実際、これまで何か月も取り組んできて、未だに事故無く最後まで到達したことがない！！まさに、問題山積み・噴出状態。

 

でもでも、これが、ぴったりはまると、まさに高度な秩序が形成される状態になって、とても美しい曲です。現代の作曲では、斬新な試みを行うがために、無調無機質で不快な音を書いたり、奇を衒って変な奏法を使ってみたり、ということがあるが、この曲は違う。それぞれが渾沌の極致なのに全体としては素朴な民謡（舟歌）のアンソロジーだ。フランス音楽の響きのような和声なので、私にはロワール川に日本の小舟がたゆたっているような光景が目に浮かぶ。船頭さんが気持ちよさそうに謡う。エンヤトットという掛け声のようなリズムも聞こえてくる。川面に光があたってきらきらしている。水しぶきが舞う。時々岩に当って舟ががつっと音を立てる...。

本番まであと一週間もなく、先日のリハーサルでもまだ事故が起こっている。こんな演奏では先生の顔に泥を塗ってしまうのではないか、という懸念もある。何とか少しでも高度な秩序の形成ができるように、この多様化・複雑化・渾沌に諦めずに取り組みたい。

P.S. ところで、本人によると「チキンラーメンのテーマ」(?!)が出てくるらしいんですけれど、どこだか特定できていない。というか、チキンラーメンのテーマってどんなのでしたっけ？いずれにせよ、「こんな音楽を書くなんて一体どういう頭の構造なんだ（尊敬）」、と思っているところに「チキンラーメン」とか言われると、そのギャップがまたおかしい。

P.S.2 現代の音楽って言葉にするのが難しい、と思ってたら、たまたま今読んでいる本にこう書いてあった。「現代という時代は自分を表現する古典をもっていない。」うーん、当然と言えば当然だけれども深い。（「現代倫理学入門」、加藤尚武、講談社学術文庫）

評論家はキライ

評論家というのはどうも好きではない。

 

新聞の夕刊にはよく演奏会評が載っていて、ついつい読んでしまうが、辛口批評を見ると、そんなによーくわかっているんだったらご自分で弾いてみたら、と思ってしまう。勿論、評論家が演奏家の賞賛や応援ばかりしている訳にはいかないし、それでは評論の意味が無い。しかし、イマジネーションを具体的な音に射影 し、その「欲しい音」を紡ぎ出すための飽くなき研鑽に比べたら、後からどうこう言うのは簡単でしょう、と思ってしまう。

 

経済評論家もそう。既に起こったことに対し、後知恵で尤もらしい理屈をつけることについて、意味がないとは言わない。しかし、リスク承知で困難なことに挑戦する人々に比べたら、一体どれだけの価値があるのでしょう。それなら、後知恵でなく予測すればよいのか、というと、その予測が的を射ていなければ大勢に影響ないし、もしも的を射ている場合はそのこと自体がシステムの挙動に組み込まれることになるので、どのみち予測にはならない。

 

しかししかし、ふと我が身を振り返ってみると、自分の仕事が何だか評論家っぽくなっていないだろうか。現在実際にコードを書いている訳でもなく、製品を使って実際にサーヴィスを提供している訳ではない。製品開発に間接的に携わっているものの、自分が手を下していないのに批判してしまうようなことがある。自分があんなに嫌っていたことを自分でやっているのではないか?!

 

でも自分の今の適性を考えると、コーダに戻ってもあまり生産性が上がらないだろう。せめて、開発者と話すときは開発者の土俵に立って、サーヴィス提供者と話すときはサーヴィス提供者の立場に立つようにしよう。後知恵ではなく、常に自ら考えて結果を謙虚にフィードバックしよう。常に修行僧の気持ちでいよう。新たな視点を探してみよう。問題を発見して面白がるだけでなく、解決方法を考えよう。

 

ところで、余談だが、実は評論家よりもさらにキライな人種がいる。...それは政治家。

 

「音楽家としてのモットー」

都響のパンフレットの楽員紹介のページに、各メンバーの写真と簡単なプロフィールが載っている。プロフィールの項目の一つに「音楽家としてのモットー」というのがあって、これがとても興味深い。

モットー(Motto)って、たぶん元は「大切な言葉」というような意味だろうか。転じて、信条とか行動指針とかを表すのだけれど、同じオケに所属する音楽仲間・同僚であってももう千差万別である。「感性や感覚を磨く」、「日々驚きを求めて」などの感性派、「明るく」「楽しく」とか「健康第一」とかいうヘルシー派、「人に楽しんでもらう」「ひとつひとつの演奏会を大切にする」などのサーヴィス派、「誠実に」「真摯に」「常に原点を忘れない」「一生学習・練習」というストイック派、「自然に」「シンプルに」「素直に」といったナチュラル志向、などなどなどなど。「音楽家としての」というよりは、それを超えた、その人の人間としての生き様のようなものを感じる。

ぶっとんだのは、何てったってソロコンサートマスターの矢部達哉さん。一言、「脱力」。もしインタヴュアーが意気込んで「あなたのモットーは？」と訊いたとして、こう答えられたら、インタヴュアーの方が脱力してしまうのではないか。いやしかし、これはすごくよくわかる。少しでも余計な力が入ると音は微妙に硬くなるため、豊かな音、深い密度の濃い音を出したい時こそ、脱力は重要。でも現実にはしっかり弦を抑えたり、弓をholdしてかつ制御しなくてはならなくて、これには勿論必要最少限の力が必要だ。だから演奏家にとって脱力は永遠の課題である。しかし、矢部さん程の方でも常に心がけておられることだということ、しかも「音楽家としてのモットー」とまで言ってしまうほど大切なことなのだ、ということに、何とも深い深淵を見たような気がする。

コンマスの山本友重さんのもすごい。「絶対的透明な響きを目指す」。「絶対的透明」ってあるのでしょうか？透明な響きとは？絶対的透明って？？うーん。うーん。

さて、親愛なるチェロパートのメンバーはどうだろう。古川展生さん、「一匹狼」。ひぇー。そうですか。そうだったのか。そして我が尊敬する師匠、江口心一さん、「夢ある音を求めて...。」そういえば江口先生は、勿論具体的なアドヴァイスもして下さるが、時々夢の世界からの伝言のようなことを口走る。「うーん、楽器が喜んでない！」　「楽器を弾こうとするのではなくて！」

私の「音楽家としてのモットー」を訊かれたらどう答えるかな。取敢えず今は「仮想と物理現象とのよりよいマッピング」かな。あ、これは仕事でも結構当てはまるかも。

抽象化の功罪 - 実装の問題

　何のために抽象化、モデル化するかというと、ごちゃごちゃと複雑な現実を整理し、理解し易く、設計・開発・保守し易く、また再利用しやすくするためである。コンピュータ通信の分野で言うと、レイヤ化がその一例である。

　レイヤ化モデルで代表的なものはOSIの7階層モデルであろう。ここで書くまでもないが、同一ノード間では、あるレイヤnはn+1レイヤおよびn-1レイヤのみとインタラクションし、対向ノードとは同じレイヤ同士のみ(peer)がコミュニケーションする。下位レイヤはカプセル化され、上位レイヤに対して下位レイヤの機能は隠ぺいされる。整然としているが、実際には、今日OSIモデルのサブセットが断片的に使用されているだけで、そのフルスタックの実装が普及したことはなかった。必要以上に機能分化され、必要以上にオーヴァヘッドが大きいためだと思う。

　TCP/IPプロトコルスタックも、一応はレイヤモデルに基づくが、理論後付け的なところがあり、あまり整然とした階層にはなっていない。例えば、IP（ネットワーク層）を補完する機能としてARPやICMPがあるが、ARPはEthernet専用の機能でEthernet Frameを使用する一方、ICMPはIPにカプセル化される、等、図に書いてもきれいなレイヤ構造にならない。（rfc3439では、"Layering Considered Harmful"とさえ言ってる:)）トップダウンで設計されたOSIと、時とともに漸次進化してきたTCP/IPの違いである。

　レイヤによる抽象化は、モジュール化に加えて相対化という側面を持つので、いろいろ面白いことが起こる。ある問題を解決したつもりになっていても、実は、単に新たなレイヤを追加しただけだったり、他のレイヤの問題を増やしただけだったり。“Any problem in computer science can be solved with another layer of indirection.” “But that usually will create another problem.”という箴言もある。（これを言ったのは誰か、というのは、どうも諸説あるらしい。David Wheelerだと思っていたが、WikipediaによるとButler Lampsonと書いてあった。 )

　ところで、IPv6では、OSIモデルのような必要以上の機能分化は行わず、しかしIPv4の時よりは、もう少し整然とした抽象化を行おうとした。まず、ARPやIGMPに相当するIPレイヤを補完する機能(Neighbor DiscoveryやMLD)を、ICMPの拡張メッセージとして統合し、また、ヘッダを階層化した。前者は、「ICMPへの統合によるメディア非依存」、という抽象化であり、後者は、「再帰」による抽象化である。

　これは結構素敵である。IPv4の時よりもすっきり整然とするとともに、OSIよりも実践的だし、実際のプロトコルスタック実装にも適性が高い。

　しかし、しかし。特にハードウェアに近くなればなるほど、やはり実装と抽象化は相容れにくくなる。

　まずメディア非依存。Neighbor Discoveryに関するメカニズムは実際はメディア種別に依存するが、rfc4861(IPv6 Neighbor Discovery)は、メディア非依存であらゆるリンク属性｛point-to-point, multicast, NBMA, shared media}を対象とする。属性によって適用するメカニズムを取捨選択することになるのだが、これは実装に任されるところになる。point-to-point linkではNS/NA(Neighbor Solicitation, Neighbor Advertisement)は行わない。ではDAD(Duplicate Address Detection)はどうか。これもpoint-to-pointでは無くてもよいのではと思うが、rfc4862(IPv6 Stateless Address Configuration)では、特にlink種別の記述はない。また、subnet-router anycast address(interface-id = 0)も、point-to-pointに必要とは思えないが(shared linkであっても使ってないのでは）、rfc4291(IPv6 Addressing Architecture)は、実際のinterface-id生成アルゴリズムについてリンク依存性(EUI64など)を言及しているに留まる。

　そして再帰。Fragment処理に関しては、エンドに委ねたのはよいと思う。ただ、ヘッダ階層化による柔軟性・拡張性は、ついそれを有効利用したくなってしまうというところが悩ましい。Routing Header 0 は廃止されたが、1(Nimrod), 2(MobileIP)は残っており、これからも追加される可能性がある。再帰処理によるオーヴァヘッドやリスクと、得られる効用をよく見極めたい。

　一番悩ましいのは、これらがセキュリティホールになることだ。pingpong問題(*)は、point-to-point linkではNS/NAが行われず、同一サブネット上のアドレスで自身のアドレス以外のものは着信したインタフェースへと送り返す動作に起因する。さらにsubnet長を一律/64にするというガイドラインもあるため、リスクの確率が大きくなる。

(*)
http://atm.tut.fi/list-archive/ipng/msg00163.html
http://www.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf

　/127が使えればこの問題を防げるが、rfc3627(Use of /127 Prefix Length Between Routers Considered Harmful)にDADやAddressingとの不整合が記述されている。但し、ここに記述されている点は、point-to-point linkには適用外だと思う。下位メディアは、概念としては抽象化されていても、現実の実装の際はl属性を個別に考えた方が良い。

　rfc4443(ICMP for IPv6)には、このpingpong問題を回避するためのソリューションが記述されているが、これもハードウェアフォワーディングにとってはかなりハードルが高い。抽象化のためにパフォーマンスを劣化させるのはあまりぱっとしない。

　Routing Headerのセキュリティリスクについては言うまでもない。itojunさんのことが思い出され、今も胸が痛む。抽象化と実装が背反するような場合があれば、私だったら実装面を優先させるだろう。たぶんitojunさんも賛成してくれるのではないだろうか。

チェロの修行 (5) - 毎日3時間は必要！

年の瀬も迫った先日の日曜日、仕事はある程度落ち着いており、合奏の練習もなく、夫と子供たちは出かけ、溜まった家事や雑用は年末休暇を当てに先延ばし...。本当に珍しく、まとまった時間が取れた。

ゆっくり時間をかけてチューニングし、サポージニコフ（初歩の教本）からいくつか取り出して、左手のポジションと指の間隔、右手の弓の返し・移弦等、基本の「き」を覚醒させる。校閲の井上頼豊先生が脚注で仰ってることは奥が深いと、改めて感じ入る。その後スケールを軽く弾いてから、今持っている曲を、細かく、じっくりレヴューする。１～２小節弾いては立ち戻り、右手と左手を分けてさらってみる。うまくいってない部分は、問題点と原因を分析しながら、何度も何度も、改善が見えるまで繰り返す。こうしてさらうと、練習の甲斐があるというもの。少しずつ調子がよくなってくる。

....はっと気がついて時計を見ると、これだけで二時間半経っていた。そろそろ食事の支度をしなくちゃ。あー、でもまだエチュードやってない。曲もとても最後まで行ってない。

やっぱり、向上するためには、このような練習を毎日する必要がある。2時間半では足りない。どんなに最低でも3時間は必要だ。本当は5～6時間欲しい。そうでなくては、「ただ弾いている」という状況から脱却できない。

しかし今は、平日は朝10分の時間を捻出するのが精一杯だし、週末は合奏の練習があったり、子供関連の用事があったり、仕事を持ち帰っていたり、と、時間が絶対的に不足している！！これでも結構ぎりぎりの生活で、これ以上睡眠時間を削ることはできない。どうやったら時間を作れるのだろうか。仕事の方も、これからますます基本的な価値が問われる時代に突入する。当然手を抜く訳にはいかない。どうしたらよいのだ？！

3時間を捻出するのは今すぐは無理としても、これを機にさらい方を変えよう。譜読みや曲の構成等のレヴューは通勤時間等に行い、楽器を触われる時間は、わずかな時間であっても、徹底的に、基礎に集中することにする。

知ってない問題 (3)

「知ってない問題」とは、「知ってる？」の否定応答が、なぜ「知ってない」ではなくて「知らない」になるのでしょう、という問題。依然としてすっきりしないままでいる。

英語(know)やフランス語(savoir)では、このような非対称は無い、と、前のエントリーには書いた。しかし、それら言語では、状態を表す動詞（have, love, liveなど）と、行為(go, play, takeなど）を表す動詞が、同じ一般動詞として存在しているため、「○○ている」というように、状態を表す時に語尾を変化させる日本語とは異なり、同列に比較はできない。「知識を得るだけでは知ったことにはならないのではないか。」というのは、仮説としては悪くないとは思うが、ちょっと無理があるかもしれない。

日本語では、状態を表す時には、「○○ている」になるので、「知っている」状態を否定するのは、普通に考えたら、やはり「知っていない」が自然であろう。実際、言葉を覚え始めたばかりの子供はこう答える。しかし大人は「知らない」と言う。この質問と応答の非対称性は、単なる偶発的なものではなく、やはり「知る」ということが特別であることを示しているのではないか。従って、この点に関しては、前のエントリーでの仮説（↓)はあながち外れていないように思える。

「ｘｘを知っている？」と質問された人は、質問されたという事実により、そのことに関する知識を得てしまった、ということになる。そのため、常識を持った 大人であれば、質問を受けた途端、そのことについて「知っていない」とはパラドクスになり、そうは言えなくなってしまうのではないか。だから、「そのこと は過去も知らなかったし、こんな風に質問されなければ、これからもたぶん知らなかっただろう」という意味をこめて、「知らない」と答えるのではないだろう か。

しかし勿論、根拠にも確信にも欠ける。

......という訳で、悶々としていたところ、養老孟司先生の著作に、やはり「知る」ということの特別さを記述した文章を発見。

「知ることの深層」

知ることとは、どういうことか。（中略）
一般的に、知ることというのは、知識を増やすことと考えられています。しかしもちろんそうではありません。私はよく学生に、自分が癌の告知をされたときのことを考えてみなさいといいます。「あなた癌ですよ」といわれるのも、本人にしてみれば「知る」ことです。「あなた癌ですよ。せいぜいもって半年です」といわれたときにどうか。知るということを考えるとはそういうことです。
あと半年と宣告されて、それを納得した瞬間から、自分が変わります。ですから、知ることというのは、じつは自分が変わることだと私は思うわけです。

　　　　　　　-　「知」の毒　自分は死なないと思っている人へ　大和書房　より

やっぱり。我意を得たり、という気がする。知ることは、単に知識を増やすことではない。知る前と知った後で自分が変わるということもあり得るのだ。勿論、「知ってない」問題への十分な根拠や確信にはなる訳ではないけれども、「知る」ということは、やはり特別で重大なことなのだと思う。

インターネットと、エリザベス キューブラー=ロス "On Death and Dying"

一時期、「生きるって何のため？」、「死とは何？」、ということを考えあぐねていた時があって、死に行く人の闘病記や医師の手記、そしてアルフォンス デーケンやエリザベス キューブラー=ロスの、死生学に関する本を読み漁っていた。中でも、スイスの精神科医キューブラー=ロス著「死ぬ瞬間」は世界的にも著名な書で、200人の余命宣告された患者とのインタヴューによって導かれた死の受容に至る5段階のモデルは、それまで思い至らなかった捉え方であったため非常に印象的だった。（ところで、この書をなぜ「死ぬ瞬間」と訳したのかよくわからない。"瞬間"ではなくて"プロセス"だと思う。なので、タイトルには邦題ではなく原題"On Death and Dying"を載せておく。）

その5段階のモデルとは次のとおり。

[Stage 1: Denial (否認）]
　予期せぬ事態、衝撃を直視できず、「そんな筈はない」と否定する。

[Stage 2: Anger (怒り）]
　なぜ私が？理不尽だ。怒り。不満。

[Stage 3: Bargaining (取引）]
　生活を改めるから生かして欲しい。せめて○○までは生きたい。

[Stage 4: Depression (抑うつ）]
　あきらめ。無気力。落ち込み。

[Stage 5: Acceptence (受容）]
　解脱。穏やかな心境になり、自らの死を受け入れる。

私の方は、そのうち子供が生まれたりして、目前の生を育てる（というよりは活かしておく）のに精一杯になり、この本のことは記憶の底に深く沈んでいた。

...それなのに、最近、なぜか仕事関係で、このキューブラー=ロスの5段階モデルが言及されているのを相次いで発見して、ちょっと面喰っている。

●例その1　- 「製品に脆弱性が発見された時！！」

James Duncanの資料より。

[Stage 1: Denial (否認）]
　「それはセキュリティホールではない。機能仕様だ。」

[Stage 2: Anger (怒り）]
　「一体誰がそんなこと言い出したんだ。いい迷惑だ。」

[Stage 3: Bargaining (取引）]
　「条件を変えれば脆弱性は無いのでは？」

[Stage 4: Depression (抑うつ）]
　あきらめ。無気力。落ち込み。

[Stage 5: Acceptence (受容）]
　解脱。正しい手を打ち、また将来同じことのないように備える。

●例その2　- 「IPｖ6の受容 」

Tony Hainの資料より。

[Stage 1: Denial (否認）]
　「IPv6なんて来ないだろう。」

[Stage 2: Anger (怒り）]
　「ひどい。そんなの聞いてないよ。」

[Stage 3: Bargaining (取引）]
　「せめて自分が引退するまではこのままで...。」「NATがある。」

[Stage 4: Depression (抑うつ）]
　「NATだと、いくつかのアプリケーションが正常に動作しなくなる。仕方ないか...。」

[Stage 5: Acceptence (受容）]
　「IPv6をdeployしよう！」

うーん、何だか笑えるような笑えないような......。しかし、元のコンテクストは「生命体による死の受容」ですよ。こちらはお仕事の話。お仕事の場合、通常であれば、まぁかなり理不尽であっても、かなり困難であっても、それが重要なのであれば、只管やるのである。「仕様追加がどうしても必要だ。でも納期は変えられない。よろしく。」などという事態になった時、ぶーぶー文句を言いながらも、やってきたではないか。

このような事態に、キューブラー=ロスが引用される、ということは何を意味するか。

これらのセキュリティ脆弱性やIPv6移行問題が、「死」に匹敵するような、致命的な困難さを持っている、ということなのだろうか。それとも、システムが多くの要素と有機的に連携し過ぎていて、生命体と同様になっている、ということなのだろうか。いや両方なのだろう。勿論、多少の誇張と冗談が交じっているにせよ、「生命体（のようなもの）に対する死（と同じくらいの困難）」が、最近は起こっている、ということか。

具象と抽象と

　算数は主に具象的なものを扱う。数学は主に抽象的なものを扱う。そんなことを再認識した。

　現在小学校5年生の娘が、ひょんなことから、もしかすると中学を受験するかもしれないことになった。私は学問に関しては本人の自覚に任せてよいと思っていたので（音楽は別）、これまで勉強は放任してきた。今からでも間に合うのか。かなりヤバいかも。

　取敢えず過去の入試問題でも見てみよう、と問題集のページをめくると、やはり結構手強そう。最初の計算問題が、問題用紙の横一杯に長い。今まで塾にも行ったことがなくて、分数の加減乗除もまだやっていないという、超原始的な娘にどうやって教えればよいのか。

　ひとつひとつ教えて行くしかない。しかし、変なところで躓く。例えば、 A-□=B のような形になって、Aを両辺からひいて -□=B-A にする、というところで、どうも納得できない様子。娘　「この一番左の"-"は何？！」　私「へ？何ってマイナスだよ。」　娘「？？？」。そうか。これまでは"-"というのは「何かから何かをひく」というアクションを表す演算子として理解していたので、被演算対象が無くなってしまうと混乱するのだ。さてこれをどう教えるか。１）数直線を書き、0を境に、「左側はマイナスの世界、右側はプラスの世界。マイナスの世界の数字には、数字の前に符号"-"が付く」、と教える。２）"-"のつく数字は、「ある数字に"-1"をかけたもの」、という、単項演算子として教える。1)は算数の領域、2)は数学の領域だろうか。でも、両方必要。

　抽象的な操作に慣れてしまっていると、却って具象は難しい。うっかり娘に、「だから移項して」とか言ってしまって、顰蹙を買った。移項は操作法であり本質ではない。「お母さんは教え方が下手だ。」と言われる。まったくだ。ごめんなさい。「何で、掛け算割り算を先にやって、足し算引き算は後なの？」という根本的な質問にもたじろぐ。「掛け算割り算は同じ項としてまとめられるけど、足し算引き算は別物なんだ。」「項って何？」「うーん、塊みたいなものかな...」とか言ってみるが、何だか全然説明になっていない。

　でも、このように改めて根源的なことを考えるのは、結構面白い。以下雑感。

• 　抽象的な思考、操作は、生産性を飛躍的に向上させる。

• 　しかし抽象化したレヴェルで閉じてしまうのはよくない。具象的なものとの相互作用や関連付けが必要。

• 　具象と抽象は、現実と仮想に通じるのかも。

　

NAT....

　最近は各所でv4アドレススペース枯渇対策としてのNAT論議がかまびすしい。今週のDublinでのIETF72でも、 v6ops, softwires, behaveの各WG、Internet Area open meetingに加え、Technical Plenaryでも大きく取り上げられた。その中でも重要なポジションを担っているのが、われらが宮川隊長率いる、日本勢である。

　World WideのInternet Communityにおいて、日本勢と言えば（と一般化するのは抵抗かあるが、ここでは本質ではないので置いておく）、熱心なIPv6を推進者と知られている。そしてそのIPv6の、アドレススペース拡張に次ぐ利点は「NAT不要」ということだ。その日本勢が今はNATを推進しているのだから、目を丸くしている人も多いのではないかと思う。"What an irony"、という言葉もちらほら聞いた。

　この背後にあるのは、理想は理想として一旦おいておき、乗り越えなくてはならない現実の問題を、着実に乗り越えよう、という、プラグマティズムと「八百万の神」的精神だろうか。そういえば、本社のエンジニアを交えミーティングしていた時、その米国人がある文脈で"God knows"と言ったら、宮川さんは"No. Nobody knows"と言った。私は、「いずれにせよ誰にもわからないっていうことだから同じじゃない」と茶化したが、実は言わんとされていることは少しわかる。キリスト教的決定論と、仏教的色即是空の違いだ。

　Plenaryでは、かつてIAB席に座っていたitojunさんの事が思い出されて、涙が出た。とにかく考えることべきことは山ほどある。この変遷の時代を、愉しみながら、乗り越えたい。

　....ところで、そのNATにはあまり関係ないが、私は結婚後も旧姓を通称使用している。これがprivateなIDが公的な場に出る時にpublicなIDに変換される、という意味において、何だかNATに似ている。ホテルや飛行機にはパスポート名でチェックインするため、仕事の関係で、誰かが私をホテルから呼び出そうとしても、「そんな人はいません」と言われるだろう(hole punching不能）。予め連絡が来そうなことがわかっている時は、チェックインする時に、通称名も登録してもらう（static destination NAT）。

　おかげで、私が何をしでかそうと、夫（守備範囲は違うが業界は少しオーヴァラップしているため、仕事上の共通の知人もいる）や子供に迷惑がかかることはほぼ無いであろう、という安心感がある。姓が違うためトラックされにくいのだ。（しかし、あまり無防備に慣れきっていてはいけない。気をつけましょう。これで急にIPv6でNAT無しになったら、心して、privacy保護に留意しなくてはならない。）

　仕事のときに加え、音楽・演奏のときも、public name（旧姓）を使っている。音楽は、私にとっては私的領域を超えているし、仕事仲間と共演することもあるので、この方がよいと判断した。ただ、先日娘のヴァイオリンの発表会で、私は講師演奏と娘の伴奏という立場で出演したときに、親子なのに姓が違うことになり、ちょっと居心地の悪い思いをした。local折り返しのときはprivate spaceのままにすればよいのかもしれないけれど、何を以ってlocalとするかが結構難しくて...。

　って何の話をしているのでしょう。失礼いたしました。

子供が言語を習得する過程 (3)

　どうも子供は自分で考えて言葉を使って（作って/活用させて）いる。そしてそれには、それなりの立派な理屈がある。それを、少しずつ、常識や社会通念に合わせて適応して行くのだろうが、フツウになって行ってしまうのは、寂しい感じもする。小さい頭で一生懸命考えて、紡ぎ出した言葉というのは、何とも愛おしい。

　最近のおもしろかったネタ二つ。

• 　「おみやげ返して」

　先週IETFで一週間出張し、帰宅した時に何度も言われた言葉である。いや、いつも出張から帰るなり、まとわりつかれて、「おみやげは？」「おみやげちょうだい」と言われるのだが、「おみやげ返して」、と言われたのは初めてだ。

　大体、今の子供にとって、モノは溢れているし、食べ物だって大抵のものは日本でも手に入るどころか、日本の食べ物の方がおいしい場合が多い。おみやげなんてあまり欲しがるとは思えない。それなのに、出張の度に必ずおみやげをねだられるのは何故かと思っていたが、「おみやげ返して」と言われ、はっと気がついた。「一週間も寂しい思いをしていたんだからね。それを償ってください。」ということか。

　そういえば、英語で給与等のことを"compensation"と言う。"compensate"は、償うとか埋め合わせるとか言う意味で、初めて外資系企業のofferにsign upしたとき、不思議な感じがしたものだが、時間と労力をかけて仕事をするので、それに対する償い、ということなのだろう。子供の言う、「返して」、という感じに少し近い。

　という訳で、非常に愛おしかったので、いつもは子供を寝かせてからがお仕事タイムなのだが、その日は「一緒に寝よう」と言って、一緒に布団に入った。（が、私が即、先に眠ってしまい、全く意味が無かった。）

• 「あっ、知った！」

　宿題をやっていた時、「うーん」と思いを巡らせ、はっと気がついた時に発した言葉である。「知ってる？」に対して、「知ってない」と答えていた娘なので、こちらももう驚かない。「わかる」と「知る」の区別があまりついていないのだろう、と思う。

　しかし、よく考えてみると、「わかる」と「知る」の違いって何だろう。問題は「わかる」で、事実は「知る」、だろうか。「わかる」は「解かる」だから、自分で考えて解決に至ったときには「わかった!」となる。でも、たまたまその時ちょっと思い出せなくて、それをぱっと思い出したときは、「わかった」とは言わない。大人だったらこのような時、「思い出した!」と言うのであろうが、それを「知った!」と言ってしまったのだろうか。

　でも、英語だったら、"Ah..., now I know it !" と言ってもおかしくないような感じもする。「知る」という動詞は、本当によくわからない。行為を表すのか、状態を表すのかも曖昧だ。愈々以って、"Que sais-je ?"（我何をか知る）。

すべてのものは疑わしい

　考えていることは山積みなのだが、なかなか文章にできない。今までの言動も、単なる思い付き、わかったような気になっていただけ、という気がする。何かを掴んだような気になっても、次の瞬間には、打ち消す考えが生まれてくる。さらに、単なる思考の堂々巡りで、何も前に進めていないことに対して自己嫌悪に陥る。Blogさえも書けない。

　一つだけ腑に落ちたことがある。できるだけ事象を正確に認識しようとすると、すべてのものを一旦は懐疑すべきであるが、「すべてのものは疑わしい」という命題は、それ自体が疑わしいということになり、成立し得ない。自分も懐疑の対象にしなくてはならない。

　ウィトゲンシュタインは言った。「語りえぬものについては、沈黙せねばならない。」

　苦しいけれど、もう少しこの状況で格闘してみるつもり。

ランダム性を愉しむ

　次女のパジャマ姿は非常に情けない。寝相が悪いのでかぶりタイプのものにしているが、裏返しだったり、うしろまえだったり、まともに着ているためしがない。「だらしないなぁ。何でそうなの？」と言うと、「誰に見られる訳でもないからね。いいでしょ。」　いやいやそういうことではなくて。

　よくよく訊くと、脱いだ時にくしゃくしゃとしまうが、それをそのまま取り出して、一番手間のかからないようにして着るようにしているそうだ。だから脱いだときに裏返しになってしまえばそのまま着る。取り出した時にうしろまえになっていてもそのまま着る。ははぁ、さようでございますか。しかし、いつもいつもまともではない、というのはどういうことだ。

　すると長女が、「でも、裏表と後ろ前があるから、確率は4分の１だよ。」とぼそっと言う。おおお、そう来るか。すばらしいぞ。「いや、シャツだけでなくズボンもあるからね。すべてがまともに揃う確率はいくつになるかな。」...嬉しくなってつい乗る私。「4分の１と4分の１だから...、8分の2かな。」とアホをかます次女。「16分の１」さすが長女。

　そう。16分の１。だから一か月のうちに２回もまともにはならない訳だね。親としては本当は、だらしなさを諭さないといけないのだろうが、「お、今日は上は合っているのに、ズボンが後ろ前だね。」とか、すっかり愉しんでいる。このランダム性、コンピュータでつくりだすのはすごい難しいんだよ。さらに、ランダムであるということを証明する方法はないんだ。...と蘊蓄をたれようとすると、アホ娘たちはこぞってどこかに走り去ってしまった。

落し物が戻ってくる国 － ニッポン

　自慢ではないが、ADHD（注意欠陥多動障害）気味の私は、よく物を落とす。特に、手荷物が３個以上になると、何かしら落し物をする確率が非常に高い。だから荷物の多いときはかなり自分自身に気合いを入れて、頭の中に点呼リストを作り、出発の時、乗り換えの時に、チェックをするようにしなくてはならない。しかし、ついついボーッとしてしまうとダメだ。仕事でもそうで、あることに集中すると他のことが*全く*見えなくなるので（幼児か）、プライオリティ順位を付けたTo Do Listを、目に入るところにおいておかなくてはならない。

　先日の日曜日は朝から雪で、楽器（チェロ）と、譜面台と、譜面やMDや何やらを突っ込んだトートバッグと、傘を持って出なくてはならなかった。この時点でかなりヤバイ。午前中はピアニストの友人とピアノ合わせ、午後は弦楽合奏の練習だった。一つの外出で用事が二つ、というのは、情報処理が複雑になり、さらにヤバい状況に拍車をかける。さらに、そのピアニストの友人は、本職はピアノの先生なのだが、パンづくりが趣味で、時々手作りパンを作って来てくれる。（この友人の手づくりパン、本当においしい。子供達も夫もあまりに感動して食べるので、私も、と、パンづくりの本を買ってきたものの、挫折している...。）この日は、くるみ入りフランスパンを戴いた。

　という訳で、楽器、譜面台、傘、トートバッグ、そして、戴いたパンの入った紙袋を持ち、電車を乗り換えて、弦楽合奏の練習場に向かう。気合いも少し薄れてきて、さらに、弦楽合奏の練習に初めて参加するメンバーと駅で待ち合わせをする、という、新たなタスクも加わり、もうヤバ過ぎる状況。やはり、案の定、着いたら譜面台が無かった！電車の中に置いてきたのだった。

　譜面台で済んだのをよしとすべきだろうが、その譜面台は超軽量で、ケースにチェロの形の七宝焼きのブローチを付けてあって、とても愛着があった。藁にもすがる思いで、JR落し物センターに電話すると....、見つかった！！どなたかが届けて下さったのだ。

　実際これまで何度となく落し物をしているが、かなりの高い確率で戻ってくる。多少金目のものであっても、だ。こんなこと、外国では考えられないのではないか。例えば、きちんとしたホテル内であっても置き引きやスリが横行する。注意散漫な人間などいいカモである。外国にいる時は、常に緊張し、気合いを入れまくらないといけない。

　日本という国、国民性、社会については、日頃いろいろ言いたいこともあるが、すばらしいところもあるなー。感動。無論「衣食足りて礼節を知る」であるが、落し物は届ける、という奥ゆかしいDNAが、広く行き渡っているのだろう。そういえば、幼少のころ、５円や１０円玉を拾って交番に届けると、お巡りさんが「エラかったね」、と頭をなでてくれて、お駄賃に飴を貰ったりした経験がないだろうか。こうやってDNAを育んで行く。勿論、不注意な落し物は、しないにこしたことはないのですが。

　ちなみに、JR東日本の落し物センターは、下記URLをご参照。

http://www.jreast.co.jp/info/wasuremono.html

http://www.jreast.co.jp/press/2003_1/20030601.pdf

　落し物が全てデータベース化されているので、電話一本で検索してもらえる。ありがたいことだ。但し、今回の場合は、3回目のトライでやっと見つかった。譜面台というカテゴリーが無かったのか、何をキーに検索してよいかわからなかったらしい。従って、一見して分類不能なものの検索は、担当して下さるサーチャーのセンス(?!)に依存する。件の譜面台は、黒いナイロン製の細長いケースに入っていたのだが、なんと「黒いかばん」として登録されていたそうだ。

巨匠の校訂には要注意?!

　来月2月17日のおさらい会で、ハイドンのC-durコンチェルトを弾くことになった。（一応希望の曲を訊かれたので、ブラームスのOp.78（「雨の歌」...作曲者自ら編曲したと言われるチェロ版)と言ったら、やはりけんもほろろに一蹴された。バロック、古典を一通りしっかり弾いてからにしろ、ということだ。）しかしそれでも、ハイドンのチェロコンチェルトは素晴らしく奥が深い。相当なテクニックも要求されるので、それをどの程度きちんと正確に弾けるか。そしてその上で、光を放つような音色が出せるか。

　楽譜は、メジャーなのはHenleの原典版とInternational版だと思うが、Internationa版にも、Milos Sadlo校訂のものと、Milos Sadloを基にしたRostropovich校訂版の2つがあり、私が持っているのはRostropovich版である。ロストロ先生のフィンガリングとボウイングは、「おおお、そうくるのか」というのが非常に多い。弓先での逆弓。低いポジションと高いポジションとのシフトの多用。親指のポジションでも、並行移動ではなく、なるべく低いポジションから使わせようとするし、フレーズ内でのポジション移動も辞さない。極めつけは、三楽章の206-207小節でのA線でGを弾きながらD線でメロディを弾くところ、何とA線のアーティキュレーションとD線のアーティキュレーションが違う。これはいくらなんでも不可能だ。でも気持はわかる。違うパートなのだから。

　でもせっかくのロストロ先生の指示なので、できるだけそれでさらって持っていったら、師匠に「こんなのロストロだからできる弓さばき・フィンガリングで、普通は無理。サマにならない。」とあっさり言われて、結局、オーソドックスなMilos Sadlo版に殆ど戻された。えーん。せっかく正月休み返上でさらったのに。弾きにくいかなぁ、と思いながらも、一旦はこれで暗譜してしまったので、これから修正するのが大変。しくしくしく。

　という訳で、巨匠による校訂（ボウイング・フィンガリング）には要注意だ。巨匠だから、という訳ではないが、後進を育てるような目線で校訂する場合もあれば、「自分だったらこう弾く。どうだすごいだろう。」という感じで校訂する場合もあるのだろう。今回のロストロ版ハイドンコンチェルトは、後者に近いかもしれない。

　あとは、カデンツァをどうするか。ロストロ先生版も、カデンツァに関しては、Milos Sadlo版をそのまま使っている。これもオーソドックスでよいのだが、以前聴いたL.Kantaのカデンツァが非常に印象深く残っている。現代的（というかジャズ的）な和声を使っていて、古典の音律に戻るときに違和感を感じるくらいなのだが、これを部分的に拝借してアレンジしようかと思っている。（ところで、他人のカデンツァを耳コピ、というのは、厳密には著作権侵害になるのだろうか。公演は当然非営利なので問題にはならない筈であるが、どうしよう。）

　本番まで一か月を切ってしまい、またその間出張もあり、さらう時間の確保が困難だが、何とか頑張ってみるつもり。決してなんとなく弾けた気になるのではなく、細部に渡って基本に忠実に、しっかり弾くことを目標にする。

インターネットのこれからを育む

　インターネットの理念の真髄は、たぶんその逆説的でリベラルなところにある。

　逆説的な例。

• End-to-End、網はビットを愚直に運べ。 <愚直の方がIntelligenceを育む。>
• Best effort, No guarantee。 <保証しないことにより障害耐性が大きくなる。>

　そしてリベラルな例。

"We reject kings, presidents and voting. We believe in rough consensus and running code. "  (我々は、君主、長、そして多数決も拒絶する。大まかな合意と動いているコードを信じるのみ。)　　　　　　　　　　--　David Clark

"Internet is for everyone - but it won't be if Government restrict access to it, so we must dedicate ourselves to keeping the network unrestricted, unfettered and unregulated. We must have the freedom to speak and the freedom to hear.  (インターネットはみんなのもの。だから政府がアクセスを制限するようなことがあってはならない。我々は、ネットワークが制限も拘束も規制も受けないように努力しないとならない。..)　                                          --  Vint Ceff/rfc3271

　しかししかし。現実はそうは言っていられなくなってきた。専門家でない一般ユーザが圧倒的多数を占め、セキュリティ脅威や迷惑メールが社会問題になっている。インフラとしての信頼性などということが問われ、国家政府も介入する。

　

　そのため、ネットワークの運用は、当初の逆説的（反体制的?!)リベラリズムから、ここ最近、大きく管理・制御の方向に舵をきったと思う。これは程度の多少はあれ、世界的な潮流のようだ。（日本は元々リベラリズムが根付いていなかったが、西欧ではそんなことはないのでは、と思うかもしれないが、とんでもない。背景も意味合いも違うのでリベラリズムという言葉の使用自体が適切でないが、彼らは、管理・制御が必要と判断すればどんどんやる。その点日本の方がナイーヴなくらいである。）実際、現在インターネットのトランスポートを運用・提供しているのは、殆どが伝統的な電話会社であるので、管理・制御の方向に向かうのはある程度自然なのかもれしれない。

　

　　

　しかし、管理・制御する、ということは、迷惑や危険からユーザや社会を「守る」方向であり、全く新しい使い方を生み出す、とか、試行錯誤や実験をさせてみる、といった「育む」方向ではない。安全を担保するのは勿論重要なことであるが、一方、革新、進化が起こりにくくなる、という面は否めない。エライ人はよく「いいとこ取りすればよい」と仰いますが、そんなに簡単ではない。

　

　　

　...とかいうことを考えていたら、IIJの浅羽さんがかねてからの構想の実現に向けて動き出した。IIJ Innovation Institute。そうだった。日本には、IIJという、インターネットの理念の大いなる擁護・具現者があった。創立15周年を迎え、次のインターネットの発展に寄与するような、新しい技術ベンチャーのインキュベーションを行うとのことだ。

　

　　

　インターネットは、その自律分散性、フラクタル性により、発展というよりは生物的に進化するようなので、もしもどんなに今が行き詰ったとしても、世代交代という方法がある。ゆずりはのような。だから、後世を育むことは非常に重要なのだと思う。

　

　　

　新たなアーキテクチャ可能性(Mobility, Gridや、その他もっととてつもないこと）を、現在のインフラの上に作ってみる、とかいうことが、より現実味を帯びてくるかもしれない。

　

チェロの修行(4) - 正念場

　今の先生についてもう6-7年になるだろうか。下の子がまだ赤ん坊の頃だ。子供が生まれてからは、とにかくチェロを弾く余裕なんて全くなくて、オーケストラも、室内楽も、一切やめていた。一年に一度もチェロケースを開けない、なんて時もあった。これでもう弾かなくなってしまうのか、と思い始めていた頃、いや細々とでもよいから続けた方がよい、と一念発起して師事した。どうせなら一からやり直すつもりで。

　レッスンのペースは、一か月に一回を何とか維持するのが精一杯であるが、基礎を叩き直すのにはよい機会だ。ソロで弾くのは、裸の自分を見せるのと一緒で、一切ごまかしがきかない。テクニックはおろか、何を考えているかまでわかってしまう。ほんとうに細々とではあるが、継続は力なり、と思ってやってきた。

　しかし、先日とうとう師匠と衝突してしまった。私には弾きたい曲が山ほどある。特に、ロマン派以降の、内面の表現の要求が高まって、それまでの予定調和や秩序を破らざるを得ない、といったような切ない音楽にとても惹かれる。ブラームス、シューマン、エルガー、ドホナーニ、リゲティ...。それに、フランス物やロシア物もやりたい。ああ、それなのに、それなのに、やりたい曲は決してやらせて貰えない。「コンチェルトならまずバロック、古典をこなしていないとだめ。全部とは言わないが、エチュードコンチェルトもやっておかないといけない。その次にサンサーンスとラロ。物事には順番というものがある。」

　平素のレッスンでも、一つのエチュードを終えるのに5、6回かかったりするので、一か月に一回のペースだと、一年にエチュードが2曲しか進まない計算だ。弓先で音がやせない、とか、移弦やシフティングで音が切れない、とか、指を軽妙に使った弓のコントロール、とか、ハイポジションの正確さとか、そういう細かいことを徹底的にやらないといけないのだが、現在取組んでいるエチュードは、和声や構成も、要求されるテクニックも一見非常にシンプルなので、一回さらってしまうと、どうも気が乗らない。ついついいい加減になってその後の深堀をしなくなる。それでいつまでたっても先に進まない。

　これでは、生きているうちに、弾きたい曲は弾けないではないか。もっとモチヴェーションを駆り立てるようなエチュードや曲をやらせて戴けないものだろうか。弾きたい曲が弾けなくてチェロを弾く意味があるのだろうか。今のままではさらう意欲が湧かない。さらう意欲ががなければ進歩もない。大体さらう時間を捻出するのだってすごい大変なのだ。...今まで溜まっていたものも何だかこみあげてきてしまって、もう恥も外聞もなく、半泣きで訴えた。

　「でもあなたはチェロの勉強をしに来ているんでしょう。曲の選り好みをする立場ではない。曲の選り好みをするなんて、それではアマチュアではないか。」

　....いや、私アマチュアなんですけれども...、ってそういうことではない。確かに、勉強する、ということに妥協はない。プロもアマチュアもなく、求道であり修行である。そして先生は、私のような者にでも、一切妥協せずに対峙して下さっている。私はチェロの修行などといいながらも、実は修行ではなく道楽をしようとしていたのか。高みを目指すのであれば、これまでの甘い考え方を立て直さなくてはならない。

　正直言って苦しい。でもこれが現実だ。

　いつか必ず、シューマンのコンチェルトを立派に弾けるようになることを目標に、基礎を積み重ねて行こう。次に貰える曲はたぶんエチュードコンチェルト、またはハイドンの一番だろうか。いずれにせよ、心を入れ替えて頑張ってみる。

IW2007 - future routing

　先週のIW2007で、次世代ルーティングというセッションを担当させて戴いた。今回は、慶應大学の湧川さんという、Mobile Architectureの分野での第一人者とご一緒させて戴き、大いに勉強になった。プログラム委員の江崎先生、浜田さん、向井さんに、感謝したい。

　しかし、「次世代～」というお題を戴いたものの、私の問題意識は、次世代以前に、そもそも「インターネットはトランジションできるのか」、というところにあった。

　インターネットは、self-similarな自律分散システムであり、「設計し構築する」、という建築物とは違い、その進化発展や振る舞いはむしろ生物のようなものに近い。自然の生物であれば、望む望まないに関わらず、寿命があり世代交代が行われるが、そこは人工物であるため、一からやり直す、ということがしにくい。しかも、当初そんなつもりもなかったのに(?!)、社会インフラなるものになってしまったため、何か新しいことへのチャレンジも失敗も許されないような雰囲気。一方、ビジネスインセンティヴが無ければ投資できない、という現実もある。（本当に社会インフラなら、市場原理とは相容れないのではないか、という気もするが、それはそれ、なのか。）さらに、Global規模で全て繋がっているからこそのインターネットであるから、例えば、ある一組織の判断や行動で何かを推進することもできない。

　では、インターネットにトランジションは必要なのか。...このところずっと考えていたが、Yesだと思う。ディジタル情報社会に由来する現在の問題（セキュリティ、著作権、匿名性による諸問題、等等）はひとまずおいておいたとしても、物理的な資源問題というものがある。IPv4アドレススペースは最たる例であるし、もしIPv6に移行できたとしても（これさえも非常に難しいのに）、ルーティングスケーラビリティの問題は残る。勿論、これまでも、半導体集積度や光技術は、ブレークスルーを繰り返してきたし、これからも期待するが、ある程度トランジションできるしくみをインターネットにBuild-inできない限りは、今後、環境が様々に変化する中、永きに渡って続く進化発展は見込めないことになる。また、新しい技術可能性というのは（良し悪しは別として）、最初は一部の人だけに見えていて、他の殆どの人には見えない。皆が合意して一斉に移行、というのは起こりにくい。

　現在の、IRTF/RRGを中心としたルーティングアーキテクチャ再考議論で主に取り上げられているのは、IPアドレスが持つ２つの意味 - Locator（位置を特定するもの）とID（エンドシステムを特定するID） - を分離しよう、というもの。この分離により、コアネットワークはLocatorのみをcarryしていればよいので、コアにおけるRIB/FIBエントリー数を削減することが可能になる。しかしこのためには、分離したLocator/IDのマッピング/バインディングのしくみ、およびマッピング情報の伝達のためのしくみ、そしてencapのためのトンネリングが必要になる。技術的懸念として、マッピングが変わった時のコンヴァージェンス時間、トンネリングのためのオーヴァヘッド、ボトルネックがあるが、それ以前に、このままではdeploy可能性が無いような気がする。何といっても、コスト対効用が、IPv6よりもさらに不明確である。移行のmotivationを見出すのも容易ではない。

　ところで、このLocator/ID分離によるアーキテクチャは、HA(Home Agent)が、Home AddressとCoA(Care of address)のバインディング情報に基づき、Tunnelを生成する、Mobility Architectureと符合する。さらに、これは今回湧川さんにご教示戴いたのだが、HAのsingle point of failureやperformance bottleneckを防ぐため、BGP anycastによるHAの分散や、CoAの複数経路化(multipath!)も考慮されているとのことだ。さらにさらに、これらMobilityのためのルーティング情報を、IXを介して相互交換することも、実験段階ではあるが、行われつつある。こうなると、Mobilityを実現するための構造は、現在のインターネットとは別プレーンとして考えた方が考えやすい。

　IRTF/RRGにおけるLocator/ID分離も、要するに現在のインターネットを階層化することにより、スケールさせようとするものだ。それなら、こちらも、新たにできる階層を、現在のインターネットとは別プレーンとして考えると考えやすい。プレーンを分けておいて、下部構造は極力意識しなくて済むようにしておけば、共存や移行がある程度現実味を帯びる。"map and encap"を自己完結的に解決しようとするから、コスト対効用とか、移行が問題になるのではないか。

　「やはりオーヴァレイなのか。」これが、今回のセッションのWrapupでコメントを求められて発した言葉。オーヴァレイなんて、もうずいぶん前から注目を浴びているし、我ながら陳腐かつ身も蓋もないコメント、と思ったけれど、強く感じたのがこれなので仕方がない。

　そういえば、「Testbedとしてのオーヴァレイ」とかいう言葉を聞くけれども、ああ、そういうことなのか、と突如合点が行った。今のインターネットは親世代となって、子世代のいくつかの技術可能性をオーヴァレイとして育む。子世代の技術が成熟、普及すると、インフラ運用のメインプレーヤーとして世代交代する。（ここで、階層化していたものを、再度flat化する局面もある。）こうすることによって、インターネットの進化発展の可能性が開けるのかもしれない。

　次なる問題は、アナーキー的p2p(?!)と、将来性のある子世代としてのオーヴァレイを区別できるのか、区別すべきなのか、というところだろうか。

itojunさんのこと

　37歳という若さで急逝したitojunさん。潔すぎる。かっこよすぎる。でも、過ぎたるは及ばざるがごとしだ。ばか、ばか、ばか。なんで死んじゃうんだ。

　私は、itojunさんとは、少し距離をおいてきた、と思う。話が噛み合う筈がないと思っていたのだ。

　彼には強い使命感、信念のようなものが、あった。Routing Header騒動のときの昂揚そして憔悴ぶりは、凄まじく痛々しく、何度か声をかけようかと思ったが、そういう声かけ自体がspamだというので、ハラハラ見守るしかなかった。彼は「みんなのしあわせのために」と言って突き進む。でも私は、「"みんな"って誰ですか？」「"しあわせ"って何？」といちいち突っかかって考え込むタイプ。

　あとあとあと、kimyaiさんの投げかけたmixiスレでのやりとりも、なんだか涙が出る。（kimyaiさんの投げかけ自体が揮っている。そしてitojunさんが言っていることもよくわかる。正しい。彼のロジックは、ある観点からは正しすぎるのだけれども、ある観点からは肝心のところが欠落しているような気もする。）
　

　それでも、カンファレンスやIETFでお会いすると、いつもitojunさんは人懐っこい笑顔で、「どうも～」と話しかけてくれた。転職を一番喜んでくれたのは彼かもしれない。（JunOSのv6 control planeはKAMEをベースにしているので。）　v6移行の困難を問う私に、次のようなメールを下さった。

> -----Original Message-----
> From: Jun-ichiro itojun Hagino [mailto:[email protected]]
>
>  ISPとかはみんなサボる理由を考えて遅らせているだけなので(一部NTT
>  とかを除く)、いまは他のびっくりするような業種から外堀を埋める計画を
>  たてています。Juniperとどうからむかはちょっとわかんないんですが、
>  顔の広さを活用してなんとかやります。
>  メールだと長くなるんで、日本でも先にお話できれば。
>
>  どっちにせよ2010年くらいにはIPv6に行くしか選択はないので、
>  あとはこちらとしてはみんなに情報をあげておいて「早くやった方が
>  いいことあるよ」とみんなに伝えることではないかと思っています。
>  で、ギリチョンに移行するひとは値段が上がる(笑)。

-------------

　「日本でも先」に、と書いてあるのは、11月8日にSunnyvaleで本社開発ともミーティングを持つ予定にしていたのだ。それでも話が噛み合うかは自信がなく、何を前提にして何をゴールにするか、今後よい関係を築けるのか、逡巡もあった。でも、まさか亡くなってしまうなんて。

　話なんて噛み合わなくてもよいから、もっともっと、何度でも、うるさいと言われるくらい、コミュニケーションしてみればよかった。尊敬する人だからこそ、なぜ私が日々懐疑するか、一つの信念や、一つの技術への過信に危惧を感じるか、というのも、じっくり話してみたかった。もちろん、思考ばかり堂々巡りしているよりは、山ほどCodeを書き、Hackし、Commitし、RFC/I-Dを出し、という方がよいに決まっている。でも、速く進めば進もうとするほど、dullな現実とのギャップを感じ、絶望の深淵をみてしまったのではないかとも思う。

　itojunさんは、最期は何をどう感じていたのだろうか。今となっては、ただただ喪失感から抜け出せない。

習慣からの脱却

　この頃、時々公開マスタークラスを聴講する。2005年10月にはジャン=ギアン ケラス、2006年11月にスティーヴン イッサーリス、そして2007年10月には、ルイス クラレットによるマスタークラスを聴講する機会を得た。

　公開レッスン自体が自分自身の演奏に直接役立つか、というと、必ずしもそうではない。レッスンは、師の個性と受け手の個性、およびそれぞれのその時の状態に依存する、極めてlocalかつprivateなもの、という側面がある。芸事は、守→破→離→守...をサイクリックに繰り返しながら高みに登って行くので、個人がその時にどのフェーズにいるかによって、指摘することのヴェクトルが全く異なるということもあり得る。それに、守るべき基本はあれど、唯一絶対の奏法というものはない。

　だから、一般的には、個々の指導やコメントは鵜呑みにせず、十分斟酌する必要がある。しかし、しかし、である。名チェリストというのは（チェリストだけではないかもしれないけれど）、何という哲学者・求道者だろうかと心底思う。時々はっとするような金言が飛び出す。

　ルイス クラレットは、「習慣から脱却(move habit)することが必要。その習慣の良し悪しに関わらず」と言った。どんなにきれいな音が出せたとしても、それが習慣化してしまってはいけない、というのだ。勿論、きれいな音を出せることはよいのだが、それが「習慣」となると、いちいち意識しない、考えない、ということになり得る。この、「意識しない」、「考えない」で音を出すことを戒めているのだ。常に、その時の状況や、新しい考え方、新しい発見を取り入れ、数ある選択肢の中から、意識して、その音の出し方を選び取った上で、音を出す。これは結構厳しい要求である。でも、音楽だけでなく、様々なことにあてはまるのではないか。

　イッサーリスは、幾度となく「チェロを弾かないで（don't play cello）」と言った。チェロを弾くこと自体が目的になってしまってはならない、ということだ。何かを表現する、流れをつくる、響きをつくる、ということのために、チェロという楽器を使っているに過ぎない。楽器は媒体であり、弓に魂を込める。

　そして、ジャン=ギアン ケラス（何を隠そう大ファンである。この時はチェロケースにサインして貰い、しばらくボーッとしてました）は、「（音を）外してしまう自分も受け入れよう」と言った。難所のパッセージがなかなか上手く行かない時、外す→情けない→自分を責める→身体が萎縮し固くなる...、というスパイラルに陥りがちである。そんなとき、何が悪いかを考えるのでもなく、反省するのでもなく、失敗を排除しようとするのではなく、まずは「失敗してしまう自分を受け入れよう」、というのだ。ああ、何という包摂。ケラスの奏でるチェロは、飾らず、気負わず、本当に自然体の音がする。彼の哲学の現れなのだろう。

インターネットはトランジションできるか

　インターネットの良さは、「何でも取り込む」というところにあると思う。まずは包摂し、後は淘汰的フィードバックに任せる。

　しかし、「トランジションできるか」というと、これが難しい。（トランジションすべきかどうかは、ここではひとまずおくとして。）例えばIPv6。IPv4アドレススペースが足りなくなることは分かっているのに、移行できない。

　なぜか。答えは自明である。IPv6に移行するにしても、しないにしても、皆が一斉に切り替わるのは不可能である限り、NAT(NAPT, NAT-PT含む）はどのみち必要。しかし、IPv6のメリットは、NATなどという複雑なことはしなくてよい、というところにある。ここがジレンマだ。「NAT邪悪」、「網はtransparentであるべき」、というIPv6原理主義が、逆説的なことに、IPv6への移行を阻害する。

　さらに逆説的なことには、移行のために仕方なくNATの類を認めたとたん、今度は移行する必要性自体が減る。ううう、究極のジレンマ。

　

Macとの再会 - (10) C'est fini..

startmac #10

　元々かなりの筆不精で、ようやく始めた Blogも1ヶ月に1～2エントリーというペースなので、Startmacモニターをさせて戴く際の条件、－モニター期間中に10本のコラム－を全うできるか、甚だ自信がなかった。案の定、最近のエントリーはMac関連ばかりになってしまったが、しかし、ぎりぎり駆け込みで、ついにこれで10本目のエントリー！何とか約束は果たせそうだ。

　転職も重なったりしてドタバタの日々、一時はどうなることやらと思ったが、Macと再会し、Macとともに過ごした日々は、思いのほか愉しかった。モニターを終えるにあたって、印象に残ったことをまとめてみたいと思う。

　●子供たちとMac

　それまで見たことも無い、眩いばかりの真っ白いマシンを使い始めたものだから、子供たちが黙っている筈が無い。使わせて、使わせて、と、大変だった。子供たちのPCの使用は最低限にしているので、殆どの場合「ダメ」と断って来たが、ちょうど夏休みで時間の余裕があった時に、自由に使って良い日を設けたことがあった。

　二人の子供たちが気に入ったのは、GaragebandとiCartoon。何も教えていないのに、勝手にいろいろ試して遊んでいた。特にiCartoonは傑作。自分たちの表情を内蔵カメラで撮影、自分たちが主人公の簡単なストーリーを作り、4コマ漫画のような（4コマとは限らないが）ものにまとめるのだ。これが、初めて触った子供にもできるくらい、簡単にできる。出来上がったストーリーは非常にアホらしいものだが、たぶん後から見たらよい思い出になるだろう。

　ついでに、子供たちによる体験レポートを書いてもらおうと思ったが、これはボツだった。「画面の文字がきれいです。」とか、「デザインがよいと思います。」とか、通り一遍の褒め言葉ばかり。これではレヴェルの低いヤラセ記事になってしまうではないか。それにしても、子供たちというのは、自分に課されている期待役割を敏感に感じ取って行動しているのだぁ、と変なところで感慨を覚えた。今回も、体験モニターという状況をわかっていて、「良いことを書いた方がいいんだよ」とか言う。きっと日々の行動のいちいちが、学校の先生が何を期待しているか、親が何を期待しているか（親の場合は反抗して逆のことをするが）、ということに、意識的にも無意識的にも、基づいているのだろう。小さいうちは、自らの判断基準などというものはまだ無いから、当然といえば当然なのかもしれないが、何だか不憫でもある。

　●ディジタル技術と著作権法

　今回、.macにdigital libraryを作って公開しようとしたが、著作権で躓いた。しかし、このことは大いなる思索のきっかけになった。芸術とはなにか、創作とは何か、表現とは何か。

　そして、現在に見るディジタル技術とインターネットの発展は、15世紀のグーテンベルグの印刷機の発明以来(!)の、情報流通・複製方法における大変革であるという事実。ネットワーク技術と音楽・芸術との双方に関わる身として、こんなにも興味深いテーマがあるであろうか！

　という訳で、遅々とではあるが、俄然勉強し始めている。非常に良いきっかけを与えて戴いたことを、感謝している。下記は参考文献のリスト（まだ机に積んであるだけで未読のものも含む）。もう少し思索を深め、考えをまとめてみようと思う。

• 中山 信弘　「マルチメディアと著作権」　
• 岡本 薫　「著作権の考え方」　　
• 福井 健策　「著作権とは何か？文化と創造のゆくえ」　
• 名和 小太郎　「情報セキュリティ」、「ディジタル著作権」、「情報の私有・共有・公有 ユーザから見た著作権」　
• Lawrence Lessig　「Code」、「Creative Commons」　
• 白田 秀影　「インターネットの法と慣習　かなり奇妙な法学入門」
• http://www.archi-music.com/tamaki/copyright.html
• http://www.yung.jp/hp/php/tyosaku.php

　

　ところで、あまり関係ないのだけれども、先日ある大学に行ったら、講義関連掲示板に「レポートは手書きのみ許可」というメッセージを多数発見。引用もよいが、せめてコピペはやめろ、ということだろうか。うーん。:)

　●技術と人間をみつめる - 第二ラウンド

　私が技術者として駆け出しだった頃、開発環境はUnixだったし、PCはMacを使っていた。そして幾歳を経て、そして今回のMacとの再会。期せずして、初心・原点に立ち還ることになった。

　さらに、ごく最近のIT部門からのアナウンスによると、会社支給のPCに、Macも候補に入ることになった！現時点では本社Sunnyvale勤務の技術者限定であるが、様子を見ながらカヴァーエリアを拡大する方針とのことである。ここ暫く、会社が支給するPCはWindowsのみ、というのが常識であったので、これは大きなニュースだ。やはり開発エンジニアからすると、Mac OS Xの開発環境は魅力的だし、遊び心をくすぐられるのかもしれない。

　時期を同じくして職場が変わったこともあり、何だか私の職業人生も第二ラウンドに入ったような気がしている。気概を新たにして頑張りたい。

Macとの再会(9) - Mac OS Xで遊ぶ

Startmac #9

　今回思いがけずStartmacモニターの機会を与えて戴き、約10年ぶりにMac Userになったことになる。懐かしさが先に立つせいか、差異よりも、一貫した、変わらぬ開発思想のようなものに着目することが多かった。勿論、マルチメディアコンテンツ作成のためのアプリケーションの進歩はすごいと思うが、これはCPU Power、メモリ、ディスク容量、そしてネットワーク帯域幅が増したことによる恩恵が大きく、Macの目指していた方向性のようなものは、以前と変わっていないように思う。

　たぶん基本的な最大の変更はOS（とCPU...）だろう。当時のOSはSystem7.5。日本語版は漢字トーク7.5（これってOSの名前っぽくない）というものだった。ResEditなどというツールを使って多少の操作はできたけれども、何というかBlack Boxで、Inside Macintoshとかいう本を買ってみたけれども挫折。よくわからなかった。しかし今はunix、Free BSDベースのdarwinである。これは結構うれしい。

　psやtopで何がどう動いているかわかるし、suでrootにもなれる（defaultではrootになれないようになっているのでNetinfoマネージャでroot userを有効にする必要がある）。「だから？」と言われると困るのだが、これで、何があってもこわくない気がする。昔は為す術もなく、突然freezeしたり、sadmacにお目にかかったりしたものだ。あと、Apple Developer Connectionにsign inすると（無料！）、開発ツールをダウンロードできる。GCC(GNU Complier Collection)を入手し、たちまち全く申し分の無い開発環境ができた。Macで、ちょっとしたプログラムを作って動かせるなんてうれしい。起動も早くさくさく動く。仕事用のマシンも、Macの方がいいような気がしてくる。

著作権に関する追記

　いろいろな文献を読み、著作権に関することはとてつも無く複雑で難しいことがわかってきた。私が先日書いた思いは今も変わってはいないが、それは自分の主観的な問題に端を発していて、著作権問題のほんの表層の、さらにそのほんの一角しか捉えていない、ということを強く自覚したので、追記。

　著作権法では、著作物を「思想又は感情を創作的に表現したもの」と定義している。細かい突っ込みをすれば、作品には、諧謔のために作ったものもあるだろうし、純粋に商業的に作ったものもあるだろう。必ずしも、思想もしくは感情の発露とは限らないかもしれない。ジャンルも、音楽に限ってもクラシック、ポップス、演歌、ゲーム音楽等多岐にわたる。これらの異なるジャンルや異なる性質を全てひっくるめて「著作物」としして一律に扱うのは、どうにも無理があるのではないかと思う。しかし、では、分けられるのか、（分けられとして）分ければよいのか、と聞かれると、答えは無い。

　芸術的著作物は個人的・主観的なもので、経済における「市場」、学問における「理論・実証」、技術・工学における「効用」のような、明確な指標がない。ソフトウェアは少し近いと思ったが、やはり目的も異なる。そのため、作品やその権利を取り扱うのは相当に難しいし、立場や見方によって大きく意見が分かれるのは当然だろう。

　同時に、これは構造問題でもある。考え方の基礎になっているのはベルヌ条約なのだろうが、その上に、現在までに脈々と築かれた業界構造、産業構造、文化がある。レコード会社は、単に作品を流通させるだけではなく、新人を発掘し、投資（販促活動など）をし、育てる、という役割もあるのだろう。そういった構造が、ディジタル技術の進化と、個人個人の意識の変化で、変わるかもしれないし、変わらないかもしれない、というところだろうか。

　せっかく少し勉強するきっかけを得たので、関連する規範、法律、そして現在の構造の良いところ、悪いところを、自分の利害とか好悪感情をできるだけ抑えて、吟味してみたいと思う。今回、著作権に関することを調べるために、インターネットを検索してみたら、考えさせられる資料が非常に多数見つかった一方、中には、中傷の類や、事実誤認かもしれない憶測に基づく発言もあった。これはよくない。「インターネットでクリエイティヴ・コモンズとか言っているが、結局は、責任の無い言いっ放しではないか」、と言われたら反論できないではないか。自戒を込めて。