梅田さんのBlogを初めとした、はてなのBlogを眺めながら感じた違和感について。
人間の思考は、相手が発信する情報によるのではなく、自らの思索の中で醸成されたキーワードを手がかりに、脳内のニューロンがスパークし、その量子状態の結果が、結果的に相手の発信情報を取り込み（繰り込み）、自己組織化することで、意味創生と言う量子化が行われるのだと考えています。
つまり、はてなの電子空間のパトロールのようなキーワード化は、きわめて不愉快であり、情報発信者の意図と隔絶したこの仕掛けは、思考のメカニズム化のそしりを免れません。
はてなの概念に足りないのは、人間の思索の重層性であり、自己組織性です。
実はこの両方にはてなの「技術」は有効ですが、概念が理解できていないためかその適用の方法が間違っています。
聞く耳があればいくらでもアドバイスします。 KAI
導入（２）
２番目の内在する問題、「ユーザーの無知の問題」について。
アプリケーションプログラムで実現される機能は、現場の担当者の頭の中にあって、今後想定される「ルール」の範囲の中にあります。当然の話しですが、想定されない「ルール」が実現されることはありません。
例えば、今まで卸しか行ってこなかった企業が、インターネットによる通信販売に進出することがあります。卸販売におけるさまざまな「ルール」を、そのまま通信販売に適用できないのは、誰が考えても明かです。そこで卸販売用のシステムに加えて、通信販売用のシステムが必要となって、ここで、通信販売の業務担当者は様々なトラブルに遭遇することになります。
一から開発するか、通販用のパッケージソフトをカスタマイズするか、あるいは卸販売用システムを改修して通販機能を追加するか、いずれの方法にせよ、商品の在庫管理は卸、通販共通で行う必要があります。
そうなると、パッケージでは対応できないと言うことが分かります。なぜなら、在庫のデータベースを共有化できませんから、結果的に、在庫情報のバッチ交換しか実現できず、全社の商品の在庫状況をリアルタイムに把握できなくなります。今時リアルタイムを実現できないシステムは使い物になりません。
残る方法、一から開発するか、既存システムの改造かになります。まず一から開発する場合、卸機能を含んで、通販機能を開発する必要があり、これでは通販業務開始に間に合うわけがありません。後は、既存システムの改造ですが、今更レガシーシステムに新機能を追加するわけにも行かないので、オープンプラットフォームへマイグレーションの上、別コンポーネントとして通販機能を実現すると言うのが現実解となります。
しかしこれも、本番稼働に最低10ヶ月は必要となって、通販開始にとても間に合いません。しばらくの間は、暫定システム、ツールを使用した二度入力、三度入力の修羅場を味わうことになります。
しかしながら、これがベストの選択だったのでしょうか。もっと方法はなかったのでしょうか。
ここで、卸販売用システムの開発当時に時代を戻します。
経営者は当然がごとく言います。
「当社は卸専業であり、小売は一切行わない。」
この時点で、システム担当者の頭から、小売に関わる「ルール」が一切消えてなくなるのは当然と言えば当然です。が、果たしてそれでよかったのでしょうか。
「当社は卸専業であり、小売は一切行わない。」と言う言葉の妥当性はさておき、これから開発するシステムで実現する「ルール」から小売に関する「ルール」を排除、あるいは、検討しないと言うのは正しい選択だったのでしょうか。
つまり、もしこの時点で、卸業務の「ルール」にとらわれず、小売を含む販売業務全般の「ルール」をシステムとして実現していたら、上記のような塗炭の苦しみを味わうこともなかったはずではないかと考えるのです。
これに対して「それは無理です」との反論が予想されます。「小売機能まで入れ込んで開発すれば、開発費がとても予算内に収まりません」と。もっともな意見です。
ところがこれは大きな誤解であり、これこそが「ユーザーの無知の問題」であるのです。
ユーザーの無知とは
卸業務に例えば50の業務機能があるとします。小売業務にも50の業務機能があるとすれば、この二つを足すと、
■＜業務機能＞50＋＜業務機能＞50＝＜業務機能＞100
一見このような式が成り立つように思えます。
しかし実際は、
■＜業務機能＞50＋＜業務機能＞50＝＜業務機能＞65
となるのです。考えれば当たり前ですが、冒頭の例でも述べた通り、在庫管理など共通の業務機能が大半であって、二つの業務の「ルール」の詳細である業務機能を足し合わせても、増えるのは一部の業務機能にすぎません。上記システム開発当時、50が65になる程度であることが最初から理解できていれば、まったく違ったシステムの開発を目指すことになったかも知れません。
なぜこう言った勘違い、誤解が生じるのかと言うと、ユーザーの卸業務担当者が、小売業務の「ルール」の知識を持ち合わせていないからです。知識がないから、卸業務と同じ程度の50と見積もるしかありません。これがユーザーの、自分たちが所属する業界以外の業務への無知です。
更に、同じ業界でも、知っているつもりの他社の業務「ルール」に対する無知もあります。同じ業界の競争相手でもある他社には、競争優位となる「ルール」ほど公開しないものです。ユーザーは、現場でやっている自分たちが、一番業務のことが分かっていると思いがちです。実際は限られた範囲の「ルール」しか理解できていないと考えているユーザーはまれです。
それでは、この「無知の壁」は、どうやれば乗り越えられるのでしょうか。以下次回です。 KAI
導入−ルールと言う機能からの導入
具体的な事例で検討した通り、アプリケーションとは、ルールと言う機能を具体的なプログラムの形に定式化したものとみなします。
このルールが変わるたびにアプリケーションを作り直していては大変ですから、通常は、事前に想定されるルールを網羅することで、多少の変化に耐えるアプリケーションが出来上がります。
このプロセスには、二つの大きな問題が内在します。
ルールの意味が理解できていないと言う問題
先の具体例では、二つの仕訳の意味の本質的な違いはありませんが、なぜこう言った仕訳をする必要があるのか、その意味を理解して、想定されるルールを準備するのと、しないのとでは、全く結果が違ってくることになります。
今回の具体例のルールで言えば、会計上のB/S、P/Lと言う概念、意味への理解があるかないかで、出来上がるアプリケーションは全く違ったものになります。
理解できていないエンジニアあるいはユーザー側のシステム担当者は、恐らくこの二つの仕訳の違いがわからず、結果的に以下のような同じ仕訳をしてしまうのです。
■4/11 （消費者）売掛金／売上
■4/25 普通預金／売掛金（消費者）
もう一方が、
■4/11 （消費者）売掛金／売上
■5/10 普通預金／売掛金（消費者）
これではたった一日ですが、会社の資産（負債）の計上漏れが発生することに気付いていません。4/10が決算日と言う期末の一日であれば決算に多大なる影響を与えます。
ユーザーの無知の問題
アプリケーション問題は、このもう一つの内在する問題であるユーザーの無知に起因するものがほとんどであると筆者は考えていますが、これは次回に論じます。 KAI
「バグ・ゼロ」幻想
日経ビジネスに久しぶりに面白い記事が載っていました。（2005.4.25-5.2、p.44）
ではソフト大国インドから見た日本のソフト産業の実力はどうか。東芝とC-DAC（引用者注：インド政府系のIT教育機関）の仲介をしたベンチャー企業、ソフトブリッジ・ソリューションズ（東京都千代田区）のインド人社長、ブラシャント・ジェイン氏は「日本は不思議なソフト大国」と話す。（中略）
もう１つ「日本のソフト産業の成長を阻害している因習がある」とジェイン氏は言う。「バグ・ゼロ」の幻想だ。
「メード・イン・ジャパンは壊れない」。日本製品の品質神話を支えたのは、「不良品ゼロ」を追求するメーカーの執念だった。この常識がソフトの世界では通用しないというのだ。
数百万から1000万行という膨大なソフトでは「バグは絶対出さない」と言う人がいたら「その人は嘘つきだ」とジェイン氏は言う。多少のバグは覚悟しないと革新的なソフトは作れないからだ。
斬新なソフトがもたらす価値とバグのリスクを勘案し、価値が勝る時にはリスクを取る。これが米欧のソフト業界の常識だ。バグ・ゼロの無菌室を目指すのではなく、致命的な部分でバグを出さない工夫や、バグが発生した時の対処方法に力を注ぐ。バグと折り合い、コントロールする考え方だ。
最近のエントリーで書きましたが、
「人間は間違える動物である」ハードウェアは必ず壊れるし、ソフトウェアは必ずバグがあると言うことです。人々はマイクロソフトを非難しますが、マックの爆弾マークは非難しません。これはバグの数と製品への信頼感が無関係であることの証拠です。つまり、すべて、バグがあります。
こう言う人間である技術者が作るソフトウェアと、ユーザーである人間がどうすれば共生関係を構築できるのか、敵対関係ではなく共生関係を構築できるのか、私の大きな夢でもあります。
と言う内容の通りです。
やっと、ソフトウェアエンジニアリングと言う「工学的」特性に対する社会的認知の端緒が見え始めたかなと言う感じです。これは車社会を考えれば全く持って簡単な話です。いくら教習しても事故は起こります。加えて車自体が欠陥によるリコールを重ねていると言う事実を見れば、パーフェクトなどと言う技術は存在しません。
ただ、こう言う状況であっても救われるのは、前掲記事にもある通りOTA（Over-the-air）です。これは本番後に不具合を修正して対策するための技術ですが、残念なのはこの技術がその場しのぎの技術だと思われていることです。
まったく話が別になりますが、物理学の世界で朝永振一郎のノーベル賞受賞が示唆的です。彼は、繰り込み理論によってノーベル賞を受賞しましたが、この繰り込みと言う手法は、当初はただ辻褄合わせの方法と言う評価でしかありませんでした。ところが、この繰り込みこそ結果的に量子状態の自己組織化構造を説明することになります。
OTAとは、この繰り込みと同じ手法であると筆者は考えています。
なかなかこの啓蒙活動には苦労していますが、少しずつ社会的認知を得つつあるのではないでしょうか。 KAI
閑話求題その３
情報と機能の関係性に関して。
実は情報には機能が含まれます。情報についても、状況によりデータと言い換えることで、機能を含まない情報を言い表す場合もあります。
この意味は、機能に言及しながら実際は情報について言及すると言う意味で、実はこれはリカーシブル（再帰化）問題です。更に言えばオブジェクトのDI（依存性注入）も、同じ意味でこの再帰化問題です。Java陣営が今回これを標準仕様としたのも納得できる話です。
このDI技術については別途テーマにして取り上げたいと思ってますが、結局すべての技術の流れがつながっている、すなわちシンクロニシティです。 KAI
閑話求題その２
閑話と言いながら自己組織化アプリケーションの看板が掛かったままです。多少関係するかも、と言うことです。
CNETにSAPのオンデマンドビジネスに関する記事が載っています。
SAPのCEOであるHenning Kagermannは、「オンデマンドアプリケーションが登場したとき、われわれはこれに対し慎重な態度をとるべきだと感じた。オンデマンドは、将来に通じる顧客ロックイン戦略ではない。オンデマンドアプリケーションサービスにより、顧客は自らの運命を第三者へ委ねることとなる。そして2年〜3年後、自らの運命を取り戻せないことに気が付く結果となる」と述べた。SAP幹部らは、オンデマンドのアプリケーションサービスプロバイダがプログラムの修正に対応しない場合、そのサービスを利用する顧客はビジネスのやり方を変更したり、業務改革を行ったりすることができなくなる可能性があると、強調した。SAPでは、アプリケーションが稼働するシステムの所有を可能にする仕組みと、オンデマンドでホスティングするアプリケーションの選択を可能にする機会を顧客に与えたいと考えている。
「ホスティング会社になるつもりはない」とKagermannは述べた。
オンデマンド（ASPサービス）では、自社の業務改革に対応できない、ホスティング会社にロックインされてしまって身動き取れなくなると言う主張です。
普通のオンデマンドでは、この指摘は当たっています。
しかし、私たちが目指す自己組織化アプリケーションでは、これが解決されます。逆に、自社で所有する仕組みの選択の方こそ、その開発の継続という意味で開発会社にロックインされ続けることを意味します。
なぜ自己組織化アプリケーションでは、ロックインが解決されるのでしょうか。それは、一千社以上の業務変革を、たった一つのアプリケーションがすべて吸収して、次々と進化を続けるからです。一切カスタマイズと言う個別のバージョンは存在しません。つまり一つのアプリケーションの中に、業界の一千社の業務仕様がすべて実現されています。自社が、業界の一千社に先駆けて業務改革する内容は限られます。
もし、本当に業界で初めての変革であるなら、私たちは喜んでその改革を標準仕様に組み込んでしまいます。私たちのこの12年間の取り組みの結果が、これを証明しています。 KAI
ひとつ大きな前提条件を、このBlogをスタートさせて以来、書いていませんでした。
私たちは開発したERPパッケージをASPサービスすることを仕事にしていて、まったく受託開発などは前提にしていません。
このBlogも、私たちが開発した製品をどうすれば恒久的な生命力を持った製品に進化させるか、実はこの一点が、本Blogのテーマであります。今続けている自己組織化アプリケーションのテーマも私たちがどう言ういう方向へ行けばいいか、私自身への問いかけであるわけです。
ITについて私は大前提を、30年前の新入社員の時に学びました。
「人間は間違える動物である」
ハードウェアは必ず壊れるし、ソフトウェアは必ずバグがあると言うことです。人々はマイクロソフトを非難しますが、マックの爆弾マークは非難しません。これはバグの数と製品への信頼感が無関係であることの証拠です。つまり、すべて、バグがあります。
こう言う人間である技術者が作るソフトウェアと、ユーザーである人間がどうすれば共生関係を構築できるのか、敵対関係ではなく共生関係を構築できるのか、私の大きな夢でもあります。
閑話求題。 KAI
４次元多様体なんて大上段に構えてしまいましたが、お金、商品（モノ）、情報のそれぞれの流れである「取引」の内容を理解し、これをいかにしてプログラムと言う実体のある形に定式化するか、その方法論を考えることが、今回のポイントです。
あまり抽象的なことを考えていても前に進みませんので、具体的な例を出して検討しましょう。
■通販の支払方法にコンビニ振込と言うのがあるのは、ご存じでしょうか。
バーコードが３つとか４つ印刷されている用紙をコンビニに持って行って支払うものですが、この入金を確認してから商品を発送すると言う販売方法について考えます。
消費者が、あるWebサイトで欲しい商品を見つけました。支払方法の中から「コンビニ（先払い）」を選んで、その場でバーコード付きの振込書を印刷しました。それを持ってコンビニでお金を支払いました（日付は4/10とします）。
この入金情報はコンビニの本部にオンラインで伝送され、2〜3時間後には通販会社に入金があったことが伝えられます。しかし実際にこのお金が、コンビニから収納代行会社経由で通販会社へ支払われるのはずっと後になります（4/25とします）。
4/10時点で通販会社は入金の連絡を受けて直ちに出荷作業に入ります。運送業者が荷物を取りに来る時間に間に合えばその日の内に出荷しますが、間に合わなければ翌日出荷となります（今回は翌日4/11とします）。更にその翌日に消費者の手に届けられました（4/12）。
さて現実に起こった（はずの）この取引の内容を、お金、商品、情報のそれぞれの流れに整理すると次のようになります。
■お金
＜消費者＞(4/10)→＜コンビニ＞(4/25)→＜通販会社＞
■商品
＜通販会社＞(4/11)→＜運送会社＞(4/12)→＜消費者＞
■情報
＜消費者＞(4/10)→＜通販会社＞
＜コンビニ＞(4/10)→＜通販会社＞
ここで、経理の仕訳を行うプログラムを起動すると、以下のような情報操作の機能が必要になることが分かります。
■4/10 （収納代行）未収金／前受金
■4/11 前受金／売上
■4/25 普通預金／未収金（収納代行）
更に、具体的な例を続けます。
■支払方法がコンビニ（後払い）ではどうなるでしょうか。
詳細な説明は省略して結果だけ書きます。
■お金
＜消費者＞(4/15)→＜コンビニ＞(5/10)→＜通販会社＞
■商品
＜通販会社＞(4/11)→＜運送会社＞(4/12)→＜消費者＞
■情報
＜消費者＞(4/10)→＜通販会社＞
＜コンビニ＞(4/15)→＜通販会社＞
仕訳は次の通りです。
■4/11 （消費者）売掛金／売上
■4/15 （収納代行）売掛金／売掛金（消費者）
■5/10 普通預金／売掛金（収納代行）
この二つの例から分かることは、消費者からの入金という「取引」でも、その仕訳方法を見ると、一方は、
■4/10 （収納代行）未収金／前受金
であり、もう一方は、
■4/15 （収納代行）売掛金／売掛金（消費者）
となって、全く異なる仕訳をする必要があると言うことです。
この違いはどこから来ているかというと、「支払方法」と言う概念から来ているのですが、この「支払方法」と言う概念は、「委託販売」や「消化仕入」と言った概念と同じように、取引先との契約内容、やさしく言えば約束、ルールなのです。
このルールとはすなわち、情報と機能と言う関係性で説明すれば「機能」以外何者でもありません。
よく、データこそ重要であって、アプリケーションはその次と言う議論がありますが、筆者がこの論に全く組しない理由はここにあります。 KAI
分割と階層化の限界（３）
自己組織化アプリケーションの対象とする問題領域の特徴として、その問題領域自体の変化です。
例えば原子力発電所を設計する場合を考えると、将来の電力需要と言う要求仕様を満たすための発電設備の設計と言う問題領域に絞り込むことができます。将来の電力需要の増加、設備の老朽化、運転中の周辺環境への影響、核廃棄物の処理、自然災害対応、テロ対策などすべて当初から、問題領域として想定内です。
これに対して、ビジネスの現場を支えるシステムが対象とする問題領域は異質です。
異質とは、時間軸とともに次々と問題領域が変化すると言うことですが、これはなぜかと言うと、ビジネスの現場の問題領域とはその外部環境に十分に開かれているだけでなく、逆に依存する部分が少なくないからです。つまり、外部環境の変化の結果が問題領域の変化を生んでいるのだと考えられるのです。
こう言った問題領域を扱うためのアーキテクチャこそ、前回のエントリーの「自己組織化型」アーキテクチャなのです。
それはまた後ほど詳しく述べるとして、とりあえずこの問題領域への「分割と階層化」の適用を考えます。
ビジネスの中で一番重要な概念が「取引」と言う概念です。具体的に言えば取引先の企業あるいは消費者を相手の、お金、商品、情報の流れが「取引」と言う概念です。これに社内取引と言う概念を導入すれば、ビジネスと言う現場の問題領域は社内、社外を問わずすべて、「取引」と言う時間・モノ・お金・情報を次元パラメタとする４次元多様体問題と捉えることが可能になります。
これを理解するために「分割と階層化」が無力であるというのは容易に想像できることです。（分割している間に分割対象が消滅した！）
さて、それではこの「４次元多様体問題」をどうすれば、理解し、制御できるのでしょうか。 KAI
本日もYAHOO!は障害を起こしています。
本当にYAHOO!技術陣は、もしYAHOO!の仕掛けを利用してミッションクリティカルなビジネスをやろうと考える人たちがいて、彼らから見れば、YAHOO!は「とても怖くて使えない」システムと思われてもしかたがないと言う事実に気づくべきです。
なぐさめではありませんが、確かに、銀行システムも筆者の現役当時毎週のように障害が発生していたのも事実です。言ってしまえば昔も今も進歩していないと言うことです。
しかし一方Googleの安定性をどう考えるかです。
もしGoogleがGmailやGoogleニュースだけでなく、例えば今日YAHOO!で障害のあったオークションにまで触手を伸ばし始めたら、最終的に消費者はどちらを選ぶのか、あっという間にGoogleに軍配が上がると言う可能性があると言うことです。
このことは、現に欧米ではGoogleのシェアがYAHOO!を超えている事実と無縁ではありません。
YAHOO!とGoogle、一方は手作業の最大限の発展形、一方は自動化の最大限の発展形。どちらもインターネットの技術を活用してアプリケーション機能を進化させてきていますが、ここにきて両者の基本的な「アーキテクチャ」の違いが顕著になってきたとも言えます。
もう少し具体的に言えば、YAHOO!は「ヒエラルキー型」アーキテクチャであり、Googleは「自己組織型」アーキテクチャです。
「ヒエラルキー型」技術の典型は原子力発電であり、スペースシャトルです。こう言った技術の特徴は、「すべて計算可能（想定内）」と言う前提の下に将来起こる事象と言う不確定な問題を、技術的に制御する、できると言う思想です。
一方の「自己組織型」技術は、将来計算外の事象が発生することを前提に、これに対してできるだけの機動的、ダイナミックな仕組みのつくりかえ、再編成を実現することに技術の中心をおくと言う思想です。
この思想の実験の取り組み結果は、すでに勝負あったと言ってもいいのではないでしょうか。 KAI
分割と階層化の限界（２）
アプリケーションの本質が、情報と機能の関係性にあるのは、コンピュータ誕生以来当時も今も変わりありません。
この情報と機能の関係性において、機能の方の分割と階層化を目指したのが構造化と言われる設計技法です。この設計技法のメリットは、アプリケーションが稼働するオペレーティングシステムとの親和性が高いことです。
つまり、汎用機のOSを初めとしてUNIX、Linux、Windowsといずれもすべて機能駆動型のOSであるため、アプリケーションを実行させる環境としてネイティブにオペレーティングシステムの機能を利用することができました。実は、この問題が自己組織化アプリケーションのアーキテクチャにも大きな影響を与えるのですが、これは後述します。
一方の情報の分割と階層化を目指したのが、リレーショナルデータベースの概念を初めとしたデータオリエンティッドの設計技法です。
しかし、この技法はうまく行きませんでした。情報と機能の関係の問題でもあるのですが、実際に情報を操作するのは機能であるプログラムです。いくら情報を正規化という形で分割しても、その構造を、それを扱う機能側が理解していないと操作できません。しかもOSは機能駆動型ですから、常に最初に呼び出されるのは機能です。データ中心と言いながら実行は機能であるためプログラムの構造が犠牲になって大半のプログラムは遅くて使い物になりませんでした。
ここで登場したのがオブジェクト指向です。
情報と機能を一つのパッケージで扱うことで、情報と機能の関係をオブジェクトと呼ぶパッケージの中に隠蔽し、かわりに継承と言う形でオブジェクトの階層化を実現します。
Javaの登場がオブジェクト指向の普及を決定的なものにしましたが、当初のJavaは、データオリエンティッドアプリケーションと同様、遅くて使い物になるものではありませんでした。これがOSのAPIと言われるインターフェイスの改善によって、それなりに使い物になりつつあると言うのが現状です。更に、アプリケーションの特性に合ったフレームワークと呼ぶ、機能駆動型OSをオブジェクト駆動型として機能させるための環境の開発プロジェクトがOSSプロジェクトと言う形で進行中です。
ここで問題となるのが継承と言う階層化です。
前回のエントリーで触れた通り、情報と機能の関係は「ノンリニア」であり「疎」です。これが継承と言う形で階層化されれば、本来の階層化の目的である単純化、複雑性の除去と言う方向とは逆に働くと言うのは容易に想像できます。
つまり階層化によって単純化されるどころか複雑性が増してしまうのです。 KAI
分割と階層化の限界
業務系アプリケーションが対象とするビジネスの現場を見ると、その業界毎に、会社毎に、驚くほど多様な取引形態があって、これを顧客情報、商品情報、受注情報と言った情報ベースで整理しようとしても一筋縄では行きません。
顧客情報一つを取っても、例えば顧客住所は、受注担当者から見れば商品のお届け先であり、請求担当者から見れば請求書の送付先になり、プロモーション担当者から見ればDMの送付先になると言う具合に、それぞれの担当者（業務機能）から見て同じ住所でも全く異なる目的があります。
これをもちろん目的別に分けることもできますが、そうなると、業務機能が追加される度に冗長な情報が増えていくことになります。
これが何を意味しているかと言うと、情報と業務機能の関係がリニア（線形）になっておらず、かつ、関係自体「疎」の関係であると言うことです。関係がリニアでないというのは、情報（データ）と業務機能が１対１に対応していないと言うことです。「疎」の関係とは、例え１対１の関係が成立していても、新しい業務機能が追加されると、今までの関係が簡単に解消ないし集約されると言うことです。
こう言った業務系アプリケーションが対象とする問題領域の特性を前提に、アプリケーションを設計、構築するための「アーキテクチャ」をテーマに、しばらく論じたいと思います。
更にもう一つ前提があります。
これから取り上げる問題領域とは、すでにコンピュータによってシステム化が行われている世界であり、手作業をアプリケーション化することは「想定外＾＾」です。この問題については以前のエントリーに書いた通り、ハブシステムによるスイッチを含めて別のノウハウが必要です。 KAI
量を制御するために昔から採用されてきた方法の代表は、分割と階層化です。
毎朝早朝のテレビの天気予報を見ていると、全国の地図を見ながら、それぞれの都道府県の天気を表示しています。この地図の上には都道府県の境の線が引かれていますが、大陸の国境と違って、ご承知の通り実際に物理的に境界を示す線があるわけではありません。
日本全国と言うエリアを管理するために、物理的な土地を、都道府県→市区町村→住所表示と言う形で分割・階層化し、広大な国土の管理（制御）を実現しているということです。
しかし、この例を検討するまでもなく、こういった方法が、問題解決の解を提示するわけではないというのが今回以降のエントリーのミソです。 KAI
今朝方えらいリアルな夢を見ました。
なぜか（夢ですから）教壇の上から、（閻魔大王みたいに）今話題の北○先生が私たち3人の生徒を見下ろしています。
北○先生 「きちんと説明できれば許してやるよ。（何を！？・・・夢ですから）」
生徒(kai) 「私たちの仕事のやり方は、考え方さえあっていれば何やってもいいんです。」
北○先生 「それでは何をやって良いかわからんじゃないか。」
生徒(iz) 「そうです、わかりません。」
生徒(to) 「最初はわかりませんでした。」
北○先生 「普通は上司が目標を示して部下がそれをやるもんだよ。」
生徒(kai) 「普通は、そうですが、私たちは違うんです。目標は自分で作るんです。それを自分で解決していくんです。これをすべてメンバーにメールで伝えます。」
北○先生 「その組織の目標はどうなってるんだよ？」
生徒(kai) 「それも自分で考えるんです。もちろん上司の人も目標を自分で考え、メンバーにメールで伝えます。それを読んで自分で考えます。」
北○先生 「・・・（しばし沈黙）」
北○先生 「それでうまく行くとは思わんね。却下！」
何を却下されたか、思い出せません。 KAI