日本のプログラマはどれぐらい優秀なのか?

「ソフトウェア企業の競争戦略」読書感想文にツッコミをもらった。「日本のプログラマは世界一だというが、定量的な根拠はあるのか?」。企業のパフォーマンスを横断的に評価することは非常に難しい。そもそもサンプリング手法からして評価する必要がある。

それでも暫定的なデータとしてこの本では次の通りに述べられている。引用もとはp.281「第4章　開発のベスト・プラクティス」の「パフォーマンスに関する地域差」だ。

顧客へのシステム導入後12ヶ月で計測した1000行ごとの不具合報告で、日本は最も高いレベルにあった。

　　　　　　日本　　　0.020
　　　　　　欧州　　　0.225
　　　　　　米国　　　0.400
　　　　　　インド　 　0.263

プログラマ一人が一ヶ月で書けるコードの行数も、日本に優位性あり。

　　　　　　日本　　　469
　　　　　　欧州　　　N/A
　　　　　　米国　　　276
　　　　　　インド 　　234

品質の良いプログラムを量産することについては、日本のプログラマは世界一イイィィー、といえる。ただし筆者は「ソフトウェアのイノベーションでは、日本やインドの会社は、真の意味で世界レベルの実績を残していないという点も忘れてはなるまい」、と釘をさしていることも付け加えておく。ここでいう「生産性」を「稼ぎ」に置き換えると、最下位なんだろうねorz

ソフトウェアファクトリーに関するパフォーマンスの調査報告の出典はこれ↓

Michael A. Cusumano and Chris Kemerer,"A Quantitative Analysis of U.S. and Japanese Practice and Performance in Software Development" Management Science 36, no.11 Novenber 1990

「ソフトウェア企業の競争戦略」読書感想文6（最終回）

ソフトウェア「ビジネス」で起業する人向けの話。そのアンチパターンを紹介しているのが「第6章スタートアップ10社のケーススタディ」なのだが、さすが米国だけあって、まさに死屍累々。気持ちいいぐらいの栄枯盛衰。

その10社は、それぞれオリジナルの優れた製品やサービスを有していた。ITバブル華やかなりし米国市場に参入し、人とカネを集め、「モノを作り」、売れずに落ちぶれていった（ただ1社を除く）。筆者は経営顧問や取締役会などの立場からアドバイザリーを行った。どこぞの「動かないコンピュータ」のように、記者の立場から安穏とインタビューした報告ではなく、まさに当事者の一員としてかかわっていた分、生々しい。

報告の一つ一つは、これから起業しようとする人にとっては「めぐすり草」となろう[注1]。最も重要なのが「死のくちづけ」。ベンチャーキャピタルからの資金調達に成功したことを指すのだが、これはなぜ「死」なのか? 答は明らかなのだが、状況により様々な姿をとる。

いったん資金を調達すると、約束したとおりにカネを使わなければならなくなる。ビジネスを構築していく過程で、資金の使い方に注意を払っていれば、もっとよいポジションにいることができたかもしれない

「カネを調達したら、約束どおり使わなければならない」←目論見書には小難しいことがいっぱいかいてあるが、本音はこれやろ。技術や市場の充分な下調べがないまま、経営プロのサポートがないまま起業へと踏み込むと、この「くちづけ」を受けることになる。

「くちづけ」は、製品とサービスのどちらに重心がかかっているかによって、異なる化け方をする。製品を売ることを主眼とする場合、調達した資金は、新規開発費に費やされる。何のためにVCがカネをよこすのかというと、リターンを望んでいるからだ。起業というリスクを一度負いながら新たに開発を始めてしまうということは、種銭を再ベットしてしまうことと一緒。まずいま起業したネタを売ることを考えるべきだろう。売るべきソフトウェアがあるのなら、その市場の顧客全てに売り続ける。一度作って、何度も売ることが極意。Javaの極意が"Write Once Run Anywhere" なのと同様だ。一方サービスで儲けることを目的とした起業だと、調達したカネは、豪奢なオフィスやマネージャ層の新規雇用や新たな販売拠点へと化ける。外部からの資金調達を得る理由は、内部でまかなうよりも、よりスピーディーに有望顧客や市場へ近づくためなのだ。いわばこれらは作られた富、身の丈にあっていないカネなのだろう。

実は、起業できるかと企んでいたネタがある（というか、あった）。ターゲットは「ソフトウェア開発企業」そのもので、売りものは「ソフトウェア開発ライフサイクル全般のプロセス管理スキル」を有した人。売り方はサービスプロセスの均質化と人材開発の注力による「固定価格／固定時間」、即ち時間・コストの遅れはなし（出た場合は追加コストを一切請求しない）。まとめると「ソフトウェア開発プロジェクトマネジメントを人員込みで売る」企業なり。本書でそっくり同じコンセプトの会社の顛末を読んで、あきらめたorz すでに前例があったのね…

* * * * * * * * * *

結論みたいなもの。

本書で何度も強調されてきた「製品を売って、サービスでもうける」という、ソフトウェア企業の基本戦略は、企業に限らず、社畜である私自身にもあてはまることに気づいた。企業と個人の関係で置き換えると、「製品」は「技術」であり「サービス」は「貢献」になるだろう。つまり、私は技術を会社に売って、会社への貢献でもうけることでキャリアを積んでいるのだと考える。

私が新人だったころは「COBOLさえ極めれば、一生喰っていける」あるいは「Cがちゃんとできれば、一生喰うには困らない」と言われた。しかし、かつてバリバリのコボラーや、Cのプログラマは今ではプログラミングをしていない。いや、COBOLやCのプログラミング需要が無くなったとは言っていない、メンテナンスやレガシー更改のため、まだ需要は沢山ある。しかし、COBOLやCを読み書きできるもっと安い給料の若手も沢山いることも事実。さらに、JavaやC++といった、もっと単価の安い言語（失礼！）が取って代わっていることも事実。

そんなわけで、かつてバリバリのコボラーやC使いは、製品の製造過程で身に付けたマネジメントスキルやノウハウ、あるいは特定業界の業務知識やパイプにより、管理職や営業職や指導者へクラスチェンジしている。COBOLなりCといった「技術」にしがみついているわけにはいかない。なぜなら、若手プログラマやJava技術と取替えができるから。会社としては同程度のことを安くあげることができるのなら、むろんそっちに飛びつくだろう[注2]。その代わり、取替えがききにくい「貢献」により employability を向上させることができる。

会社が欲しいのは「そのソリューションを適用して製品化できる人」であって、募集要項「要Javaスキル」はその一例に過ぎない。Javaプログラマとして入社した新人クンは、「Javaが使える人」というパッケージ「製品」としてその「技術」を買われたのであり、恒常的なサービスを提供しつづけなければ、いずれもっと安い「若手Javaプログラマ」という製品に取って代わられることになるだろう[注3]。極端に言うと、究極のプログラマは、一行もコードを書くことなく、製品を生み出すことができる人だろう。MDAが取りざたされているが、ありゃモデルのパターンや部品の数だけコードを書かなきゃいけないので、むしろ業務にロックインされたプログラミングを強いられるオチになろうかと。

COBOL→C→Java と転戦してきたが、次の技術を追いかけるのはちょっと休憩にしてみよう。そして、これまでの経験を基にし、会社の利益に対して貢献できる私なりの方法を形にしてみようと思う。会社であれこの業界であれ、私なりの方法にロックインされるようなサービスを提供できるか、（そのアイディアをカネに換える方法も含めて）考えてみよう。P.F.ドラッカー「プロフェッショナルの条件」で言っていた一節を思い出す。えらい回り道だったが、この「貢献を重視せよ」がようやく分かった気がする。

貢献を重視せよ。貢献に焦点を合わせることによって、専門分野や限定された技能に対してではなく、組織全体の成果に注意を向けるようになる。成果が存在する唯一の場所である外の世界に注意を向けるようになる。自らの専門や部下と組織全体や組織の目的や関係について、徹底的に考えざるを得なくなる。

