システム的視点
システムを構築するとき、ソフトウエアを設計するとき、企画をまとめるとき、これらを行うときに、必要な考え方をまとめてみます。
まず、問題の大小にかかわらず、仕事をある単位で分割します。分割の単位を決める視点は、「なんのために、なにをするのか」、目的と手段です。
巨大なプロジェクトであっても、小さなプロジェクトでも同じです。この分割は、これ以上できないというまで繰り返します。
分割されたまとまりを「タスク」と呼ぶことにします。
次に、タスクの共通性を探します。この共通性探しは、そのプロジェクトの中だけでなく、他のプロジェクト、世の中のすべての問題から探します。そうすると、1つのタスクだと考えていたものが、さらに複数のタスクから構成されていることを発見することがあります。発見したらタスクを分割して、さらに共通化を行います。
次に、手順を考えてみます。たとえば
a->b->c->d->e
の順で行うことが、
a->c->d->b->e
の順で行うことができるか、その場合に結果が同じを考えます。同じであれば、b, c, d の共通性を再考します。さらに複数タスクへの分割の可否を検討します。
そうすると実は、
a->b*3->c*2->d*6->e
であることが発見できることがあります。ここで、多重が見つかったときには、並列化の可能性を検討しますが、多くの場合は並列可能です。
完全に、部品の共通化が計られていますので、再利用性はきわめて高く、開発は最小限の労力で行うことができます。
次に、各タスクの実装を検討することになりますが、ここからは実際に現実との対比を意識することになります。つまり、各タスクはすでに実際に実現されているもの、動いているシステムが存在していないかを調査しなければなりません。もちろん、そのものずばりとは限りませんから、情報の内容、流れを可能な限り抽象化して、類似性をチェックしていきます。
こうすることにより、システムも企画も汎用化が計られ、適用範囲を拡大することができます。
ここでの汎用化はもちろん汎用的に使うことのできる部品をたくさん作って組み立てるという面が大きいわけですが、その部品が得意なもの、得意な手法であるように導くことができれば、システム構築、企画の提案に対して、自信のあるもの、説得力のあるものになるでしょう。
最終更新日: $Date: 2008-10-23 14:34:46+09 $
サービスを作るということ
グラフィCMSの原点で書きましたが、自分が使いたいものを作り、便利なものができたから他の人にも使ってほしいというのは、サービスの質を維持する基本の姿勢だと思います。自分は昔からコレを使っているからそれは変えられないけど、他の人は別の、今、どうやら、はやっているらしいものが欲しいというから仕方がないけど提供しよう、というのでは質的に最高のものを提供できるとは思えません。
ビジネスモデルという非常に聞こえのよい、しかし危うい概念があります。ビジネスモデルは事業の収益性を説明するという点では必要ですが、サービスの質を向上することを必ずしも含んでいません。もちろん、便利なものあっても、高いものであっては多くの人が利用できるものにはなりませんから、その点での配慮は必要ですが、それはスケーラビリティや、スケールメリットに対する意識だけで十分で、モデルではありません。
ビジネスモデルが優れているから、不便であっても我慢して、そのサービスを使うべきだ、というのは間違っています。不便だとということであれば、そのモデルは本来成立していないものであって、改善を必要とするものであるはずです。
私は、大学で化学の研究を行っていましたが、実験には時間がかかります。長い時間を要することは、極力、装置を使って自動化して有効に時間を使います。人は寝ないといけませんが、機械はその間も働いてくれますから、効率のよい実験の計画を立てて、時間を有効に使います。この計画がうまくできないとたくさん実験をこなすことはできません。
実験はうまくことのほうが少ないですから、多くの実験を行うことは非常に重要です。予想したとおりの結果がでるわけではありませんが、予想や仮定はありますから、その姿を想像しながら計画を立てます。想像したものと異なってきたら、なにが起こっているかを考えて計画を修正します。そうしたことの繰り返しを経て、最終的な結果に到達します。
本来の目的があって、その目的を達成するために、手段を選ぶ。すでにその手段が一般に、安価に手に入るものであれば、それを使う。複数の手段の組み合わせで目的が達成できれば、組み合わせて使う。どうしてもないものがあれば、どうすればいいかを考える。組み合わせて使う場合にも手段と手段の間の手間を小さくできないかを考える。
手段が簡単に得られないときには、目的を細分化してみて、優先順位を考え、優先順位の高いものから順に実現する手段を再検討する。そしてそれを便利にするには、どうすればいいのかを考える。
こうしたことを繰り返すことが本来必要なことです。
全体の目的を達成するためにぴったりする手段、製品が簡単に見つからないと諦めるか、丸投げする。そのうち、いつのまにか、本来の目的の優先順位のことを忘れてしまう。目的意識が薄れると、目的よりもリスクが一番上に来てしまい、これが満たされていないから、できないと言い始める。
こんな思考をしていては、サービスや製品を作ることはできません。もちろん社会に責任を持った形で出すためには、ちゃんと安全なものとして整えなければいけませんが、そのためには数多くの検証、実験を行わなければなりませんから、多くの人が使うことはとても重要です。
しかし、始めるときには、目的をはっきりして、まず最優先する目的を実現し、徐々にきれいに整えていけばよいのです。次の段階で既存の技術や製品を利用、活用できないかを検討すればよいのではないでしょうか。始めるときに、もうすでにぴったりするものがあれば、だいたいこんな検討が行われることはないわけです。買ってきて満足できるでしょう。
それは○○だからできないというのは簡単な話ですが、本来の目的やサービスの向上がそこに存在しているのかをよく考えるべきです。そのために、すでに何が実現されているのかを知り、なぜそれが使われているのかを考え、そして自ら体験してみることも非常に重要なことなのです。
それに古いものを大切にするのはいいことですが、それはなぜ大切にするのかも同時に考えるべきなのです。
最終更新日: $Date: 2009-04-27 10:14:55+09 $
デジタル化の意義
デジタル化してしまうと、なんでも 0, 1 の羅列になってしまう。元が何であろうと関係なく、0, 1 の羅列になる。
もちろん、どうやってデジタル化するかというところに問題はある。しかし、簡単にいえば、なんでもそうなのだが、画像や音声についても、再現性を高めようとすればするほど、データ量は多くなるというのは簡単な法則である。アナログデータをデジタル化するには、サンプリングという方法によって、切り刻んだ各点のデータを数値化することで表現する。再現性に影響するのは、サンプリングの個数（頻度、間隔）とダイナミックレンジである。ダイナミックレンジはたとえば音声であれば、音の強弱を、16ビットならば、65,536 段階、20ビットならば、1,048,576段階にで表現するということだし、静止画（写真）の場合だと、画素数が、1500万画素、2100万画素というのがサンプリング数で、RGB の各色について、AD変換時の、12bit とか 14bit というのがダイナミックレンジである。JPEG では、RGB各色について、8bit しかない。
これは余談だが、写真でいうダイナミックレンジには、フィルムや、デジタルカメラの撮像素子で光量の差がどれくらいあるものを記録できるかというものもあり、これは db で表現される。8ビット分、つまり256倍の場合、48db相当。 ちなみに、デジタル一眼レフカメラでは、60～80db くらいだ。フィルムでは、ネガが80dbくらい。ポジで、70dbくらいになる。この差が、ラチュード（露出の寛容度）といわれる部分で、ネガフィルムが大きなラチュードを持つことがわかる。これに比べると、最近ではかなり良くなってきているとはいえ、やっと最高級デジタル一眼レフがここに到達してきたという感じだ。
デジタル化した後の利点は、0, 1 の羅列なので、数学的な処理が可能であるということだ。数学的な、圧縮技術によってデータ量を減らすことができる。そのデータがなんであるかを考えないで圧縮する方法では、一般的に可逆的である。つまり、圧縮しても、まったく同じように元に戻る。zip や、 lha などのアーカイバで用いられる手法だし、通信路の圧縮でも用いられる手法である。データの圧縮は、規則的なデータには圧縮率が高く、ランダムなデータでは圧縮率が低いというのが、一般的な傾向である。そのため、音楽や、画像ではあまり圧縮率を稼ぐことはできない。
これに対して、そのデータがなんであるかによって、その特性を生かして圧縮する方法がある。音声に対しての圧縮、画像に対しての圧縮方法である。これらは、一般に不可逆（完全に元には戻らない）的である。音声の MP3、静止画の JPEG、動画の MPEG がその代表である。その代わりにこれらのデータは非常に大きいので、こうした不可逆圧縮方法で、大きな圧縮率を得ることができる。不可逆的な圧縮法によって得られたデータを元に戻そうとするときに、オリジナルとの差はノイズや歪という形で現れる。映像のモザイクノイズがその例である。
デジタル技術は、サンプリングと圧縮技術によって、デジタルデータ化を行うものである。
さて、最も大きな利点はこうしてしまったら、元がなんでも同じデジタルデータだということである。違いはデータ量の大きさだけで、それ以外に違いはない。コンピュータや、通信路の上では、まったく同じに扱える。
もっとも、巨大なデータを一定時間内で処理するためには、高速なネットワークと大きな記憶装置が必要となる。しかし、評価の基準は、速度と容量だけで、元がなんであるかは関係ない。関係するのは、あくまで、そのデータを作るときと、オリジナルに戻そうとするときだけである。
最終更新日: $Date: 2008-10-28 16:29:51+09 $
ネットワークによる情報流通におけるメタデータの活用
メタデータとは、データに付随するデータのことで、作成日時、作成者、作成したソフトウエアなど、データ本体に対して注釈のような役割をするもので、データを効率的に管理、検索するために用いられる。
オペレーティングシステムで、ファイルに対して付けられる、タイムスタンプや、オーナー、パーミッションも情報としては同じものであるが、ここでメタデータという場合には、単一のデータセット内に格納され、ポータビリティを有する形式であるものということにしたい。なぜならば、ネットワークでの流通を前提にするとき、付随する情報と別のところにあるデータベースに管理されていると、分離されてしまうと失われてしまうからである。ただし、単一のファイルに格納しなければならないことにすると、標準やファイルフォーマットとの関係で実現しないこともあるので、一対一に関連付けられたものであればよい。Adobe が提唱している、xmp (eXtensible Metadata Platform) などの方式がこれに相当するだろう。
html には、meta フィールドが定義されている。文字コードや、スタイル、スクリプトの宣言のほか、keywords, description, author, generatorといった内容にかかわる注釈を記述するタグが用意されている。この meta フィールドは、通常のブラウザでの表示ではあらわれない。しかし、検索エンジンでは、タイトルや meta フィールドの内容、重複などを注意深く検討して、検索結果に反映しているといわれている。しかし、一般のコンテンツ作成においては、このタグの存在自体もあまり十分に認知も、活用もされているとはいえない。確かに、ページごとにtitle, keyword, descriptionを別々のものを記述するというのはわずらわしい。しかし、情報の管理、検索の点でこのメタデータが正確に記述されていることは必要なことだ。
画像データのメタデータは、もっとも充実したものの一つである。JPEG, TIFF といった代表的な画像フォーマットで標準化されている。デジタルカメラの RAW データフォーマットは、多くの場合、TIFF に準拠しており、メタデータに関しては、TIFF と同様に格納されている。画像データのメタデータは、EXIF (Exchangeable Image File Format) と IPTC (International Press Telecommunications Council）フォーマットの2つの形式が代表的である。前者は、カメラの撮影データを主とし、後者は撮影者が後で注釈として記述することが主たる目的である。両者とも、JPEG, TIFF をはじめとして、adobe の PSD などで利用することができる。EXIF は、デジタルカメラが撮影時にデータを自動的に記録することが一般的である。IPTC は、Microsoft の Pro photo tool 2 や、Photoshop などで記述を加えることができる。
EXIF には GPSデータを格納するフィールドがある。GPS 付のデジタルカメラでは撮影時に書き込まれる。そうでない場合にも、SONY の GPS-CS1K などの GPS ロガーを用いると撮影時刻と比較しながら、GPS データを EXIF に書き込んでいくことができる。旅行中に撮影した写真などでは、撮影場所を自動的に記録できるので便利だし、楽しみも増えるだろう。
Microsoft Office でも、一般的な作成日、最終更新日、タイトル、作成者などの情報の他に、Word count, Char count, Code Page などの情報が入っている。変わったところでは、Total Edit Time というものがある。
PDF でも、情報は比較的少ないが、一般的なものは入っている。Adobe Acrobat で作成した場合には、Document ID などの管理的な情報も加えられている。
他のインターネットアプリケーションを見渡してみると、電子メールやネットワークニュースではヘッダ情報は、メタデータとみなすことが出来るだろう。From, To, Cc, Subject, Date などである。Message-IDは、そのドキュメントの特定をするために必要なユニークなものとなることを保証している。
こうして見ると、それぞれのアプリケーションで方式は違っているが、理念としてメタデータの有用性と必要性をそれぞれのシステムを作った人々が感じていることが分かる。メタデータとして、被参照要素をまとめて、本データとともに管理すれば、別のデータベースで管理する場合のように流通時に別々になってしまう虞はなくなる。実際の検索を行うためのインデックス情報はもちろん必要だが、それは壊れたり失われたりすれば再構成すればよく、本データが失われる場合にくらべれば問題にはならない。
イメージデータに付随するメタデータ情報が、データ量が多くなることから削ってしまう Blog システムなども多くみられる。こうしたシステムにはオリジナルデータを保存し流通するという意図はない。
ネットワークでの情報流通という観点においては、メタデータ方式が望ましい方式であると思う。Microsoft や、Adobe がイメージデータの管理を行うのにメタデータを活用する方法を重視し始めているのは、当然こうした流通を意識しているものと考えられる。
今後は、動画データにおいても流通が意識されるようになり、メタデータの活用、標準化が行われていくものと思われる。これによって現在よりも管理、検索が容易になり、再利用が促進される環境が整っていくだろう。
グラフィCMSでは、各ページごとにプロパティを管理しているが、CMSテキストからは、html のメタフィールドを独立して生成するための項目を持たせてある。さらにアップロードされたイメージデータや、Office ドキュメントや、PDF からも可能な範囲のメタデータを抽出して、管理するようになっている。CMS内部のメディアブラウザでは、メタデータ要素の一覧を見ることができるし、検索、抽出ができるようになっているし、Web として公開する際にも、システムが生成したプレビュー画像を除いてはメタデータを、完全に保存するようにしている。
最終更新日: $Date: 2008-12-07 01:09:56+09 $
Edenの原案
ネットワーク管理のソフトウエアは、1980年代からいろんなものがあるわけだが、1990年代初めは、OpenViewや、Sun Netmanager などが中心で、単一のワークステーションから監視対象をポーリングするタイプで、それをワークステーション上にグラフィック表示するものであった。
主に、現在どうなっているのかを表示することを主目的にしていて、それを美しく表示するというのが特徴であった。そのツールの使われている状態というのは、オペレータがその前に座っていて、監視しているという使い方でなのである。
これに対して、大量の機器を定期的に継続的に監視し、その状態を記録しておき、その結果を必要に応じ、整理し、条件検索して表示するというツールはほとんど存在していなかった。
私は、IIJを辞めて一時コンサルティングを中心に活動しているとき、その中に、ちょうどケーブルテレビのインフラを利用してネットワークサービスを提供する、いわゆるケーブルインターネットのシステムの構築を行う仕事があった。ベンダーが提供しているツールは、ケーブルモデムの設定をリモートから行うツールであった。例によって現在の状況を知ることはできるが、全体として状態を継続的に履歴管理するものはなかった。
そこで、私たちは、そういうツールを作ることにした。こうした仕事には、UNIXを使って行うことが向いているので、もうすでにフリーで使えるようになっていた、PC-UNIXで構築して、ユーザインターフェースとして、Webブラウザを利用するというシステムを作った。UNIXのシステムが継続的にポーリングを行いデータ収集をして、ファイルにその結果を書いていく。条件を与えると、その中から該当する現象を起こしているデータを記録しているものだけを選んで表示するという、そう言ってしまえば、簡単なものであったと思う。
設定を行うために、指示を行うときには、Webサーバ経由でそのデータを渡しておくと、サーバ側でそれを機器に向かって送出する。ちゃんと反映されたかは、読み取って確認して表示する。
この時は、要求が簡単なものであったし、ネットワークシステム自体がまだトライアルの段階で我々のシステム開発への要求もプロトタイプまでであったので、ここで終わったが、このときの経験、アイディアが後の Eden につながっていく。
このときに、このプロトタイプのコーディングを実際に担当したのが、現在オムニサイソフトウエアの社長の藤原氏であった。実は、私が依頼したのは、別の会社であり、彼はその下で下請けとして製作に当たっていたのだった。
最終更新日: $Date: 2008-10-20 14:26:13+09 $
Edenの思想
Edenは、見た目としては、Webサーバでネットワークの監視情報を集めて、Webインターフェースで表示するというシステムである。
確かに他のネットワーク監視システムとの比較の上では、そうなってしまう。それは他のネットワーク監視システムが、情報のビジュアル化が目的であるため、その比較においては残念だがそうとしか見えない。
Eden は、まず情報収集整理ロボットだと思うと分かりやすい。指示を与えておくと、その指示に従って、情報を、独立して収集し続ける。ある条件にマッチした場合には、警報を発する、あるいはあらかじめ決められた作業を自動的に行う。
そしてこのロボットは、過去の情報を全部記憶していて、指示を出すとその記憶をプレイバックしてくれる。そういうネットワーク監視システムなのである。オペレータが前に座っていて、情報をビジュアル化し、オペレータの仕事を助けるというものではない。人工知能というほど大げさなものは実装していないが、条件文を記述することにより、次のアクションを起こすというプロシージャを定義することができる。システムがその機能条件を満たしていれば、自動運用システムになるのだが、大方の条件は機材が壊れたなどのトラブルに起因するため、そうはならないというのが現実だ。
しかし、たとえば Windows サーバが原因不明で固まってしまったのを、自動復旧するというようなことはデバイスさえ整えば可能なシステムとして当初から設計されている。 情報をビジュアル化する機能は、その条件を管理者が判断する材料としての補助的なものとして、必要であるため、実装されている。そのため、複数の情報を比較するだけでなく、加算、減算などの処理を行うこともできるようになっている。オープンソースのもののように、古い情報は合算して消していってしまうのではなく、生データを継続して記録しておくようになっている。
なぜ、このようなものを作ったかというと、別のところで書いたように、一つには、メディアエクスチェンジで、少人数でネットワークを管理する必要があったからだ。この少人数のスタッフは一人で何役もこなしているために、いつどこからでもこの管理システムにスムーズにアクセスすることができなければならないので、あまり特殊なアクセス方法を使わなくてもよいようになっている。その上、最近は非常に便利なファイアウォールボックスがあるので、ダイナミックなアクセス制限を行ってシステムを保護することができるようになっている。
監視ロボットに対して、Webインターフェースを介して情報のやりとり、指示を行い、問題解決を行うようになっている。
もう一つは、情報の継続的な保持という必要性である。これは、健康診断によくたとえるのだが、人間の場合、生物化学的な標準値というものがあるので、正常、異常の判断はそこから行うことができるが、ネットワークシステムにおいては、標準値がないのでそうはいかない。しかしながら、急激な変化はトラブルの兆候であることが多いので、それを検出することによって、できることなら未然に障害を食い止める。DDosアタックなどの検出には非常に有効な手段であり、ネットワークが使用できなくなる致命的な状況になる前に検出することもできる。
こうした思想のもとに、Edenは作られている。この考え方は、Edenだけのものではなく、他のソフトウエア、システムにおいても反映されている。
最終更新日: $Date: 2008-11-03 09:12:53+09 $
It’s really desktop !
Microsoft が VISTA をリリースした時に感じたことが、次期プラットホームでより具体的に実現しようとしている。Windows 7 や Azure で現実になってきたと思う。
VISTA が登場したとき、講演等の機会に「普通の人は早く VISTA を使ったほうがいい」と言ってきた。その時に思っていたことは、Microsoft は、Windows を Oparating System として考えているのではなく、”Real Desktop” を目指していると思ったからだ。
会社で業務に利用している場合には、OS としての機能を期待されているので、その上で特定のアプリケーションが動作することが重要であり、XP からアップグレードできないという理由は、一定の範囲でやむをえない。Microsoft が、OS ベンダーであるとすれば、バックワードコンパチビリティを完全に保証していないというのは欠陥である。
しかし、VISTA のリリースは、OS ベンダーであることから離れようとしている兆しを感じさせるには十分だったと思う。OSとしての、バックワードコンパチビリティを重視するアプリケーションベンダーは、早く Windows から離れたほうが賢明だろう。新しい世界のプラットホームとしての可能性のほうがはるかに大きい。
Microsoft いや、ビル・ゲイツなのか？その方向性の原点は、Real Desktopだ。机の上にパソコンが乗っかっているのではない。従来、机の上でしてきた仕事を、パソコンによって、Virtual な机の上を実現して、作業環境を提供しようとしているのだ。たぶん、これがビル・ゲイツの最初の理想の姿じゃないだろうか。
CES で、タッチパネル式のテーブルディスプレイでデモをして見せたことは、これをわかりやすく具象する行為だろう。
しかし、Virtual Desktop は広さの制約もないし、書類を積み上げたからといって、下になっている書類を発掘しようとしたときに、なだれを起こすような苦労はない。
従来のアプリケーションに対しては、データ、情報を扱えればよく、思想の異なるプログラムをデスクトップのパーツにできるならともかくとして、中核として継続して使えるようにすることを優先してなど、全く考えていないだろう。
そして、その中に、その先に広がるインターネットの世界をデスクトップ環境として統合しようとしているだろう。そう考えるとき、Microsoft の情報流通に対する戦略が見えてくると思われる。
個々の細かいソフトウエアのバックワードコンパチビリティにもはやこだわっていてはいけないだろう。手のひらの上で満足しているのか、机の上に挑戦するのか。
ちなみに私は大きな机が好きである。
最終更新日: $Date: 2009-01-17 09:07:39+09 $
大規模メールサーバの試み
ISPもビジネスとして確立してきた時代だった。これもIIJを辞めたあとのこと、当時 DTIの企画部長だったかをしていた、石田君（現フリービット社長）に請われて、DTIの技術顧問をすることになった。
その中で、メールサーバをなんとかしたいという話が出てきた。インターネットの電子メールは、UNIXシステムのユーザのメールシステムが分散して接続している形態から出来ているので、一つのシステムにたくさんのユーザが存在しているという管理はあまり想定していない。いまでもサブドメインを分割してユーザを収容していることが多い。フリーのソフトウエアもほとんど UNIX のユーザ管理を利用しているものである。
さて、ISPで事業用に利用するサーバは、UNIXのユーザ管理を利用しないものが欲しい。単一のドメインで運用するのではなく、複数のドメインを一つのサーバで管理して、別々のユーザ空間を実現したい。そうしたサーバは、たぶんなかった。UNIX上では、UNIXに標準的にメールシステムが内在しているので、どうしても余計なコストのかかるニーズがなかったのかもしれないし、だいたいドメインの考えと逆行するようなシステムを考える発想は生まれなかっただろう。
そこで、データベースを利用して、メールサーバ（というよりは大規模なメールボックスサーバ）を作ろうということになった。UNIXのユーザ管理ではなく、メールアドレスそのものを管理して、メールをデータとするというシステムであって、機能を実現することだけはそれほど難しくはなかったが、ユーザ管理を行うためにユーザインターフェースを作ることや、メールを実際に格納しておく巨大なディスクシステムのほうが、その当時の技術としては大変なことだった。
このメールシステムは、完成したのだが、当時のハードウエア環境の制約から、運用が難しいシステムになってしまった。確かに受託開発の形式で行い、納品はできた。しかし、ハードウエアの選定や調達、運用は我々は担当しなかったために、ずれが生じてしまったのではないかと思う。そのため、実際にこのときには本運用には入れなかったかもしれない。これもある時点で我々の手を離れてしまい、DTIから、石田君たちが離れて、フリービットを設立したために分からなくなってしまった。
これも、後にハードウエア環境とデータベースなどのミドルウエア環境が整ったあとで、このときの経験を生かして、再度作成することになった。ただし、今度はハードが高性能化したので、メールボックスくらいは、あまりこういう凝った工夫は必要なく、乱暴なシステムでも十分運用できるようになってしまった。
ただし、このシステムのアイディアは、現在のグラフィCMSの中に、登場してくる。一つのサーバから、たくさんのどんなドメインのWebサーバでも作ってしまうというものだし、CMS内でメールを送受信する機能では、事実上、このメールサーバと類似したことを行うことになっているだろう。
最終更新日: $Date: 2008-10-18 22:14:06+09 $
Ripgate
RipGate や、関連ソフトウエアの開発の裏話(?)を書いておこうと思います。
RipGate は、電子メール用のソフトウエアですが、情報共有のツールのひとつです。技術はつながり発展しますので、ここから違った切り口のツールも生まれます。そういう考えをダンプしておこうと思います。
RipGate の開発のきっかけはあらためて書きますが、大容量ファイルを何の考えもなく、電子メールとして（添付ファイルとして）送るユーザが増えて、それをなんとかしたいという管理者間の雑談から生まれました。宅ファイル便という無料のサービスがありますが、あれは電子メールの外枠にあって、アップロード、ダウンロードという、まあ、そういう操作に慣れた人にはいいのですが、そうでない人に説明不要で使わせるにはちょっと無理なので、ともかく送る人には電子メールソフト以外の操作をさせないことにしました。
アップロード、ダウンロードがわかる人には、むしろ非効率に写っているかもしれません。
Ripgateのアイディア
RipGate を作るきっかけは、2004年ごろの Interop の会場での立ち話でした。
「最近、メールでパワーポイントとかのデータを平気で送ってくる人が増えたので、メールサーバがあふれてしまう」という某大手コンピュータ系メーカの人の話でした。そこでそれを解決するソフトウエアかなんか知らないか、ということだったと思います。
「そんなの、入り口で引っぺがして別に取っておいて、あとで取りにくるようにすればいいじゃない。今だったら Web access できるようにすればいいじゃないの？それくらい作ったら？」
と言ったら、言いだしっぺの法則によって作るはめになったというわけです。
早速、会社の人やソフトウエア開発会社の知り合いにアイディアを話して、仕様を簡単にまとめました。あまりに簡単だといえば簡単なので、なんか特許なりなんなりを出しておいたほうがいいかもしれない、ということで特許の申請にも挑戦してみることにしました。
そこで、名前を決めようという話になりました。まずは開発コード名ということでしたが、メールからマルチパートの部分を切り離すというイメージが最初強かったので、そこから rip というという単語を選びました。
Jack-the-ripper = 切り裂きジャックというイギリスの連続殺人鬼の名前からの連想で、ゲートウエイで切り裂いておいていかせるという感じなので、gate-the-ripper という名前も考えましたが、やりすぎということで、RipGate になりました。その名前がそのまま製品名になりました。
RipgateASPサービス
日本語ファイル名の扱い
2006年9月から、RipGate ASP サービスが正式に始まりました。試用サービスとどう違うかですが、有料サービスですので、課金、管理関係が強化されたのは当然ですが、それ以外にもこの間いくつかのバグの修正が行われました。
その中でやはり問題だったのは、日本語の扱いです。電子メールでは、日本語（というより、non-ascii character) の扱いが３種類あります。本文（ボディ）中での日本語（これは、ISO-2022-JP という方式です）と、ヘッダでの日本語（いわゆる MIME ヘッダといわれるもの）、そして添付ファイルのファイル名（マルチパート部分のファイル名）の日本語です。それぞれが、Windows, Mac, UNIX 系システムでコード体系が異なるものですが、電子メールとして交換されるときには決められたエンコーディングをしなければなりません。これは、電子メールシステムのバックワードコンパチビリティの中で、どんなシステムにおいても影響を受けずに中継をされることを保障するために必要です。
本文中で、いわゆる半角カナを使ってはいけないというのは、よく知られたことですが、かつては Subject や From などのヘッダでは日本語を使うことを許されていませんでした。英文や、ローマ字書きをしていました。しかし、当時の NIFTY-Serve とインターネットの間で電子メールの交換を実現するためには、ヘッダに日本語を含めないといけないということで、当時決まったばかりの、MIME ヘッダの普及が一気に進みました。
今回問題になったのは、添付ファイルの日本語ファイル名です。これについては、ずいぶん前に RFC2231 で決まっているのですが、実際には実装は進んでいるわけではありません。
http://www.emaillab.org/essay/japanese-filename.html
に詳しく書かれていますが、ヘッダと同じ、MIME エンコーディングを行っているものもあります。また微妙な解釈が異なっていることがあり、メールソフト（MUA）によってさまざまな実装がありました。RipGate では、これらについてとりあえずできるだけ多くの現実の実装に対応することを行いました。
ただし、完全に世の中にあるすべてのソフトウエア、すべてのバージョンに対応できているわけではないので、まだトラブルがあるかもしれません。現状では、RipGate に限らず、もっとも確実に送るには、残念ながら、ファイル名には日本語を使わないことなのです。
Ripgate – 添付ファイルとは
添付ファイルという呼称は、MUA (Mail User Agent, 一般にメールソフトということが多いようだ）で使われるようになったと思われますが、正確には電子メールでテキスト以外のもの（画像や音声など）を一緒に送るための規格である MIME (Multipurpose Internet Mail Extentions) で規定された、本文テキスト以外の部分の各パートのことです。
MIMEについては
http://www.atmarkit.co.jp/fnetwork/rensai/netpro03/netpro01.html
http://www.atmarkit.co.jp/fnetwork/rensai/netpro04/netpro01.html
にわかりやすく解説されています。これらは受け取ったときに、受け取った側の MUA で処理されてファイルに戻されます。これを RipGate では、通過する時点で、全部ファイルとして復元して、各ファイルの属性 (mime type) を Web server 側に引き継いで、保存した URL を各パートの代わりに本文に挿入するということを行います。属性が引き継がれていますから、URL をクリックすると（これは、MUA に実装されている Web 連携の機能を使っています）、しかるべき表示ソフトウエアが起動されるようになっています。
RipGate が開発された背景には、MUA にこうした、 URL をクリックすれば、ブラウザが自動的に立ち上がって、見ることができるという機能が一般的になっていたという背景もあるわけです。
添付ファイルの管理
さて、RipGate で分離されたファイルの管理について書いておきます。RipGate では、各添付ファイル、およびメール本文について、ハッシュ関数によるハッシュ値をデータベース化して管理しています。表面上使っているのは、MD5 です (最新版では、内部的に SHA1, SHA256 も利用しています）。
これによって何ができるかというと、ひとつにはファイルの同一性のチェックができます。ファイルの中身に何が書いてあるかは、通信の秘匿に該当しますから、これを調べることはできませんが、送られようとしているものが、以前に送ったものと同じであるかとか、特定のファイルと同じであるかはチェックできます。
RipGate では、同じものを送ろうとすると拒否する機能があります。ただし、ASP サービスではこの機能はオフになっていますし、個々のユーザごとに設定することもできます。現在は、閲覧するときには、ID (mail address), password を入力して、認証を行っていますが、クライアントのブラウザを認証する機能を追加することにより、ハッシュ値ごとにその閲覧の認証を行うことも検討しています。
添付ファイルのアクセス制限
添付ファイルを剥ぎ取って、Webサーバに格納するというインテリジェントな機能をメールゲイトウエイに付け加えたことによって、さまざまな制御機能が実現されています。
もっとも簡単なものは、添付ファイルの種別による制限です。たとえば、PDFは出してもいいけれども、MS-Wordのファイルはダメ、というようなものです。これはメールを受けとった側で正しく、そのファイルに対する処理を行うために、送信側でその情報を加えているからです。Web 上でも mime type として表現され、適切なブラウザ、アプリケーションを立ち上げて処理するようになっています。RipGate では、mime type により、許可、拒否を判定しますので、もちろん送信側で意図的に、mime type を偽ればごまかせます。しかし、ごまかしたときには、octet-stream になるか、自分でエンコーディングして、テキスト内に入れるかですから、それはそれで検知可能です。
参考までに、MS-Word は編集履歴などの情報をファイルの中には保存しているために、共同して編集作業をしているというような場合にはやむを得ませんが、単に整形した文書を他人に送るという場合には、不必要な情報まで渡してしまうという虞がありますから、適当ではありません。かならず、PDFや、XML などに変換して送るべきです。PDFは印刷のイメージですから、目で見える以上の情報は含まれていません。
Ripgateの拡張性
RipGate は、電子メールを中間で処理するシステムですが、あくまで電子メールのシステムそのものとしては透過的な中継ホストとして機能しています。
電子メールは、sendmail で扱われ、RipGate は、milter インターフェースによって実現されています。
電子メールの配送そのものは sendmail で行われていますので、sendmail の機能として可能な制御、インターネット上のメール配送マネージメントは利用可能です。今後、Spam 対策などさまざまな要求が電子メール配送に対して求められても、最も一般的に使われている配送系ですので、きちんと対応可能です。
milter インターフェースは、当初 sendmail の拡張として提供されましたが、現在のバージョンでは標準機能としてとりこまれています。milter を利用した実装例としては、Spamassassin, bogofilter などへのインターフェース、amavis などのウイルス対策ソフトなどがあります。
milter の利点は、milter の先のプログラムは、ネットワーク接続された先の別のホストで稼動することができるということで、メールの中継をするホストと、RipGate で添付ファイルをマネージメントするホスト（Web server) は別々にできます。複数の sendmail の動作するホストから、１つの RipGate サーバへ接続を行って、添付ファイル管理をすることもできます。また、直列に Spamassassin, RipGate という処理をひとつのメール中継サーバから行うこともできます。
われわれの内部運用では、実際にこの順で処理をしています。
Ripgateの機能拡張
RipGate の機能拡張の要求として、添付ファイルの条件でのアクションの追加があります。
現在は、添付ファイルの mime type によって、メールの送信を許可するか、しないかだけしか選択肢がありませんが、まず、これを、1) 送信を許可し、Rip する、2) 送信を許可し、Rip しない、3) 送信を許可しない、の３つにする。
現在は、条件として、ファイルのタイプ（mime type) だけですが、これにファイルのサイズをレンジとして、メタタイプとして登録することによって、○○バイト以下は、送信許可、rip しない。○○バイトから△△バイトまでは、送信許可、rip する。△△バイト以上は、送信不許可（送信許可、rip しないというのも可能）とする、というような設定をできることになります。
現在、実装の検討をしています。
Outlook
Outlook Express、Outlook を使い続けている人は確かに多い。Microsoftの付属のソフトだからしょうがないが、機能は十分ではないし、仕様は古い。アップデートはされていない。所詮おまけなのだろうか？
Vista になっておそらく仕様の問題は直っているだろう。みんなが Vista に移行してくれれば問題は起こらない。でも、そんなに Vista に移ってはくれないだろう。Thunderbird/Firefox を使ってくれれば言うことなし。Becky! や Sylpheed といったシェアウエア、フリーソフトもまじめに作られているし、ちゃんと現在のインターネットのニーズと状況にあわせてアップデートされている。
Vista に移行しないとインターネットを使っちゃいけないということはまったくないのだが、Microsoft の考え方は最新のソフトなら問題ないのだから、そうだといわれてもしかたがない。
作る人、育てる人（余談）
ぶらっと立ち寄ったホームセンターのガーデニングコーナーの店頭で、若い女性２人が、ミリオンベルの見本鉢を、これを売ってほしいと交渉していた。お店の年配の男性は、「これは見本で、こちらの苗を買って行って、植えるとこうなる」と説明をしていたが、笑いながら女性たちは、交渉している。別の店員にも話をして確認していたが、売らないということで、女性たちは帰っていった。たしかに、植えたところで、日当たりを確保して、水やりをちゃんとしないと見本のようにはならない。
最近のできごとでこうしたことがとても気になる。花屋の店頭には、きれいに咲きそろった花が売っている。鉢花にしても切り花にしても盛りのちょっと前くらいの花がいっぱい並んでいる。一方、ガーデニングショップにいけば、苗や種、球根などもところせましと売っている。ガーデニングショップでも商品として並ぶものは、小さなポット苗であっても花をつけているものが多い。先日のNHKの趣味の園芸で、たしかネメシアだったと思うが、買ってきて大き目の鉢に植え替えたら、花を全部切るという話をしていた。一旦切り戻すと、分枝をして一か月くらいすると立派な株立ちになるという話だ。
ものを作るとか、育てるということは、気の長い、手間のかかる話だ。今は、ちょっとお金を払えばきれいな完成品を買うことができる。しかし、育てたり、作ったりして、そこに到達したときにはさらにすばらしいものが得られると思う。女性の行動だけでなく、世の中には、小さな種や、苗から育てることや、自分で作ることをする人としない人がいるようで、しない人はともかく買ってきてならべて、満足するようだ。
それだけではすまないと思うのだが、気にしすぎだろうか。
分散コンピューティングの行方
グラフィCMSも例外ではないのだが、ブラウザをユーザインターフェースにして、サーバ側ですべての情報を管理し、サーバ側でアプリケーションを動作させるという傾向が進んでいる。現在、我々が使っているPCはかつてに比べると非常に能力が高く、さまざまなアプリケーションを動作させることが可能である。しかし、一旦ブラウザを立ち上げてしまうと、ブラウザのレンダリングを行うこと以外では、手元のPCのCPUは使われない。
電子メールですら、Gmail ではすべてメールはサーバ側に保管されていて、手元にはなにもない。確かにこの方法だと、インターネットにつながってブラウザさえ動作すれば、手元のPCはなんでもいい。PCを持って歩く必要はない。ただし、ユーザIDとパスワードをブラウザに覚えさせるわけにはいかないので、それは自分で覚えておかなければならない。
ネットワークの便利なサービスは始まっていても、ネットワークの環境が貧弱であった時代には、ネットワークには間欠的につながっているくらいの前提でアプリケーションを組み立て、後は手元のPCで処理をするという考え方であった。電子メールは、POPベースのMUA（Mail User Agent) ソフトウエアをPCにインストールして、メールをサーバから取得、メールをサーバへ送信という操作を行い、それ以外にはネットワークは必要なかった。
掲示板のようなサービスもこのような方法で利用できるようにいくつかの工夫がなされていた。Webも、一括してダウンロードするソフトウエアなどもいくつか見られた。
この種のやり方の問題点は、手元にかなり大きなストレージを持っていないと実際には、便利には使えない。電子メールにしてもすべてのメールをダウンロードするので、メールの容量が大きくなったり、スパムにまみれたりすると大変な目にあう。
私はメールに関しては、現在両方の手段を併用しているが、スパムの扱いに関しては相変わらす頭が痛い。コンピュータウイルスに関しては、手元のPCでなく途中の経路で対処をするようになったので、まだ、手元に念のため、対策ソフトを入れてはいるが、手元に来ることは全くなくなった。
つながっていると確かにとても便利で、その前提でサービスを組み立てると、確かにいろんな今までには出来なかったことを考えられる。それに情報をサーバ側に集約するメリットは非常に大きい。したがって、この流れは今後も確実に進むとは思われる。
しかし、従来の代表的なアプリケーションである電子メールにしても、電子掲示板にしても、Webにしても蓄積交換型のサービスというのは、本来は、非同期的にコミュニケーションができるというのが利点だったと思う。都合のよいときに処理できて、相手の仕事を中断しない。Webの実現方法では、クライアント側にキャッシュをして一定の作業環境を作ることは不可能ではないが、情報の整合性を保つことをしっかり考えないと、だまされるようなことが起きかねない。
ネットワークで同期的にサービスが提供されるようになると、病的に、つながっていることに対する依存性が出てきてしまう。携帯電話への依存や、Blogノイローゼはこうしたことに対する不適合性があらわれてきた現象だろう。電子メールにしても、メールが来るとすぐに返事をしなければいけないと思い始めるときりがなくなる。返事をするとまたその返事がすぐ来るということの繰り返しになる。
機械同士だけであれば別にかまわないが、人間が操作しているアプリケーションでは、なにかのリクエストを行って、それがサーバ側で完了し、返事があるまで待つということを強要されるのは、あまり快適なものではない。「ちょっとこれやっといて」と言って別のことができたほうがいい。じっと待たされるのはいやだ。やむをえない場合を除いては、非同期的に動作するほうが、望ましいと思う。
ネットワークとサーバが十分早ければ、作業終了を待っても不便を感じることはないのだろうし、多くの場合実装は容易だ。しかし、現実は必ず有限である。特に、人間のリソースは一定の有限性があるし、有限性を尊重するほうがより健全であると思う。
グラフィCMSでも、この部分はまだ不十分である。現在のブラウザ環境では限界もある。しかし、今後の開発のなかでは可能な限りの非同期性を実現していこうと思う。
最終更新日: $Date: 2008-11-24 11:22:52+09 $
情報の収集、管理、流通
私たちは、データセンターの運用管理だったり、インターネットサービスの基盤を構築する仕事をしてきて、その中でさまざまなソフトウエアを開発してきた。インターネットに限らず、汎用のコンピュータを用いて行う情報処理は、情報を入力したり、収集したりすること、その情報を管理すること、そして必要に応じて情報を流通し、出力することの組み合わせだ。
こうした機能を実現する際に、われわれは作り手なので、素材であるシステムを意識せざるを得ないわけだが、サービスとして提供する以上、サービスの利用者は、本来の興味である、そのサービスを使ってできることに如何に集中できるか、集中できる環境を如何にして作るかということだ。また必要なのは、個々のユーザが独立したシステムを所有することに比べて利点があるものを作るということだ。
情報を入力、管理する時に、置き場所を強く意識しなければならないというのは余計なことだ。Webは、全ての情報を URL (Uniform Resource Locator)という文字通り単一の指定方法で指示できるというのはメリットであるのだが、反面、情報を保管したいときに、多くの場合ユーザは、URLを先に決めなければならない。インターネット上のサーバの名前（場所）、そしてサーバ内での情報の場所である。Web のオーサリングツールといわれるものは、こうした作業の負担を軽減してくれるようには作られているが、決して楽な作業ではない。リンクについては、URL を書かなければならないことが多い。
Wikipedia で使用されている Wiki というシステムは、情報間のリンクについて、データベースの技術により、この点を大きく改善している。
グラフィCMSでは、情報の入力、管理については、この Wiki の方式を応用している。Wiki では、情報は完全にフラットな空間に管理されているが、グラフィCMSでは、階層構造を併用できるようになっている。これは、階層構造の利用は多くのユーザはパソコン上でもすでに使用しており、また階層構造になっている情報をすでに有しているからである。また、完全にフラットな空間では、同名の情報を区別して扱うことができない。たとえば、ロココという名前は、チューリップとバラの品種として存在しているのだが、これを別のものとして管理するには、階層性があるほうが扱いやすい。
そして、階層構造は、情報の保存状態の上では、ツリー構造を形成することになるが、名前をデータベースで管理し、ツリー構造によって、同じ管理空間内での、部分独立性を得るようになっている。そして、この独立した部分に対して、Webサーバとしての名前を与えて、インターネット上に情報を公開できるようにした。
情報には、秘匿性(Confidentiality) の点でさまざまなレベルが存在している。管理している間はこのレベルを変えながら、しかし必要な人が必要な情報にアクセスできる状態を柔軟に作ることが必要となる。こうした中から、同じレベルの情報だけを集約して、Webとして作成しておくと、活用しやすくなる。管理状態から、公開状態への遷移を実装し、この時点で、サーバ名（FQDN) を与えることで、場所を先に決めるという作業から解放されたと考えている。グラフィCMSは、Web 作成を当初目標にしていたが、この機能の充実を計ることで、情報管理ツールとしての位置づけが大きくなった。
さて、Webサーバとしてアクセス可能な状態にするときには、それがどれくらいアクセスされるかによって、サーバの能力を決めなければならない。グラフィCMSでは、基本的には、バーチャルホストの技術によって、同一ホスト上に Webサーバを作成するようになっている。確かにアクセス量とサーバの能力は重要な問題であるが、最初から決められるものでもない。グラフィCMSの開発当初は、今のように仮想化サーバ技術を潤沢に利用できる環境ではなかったため、公開時に、公開する先のサーバを共用のバーチャルホストだけでなく、専用サーバを使うことができるようにした。
Wiki では、情報はすべてデータベースで管理されており、ユーザの Web アクセス時にデータベースから情報を取り出し、Web コンテンツとして表示する。グラフィCMSでは、公開作業時のデータベースから Web 公開する情報を取り出して、ツリー構造に展開して、Web サーバに格納する。ユーザがアクセスする時には、データベースを使用しない。そのためサーバへの負荷を大きく軽減することができる。もっとも検索機能を、公開後コンテンツでは利用できなくなるが、Webコンテンツの検索機能は、Google をはじめとする優れた技術を活用可能である。
実際、サーバ能力を推し量るのは容易ではない。
車を買う時、いくら機械に関心のない人でも、エンジンの排気量を確認しない人はいないだろう。また、車の大きさ、幅、長さは車庫との関係、自分の使う状況を思い浮かべ、大きさを選択するだろう。コンピュータに当てはめれば、CPUの選択、メモリとディスクの容量になるわけだが、車のようにその数値がどのように性能に反映するかが分かりにくいことは確かだ。車がどのように動いているかを知ることは、安全のために必要なので、全く知らなくてよいとはいえない。しかし、それ以上のことはすべての人に必要ではない。
仕事で車を使う人だと、荷物を載せる場所の大きさ、積載量を自分の用途と照らし合わせて考えるだろう。肝心な荷物が載らなかったというのでは話にならない。
失敗しても容易にやりなおしができないので、一旦買ってしまうと、経済的な問題もあり、違う用途が発生したからといって、おいそれと買い替えることができなくて、使い方をなんとか工夫するという涙ぐましい努力も必要になる。
市販の汎用のコンピュータというのは、CPU、メモリ、ディスクといった単純な構成要素を組み合わせ、プログラムによって動作するようにしたものだ。単純な構成要素といえども、ハードウエアの購入ということになれば車と同じことが起こる。
車にしても、レンタカーというシステムがあり、必要な時に必要な車種を必要な時間借りることができる。所有することは一定のメリットはあるが、それ以上のニーズにはレンタカーを利用することは効率的なことである。
サーバの場合も、レンタルシステムは存在しているが、ハードウエアのレンタルではレンタカーほどきめ細やかではない。それは、車と違い、ハードウエアはそこそこに汎用性があっても、ソフトウエアをインストールして使える状態にするには相当な手間がかかるので、柔軟なものは難しい。 この状況を打破してくれるという点では、仮想化技術は間違いなく、画期的技術だろう。CPU (の個数）、メモリ量、ディスク容量は、管理者によって、自由に変更可能である。一旦作って動き始めた後であっても、ちょっと止まってくれれば、あっというまに変更可能である。その上、高可用化機能やバックアップ機能も、利用者が意識しない部分で実現可能であるし、動いているサーバをまるごと複製し、もう一つ稼働させるなどということが簡単にできる。 仮想化機能は、ハードウエア資源を有効に活用するものというような意識もあるが、本当に有効なことは、この能力を可変にできることと、高可用化、機敏なサーバ生成機能の部分だと思う。もっとも、これは一定以上に潤沢なリソースを用意しておいて、その一部を利用するという時に実現できることである。
だからこそ、これはサービスとして提供することに大きな意義がある。仮想データセンターシステムとは、もともとは、複数のサーバに搭載されている、複数のCPU、メモリ、ディスク、そしてネットワークを仮想化技術によって連続的に管理し、そのプールの中から、サーバを生成し、ネットワークを接続し、あたかもデータセンターでラックにサーバ搭載し、ネットワークを接続し、設定するという作業を、コンピュータ上のインターフェースから可能なようにしたものであり、ユーザは必要に応じてサーバ資源を増減することができるのである。
最終更新日: $Date: 2011-10-14 12:54:16+09 $
作るメリット、使うメリット
クラウドというのはネットワークを介して、コンピュータリソースを利用すること一般を指すこともありますが、ここでは、主として仮想化技術を活用して、NISTの定義した5つの要素を満たすシステムのことを指すものとします。
クラウドを作るメリットとしてもっともわかりやすいことは、コンピュータリソースを集中的に投資して、それを分け合って利用することを可能にすることで、それまでばらばらに構築され、ばらばらに運用されているシステムを集約して運用可能にすることができ、投資効率のよいシステムとなるということです。
空いているリソースは、他の仕事のために使えます。共通したものは集中して共有できます。このメリットが活かせるのは、負荷の平準化ができるほどの規模があり、また負荷にそれなりの変動があるものを混在していることです。
現状の技術では、仮想化手法を活用することが一般的です。仮想化は、資源の集約化のメリットもあるので、複数サーバを統合していくことだけを考えても実施は可能です。しかし、固定的なリソースの中で集約だけを行っても大きなメリットを得ることはできません。単にサーバの数を減らす以上の効果を得られることはありません。ましてコスト優先での集約行為は全体の運用にリスク要因を増やすことになりかねません。保守運用のコストを下げることを意識して導入しなければ、自殺行為になるでしょう。
現状は、過渡期であるため、ソフトウエアライセンスの関係からハードウエアを限定するという問題も存在していたりして、まだ矛盾だらけですが、そうしたライセンス体系は自然と淘汰されていき、こうした問題は早晩解消していくでしょう。
ハードウエアを共有し、複数のエンティティでシェアしなければ大きなメリットを得ることはできないでしょう。これは保守運用コストを下げることにもつながります。これが、クラウドサービスを利用することのメリットです。自社でリソースを保有しなければならない事情があっても、保守運用の観点から、サービスを併用してハイブリッド化しておくことはメリットがあります。
これは高速なインターネットが非常に広汎に利用できることになったことが大きく寄与しています。
NISTの5要素を見ると、Rapid Elasticity, On-demand Self Service というものが出てきます。必要なときに必要なコンピューティングリソースを必要なだけ得ることができるということです。システム構築を行っている者にとっては、これを簡単な操作で try and error, scrap and build を繰りかえすことができるというのは、とても大きな恩恵があります。
さて、しかしながら、これらはやはり作る側のメリットです。クラウドシステムを作る人、システムを作る人です。一般のエンドユーザにとってはどうなんでしょう？
一般のエンドユーザ、それもオフィス内でパソコンを使っているだけのユーザには、変化はなにもありません。目の前にあるのは、依然として Windows の画面だし、アプリケーションは同じだし、なんにも変わりません。なんか、ときどき反応が遅くて使いずらい、なんていうのが関の山です。まあ、なにも変わらないから大丈夫ですよ、ということも事実ではあるのですが、それではなんでお金をかけてクラウドシステムにしなければならないのでしょうか？
情報が共有できる、社内のファイルにどこからでもアクセスできる、社内のシステムにどこからでもアクセスできる。確かに技術的に実現できることですが、働くスタイルや、ルールはそうなっていないことが多く、その検討に長期間必要であることから、最新のシステムを企業で使うことはなかなかできません。これは使う側と使わせる側（作る側）双方の問題になります。
いくらシステムを導入しても、大量の資料の紙と、会議会議の連続という仕事のスタイルが変わらなければメリットはありません。
情報には、作成⇒配布⇒使用（活用）⇒保管（保護、管理）⇒廃棄、というプロセスがあるとされています。これを、Information Lifecycle Management といいます。各段階において、適切なツールとルールが存在しなければ、使う側にとってのメリットは生まれません。クラウドシステムは、広汎で、高速なネットワークを内在したものです。したがって、この問題に対していままでと違って適切なツールを提供し、これを広域で共有することができます。
コンピュータシステムとしてのクラウドと、こうしたツールとは両輪であり、両方が実現しなければ、作る側と使う側が目標に向かって真っすぐ走っていくことはできません。
最終更新日: $Date: 2015-02-15 14:10:49+09 $