2009年11月アーカイブ

ＳＯＡなんか使えない、そんな声も聞く。ある意味でそれは正しい。なぜなら、ＳＯＡ化を成功させる要素がいくつか欠落しているからだ。ＳＯＡそのものの目的と自分たちの目標とするものが一致しているのかという根本論からはじまって、（必要最小限の）ＢＰＲの欠落、機能仕訳の甘さ・・・などなど。しかし、最も大きいのは、優良なサービス、つまりサーバサイドの部品の選択肢が少ないことだ。ＳＯＡの真価はサーバサイドの汎用化、部品化によるコストと工期の削減にある。しかも、たとえばより処理性能のいいサービスと入れ替えたとしても、フロントであるユーザインターフェイスへの影響は少ないし、ユーザにとっての使い勝手は変える必要がない。しかし、サービス、つまり、サーバ側の部品の選択肢が、少数のパッケージベンダが提供する独自仕様のサービスのみであったとしたら、苦労をしてＳＯＡ化する意味も薄れてしまう。こればかりはユーザがいくら頑張っても、解決は難しい。

ＳＯＡに至るシステムアーキテクチャの流れは、小さな湖でせき止められてしまうかに見えた。しかし、やがて、この流れも、あふれて大きな海に流れ込む。インターネットという大海にだ。そこで、他の水と混ざり合い、新たな命をはぐくむことになる。

こうして、インターネットという海は、すべてのＩＴの流れを受け止めて、大海となり、水はまた空に戻って雲となる。この雲の中には、すべての川の流れによって持ち込まれた水が混在している。いや、存在していなければならないのだと私は思う。次の章では、雲の成分について、少し詳しく考えてみよう。

（１章終り）

ソフトウエアの生産性を上げるための取り組みの流れをもう一度考え直してみよう。標準化にしても、構造化にしても、オブジェクト指向にしても、すべてプログラムの再利用もしくはもう一歩進めて汎用的な部品化を行うための考え方だと言える。このためには、似て非なる処理に共通した部分と違う部分を徹底的に洗い出し、分離することや、必要に応じて、プログラムの構造を、それに適した形に変えてやることが必要になる。

ビジネスロジックの部分でも、それは同じだ。後者がＢＰＲならば、前者はビジネスロジックの汎用化である。幹と枝葉をきちんと分離できれば、多くのビジネスロジックは共通化できる。これまでパッケージではこの作業が行われてきた。それにより、ユーザのカスタマイズ要求に対して、変更が必要な部分を局所化して、カスタマイズ作業の負荷を減らすことを目指してきたわけだ。ただ、パッケージという、ある意味で閉鎖的な環境の中では、この共通化という作業はそれ以上の意味をもたない。だから、案外、この仕分け作業は中途半端に終わってしまい、時にはユーザの要望に応じるために、本来共通化されているはずのロジックにも手をつけざるを得なくなってしまう。だから、こうした作業そのものが無意味だという極論を言う人もいるわけだが、むしろ、パッケージという閉じた世界では、無意味というよりもそれを徹底的にやるだけのメリットが、ベンダにはないのだろう。カスタマイズの余地が多いほど、そのパッケージを使ってカスタマイズする仕事が増えるからだ。つまりは、パッケージを担いでくれるＳＩ会社の仕事を増やすことにつながり、そのパッケージが好んで提案される理由となる。ユーザにとって使い勝手をよくするカスタマイズが柔軟に可能である・・・という理由が表向きの話だが。

これはベンダ目線にほかならない。ユーザ側から見れば、工期や工数を削減する目的でパッケージを選んでいるはずなのに、実際は、カスタマイズに大きな費用がかかり、工期もどんどん長くなる。ユーザから見れば、こんな馬鹿げた話はない。おまけにビジネス環境はめまぐるしく変わるのだから、それになかなか追い付いていけないＩＴは常に経営陣の悩みの種になってしまう。ユーザから見れば、最初の段階でシステムのそれぞれに機能に選択肢があり、それを組み合わせると必要なシステムが出来上がるような、いわば、システムのＢＴＯ（Build To Order）モデルがあるといいわけだ。パソコンのＢＴＯは、ＣＰＵ，メモリ容量、ＨＤＤの容量、周辺機器など、様々な仕様をユーザが指定したとおりに組み立てるものだが、必要なパーツは規格化、標準化されていて、メーカーはそれを組み合わせて組み立てるだけである。（厳密にいえば、これはＣＴＯ（Configure To Order）とも言えるが、CTOは標準製品の一部だけを別仕様に変える、もしくは選択する・・という意味のほうが強いのではないかと思うので、パッケージのカスタマイズに近い）　要するに、システムのＢＴO化が望まれるわけだが、残念ながら、情報システムのパーツは業界レベルでは標準化されておらず、ユーザにとって自由に選択できる状況には程遠い。たとえば、各パッケージベンダが自社のパッケージの一部分を標準化したいと思っても、意外と敷居が高い。記述されている言語も違えば、使っているデータベースも違う。たとえば、ユーザがＡ社の営業系パッケージとＢ社のＥＲＰパッケージの会計部分を組み合わせてシステムを作りたいと思っても、単純にそれを張り合わせることは不可能だ。こうした違いを乗り越える、新しいアーキテクチャが必要だ。

違う言語やデータベースを使って作られた「機能」をうまく連携させて使うにはどうしたらいいのか。こうした違いを超えて、互いにその機能を「呼び出せる」ようにできればいいのだが。たとえば、ネットワーク上のサービスとしてその機能が定義されていて、その呼び出しのインターフェイスも通信手順として標準化されていたなら・・・。

私の目線から見たＳＯＡ（Service Oriented Architecture）とは、このようなものだ。

（続く）

特にどこかへ行くでもなく、のんびりと過ぎた連休。最終日の今日は天気も回復して、気持ちのいい天気になった。少し朝寝してから掃除、洗濯、布団干しで午前中をつぶして、午後からちょっと横浜まで出かけてCDを2枚ほど買ってきた。

一昨日、DSi-LLを早速買い込んだのに、結局、無線LANにうまくつながらないところで頓挫、ゲームはできるのだけど、あれこれしているうちにもう、休みも終わってしまうので、お預け。

帰ってきて、ちょっと携帯の音楽ファイルの編集などをしていたらもう夕暮れ。どんどん日が短くなってる。

夕日が赤い、ということは明日はまた天気が崩れるのかな。みなとみらい方向のビルが夕日を反射して輝いてる。