（;ﾟ０ﾟ）ﾊｯ！ 本の題名が違う…が、まぁ気にしないで下さいませ。だらだらと書きなぐったこの連載をここまで読んでいただき、ありがとうございます。

（おしまい）

--
[注1] 「めぐすり草」を知らないよい子に説明しよう！ めぐすり草とは、「風来のシレン」や「トルネコの不思議のダンジョン」シリーズにでてくる、「隠れていたワナが見えるようになる薬草」のことだ。転ばぬ先のめぐすり草だねっ。

[注2] もちろん一定の年齢以上になっても「プログラマ」として雇われ続けることができる人がいる。しかし彼はその世界では既にネ申のごとき存在となっている。神はそうそういない。

[注3] 話を分かりやすくするために形式知と暗黙知という要素を除いて書いているが、「開発のお作法、暗黙知があるじゃねーか！」というツッコミが入れられる人は、もう「サービス」で会社に貢献しているといえる。

「ソフトウェア企業の競争戦略」読書感想文5

マイクロソフトの開発スタイルの話。カネに飽かせて優秀なプログラマがわんさと集めているマイクロソフト。放っておいても凄いものができるんじゃないの? という人は、少なくともこの記事なんて読まない。良いプログラムは良いプログラマでしか書けないが、良いプログラマさえ集めれば良いプログラムになるとは限らないことを知っているから。ここでの「良い」は各人の好きな内容でどうぞ。

筆者は Windows95/NT/2000 および MS-Office シリーズの開発スタイルを分析し、一つのベスト・プラクティスを導き出している。筆者は「同期安定化プロセス」と名づけている。第4章「開発のベスト・プラクティス」でその詳細な説明があるので、開発手法やマネジメント手法にお悩みの方は読むと得るものがあるかも。

そこで問題。Windows開発プロジェクトチームのうち、最も強い「権力」を持っていたのはどれか?

　　1.プログラマ
　　2.テスタ
　　3.ビルダ

答はマウス反転表示→「3.ビルダ」。「ええっ」と思った方もいるかもしれない（それは私）。モノ作りのメインであるプログラマこそが最も力が強いはずじゃないのか?

プログラマは、同時並行してテストを行うテスタの「相棒」と一対一の組になって開発する。そうした組が3-8人程度で一つのチームを編成し、個々の機能（ユーザが確認できる機能）を作る。それらのチームが、一つの大きな組織のように協同作業する必要が出てくるわけだ。Windows2000 の場合は15-20チームで並行作業していたという。

仕様や設計上の変動要素もある。秒針分歩の技術・ニーズをいつ実装するかという課題もある。そのためWindows の開発では詳細な仕様書を書かなかった。書いてもどうせ変更されるんだ。プログラムの変更に合わせて仕様書との一貫性を保つための作業は、捨てるかもしれない機能のための仕様書を書く作業と同様、リソースを割り当てられることはなかった。

複雑で大規模なプロジェクトを、多くの人員を投入し、同時並行で進める。しかも変更が大いに発生することは予め分かっている。マイクロソフトは同時並行して作業を進めながら、たえず同期を取るプロセスを適用することで、この問題に対処した。そのキモは、

　1.完全な製品のビルドを、毎日、決まった時間に実施する
　2.ビルドの度にテストを繰り返し実施しデバッグを行う
　3.ビルドとデバッグの時間厳守

マイクロソフトの場合は夕方5時がチェックインタイム。この時間までにソースをアップしておくことが絶対条件で、逆にいえば、それさえ守っていれば何をしててもOK。遊んでいようが、夜中だけ働いていようが、部屋から一歩も出てこなくても、何の文句もいわれない。元イスラエル軍戦車部隊の指揮官で、Windows95の品質管理責任者を担当したデーブ・マリッツのコメントを引用する。

組織構造がなければ複雑なことは何もできっこない。ただし、できるだけその体制は見えないようにし、あの気難し屋の開発連中に、何でもやりたいことをできるという幻想を抱かせなければならないのです。一日中、素足で歩き回っていても構いませんよ。オフィスの中にテディベアのぬいぐるみ、どうぞどうぞ。私にとってそんなことはどうでもよいことです。ただし、もしだれかが、夕方五時までにコードをチェック・インしていなかったとしたら、そのときは私がそいつのオフィスに入っていくときだということを、連中はよくわかっているはずです。

プロジェクト・ビルド・マスターはマスター版ソースを用いて毎日「製品」をビルドし、テストする。ビルドもテストもスクリプトによる自動化が図られているため、時間的にはたいしたことはない。ただし、ビルドやテストが通らなかった場合、プログラマは「居残り」となる。イノベーションは任されているし、自由度もある。しかし好き放題にプログラミングしても「製品」は絶対に出来ない。ともすればバラバラになりがちのプロジェクトをデイリービルドで「同期」を取り、その度にテストを実施することで「安定化」を図る。これがマイクロソフトのやりかた[注1]。

マイクロソフトが作っているのは「製品」だ。デイリービルドでは部品ではなく、「製品」を作る。では「製品」とは何か。製品とはビルドとテストが通った機能群のことを指す。どんなに優れたライブラリやクラスでもビルドとテストが通っていないのであれば、それは製品とは呼ばない。それは「在庫」だ。在庫はいくら良質でも、大量にあっても、動かない（動かせない）プログラムだ。酷い言い方をしていいなら、ゴミだ。

「ファクトリー」と銘うたれた日本のソフトウェア企業はこの意識が低い。「製造業」のくせに在庫を「在庫」と思っていない。「製造業」の最たるトヨタを例に挙げる。ジャスト・イン・タイム方式と世間にもてはやされているが、あれは「在庫を道路上に放置プレイ」なんだろ。トヨタに限らず、製造業が蛇蠍のごとく嫌っているのは在庫だ。なぜなら、いかなる在庫であれ、それを保管しておく場所代、管理費（人件費）を要する。そのくせバランスシートでは「資産」として扱われる。一円にもなっていないのに！系列子会社に対し、原材料を工場へ持ち込む時間を細かく指定することで、在庫ゼロを目指しているのだから。トヨタ系列の工場を早朝に訪れてみるとよく分かる。子会社からの原材料を積んだトラックの列が長蛇を成している。それほど「在庫」は悪なのだ。

しかし、ソフトウェアの場合の「在庫」はほとんど意識されない。なにしろ場所代をとらない。コンパイルしてなければ数キロで済むテキストファイルだから。もちろん管理費も取らない。プログラムを書いたらどっかのフォルダに放り込んでおけば一丁あがり。でもやっていることは在庫を量産しているだけなんだ、そいつがビルドとテストを通らない限り。

本書では一言も言ってないが、「製品」を毎日作る同期安定化プロセスは、「在庫」を極力なくそうとするジャスト・イン・タイムにだぶって見える。

また、同期安定化プロセスの説明により、マイクロソフト独自の「それは仕様です」の理由がわかる。仕様書なんて書いていないので、仕様なんてはじめから存在しないのだ。ある操作をすると必ず青画面になったりするのは、開発者が想定していなかった動作であり、そいつは「再現可能な不具合」や「認識された誤動作」と名づけられる。別名「それは仕様です」だ。その「仕様」に対しリソースが割り当てられリリース予定日が決まった時点で初めて「バグ」として認められるのだ、めでたしめでたし…ってザケンナー！

日本（やIBM）を代表とするソフトウェア・ファクトリーでは非常に詳細な仕様書を書く、と筆者は指摘する。それが柔軟な変更や素早い開発（あじゃいる?）を妨げていると断ずる。しかし、できあがったモノに対し「それはおかしい」という指摘の根拠があるわけだ。つまり仕様書にあるから仕様なのであり、無いから仕様ではない、という非常にあたりまえな話ができる。

