どこらへんを、この話の着地点にすればいいか、少々迷っています。この三日間書いては消し、書いては消しして、また筆が進まなくなりました。
だいたいこの先のストーリーとして、ASPサービスってえのは、ユーザーとサービスが密結合だからユーザー自身がサービスと同じレイヤーにいる必要があって、逆にお互いが同じレイヤーに同居できないユーザーもサービスも、これはASPサービスと言うビジネスモデルには向いていない、ユーザーでありサービスだってことなんだよ。
と言うような話にしたいのですが、こんな話をしても、まあ普通はワケワカメ。
うーん、いいアイデアはないものか。
今日は出足が遅くて、まだマティーニ1杯目。と言いながらこれから10年続いた星条旗の最後の日。適当に切り上げて顔を出さなくちゃいけないので、アイデアを瞑想しながらとりあえずアップ！ KAI
なぜ機能単価なのか？（２）
アナザーランドとはある意味、インフラです。ビジネスだけではなく、人々の生活を支えるインフラとなるものです。その意味で生活におけるインフラ、すなわちライフラインに相当するビジネスのライフラインが、ASPサービスになります。ライフラインとは、それが一時でも欠ければ生命を維持することができなくなると言う、まさに生命線となるものです。ASPサービスは、このまさにのビジネスの生命線です。
そう言った意味で、サービスをする側も、サービスを利用する側も、世の中の普通にあるサービスと違って、両者はひとたび契約すれば、以降一時も離れることのできない関係にあります。これを業界用語で密結合の関係と言います。
この密結合の関係こそ、今回のビジネスモデルの本質を理解するためのキーワードになるのですが、これはもう少し後で説明します。
ユーザーにとって、例えばマンションと言うハードウェアの住人であれば、マンションの間取りに行動が支配されます。まさか壁をつきやぶることは100％ありません。実は、これと同じことがASPサービスに言えるのです。もちろんここで言うASPサービスとは、私たちが扱っているERPパッケージと言った、単機能ではないASPサービスを指す話なのですが、マンションの間取り同様、ASPサービスはユーザーの行動を制限し、結果的に支配します。
ユーザーからすると、自分たちがASPサービスを利用する、一見、支配しているように見えます。しかし実態は、システムに合わせざるを得ないのです。理由は簡単で、ユーザー側が可変だからです。
この結果、ユーザーとシステムの間を介在する、いわゆるEXCELの達人たちが、ユーザー企業だけではなくコールセンターなどの営業マン、物流会社の出荷担当営業マンの中に、鬼のように存在することになります。きみら、いい加減EXCELを捨てろって＾＾；
と言うことで、この世界の状況が多少リアルに見えてきました＾＾； KAI
またまたやってしまった。どうもマティーニ3杯は、身体ならぬBlogに悪い。2杯だとまだ少しは理性が残っていて、ブレーキがきくのに・・・。と言いつつまたまた放置しといて、つづき、つづき＾＾；。
なぜ機能単価なのか？
そもそも商売とは、お客様に何を買ってもらっているのか、すなわち、何を売っているのか、この明確な認識なしにはなりたたないものです。にもかかわらず、この原点から目をそらし続けている商売があります。それがソフトウェア開発と言う商売であると言うのが、このエントリーでふれた内容です。
しかしこれは考えてみれば当然の話です。そもそも「ソフトウェア開発」と言う商売って、「開発」を売る商売であって「ソフトウェア」を売る商売ではないってことですから。つまり「開発」と言う行為を売る見積もりが「人月」になるのは、しごく当たり前の話だと言うことです。
一方、「ソフトウェア」を売る商売とは、突き詰めれば「モノ」を売る商売ですから、価格は市場で決まります。たとえばパッケージであれば、同様のソフトウェアを他社がいくらで販売しているかが、価格決定の重要ファクターになるわけです。
これに対して、ASPサービスのようなオンラインでソフトウェアを利用する形態では、販売する「モノ」が存在しません。あくまでこれは、利用する権利の販売です。このあたりの考察は、すでにこことかここでやりましたので、今回はこれを踏まえて、もう少し、その先の話をします。
筆者は極論すれば、よほど特殊なソフトウェアを除けば、将来はすべてのソフトウェアがASPサービスによって利用される、そんな社会になると考えています。分野によりますが、将来と言うのも、かなり近い将来にこれが実現するのは間違いないでしょう。
これがどういった社会かよくよく考えてみると、ある不思議な、しかし当たり前の事実に気付きます。それはネットに繋がっていないと、何も始まらないと言うことです。逆に言うと、すべてがネットの中の世界になると言う事実です。
こういった世界のことを、筆者はかねてよりアナザーランドと呼んできました。このアナザーランドにおけるビジネスの有り様こそ、筆者のここ10年余りに渡る重要な研究テーマだったりするのですが、その中での“機能単価”が持つ意味を理解すれば、自ずとこのビジネスモデルの本質が見えてきます。 KAI
ひょっとするとカスタマイズが必要なのかと、誤解するかもしれない読者の為に、前回述べた、毎度繰り返される企業におけるカスタマイズの意味を、もう一度今回、説明します。
そもそもあなたが望む業務の世界って、何ですか？
ほんとうに、あなたが望む世界を、あなたは、理解しているのですか、正しく？
実際は、前任者から引き継いだ文言を、ただリピートしているのが、今目の前のあなたなのではありませんか？
そんなあなたが、えらそうに、どうして、会社のやり方はこうだって、言えるんですか？
え？
実は、あなたが知っている世界は、たった一つ。目の前の自分だけ。
いいかげんお仕舞いにしません？
企業はCEO。小さくてもCEO。そのCEOを、あなたが一緒になってささえる、いやそうではなく、その前にあなたはCEOの志を理解しているのか。
すべての人に必要なのは、カスタマイズとはそもそも何か？と言う疑問です。
車を買って、後からエアコンつければ満足すると言うのを、いい加減止めにしませんか。（マティーニ3杯） KAI
朝青龍は、白鵬に負けていた。このまま勝てば確かに優勝であるけれど、白鵬に負けた優勝と言う、優勝へのけちがつく芽を摘むことはまことに当然のことであります。
かくして決定戦で白鵬に横綱相撲でけりをつける、チョーかっこいい。
しかしもし栃東が負けていれば彼には横綱昇進への可能性が消える。これも回避された。これらすべてが誰かが意図して行えるものではありません。すべて結果です。
横綱の重みとは、つまりこう言うことです。相撲界が、とりあえず、これで安泰を、自分の意志と関係なく、演出された。これが昔からの伝統が持つ、伝統と言う作用の意味なのかもしれません。 KAI
カスタマイズとは？
筆者は根っからのソフト屋です。ですからハード屋とはソリがあいません＾＾；。
ハード屋がソフトを作ると、携帯の電源を入れるのに1.7秒ボタンを押し続ければできるとか、ボタンを2度押せば別のメニューになるとか、こういったボタンの押し方によるインターフェイスが、性に合いません。（とりあえず日常生活は致し方なく適応してはいますが）
しかしなぜそうなるのかは、簡単に理解できます。ハード屋の選択肢はせいぜい200どまりです。ところがソフトの世界は、200なんて話にならないどころか、この上限はありません。つまりソフトはボタンインターフェイスさえ、自由にその上限の選択肢をコントロールができ、つまりハード屋が考えるようなチープなインターフェイスは、まったく不要であるわけです。
これと同じ問題が、ユーザーが要求するカスタマイズにあります。
ユーザーが理解している業務の世界は、筆者が言う「ハード屋」の世界と、寸分たがわず同じです。ユーザーは、これは致し方ないとはいえ、全く自分以外の、他人のことを理解してもいないし、しようともしません。こんなユーザーの言い分をたとえ一つでもきいて、アプリケーションを作ったら（大半の企業はつくっているけれど）、結果できあがるのは、そのユーザーでしか通用しない選択肢200の世界です。
ところがユーザーの業務領域は、日々変化していきます。当然選択肢200では不足します。別の選択肢を増やさざるを得なくなり、これをカスタマイズと呼ぶわけです。ですからユーザー企業が成長する限りカスタマイズが止むことはありませんし、逆にカスタマイズが不要になるとは、その企業が成長をやめたことを意味します。
これに対して、パッケージと言うのがあってこれになぜカスタマイズがついてまわるのかと言うと、実はこのパッケージと称しているものが、ほんとのパッケージではないからです。ユーザー企業の業務を知らないパッケージベンダーが、どこかのユーザー企業の言い分を聞いてつくったものを、あたかもパッケージでございますと言う衣装を着せているだけのことだからです。当然他のユーザー企業にそのまま通用するはずもなく、当然がごとくカスタマイズがついてまわる訳です。
しかしこの構造はパッケージベンダーにとっては、おいしい構造です。受託開発では高いと言う顧客に、一見割安な見積もりを提示できるからです。顧客が金を持っているなとわかると、あとはカスタマイズの名の下に相手のサイフの中身の上限まで価格を吊り上げていきます。ユーザー企業もいまさら他の“パッケージ”に切り替えれないのは、ご愁傷様の限りです。
と、シニカルに評論家をきどるつもりはありません。まったく逆の立場で、このどうしようもない構造をどうやれば変えられるか、筆者のこのエントリーの重要なテーマです。 KAI
なぜカスタマイズ不要か？
なぜカスタマイズ不要かを問うとき、なぜカスタマイズが必要かを問えば、自ずとその答えが出てきます。カスタマイズ必要論者の言い分はこうです。ビジネスプロセスは各社各様であって、すべからく一様には作れない。よってカスタマイズが必要であると。
確かに「ビジネスプロセスは各社各様」であることには同意します。しかし、「すべからく一様には作れない」には同意できません。なぜ一様には作れないのでしょうか。
これは、筆者のKAIモデルでいけば、「すべからく一様に作れる」となって、全く反対の結論が導かれます。この理由を説明するのは少々骨が折れる仕事ですが、目一杯端折って言うと、レイヤー化の方向が90度違っているからです。その結果、密結合の方向が、レイヤー化されているにもかかわらずレイヤー同士が結合すると言う方向になってしまっているからです。（えー？わからん？わからなくて当然です＾＾；）
もちろんこんな話では誰も筆者のプレゼンを聴いてくれませんので、もっとわかりやすい説明を考えるつもりです。
いずれにせよ、もし本当にカスタマイズしなくてもいいなら、ASPサービスにおける大半の問題は解決します。つまりSalesForceを含む今までのASPサービスの一番の問題が、このカスタマイズ要求にあるからです。ASPサービスの提供側はこのカスタマイズ要求に抗し切れず、応じてきた結果、結局受託開発と同じ労力を要するため割安な価格を提示できず、ビジネスとしては拡大しないと言う悪循環に陥っているのが現状です。SalesForceでさえこの問題を避けて通れないのは、以前のエントリーに書いたとおりです。
カスタマイズの必要のないASPサービスは、利用する方もサービス側も、とてもスムーズに導入できます。まさにインターネットに接続されたブラウザが動くパソコンさえあれば、申し込んだ翌日あるいは翌々日には、もうアプリケーションを利用することができます。これはEXCELを買って来て自分のパソコンにインストールして利用するのとは訳が違います。何十台で行う業務のアプリケーションが、こんなに簡単に使い始めることができるのです。
昨日のブラウザの話を含めて、この話は、ヘッポコは理解できるし、ヘッポコでないヤツは理解できないと言う話も、すでに書いたとおりです。この話はますます続きます＾＾；。 KAI
やっと懸案のレポートが仕上がったと思ったら、今度は来月やるフォーラムのプレゼンが待っていました。と言うことで、またつらつらとここでアイデアを書いていくことにします。
今回のプレゼンのテーマは、「ASPサービスと言うビジネスモデルの本質を読み解く」です。
このASPサービスが、将来どういったサービスになっていくか、恐らく今の私たちを含めて誰にとっても想像外の世界だと、筆者は考えています。あたかも日本に初めてマクドナルドを開店した時と、日本で初めてセブンイレブンを開店した時と、同じ状況にあるわけです。
これが当たり前だと今思うものでも、その初期段階では、人には言えない出来事と苦労があり、それを乗り越えてきた結果の、その当たり前であるわけです。つまりASPサービスがその苦労を乗り越えようともがき苦しんでいる状況が、まさにいまではないかと思っています。
ですから、その本質と言っても現在進行形の本質です。それは簡単に言ってしまえば、ブラウザ、カスタマイズ不要、機能単価の三つの単語に集約されるのですが、こんなことをそのままプレゼンしても誰も理解できません。（誰もハンバーガーなんて食べたこともないし、それを作ったことも、売ったこともないのですから）
まずはとりあえず、一つ一つ紐解いていくことにしましょう。
なぜブラウザなのか？
これは筆者の持論である最適環境論から来る必然の帰結です。通信環境の高速化で、LANとWANの境目がなくなった結果、梅田さんの言う“こちら側”にある目の前のパソコンから、モニタ以外のすべてが“あちら側”へ行ってしまったってことです。残ったモニタに、画面を表示させる機能であるブラウザが必要になるのも当然のことです。
しかしこのブラウザが、ASPサービスにとってみると大いにくせ者なのです。初期の頃のような単機能のアプリケーションのASPサービスでさえ、通信速度が今ひとつと言うハンディキャップがあったとは言え、そのトロさかげんにみなうんざりでした。この事情は通信速度が改善された今でも大して変わりません。
ERPパッケージのような高度な機能を実現するアプリケーションは、常にリアルタイムで業務をこなす必要のある現場で使われます。これがボタンをクリックするたびに砂時計が出ていては使い物になりません。つまり、単純にブラウザ＋HTMLの組み合わせではリアルタイムの業務はこなせないと言うことです。
ちょうどいま、CNETの中島聡・ネット時代のデジタルライフスタイルに、“パーベイシブ・ウェブ・アプリケーション”と言う考え方が紹介されていますが、こういった問題を克服する概念の一つといえます。
とは言え、ブラウザです。ブラウザ（＋アルファ）さえあれば、どこでも、どんなデバイスでも、アプリケーションをリアルタイムに利用できる、そんなサービスこそがASPサービスと言えるわけです。（続く） KAI
このBlogを書くのは大抵バーのカウンターの上でだと、以前書きましたが、前回のエントリーもそうでした。ただ、普段はそのままアップしないで、翌日の朝もう一度細かに手を入れてから本番登録するのに、これは酔った勢いのまま上げてしまいました。
そうするとどうなるかの典型的な見本です。つまり、良いアイデアがわくと、文章の組み立てを気にせず言いたいことを、まず一気に書いてしまいます。そのあと、あっちをいじりこっちをいじりして最初からは想像のつかない文章ができあがります。前回のエントリーは、その最初のプロトタイプをそのまま公開してしまいました。ですからちょっとオカシイ。ですが趣旨は違ってないのでこのままにしよう＾＾；（と言い訳して）。
本題です。おなじみのLife is beautifulから。ソフトウェアの仕様書は料理のレシピに似ていると言うエントリーに反応しました。
日本のエンタープライズ系のソフトウェア業界は、そんな根本的に間違ったソフトウェアの作り方を長年してきたために、まるで建築業界のような下請け・孫請け構造が出来てしまい、下流のエンジニア達が十分な経験も得ることが出来ずに低賃金でこき使われ、業界全体として国際競争力をなくしてしまう、という状況に陥ってしまったのではないか、というのが今回の私の仮説である。
この仮説は全く正しいと思います。しかしなぜそんな「間違ったソフトウェアの作り方」をしてきたのか、これを考えないと、一向に解決にはなりません。
なぜそんな「間違ったソフトウェアの作り方」をしてきたのか、理由は簡単です。その方が目先で儲かるからです。もう少し具体的に言うと「人月」（にんげつと読む）商売をしている限り「間違ったソフトウェアの作り方」しかできないし、これ以外の作り方をする必要がないからです。しかも、国や公共団体からして「人月」商売を入札基準と言うかたちで強制するのですから、もはやなにをかいわんやです。（このあたりの考察は以前やってありますので、詳細な説明はこのエントリーから辿ってみてください）
そこで唐突に、Web進化論に関する梅田さんのインタビュー記事を取り上げます。一見全然関係ない話のように見えて、実はこの問題に重要なヒントを与えてくれます。長いですが引用します。
B――おまけに「あちら側でどう稼ぐのか」が非常に分かりにくいから。
梅田 問題はそこです。ウェブの世界というのは、金があんまり回らないんですよ。だからリアルの世界のビジネスを捨ててウェブの世界に来ようという判断は、経営判断としてあり得ないんですよ。
だから、自分たちの事業のベースになっているリアルの世界のビジネスを維持するために、どうやったら橋を架けられるか、どうネットを使うんだ、という視点で行くべきなわけでしょう。
この本についても、中身はウェブの上でずっと議論してきたことが断片としてずっとあって、でもそれで伝わっていた人たちというのはすごく狭い、コアな読者だけだった。ところがそれをきちんと本という形にしてみると、今度は全然違うところへ届いただけでなく、リアルなビジネスになるわけですね。
出版社としてもこれだけ売れれば儲かるし、書店だって儲かるから。何か巨大な歯車がかみ合い始めた感じがしたもんね。本が売れ始めたときの1週間目ぐらいに、ああ、こういうふうにかみ合うのかと。書店はこれを売ると儲かるから売りたい、それから出版社の広告部門も盛り上がってくる、営業部門も盛り上がってくる、みたいに。
逆に言うと、リアル世界は、本当にリアルに動き出すまでは何を言っても何をやっても歯車はかみ合わない。本を出す前というのは「売れるかどうか分からない」から歯車が回らない。だけど何かを証明した瞬間に、リアル側の歯車がかたかたっと動いて、ブルドーザーが動きだす。こんな感じがリアル世界のビジネスですよね。それを初めて自分の経験として実感しました。
（日経ビジネスEXPRESS）
ソフトウェア開発の現場とは、まさにここで言う「リアル世界のビジネス」そのものです。そして要はリアルビジネスも、儲かりさえすれば何でもありの世界ですから、人月商売をやらなくても儲かるんだと言うことを証明してあげさえすれば、彼らはある意味簡単に歯車を切り替えてブルドーザーを動かし始めます。それをすでに私たちは、事業モデルをASPサービスに転換して4期連続の30％以上増収増益を達成することで、ちゃんと証明しています。
つまりソフトウェア開発の現場におけるASPサービスとは、梅田さんが「自分たちの事業のベースになっているリアルの世界のビジネスを維持するために、どうやったら橋を架けられるか、どうネットを使うんだ」と言っている、そのウェブとの間の架け橋そのものにあたるわけです。
もちろんASPサービスが唯一の答えではありませんが、少なくとも私たちのソフトウェア開発の現場には「間違ったソフトウェアの作り方」の入り込む余地など、一切ありません。これは、人月単価ではなく機能単価と言う仕掛けがソフトウェアの作り方に直結しているからです。
ぜひこのあたりの仕組み、仕掛けを、開発現場で苦しむプログラマだけでなく、これからプログラマを目指す若い人たちに知ってもらいたいと、筆者は切に願います。 KAI
システム設計と言う仕事は、もしかして例えば全国網のトラック運送会社の運送ルートの設計担当者の仕事と似ているかもしれません＾＾；。
最新 はじめてのシステム設計（技術評論社、永嶋 浩、2006/02）を読みながら、そう思いました。
トラックを全国にくまなく走らせるためには、全国の高速道路網の地理的理解はもちろん、経済性、効率性、その季節要因（ガソリン代、道路工事など）を把握し、最適なトラックの配送スケジューリングが求められます。この仕事を新人が理解し習得するために必要とする知識の一番は、全国の高速道路マップの理解です。この本は、まさにこの全国高速道路地図に相当します。
その意味で、やっとシステム設計という世界に全国網のマップが作られた意味は重要です。いままでなぜしばらく、この手の書籍がなかったのか、その理由は簡単です。それはあまりにもこの世界の変化のスピードが速かったからです。
そのためかこの本には「フレームワーク」の記述が決定的に漏れています。逆に言うと「ラッピング」の記述があるこの手の書籍にやっと出会いました。ラッピングとは名神高速道路です。フレームワークは名古屋の高速道路です。
え？またわけの分からんことを言う？
そうです、筆者のカーナビは2001年に購入したものですが、これが、おととし姪っ子の結婚式で車で名古屋に行ったときに、全く機能しませんでした。名古屋の高速道路網はここ数年で激変しています。名古屋に入るなり「ルートが変わりました！」とソニーのナビコは喋り捲りで、もちろんナビコが悪いわけではなく、単に最新情報に更新していないKAIが、悪いのです。
これとフレームワークは同じです。今やフレームワークの知識がなければ、アプリケーション設計は手も足も出ません。
ぜひこの書籍の改訂版を望みます。過ちてこれ改めざる、これ過ちと言う。 KAI
やっと12杯目にしてフクダ君のマティーニが、KAIテイストに合格しました。ユーイチ君がKAIのマティーニを初めて作ったときは、3回でＯＫが出てビックリしましたが、彼は特別です。ヨッシーはフクダ君と同じく12杯くらいかかったと思いますが、一緒に行ったクールの古川さんのステアリングを見てコツをつかんだようです。
筆者のマティーニとのかかわりは、以前のエントリーに書いた通り、バーなるものとの出会いにはじまります。このクールへ初めて行った時期と相前後して、今は絶版の山口瞳の「酒呑みの自己弁護」と言う文庫本を読み、以来筆者の人生はマティーニにはまりまくりです。
この本を読んで、筆者にとってマティーニが、すべての飲み物の中の、つまりキングオブカクテルとしてではなくキングオブドリンクとして、筆者の人生を支配し始めたのでした。それから30年、外で飲むときはほぼ毎日が、マティーニです。クールのダブル8杯はあれっきりですが、だんだん杯数も減ってきて、今は2杯と決まっています。
ところがこのところ3杯に増えました。理由はヒ・ミ・ツ＾＾； KAI
梅田さんの虚業という言葉についてを読んで、あらためて虚業について考えてみようとググって見たら、何やら福沢諭吉がからんでいるような話が。そこで諭吉もキーワードに加えて行き当たったのが、以下の書籍福翁自伝新装版（慶應義塾大学出版会、福沢 諭吉 (著)、富田 正文、2000/12）の書評でした。少々長いですが引用します。
とやかく言うまでもなく、本邦自伝文学のぴか一ともされる作。福沢諭吉６４歳の明治３１（１８９８）年に脱稿し、翌３２年に出版された。早速、どしどし版を重ねたという。
維新の志士たちに比べるなら、福沢の生涯はそれほどに波乱万丈であったとも思えない。大阪や九州の中津での少年時代はいささか学問ができ、いささか生意気でイタズラ好きな子どもにすぎなかった。緒方洪庵の適塾での修業時代は大酒で羽目をはずしたり、むちゃくちゃに勉強したりの日々であったが、そうした若者は別段めずらしくなかっただろう。維新のただなかでも徹底したリアリストとしてふるまい、みずから危険に身をさらすことはなかった。
それでいながら、自伝での語り口の激しくも精彩に富むこと。実にたくましく力感にあふれていること。山あり谷あり丘あり坂あり野原ありのドラマチックなうねりに満ちみちていること。ある座談会で安岡章太郎が語っているところによれば、安岡はこの自伝の中で志を抱いて大阪に旅立った諭吉が、途中の茶屋で、タケノコで酒を飲んで勇気を出す個所が好きだという。
「如何にも筍で酒飲むというのも、また福沢的なんだな（笑）。恐らく孟宗竹の、こんな太いやつを、部厚いのを、丈夫な歯でね、バリバリ食いながら酒を飲んでね（略）、それで勇気百倍してまた歩き出すというのね。ああいうところがとっても、躍如たるもんなんだな」
（日刊ゲンダイ書評）
筆者が竹の子太郎であることは以前書きましたが、なんと諭吉さんもタケノコ太郎だったようです。しかも「タケノコで酒を飲んで勇気を出す」なんて筆者のタケノコがエネルギー源であるのと同じではありませんか。
そう言えばあと1ヶ月ほどで実家の母親から、タケノコの薄味の煮込みが送られてきます。これで焼酎の中々をロックで飲むと、もう他のつまみなんていりません。タケノコのあの姿勢がごときまっすぐな味と、中々のあの素直な味が見事にハーモニーして、すでに筆者の身体はハープ状態です。
それにしてもタケノコパワーの秘密とは。これは、まっすぐとスピードです。そのまっすぐとは原色のことではなく、素朴さのまっすぐです。タケノコが一生懸命一気に伸びる様のことです。そのパワーのエキスが、あのやわらかいタケノコの中に詰まっているのは、考えてみれば当然のことです。
と言うことであと五日＾＾； KAI
目下のレポートには役に立たない話題ですが、ASPサービスの本質（の誤解）にかかわる記事、ITProのサービス型ソフトウエアがSAPを駆逐する？？について。
いいことづくめのようだが，ASPサービスにはもちろん弱点もある。
その1つは，業務システムを外部に委ねてしまうことへの不安だ。もちろん，社内でシステムを運用していても，情報漏えいやシステム・トラブルは発生する可能性はある。それでも「自社の目の届かないところで，機密データが流出するのではないか」といった不安を感じるユーザーは少なくないだろう。
もう1つは，企業ごとのカスタマイズに限界がある，ということだ。特に，ERPのような基幹業務システムになると，導入時だけでなく，稼働後も細かい機能修正が必要になる可能性がある。企業が自前でシステムを運用する場合に比べて，ASPサービスでは臨機応変な対応は難しいだろう。
一番目の弱点と言っている部分が、実は今のセキュリティ最優先の時代では、逆に追い風になっていることにこの記事を書いた記者は気づいていません。いまどきシステムをデータセンターに置いていない企業が、実際にどういった企業か調査すれば一目瞭然です。（単に置かないのではなく置くことができないだけ）
二番目の弱点こそ声を大にして言いたい、カスタマイズは不要だ！ってことを。ASPサービスにとってカスタマイズこそ最大の害悪です。オンライブテクノロジーにおいて、カスタマイズとは成長の阻害要因たるガン細胞以外何者でもありません。
当然この話の前提に、カスタマイズしなくてもそのまま使い続けることができるだけの、潤沢な機能とそれを実現するアーキテクチャの存在が欠かせません。逆に言えば、機能もなくたいしたアーキテクチャも持たないアプリケーションでASPサービスを行うのは、全く不可能であることを意味していると言うことです。つまり単機能ならWeb2.0系企業が無料でサービスしまくりだってことです。
とここまで書いて、目下のレポートに役立たないどころか、関係しまくりのアイデアが湧いてきました。ふむふむ＾＾； KAI
大脳時代の経営
煮詰まり続きです＾＾；が、少しずつ整理していかないと。
前回書いたとおり、まず堰を切ること。技術者も爆発寸前、ユーザーも爆発寸前、まさに世の中はハイタイドでいます。いま溢れんとするばかりの状況です。
なぜこうなっているか。これは、人が子どもから大人へ成長する過程でしばしば骨の発達に筋肉が追いつかないために激痛を感じることと、よく似ています。この骨の発達とは、コンピュータの世界では通信を含むハードウェアであり、骨の発達に追いついていない筋肉が、ユーザインターフェイスを含むアプリケーションソフトウェアの世界です。それに技術者も、ユーザーも激痛を感じて爆発寸前まで来ているのです。しかしこの激痛が筋肉の発達を強く促すように、技術者やユーザーにとっても、まったく新しい強靱な肉体への成長に導かれる契機となるのは間違いありません。
強靱な肉体、その筋肉を制御する大脳の発達と言うこの言葉以外に、いまと言う時代を説明する言葉はありません。そうです、若者の健全な肉体と精神の発達を促すために必要とすること、肉体の栄養、精神の栄養、そのどちらもかかせません。同じようにアプリケーションにとって必要な栄養とは、技術者、ユーザーにとっての栄養とは。
このあたりにかすかな光明が、見えてきたり見えなかったり＾＾；。 KAI
いいアイデアがわいてこない。今年の頭からずっと考えてきて、3/20レポート提出期限だから余裕があると思っていたのに、あと10日になってしまった。このところこのBlogの更新が途切れがちなのも、このレポートに頭が行っちゃってるせいです。
なんて考えてたら少しだけヒントになりそうな本が。楽天市場がなくなる日（洋泉社、宮脇 睦、2006/02）と言うちょっと刺激的なタイトルの本です。まあこの本自体の中身は、筆者でも間接的に指摘してきた楽天のビジネスモデルの問題意識にもとづくものです。
先日も灘酒造が倒産しましたが、その理由が焼酎に押されとは笑止です。真の理由は単に消費者の声を聞かなかったからです。楽天と言う日本酒メーカーもいつ焼酎メーカーにつぶされるかわかりませんが、その理由が焼酎メーカーにあるのではなく、消費者の声を聞かない日本酒メーカー側にあるのは誰が考えても簡単に理解できます。
とは言えASPサービスです。
データ移行に2000万円なんてふっかけて、時代の流れに背を向ける石器企業がいまだに幅を利かせています。時代が明らかにASPサービスに移って、そのハイタイド（満潮）の堰を開ける方法とは。眠れない夜が続きます。あともう少しです。 KAI
豚肉の梅肉ソースがけご飯
これは絶品料理です。
まずユーイチ君直筆のレシピから。
生姜、長ネギのみじん切り、砕いた鷹の爪、玉ねぎを、弱火で香りが立つまで炒める。
豚バラ肉を入れて少し炒めたら、鶏ガラスープ（鶏ガラからちゃんととったもの）を入れてナンプラー、包丁で細かくペーストにした梅肉、醤油、白だし、砂糖を加え、肉が柔らかくなるまで煮る。
仕上げにすりおろした生姜を加え、片栗粉でとろみをつけて、ご飯と一緒に皿にもり上にシャンツァイをのせたら出来上がり！
え？おいしそうでしょう？
鶏ガラスープとナンプラーのうま味に、梅肉が効いて、食べててもよだれが出てきます。
しかし、ユーイチ君の料理も、この1年でえらい進化したもんだ。この料理も、ウェンさんのノウハウを随所に取り入れながら、梅肉を加えてユーイチ風味に仕上げるなんざあ、手練れの料理人顔負けの技です。こうして自在に技を操れるようになると、面白くてたまりません。
これからますます進化が楽しみな、ユーイチ君の料理でした。 KAI
久しぶりにすがすがしいセリフを聞いた。
ただ、それでやる気にならない、というのは間違っている。やる気になってガンガン仕事こなして、経験とスキルを積めば、いずれ必ず、会社に残るか、他の会社に行くかの選択権は自分の手中にできると、わしは思っているからジャ！ (`ω´)
（ヘッポコプログラマの日記）
ヘッポコは仕事の本質を理解しています。独立なんかしなくても（独立しても）ヘッポコは必ず企業のトップに立ちます。これをKAIは断言できます。
筆者は常々、ヘッポコのような考え方がなぜみなできないのか、不思議でたまりません。もちろん仕事の内容、給料が多い少ない、上司との人間関係と、条件は様々ですが、結局は「会社に残るか、他の会社に行くかの選択権は自分の手中に」あるか、ないかだけです。ヘッポコは新人でもすでにこれを手中にしています。
この「選択権」を持たざるサラリーマンは、極論すれば奴隷と一緒です。こう言う人に限って、新人である経験者であるにかかわらず、この「選択権」の意味をおもいっきり勘違いしています。いわゆる「労働権」とです。
新人を企業側が雇用する理由は、新人の将来の可能性ではありません。新人の今の可能性です。今、目の前にある仕事をやりとげる可能性を、企業は新人に見出したから雇用するのです。将来の可能性などと言うあまっちょろいものではありません。つまり、企業と新人の関係は、労働権によって選択権が与えられているのではなく、「会社に残るか、他の会社に行くかの選択権」によって、最初から「対等」の関係にあるのです。
それにしてもヘッポコは、天性か。こう言う若者がまだまだいることを知って、KAIもがんばるエネルギーをもらいました。ありがとう＞ヘッポコ KAI
ユーザーインターフェイスの議論の着地点は難しい。
私たちのASPサービスのユーザーインターフェイスも、すべて筆者が設計しましたが、これに対して、従来からの業務系アプリケーションのユーザーも、最近のWeb系アプリケーションのユーザーも、最初は皆ビックリします。なぜなら、ユーザーの誰もがかつて体験したことのない、初めてのインターフェイスだからです。この驚きの後、ユーザーの内心が求めるものと違えばユーザーはネガティブに反応し、反対に何か新しい発見をしたユーザーは、前向きに反応し、やがてこの新しいインターフェイスを受け入れていきます。
この前者の反応をするユーザーを類型化することは、容易です。誰でも求めるものと与えられるものが違えばとまどいます。しかし、求めるものが、常に正しく求めるものであるとは限りません。知らないが故に間違ったものを求めることは、よくあることです。古くは、テレビの中に映画の厳粛さを求めたように、近くはメールの中に手紙の作法を求めたように、です。
つまりユーザーインターフェイスの議論の本質とは、この「求めるもの」と言う価値観と「与えるもの」と言う価値観の、マッチングでありミスマッチングであります。すなわち価値観同士の問題であれば、どちらの価値観が正しくてどちらの価値観が正しくないと言う決着は、永遠につきません。ミスマッチングなら単に相手の価値観に譲歩するだけです。互いの妥協はあり得ません。
故にインターフェイスの議論の着地点は難しい。
しかし、時代が映画からテレビへと、手紙からメールへと、大きく移っていったように、人の価値観はやがて変化します。モニターの中の世界が日常になればなるほど、この価値観の変化は加速します。その先にある価値観が見えているかどうか、すべてのキーポイントがここにあります。 KAI
一千年時空間のコミュニケーション。当然、一千年の間の情報の淘汰によって、後世に伝わるべき情報が、伝わるべくして伝わっていくと、普通は考えてしまいがちです。しかし、これをよく考えてみると、今ある一千年前の情報とは、実はその情報の中身の淘汰ではなく、記録された媒体が物理的淘汰に耐えて生き残った結果ではないのか、と言う疑問がわいてくるのです。
以前、国会図書館の蔵書の酸性紙問題を取り上げたNHKの番組を見た記憶がありますが、50年でボロボロになる（媒体の）情報は、とても一千年時空間を越えることは不可能です。もちろんコピー（写本）も可能でしょうが、コピーによってオリジナルが持つ多くの情報が劣化するのは避けられません。これがデジタル化しても別の意味の“劣化”が避けられないことは前回すこし触れました。
つまりこの別の意味の“劣化”とはコード自体の劣化のことを指しているのですが、これは、コード自体も媒体の一種とみなせば、デジタル化される前の“媒体”の劣化と実は同じ現象であることがわかります。
これらの考察から導かれることは、一千年時空間のコミュニケーションにとっての必要十分条件が、広義の媒体の、劣化対策以外何者でもないと言うことです。
ここに漢字文化圏の出番があるのではないか、と考えるわけです。もう少しこのテーマの考察を続けることにします。 KAI
漢文の素養（光文社、加藤 徹、2006/02）がなかなか面白い。
かつて漢文は、東洋のエスペラントであった。
漢文で筆談すれば、日本人も、中国人も、朝鮮人も、ベトナム人も、意思疎通することができた。また漢文は、語彙や文法が安定しているため、千年単位の歳月の変動にも、あまり影響されない。
日本や中国の生徒は、学校の授業で、『詩経』の三千年前の漢詩や、『論語』の二千五百年前の孔子の言葉を読まされる。これは東洋人にとってはあたりまえのことだ。しかし世界的に見ると、そもそも「古文」がない国のほうが多いのである。
例えば、イギリスやアメリカの学校の授業に「古文」はない。アルファベットでしか書けぬ西洋語は、文字が発音の変化を忠実に反映しすぎて、綴りが百年単位で変動してしまうため、千年もたつと「外国語」になってしまうのだ。英語の最古の叙事詩『ベーオウルフ』は、八世紀の作品であるが、一般の英米人はこれを音読することさえできない。（p.11-12）いまの日本の教育システムでは、英語はコミュニケーションの道具として教えられるが、漢文はそうではない。そのため、若者にとって、漢文はつまらない科目である。
しかし本当のところは、漢文は、千年前の古人や、千年後の子孫と「対話」するためのコミュニケーションの道具になりうる。また、ホームページや電子メールの普及により、新しいかたちでの筆談文化が復活したことで、漢文の「東洋のエスペラント」としての側面にも、新たな可能性が出てきている。（p.231）
この「漢文で筆談」を筆者も体験しました。ただ筆者の場合「漢文」ではなく「漢字」ででしたが＾＾；。台湾の北端の、日本人観光客は誰も行かない街に、家族と友達で行ったときです。レストランに入って注文しようとしても、日本語も英語も通じません。そこで始めたのが漢字による筆談です。メニューは漢字ですからなんとなく中身はわかりますが、お酒や飲み物が載ってません。そこで紙に漢字と絵を描きながら注文しました。実際に出されたものをとっかえひっかえしてやっと乾杯できました。
しかし、この“千年前の古人や、千年後の子孫と「対話」”と言う視点は新鮮です。特に「千年後の子孫との対話」が、果たしてどのように行われるのか、いままで考えたこともありません。ほんの十数年前のフロッピーでさえ、いまでは読むことすらできないのに、これが一千年単位となるとどうなるのでしょうか。
情報がデジタル化された結果、コード変換と言う水平軸だけでなく、時間と言う垂直軸のコードの互換性が問題となります。つまりこれは、時間軸上の互換性を維持するためには、デジタル情報だけでは足りなくて、それがどう言ったコード表を使用しているのかバージョン情報も含めて必要になることを意味しています。しかしこれは大変なことです。
1989年から2010年まではこのコードはこう言う漢字に対応していたなんてことを、それぞれの文字毎に一千年間管理しきれるものでしょうか。デジタル情報自体は何年でも次々新しいメディアにコピーすればそれでおしまいですが、時代が輻輳しはじめるとそれぞれを峻別できるものなんでしょうか。なんだか理解の範囲を超える問題であるような気がします。
とは言え、未来の技術者がなんとか解決していってくれるであろうことを、楽観的に期待することにして＾＾；、問題は漢文です。
「世界人口の四分の一を占める漢字文化圏」（p.17）と言う文化は貴重です。各国いろいろ政治的思惑があるにせよ、この漢字文化を「千年時空間のコミュニケーション」に利用しない手はありません。じゃあそれは具体的にどうやるのでしょうか？（続く） KAI