昨日の薄っぺらい月は今日はもう三日月に見える。日が暮れてから見たら、木星がだいぶ月に近づいている。明日あたりには追い越すかな。またなんとなく妄想してしまいそうだけど、今日はやめておこう。絵にかけないものを想像するって結構疲れるし。でも、パラレルワールドって結構魅力的かもね。この瞬間も自分がどんどん枝分かれしてるなんて。案外、ポジティブに物事を考えていると自分が思うことが実現していくのも、無意識にそういう流れに乗っているのかもしれないな・・・と、これはちょっと哲学っぽくなるな。案外、超能力なんてのも・・・、おっとこりゃ「とあるアニメ」の見すぎかも。妙な方向にずれるまえにやめとこう。

さて、また100万年前に生まれて、8分前に太陽を旅立ったフォトンを浴びて・・・・明日からのエネルギーにかえておこうか。（笑）今週は1日短いし、出張もあるので忙しいから。

部品化はその粒度が大きくなるに従って難しくなる。様々な要素が加わって、オプションがどんどん増えていくからだ。特に、ビジネスロジックに至っては、その組織ごとに昔からの「やりかた」があり、システムは、それに合わせる形で作られてきた。

ＩＴが補助的な、つまり省力化の役割しか持たなかった時代はそれでよかっただろう。しかし、いまや、ＩＴがなければ不可能な仕事も多い・・・・、というよりＩＴをいかに使いこなすか、ということが会社の生命線にもなりつつある。

ビジネス環境の変化はどんどん加速していく。それはあくなき利潤追求という資本主義の本質と結びついている。他より効率よく、どんどん新しいことを進めていかないと会社は生き残っていけない。ＩＴはそれを支えてきたのだが、いまや、ＩＴ化をどんどん加速しなければ環境の変化についていけない主客転倒な時代になってしまったようだ。

そんな中で、システムのライフサイクルはどんどん短くなり、かかるコストもどんどん膨らむ。そんな状況下では、業務とＩＴを別々に考えているわけにはいかない。人とＩＴを含めた全体を「システム」と考えることが必要になる。これは、ＩＴを仕事にあわせることでも、仕事をＩＴにあわせることでもない。仕事全体の最も効率のよい形を考え、その中で人とＩＴの分担を決めるのだ。つまり、業務全体に対する見直し（ＢＰＲ)が必須になってくる。これは簡単ではない。ともすれば、ＩＴ屋は人の側をシステムに合わせようとする。いわゆるパッケージ文化はシステム開発は効率化しても、往々にして人にストレスをもたらす。パッケージが提供するモデルは、あくまでその業種の標準的なモデルであり、その組織によって適合度が違う。だったら業務をパッケージに合わせれば・・・と思うのがＩＴ屋のあさはかさ。業務の流れは、長年のノウハウでもある。多くの会社は漫然と同じやり方を続けてきたわけではなく、それなりに自分たちの仕事に合った形を確立させている。したがって、双方の歩み寄りは必須だ。この歩み寄りを合理的に行うために、業務全体の見直し（ＢＰＲ）が必要になるわけだ。これをきちんとしないと、結局、システムへの不満が残ったり、過剰なカスタマイズが発生したりする。

仕事のインプットとアウトプットを明確にしたうえで、その間のプロセスを細分化していくと、複数の業務で類似の作業の存在が見えてくる。これら類似の業務を「手間を増やさずに」どう共通化するかというのがポイントだと思う。共通化したことにより、作業の手間が増えてしまっては本末転倒だ。手間を減らす方向で考えられるかどうかがポイントである。

この共通作業の部分をＩＴ化して効率を上げれば、複数の業務の効率を上げられる。また、逆に、似て非なる処理を作りこむ必要もなくなり、ＩＴコストの削減にもつながる。

言うのは簡単だが、実際には難しい問題が多いのも事実。こうしたＢＰＲをコンサルタントにたのむ会社も多いのだが、多くの場合、「まる投げ」が発生する。結果として、コンサルタントは、その会社のすべての部門を相手にして、ヒアリングやらとりまとめやら、ひどい時には部署間調整までやらされるハメになってしまう。これではコンサルタントはそれに見合う費用をもらうか、どこかで線を引いて「腰が引けた」作業に徹するかのいずれかを選択するしかなくなってしまう。少なくとも、会社側にも取りまとめ役、それもある程度ＢＰＲのやりかたについて知識、経験と必要な権限がある人間が必要だ。自前で全部やれればいいのだが、一般の会社で、ＩＴまわりの最新情報をフォローしていくことはなかなか難しいから、その部分はコンサルタントにまかせ、業務まわりは自社で考えることを基本にすべきだろうと思う。

特に日本はこうした「まる投げ」傾向が強いように思う。世の中が、今よりゆっくりと進んでいた、古き良き時代の名残ともいえる「まる投げ」を続けていたのでは、今のグローバル化した経済の中で企業は生き残っていけないと知るべきだ。会社は、それ自身でＢＰＲのエキスパートを最低限の人数持つべきだと思う。ＢＰＲはそれ自体がひとつのマネジメントサイクル（ＰＤCAサイクル）でもある。決して一回きりで終わるものではなく、継続的に改善されるべきものだからだ。経営陣も少なくともそうした知識は持つべきだ。長年の経験は宝ではあるが、それを体系化できなければ伝承もできないし、応用もできない。そういう意味で経営者はＭＢＡくらいは持っているべきだ。特に、経営判断の基準をぶれさせない、という意味では体系化された知識は重要かもしれないと思う。もちろん、経営者特有の「動物的なカン」も必要だが、往々にしてそれは、知識によって体系化された長年の経験から生まれる。

ちょっと話が脱線気味だが、これからの話は、こうした本当の意味でのＢＰＲが前提になってくる。これなしでは、「使えない考え方」になってしまうからだ。せっかく、ＪＳＯＸ対応で業務フローを書いたのだから、一度それを全部並べて見比べながら、業務の非効率な部分を見直してみるといいのではないだろうか。その上で、今のシステム（人＋ＩＴ）の問題や足りない点、共通化できそうな点を洗い出してみるといいだろうと思う。

さて、こうした前提で、ＩＴのアーキテクチャを考えてみよう。

（続く）