もちろん「黒は色である」という仕様に対し「白も色である、従って、黒は白である」と展開する顧客もいる。狂っているとしか思えないが「色は黒とする」という仕様は存在する。そして通常、そうした仕様は契約条項として残る。仕様書に書いていないことを要求する理不尽な顧客に対しては「仕様書に無い機能については…」といった免責事項も可能だ。

いずれにせよ、契約による仕事を行う場合の根拠となるのが仕様書だ。これなしでビジネスをするのであれば、契約する相手もいない全く新しいモノに対し仕事をするか、あるいは顧客なんて相手にしない殿様商売の場合に限られる。ま、筆者に言わせるとこのような考え方そのものが「ファクトリー」的な発想なんだろう。はい、分かってます、私は大富豪にはなれませんな(w

（つづく）

--
[注1] このへんの打打発矢は「闘うプログラマー」が面白い。Windows-NTの開発秘話。OSの開発が非常にスリリングに物語られている。ネタとしてはよいが、プロジェクトとしては問題アリだろう。

日本経済新聞は信用できるか

挑発的なのは題名まで。これが「朝日新聞」なら読人は激減するだろう。この本は1997-2004までの日経を読み解いて、その見識の浅さ、煽リスト具合、首尾不一貫性、勉強不足、紋切型、逃口上を淡々と検証している。

例えばバブル経済。日経連載「犯意なき過ち」は興味深く読ませてもらった（かつ面白かった）が、そのツッコミは2chなら一コマで済む↓

　　 ∧＿∧　　　／￣￣￣￣￣
　　（　´∀｀）＜　オマエモナー
　　（　　　　）　＼＿＿＿＿＿
　 　｜ ｜　|
　　（＿＿）＿）

バブルを煽った日経がそう言うなと。「バブル崩壊は予測不可能の事態で、みんな踊らされたのです」論調は、そいつを煽りまくった自戒は一切無し。だいたい同一日の紙面で円高善玉論と悪玉論を仲良く併記できるなんて、節操もないというか日和ん[注1]だねッ

…という訳で米国御用聞カタログレベルの日経について、ここまでホンキで読み解いている著者にある意味感動。そしてamazonレビューイたちも同様↓

おまいら、新聞をそこまで信じて読んでるんだね （つД｀）
新聞で最も信用できるのは天気予報だけだって。
--
[注1] 「ひよりん」と読む。日和見主義のこと。「ひよったな！」は団塊ネタ。「るんらら～」は水色ヲタ。

「ソフトウェア企業の競争戦略」読書感想文4

日本のプログラマは優秀だ。コスト意識が高く優れた品質のソフトウェアを作ろうとしている。しかし、そんな優秀なプログラマがいる日本企業が世界を変えたり、誰かが大富豪になったりしない理由はカンタン↓

コスト意識はあるかもしれないが、ベネフィット（利益）意識をもつ人はいない

コストを削減し生産性を上げることは非常に重要。しかし、それで莫大な利益をもたらしたり会社が安泰になったりすることは、ぶっちゃけありえない。「生産性の向上で○%のコスト削減！」は耳タコだが、「このテストが今週中に通って出荷できれば○千万円の利益が見込めるが、来月までズレこめば○千万円の損だ」なんて聞いたことがあるかだろうか?

「それはプログラマの仕事じゃない！」という反論は、そのとーり。ワタシも激しく同意。その仕事はプログラマの仕事じゃないことは認めるとしても、ビジネスとして会社をやっていくのであれば、会社の誰かがやっている仕事、だよね?

その仕事をプログラマが引き受けてしまった場合、悲劇がうまれる。

この本には、エクスプローラとネットスケープのブラウザ戦争の話が出てくる（以下IEとNN）。モザイクやネットスケープが普及し、IEが参入した頃の話だ。Windowsにバインドさせるマイクソロフトの販売戦略により、最終的にネスケが敗れ去ったと記憶しているが、著者は別の観点から分析している。

マイクソロフトが当初リリースしたIEは酷いものだった。非常に不安定なしろもので、ブラウザがフリーズするならまだしも、青画面まで引き起こすようなものだった。機能も貧弱で、NNと比較するのが気の毒なぐらいだった。

初期のIEを開発したプログラマは、その出来栄えに充分満足して出荷OKをしたわけではないことはわざわざ言うまでもあるまい。むしろ出荷判定にかかわっていないまま「知らないうちに」リリースされていいたんじゃないかと勘ぐる。

酷かろうがなんだろうが、あのタイミングでブラウザ市場に参入できていなかったならば、マイクソロフトは永久に「ブラウザ」を出荷することはなかっただろう。バグだらけで不安定だったとしても、リリースするタイミングは純粋にソフトウェア「ビジネス」として下されたと確信する。品質やコストを重視するのは大切だが、「ビジネス」ではシェアを奪らなければ意味が無い。市場参入のタイミングや、OSにバインドする売り方は、プログラマからすれば正気の沙汰とは思えないが、その決定はソフトウェアの品質やコストとは別の次元で決定されていた筈だ、間違いなく「プログラマ」ではない人によって。

一方でネスケのNN開発はどうだったか? 著者によると、アーキテクチャのモジュール化をほとんど考慮する間もなく、1994-96にかけてコードベースを10万ステップ→300万ステップに拡大したという。その原因は「市場の圧力」即ち「より多くの機能を！」に応えた結果だ。より多くのプラグインを、より便利なショートカットを、よりグラフィカルにetc…　

結局のところ、規模がある臨界点を越えたときから、開発チームは200人全員で二人三脚レースをしているようになってしまった。本当に速いスプリンターがいたとしても、全員の足がつながっているため、最も足が遅い人のスピードで走らざるを得なくなっていた。誰かが失敗したわけでもないのに、チーム全体がつまずいたり、遅くなったりするのがあたりまえの状況となっていた。誰かが「もういい、ここでいったん切り離そう」と言わない限り、200人201脚は離れなくなってしまっていたのだ。

マイクソロフトはソフトウェア「ビジネス」を追求した。彼らはビジネスとして利益を追求するための判断をした。たとえそこに、ユーザーやプログラマの意思が除外されていたとしても、ソフトウェア「ビジネス」としては正しい判断だったのだ。

「ビジネス」の視線を最も端的に表現した発言を引用する。マイクロソフト副社長、クリス・ピーターズの発言だ。太字化は私。自分のblogはときどき読み返すが、この引用文は頻繁に読み返す必要がある、この単純極まりない事実をよく忘れるので。

マイクロソフト事業部門のメンバーの職務は、全員が全く同じです。それは製品を出荷することです。コードを書くことでも、テストをすることでも、仕様書を書くことでもありません。製品を出荷することが仕事なのです。コードを書こうなどと考えることすら避けるべきでしょう。コードを書かずに稼げるのであれば、是非そうしたいものであります。

問題へ戻る。

利益を意識して仕事をする人がいない

問題はここにある。なんちゃってSEや駄目プログラマや能書きマネージャが問題なのではない。そんな奴ぁ日本に限ったことではない（ディルバートを見よ！）。一部のグズが全体の足を引っ張っているなんて、ソフトウェア産業に限ったことですらない。

ソフトウェア「ビジネス」として成立させるための努力を措いといて、「コスト」「品質」「納期」の徹底さえできれば良しと考えている経営が真の原因なり。もちろんそれらは重要だが、ビジネスとして必要なのは、利益を出す、しかも出しつづけること。先に述べた「製品を売って、サービスで稼ぐ」しくみを続けていくこと。やりかたはここで書くのが恥ずかしいぐらいあたりまえだが…

1. 市場を見極め、必要な技術、人材、資金を集める。銀行ごと買ってもOK
2. 製品を作る。作らなくてもヨソから買ってきても可だし、製造会社ごと買ってもOK
3. 製品を売る。販売部隊を買ってきても可だし、営業会社ごと勝手もOK
4. シェアを奪う、あるいは開拓する。「売」らなくても可。シェアを奪るためであればタダでも可
5. サービスで継続的に稼ぐ（バージョンアップなどそのサービスを受けつづけざるをえない状況を作る）
6. ↑のやり方を「業界標準」化することで、自社と業界そのものをバインドさせる
7. ↑で得た自社株やブランドを元手に1へ戻る

あれ? どこかでこのやり方を目にしたような…なんのことははい、孫正義氏がやっているやり方ではないか。毀誉褒貶が激しい人物だが、彼がやっていることは「ビジネス」なんだと思う。日立や富士通と比較した場合、「人材」レベルでは雲泥の差のソフトバンクが（失礼！）そうした大企業と伍している（ように見える）のは、ソフトウェア「ビジネス」とソフトウェア「ファクトリー」の差なんだろうねッ。

近い将来、孫氏は大富豪になるかもしれないが、大企業のあるマネージャが大富豪になる可能性は、ずっと低いだろう。孫氏が世界標準となる技術を手にする（開発する、ではないよ）可能性はあるかもしれないが、大企業のあるマネージャがそうなる可能性は、ずっと低いだろう。

（つづく）

「ソフトウェア企業の競争戦略」読書感想文3

我が日本のプログラマはァァァァ世界一ィィィィィ（シュトロハイム風）の話。ここでは、そんな優秀なプログラマを抱える日本企業が、海外雄飛できない理由を書く。

バカな!? 自動車を代表とするメイド・イン・ジャパンは世界に通用するはずなのに、ソフトウェアビジネスでは例外なのか?

日本のソフトウェア企業が優れたアプリケーションプログラムを書いたり、極めて高度な統合システムを構築する技術・能力を有することは明白だろう。それは、メガバンク金融システムや新幹線の制御システム、テレビゲームに至るまで、さまざまな事例が証明している。

しかしこうしたシステムの多くは、特定の顧客専用に作られたものであり、設計上のイノベーションといえるようなものはほとんどない、と著者はいう。

日立、富士通、NEC、東芝、NTTのようなメジャーなソフトウェア企業は、主にハードウェアやサービスを販売するためにソフトウェアを書いているのであり、これはIBMが数十年にわたりたどってきた道にほかならない。

太字化はワタシ。営々とやってきたことはIBMのものまね師[注1]なわけね。ぐぅの音も出ないまま「TRONなら…」とチラと考えたが、読み進むに従ってその未来が見えてきた（数ある未来の一つと思いたい）。著者は、日本では基礎研究や大学教育に対し充分な教育を行っていないと指摘する。コンピュータや情報システムに関して、貧弱な教育しか行ってこなかった結果、日本のソフトウェア企業は、従業員の大部分をOJTで教育していると指摘する。

その結果、ソフトウェア開発は主に製品製造過程での課題の一つとして扱われるようになった。いくつかの例外を除くと、筆者がよく知っている日本の大企業は、経験則、プロセス上の統制、いくばくかの資本、そしてマンパワーによって、大規模システムに取り組んできた。文字通りの「ソフトウェア・ファクトリー」なのである。

ソフトウェア・ファクトリーという製造方式は、標準化された設計パターンに従い、元の条件からはほとんど変更しないカスタムアプリケーションを複数バージョンや、その亜流を大量生産することに向いている。一言でいうと「製造業」やね。与えられた「コスト」「納期」「品質」の中で、コストをいかに削減し、納期をいかに短縮し、品質をいかに高めていくかを追求することが至上命題というワケ。

「そんなことアタリマエじゃねーか！」というツッコミ上等。ワタシ自身もそう思ったから。しかし、そこには「ビジネス」という観点が抜け落ちている。ビジネスというと語弊があるなら商売といいかえてもよい。次の例で考えてみよう。

【例題】サービス開始直前に機能の追加を要求する顧客がいる。当然のことながら当初の仕様書にないことを要求してくる。

【解答?】ビジネスとしての視点があるなら、その機能が（サービス開始直後に）無いことで、何ドルの損失があるのか、サービス開始に間に合うことで何ドルの利益をもたらすか、という問いかけをするだろう。そして、理不尽な要求（?）をする顧客もいくらいくらであると回答しようとするだろう。

日本でもちょっと商売っ気のあるSE・プログラマだとこんな話のもって行き方をするが、おそらく良くてプライオリティ付や裏取引、悪ければ感情論や根性論に陥る。仕様書にない要求を直前になって言い出す客がいるのは米国も日本も同じ。その対応の差がソフトウェア「ビジネス」とソフトウェア「ファクトリー」の差だ。

日本には、良いもの（優れたもの・効率よく・高品質なもの）を作ろうと心がけて仕事をするプログラマは沢山いる。しかし、儲かるものを作ろうと考えながら仕事をするプログラマは皆無だろう。「このプログラムで大もうけしてやろう」とﾆﾔﾆﾔしながらビルドする奴がいたらちょっと不気味だが、その数は米国の方がはるかに多いに違いない。

（つづく）

--
[注1] 「ものまね師」を知らないよいこに説明しよう！　「ものまね師」とはファイナルファンタジーVのジョブ（職種）の一つ。転職はかなり大変だがものまね師は、前のキャラの動作をそっくり真似をする特殊技能「ものまね」を持つ。これが重宝するんだな…って、もう古典だねっ＞FFV

「ソフトウェア企業の競争戦略」読書感想文2

ソフトウェア企業の競争戦略の原則は製品を売ってサービスで儲けることに尽きるよ、という話。とてもあたりまえなことなのだが、意外と見落とされている古くて新しい視線。

これは「ソフトウェア企業の競争戦略」でガツンと思い知らされた。本書によると、生き残るソフトウェア企業はすべからく「製品→サービス」へ変遷をとげているが、完全にサービスに移行するわけではないという。製品とサービスが半々のハイブリッド形態を呈する。「製品」と「サービス」の違いとは、

製品	サービス
一過性 「パッケージ」というオブジェクトで提供 コピーしやすい 規模の経済が適用できる 新規に市場に参入しやすい あたればでかいが、なかなかあたらないのが現実	持続性 形（オブジェクト）を持たない コピー困難 顧客増→コスト増 市場参入に一定の評価（ブランドともいう）が必要

たとえばネットゲームの例。かつてゲームメーカーは「メーカー」の名の示す通りパッケージ製品を開発し、世に送り出していた。現在ではパッケージの名を持つオンラインゲームサービスを提供している。ファイナルファンタジー・オンライン（FFXI）やウルティマ・オンライン（UO）などが有名。

パッケージ製品には、規模の経済を適用することができる。ゲーム一本の開発費に莫大な資源を投じても、いったん「製品」ができあがれば、そのコピーを作るのは容易。ソフトウェアは目に見えないが、「パッケージ」というモノとして切り取られた形なので、売るほうも買うほうも扱いやすい。言い換えると模倣もコピーも容易のため、亜流や海賊版に悩まされることになる。

一方、オンラインゲームサービスは、提供しつづけていく必要がある。作って売ったらお終いではない。「製品」のコピーにかかる費用は、作れば作るほどゼロに近づくが、「サービス」は提供先が増えれば増えるほど、その費用は増大する[注1]。ソフトウェアは目に見えない上、サービスもさらに目に見えない（モノとして存在しない）。サービスを評価するためには一定の期間が必要で、良し悪しの判断は難しい。製品同様、ヒット作の亜流は存在するが、その「サービス」までもコピーすることは不可能。

「ファイナルファンタジー」というゲームに着目してみる。昔はパッケージ（カートリッジやCDのROM）形態で売り出されていた。「大作主義」と呼ばれ、美麗なグラフィックやムービーに莫大な費用をかけていた。一本一本のコストがでかい分、外れた時のリスクが大きく、社としての屋台骨をゆるがすほどだったらしいく[注2]。

現在では FFXI という名でネットゲームサービスが提供されている。作っては売り、作っては売りするのではなく、ネットを通じてひとつのゲーム世界をレンタルする。不具合や世界の広がりは、パッケージのバージョンアップではなく、メンテナンスにより実現する。

もちろんインターネット環境の整備やリッチクライアントの普及に負うところが大きいが、製作元の利益を得る方式の転換と見たほうがよいだろう。一本のゲーム（=プロジェクト）にコストとリスクを積み上げるよりも、「ファイナルファンタジー」というサービスブランドで長く売っていく方が得策だと判断したに違いない。

本書では、ゲームメーカーをリサーチの対象外としている。「ソフトウェアビジネスモデル」にはそぐわないらしい…が、同様のことは Oracle や Microsoft にも言える。両社はその看板製品のバージョンアップを繰り返しつづける一方で、その製品を元としたサービスを長く売っていこうとするだろう。単なるDBやOSではなく、継続的なサポート／サービスを必要とするアプリケーションサーバを販売の中核に据えていることがその証左といえる。

製品でシェアを確保し、サービスで恒常的に利益をうみだすビジネスモデル。これ最強（というか、これしかない）。「製品だけ」あるいは「サービスだけ」に注力する場合、ビジネスとして継続的に続くことは、ない。

言い換えると、スゴい製品を開発し、市場で大ヒットしただけでは、大もうけするかもしれないが、恒常的な利益を得ることはできない。また、スゴい技術を持っていて、そのサービスが大いに期待されているだけでは、利益を全く得られないまま風化するリスクは多々ある。いずれの場合も、ビジネスとして成立させるためには不十分。片方だけを引っさげて颯爽と参入するベンチャーは多々あれど、ビジネスとして成立しないまま上場資金を食いつぶして消えてゆく。

ベンチャーの流れは絶えずしてしかももとの社名にあらず
IPOに浮かぶボロ株はかつ消えかつ結びて久しくとどまりたるためしなし

（つづく）

--
[注1] もちろんオンラインゲームもパッケージ「製品」という形で有償／無償問わず頒布していることは合点承知。しかし、その「製品」単品だけでは充分遊べないことも事実。

[注2] 大作主義　…　死語なのだが、もはや死語ですらないかも。某社の「シェンムー」のように一本のゲームに社運を賭けるのは無謀かと。

正しいorz

ここを見てキミも正しいorzをマスターしよう。ポーズとっている女性がなんかエロい。

1. ハダシになる
2. 両手とひざで体を支える。このとき、肩の真下に手が、腰の真下にひざがくるようにする。肩甲骨－背骨－腰が一直線になるようにイメージする
3. そのまま息を吸い込みながら、床を押す感じで、背中をぐっと反る（牛のポーズ）
4. 次に息を吐きながら、頭を落として背中を丸める。お尻を落とす感じで（猫のポーズ）
5. 呼吸を整えながら牛のポーズと猫のポーズを繰り返す

コツは尾骨にシッポがあることをイメージしながらシッポから動き始めると良いらしい。やってみると、腰がスゴく楽になるるる～　腰でお悩みの方はぜひお試しあれ。

委譲できるのは権限までであり、責任は分担できない

PMの孤独感とは、プロジェクトマネジメントの成功・失敗の責任を負うのは自分だけなのだという認識からくる。仕事量を減らすため、マネジメント対象（スコープ・スケジュール・コスト・リスク・人材）ごとに担当を割当て、権限を委譲すればよいとアドバイスされるが、委譲するのは権限だけであって、責任まで分担することはできない。

たとえば extends を使ってスーパークラスの性質を継承させることができる。サブクラスに振る舞いを「委譲」しているわけだ[注1]。振る舞いが問題ないことはスーパークラスが保証する。この場合、責任はスーパークラスが負っている。

あるいはアサーションを使って契約によるプログラムを徹底させる。事前／事後条件（の完全さ）をプログラムに組み込むことで、責任を外出しにすることができる。この場合、責任はそのクラスを使う側が負っているといえる。

しかし、マネジメントについて言えば、事前条件も事後条件も最終チェックするのは責任者であるあなただ。たとえ成果物をチェックする機構を取り入れるとしても、その機構の妥当性そのものを確認したり、そこでチェックOKとなった成果物を受け入れるか否かの最終判断を下すのは、やっぱり責任者であるあなただ。

権限を担当に割当て、担当を人に割当てることで、「その担当としての責任」があるじゃないか、という反論は可能。ただ、誰にどの権限をどこまで割当てるかもPMの仕事になっているため、人材と担当のミスマッチによる失敗もPMの責任と化す。担当としての最後の言い逃れは「指示どおりにやったのですが…」だが、PMには使えない。

ここで誤解されるのが「責任者」。責任者は責任をとるために存在するのであって、それ以外の何者でもない。いかなる前提の下であれ、サインしたのなら責任を取れ。逃げるな。責任を取ることがどういうことなのか分からないのであればサインする資格なんて無い。仕事割りやダンドリが得意なだけでPM目指してるそこのアンタ！　…というのは実はワタシだったりする。

理論も実践も精進が必要。「がんばれ受験生」の季節になると思い出す。むかし「大人はいいなー勉強しなくてもいいから」などとほざいていたが、オッサンになった今の方が勉強している。勉強だけで「責任を引き受けられる人」になれるとは、これっぽっちも思ってないが、「勉強してない責任者」ほど恐ろしいものはない。

頑張れ俺、もっと頑張れ。

--
[注1] 本来の意味での委譲（Delegation）は継承と異なることは合点承知之介

「ソフトウェア企業の競争戦略」読書感想文1

この企業の社畜として、自己の立ち位置を再確認するために読んだのだが、結局のところ、ど真ん中の一冊になった。「ソフトウェア企業の競争戦略」を紹介していただいたこの記事に感謝。好川さん、ありがとうございます。ソフトウェアでメシを食べている人は必読だろうなぁ…。理由は次の通り。

ソフトウェア・ビジネスが一般のビジネスと違いが無いのであれば、本など書く必要がない。この本は「ビジネス」としてみた場合の「ソフトウェア企業」を冷徹な視線で語っている。ソフトウェア・ビジネスとして成立させるために必要なことは「製品とサービスのハイブリット形態」なり。製品は市場に参入し、シェアを確保するため、サービスは恒常的な収入を得て、好不況の波を越えていくために必要。マイクロソフト、IBM、オラクル、SAP、シーベル、i2テクノロジーズの例を挙げて、その必要性を詳細に語っている。

世界と比較して、日本のプログラマは優秀か? 答えはYes[注1]。日本のプログラマの品質は、世界最高の水準か、それ以上だという。プログラマは優秀なのに、日本のソフトウェアビジネスがパっとしない理由も書いてある。それは品質重視の工場型モデルを（相も変わらず）採用しているからにほかならない。「良いものを作れば売れる」主義を信奉するあまり、ビジネスの本質から離れてしまっているらしい。

例えば欧州企業にとってソフトウェアは「科学」として扱われる。コンピュータサイエンスとしての「ソフトウェア・ビジネス」であるがゆえに、形式的手法やオブジェクト指向分析・設計手法が重視される。また、米国企業にとってソフトウェアは「ビジネス」そのものとして扱われる。会社をつくって「まぁまぁ良質」の製品を作り、業界標準を打ち立て、その過程で大儲けしようとたくらむ。

しかし、日本企業にとってソフトウェアとは「工場出荷製品」そのもの。文字通り「ソフトウェア・ファクトリー」を目指している。標準化された設計開発工程に則り、仕様からほとんどブレない製品を粛々と出荷することを随一としている。「良いものを作れば必ず売れる」信者の松下イズムが蔓延しているため、ソフトウェア・ビジネスの最もメジャーな課題「何が欲しいのか分かっていない顧客に売る」ビジネス視点が抜けている。

「ソフトウェア企業を創って世界のルールを変えてやろう、その過程で大儲けしてやろう」ことがヤれるのは、米国だけなり。でも、沸騰しまくっている米国でヤっていけるのかも、やっぱり書いてある（つづく）

--

[注1]なにを根拠に「世界」というか? 筆者の研究（っつーかフィールドワーク）は以下の企業を対象としたらしい。日本、米国、欧州、インドの主なソフトウェア企業だろう（もちろん漏れているのも多々ある）。

　マイクロソフト
　IBM
　NEC
　富士通
　日立
　オラクル
　SAP
　シーベル
　i2テクノロジーズ
　ビジネスオブジェクツ
　タタ

PMBOK3とPMBOK2000の違い

PMBOK 3rd Editionをぼちぼちと読み始めている。ボリュームはPMBOK2000の1.5倍ある（400頁）。1996年に初版、2000年に2版、そして2004年に3版と版を重ねてきたPMBOK。オンナであれWindowsであれ、3番目から具合がよくなってくるといえるし、PMBOK3も同じに違いない。ダイターン3やザンボット3と同じように、PMBOK3も無敵になるといいねっ。

一言で言うと「隙が無くなった」。2000版はツッコミどころ満載で「書いた奴ぁ現場知らないね」と毒づいていたけれど、3版は隙なし。あやふやにぼかしているところが無い。語句の統一性（動詞-目的語）や明確さと具体性を追求している分、わかりやすい英語になっている。不得手な私でも分かる（スピードは出ないけれど）。難しい言い回しや語句は減っている。言い換えると翻訳ソフトとの親和性が高いベタな文になっている。

PMBOK2000→PMBOK3の改訂にあたり以下の部分を拡張しているという。

• プロジェクトマネジメントプロセス
  
• 立ち上げプロセス
  
• 終了プロセス
  

重要度の高いところを拡充しました、ということが良く分かる。「始めよければすべてよし」と「終わりよければすべてよし」というやつ。

プロジェクトライフサイクルとプロダクトライフサイクルの違いを明確にしてある。「プロダクトライフサイクル⊃プロジェクトライフサイクル」なカンジ。「新製品を開発する」プロジェクトは、できあがったその製品を「売りさばく」プロセスを含まない。一方、「新製品開発→売る→フィードバック」となっているプロダクトライフサイクルは、プロジェクトライフサイクルを含んでいるといえる。

プロセスの数は39→44に増えたそうな。7つ追加され、2つ削除されている。追加されたプロセスは次の通り。

• プロジェクト憲章の展開（sec4.1）
  
• スコープ記述書の作成（sec4.2）
  
• プロジェクトのモニタリングとコントロール（sec4.5）
  
• プロジェクトの終結（sec4.7）
  
• WBSの作成（sec5.3）
  
• アクティビティリソースの見積もり（sec6.3）
  
• プロジェクトチームのマネジメント（sec9.4）
  

WBSの重要性を強調しておきながら、その作成プロセス（5.3）無かったのねorz このへん未読なので楽しみ～ あとプロジェクト憲章をどう展開させるか（4.7）も興味あり。プロセスは増えただけでなく、プロセスの順番と構成に注力している（chap.3）。フローチャートやシーケンス図（?）もどきを使って、プロセスの順番や構成を解説している。相変わらず「そんなキレイに分けられるかぁ?」と言いたくなるが、その順番は妥当。

PMOの役割や、PMとの違いについての説明が増えている。Project Management Office って世の風潮という奴なのか? 組織がそんなにキレイに割れないだろうとは思うのだが、まぁハヤリモだし…

そういや、和訳版が同時刊行と噂されていたけれど、出ているのかな? amazonでは見当たらなかったナリ。ボランティアの皆さま、がんがってくださいまし。このblogではﾏﾀｰﾘと紹介しようかと。あくまで私の「読み」なので誤読&バイアスがかかっている模様。

夜泣き対策 －応用編－

毒男には全く役に立たない赤ちゃんの夜泣き対策の続き。ここではQ&A形式で夜泣き対策を紹介するぞ。あくまで私の経験（あるいは読みかじった情報）であることをお断りしておく。

Q1.泣いてる赤子をずっと放っておいたら、泣き止むのではないか?
A1.Yesだが、子どもの心に決定的な影響を及ぼすかも

押し入れや別室に放っておく、というオヤはいると思う。どんなに泣き叫んでも誰もこないならば、赤子は泣き寝入りするだろう。「死にゃしない」と考えるのは勝手なのだが、そういう風に育てられた子どもは大きくなると、ある傾向が見受けられる。それは人を信じる心が欠けていること。「泣く→めんどうを見てくれる」の繰り返しによって、赤ん坊は「泣いたら世話してくれる」ことを知る。さらに「泣いたら助けてくれる存在=親」を信じるようになる。どんなに泣き叫んでも誰もこなかった夜が繰り返されると、赤ん坊はついには絶対に泣かなくなる。「泣いても助けてくれない」ことに諦めてしまう心ができあがる。この子は長じて「人を信じる」という心が抜け落ちてしまっている。これは「ガマン強い」心ではない。むしろその逆。泣きつづける子の方が「ガマン強く」助けを呼んでいるんだ。子どもが最初に信頼する人は親。親が信じられない子どもは、誰も（自分自身すら）信じることができなくなる。

ネタ元「子どもへのまなざし」

Q2.赤ちゃんのためのCDを聞かせる効果は?
A2.気休めに毛が生えた程度

ズバリ「赤ちゃんのためのリラクゼーションCD」と銘打ったモノがある。心音などの体内音もを聞かせることで、胎内にいた頃の安らぎを思い出してもらう意図なのだが、ぎゃあぎゃあ泣いている赤ん坊は、聞いちゃいねーよ！。自分の泣き声でさらに泣いてるので、周りの呼びかけもほとんど耳に入ってこない状態なり。BGMのようにずーっと流しつづけるならばちょっとは効果があるかもしれないが、「夜泣きに困った親向け」の商品であって、けして「赤ちゃんのための」ブツではないと思うぞ。あと「赤ちゃんのためのモーツァルト」も然り。「親がモーツァルト好きで、赤ちゃんにも聴いてもらう」なら分かるが、自分が好きでもないのに流すのはヤセ我慢というもの。身の丈に合った音楽を（だからといってデス系はどうかと）

Q3.泣き喚く赤ん坊に殺意がわいているんですけれど
A3.そうかもしれないが…

もちろんサー残で疲れ果て、当然のごとく明日は平日なんだけれど、そんなことにはお構いなしに泣き叫ぶ赤ん坊に心底イヤ気が差すのはあなただけではないはず。一線を超えてしまう人もいる、いわゆる「魔が差す」というやつやね。けれどこう考えてほしい。赤ん坊にしてみれば「テメェの都合なんて知ったこっちゃないんだヨ！」と言いたいはず（口がきければ）。泣くことしかできないから泣いているんだし、赤ん坊にとってサー残や平日は心底どうでもいい話。ここはひとつ、オトナであるアナタが大人にならなきゃ。赤ん坊は泣くのが仕事、アンタはその面倒を見て、それから自分の仕事もする、だってオトナだから、オヤだから。あるいは中国の諺を紹介しとく「よく泣く赤ん坊は、いい声になる」そうな。だからおっくうがらずに「いい声になーれ」とかなんとかハイになって、明日（既に今日だが）の会議は放っておいて、朝まで付き合ってあげな　＞私

おまけ。いま「夜泣き対策」でGoogleってみたらオモシロイ対策が→着メロで夜泣き対策 。いわゆるレジ袋のカシャカシャいう音の着声素材なんだけれど、これはユニークなり。

--------------
2005/11/23追記
はてなでの夜泣き対策の質問と回答
赤ちゃんの夜泣きへのアドバイスをください

夜泣き対策 －入門編－

8ヶ月目の娘も、そろそろ夜泣きの頃となり候。上の子も苦労させられたので、ある程度は覚悟の上よ。でも1.5時間おきに「ぶっギャーンンッ！」（ｼﾞｮｼﾞｮ風）な泣き声で起こされるのはちと辛い。毒男には全く役に立たない赤ちゃんの夜泣き対策をいくつか紹介するぞ。

1.とりあえずいま泣いている赤ちゃんを泣き止ませたい

そのまんまの題名の本がある→「赤ちゃんがピタリ泣きやむ魔法のスイッチ」…んが、買うほども無し。授乳や抱っこのテクニックは経験的に知るものだし、それこそネットには様々な「泣き止ませ方」が転がっているので。それでも使えるのは「シーっ」という魔法の言葉。どこの国の言葉でも「静かにしろ」は「シーっ」と発音する。もちろん赤ちゃんにも通じる。耳元で（大きな声で）「シーっ」をゆっくりくり返すと、あら不思議、泣き止みます（本当）。いろいろな説があるが、胎内音を聞かせてもらったときの呼吸音「シーっ」を思い出すのかなぁ、と勝手に解釈している。

2.泣き始める前にできることは?

上記の本で「おくるみ」スイッチが紹介されていた。タオルケットを何枚も使って、赤ちゃんの身体をぐるぐる巻きの繭状態にするとよいらしい（もちろん顔は出して）。お腹の中にいた頃を思い出してもらうために、キュウクツな思いをさせるという←実験済みだが、ぎゅっと抱っこするのと同程度の効果。実験済みで有効なのは心臓の音や呼吸音を聞かせるがある。赤ちゃんの耳を自分の胸にあてるように抱っこして、心音を聞かせると心地よいらしい←彼女いる毒男は彼女にさせると良いらしいぞ。ボセイホンノウとやらを刺激することができる（たぶん）。

3.夜泣きしないような予防策は?

決定打は見当たらない。なるべく昼に機嫌よく遊んでもらって、夜は早寝してもらうとか、お風呂にゆっくり入ってもらう、とか月並みなことしか思い浮かばねぇ… つか無理。　「赤ちゃんは夜泣きするもの」と腹を括って相手するしかない。

さて、抱っこしてまいりますか。

野郎ども、がんばれよ

ここ25年間で最も革新的な技術ベスト25

携帯、メール、デジカメ、ATM... 今では身近なものだけど、25年前はどうだっただろうか? CNNはここ25年間で最も革新的なイノベーションのトップ25を挙げている[参照]。1位は現在非公開、1/16に発表するとのこと（間違いなくインターネットだと思うが）。このランキングは医療技術を除く。

1. ???
2. 携帯電話
3. パーソナルコンピュータ
4. 光ファイバー
5. 電子メール
6. GPS
7. PDA
8. CD
9. デジカメ
10. RFID
11. MEMS [注1]
12. DNA判定
13. エアバッグ
14. ATM
15. 充電池
16. ハイブリッド車
17. OLED [注2]
18. 液晶パネル
19. HDTV
20. スペースシャトル
21. ナノテクノロジー
22. フラッシュメモリー
23. ボイスメール
24. 補聴器
25. 高周波ラジオ

25年前、つまり1980年当時からは想像もつかない技術もあるが、興味深いのは上位のほとんどは25年前に存在していたが、持ち運べるようなシロモノじゃなかったこと。言い換えると、ここ25年間のイノベーションはポータブルなブツを生み出すことに注力してきたとも。

今は持ち運べるシロモノじゃないが、25年後はポータブルになっていたりして。例えばヘッドマウントディスプレイとか。OLYMPUSの"EYE-TREK"が生産終了してだいぶ経つ。夏休みの工作とかでPSPとゴーグルを一体化させる厨房が出てくるかも。

あるいはノーズマウントデオドラント装置とか。「ゴーグル型加湿+除湿+脱臭装置」で、その頃は世界的に花粉症が流行してたりして（Kafun-Syndrome）、さらに花粉症先進国の「メイド・イン・ジャパン」がもてはやされてたりして。
--
[注1] MEMSとは"Micro-Electro-Mechanical Systems"略。次世代のシリコン加工の革命的技術のこと。機械システムを極小レベルまでスケールダウンし、全てのシステムが砂粒程度の大きさに収まる大きさのものを指し示す。例えば、半導体極小部品やセンサ、アクチュエータの構成要素に適用されている。

[注2] OLEDとは"Organic Light Emitting Diode"の略。有機ELディスプレイ（有機EL）のこと。視認性、応答速度、寿命、消費電力でこれまでの無機ディスプレイ技術を凌駕している。例えば、携帯電話やPDAなどに適用されている。

ムシキング必勝法

CPUアルゴリズムは単純。でないと小学生でも勝てない。どのムシでもよいが、テクニックは100欲しいし、拳、鋏、破の技カードがスキャンされていることを前提として解説する。ムシキングROMは3バージョン出回っているが、全バージョンに共通。

【基本戦略】1回目、敵は必殺技（大きいアイコンで表示）を必ず出す。それに勝ったら、次からは左回り（拳→鋏→破）で押し続ければ良い。基本的に敵は「前回負けた相手の手に勝ちにいく」ように思考している。

【必殺技・超必殺技について】自分が必殺技・超必殺技で勝った場合、その次も同じ手で勝てる。これはボーナスと考えて良いが、「二度あることは三度ある」ワケではないので注意。

【ポポの助言】リンクのなりそこないの格好をしたポポの助言は聞いておく。「気をつけて、僕らの手を読んでるよ」は、左回りの手を一手戻す。「フラフラしているよ」は同じ手で勝てる。「必殺技で勝ったときは…」は同じ手で勝てる。

【あいこやぶり】この後は「基本戦略」から外れる（ランダム?）。負けるかもしれないが、敵が勝った場合同じ手で勝ちに来るため、次の勝利は容易。

【必殺よこく】ハッタリだと思えばよい。ただし100％というわけではない。

【ムシのレベル】自分が強いムシだと敵は2回目以降強いムシを出してバランスを取ろうとする。わざとムシカードをスキャンせず、デフォルトのカブトムシで闘うのが「通」との評判あり。

ROMバージョン3以降のTips：「ひとりであそぶ」を選択時、拳鋏破の全ボタン同時押しで、ボス（アダー）を打ち負かした後のストーリーから始まる。性懲りもなく同じセリフをくり返すアダーはちょっと可愛いが、敵レベルが1.5割増されているため、「むずかしい」モードになっているといえる。

ちなみに、上記のネタをムシキング行列のお友達に吹聴してもバカにされるだけ。彼らにすれば常識なので。

子どもに「礼儀正しさ」をどうやって教えるか

それこそ乳幼児の頃は「育てる」よりもむしろ「世話する」時代だった。語弊があるかもしれないが「飼育する」という感じ。世話をしているうちに勝手に大きくなり、幼稚園に行くようになり、「ともだち」なる存在を見つけ、裏拳を覚え、悪い言葉を仕入れてきては叫んだり… と、立派な3歳児に育っている。

そこでフと気づいたのが上の課題。確かに学校などで「集団生活を通じ社会性を身に付けることができます」などと言われるが、「社会性」の中には礼儀正しさは含まれていないぞと。

目標を分解してみる。

　　1.「礼儀正しい」とはどういうことか分かる
　　2.「礼儀正しい」ことがあたりまえのようにできる

親なる私自身できているかが最大の問題なのだが… とりあえず 1 について自問。「礼儀正しい」とは何か?　→　相手を尊重する意思が言動に顕れたもの。「礼儀作法」とは少し違うと思う。辞書にあたってみる↓

　　広辞苑：社会生活の秩序を保つために人が守るべき行動様式
　　新明解：尽くすべき敬意表現と、超えてはならない言動の壁

微妙に違うが気を取り直して 2 へ逝ってみよう。「あたりまえ」になって欲しいのは次の4つかな。

あいさつをする

基本にして最強。「できていない」人は数多く見かけるが、それは本人が悪いのではない。親がちゃんと教えていないので、「あいさつをすることは、あたりまえなんだ」と思えないだけ。大きくなってからの矯正は、本人が気づかない限り、不可能。これはオヤなる私が「礼儀正しく」家族にあいさつをするところから始まる。子どもはマネの天才。

話すときも、聞くときも、相手の眼を見る

ごめんコレできていない→私自身が。そっぽ向いたまま話を振ってるし、目線を合わせるためにしゃがんだりしてない。（叱るときなど）強く言うときは上から押さえつけるように言うため、子どもはけして目を合わせようとしない。誉めるときは目線を合わせているんだけどな… アイコンタクトの無い親子会話を避けるため、私が直さなきゃ。

悪いことをしたら、「ごめんなさい」と言う

おとうちゃん謝り上手だから、息子も上手（w … んが、何でもかんでも謝れば良いわけではない。「ゴメンで済んだら警察いらない」が、過ちを繰り返さない決意が入っているかがポイント。これも「謝る姿」をさらすことでマネしてもらおう。

なにかをしてもらったら、「ありがとう」と言う

これも最強。「ありがとう」は魔法の言葉。何度使っても磨り減らない、使えば使うほど輝きを増し、自分も相手もハッピーになれる魔法の言葉。一生の中で誰よりも多くの「ありがとう」をいえる人になってほしいなー　と思っているので、まずオヤから実践中。hirocさんの「1日10回ありがとう」に倣って、「ありがとう」をできるだけたくさん（自然に！）言えるようにならなきゃ。

ううむ、だんだん「あたりまえだけど、とても大切なこと」に似てきたぞと。それはともかく、上記は全て、「相手を尊重する意思」が根っこにある。相手をかけがえのない存在として認め、尊重することにより自然に出てくるのが「礼儀正しさ」なんだとあらためて思う。

ただ、普通は「相手を尊重」→「礼儀正しい所作」のプロセスを経るのではなく、その家族を通じて習慣化していく「クセ」のようなものだと考える。なぜなら「礼儀正しい人」はそうするのがごくあたりまえのごとく行動しているから。礼儀正しさとは、習慣なんだ。

だから先ず私が、子どもに対して「かけがえのない存在」だと思っていることを示し、彼が幼い存在だとしても「礼儀正しく」接することにより、習慣づけていくのが正道だな。大切にされたことがない限り、誰も大切にすることができないだろうし、礼儀正しく接せられたことがない限り、（人に）礼儀正しく接することなぞできないだろう。子どもはマネの天才。だから私のマネをしてもらうべく、私が「礼儀正しく」あろう。

時間はみんなに平等だが、あなたにだけは平等ではない

「『年を取るほど一年が短く感じられる理由』←意味がよく分からねぇ」というツッコミをもらった。ううむ、なるべく分かりやすくしたつもりだったが、書き方まずかったかも… なので再エントリ。まずはこの図を見てほしい。

この図は、ちょっと違う見方で「1年間」を「測って」いる。ポイントは2つ。

1つ目は、「1年間」という時間を「量」とみなしている。「1年間」を時間として見る限り、「計る」方法は時計しかありえない。「1年間」をボリュームとみなし、何らかの方法で「測って」みる。

2つ目は、「測る」方法を体感量として相対化できないかと考えた。つまり、今まで生きてきた時間のうち、1年間が占める割合で「測って」みるんだ。

例えば、生まれたての赤ちゃんにとって「1年間」は「生きてきた時間」とイコールだろう。10才の子どもにとって「1年間」は生きてきた時間の 1/10 に相当する。20才なら 1/20 になるし、30才なら 1/30 だろう。

10才の子どもにとって「1年間」はかなり長い。なぜなら生涯の 1/10 に相当するから。しかしその子が年をとって20才になると「1年間」は、10才の時よりは短くなる。体感量は 1/10 → 1/20 になるから。単純計算だと 1/2 に短縮されてしまう。もちろん物心つくまでの期間が含まれているため、単純に半分とするのは乱暴だが、それでも短くなっていることは確かだろう。

また、この考え方は同一人物の体感量に限っている。10才の観鈴さんと20才の晴子さんの「1年間」は、1/2 にならない。10才の「1年間」との差を体感できるのは20才の晴子さんだけだから。20才になれなかった観鈴さんにとっては体感していない時間だから。

年をとればとるほど、「1年間」の体感時間がどんどん短くなってゆくのが分かっただろうか? 具体的にどれだけ短くなるかというと、以下の計算式で求められる。

　　今年の体感量　＝　365　×　あなたの年齢　÷　（あなたの年齢　＋　1）

仮に観鈴さんが16才なら、17才の誕生日を迎える年は、前年に比べると

　　365×16÷17≒343.5
　　365－343.5＝21.5

だいたい3週間、短くなるというわけ。

一方、観鈴さんと晴子さんふたりの時間を比べる場合は、時計を使うしかない。この場合、「1年間」は二人にとってほぼ同じ時間となる。「時間は誰に対しても平等」というのはこのこと。

誰に対しても等しく過ぎゆく時間。しかし、自分の体感としてみた場合、年をとればとるほど、どんどん短くなってゆく。時のスピードが速くなっているのではない。秒針の速さは同じ。しかし受け取れる時間の「量」が相対的に減っていくわけなんだ。

「ああ、もう大晦日か」とつぶやいた人は沢山いただろうが、今日（1/7）はそのときから1週間しか経っていないことに気づいている人は、わずかだろう。2005年が始まった最初の1週間は妙に長かった。しかし来週は、今週よりも「速く」過ぎ行く… 違う違う、時間は加速しない。あなたの受け取り分が減っているんだ。

時間はみんなに平等だが、あなたにだけは平等ではない

渋谷の女子高生という神話

あれは「渋谷にいる制服を着た女」だよ、という話。知ってるよ、という人は読む必要なし。渋谷を歩く制服を着た女性は、「女子高生」という記号をまとっていることをよく理解しているが、周りはそう思っていないらしい。

たとえば街頭インタビュー。カメラに向かう「女子高生」は、生で見るとハタチをかなり過ぎてる。大人肌はファンデやTVブラウン管でごまかせるらしいが、照明さんやレフ板さんに囲まれ、「渋谷の女子高生」を演ずる女性は、ロケバスで着替えを済ませる。

着替えといえば、ロッカーでの着替え。ハイティーン（死語）の娘は、確かに東急ロッカーで着替える。私服→制服にな！ 私服で電車に乗ってやってきて、わざわざ制服に着替えることに何の意味があるのか、オヂサンには分からない。

テレビ収録もそう。カメラを向けると逃げ出す娘が本物。東急や井の頭沿線の子は、学校バレすると問題があるため、写らないように逃げる。嬉々として応ずる女子高生は確かにいる。しかし彼女らは、電車を乗り継いで渋谷にやってくる。

水色ワンピース着てるオッサンや、熱々レズカップルが闊歩する街だから、めったなことには驚かないが、どうみても20代後半なのに女子高生な2人が腕組んでいるのを見かけたときにはのけぞった。好奇心を隠せず「なにかの撮影ですか?」と尋ねたところ、卒業して十年経つけれど、どうしても制服を着て渋谷を歩きたかったそうな。

ここまでくると、一種のコスプレ、つまり渋谷という聖地でくりひろげられる女子高生というコスプレなんだ…（109が"はにはに"聖地であるのと同じだねっ）。

では本当の「渋谷近辺の高校の女子」は? もちろん Book1st や マクドに駐屯（たむろ）ってる娘もいるし、ハチ前の電話ボックスで一生懸命客引きをしている娘もいる。でも、ほとんどの子は、少し疲れた様子でノートや参考書を眺めている、どこにでもいる高校生。

がんがれ、受験生。センター試験はもうすぐ。

--