プログラミングとは経営判断の集積である

ソースコードの一行一行は、経営判断そのものだ。
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。
「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは、投資判断を行っている。なぜなら、プログラマーの作業時間とは、会社の資産であるから、その時間をなにかの価値あるものを生み出すために使うということは、投資以外のなにものでもないからだ。
そして、プログラマーが、ある使い回しモジュールを時間をかけて汎用化するとき、今後もそのモジュールが使われつづけ、役にたちつづけることをイメージしている。そのモジュールは、会社が今後どのような人材を雇い(少数精鋭ならハイスキルの人が使いやすいように、サラリーマンエンジニアを組織化するつもりなら、そういう人にも理解されやすいように)、どのような組織体制で開発し(内部だけで開発するか、外注もつかうのか)、どのような種類のアプリやサービスを開発し(トラブったときの対処をどのようにフレームワーク化するか)、どのような顧客に提供し(生産性重視か、信頼性重視か)、どのようなモノをウリにするか(繊細なユーザインタフェース重視か、機能重視か)によって、どれだけ使い回されるのかが決まってくる。
さらに、もっと恐るべきことは、「わが社は、こういうライブラリや共通モジュールやお抱えエンジニアのスキルセットがあるから、こういうサービスなら比較的容易に立ち上げられるはず」、というように、過去にプログラマーが「なんとなく」決めた共通モジュール化についての意思決定が、会社の将来の重大なビジネス的意思決定を左右してしまうということがあるということだ。
こう考えると、そもそも、ソフトウェア開発を外注に出すというのは、そもそもかなり無理のある話なのだ。だって、ソフトウェア開発とは、経営的意思決定の集積なのだから、経営的意思決定を外部の会社に委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。もっと言うなら、自分の会社の今後のビジネス的ポジションを、他社に決めてもらうようなものだからだ。外注を出された会社は、そのソフトウェアが未来に実現するであろうビジネス的価値を犠牲にして、できるだけ少ないコストで作ろうとする。というか、そもそも、顧客の会社のビジネス戦略を判断するのは、外注先の仕事ではないから、顧客の会社のビジネス戦略と矛盾したような構造のソフトウェアシステムを平気で作り込む。外注を出す側にとっては、ソフトウェアの中で行われた経営判断など、そもそもたいしてアテにしてないし、それが漠然とあったとしても、その価値はよく見えないから、できるだけ買いたたくことばかりに腐心する。どちらにとっても得のない、不毛で非人間的な作業でどちらも消耗することになる。
一方で、ソフトウェア開発には、高度な専門的知識が必要だ。そして、近代社会とは、専門家どうしによる分業によってここまで発達してきたのであって、その分業なしでは、現在の世界の経済規模ははるかに小さなものになってしまっているはずだ。なぜ、分業によって豊かになるのかは、サミュエルソンだかだれだかうろ覚えだが、昔の経済学者が言っていた比較優位の原理があるからだ。その古典的な例では、ある弁護士は、タイプをうつのがとても早く、一時間に8ページもタイプできる。しかし、その弁護士は、自分でやった方がはるかに速いにもかかわらず、自分ではタイプを打たず、一時間に2ページしかタイプすることのできないタイピストをわざわざ雇ってやらせている。タイプで1ページあたり500円稼げるとすると、その弁護士はタイプで一時間に4000円稼げるが、弁護士として働けば、時給2万円稼げる。だったら、1時間に2ページしかタイプできないタイピストを時給1000円で雇ってやらせて、その間弁護士の仕事をした方が、一時間当たり1万6000千円得する計算になる。だから、どんなに得意なことがたくさんあっても、すべてを自社でやってしまえたとしても、企業は選択と集中をし、最も得意な仕事以外はできるかぎりアウトソースしようとする。つまり外注を使う。また、どんな国でも、国際貿易をすれば豊かになれるのも、この原理によるものだ。
つまり、ソフトウェア開発ビジネスは、生まれながらにして、この分業のメリットと分業のデメリットの本質的な(笑)矛盾の上に成り立っている。ソフトウェア開発作業というのは、本質的に切り出して外部の専門家に任すという分業を受け付けないような、経営の根幹となる行為でありながら、同時に、分業によって餅は餅屋に任せないと効率が悪すぎるどころかその実現すらおぼつかないほど高度な専門性を要求される作業なのだ。このため、ソフトウェアエンジニアという専門性をウリにする職業それ自体が、矛盾そのものなのだ
実は、この矛盾を解決する方法がある。それは、ソフトウェアの専門性とビジネスの専門性を兼ね備えた人材が、ソフトウェアアーキテクチャとビジネスアーキテクチャをシームレスというか一体不可分の一つのアーキテクチャとして設計することだと思う。ぼくの知る限り、そういう人材は、ハイブリッド人材と呼ばれることが多いようだ。ぼくの知るハイブリッドさんたちは、日本でも海外でもほぼ例外なく、どの人もけっこうな高給取りだ。ただし、個人的には、「ハイブリッド」という表現は正確ではないと思っている。ハイブリッドとは、もともと二つの異なるものを貼り合わせたようなものを意味するが、単に技術とマーケティングの両方のスキルを兼ね備えた人材とは、彼らはまるっきりちがう。彼らと話していると、回路のビット演算の方式によるパフォーマンスの違いが、そのデバイスが組み込まれたどのような新製品を可能にし、新しくどのようなユーザがどのように使うことを可能にし、それによって何百億円ぐらいの市場を創り出すか、またその開発にはどのような人材をどのような会社から調達することができるか、というような、話がポンポンでてくる。つまり、ビジネスと技術の両方の作業をやっているのではなく、ビジネスとも技術とも言えるようなある一つの行為を、その両方の意味を考えながら行うのだ。分かりにくいと思うので、もう少し描写してみる。たとえば、そういうハイブリッドな人たちは、清濁併せ呑む側面もある。画期的なサービスで社会を豊にしようともするが、その中で、抜け目なく自社の取り分を確保しようともする。たとえば、彼らは、難解な技術用語に満ちた分厚い技術仕様書の細かい文字の中に、お金の臭いをかぎ分ける。またそうでなくては、その手の人材としては使い物にならない。経営とは、単純にユーザ価値を考えればいいだけではなく、ライバル企業との生き馬の目を抜くような競争があり、政治的かけひきにも長けていなければ、話にならないのだ。
たとえば、iモードとかいうサービスのソフトウェアを開発したエンジニアは、開発費をタダにするから、うちのサイトのブックマークを出荷時に設定しておいてくれという要求を出した(もちろん、却下されたが(笑))。そのわずか数百バイトが、どのくらいのキャッシュフローを生み出すかのイメージをちゃんと持っているのだ。一バイト一億円以上の価値は十分にある*1。また、もっとダークサイドの話をすると、ある特定のデバイスのグラフィックチップ市場を牛耳るための仕様の作り込みをし、その政治的意図をライバル企業に見抜かれずに、世界標準仕様に押し込むために、巧妙な技術的詭弁を標準化会議で繰り返すハイブリッド君もいた。場合によっては、仕様策定をわざと遅らせるために、「この部分の技術的仕様が曖昧だから、明確にしなければならない」と高度な技術論争をふっかけ、ライバル企業の製品の出荷を遅らせ、自社の開発陣がその間に追いつけるようにするような、おいらのような、疑うことをしらない凡庸な人間にとっては、ほとんど妖怪じみて見えるハイブリッド君までいる。
じつはここで、わりと深刻な問題が発生する。その問題のために、ずいぶんたくさんの悲劇と悪夢が繰り返されてきた。それは、この、経営とソフトウェア開発を一体不可分のものとしてビジネスをする、という行為が、実は、そういうハイブリッド人材だけに要求される行為ではない、ということだ。
ソフトウェアアーキテクチャというのは、カオス理論で言うところのカオス系の特徴に類似した性質をたくさん持っている。カオス系では、ミクロとマクロに本質的な違いがない。すなわち、極小の部分のごくわずかな差異が、すさまじい規模の効果の違いを生み出す。俗に、バタフライエフェクトと呼ばれる性質だ(アマゾンの森林の小さなチョウチョの羽ばたきが、一カ月後に、ハリケーンとなってメキシコ湾を襲うことだってありえることから、気象のカオス的振る舞いを説明する例に使われた)。これと同じように、ソフトウェアの絡んだビジネスでは、最後のほんの数バイトが、ビジネスモデルを根本から覆すようなことが簡単に起こりうる。たとえば、あるコンテンツ配信プラットフォームで、ほんの数ビット、著作権管理のビットを広く持たせるのとそうでないので、キラーコンテンツのプロバイダが参入できるかどうかが決定しまうことがあった。そうすると、すべてではないにしろ、そのソフトウェア開発に携わる、かなりの部分のエンジニアは、完全にハイブリッドとはいかないまでも、どの部分のコーディングについて、上司のハイブリッド人材の判断を仰ぐべきかの判断ができなければならない。すなわち、膨大なソースコードの中で、どの部分が、ビジネス的、マーケティング的なバタフライエフェクトを起こす可能性があるのかを、見抜けるだけの経営センスがなければならない。
そして、それがいかに困難な作業であるかを、エンジニアが十分に理解してないケースがよくある。経営やマーケティングの人間が、ソフトウェア開発について無理解であり、理不尽な無理難題を言ってくるのの逆だ。ソフトウェア開発は、高度な頭脳労働であり、高度に知的な判断が必要であり、単なる「製造」という行為とは、まったく異なる次元のものだが、そんなことは、営業や経営の人間には漠然としか理解できていないし、甘く見ている。だから、エンジニアが、ビジネス的に大切な仕様変更に対して「技術的な理由」から抵抗すると、頭に来て、影でそのエンジニアの無能さをこき下ろす。ボロクソに悪口を言う。しかし、じつは、経営やマーケティングも、ソフトウェア開発と同等か、時としてそれ以上に、高度な専門的スキルを要求される、高度な頭脳労働なことを、実感値として理解しているエンジニアはほとんどいない。だから、多くのエンジニアは、自分がマーケティングや経営のスキルを磨く訓練をろくにしてもいないにもかかわらず、どのような技術仕様にすべきかを自分は判断できると思い込んでいるし、技術的にやっかいな仕様変更を要求するビジネスマンや経営者の陰口を叩くことはさほど珍しいことではない。
そして、これが何を引き起こすのか、それこそが問題の中心なのである。その問題のヒントは、ハイブリッド人材と、何度か正面から議論してみれば、おぼろげながら浮かんでくるかもしれない。少なくとも、私のような凡庸な人間は、彼らとのミーティングがあるときは、ものすごく緊張する。アドレナリンが出まくる。あらかじめ準備をしまくる。自分の能力以上に能力をはっきするために、全神経を研ぎ澄ます。そのぐらい、彼らは知的にパワフルであり、頭の回転が速く、深い見識と鋭い洞察に満ちている。油断すると、彼らの頭の回転にまるでついていけず、単に話す価値のない人間とみなされ、無視されてしまうか(凹むぜ〜(笑))、矛盾や勉強不足が明らかになって、冷や汗で下着までびっしょりになるはめになる。すくなくとも私はそれを何度も経験した。つまり、ハイブリッド人材というのは、その存在自体がかなり不自然なことが多い。正規分布曲線の右端にいるような、統計学的には3σ以上の外れ値の人間であり、普通、データを統計処理をするときには、処理結果が歪まないように、あらかじめ除外されるような、文字通り例外的な存在だ。*2
なぜ、ハイブリッド人材には3σが多いのか? それは、プログラミングとは、高度な知的作業であり、常人の場合、そればかりを何年も専門的にやってはじめて、ようやく一人前のソフトウェアエンジニアになれるような高度な専門職であり、かつ、経営やマーケティングも、まったく同様に、そればかりを何年もやって究めないと一人前になれないような高度な専門職だからだとぼくは理解している。ということは、ソフトウェアエンジニアリング、経営、マーケティングを一人の人間が兼ね備えようとすれば、3σでないかぎり、どうしても二兎を追う者になって、どれも中途半端な役立たずの人材になってしまうのだ。これに似たようなケースとして、海外で育った日本人の子供は、一部がバイリンガルになって英語と日本語の両方がペラペラになるが、一方で、英語も日本語も中途半端な、「セミリンガル」と呼ばれるコミュニケーション障害を抱えた悲惨な子供もたくさん出てきており、この問題は、言語学者の間で昔から指摘されている。
にもかかわらず、ソフトウェアアーキテクチャのカオス系的性質のために、ハイブリッド人材に率いられたチームのほとんどのメンバーに、かなり高度なハイブリッド的判断能力が要求されてしまう。上司のハイブリッド人材は、自分が手がけている案件をなんとしても成功させたいと思うから、どうしても部下にハイレベルの判断能力を期待する。しかし、それは、そもそも、ぼくたちのような常人の知的能力の限界をはるかに超えている。だから、あるハイブリッドさんたちは頻繁に落胆の表情を示したり(やな感じ〜(笑))、あるいは、ひどいキャラになると、部下をけなす(よくいじめられたよなァ(T_T) )。なんでそんなアホな判断をするのか。なんて使えないやつなのか、と。でも、それは理不尽な要求というものだ。だって、オレたち凡人には、そもそも、そんなもんムリだもん。Intellectual Capacityが違いすぎるんだってばさ。
これは、じつは重要な事態が進行中であることを示唆している。まず、少なくとも、多くのエンジニアやマーケターは、人類がいままでほとんど経験したことのない種類の質の悪いストレスにされされているらしいことは見て取れる。しかし、真に恐ろしいのは、そんなことではない。恐ろしいのは、そもそもレオナルドダビンチ(注: 万能の天才として知られる)になれる素質のないぼくたちのような凡人に、「レオナルドダビンチになれ」という無理難題命令を出したのが、理不尽な上司ではなく、なんと、「社会そのもの」だということこそが、真に恐るべき事態だと思うのだ。よく考えてみれば、その理不尽なレオナルドダビンチ化要求は、ハイブリッド上司の性格がねじ曲がっているために出したわけではないのだ。ソフトウェアアーキテクチャが、(1)本質的にカオス系的な振る舞いをすること、(2)ソフトウェアアーキテクチャがビジネスと一体不可分であること、という2つの、ハイブリッド上司だろうが誰だろうが避けようのない本質的な社会状況がもたらしたものであることが分かる。
そして、この理不尽な社会的要請のために、多くのエンジニア、マーケター、企画屋が、存在価値を否定され、ひどく傷けられ、中には、実際に鬱病になったり、身体を壊したりしたケースはそれほど珍しくないと思う。少なくとも、ぼくはそういうケースを数多く見てきた。ある会社では、数パーセントもの人が鬱病になった。
そして、さらに深刻なことは、これが、IT業界に限った話ではすまされない時代に突入しようとしているということだ。この、ムチャなレオナルドダビンチ化要求を突きつけられるのは、ITやマーケティングだけでなく、法務、ファイナンス、マネージメント、語学などの領域にもどんどん広がっている。単に翻訳するにしても、その本の分野の専門知識をかなり理解してないと、ひどい翻訳になる。ある程度英語ができるなら、原書で読んだ方がマシなケースなんて、少しも珍しくない。また、プログラミングとは、経営判断の繰り返し以外なにものでもないばかりであるだけでなく、金融的・財務的なマネージメントを必要とするものでもある。だから、ほんとのことを言うと、自分がいまから設計しようとしているクラスライブラリの資産価値を、ディスカウントキャッシュフローで考えるというような、ファイナンスのスキルが必要なのだ。なんとなく自分がすっきりするから、という独りよがりで脊髄反射的な判断で、あるルーチンをクラスライブラリにすることに決めてしまったりするなどのように、資本のコストという、財務分析においては基本中の基本とも言える大切な概念が、エンジニアに決定的に欠落していることが珍しくない。資本のコストを考えるなら、資本は常に、利回りを生み出すものだから、そのクラスライブラリによって、得られるメリットを利回りに換算して、その労力を他のことに使った場合の利回りと比較してみなければ、そのクラスライブラリを開発すべきかどうかは判断することはできないはずだ。たとえば、そのルーチンを共通化することに時間を使うのではなく、ほかのやっつけアプリをさっさと仕上げて売り上げをたてて、さっさとキャッシュをゲットして、そのお金で別の人間を雇って、より多くのやっつけ仕事をやらせて、それで浮いた時間を使って、クラスライブラリを開発した方が、結局トータルの利回りはずっと大きいかもしれないのだ。少なくとも、そういう思考スキルを持っているエンジニアとそうでないエンジニアでは、同じ一行のソースコードが生み出す価値の単価が大きく異なってくるだろう。ソースコードのどのモジュールの、著作権、改変権、再配布権、販売権を関係各社でどのように分け合うような契約書の構造にすべきなのかを、法務が十分に理解できていなかったために、すさまじい損害を会社にもたらした事例もあった。でも、そんなこと、ビジネスと法務と技術をかなり詳細まで理解できるような3σ君やダビンチ君じゃないと、無理なんだよ、そもそも。なのに、それを担当していた法務の男性とSE君と営業君は、失敗を追求され、降格され、営業君とSE君は凹みまくったし、法務さんは、結局会社を去ることになった。このプロジェクトでは、営業君もSE君も、契約書を詳細をつめるのは法務の仕事だと思っていて、SE君は、ソフトウェア開発の専門家でない法務君でも分かる範囲にはしょったざっくりとした説明をすれば自分の仕事は終りだと思っていたし、営業君は、ビジネスフレームワークをビジネスの素人に分かる範囲で法務君に説明すれば終りだとおもっていた。しかし、契約書の構造を設計するには、ビジネススキームをビジネスの専門家のレベルで理解し、かつ、ソフトウェアアーキテクチャをソフトウェアの専門家のレベルで理解して、なおかつ、それを法務の専門家のスキルでもって契約書の文言に落とさなければならないものだったのだ。弁護士のチェックをかけるにしても、並の弁護士では、法律的に正しいかどうかはチェックできても、今後のビジネス戦略を描いたうえで、そこに戦略的に必要となるのはどのような権利で、それをどのように確保するのか考えてくれたりはしない。まさに、ハイブリッド君でなければできないような種類の仕事なのだ。
そして、ソフトウェアシステムは、ユビキタスなどという陳腐なキーワードを持ち出すまでもなく、ますます、ありとあらゆる産業の、ありとあらゆるビジネスにおいて、経営の中枢に入ってきている。そして、ありとあらゆる産業において、ダビンチ化が要求されていく。これによって、ますます多くの人が、その無理難題によって、否定され、「負け組」のレッテルを貼られることになる。このシールをほどんど額に貼られずに人生を送れるのは、そもそも、統計処理の対象とされずに除外されるような、一部の3σ君だけなどという、なんか三流ホラーSF小説のようなバカバカしい状況すら一時的にはおきかねない。
しかし、この奇妙なストレスの蔓延は歓迎されないものの、ぼくは、ここに、輝ける可能性への扉も開いているのではないかと感じている。人間とは、自分がやっていることに意味を見いだしたがる生物だ。たとえば、自分が一生懸命やった仕事にたいして、「そんなことやっても無意味じゃん。」という台詞は、ひどい侮辱であり、「ケンカうってんのかよ」という気分になる。そして、この社会がその構成員に要求する「ダビンチ化」は、「自分がやっていることの人間と社会にとっての意味を見極めなさい」という要求なのだ。そのソースコードの、ある部分を、やっつけではなく、汎用的に設計することで、ある特定種類のWebサイトを簡単につくったり、簡単にカスタマイズしたりすることができるようになったために、多くのビジネスマンや企画屋が、それを利用して、すばらしいサービスをどんどん企画するかもしれない。そして、広く安く高品質なサービスがどんどんマーケットにあふれ、多くの人を豊かに、あるいは幸せにするかもしれない。もしくは、それは、エンジニアの独りよがりな空想かもしれない。あるいは、たとえ多くの人に使われたとしても、その時間と労力を別のモジュール開発に使えば、それよりもはるかに多くの価値を生み出し、社会を活性化するほどにまでなるかもしれない。単なる独りよがりな妄想ならば、それは意味のない労働であり、社会を活性化するほどならそれは大いに意味のある労働だ。つまり、「自分のその努力が人間と社会にとってどのような意味を持つか、真剣に考えながら労働しなさい」という、そういう社会的な命令なのだ。それは、ある意味、新しい時代の聖書にでも書かれていそうな、とても人間的な要求だ。「より人間的に労働しなさい」という、そういう要求なのだ。
もちろん、われわれ凡人には、この要求にきちんと答えることはできない(そして、さきほどは分かりやすく説明するために3σさんの能力をわざと誇張して描写したが、実際には、3σさんたちですら、実際には判断ミスをたくさんしているから、3σさんですら、それほどきちんとは答えられていないと思う)。しかし、少なくとも、労働の意味、とくに、人間と社会にとっての意味を浮き彫りにするという点で、かつての産業革命当時に奪われた労働の中の人間性を取り戻すことができるという、ほとんど人類史的な意味で、極めて重大な希望がそこにはあるのではないか。チャールズチャップリンの映画で皮肉られたように、細部まで分割された作業工程と分業と大量生産は、働いている人間に、自分がやっている仕事の全体像についての視界を奪い、まるで自分が社会という巨大な自動機械の歯車に過ぎないかのような非人間的な、いわゆる疎外感をもたらした。自分がやっている労働の人間的意味を見失うことになったのだ。それまで、町の鍛冶屋は、自分がつくったクワやカマを使う人間の顔を思い浮かべながら、鉄をたたき、汗を流していた。妻は夫の顔を思い浮かべながら、はたを織り、着物を縫った。そして、実際に使われる人の喜ぶ顔を見たし、息づかいを感じた。それが、労働の意味そのものだった。労働とは、単なるお金のためにする以上の温かい人間的意味を備えたものであった。社会という有機的な存在を価値あるものに高めるための絆だった。それが、工場の中で、機械やベルトコンベアーでつくられるようになり、それに都合のよいように画一化され、労働というものの価値が、単なる金を稼ぐための手段に過ぎなくなるところまで転落した。「仕事」という言葉は、単に「金を稼ぐ」というのと同じ意味しか持たない価値のない言葉になった。
そして、いま、「仕事」という言葉が、かつての輝ける地位を取り戻そうとしている。社会という、ほとんど神秘的にすら感じられる有機的な存在が、生命体に酷似した自己修復機能を発揮して、仕事という、人間にとって極めて本質的な行動の中に、人間性を復活させようとしている。そして、われわれ人間の知的キャパシティーの限界をはるかに超えて複雑化し、巨大化した現代文明において、そのダビンチ化要求は、ほとんど理不尽とも言えるほどのもののようにも見える。しかし、そうではないのだと思う。われわれは、まだこの、巨大な歴史のうねりに十分乗り切れていないだけなのだ。それが、「何」であるのか、まだよく分からなくて戸惑っているだけなのだと思う。やがて、社会全体が、この、いままさにおきつつある「これ」を実感として理解することのできる日がそう遠くない未来に来ると思う。つまり、「ちゃんとしたダビンチ化」なんてそもそも「完全な円」と同じくらいイデアの世界にしかありそうもないものであるということが理解されるようになる。そして、「ほどほどのダビンチ化」を社会の構成員一人一人が行うことが、社会という有機体が落ち着くべき「落としどころ」であるということが理解される日が来る。そこに落ち着くことができたとき、その過程で起きた数々の悲劇は、人々が労働の中に人間性を復活するために避けては通ることのできないような、いわば、過渡的な、時代の波に翻弄された一過性の悲劇に過ぎなかったと、懐かしく振り返る日が来るのだと思う。

*1:ちなみに、iモードのiボタンを押したときに表示されるメニュー画面は、一ピクセルあたり一億円以上するだろう。銀座のルイビトンがあるあたりの地価の数万倍じゃきかないね(笑)。それくらいの、もしかしたら面積あたり人類史上最高の地価を持つかもしれない超超超一等地だ。究極のリアルエステイトだ(笑)))。それから、iモードの話題からついでに連想したのだが、iモードのUIDの数バイトにすさまじいビジネス的価値を見たエンジニアもいた。((このUIDこそが、ドコモの初期の絶対権力の基盤をつくることになり、多くのコンテンツプロバイダが、この数バイトUIDを賜る(笑)ために、ドコモ詣でを繰り返し、ドコモの担当者に愛想笑いやお追従をすることになった。

*2:よく、ド田舎の平凡な村の平均所得が異常に高いことがあるが、それは、その村の人たちの平均的豊さとはなんの関係もなく、たんに、ITかなんかの詐欺的商法で成り上がった怪しげな成り金長者が、そこで住民登録しているだけだった、なんてことがあるが、それと似ている。ほんとに正しい統計値を計算するには、奇形的なデータは、排除しないと「平均所得」は実体を反映しなくなってしまう。