昨日はいいお天気だったから、朝から掃除、洗濯、布団干しなど、あれこれやって、遅い目の昼飯をいつものそば屋で食べてから、向かいのコジマを冷やかし・・・のつもりだったが、折悪く、ＤＳｉーＬＬの発売日。DS-Liteのスペシャルカラー（クリムゾン・レッド）は気にいってはいるものの、画面が小さくてRPGなどの長時間プレイは目が疲れて無理。ドラクエもとん挫したままになっている。出たら買おうと思っていた「おじさん、おばさん向けDS」なので、即ゲットしてしまった。

それから、家に帰ってとりあえずバッテリーを充電しながら、あれこれ・・・。最近日が短いので、あっという間に陽が傾いて・・・・。気持ちいい感じなので、久しぶり気夕方のお散歩に出かけた。もうちょっと寒くなっている。

いつもの公園の木々はすっかり紅葉して、夕陽を受けてあざやかだ。

この公園から、いつもの高台に登って、夕陽を見るのが夕方の散歩パターン。ぼちぼち歩きながら、またしても昨日の昼のようなことを考え始めた。こうして見えている、自分を完全に取り囲んでいるように見える景色が、実はそれがすべてではなかったら・・・・。すべてを電磁相互作用に依存している人間の五感は本当に信じられるのか。まぁ、この疑問は自分の存在、いや人類やこの世界自体の存在への疑問にもつながりかねないので、非常に危険なのは承知しているのだが、最近ついついそういうことを考える。高次空間に繋ぎとめられた薄っぺらな３次元方向にしか厚みのない世界にいるのが我々なのか、もしくは、光というものの性質のせいで、そういうふうに（周囲に存在している他の次元方向にあるものが存在しないように）見えているだけなのか。この美しい夕景も、もしかしたらまったく違う見え方をするのかもしれない。

見えているものとの間の距離は、本当に見えているとおりなのだろうか。これは、単に我々が知覚できる３次元のスクリーンに光というものによって投影された影なのではないだろうか。同じ距離に見えるものでも、実はもういくつかの次元を加えて距離を測ると、バラバラなんじゃないだろうか。光によって見えるものは、すべて自分にとっては過去の影だ。アインシュタインによれば、この影の状態以上に、今に近いものを考えることは無意味らしい。しかし、それはなんとなく不自然に感じられる。その同時性における不確かさの大きさは、距離が遠くなるほど大きくなるらしい。もちろん、これは光の速度が自然界の最高速度であると仮定しての話だ。しかし、そもそもその速度は何を基準に測っているのか、それは測り手の固有時間に過ぎない。どの固有時間で測っても同じ速度に見えるという光の性質を、私はそのまま受け入れることができない。そうさせている何かが、より高い次元に存在するはずだ。いや、時間そのものについての考え方が間違っているのだとすれば、そうした時間に依存した測定は少なくとも、今考えられているような意味はもたなくなるだろう。

また、頭がこんがらかってきたので、少し忘れて、夕陽をながめることにした。この太陽は、８分前の姿だ。でも、これを見ながら、今現在の太陽がどうなのかを想像することをやめられるだろうか。それはあまりに不自然に思える。ちなみに、８分前太陽を出た光の中には、太陽の中心部で１００万年も前に生まれたものがあるらしい。太陽の中心部から光が外に出てくるには、それくらいの長い年月がかかるのだそうだ。もちろん、まっすぐに出てこられるわけではないのだが、それにしても、この落差はなんだろう。

そういえば、光は物質が存在する空間では速度が落ちる。これも不思議な話だ。真空中の光の速度は自然界の最高速度だが、たとえば水の中ではそうではない。光、つまり電磁波の伝わる速度よりも速いものが存在する。チェレンコフ効果という、高エネルギーの粒子やニュートリノの検出などに使われている現象は、たとえば水中を光よりも速く動く荷電粒子に電磁場（もしくは光子）が追い付けずに引きはがされて光として見える現象なのだそうだ。ちょうど、飛行機が音速を超える時の衝撃波に似ているかもしれない。そうなることの理論的な説明はあるのだが、なんとなく感覚的には納得がいかない。これが、私が理論家になれなかった（ならなかった？）理由なのかもしれないのだけど。

ともあれ、光、時間、不思議なものがこの世界には多い。たとえば、パラレルワールド仮説を例にとれば、この瞬間も世界は枝分かれしている。たまたまこれを読んでしまったあなたは、なんらかの理由で読まなかった自分とはすでに違う時の流れにいるわけだ。私もそう。この瞬間にも、これを書くのに一回で書けただろう私と、ミスタイプをした私はすでに違う時間の流れの中にいる。時間の流れは、もしかしたら確率的な広がりを持つものなのかもしれない。今の私がある原因の連鎖の結果だとすれば、それ以外の時間軸を持ってしまった私は、今の私の（時間の流れの空間において）周囲にに確率的に分布しているはずだ。それじゃ、時間は１次元じゃないのか。今の私という存在は高次元における私全体のひとつの切片でしかないのか。

こう考えると、そこから先にまた妄想が広がる。きりがないし、頭も疲れるので昨日はこれくらいで切り上げた。でも、こんなメモ的な日記を残しておけば、また続きを考えられるし、もしかしたら大発見ができるかも・・・なんて夢みたいなことも考えられるから楽しい。

さて、家にかえったら、DSが充電完了していたので、さっそく動かしてみた。まず、家の無線LANにつなごうとしたのだけど、これがうまくいかない。さすがに、このご時世、家はWPA2/AESを使っているのだけど、これはDS的には「上級者向け機能」ということになっている。APにはすぐにつながったのだけど、そのあと何度やってもDHCPでうまくアドレスがとれない。固定アドレスを設定してみたら通信はしてるみたいだけど、DNSへのアクセスがおかしくてネットにつながらない。どうやら設定したネットマスクもおかしいみたいで、ブロードキャストがうまくいかないようにも見える。これは、もしかしてバグなんだろうか・・・。「上級者機能」だからなぁ、そういうこともあるか・・・。ネットにつながらないとファームウエアも更新できないしなぁ・・・。困った。結局、これで３時間ほど悪戦苦闘して、昨夜はおしまい。ま、従来通りのゲームはできるので、そのうち解決策が見つかることを期待していよう。

このところ、膝の具合が悪くて長時間歩くことをちょっと控えていたのだけれど、いい天気で、それほど寒くもなかった今日は、久しぶりにお昼の散歩に出かけてみた。

気持ちのいい青空、ひんやりとして気持ちのいい空気、日差しはまだ少しまぶしいけれど、暖かい。春先に、満開になる桜並木は、すっかり葉も色づいて散り始めている。

また、春が来たら桜のアーチになるのだけど、しばらくはお預けだ。とりあえず、ぶらぶらと橋を渡って豊洲あたりまで行ってみた。運河沿いも気持ちがいい。水面にうつる日差しもずいぶんと柔らかくなった。青空をうつした水面も気持ちがいい。そういえば、このあたりの川岸を見ると、ずいぶん水が綺麗になったなと思う。川岸の浅瀬は綺麗に底が見えるから。

なんとなく時間の流れがゆっくりになった気がする。ちょっとこのところ、仕事がペースアップしてきたので、こういう時間も大切にしたいものだと。

時間といえば、ふと今日も、こんなことを考えながら歩いていた。時間ってなんだろう。昔から時間の流れの存在は、暗黙に認められていて、誰もそれに疑問を抱かない。しかし、考えてみれば、これほど感覚的なものもない。実際、時計は一定かつ共通の時間の尺度に見えるが、厳密にいえば、たとえ原子時計であろうとも、すべての時計は異なる時を刻む。単に人の感覚では違いが感じ取れないだけだ。もしかしたら、時間などという独立した軸は存在しないのかもしれない。時間は位置や運動と渾然一体として、相対的なものだ。物が動くから時間が存在する。動き方によって時間もかわる。アインシュタインの考え方だが、もう一歩進めて時間（ここでは固有時間のことだが）を独立した軸としてではなく、他の軸（次元）と同等なもう一つの自由度であると考えたらどうなるだろうか。なんとなく、タイムマシンパラドックスにひっかかりそうだが、時間はそれぞれ自由にとった４次元空間の中の３次元座標系に固有の流れを持つのだから、高い次元で見れば、運動の一つにすぎないのかもしれない。でも、時間がなければ運動をどうやって表現できるのか・・・。こんなことを考えていると、なんとなく頭がこんがらかってくる。そもそも、絵に描くこともできない、数式でしか表わせない高次元の世界を頭の中で考えることは、アインシュタインやホーキングのような超天才にしか許されないことなのだろう。でも、こういう空想は楽しい。

そもそも、人間は生まれた時から目に見えるもの、五感で感じられるものを信じてきた。まぁ、時々、＋α の次元を見通して、普通は見えない存在を見ちゃう人もいるみたいだけど。光、つまり視覚は最も信ずべき感覚だと思われている。しかし、これほどまだ実態がわかっていない代物もない。電磁波？、光量子、質量もないのに運動量は持ってる？、速度は一定で、エネルギーは波長が短いほど高い？。数式上では解けても、誰もその本質はわからない。人間の五感はそれぞれ補完し合っているのだが、よく考えてみれば、五感をつかさどっている感覚器官はすべからく広い意味では電磁作用を使って、情報を収集、伝達している。そういう意味では、電磁場に縛られているわけだから、直接、間接的に電磁場に対して影響を与えるものでなければ感知できないとも言える。重力だって、電荷を持った粒子（質量）と相互作用するから感じられるわけだ。もしかしたら、我々は偽りの世界に住んでいるのかもしれないな、とちょっと疑心暗鬼な感じだ。

ビッグバン以来、宇宙は加速膨張しているというけど、それは本当なんだろうか。結局、理論家はダークエネルギーなる不可思議な概念を加えて、また数式を複雑化してしまう。なんとなく、このままでは最も美しいはずの大統一理論も、不可解きわまりない数式の山になりそうだ。敢えて、過去にやった勉強を捨てて、こういうことを言うのだけど、自然はもっとシンプルなものなのかもしれない。時間、というものが今考えられている以上に不確かなものだったとしたら、すべての計測は無意味になるかもしれないし、ある意味、これまでの考え方を一回捨てて、一から考え直してしまうような大天才が出てこないものだろうか。たとえば、光の速度が一定で越えられない・・・ということだって、時間が自在に変化する世界では、違う見え方をするかもしれない。・・・・妄想だが、これもまた楽しい。たとえば、今我々が見ている光が、実はもっと高次の何かの影だったり副作用だったりしたら・・・。こんな妄想をしだすときりがないのだけどね。

秋空の下の散歩、そして秋の夜長は、こんなことも考えさせるのかな。

システムの構造化といっても、やりかたはプログラムとよく似ている。個々のサブシステムの機能を出来るだけ単純化し、共通化できるものは共通化する。でも、これは言うほど単純ではない。もともとスパゲティーなシステムは、そのプログラムから見直していく必要がある。

特定のデータの検索や登録・変更などの基本的な処理と、そのバリエーションや表現や使い手の利便性を向上させるための処理は可能な限り分離する。たとえば、品物の見積もりを依頼された場合、在庫を調べ、在庫があれば「即納可」として、必要数量を仮押さえ（予約）する。在庫がなければ、標準納期を検索するか、仕入先に問い合わせて在庫と納期を確認する。それから、単価、顧客ごとの仕切り率などを検索して、それらの情報から見積もり書を作成し、内容を確認してから上司のハンコをもらって・・・・。という手順だとしよう。

ここで在庫の検索、標準納期の検索、品物の予約、単価や仕切り率の検索などは、基本的な処理であり、他の作業でも利用される。一方、見積書の作成、印刷もしくはその承認という作業は見積もり作成に固有の作業だ。（もちろん承認などの統制過程は汎用的なワークフローにできるが、その際も、見積もり固有の業務フローは基本ロジックからは分離しておく）

ＤＢＭＳの多くにはストアードプロシジャー呼び出しという機能が用意されている。こうした基本処理をサーバ側に手続きとして用意しておき、それを呼び出すというのが綺麗な形だ。こうした汎用的な手続きをデータベースサーバ側に用意しておくことで、アプリケーションの処理はかなり綺麗なものになるはずだ。

しかし、依然として問題は残る。たとえば、そのような方法で作られた２つのシステムを統合することを考えてみる。企業の合併などの場合だ。しばらくは２システムの並行運用は必要になるが、最終的には統合したい。その際に、既存のシステムのパーツを利用したい。だが、同種の機能をたばねたくても、インターフェイスがまったくことなっているため、アプリケーション側にはそれぞれの異なる呼び出しを実装しなければいけない。まして、こういう整理すらされていないシステムの統合は、ほぼ不可能に近い。

経済状況の変化でＭ＆Ａなどが急激に増加し、また、その規模も大きくなってきた今日、こうしたシステム統合の問題は経営からのプレッシャーも強く、ＩＴ部門関係者の地獄絵図をもたらしがちだ。これをなんとか解決できるアーキテクチャはないだろうか。

（続く）

情報システムは常にビジネス環境の変化に対して後手にまわってきた。結果、屋上屋を重ねるようにして追加、変更を繰り返したシステムはメタボ化し、そのうち命にかかわる事態に陥る。これまで、そうなるのに約３年から５年かかってきたから、システム自体もこのくらいのサイクルで最初から作りなおす、ということが行われてきたのである。

３年から５年といっても、開発に莫大な費用がかかる企業の基幹システムをこのサイクルで作り直すのは大変だ。どうにか開発を効率化すべく、最初に考えられらのが、標準化である。これはどちらかというと保守性を向上させ、システムのライフサイクルを延ばすことが目的だったと言える。あわせて、プログラムの部品化も行われるようになった。単純な例は、よくつかわれる処理を共通化し、サブルーチンにしてライブラリとしてまとめることだ。たとえば、Ｃ言語の標準関数などはその典型だし、アプリケーションのカテゴリごとに、さらに上位の処理をライブラリ化しておけば、開発効率は大幅に上がる。

スパゲティー化を阻止するたえの構造化が言語自体に組み込まれていく話は、先に書いたが、この部品化も同様に、開発環境に組み込まれていくことになる。いわゆるオブジェクト指向の登場だ。プログラムをライブラリ化して標準にしようとすると、同時にそのプログラムが取り扱うデータ構造も標準化する必要がある。ならば、特定のデータ構造に固有の処理を紐付けて一体化できないだろうか、そういう発想から生まれてきたのがオブジェクト指向だ。たとえば、Ｃ＋＋やＪＡＶＡの「クラス」はＣの構造体に、その構造体を取り扱うための関数ライブラリをメンバとして組み込んだような形をしている。クラスで定義されたデータ構造を取り扱うには、そのメンバである関数を使うしかない。だから、データに対して設計者が想定していないような処理をプログラマーが書いてしまうことも防止できる。

オブジェクト指向も、プログラマーの意識変革を必要とした。とりわけ設計者にとっては、いかに整然としたクラスの体系を定義するかということが最も重要になってくる。クラスは、継承が可能だから、基本的なデータ処理のクラス、たとえば、ツリー構造やリスト構造のポインタ処理のクラスを定義しておき、それを継承して、実際にツリー化やリスト化したいデータ構造とその取り使いを行うクラスを作るといった整理が可能になる。こうしてけば、テスト済みのクラスを継承すれば、その部分は追加のテストは不要になる。保守性も上がる。実際、私もＣ言語でプログラムを書く場合は、まず頭の中で全体の処理を描き、必要なパーツを洗い出してから、まずそうしたパーツとなる関数から書きはじめることが多い。オブジェクト指向はこのやりかたを必須としたものだ。だが、これは言うほどやさしくはない。私がそのような書き方ができるのは、何度もプログラムのスパゲティー化に苦しんできたからであって、どうすれば共通化や標準化がうまくいくかを体で覚えているからである。しかし、いきなりオブジェクト指向をつきつけられた開発者の中には、こうした本質を理解できず、結果的にクラスを体系化できないまま、似て非なるクラスを量産するものも出てきた。こうなってしまうとせっかくのオブジェクト指向も意味なしだ。つまり、これらの考え方は、大規模な開発を前提に、トップダウンで効率よく開発を進めていくことを前提にしているわけで、少数精鋭の設計者とその他多くのプログラマーが存在するプロジェクト向けのモデルなのである。つまり、製作と保守を容易にする反面、設計者は、スキルと経験をより要求されることになる。この点が理解できていないと、プロジェクトは悲惨な末路をたどる。

これは、プログラミングという一段低いレイヤの話である。システム全体のアーキテクチャとしてはどうだろうか。先にも書いたように、プログラムのスパゲティー化は阻止できても、システム全体としてスパゲティー化していたのではしかたがない。そういう意味ではシステムにも、ある種の構造化が必要になってくる。

（続く）

アプリケーションの肥大化は、なにも今に始まったことではない。アーキテクチャを問わず昔からずっと継続的に発生している。アプリケーションを機能単位で整理して区分けするようなことはメインフレームの時代から普通に行われてきた。ＩＴの利用が進むにつれて、ビジネスサイドからＩＴに要求される内容がどんどん増えていくのだから、システム側もそれに対応した開発や運用の方法を考えていかないと、パンクしてしまうからだ。

しかし、不幸なことに、オープン化、クライアント・サーバ化の流れの中で、アーキテクチャとそれを扱う技術者、カルチャーの変化に伴い、これまでの流れが一旦途切れてしまったように思う。ともかく、データベース以外のほとんどの処理を、ＰＣ上のアプリケーションに押し込んでしまったため、アプリケーションが複雑怪奇なものになってしまったわけだ。Ｗｅｂアプリケーション化で、これらの処理をサーバ側に戻した時も、同じようにサーバ側アプリは、当初は肥大化し、混とんとした状態になってしまったようだ。

しかし、Webアプリの良い点は、１ページの処理単位で、プログラムを分割できる点だ。１本のプログラムがスパゲティー化する危険性は低くなる。しかし、これは、また一方でこれまでのプログラミングに慣れたプログラマーにとっては、悩みのたねになる。１ページごとに処理が途切れるのだから、その流れの管理、つまりセッション管理を別枠で行う必要が生じるからである。これをきちんと考えてやらないと、処理の遷移が複雑になり、システムとしてのスパゲティー化をもたらしてしまう。おまけに、サーバは１台ではない。対象となる業務単位に冗長系を含む多数のサーバが置かれ、しかもその裏側には巨大なデータベースサーバが存在している。ビジネスロジックは依然としてユーザ向けの画面処理と一体化しており、プログラムが細分化されてしまったぶん、似て非なる処理があちこちに分散してしまって、システム全体としてのコードサイズはふくらんでしまう。おまけに、クライアント・サーバの時と同様に、同時利用者数分のアクセスがランダムにデータベースに集中することで、データベースの負荷は大きくなる一方だ。

結局のところ、クライアント・サーバ型からサーバ集中型に戻したことで、クライアント側の運用は楽になったものの、サーバサイドが肥大化、複雑化し、情報システム、とりわけその改良や保守・運用のボトルネックとなってしまったわけだ。特に、近年、会社の合併などでのシステム統合があいつぐ中、いつまでたってもシステム統合がうまくいかない背景のひとつにもなっている。それもそのはず、情報システムの作り方がバラバラでは、機能の共通化や統廃合ができず、とりあえずは、間でデータ交換をする連携プログラムを作ってお茶をにごしておいて、次の開発で一から作り直し・・・・となってしまうからである。経営統合による効率化という掛け声は、こと情報システムに関して言えば、むなしく聞こえる。

さて、これを解決するいい手段はないのだろうか。

（続く）

さて、このあたりからネットワークが重要な役割をはたしはじめる。イーサネットをはじめとする、データリンク層（いわゆるレイヤ２）のプロトコルや物理層としての伝送メディア規格（レイヤ１）は早い段階で標準化はされていたが、いわゆるネットワークを作るためにはこれだけでは不十分だ。レイヤ３から上の層のプロトコルが必要である。しかし、最初の段階で、コンピュータ間通信のプロトコルは、そのOSやネットワークソフトウエアベンダに固有のものだった。一方で、国際的な標準化の動きも出てきたが、様々な利害がからんで遅々として進まなかった。その筆頭格であるOSIは、具体的なプロトコルの定義に入ったところで、事実上挫折してしまう。ただ、OSIがプロトコルを定義するために作った７階層の参照モデルは広く使われて、その後のプロトコルモデルの事実上標準となった。これはなんとなく皮肉な話かもしれない。一方、UNIX系のネットワークは米国を中心とした、政府、軍、教育機関などを繋ぐネットワークとしてどんどん普及していき、現在のインターネットの原型となった。もちろん、プロトコルはTCP/IPである。しかし、OSIの７レイヤモデルで見ると、TCP/IPとして総称されるプロトコル群、つまりレイヤ３のIPプロトコルとその補助的な役割をするICMPプロトコル、レイヤ４での確実な接続を保証するTCPと、同じくレイヤ４で軽量なデータグラム通信を行うUDPは、コンピュータ上のプロセスが１対１もしくは１対Nで通信をするための仕組みまでしか提供しない。OSIでいうところのレイヤ５（セッションの管理）とレイヤ６（交換されるデータの表現方式の互換性保障）、そしてレイヤ７（特定のアプリケーション間で行われる通信の約束事）は、まとめてTCP/IPの上で動くアプリケーションにゆだねられている。完璧にレイヤ７まで定義しようとしたOSIに対してTCP/IPのこの緩さが勝ったという見方もできるだろう。

いずれにせよ、やがてPCの世界もTCP/IPが主流になる。これまで独自のプロトコルを使ってきた各OSベンダは、レイヤ４以下でTCP/IPを使うモデルに移行しはじめた。また、UNIX系で使われているtelnet, ftpをはじめとする各種のアプリケーションもPCに実装され、PCとUNIXの世界がネットワークを介して接続されるようになった。当時は、UNIX系の処理能力がPCに勝っていたため、UNIX系を核としてPCを接続するようなモデルが広まりはじめる。PCが能力を持つことで、これまでメインフレームに集中していた処理をPCに分散することが可能になり、金食い虫のメインフレームを排除できるかもしれないと、PCやワークステーションメーカーは期待した。しかし、それはなかなか簡単ではなかった。個々のPCで処理を行っても、データをうまく共有できなければ、システムとしては成り立たない。つまり、少なくともデータは集中的に管理できる形が必要だった。そこで、能力に勝るUNIX機をデータ共有・管理のためのサーバとして使い、PCでそのデータを処理させる、初期のクライアント・サーバモデルが出来上がったわけだ。元来、技術計算用のワークステーションを作ってきたメーカーの多くが、サーバ用の高性能、高信頼性、大容量の機種を作り始める。しかし、このモデルでは、データのみをサーバに集め、ビジネスロジックは、そのほとんどをクライアント側で処理するという形であったため、アプリケーションを大量のPCにばらまく必要があり、その管理や保守コストの増大を招いてしまう。また、アプリケーションはOSやPCのアーキテクチャに依存してしまうため、たとえばWindowsとMacでは、同じことをするために違うプリケーションを作らなければならない。まんまとメインフレームを駆逐しつつあったクライアント・サーバモデルだったが、システム導入のイニシャルコストが大幅に下がった一方、保守・運用コストが著しく増加するという問題を招いてしまったのだ。

ここからの流れは、ほとんどの人が知っているはずだ。ハードウエア、ソフトウエア、ネットワークという大きな３つの流れは、インターネットという大きな海にたどりつく。この海を渡るための船がWebブラウザだ。一方、船がたどりつく先の港（Webサーバ）側では、船の乗客に対して魅力的なサービスを競って提供するようになる。それにつれて、船も大きく進化し、港もまた利便性に富んだものとなっていく。ブラウザの高機能化、様々なプラグインツール、これらを使って、使い勝手の「悪くない」サービスを提供できるようになると、アプリケーションは次第に、サーバ側に戻り始める。最初は、クライアントの使い勝手や互換性向上を目的に作られたJAVAは、クライアント側での処理系の重さや、目的とはちぐはぐな実行系の仕様変更などにより、バージョン依存などの問題が激しく、なかなか使い物にはならなかった。一方、サーバ側でも、Web用のアプリケーションを記述するためにJAVAを含む、様々な言語が使われはじめると、クライアント・サーバモデルは、あっけなく「ブラウザ・Webサーバ」モデル、すなわち結局、昔のメインフレーム＋ちょっとインテリジェントな端末のモデルとほとんど変わらない形に戻ってしまったのだ。これで保守・運用コストはとりあえず低減できたのだが、今度は、時代の流れとともにアプリケーションの肥大化に悩まされることになる。

（続く）

のどかな一日。掃除して、昼寝して・・・・、撮りだめしたビデオを整理して・・・・。暑くもなく寒くもなく、のんびりと過ごして今日も１日暮れました。

なんとなく、たまには写真ばっかりの日記もいいかな・・・・と。

そろそろ日も沈んで、なんとなくけだるい夕暮れのひと時。こちらは、今日の夕陽。

さて、明日からまた忙しい・・・。もうひと時のやすらぎを楽しもう。

マイコンは、やがて１６ビットとなり、処理能力も安いミニコンに近くなる。当時、１６ビットマイコンは、インテルの8086、モトローラの68000、ザイログのZ8000などがしのぎを削っていたのだが、最初にザイログが落ち、MS-DOSという汎用OSを得て、当時の巨大メインフレームメーカーIBMに後押しされたインテルが、勝利を手中にしようとしていた。個人的にはインテルの煩雑な命令体形や、セグメントレジスタなどというややこしい代物が嫌いで、モトローラのMC68000が大好きだった。当時、組み込みシステムでも１６ビットCPUが使われ始めていて、命令体形やアセンブリ言語が綺麗で、アドレス空間が広い68000が好んで使われた時期もあった。しかし、１６ビットの世界では、そろそろアセンブラを使うことが重荷になりはじめていた。というのも、処理能力の高さから、開発するプログラムの規模もどんどん大きくなっていたからだ。

私が、その後長い付き合いになるC言語と出会ったのもこのころだ。UNIXとそのOSを記述している言語であるC言語は、アセンブラを使いこなせて、かつて趣味でPASCALのような構造化志向の言語をかじっていた私にとって、非常にありがたい言語だった。なぜなら、構造化志向の言語である上に、これまでアセンブラでしか書けなかった処理の多くが記述できるような仕組みが用意されていたからである。C言語をはじめて学んだ際に、「ポインタ」で苦しんだ人も多いだろう。でも、アセンブラを振り回して、メモリ空間狭しと飛び回るプログラムを書いていた私にとっては、ポインタは、CPUのインデックスレジスタと同じものだった。中身はメモリのアドレスで、＊をつけると、そのアドレスが示すメモリの中身を意味するところは、インデックスレジスタ間接アドレッシング命令そのもの。唯一の違いが、ポインタには「型」があることだ。この「型」のおかげで、メモリ上の値を、必要に応じた型の変数とみなして処理できるのである。実際に、コンパイル結果をアセンブラのソースコードに出力してみると、その仕組みがよくわかる。おかげで、処理速度の関係などで、どうしてもアセンブラで書かなければいけない処理を、Cの関数として呼び出す方法なども、誰に教えられるでもなく会得していた。C言語の参考書は当時はほとんどなく、故石田晴久先生が訳されたカーニハン＆リッチー（ＵＮＩＸ／Ｃの開発者）著の「プログラミング言語Ｃ」が唯一のテキストだった。みんな傍らに置いて、ボロボロになるまで読んだものだ。余談だが、この本（初版）の中に書かれている例題が、後々深刻な問題を引き起こすとは、誰も予想しなかっただろう。標準入力からの読み込みにgets() 関数が使われていたわけだ。ちなみに、このネタがわからないＣプログラマーはただちに廃業したほうがいい。バッファオーバフローの餌食にならないうちに・・・。

UNIX上のC言語はすでにかなり安定した存在だった。しかし、マイコン用のCコンパイラは、かなりきわどい代物で、時々、バグのため、間違ったコードを吐き出すことも多かった。某M社のコンパイラ（だけではないが）には、よく泣かされたものだ。どれだけ、Cのソースコードを眺めても動かない原因が分からず、仕方なくコンパイルをアセンブラソースコードの出力に切り替えてチェックしてみたら、おかしなコードが吐き出されていた・・・などということも少なくなかった。これはもう、アセンブラを知らない人だったらお手上げな事態だ。そういうようなこともあり、当時、Cなどという言語を振り回す輩は周囲のプログラマーから変態扱いされたものだ。特に、もう一つのCを頭文字に持つ言語のプログラマーたちには、絶対に理解できなかっただろう。

16ビットになって、そろそろ「マイコン」から「パソコン」の時代になる。ようやく実用的な用途に使えるだけの処理能力を得た「パソコン」は、ビジネス用途にも使われるようになる。しかし、一台のパソコンで出来ることには限りがあるので、最初は中小企業向けのパッケージソフトを動かすくらいが関の山、多くはワープロの代わりなどに使われていた。

一方、UNIXは、DEC社製のミニコン、PDP/11とか、当時、スーパーミニコンと呼ばれたVAX/11などの上で動いていたが、やがて、１６ビットマイコンのプラットホーム上でも動くようになる。これらはパソコンではなく、ワークステーションと呼ばれて、別の方向に発展しはじめた。当時のUNIXは、オリジナルのAT&Tバージョンとその派生版で米国カリフォルニア大学バークレイ校で開発されたBSDバージョンに大きく分かれていた。BSDバージョンは、バージョン4.2以降、TCP/IPプロトコルが実装され、当時次第に使われ始めていた初期のイーサネットを使ったLANを構成できた。御同輩にはおなじみの、イエローケーブルの時代である。これを皮切りに、UNIXネットワークの世界では、TCP/IPが標準となっていく。

一方、パソコンの世界でもネットワーク化が始まったが、最初、それはベンダ独自の方式だった。マイクロソフトはNETBIOSプロトコルを、ノベルはIPXプロトコルを、インテル系ではなく、モトローラを採用したアップルはApple Talkといった具合だ。一方、TCP/IPの実装も始まったものの、その目的はUNIX機との間の通信だった。つまり、PCをUNIX機の端末として使うためである。

マイクロプロセッサの技術は急速に発展していった。それと同時に、インテル系はパソコン、モトローラはワークステーションといった棲み分けがはじまり、さらにワークステーション用に高性能な32ビットCPUが開発される。モトローラの68020は、すぐれた32ビットプロセッサだった。一方で、インテルの80386は、いまだ16ビット時代のしがらみをかかえ、複雑怪奇な代物だった。しかし、マイクロソフトもまた、インテル同様、過去のしがらみ（互換性）に縛られていた。そういう意味でこの二社は最初から一蓮托生だったのだろう。

サン・マイクロシステムズを筆頭とするワークステーションメーカーは、そうした過去のしがらみにとらわれず、自由な発展を遂げていく。当時の技術では、インテルのような複雑な命令体系を持つCPUの高速化には限界があると言われていた。このため、新興メーカーは、高速化のために命令を単純化したRISC（Reduced Instruction Set Computer）アーキテクチャを生み出す。単純な命令セットしか持たなければ、たとえば高級言語をコンパイルした結果は冗長なコードになってしまう。しかし、コードサイズが倍になったとしても、処理速度が数倍向上すれば、結果的に高速化が可能だというのが、RISCの考え方である。一方、従来型のCPUはCISC（Complex Instruction Set Computer）と呼ばれ、両者のつばぜり合いが始まった。インテルは一時は、RISCに走りかけたが、過去との互換性維持の方針からCISCに戻り、x86系列のCPUを進化させていく。結果として、ワークステーションはRISCでUNIX系OS、PCは互換メーカーも含めたインテル系CPUで、MSDOSからWindowsという形が出来上がっていった。この流れはずっと続いていくように思われたのだが、予想を裏切る結果が待っているとは、当時は誰も思わなかっただろう。

（続く）

スパゲティープログラムという言葉がある。たとえば、FORTRANやBASICなどのプログラミング言語には、GOTO文という構文がある。これを使えば、処理をプログラムの任意の場所へ飛ばすことができる。もちろん、アセンブラのジャンプ命令も同じだ。このような構文を持つ言語には共通の問題がある。無意識に使うと、プログラムの制御の流れを追うことが難しくなってしまうのだ。このように、あちこちへ飛びまくって追いかけられなくなってしまったプログラムのことを、からまったスパゲティーにたとえてスパゲティープログラムと呼ぶ。

プログラムのスパゲティー化は、保守性はもとより、プログラマーの生産性にも大きな影響を及ぼす。あらかじめきちんとロジックを詰めずに書きはじめても、前に書いたアセンブラの例のように、パッチワーク的に修正ができるので、なんとかプログラムを完成させられるからだ。もちろん、時間は余計にかかるし、プログラムはめちゃくちゃなものになるが、なんとか動く。しかし、これではその本人にしかわからない、いや、本人にすら時間がたてば解読が困難なプログラムが出来上がってしまう。処理をこまめにサブルーチン化するなどして、ある程度綺麗なプログラムにはできるが、それも人のスキルに大きく依存してしまう。サブルーチン化するということは、単に処理を分けることではなく、複数の場所で行われる類似の処理を共通化する作業が必要だからだ。これをしなければ、サブルーチン化する意味がない。

構造化プログラミングという考え方が出てきたのは、こうした現象を防いで生産性や保守性をよくすることが目的だった。基本的に、いかなるロジックも３種類の要素（詳細に言えば４種類だが）つまり、順次処理、条件付き処理、繰り返し処理（条件判断前置または後置）を使って記述できるというものだ。これには、GOTOのような飛び越しは含まれない。逆にいえば、この基本要素を使って作られたプログラムはかなりすっきりとしたものになる、というかならざるをえない。だから、まずは標準化の一環として構造化プログラミングを取り入れようとしたのだが、スパゲティーに味をしめたプログラマーには馬耳東風、なかなか根付かない。それもそのはずで、基本的な発想から変えなければいけないからだ。たとえば、昔風のBASICでは、よくプログラムの最後に、GOTO  10　という文が書かれる。つまり、プログラムの先頭に戻れ、ということなのだが、GOTO使用禁止を言い渡されたプログラマーがまず悩むのがこれだ。どうやったら処理をプログラムの先頭に戻せるのか。ここで発想を変える必要が生じる。プログラムの最後から先頭に戻す、ということは、つまり全体の処理を「繰り返す」ということだ。要するにプログラム全体をたとえば、WHILE や LOOP文のような、繰り返し構文で囲ってしまえばいいのだ。この発想の転換が案外難しい。だから、単に標準を決めただけでは、納期を理由にした標準破りが続出してしまう。

そこで登場したのが、GOTO文のない、いわゆる構造化プログラム言語だ。古くはALGOLや、その流れを汲むPASCAL、PL/1などの言語は、（例外的にGOTOを持つものもあるが）基本的に、GOTOを使えない。つまり、最初から構造化を考えて作らざるを得ないわけだ。人というのはある意味で弱いものである。いくら生産性が良くなる方法を頭で考えても、体がついていかないことが多いものだ。だから、仕組みとしてそれを組み込んでしまうことで、ルールからはずれたこと自体を出来なくしてしまおうという発想なのだ。この発想は、今日にいたるまで、形を変えながら受け継がれている。

（続く）

さて、出張明け翌日、昨夜は意外とよく眠れたので、時差ぼけもさほどきつくなく、朝から結構回転数が上がってた。新しい仕事は、今回の出張の収穫もあわせて、ちょっとエキサイティングな展開になりそうな予感。

しかし、さすがに帰国翌日出社でフル回転は、ちょっと疲れたようで、なんとなく肩がこっている。帰りがけに見たら、トリトンスクエアでは、毎年恒例の「晴海インフィオラータ」を開催中。花で作ったモザイク画が綺麗だ。

風が強くて寒いので、今日は歩かずに大江戸線利用、新橋駅で、復刻版カラーの山手線電車に遭遇。この色の山手線を見たのは、小学校に入る前の頃。でも、電車は最新型なので、昔の山手線というよりは、関西でおなじみの某私鉄の電車のよう・・・。ちょっと違和感もあるけど。もうこの色を知ってる世代は、幼少期から青年期を東京で過ごした、いい歳の、おっさん、おばはん、ばかりだろうから、しかたがないのかもね。

どうせなら、本物を復刻してほしかったけど・・・

さて、明日はお休み。ちょっと野暮用が午後からあるので、午前中はまた家事モードかな。

今日はハロウィーン。今回の出張も無事終了して、現在サンフランシスコ空港のラウンジで搭乗待ちをしている。あいかわらずの時差ぼけは続いていて、今朝も３時に目が覚めて眠れなくなった。まぁ、そのほうが日本に戻ってから体内時計を戻しやすいのだけど。

この２日は、久しぶりにシリコンバレーで企業訪問や現地スタッフと打ち合わせ。そういえば、この２年ほど、社内の仕事中心だったので、すっかりご無沙汰していた。

一昨日は夜、現地の人たちと懇親会。シリコンバレーも最近は、いまいちさえない状況みたいで、ＩＴベンチャーも総じて元気がないらしい。まぁ、ここしばらくは仕方がないのかもしれないが。

ともあれ、やっぱりこういう仕事をしているほうが自分の性に合ってるなと改めて思った出張だった。あちこち行って、いろんな人たちに会って、いろんな技術やビジネスに触れられるこの仕事はやっぱり刺激的。気持ちの上でも張り合いがある。

さて、あとは日本に帰って、明日からまた仕事だ。今朝のＳＦベイエリアは雲と霧に覆われている。空港もかすんで視界がきかない状態。フライトに遅れが出なければいいのだけどね。まぁ、霧の街の空港なのであまり心配はいらないだろうけど。

さて、あと２０分ほどで搭乗開始。そろそろラウンジを出る準備をしようか・・。