2007年12月30日

「4合を午後6時に炊き上がるようにセットしておいて」には Leadership の全てがあるお話 -1-

「子育てをしている間仕事をしていない。これは女性に不利だ」
という主張をいまだに聞くことがある。はっきり言おう。これは間違った認識だ。

仕事は常にEngineerとしての側面とLeaderとしての側面にわけることが出来る。

Engineer としての側面が要求するのは、専門知識であり、それを日常的に、意識せずとも使いこなすための訓練結果だ。確かにここに関して不利だ、というのは全くその通り。

しかし、Leaderとしての側面は全く異なるものを要求する。仲間からの信頼、この人に任せれば大丈夫という安心感、この人に任せてもらえたと言う形でのモチベーションの向上、この人が言うのだからとグループ全員に同じ方向を向かせる方向性の決定能力、の4つの能力が必要になる。

新入社員は全て、最初の内 Engineer として訓練される。その後に Leader としての訓練が始まる。一方、育児に追われる女性は、実はその中でLeader として訓練されているのだ。確かに、下っ端として復職すれば、Engineerとしての能力で周りと自分を比較してしまう。すると不利に感じるかもしれないが、それは誤った認識だ。あなたの周りにいる Engineer達は皆、これから Leader としての訓練を受けるのだから。

「そんなのは信じられない」

と言うかもしれないが、これは本当だ。その一例として次のような状況を考えよう。
あなたには二人の子供がいる。小学生の低学年と高学年だ(性別は無視しよう)。
意外と手間の掛かる盛りだ。あなたはいつも、夕方に夕食の買出しに出かける。
「4合を午後6時に炊き上がるようにセットしておいて」
というお手伝い要求を子供たちに残して出かけた。
ほら。あなたはすでに Leader だ。二人の子供から見て、あなたは Leader なのだ。そして、たったこれだけのことの中に、Leaderとして重要な要素が5つ隠されている。

1. 子供にでもできるように作業を分割してある
2. 子供を信頼して依頼する
3. 小さな約束をし、守る事で、子供に信頼してもらう
4. 結果に対してフィードバックをかける
5. 子供が依頼を遂行している間、あなたは彼らのそばにいる…も同然

詳細は後で見ていくとして、主婦(主夫でもいいが)というのは Leader としての5つの要素の重要性を日々体験している。逆に新人サラリーマンは5つの要素について考慮する機会が与えられることも、熟慮する余裕もないし、またそれらについて考えたからといって評価されることもない。

よくお父さんのことを「大きな息子」と表現することがある。それは結局家庭内での Leader がお母さん側にあるからだ。お父さんは(通常の場合、平サラリーマンなお父さんは特に) Engineer であって、最初から Leader として訓練されているわけではない。また、ある程度歳をとってからのお父さんは Leader かもしれないが、教育されたタイミングが結構後なので Leader であり続けること 自体、かなりの労力を消費してしまう。会社と家と、両方で Leader であり続けるのはかなり苦痛なのだ。だから、緊急時以外の Leadership を家庭では放棄する(事で船頭が二人になるのを防ごうとする)。その結果が「大きな息子」と揶揄される態度であり、メンタリティなのだ。

注意が1つ。お母さんが日々 Leadership について訓練される立場にある、というのと、それを理解して Leadership について修練を積んでいる、というのとは別の話だ。Engineer 失格のサラリーマンが大量に存在するがごとく、Leadershipについて何も理解していないお母さんも山のように存在する。そのようなお母さんは、「子育てがひと段落した」からと再就職しても、Leadership を必要とする身分にはつけないだろう。逆に
「きっと Leadershipについて学習してきたに違いない」
と会社側が勘違いして Leadership が必要な仕事を割り当てても、そのプロジェクトは崩壊するだけだろう。

結局、「仕事として」まじめに Engineering を学習するのと同じぐらい、まじめに Leadership というものについて学習していなくてはならない、という点は変わらないのだ。

2007年12月24日

英語をどうにかする -10- まとめ

まとめよう。

英語をどうにかするには次のようなことをまず念頭におく必要がある。
  1. 英語で伝える必要があることは何なのか考える。
    英語でなくても伝わることを、英語で伝えようとする必要はない。
  2. 「伝えよう」という熱意がまず何よりも大事だ。ちょっと努力して、すぐ諦めるようではいけない。
  3. 名詞をまずどうにかしよう。特に自分の専門に関する用語・単語は英語で書くようにしよう。カタカナでは最後の瞬間にスペルがわからなくなる。最初からアルファベットを使って書くように。
  4. 類語・類似の表現を日本語レベルで思いつく訓練をしよう。
    「洗剤」に該当する単語を思い出せなくても、「服を洗う石鹸」と表現できれば目的は達成できる。
  5. 日頃から、文章を短くする訓練をしよう。話し言葉のレベルで短く。そして主語や述語を省略しないように訓練しよう。
    長くて、主語が倒置してしまうような文章は、ただでさえ翻訳しにくいものだ。それをリアルタイムで英文に直す事など不可能に近い。普段から不明瞭な文章を話さないようにすることで、「頭の中で英語に直し易い」文章を普段からつむぎだせるようになる。そういう文章を英語に直すのは、比較的楽なはずだ。
  6. 判らない単語に拘泥しない。
    意味が後で推測できるかもしれないのだ。判らない単語はスキップして判るところをつなぎ合わせるようにしよう。
  7. 日本語混じりだって、意味は通じる。英語だけで話そうなどと拘泥する必要はない。
という7項目が今回説明した内容だ。もっと乱暴に言うと、

  • そもそも日本語を話すときに、文章を単純明瞭にする事を心がける。そうすれば英訳する際の負担は軽い。
  • 英語にできる部分から英語にする。つまり日本語の文章で、英単語がいっぱい混じっているのだってかまわない。逆に、判らないからと言って「聞くのを諦めてはならない」。
  • 類似表現をいっぱい思いつくように、普段から訓練する。
の4つにまとめることができる。


日本語を単純明快にする」というのは、やってみれば判るが、意外と難しい。これは「明確な文章を書く」事と同義なのだが、これが至難の業なのだ。実際、「明確な文章を書く」というたった8文字のこの文章自体「明確」ではない。これは正確には:

聞き手にとって明確に意味が把握できる文章を書く

という意味だ。「自分からすれば十分明確である」と言うのは、この場合の「明確な文章」の意図に反する。従って、「単純明快な文」とは単に短い事を意味しない。必要十分な情報が入った上で、短くなくてはいけないのだ。と言うことは、1文1文が内包できる新規の情報は、少量にならざるを得ない。と言うことは、何をどの順番で言うのか、という点にまで気を使う必要がある、と言うことだ。
  • 新しい単語を使う前に、その定義を明らかにする。
  • 文の主体を可能な限り一貫させる。
  • 時間の流れを可能な限り順方向にする。
などの論文の書き方を普段から意識しないと、「最小労力で英語を話す」事はできない、と言うことになる。

最後に、「英語を話す能力は日本語を明確に話す能力に依存する」事に気がつかせてくださった、恩師の 安居院 猛 東工大名誉教授 に、ここに深く感謝いたします。

2007年12月10日

英語をどうにかする -9- これでもいいのだ

これは、某不死鳥技術社において、日本の営業本部長と米国営業本部長の間で実際に交わされた会話を元に、内容を全面的に入れ替えつつも、英語の使い方に関しては一切の嘘をついていない、記録である。

いやー、Johnson さん、
Japan の bad economy のせいで、sales が hard で don't rise ですよ。

Ah, similar here in US too.
Seems like AAA(本当はライバル会社の名前1) and XXX(本当はライバル会社の名前2) seems to be pushing very hard against us. Also EFL technology by Intel is killing us too.

Japan では AAA は not so strong だから OK なんですが、but XXX は bad feeling ですねぇ。be careful が must for XXX ですねぇ。
所で、PC Sales は entire としては how ですか?

PC Sales is divided into PC server sales and personal PC. PC server is growing, for Linux and other technology is focused by IBM, HP and other company, and they are beating up their own low end Workstation markets. However, for personal PC, it' s not growing well. PDA is taking some part of PC user off, while still, new PC user is coming in due to Internet.
そろそろ疲れてきたので、この辺にしよう。

上記、青字が日本人のセリフで、黒字がアメリカ人だ。

青字を見れば判るとおり、日本側は「単語こそ英語」だが「日本語」を喋っている。黒側は純粋な英語だ。でもちゃんと意思が通じている。「本当にこういう風に話し合ってて、意味がちゃんとかみ合っている」所が…一見すごいようで、実はすごくないところだ。

実は今まで出てきた大事なポイントを全部駆使すると、こういうことが出来るようになるのだ。
  • 文章とかの全体の流れはイントネーションと間も使って伝える
  • キーワード、特に専門用語の英語を覚える
  • 文章を短くする
  • 判らない単語はすっ飛ばす、で、後で中間を類推する
この能力があると本当に日本語でアメリカ人と話せるようになるのだ。
じゃぁ、実際、聞いている側はどういう風に聞いているのか、見てみよう。

いやー、 Yeah, Johnson さん -san,
Japan bad economy のせいで、sales hard don't rise ですよ。
Ah, similar here in US too.
Seems like AAA(本当はライバル会社の名前1) and XXX(本当はライバル会社の名前2) seems to be pushing very hard against us. Also EFL technology by Intel is killing us too.
Japan では AAA not so strong だから OK なんですが、but XXX bad feeling ですねぇ。be careful must for XXX ですねぇ。
所で、PC Sales entire としては how ですか?
PC Sales is divided into PC server sales and personal PC. PC server is growing, for Linux and other technology is focused by IBM, HP and other company, and they are beating up their own low end Workstation markets. However, for personal PC, it' s not growing well. PDA is taking some part of PC user off, while still, new PC user is coming in due to Internet.
まぁ、こんな感じだ。お互いに、必要なキーワードだけは絶対にはずさないようにして、あとは単語は「音程の変化」でも同様に意味が取れるように配慮しているのがわかるだろうか?

日本語だと「所で、」のところなどは、その少し前に長い目の空白を入れて、違う話をするんだよ、という配慮などをしていた。英語側だと「However,」なんかは「ところがだねぇ~~」という感じの音程のとり方をしており、これが意味を伝えていた。

最後に、短い文章だと、英語と日本語であまり語順が変わらない、あるいはかかり方が直近の単語で済むので、ほとんど語順が変わらないことも気がついただろうか??文章が短いと、聞いている側が日本語そのものは判らなくても、相手が言わんとしている事の推測をつけやすくなるのだ。

どうだろう? これでも十分意思は通じている。
マジメに英語の文章を話せるようになる前に、このレベルを狙ってみるのはどうだろうか??

2007年12月7日

英語をどうにかする -8- あきらめるなっ!! わんもあせっ!!

"When creating the socket with asynchronous mode, or should I call it non-blokcing mode, it is very obvious to say that you must do many things which kernel was doing when using blocking mode. Communication by itself is asynchronous anyway, and hence, while in blocking mode, it was kernel, and/or libraries that was making this to act as if it is synchronous. However ...."

という英語を話しかけられたとしよう。大抵の人は次のように聞こえるのだそうだ。

"When creating the socket with asynchronous mode, or should I call it non-blokcing mode, it is very obvious to say that you must do many things which kernel was doing when using blocking mode. Communication by itself is asynchronous anyway, and hence, while in blocking mode, it was kernel, and/or libraries that was making this to act as if it is synchronous. However ...."

最初の asynchronous の辺りで力尽き、non-blocking の辺りで脳みそが拒否をはじめ、あとはもうどんどんノイズと化していく…。

当たり前だが、こんなことでは英語はどうにもならない。だってほとんど全て「認識していない」つまり「聞こえていない」のだもの(聴こえてはいるのだろうが…)。

これをどうにかするには、わからない言葉はすっ飛ばす 事を覚えなくてはいけない。つまり:

"When creating the socket with asynchronous mode, or should I call it non-blokcing mode, it is very obvious to say that you must do many things which kernel was doing when using blocking mode. Communication by itself is asynchronous anyway, and hence, while in blocking mode, it was kernel, and/or libraries that was making this to act as if it is synchronous. However ...."

のように聞け、と言うことだ。

さて、もし、あなたがネットワーク通信を行うプログラムを組んだことがあるなら、socketにはブロッキングモードと非ブロッキングモードがあるのは判るだろう。ということは次の赤字のポイントから、緑の部分の意味が推測されることになる。

"When creating the socket with asynchronous mode, or should I call it non-blokcing mode, it is very obvious to say that you must do many things which kernel was doing when using blocking mode. Communication by itself is asynchronous anyway, and hence, while in blocking mode, it was kernel, and/or libraries that was making this to act as if it is synchronous. However ...."

で、緑がわかったら、多分シンクロナスとアシンクロナスが「同期型」と「非同期型」である事が判るようになる。結果として青が埋まる。

"When creating the socket with asynchronous mode, or should I call it non-blokcing mode, it is very obvious to say that you must do many things which kernel was doing when using blocking mode. Communication by itself is asynchronous anyway, and hence, while in blocking mode, it was kernel, and/or libraries that was making this to act as if it is synchronous. However ...."

この辺りまで来ると、kernel とか library とかも意味がわかってくるので、However 以降の英語において kernel とか library というのが「カーネル」と「ライブラリ」だと言うことも類推できるようになる。


もちろん、これらのことをリアルタイムでやるのだからとても大変だ。大変だから、以上のような推理を働かせながらも、態度上は、

「まてまて、ちょっとまったーーー。
 早すぎるよ。もうちょっとゆっくり話してくれ」

という態度で臨まなくてはいけない。そうすれば相手はゆっくり話してくれるようになる。という事は推測するのにかける時間がより多くなる、と言うことで、ますます文章の予測がしやすくなる。


実は、英会話学校でずーっと英語を聞き続けることで鍛えているのはこの 理解できない単語に拘泥しない能力だ。もし、英会話学校でなかなか英語力がつかないと感じているならば、まじめに最初から全部の単語を把握して理解しようとしているからに違いない。

日本語の場合を考えてみると良く判る。日本人のほとんどは判っている単語であってもガンガンかっ飛ばす。特に疲れているとその傾向がひどい。で後で間を補完しようとして…発生するのが「まつがい」って奴だ。日本語でまつがいまくる人が、どうして英語でまつがわないように努力なんぞするのか。もう、その段階でやっていることがまつがっていることが良く判ると言うものだ。

単語が判らなくなるのは、恥でもなければ問題でもない。問題なのは「もう駄目だ」と諦めて全てを投げ出してしまうことだ。休んでもいい。負荷を減らしてもいい。

しかし、諦めるなっ。さぁ、わんもあせっ!!!

Billy は意外といいことを言っていたのだ。

2007年12月5日

英語をどうにかする -7- 短! 短!! 短!!!

『冬が始まるよ』という歌がある。槇原敬之の曲だが、あれの出だしを覚えているだろうか?

著作権の関係があるので全文引用は出来ないが、
八月の君の誕生日
から
一緒に過ごせる為の、おまじない
まで、漢字で書いても全57文字もある。普通、3,5,7 の組み合わせで一文21文字ぐらいしかないはずの歌詞の世界において、だ。

もちろん、それだけ長い一文を書いて、歌詞全体としての整合性を取る槇原敬之の才能は素晴しいが、しかし。

あの歌詞を聴いて、さ、その場で英語に訳せ、と言われたらどうだろう? 辞書を引きまくっても構わないが、何かに書き写すのではなく、全部頭の中だけで訳出して口頭で述べろ、と言われたら…

私には無理だ orz

大抵の英語は苦手、と言う人も同じだと思う。

なのに、そういう人の日本語を聞いていると、やたら長い。
そして実は文章として成り立っていない。
主語が何度も入れ替わったり、
主張点が途中ですり替わったりしている。

その日本語を英語に直そうとしたら…そりゃ、訳せないだろう。

英語の上手な人の日本語は、短い。もちろん、同時通訳レベルになるとそうでもなくなるが、中ぐらいよりちょっと上程度の人だと、英語以前に日本語が短い。

そして主語や述語など、日本語だとぼやかしたり誤魔化したりできるものを、曖昧なままにしない。そして、その日本語はそのまま英語となっても出てくる。短いからおかしな言い回しを必要とせず、順序の入れ替えも少量で済むので、頭を疲れさせない。


と言うわけで、今回のポイントは

ちゃんとした日本語を書けるようになること
短い文章で話すようにする事


これができるようになるだけでも、ずいぶんと英語が楽に出てくるようになるはずだ。

2007年11月29日

英語をどうにかする -6- 簡単な単語で表現する力を養う

私がつい最近まで知らなかった単語に detergent がある。

detergent: 洗剤、合成洗剤

海外出張が2週間以上続くと、着る物がなくなる。当然洗濯する必要があるのだが、ホテルのランドリーサービスは高い。アメリカの場合、コインランドリーが結構豊富なのでそちらを使う事になる(こっちの方が早い、というのももちろん、ある)。

特に、長期出張用の Inn とか Motel と言われるクラスのホテルは多くの場合、
  • 無料あるいは廉価なコインランドリーがホテル内にある。もちろん、乾燥機もある。
  • アイロンなども揃っている。
  • サービスで洗剤もくれる(柔軟剤をくれるところはあまりないなぁ)。サービスじゃない場合もフロントに言えば「1回分」というサイズのものを安く売ってくれる。
なので、これを使って洗濯・乾燥させればよい。特にアメリカの洗濯機、乾燥機は大きいので、一人旅であれば1週間分をまとめて洗っても一発で済む。とても便利だ。

あ、ついでに言うと、柔軟剤は乾燥機に放り込むタイプが便利だ。まるで紙みたいなのを洗濯物と一緒に乾燥機に突っ込んでやる。するとふわふわになって乾燥するのだ。コインランドリーの場合、洗濯機が結構乱暴に安物なので、「柔軟剤入れ」なんてしゃれたものはない場合が多い。なので、乾燥の時にやわらかくしてしまう。柔軟剤は softener で通じる(もっと柔らかくするもの、つまり Softな~ と覚えておけば発音はあってるから大丈夫だ)。

も一つついでに。私はそこへ行くのが二度目以降の場合、持って行く衣類に襟汚れとかが酷くてもう、捨ててもいいや、というものを持っていくことが多い。で、ついていきなり洗濯を始める。洗剤が強力なんだろう、今まで落ちなかった汚れが一撃で落ちる。乾燥機もでかくて高出力、柔軟剤も強靭なので皺も消えてふわふわ。で、これを帰る間際に捨てて帰ってくる(たまに延命してしまうものもあるが)。
この洗濯であまり改善しなかった場合は、近くのモールへ行って代わりの服を買った上で、いきなり捨てればいい。衣類は若干アメリカの方が安いので、これでOK。ただし、パンツは別。

で、問題は洗剤をもらいに行く時、だ。

もちろん "May I have a detergent" と言えば済む。文法も中学生並だ。何も難しくない。

detergent をちゃんと覚えているならば

もちろん、物覚えの悪い私は覚えていない。で、毎回酷い言い回しを使って難局を乗り切ってきた。

" May I have Soap to Wash Cloth?"
服を洗う石鹸をもらえる?

意味が通じるんだ、これで。だから、Detergent という単語を覚えない。覚えたのは、6月の出張先で、ホテルのフロントのおばちゃんが毎回言いなおしてくれたからだ。2週間言い直してもらうと、いい加減私でも覚えた。

で。ようするに「detergent なんて難しい単語を覚えなくても意思は通じる」と言う事がいいたいのだ。石鹸(Soap)と洗う(Wash)と服(Cloth)を覚えれば、detergent は後回しに出来る。
大事なのは「どの単語があると表現空間が最大限に広がるか」を常に意識しながら、単語を覚えていこう、と言う事だ。

# とはいっても、Soap と Wash と Cloth と to は、殆どの人が知っているだろうし、
# May I have ... も中学で習ったはずだから…この場合は何も覚えなくてよいのだけれど。


で、このようなものの言い方を考える場合、「類語」が次々に思い出せる、というのが大事な能力になる。「洗剤」という日本語に引っかかってしまうと、「石鹸」を思い出せなくなる。そうならないためには、常日頃から

もし、その単語を知らなかったなら、
代わりにどう言って意思を伝えるか?

日本語で訓練するとよい。よく、外国の人が少ない語彙で意思を伝えようとして、ケッタイな日本語になるのを思い出してほしい。あれを意識して実行するのだ。

一番良いのは、外人が少ない日本語で苦労して意思疎通を図ってきたら、是非付き合うことだ。相手が何を言おうとしているのか推測する。これも類語の連想ゲームが必要なので、同じ能力を鍛える事になる。

自分が、外国で英語を話そうとすると、この外人さんたちと同じレベルの話し方をしているのだ、と考えれば、少しは親切にしてあげよう、という気にもなるだろう??

なお。
上のほうで「パンツは別」と言っているが。実はアメリカのパンツはゴムの余力が少ないのだ。伸びない。日本製に比べて全然ゆとりがない。特にトランクスが駄目。
私の場合、Mサイズだと「普通に履いている」分には問題ないのだが、脱ぎ履きの際に苦しくなるぐらい伸びない。Lサイズだと脱ぎ履きは楽に出来るのだが、履いた後きちんと落ち着いてくれない(スルズル落ちる)。
なので、トランクスだけは日本製が良い、と思っている。

2007年11月11日

英語をどうにかする -5- 名詞

三度、うちの3姉妹のチー先生にご出馬いただこう。

彼女が最初の内覚えている単語は何だろう? お子さんがいらっしゃる方は自分の子供が覚えた単語でも良い。

まま、とか パパ とか まんま(ご飯) とか…「名詞」じゃなかっただろうか??!

もちろん、これには教えやすいというポイントも挙げられる。ろくな概念を知らない赤ん坊に「美しい」だの「走る」だのと言った形容詞や動詞を教えるのは、はっきり言って無理だ。名詞であればとても教えやすい。指差して、名称を言い、相手が復唱するのを待てばよい。

しかし、一旦覚えた名詞は、イントネーション次第で同じ単語に異なる意味を持たせる事もできる。現にリンク先ではおなじ「まんま」と言う言葉を、
  • 空腹だ!! 何か食べさせろ!!!!
  • それだよ、それ。そのご飯♡ それを待ってたんだ
の両方の意味で使っているし、ちゃんと意思は通じている。

人間はみな、この「名詞を覚える事からはじめる」というフェーズを経験しているので、言葉に不自由している人に対しては 名詞から状態を推測する 事をある程度やってくれる。これは世界中で共通した特徴だと思う(全員に心理テストを掛けて回ったわけではないが、言語学習手順が1通りしかない以上、ほぼ確実だろう)。不足している部分は身振り・手振りで補えばよい。


というわけで、最初は名詞を中心に覚えよう。とはいっても、"help", "run", "beautiful" などといった、もう覚えてしまった単語を忘れろ、という意味ではないので勘違いしないように。あくまでも「今後覚える単語」の話だ。


さて…高校生以下の読者がいたら、ここでごめんなさいを。ここから先しばらくは、すでに仕事を持っている人向けの話になる。

仕事をしている人の場合、殆どの場合において自分の専門と言うものを持っていると思う。いまどき、専門家ではない人はいない。農家の人は農業が専門だ。もっと言えば何でもかんでも育てているわけではないだろうから、育てている動植物に関する専門家だ、と言う事になる。自分ひとりで必要なものを育て、造り、消費している人間は殆どいないだろうし、もしいたとしたら多分インターネットに接続するための「お金」の工面に困っているはずだ。
# たまーに、 お金に困っていないから そういう生活をする人もいるが…

自分の専門に関する名詞は英語を使おう

ITの人なら「コンピューター」ではなく Computer と書こう。「セマフォ」ではなく Semaphore と書こう。そうすると、実は意外な単語が判らない事が判る。それを辞書で引いて覚えていこう。

私の場合ここ3年で発見したものの一部をあげると(恥ずかしくて全部はあげられない)
  • 安全係数 (safety factor)
  • 輻輳 (congestion)
  • 観客・傍観者 (spectator)
ちなみに、科学技術系の辞書はこれらが一番だ。


目が飛び出るほど高い、と表現してかまわない値段だとは思うが、その価値はある。だって普通の辞書に「安全係数」なんて載ってないんだもの…。

英語をどうにかする -4- 動揺してても伝えられるように

このテーマの2回目3回目を読んで
「これでどうすると、英語がどうにかなると?」
と思った人も多いかもしれない。でも、これらはとても大事な事を言っているのだ。

実際問題として、我々は「英語が話したい」のではない。
共通言語が英語しかない人達と意思疎通したい
のだ。2回目3回目で示したかったのはこの事だ。この意識無しにはいつまでたっても完璧な英語が話せるようになるまで英語を話す事はできなくなる。そして、英語にも黒人訛りやスパニッシュ訛りなどがあることからも判るように、完璧な英語などない


完璧な英語などないなら、まずは少しづつでいいから意思疎通ができるようになればいい。ついで、自分が使える表現を増やしていけばいい。しかし、最初に覚えなくてはいけない必要最小限度な知識を最小限度に抑えたい。たくさん覚えなくてはいけないのでは、なかなか英語が話せる、と言う状態にならないからだ。

もう一つ重要なポイントがある。人間は緊張したり、動揺したりすると、平静であれば思い出せることも思い出せなくなる。しかし、緊急事態においてこそなんとしても伝えたい事が発生する。必要最小限度の知識は、どんな状態でも搾り出せるようにしておく必要があるのだ。そのためには、動揺しても、パニックに陥っても、必要最小限の言葉だけは出てくるようにしなくてはいけない。

どんな時にも出てくるようにする唯一の方法は、繰り返す事だ。残念ながらこれに関する限り、人間の脳に何か特別な機能と言うものはついていない。あらゆる機会を通じて繰り返す事でしか、どんな時でも出てくる知識と言うものは養えない。


だから、最初に知るべきことは英語でなくてもどうにかなる事は何か? なのだ。

英語を使わなくても伝えられる意思は何か?痛いとか嬉しいとか、そういう感情は本質的に 音程テンポ だけで伝えられる。そういうものは、日本語で伝えても伝わる、と言う事だ。英語であったとしても、ouch とか hungry とかは後回しでよい。

もちろん、これらは e-mail とかでは使えない。でも無茶を言ってはいけない。本来人間の意思疎通言語はボディランゲージであり、その次が声なのだ。声で伝えるものに論理構造を持たせ、それが書き文字となり、それだけで相当量の情報を伝えられるようになった。情報の明知化が起こったわけだ。しかし、明知化された情報を書き文字だけで伝えるには、相当の知識を身につけなくてはいけない。これには時間がかかる。

だからまずは話せる事、自分の意思が相手に伝えられる事が重要なのだ。
そして、最小限度の単語で伝えられるようにする。不要な単語は後回し。
これが基本になる。

そして、この必要最小限の単語は、常に使う。可能な限り常に使う。話す時に使うだけではない。文章を書く時にも可能な限り使うのだ。不自然になるかならないかぎりぎりのポイントまで、英語を日常的に使う事で、いざと言う時の言葉が身につく。


最初の内に覚える英語は、ある意味サバイバルなのだ。

2007年11月8日

英語をどうにかする -3- Passion!

英語は何よりも「伝えようとする意思だ」と書いたが、意思には常に Passion が付きまとう。これをハイにしておくことも同じぐらい大事だ。

再び「うちの3姉妹のチー先生」にご出馬いただこう。

チー先生は

!!!!!っんまんまんまんまんまんまんまんまっっ!!!

と「まんま」を厳しい声で繰り返すことで「お腹がすいた」と主張する。一方で、ご飯が提示されると

♡♥♡まんま♡♥♡

と言うことで、いかに待ち焦がれたか、自分がいかにうれしいか、を表現している。

つまり単語は同じでもイントネーションが違えば異なる意味になる。


もっと極端な例を言おう。たとえば、足を踏まれてすっごく痛い目にあった場合。"Ouch" と言った場合と、

『痛てぇええええっ!!!』

と言った場合とで、後者では意味が通じない、などという事があるだろうか?


これらの事は言葉を覚える上で重要なポイントを教えてくれる。
  1. 英語を覚える場合、最初に覚えるべき単語は厳選しさえすれば、あとは表現力で補える
  2. 痛いとかうれしいとかは、別に英語を覚えなくたって、表現力があれば補える
そして、こういう場合重要な表現力は
Passion
とあらわされる類のものだ。

Passionで表現できることはすべて、そちらで表現する。感情をこめた声、大げさなぐらいの身振り手振り、破顔 と言ってもいいぐらいの笑顔やしかめっ面…こういったもの全てが、あなたの実力不足を補ってくれるのだ。

シャイになってはいけない。いや、こう言った方がいいか:

英語が下手なくせにシャイになるなんて百年早い

英語は心 なのである。

2007年11月6日

英語をどうにかする -2- 意思の力だ!

英語を話せるようになる上で、最も重要なものはなにか。それは
伝えようとする意思
これに尽きる。

逆の言い方をすれば、「伝えるべき事がない」のではどのような言語もなかなか習熟しない。

例として日本語を考えてみよう。

あなたは今、日本語を完全に忘却した状態にある。文法も何もわからない。ここで、あなたは
「自分が空腹である」
事を周囲に伝えなくてはいけない。幸い、あなたには日本語の単語を3つだけ覚えている事をゆるそう。さて、何を覚え、それをどのように使う???

解答例: うちの3姉妹のチー先生

えぇ、3単語も要りません。「まんま」1つで十分。あとは強力無比に連呼するだけ。それで意思は通じます。


逆にこういうケースを考えてみよう。

あなたはある日、近所の小学校の前を通りかかった。
「すみません」
声を掛けられた。
「今日、挨拶に来るはずの人が急に出席できなくなったのです。
申し訳ありませんが、今日卒業する卒業生に送辞を話してあげてくれませんか?」
いや、いきなりそういわれても。あなたはこの地域に引っ越してきたばかりで、子供もいない。なのに30分も話せ、と言う。さて、あなたは何を話す???

日本語に堪能であるはずのあなたも、言葉が出てこなくなるはずだ。


結局、言葉と言うのは「意思を伝えるための道具」なのだ。伝えたい意思があれば、たとえボキャブラリーがどんなに少なくても、意思を伝えようとする。逆に伝えるべきものがない状態で、発言を強要されれば、どんなにボキャブラリーが多くても言葉に詰まるのだ。

だから
"this is a pen" に価値はない
だって「これはペンです」って誰に言いたいんだそりゃ??!

そうではなくて、心の底からこみ上げる衝動を大声で述べよう。さん、はい、
"food!!!!"
おや? あなたは「金返せ」でしたか? 私は大抵の場合「ご飯」になります。

英語をどうにかする -1-

日本でサラリーマンをやっていると、意外と障害物になって立ちはだかってくるもの。それが英語。

もちろん、英語なしで仕事が出来ないというわけではない。でも、新しい情報からは常に阻害されている感じがする。日本語に訳出する人達の恣意的な(あるいは無意識な)フィルターがかかっている気がする…。技術者になると、英語のドキュメントを読め、と言われて終わり、何てこともざらだ。

機械翻訳はまだまだあてにならない。日本語で書いて、それを英語に機械翻訳して、もう一度日本語に直すだけで、大爆笑な文章が出来上がる(そして、それを集めて本が出来てしまう)という事は、直訳・意訳のいずれの意味においても、和英機械翻訳の出力品質はあてにならないし、英和機械翻訳も多くの場合は混乱の元にしかならない、と言うことだ。

偉くなって通訳がつくようになっても問題は解決しない。英語と日本語は単語の並び方があまりにも違うので、通訳は「1文づつ」訳さざるを得ない。彼らの仕事は「正しく」訳すことにあるからだ。しかし、議論などをしていると、相手が話しているのをさえぎって自分が話す、なども必要になる。通訳つきではそのようなことは絶対にできない。そうしているうちに議論は終わってしまう…。


というわけで、ひそかに英語コンプレックスを持っている人は多いのではないか、と思う。実は私だってかなりコンプレックスを持っている。はっきり言って英語は苦手だ。

でも、残念なことに、世の中そうは問屋がおろしてくれない。英語という名の国際公用語を操る必要性は日々高まっているし、英語を操れたときの優位性も圧倒的だ。職探しひとつにしても、英語で自己紹介が出来る程度でも、外資系企業が採用してくれる確率は圧倒的に高くなる。だからしょうがないので、身に着けてはいる。

そこで、向こう何回かかけて、私が使っている英語の身に着け方を書こうと思う。ただしものすごく「入門編」だ。「NOVA」だの「Gava」だのと言った英語教室の入門コースよりもさらに入門の部分を説明しよう。多分ここで説明したことを実行するだけでも少しづつ英語力は上がっていくし、年齢もほとんど関係なく上がっていくだろう。上昇速度は若干遅いかもしれないが、コストも最小限度ですむ。

このテーマは実は一番自信が無い…さて…うまく行くかしら…

2007年11月4日

冬がはじまるよ

たまにではあるが、自社製品をどうやって売ればいいのか、というのは私も考える事がある。マーケティングのプロではないので年中ではないが。言いたい事を理解してもらえるような短いフレーズや、ぱっと本質を理解してもらうための表現を考えるなど、発表の練習にぴったりなもので。

そんな時にはコピーライターというのは偉いなぁ、と思ったりするわけだ。眞木準さんの作品だと

恋を何年休んでいますか

なんてのは秀逸だ。つーか、私の中ではこれは No.1 の一つだ。

で、そんな好きなコピーの一つが「冬がはじまるよ at サッポロビール」。バブル真っ盛りに冬用のビールというコンセプトで物を作ったのはいいけれど、当時は冬にビールを飲むのはあまりメジャーじゃなかった。しかもバブル、秋にはじけてるし…。

どうやって売るのかという時に
『根本的にマーケットを開発してしまえ』
として、槇原敬之が同名のタイトルで作った曲をCMで流して「冬にビールを飲む事」を当たり前にしてしまった。


もちろん、
槇原敬之の曲が良くできていて、CMがスパッとはまったからこそのヒットではあるけれど、そもそもの発想がいい。冬にサッポロビールを飲んでもらう ではなく冬にビールを飲んでもらう に焦点をあてているその一見邪念の無さと、でもよくよく考えてみたら他にそんな広告の打ち方が出来るビール会社なんてあるわけがない、北海道のイメージを持ったサッポロだからできるというしたたかさ。

そういう他にいないポイントを見つけ出して切り込んでいく時の、大きな旗印として
冬がはじまるよ
以上のセリフは、ちょっと無いんじゃないかなぁと思う。

ELTの新しいシングルの2曲目が「冬がはじまるよ」だったので衝動買い。「恋をしている」を無視してずーっと繰り返し「冬がはじまるよ」を聞きながら、そんな事を思い出していた。

2007年11月2日

黒が流行ろうとしている…

なんかここ半月ぐらいの電車の吊広告、やたらと黒のファッションを勧める女性誌が多い気がする。

不況になる寸前の状態では黒が流行る

というのがなかったっけ??
うーむ、微妙に嫌な気配がする。ジリ貧貧乏的な景気の落ち方の気配が…。

2007年10月31日

itojun さん逝去

http://slashdot.jp/article.pl?sid=07/10/31/0311203
http://www.hoge.org/~koyama/itojun.txt

などによると itojun さんが亡くなられたそうだ…ガーン orz ショック。

Security ものでは特に直接お世話になったし、IPv6など間接的にお世話になっているものも含めると、とてつもなくご恩を受けっぱなしなのに…。

ご冥福をお祈りいたします。

天国のインフラを BSD と IPv6 で埋め尽くしてください。

2007年10月27日

新社会人にあなたならまず何を教えるか? -10- まとめ

うーむ。Automationに関してはもっと色々記述するべき事があるのだが、それを書き出すときれいにまとまらない。やむを得ぬ。別の機会にまわすことにしましょう。

というわけでとりあえずまとめです。

私の場合、新人には2つのポイントを教えます。それは Customer Satisfatction (CS) と Automation (AT)。この2つを常に念頭において仕事をする事が大事。

CSはあなたの給料の源泉。CS=T1×T2×Fでその評価が -1.0 から 1.0 の間で定まります。
T1 は 0.0 - 1.0 の範囲、T2 は 0.0 - 1.0 の範囲、F は -1.0 - 1.0 の値をとります。これらをバランスよく成長させる事が大事ですが、中でも F は「他の能力が高い時に、負の値になると悲惨」なので注意します。

ATはあなたの能力を拡大(reverage leverage)させると同時に、あなた自身に楽をさせてくれるものです。また、この能力こそが後輩を育てたりする際の力の源泉でもあり、無駄を省く際の検討材料の源泉でもあり。究極的には「楽に生きるためには努力を惜しまない」という Hacker's Mind の源泉でもあります。

この2つは、サラリーマンだから大事なのではありません。独立起業の際にも、老後の楽しみにおいても、人生の全てにおいて、すべからく重要になります。


追記: reverage→leverage : typo 修正

2007年9月30日

新社会人にあなたならまず何を教えるか? -9- Automation の評価

前回 「自動化を考える場合、もう1つ、評価軸があります」 と述べました。
この軸とは「Automationを使って効率が上がるのか?」という評価軸です。
せっかく色々考えて Automation を実施しても、効率が上がらないのでは意味がありませんから。

Automation …特に「補助頭脳型」の場合、次の5つのような効率化が考えられます。

  1. 実行時間の短縮
    計算機化において特に顕著なのがこれです。紙とソロバンで計算するのに比べて、何億倍も速く計算できるコンピューターは実行時間の短縮と言う意味では圧倒的なパワーを持っています。
    実行時間が圧倒的に短縮されると、機械を動かすための出費が多少高くてもコスト対効果的には十分…などの補助的な側面も出てきます。

  2. 人間が関与する時間の短縮 / 省力化
    洗濯機が良い例です。洗濯において人間が関与する時間が減り、洗濯のために必要な体力も減りました。また、それに伴い、洗濯ができる人も体力に溢れた人だけではなくなりました

  3. 人間が関与するタイミングの集中
    自動洗濯機や自動炊飯器、自動皿洗い機などの例は、全て機械が処理をしている間、人間は自由です。つまり、補助頭脳が A という仕事をやっている間、あなたは B という仕事をすることができるわけです(もちろん、休むこともできます。つまりあなたが就寝中に自動的に処理が進むようにすることも出来るわけです)。
    これは1つ重要なポイントを示しています。
    よく、RedHat Enterprise Linux などが 4枚とか5枚とかの CD で供給されますが、これを1枚のDVDにまとめる、という技があります。あるいはインターネット経由でインストールする、という手段も提供されています。これらは、最初にインストール設定を行ったら、インストール作業の最中に
    「CD を入れ替える」
    という作業のために人間が関与し続けなくてはいけなくなるのを解除するための技です。別の言い方をすると、CD-ROM を DVD-R に焼きかえる、というのも Automation の一種なのです。
  4. 並列処理を可能にする / 複数人数での処理を可能にする
    ちょっとだけすでに言及しましたが、自動化は「なにをするのか全部教えてある」必要があります。つまり「なにをするのか全部教えられるぐらい明確になっている」ワケです。
    と言う事は、同じようなことを複数回行う必要がある場合…たとえば、あなたが会計事務所をやっていて、複数のお客様が一斉に税金申告のための書類作成を依頼してきた場合、何をどの順で処理すればいいのかを明確にしてあれば、アシスタントを使って作業を複数人で並行して行うことが出来るようになるわけです。

  5. 手順を明確にし、それを教えることができる
    何を、どの順で、どう処理していけばいいのか教えることが出来ると言う事は、それらをきちんと伝えて、理解してもらった後であれば、その背景にある理屈なども教えるための素地が出来上がっているわけです。
    つまり、Automation化のための努力は、全てノウハウを伝授する際にも使えるわけです。これはさらに、Automation化の背景にある概念や応用に関しても気がついてもらうための重要なきっかけにもなります。
見ての通り、この5つは相反するわけではありませんが、必ずしも全部を満たせるとは限りません。その事を念頭に置いた上で、これら5つの基準に立った場合 Automation 化がどれほどの効率の改善をもたらすか、考えなくてはいけません。

特に見落とされがちなのは 5 です。「知の形式知化」と「知の伝達」のためには Automation 化がとても重要なのです。そしてそれ自体が、自分以外の人に作業をしてもらう、あるいは機械に作業を置き換える場合に非常に重要な能力になります。一旦形式知化したら、あとはそれを誰に伝えるのか…は Customer Satisfaction の所で述べた Translate/Transfer 能力の問題になります。


Automation は 1,2,3 の性質から、あなたに「時間」をもたらしてくれます。

あなたが仕事をしなくても、成果が出る、
それが Automation の本質です。

Automation だけがあなたに時間をもたらしてくれます。そうして出来た時間を使って、CS で述べた Technology, Transfer/Translate, Focus に関して学習を進めることで、あなたがいままで行ってきた作業の一部をさらに Automation 化することが出来るようになり、さらに時間を得られるようになります。それらの時間を使って、顧客を増やすもよし、別のジャンルにも進出するもよし…。

逆に Automation を意識しないと、手持ちの知識と手作業だけで仕事を繰り返すことになります。時間に余裕はなくなり、常に時間に追い立てられ続ける羽目に陥ります。当然、疲れてきますから、誤りが多くなり手戻りが増え、それらがさらにあなたの時間を圧迫します。睡眠時間を削れば当然それに伴って気づき力、判断力なども劣化。ますます時間が減ってしまいます。
手持ちの知識は徐々に古くなり、周りの人達は Automation 化の恩恵を受ける中、あなたはそれを使いこなすことも出来なくなり…。悪循環が発生します。



私が新人に Automation という概念を教えるのは、それ無しでは学習のための時間が取れなくなるからです。新人の極初期の段階では、研修などを行いますが、これは通り一遍で、現場で必要な知識ではありません。OJT は良い先輩につけばいいのですが、大抵の人は知識に偏りと誤りがあり、それを鵜呑みにするのは危険です。また、OJT で身につく知識の大半は枝葉末節なモノで、10年後にも使えるようなものは極わずかしかありません。

入社後、何年たっても新しいことを吸収できるためには、そのための精神的ゆとりと休息時間が必要です。人間の脳みそはある種のデータ圧縮装置なので、ゆとりがあればあるほど…正確には脳が「ゆとりがあることを知っていれば知っているほど」…本質だけを取り出して記憶する能力があります。しかし、社会人になって以来、「最も暇なのは新人の時」です。それ以降は徐々に忙しくなっていくばかり。そのような状態でも新しいことを学習できるようにするためには、最初の段階で Automation の概念を覚え、自分で出来る範囲から自動化していく事を常に意識し続ける事がどうしても必要になります。

2007年9月29日

新社会人にあなたならまず何を教えるか? -8- Automation の種類 - 補助頭脳型

文具型とは「あなたが手を止めると、ソフトも仕事を止めてしまいます」と書きました。なら補助頭脳型の定義は簡単。

「あなたが手を止めても、ソフトは仕事を続けます」

猫でも杓子でも判る訳ですが、同時に普通、自動化と言ったらこちらを指すわけで…。同時にどうしてそんな事になるのか、その理由も簡単。

「最初になにをするのか全部教えてあるから」

全自動炊飯器、全自動洗濯機のようにプログラムされている場合もあれば(立ち上がりの際に、人間がメニューから何をどうする、と言うのを選んでいると言うのもありますし)、バッチ処理のように実行前にプログラムを1から組み立てる必要があるものもあるでしょう。でも、重要なのはシステムが動き始めたときには、よほどの例外条件を除いてどういう場合はどうする、というのを教えてある、と言う事です。

なので、どうしてそんな手品のような事ができるのか、という所から説明したりはしません。同時にこれが「よほどの例外条件」の場合は途中で止まったり人手を必要としたりするけれど、以下の議論ではそういう「例外」は起こらなかったケースについてだけ述べる、という点についても承知しておいてください。


あ、あともう1点。

「補助頭脳型」をなぜ「補助頭脳型」と呼ぶのかと言うと、まさにあなたという名の主頭脳が付き合ってなくても処理が進むからです。ですので、補助頭脳は計算機かもしれませんが、あなたの代わりに仕事をしてくれるかもしれません。補助頭脳は機械である必要はないのです。この点を留意して置いてください。


さて。

補助頭脳型の自動化にはいくつかパターンがあります。理論上は5つあります。
  1. 完全全自動
    あなたは全く関与する必要はありません。何から何まで全て、自動で行われます。

  2. 開始時点必須型
    処理を開始するときに、絶対にあなたはいなくてはいけません。つまり、何かを始めるときにあなたがいないと、全くスタートしないわけです。

  3. 終了時点必須型
    処理を終了するときに、あなたが絶対いなくてはいけません。つまり、自動で出来る処理が終わった時にあなたが側にいてすぐさま出来たものを次の処理に運ばなくてはいけません。多くの場合、できたものに「鮮度」がある時にこうなりますが、他にも自動車工場のように出来てくる物が大きくて貯蔵スペースが足りないときもこうなります。

  4. 両端必須型
    2, 3の両方を兼ねそろえているタイプです。あなたがいないと作業は開始しないし、終わるときもあなたは必要です。ただ、途中はいなくなっても構いません。

  5. 中途処理型
    2,3,4 は始まりや終わりに人手が必要でした。このパターンは「作業の真ん中で」あなたの人手を必要とします。
1 の「完全全自動」は実現できたらとてもうれしいのですが、現実問題としては実装できません。理由はちょっと考えると簡単です。たとえば自動車工場を考えてください。完全全自動の自動車工場を作れたとしましょう。でも、その工場には自動車を作るための材料を与えなくてはいけません。工場から出てきた自動車をお客様の下に運ぶ必要もあります。どちらも
工場自身には出来ない仕事です

つまり、現在の所、どうしたってあなたの人手はどこかで必要なのです。

「じゃぁ、2,3,4,5 だって同じじゃないか」

その通り。「あなたの手を煩わせる」という観点だけでものを言えば、全ての自動化は 4 のパターンが縦に一杯並んでいるものになってしまいます。ですので、上の説明をよく読んでください。これらの自動化は「あなたを煩わせるかどうか」ではなく
あなたを煩わせるタイミングが固定かどうか
で分類されているのです。


文具型と 2,4 の違いは「洗濯機の進化」で説明するのがわかりやすいと思います。

昔々、洗濯板といわれる、もはや女の子をからかう以外使われなくなった(そして、からかう側もからかわれる側も、現物を見た事などほぼ確実にない) 板を使って洗濯は行われていました。これはまさに文具型。洗濯板は汚れを落とす効率を上げてはくれましたが、あなたが手を止めれば汚れは落ちません。

話を簡単にするために、ある分量を洗濯するには 1時間かかったとしましょう。


ここに、画期的な製品が現れました。「洗濯機」です。
洗濯機は洗い物を入れ、水を張り、洗剤を入れると、『洗う』という作業を自動的にやってくれました。5分から10分ぐらいの時間、あなたは洗濯から開放されると同時に、ハードワークからも開放されました。その後、洗い物を取り出して手で絞ります。排水し、水を入れなおして今度はすすぎです。洗い物を入れて、また 5分から10分…あなたはすすぎの間の時間洗濯から開放されます。もちろん、ハードワークからも。そして洗い物をまた取り出して手で絞り…干しに行くわけです。

見ての通り、これは典型的な 4 のパターンです。
同じ分量を洗濯しているとして、上記の通りだとすると、20分 + 絞り…そうですね10分としましょうか…かかります。色物と、それ以外を分けているとすると、合計60分でこれは変わりません。しかし、内、40分の作業は機械がやってくれます。40分分のハードワークからの開放と、その40分間別のことが出来る(1度には10分しか空いていないため、それで終わることしか出来ませんが)事になります。


その後現れた「二槽式洗濯機」は、「絞り」も自動的にやってくれます。しかも「洗っている最中」に「絞る」ことができるのです。つまり
  1. 色物洗い
  2. その他洗い, 色物絞り
  3. 色物すすぎ、その他洗い
  4. その他すすぎ、色物絞り
  5. その他絞り、色物干し
  6. その他干し
のように洗いと絞りを並列処理する事が出来るようになりました。見ての通り、結果として処理時間が10分短くなり、絞るという重労働からも開放されています。しかし、相変わらず10分ごとに洗濯機の相手をしなくてはいけない事に変わりはありません。


「全自動洗濯機」。いまどきの洗濯機の大半はこれですが、これの最大のポイントは、
洗いとすすぎと絞りを全部やってくれる
事です。30-40分間、洗濯機の相手を全くしなくても良い。長い連続した時間、選択から開放されるわけですから、掃除だろうが皿洗いだろうが、何か集中した事ができます。ただし、色物とそれ以外に分けると、合計で 60-80分洗濯にかかるわけですから、「洗濯そのものにかかる時間」は伸びています。延びていますが、人間が関与しなくてはいけない時間が1箇所にまとまったため、時間を有意義に使いやすくなったのです。

しかし、全自動洗濯機も 4 のパターンです。洗濯機をスタートさせる際には、洗濯コースを選び、洗い物を放り込み、洗剤等をいれ、Go! を押す必要があります。洗い終わったらとっとと洗濯機から取り出して干さないと、洗濯物は腐ります。このため、洗濯を開始したら、終わりのタイミングであなたはまだ洗濯機の相手をしなくてはならず、そのタイミングをずらす事はできないのです。


しかし。ここに。とうとう文明の利器が。現在における洗濯機のファイナルバージョン。
乾燥機能付き、全自動洗濯機
の登場です。実はこいつは 2 のパターンなのです。洗濯を開始するために必要な人手は今迄で最大です。乾燥モードまで走らせると…特に私が持っている洗濯機が初期型だからかもしれませんが…5時間近くもかかります。しかし、
乾燥し終わった洗濯物は腐らないのです。
洗濯機を使わないのであれば、何ヶ月放置しても大丈夫。この意味において、洗濯の処理が終わった際に、そのタイミングで、あなたは必要とはされないのです。

実際、私が良くやるのは、海外出張の直前に洗濯機を動かして出発する事です。1週間後なのか、1ヵ月後なのかはともかく、それまで洗濯物は洗濯機の中です。全自動洗濯機までの洗濯機であれば、どのやり方でも確実に洗濯物は腐ったでしょう。しかし、乾燥まで済ませてくれる事で、洗濯物は「私が出張から帰ってくるまで待っててくれる」ようになったわけです。


3のパターンは…どちらかというと、「障害対策」などでよくあるパターンです。ちょっと家電における良い例が思い浮かびません。

サーバなどの計算機は、必ず「バックアップ機」が用意されています。サービスをしてくれている機械にトラブルがあった場合、自動的にそれを検出する機構が用意されていて、自動的にバックアップ機に切り替わります。これによってサービスが止まってしまう時間を0…あるいはものすごく小さくする事ができます。

しかし、壊れた機器をそのまま放置する事はできません。壊れていないものと置き換え、新しくすえつけたものをバックアップとして登録しなくてはいけません。つまり、障害が起こってからすぐは自動的に処理してくれますが、最後のお片づけは人間がやらなくてはいけないのです。

この方式の良い所は、「お片づけのタイミングを少しだけ後ろにずらせる」事です。夜中の3時に機械が壊れて、バックアップがなければサービスはそのままとまってしまいますから、人間は夜中の3時に叩き起こされ、対処をする羽目になります。このバックアップ機のお陰で、朝の9時に出社したら機械が
「直せーーー、俺は壊れたーーー、直せーーーー」
と叫んでいるのを目にしてから対処しても間に合うわけです。

しかし、あまり長い事放置は出来ません。予備は使い尽くしたのですから、次に故障したらもう終わりです。そうなる前に「予備」を準備してあげなくてはいけません。洗濯機の例で、洗濯物が「腐る」のと同じ事です。その意味で、いつ人間が関与するのか、そのタイミングは 2 のケースほど自在にはなりません。


最後に 5 のケースですが…これの最も判りやすいのは「スチャラカ上司」ですね。

あなたが仕事上何かを購入しなくてはいけないとします。どのメーカーの何を買うのかは決めました。でも、即、注文と言うわけには行きません。偉い人が「その経費を出すよ」と、物品購入書にサインをするなり、判子を押すなりしなくてはいけないわけです。
その人が判子を押したら後はまた、あなたの仕事。購買部に発注を掛けるなり、自分で発注するなりして、受け取って、設置して、それを使えるようにして、実際に使って成果を出して…

スチャラカ上司の立場に立って考えると、これは 5 のケース、つまり「真ん中であなたがサインしないと仕事が進まない」ケースになっている事に気がつくと思います。

実際に 5 のケースになるのは、自動化しているはずのシステムがちゃんと動いているかどうか確認するため、である事が多いようです。おカーちゃんが、子供がちゃんと勉強しているか、監視するのと同じですね。



今回は、『補助頭脳型』の定義と、その自動化の種類について述べました。現実に存在しえるのは:
開始時点必須型、終了時点必須型、両端必須型、中途処理型
の4種類である事と、それぞれが「あなたが拘束される時間が決まっているかどうか」で決まる事、などを説明しました。

実は、自動化を考える場合、もう1つ、評価軸があります。文具型の場合はあまり気にする必要はないのですが、補助頭脳型の場合は特に注意が必要な、もう1つの評価軸について、次回は説明しましょう。

2007年9月23日

新社会人にあなたならまず何を教えるか? -7- Automation の種類 - 文具型

Automation にはいくつかの種類があります。あるものは簡単ですし、あるものは実装が難しい。あるものは効果が絶大ですし、あるものは効果があまりありません。そして何よりも 何を自動化するのか で効能が変化します。

そこで、まずは Automation の種類を見てみましょう。ここではイメージしやすいように、例として電化製品やソフトを例に挙げてみたいと思います。ただし、分類方法は定番の方式をちょっとはずして、私の方法で行ってみたいと思います。

まず、Automationは大きく「文具型」と「補助頭脳型」に分かれます。


文具型というのは…大抵のPCのソフトがそうですね。特に Office Suite と呼ばれる類のソフトは完全に「文具型」です。あなたが手を動かしている間は動作してくれます。あなたが手を止めると、ソフトも仕事を止めてしまいます。鉛筆などと同じ性質を持つわけです。

たとえば、MS-Office のソフトで英語を打つと、1 word 打つたびにスペルミスをチェックして自動的に直してくれます。たまに固有名詞を直してくれて、えらい迷惑だったりしますが。これが文具型 Automation です。技術的には on demand 型と呼ばれるものの大半がこれに当たります。

文具型は「ミスの低減」を目的とする場合に効果があります。スペルミス、あいまいな文章の発見、計算の不一致など、その場で発見すればワケも無く直せるが、後で間違いがあると言われるとどこが間違っているのか全体から見つけ出すのにすごく苦労する種類の間違い をその場で直すのに効果があるわけです。機械の場合ですと、プログラミング環境を統合環境にすると typo を見つけてくれたりするエディターがついてきますが、あれなんかも良い例です。

文具型の Automation について、人間の場合の例ですと…そうだな。マクドナルドなどで、高額紙幣を出すと
「1万円、入りまーす」とか
「8千円、確認お願いしまーす」とか
レジを打つオネーチャンが、他の人にチェックしてもらっているシーンが良くあると思います。あれなんかが、文具型 Automation に近いと言えます。
他には、プログラミングスタイルの一種にペアプログラミングと言うのがありますが、あれも文具型 Automation の一種でしょう。プログラマがペアを組む事で、相互に間違いをチェックし合い、単純な打ち間違いからロジックの間違いに至るまで、様々なヒューマンエラーを減らしていこう、と言うわけです。

しかし、文具型 Automation はやはり、機械に任せた場合圧倒的な効果をもたらすようです。レジスターの中にはおつりを自動的に必要なコインとお札で出してくれるものがありますが、あれですとヒューマンエラーはなくなります。機械の間違いはもちろん発生しますが、一般的に機械がお札やコインを数え間違える確率は、人間が間違える確率の何千分の一、という値です。
逆に言うと、機械に任せてもあまり効果が無い場合、文具型 Automation には向いていない、と言えるかもしれません。


文具型 Automation …というよりこれは on demand 全般に言えることですが… には、1つ大きな弱点があります。即時性が求められるのです。

「8千円、確認お願いしまーす」
と言われて、3時間後に
「さっきの8千円、1万3千円だったわよ」
と指摘されても困るわけです。その場で言ってもらわなくては。

従って、文具型 Automation は複雑な、難しい処理はほとんど出来ません。チェックにかかる時間がほとんど一定で済むような処理…俗に「計算量 O(1)」と言われる類の処理しか出来ないのです。たとえば、先ほどのお札の確認でも、
「千円札で8億円、確認お願いしまーす」
などと言われる事の無いファーストフード店では、手の空いている人を捕まえてチェックしてもらう程度の事しかしません。5千円札、千円札をふんだんに用意する事で、最大でも5枚までしかお札をチェックしなくて良いようにすれば、チェックにかかる時間はほんの数秒で済みます。

しかし、銀行では「千円札で8億円」というケースは無いとはいえません。いや、8億円は無いかもしれませんが、もう少し少額なら店舗が連休のおつり用にと、枚数を多い目に引き出そうとする事は大いにありえますし、逆に一日の売り上げを預ける場合、必要以上に小銭が多くなる事も十分ありえるわけです。
この場合、ちょっと手の空いている人を捕まえる、という方法は危険です。実質お札(やコイン) の枚数に比例して確認にかかる時間は増えるからです。ちょっとトイレに行きたいから…と交代してもらった人をとっ捕まえて80万枚もの千円札を数えさせたら…間違いも増えるでしょうし、そもそもお漏らしをしてしまいます :p

このように、文具型 Automation は適用できる範囲が狭いのですが、その範囲内であれば効果は絶大です。このため、誤り訂正(間違いを見つけて、指摘するあるいは即効で直す)ものには良く使われます。もちろん、訂正率は 100% ではありませんが、そもそもやらなければもっと間違えていたのです。やればやるだけ得、と言う事ができます。


誤り訂正を使って間違える確率を減らすやり方は、より大きな目で見た場合デバッグサイクルを廻す頻度を下げる効果があります。俗に「手戻り」と言われる奴ですね。
「手戻り」の発生は、お客様の信頼を低減させますし、たいていの場合1ターンが結構長い。このため、お客様を待たせる事にもなります。さらに信頼を低減させているため、「次」のチャレンジの際に「重箱の隅までチェックされ」てさらに手戻りを発生させる、という悪循環へと繋がりかねません。もっと言えば、人間は手戻りを食らって何度も同じ事をやり直すと、疲れてきて間違えやすくなると言うおまけまでつきます。

従って、可能な限り誤り訂正が使える所では、使ったほうが良いのです。
実際、これから説明する「補助頭脳型 Automation」を人間に適応する場合、各人が行う処理は可能な限り文具型 Automation による補助と誤り訂正と組み合わせるのが効果的です。


さて、補助頭脳型 Automation ですが…これ以降は次回といたしましょう。

2007年9月22日

新社会人にあなたならまず何を教えるか? -6- AT

AT: Automation … 自動化

普通、自動化と言うと
  • 機械が
  • 最初から最後まで
というイメージがあるけれど、ここで言う自動化はもう少し幅が広くて
  • 機械でも、人でも、猿でも何でも、
  • 一部分しか自動でなくてもよい
というイメージです。中にはこれを しくみ化 と呼ぶ人もいます。ただ、しくみ化はこれはこれでなんか条件が狭いイメージがある(機械というよりは人間がやるとか、最初から最後までは変わらない、とか)ので、私はわざと Automation と言っています。


さて…
Customer Satisfaction の所で、お客様を満足させるのがまず大事だと言いました。とはいえ、あるお客様を満足させるのに 100 の力を投入したら、他の事が何もできなくなります。この他の事の中には
  • 他のお客様を満足させる
  • 自分がやりたい事をやる
  • 家族を満足させる
などが含まれます。ですので、なるべくお客様の満足度が下がらない範囲で、100投入していた力を 95 でも90でもいいから、減らす努力をしなくてはいけません。

自分の力を投入せずに、お客様に提供するものの量・質共に下げないためにはどうすればいいか…他者の力を借りればいいのです。自分が 10 力をセーブして、他者の力を20借りたら同じ品質になる、というのであれば、他者から 20、力を借りればいい。

ただし、お金を借りる場合と違って「他者から力を借りる」のは
「貸して」
「ほいよ」
とは行きません。『何をすればいいのか』『何に対してすればいいのか』『いつすればいいのか』などをはっきりさせなくてはいけません。これらの準備が出来て初めて、他者の力を借りる事ができるのです。

また、他者の力を 20 借りて自分の 10 に充当させる、という例を上で挙げましたが、本当は他人から力を借りたら、何かの時にはその分お返しをするべきです。となると、借りた力もなるべく効率的であるほうが良い。20借りて 10に充当させるよりは、15を借りて10に充当させるほうが良い。

運がよい事に、人間には得手・不得手と言うものがあります。あなたにとって 10 の仕事が、他人にとっては 5 ぐらいで済む仕事かもしれない。そしてあなたも、その人にとって 10 かかる仕事を 5 でこなせるかもしれない。互いに準備を整えるのに 1 づつ力が必要だったとしても、互いに助け合うなら、お互いのお客様の満足度は変わらないまま 96 づつで仕事がこなせる事になります。


というわけで、Automation を考えるにはどのような点を注意・注視するべきか、を述べていく事にしましょう。

2007年9月16日

新社会人にあなたならまず何を教えるか? -5- CS: Focus

こんなシーンをちょっと想像して欲しい。


あなたは吉兆の京都本店にいるとしよう。嵐山にある、あれだ。
あなたはそこでご飯を食べている。もちろん、辺りは…ではなく一色だ。

そこに、サプライズが発生する。KISS の生コンサートだ。そう、ニューヨーク出身のハード・ヘヴィーメタルバンドだ。メンバーがそろそろ全員いい歳だ、というのはちょっと無視しよう。

場所は嵐山。景観は最高だ。
食事は吉兆。食材も、加工技術も超一流と言っていいだろう。
そしてBGMは KISS。ヘヴィーメタルの最高峰…かどうかは異論があるかもしれないが、ちょっとここは最高峰だってことにしておいてくれ。必要なら、自分が最も好きなバンドに差し替えてくれて構わない。

今までの説明の通りだと、それぞれの Technology は最高だ。それを伝えるための技術も最高だろう。

で、あなた、そう、客であるあなたは幸せだろうか?


決して幸せではないはずだ。なぜなら、吉兆でご飯を食べるという段階で、ヘヴィメタを聴くような心境ではないはずだから。あるいはヘヴィメタを聴く心境だった場合、嵐山はただの交通の便が悪いド田舎だし、吉兆のご飯も肩肘が張っているだけで値段に対して味は大して…という心境のはずだ(吉兆の味がどうこう、という意味ではなく、受け入れるような心境には無い、という意味において)。

もし、これがサプライズではなく、最初からそのように予定されており、お客様にそのように伝えられていて、それでこそ良い、というお客様だけが集まったのであれば、これは単に異色の取り合わせでよかったのかもしれない。しかし、サプライズの場合、そこに集まっているお客様は嵐山の景観と吉兆のご飯を、静かな環境で食べたいと思っているのであって、間違ってもヘヴィメタを聴きながらとは思っていないはずだ。


これが Focus だ。


お客様と言うのは、自分が着目しているポイントに関しての Technology を重視し、それに関する説明を熱心に聴く。それ以外のものについては興味は無いのだ。

ある程度までは無視してくれるかもしれないが、邪魔なものがあるという意味においてプラスには取ってもらえない。限界を超えると、もはやマイナスのスコアをつけられてしまう。
「そんな余計なものをつける余力があるなら、
もっと値段を下げるか、
もっと本筋にリソースを集中投下しろっ!!!」
というわけだ。


お客様の Focus から外れた仕事はいかに優れていようとも、いかに説得力に満ち溢れていようとも、評価はしてもらえない。限界を超えて外れているとマイナスの評価さえ受ける。

そう。Technology も Transform/Translate も 0.0 から 1.0 の値をとっていたのに対し、Focus だけは、-1.0 から 1.0 の間の値を取るのだ。そして、お客様が「欲しくない」物について高度な技術が投入され、それがお客様に見える形で提示されると…お客様は激怒する。

なぜかというと、お客様はお金を払っているからだ。そして、その対価として
自分にとって重要なポイントに Focus があたった製品(なりサービスなり)
が欲しいと思っているからだ。自分にとって重要ではないポイントに、投資したお金を使われると、無駄遣いされた、と感じるのは当然だ。この場合、お客様が良く判る形で、無駄遣いされたような印象を与えると、より多くのリソースを無駄遣いされたと感じるようになるので、0.0 ではなく -1.0 の評価を得てしまうわけだ。


新入社員にやらせる仕事の多くは、先輩社員がすでに Focus の調整は済ませてくれているものだ。やるべき仕事のテーマははっきりしており、その内容はすでにお客様の満足度を満たすように調整されている。従って、新入社員の場合、この点を心配する必要は無い。

ただ、新人の段階で Focus の事を十分理解していないと、後で酷い目にもあうし、ひどい迷惑を回りに掛けることにもなる。


Focus が甘いケースと言うのは面白いことに2種類ある。本来あるべき焦点より手前に Focus があたっている場合と、奥にあたっている場合があるのだ。



本来より手前に来てしまった例で私が経験したのは次のようなものだ。

あるプロジェクトが納期を過ぎても完成しなかった。3ヶ月締め切りを延ばしてもらい、新規投入されたマンパワーの一方が私だった。このプロジェクトは Web プログラムを作るプロジェクトだったので、プログラム自体のアイコンが必要になった。で、プロジェクトリーダーはそれを数日掛けて作った。

アイコンの品質は実に素人くさいもので、今回のプロジェクトには丁度良い…つまりどう見ても1-2時間しか掛けていないように見えるものだった。ので、お客様の感想は文字通り
「素人臭い」
だった。これはとても良い兆候だった。プロジェクトは納期を過ぎており、1秒でも早く作れるならば、そのための努力を怠るわけには行かず、無駄なリソースを使っていないように見せる必要があったからだ。しかし、プロジェクトリーダーはそう取らなかった。お客様の満足度を向上させねばならぬ、と思ったのだろう。


リーダーは数日徹夜して、はるかに素晴しいものを作り上げてきた。当然、お客様は激怒した。
素晴しいアイコンを作ったから
お客様は激怒したのだ。そんな所にマンパワーを投入している暇があったら、ドキュメントを1文字でも多く書くべきなのに、ドットをいじっているとは何事か、と言うわけだ。


これは、リーダーがプロジェクトの本質を正しく理解しなかった好例だ。締め切りを過ぎているのだから、アイコンなど「◎」だって良かったはずなのだ。しかし、お客様にとって必要かどうかを熟慮せず、自分の趣味に走った。これは典型的な焦点がお客様よりも自分側にいる例だ。



もう一つは、焦点が逆…つまりお客様のさらに奥に行った例だ。

ある会社がコンサルタントを要求してきた。仮想化技術の将来について現状を評価し、未来を予測して欲しい、というものだった。

このお客様は、仮想化技術を「過去に作ったプログラムを、バイナリレベルで変更せずにいつまで使い続けることが出来るか」という視点に基づいた仮想化技術の評価が欲しいのだ、と言った。プロジェクトリーダーがそれをちゃんと把握できたのかどうかはともかく…調査員はこのことを理解しなかった。

調査員は非常に優秀で、現在ある仮想化技術について、1から100まで調べ上げた。その内容は実に見事なものだった。そして、それをそのまま…つまり「今すでに存在するバイナリを、変更せずに使い続けるための道具としての仮想化」という視点に基づいたフィルタリングをせずに、お客様に提示してしまった。

当然、お客様は混乱する。100 もの情報を与えられ、それを全部噛み砕いて飲み込まないと、その情報の中でどれが自分たちの目的に合った情報なのかわからなかったからだ。そもそも、そんな把握が軽々と出来るならコンサルタントになど雇わない。確かに、与えられた情報は「後で」必要になるかもしれないが、とりあえずは不要なものだ。そのような情報は「削っておいて」欲しかったはずだ。

ちなみにこのリーダーはいまだに何が悪かったのか判っていないらしい…

これはお客様の「先」を「見据えすぎた」例だ。どの情報が必要になるか判らないので、お客様のために「全てを」与えた。結果としてお客様の受容容量を超え、お客様の満足度を下げてしまったわけだ。


ついでだから言っておこう。このお客様が望むような仮想化技術は、ない。

ゲームソフトを仮想マシン上で動かそうとするプロジェクトはあちこちにあるが、微妙なタイミングを無駄なループなどで図っているゲームが意外と多く、タイミングの再生に難儀するそうだ。何しろソフトウェアエミュレーションというのはどんな1命令もハードウェアと同じ速度で実行できるように調整しているわけではないのだからして…

理想的なアプリケーションであれば、仮想化技術で寿命を延ばすのも良いだろう。しかし、そのようなソフトはちょっとした手を加えるだけで、新しい環境に適応する。新しい環境に適応しないのは、ソースコードがなくなっていたり、あってもナニをやっているのやら良く判らない…「いじるな!!! 今動いてるんだから!!!」系のソフトだけだ。そのようなものは、仮想化で寿命を延ばそうにもほとんど伸びない。仮想化ソフトが持っているバグを踏んづけて、ゆとりがなくなってから地獄を見るのがオチだ。

…見ての通り、たった3段落で結論は説明できてしまう。これなら、お客様は一瞬で理解できたに違いない。
100ページを越す大作は、顧客満足度を下げるだけだったのだ。





このように、Focus がきちんとお客様の望むものに当たっている事はとても重要なのだ。お客様に対し、無駄なものを与えるのも、お客様が飲み込めない程の内容を与えるのも、同じぐらい重罪であり、それらはどちらもお客様からは無駄遣いに見えるため -1.0 の評価を受けてしまう。


以上、 Technology, Transform, Focus の3つについての説明は終わった。
Technology と Transform は 0.0 から 1.0 の、Focus は -1.0 から 1.0 までの値をとり、それらの掛け算の結果がお客様の満足度になる。

当然、結果は -1.0 から 1.0 の値をとる。1.0 が大満足、-1.0 はぶん殴られる状態、というわけだ。


…さて、次回は もう一方の重要なポイント、Automation(AT)について説明しよう。Cusotmer Satisfaction だけに注目したのでは、札束で頬を殴られている奴隷と何が違うのかわからなくなってしまうからね。

2007年9月15日

新社会人にあなたならまず何を教えるか? -4- CS: Transfer/Translate/etc..

二つ目のTは伝える力だ。残念ながら、英語でしっくり来るものが無い…

なぜ、しっくりこないかと言うとここでいう伝えるとは、相手を問わないからだ。

もし、相手が計算機ならばプログラムを組んで、あなたの意図通りに動かすことを言う。これに合うのは、どちらかというと意思を「伝達・翻訳」するという意味で Translate がしっくりくる。

しかし、相手が人間の場合は、相手に自分の主張を理解してもらい、納得してもらい、同意してもらい、賛成してもらう事がポイントになる。こうなると本当は Communicate が正しいのだが、そうすると T で始まらない…。いや、それはどうでもいいのだが :p

この能力で大事なのは
  1. 相手に伝えたい事は何かをはっきりさせること
  2. 相手に応じて伝え方を変えること
の2点だ。



判りやすいように計算機のほうから始めよう。

ご存知の通り、計算機は愚直で、単純で、疲れを知らない。正確にいわれたことをやり、いわれていないことはやらない。従って計算機が行うべき作業を緻密に、正確に、指定すれば、その通りに実行してくれる。逆に緻密に、誤って指定すれば、それもその通りに実行する。パフォーマンスがどれぐらい出るのかなども含め、指示次第である。計算機は誤解などしない。計算機に与えた指示が間違っているだけだ。

このような対象である計算機に、計算機が理解できる言語で、何をするべきかを伝えるのがプログラマである。プログラマの仕事は、
  1. その計算機が何をするべきなのかを正しく・漏れなく・重複無く(MECE)理解する
  2. それを 正しく・漏れなく そして…できれば重複無く 計算機が理解できる言語に翻訳する。
メンテナンスを考えないなら後者の『重複無く』は無視しても良い。しかし、大抵の場合間違いは『重複』の部分に存在し、そのせいで直しても直しても『べつの場所』に『同じ間違い』が残っている、という賽の河原が発生するので、出来る限り重複は無くしたい。

計算機に伝えるための言語は、プログラミング言語でありさえすれば何でも良い。もし Linux のように既にあるプログラムに対する機能追加や修正の場合は、Linux がすでに利用している言語(この場合は C言語とアセンブラだが)を使うことになる。それ以外の選択肢は与えられていないからだ。しかし、新しくプログラムを1から作るのであれば、要件を全て記述でき、必要な性能が出るのであれば本質的にはプログラミング言語は何でも良いのだ。

別の言い方をすれば、優秀なプログラマの要件の1つは多くのプログラミング言語を知っている、という事だ。あえて言うならば、計算機をプログラムするに当たっての最も Primitive な言語である Assembler は理解しておいたほうが良い、と言う程度だろう。


伝える内容は最初のT, Technology で指定された内容になる。

伝えるべき内容が 0 であれば、プログラミング言語をいくら知っていても出力は 0 だ。逆に伝えるべき内容が判っていても、プログラミング言語を知らなければ、やはり出力は 0 になる。



理解しにくいのは次の「人間を相手にした場合」だろう。実際私も得意ではないので、なかなか上手に伝えられないのだが…。

「シッタールダ王子は何が偉かったのか?」

という命題がある。シッタールダ王子というのは、ご存知『仏陀』になった人だが、この人は

悟りを開いたのがえらいのではない

えらいのは、

「悟りを開いていない」人に、
「自分は悟りを開いたのだ」と言う事を、
伝える能力があった


と言う点だ。もしかしたら、彼以前にも悟りを開いた人はいたかもしれない。でも、まだ悟っていない人にその事を伝えられないのでは誰も弟子にはならないし、当然他人を悟りに導くことも出来ない。

仏陀の仏陀たる所以は、「悟っていない人に、自分は悟っており、相手を悟らせることが出来る」と説得できたことにあるのだ。


ここでいう「悟る」というのが Technology にあたる。人間を相手に Communication をはかる場合に重要なのは、

技術を理解していない相手に、
自分は技術を理解している事を伝える


事なのだ。

もちろん、世の中には「天才は天才を知る」という言葉があるように、本当に超高度な Technology を厳密に伝え合うためには、相手も自分も同じ Technology をほとんど全て理解し、扱えなくてはいけないだろう。「相手に自分が知っていることを全て伝える」事が常に可能なわけではない。

しかし、思い出して欲しい。我々は「お客様を満足させるために」Communication をはかろうとしているのだ。何もお客様と、ユニゾンをはかろうとか、
「あなたと一つになりたい」
などとエヴァンゲリオンのテーマのようなことがやりたいわけではないのだ。であれば、全てを伝える必要など無いではないか。

人間と言うのは「信じる」という行為を取ってくれる。ある一定以上、相手が正しいことを理解したら、「前提と結論との結びつきがまったく理解できないにもかかわらず」その結論が正しい、としてくれるのだ。

このような場合、大事なのは 1から100まで全てを伝えることではない。乱暴かもしれないが、
  • まず、相手に自分がいう事を信じるように仕向けること
  • 次に必要最小限の前提と結論を覚えてもらうこと
  • 運がよければ、その中のいくつかについては理由も理解してもらうこと
程度を目標にするので構わないのだ。


判ると思うが、「最小限度」というこの条件を満たすためには MECE の考え方は役に立つ。重複があると、情報量としてのエントロピーは増えないのに送受信しなくてはいけないビット数は増えてしまうのだ。人間は「飽きる」し「疲れる」ので、余計な1ビットがあるとそれだけで受信ミスを起こしたり、受信拒否を起こす確率が跳ね上がってしまう。

もう一つ大事なのは、文法上の間違いやあいまいさを排除する事だ。最後まで読めば意味が一意に決定するが、途中では何通りも解釈がありえる、なんてのもダメだ。読むほうにすれば、1つの文章を読んでいるだけで何通り分もの脳みそを使えと言われたことになる。見る見るうちに疲れ果て、読む気を失うのが先か、読み間違えるのが先か…いずれにせよ、あなたの目的は果たせないだろう。

このように、ちゃんと受信してもらえるようにすること、Transfer が人間の場合重要なキーポイントになる。




このように、相手によって、何をどのように伝えるべきなのかは変わる。

これは「伝える」事そのものが目的なのではなく、

お客様に満足いただくために
情報を伝えている

からだ。

お客様に満足いただくために、計算機に正しく動いて欲しいから、正確に、厳密に、漏れなく、重複無く、計算機にやるべきことを伝えなくてはいけない。
お客様に満足いただくために、お客様が理解しなくてはいけないことを、お客様が受け付けてくれる形で伝えなくてはいけない(あるいは、お客様以外の人であっても同じだが)。


私の場合、多くの新人は理系の学部を出ている。そのためか「日本語の文章が不自由」な人が多い。この blog にも誤字脱字、文法の間違いは多いが、この何万倍も酷い間違いをして、なおかつどこが間違っているのか判らない、と言う人が多くやってくる。

この場合、Technology は問題ない。また、計算機への Translate も問題ない。しかし、人間への Transfer に問題があるわけだ。

可哀想だが、やることは一つ。作文の特訓である。
だいたい2年ぐらいかけると、誰でもわかりやすい文章を書けるようになる。そして、そうなると、その新人の評価はぐっと高まる。
T x T

の左の T は最初から高い数値だったのに、右の T の値が低かったため、計算結果が小さな値になっていたのに過ぎないからだ。ちゃんと他の人に伝える能力がつけば、評価は高くなって当然である。



新人の間はこれでほとんど問題は無い。しかしたまに、転職組などで問題が出るケースがある。それが第3番目の項目、F がきちんと出来ていない場合だ。新人の場合は仕事の範囲が狭いため、Focus がぶれることは無い。しかし、転職組の場合はもう少し幅広いレンジを相手にすることが求められる。すると Focus の問題が発生するのだ。従って、新人の段階から Focus についても説明することにしている。ただし、彼らがそれについて実感するのは3年目以降になるだろうが…

というわけで、次回は Focus について説明しよう…。

2007年9月9日

新社会人にあなたならまず何を教えるか? -3- CS: Technology

順番に行こう。

まずは最初のT、Technology = 技術だ。

大昔、各人、あるいは家族単位で必要なものを全て自己調達していた時代はあった。しかし、現代では全てのものを自己調達している人はほとんどいない。大抵の人は家を専門家である大工さんに作ってもらう。大工さんはトンカチや釘、木材を自分で作ったりはしない。これらを作るのは別の職人さんだ。

このように現代の職業は分業で成り立っている。分業することで、各自自分が専門とするものに集中でき、結果として社会全体がより高い品質の製品やサービスを手に入れられるようになった。この「分業」の単位になるものの一つが技術だ。

ここでいう技術は、単に何かを作る、というだけではない。もちろん、作るにしたって製鉄から、板金から、プログラムから…と色々あるわけだが、他にも魚を捕まえる技術、植物を育てる技術なども考えられる。レストランに行った場合、客の後ろから食器を並べるのだって技術だ。


基本的に私自身はコンピューターのソフトウェアを作るのが本業になるので、その系統の技術レベルは高い。当然教育する相手に最初に伝えるのもそのような技術になる。しかし、大抵の人はそれ以外の特技なり何なりを持っている。それらも含めての技術、と言う事になる。

私の職能上、後輩がこのエリアに問題がある事はほとんど無い。大学などでそこそこ学習してきているからだ。逆に言うと、ここに問題がある場合は、学校と同じように教育するしかない。ただし、社会人になっているので「スパルタ」方式を使うが。


一つ重要なポイントがある。たとえばプログラムを作る場合、「C言語を理解できる」とか「アセンブラが読める」などの特性は、実は Technologyには含めない。それは Transfer/Translate のTの方に属する。プログラムの場合はその数学的な構造が理解できるとか、構造を作り上げることが出来る、と言ったものが技術であって、C言語は文字通り「言語」に属する特性なのだ。


この技術というものは純粋化していくと、数学に帰着する。釘の打ち方、鍋の振り方でさえ、数学に帰着するのだ。大抵の人は「帰着するまで深く考え抜かない」だけであって、そこに数学が無いわけではない。

このため、世の中の様々なことを適切な数学モデルに翻訳できた場合、応用性が非常に高い。ジェネラリストを育てたかったらまずスペシャリストになれ、最初にジェネラリストを目指そうとすると、太鼓もち以上にならない、というのはこれゆえである。

2007年9月8日

新社会人にあなたならまず何を教えるか? -2- CS

会社に勤めている場合、最も重要なのはお給料である。

そもそも、給料をもらわなくても生きていけるのであれば、仕事なんぞする必要は無い。好きなことをして生きていればいいのである。

しかし、それでは実は生活が成り立たない。だから仕事をするわけだ。学生までの時代と社会人との最大の違いは、「生活が成り立たない」経済状態に対し他者が支えてくれるかどうかだ、と言う事も出来る。


さて、そのお給料だが、一体誰が払ってくれているのだろうか?

あなたの会社の社長だろうか? それともアナタの上司?
営業マン?
研究員のような非営利部門の場合、営利部門である開発部隊とかだろうか?

全部間違いだ。あなたのお給料になるお金を払ってくれているのは、

あなたの会社にお金を払ってくれているお客様だ。


さて、次の問題。

お客様に何か物を売って、利益を得たとする。その利益の中からアナタの給料が払われるわけだが…そのお客様が
「もう二度と、あいつらから物を買うものか」
と思ったらどうなるだろう?


実は2つ問題が発生する。

1つ目の問題は「風評」というものだ。

あるお客様が「二度とあそこから買うものか」と思った場合、そのお客様は単にそう思うだけではなく、その事を周囲に伝えるはずなのだ。そういう話を聞いた周囲の人の何割かは
「じゃぁ、あそこから物を買おうかと思っていたが、止めようか」
という判断を下すだろう。

つまり一人のお客様が不満一杯な状態で契約を終了すると、何人かの潜在的なお客様を失っている事に等しい状態が生まれるのだ。当然、そうなればあなたの給料になるべきお金が会社に入らなくなってしまう。


2つ目の問題は「リピーター」という問題だ。

今、世界中で人口は 60億人しかいない。その20% 以上は一日の生活費が一人1円程度…というレベルにある。このような世界で、一度しか商売の相手になってくれない人ばかり増やせば、一人当たり1円づつ利益をあげられても、総額で60億円しか儲けられない。

一人1000円づつにして、その代わり全人口の1割を相手にするとしても、6000億円で止まってしまうのだ。平均年俸が600万円の社員を抱えている場合、10万回しか給料は払えない。1万人を雇って10ヶ月で破綻するのか、1000人で8年ぐらい持たせるのかはともかく、その程度しか稼げないのである。

これは金額がいくらであっても同じだ。有限の人口を相手に、一人当たり有限回数しか商売しないとするならば、あなたの会社の収益の上限はたかが知れてしまうのだ。この限界を打破するには、おなじお客様から何度も利益を戴くしかない。


以上2つの点から、売買でもサービス契約でもいいから、商売をした場合、お客様に
「あぁ、この人達から物を買ってよかった」
と満足してもらわなくてはいけない。そうして
「もう一度、この人達から物を買ってもいいかな」
と思ってもらわなくてはいけない。

このお客様に満足してもらうこと。これが顧客満足… Customer Satisfaction というものだ。


あなたが会社で仕事をしているのは、お給料をもらうためであり、そのお給料はお客様が払うお金から出来ている。もし、あなたが給料を払い続けて欲しいと考えているなら、お客様に「お金を払い続けたい」と思わせなくてはいけない。

社長でも、上司でも、営業でも、営利部隊でもない。
お金を払ってくれるお客様の満足 につながるような内容を仕事としなくてはいけない。
極端に言えば、社長や上司や営業の意向なんぞどうでもよいのだ。


顧客満足の向上には何をすればいいのか、顧客満足ってどうやって測ればいいのか、などなどこのテーマは結構深いのだが、新入社員にそんなことを言って混乱させてもしょうがない。ので、私は

CS = T × T × F


を説明している。なお、最後のFはここ数年で、重要だと思うようになった。

さて、それぞれ何の略かと言うと:


最初のTTechnology つまり 「技術力」
次のTTransfer/Translate つまり 「伝える力」
FFocus 「焦点」


2つの T は0.0 ~ 1.0 の間の値を、最後の F は -1.0 ~ 1.0 の値を取る。掛け算の結果が顧客満足度というもので -1.0 から 1.0 の間の値を取る。満足度は 0.0 が「まったく満足していない(無価値と評価される)」、1.0が「完璧な満足」と定義する。-1.0 は「ふざけるなこの野郎」で、「損害を与えた」と思われている、という状態を意味する。

この3つを正しく理解し、正しく実行しないと、わけのわからないことをやることになってしまう。

というわけで、次はこの3つについての説明だ…。

2007年8月31日

新社会人にあなたならまず何を教えるか? -1- CS と AT

数日前、会社で "mentee training" という謎のトレーニングがあった。 mentor training ではなく
mentor から指導を受ける mentee
のトレーニングだ。

mentor が本来きちんとなすべきことを mentee 側が意識して mentor を誘導する必要がある段階で、もはや mentor : mentee の立場が逆転しているも同然なのだが…それはともかく。


このときふと、

私が新社会人のトレーニングを受け持ったら、最低限何を教えるだろうか?

というテーマでここに書いていない、という事に気が付いた。また、これらをきちんと理解している人が、今の会社にも少ない…身分上の上から下まで、ことごとく少ないうえに、年齢を食っている人の中にも理解していないものがかなりいる。

HR の TかSがさんにはその場で話したはものの、TかSがさんの反応も鈍い…
これはいけない。というわけで、書く事にした。


私の場合、一貫して2つのことだけ意識する事を伝えようとしている。細かい社則はマネージャーの方が詳しいし、人には得手・不得手があるので、私と資質がある程度合致していないと私のやり方はきっと参考にならないからだ。


普段、私はこの「2つの事」を CSAT と略している。

CS: Customer Satisfaction
AT: Automation

の事だ。



で、実はなぜこの2つが大事で、この2つだけは最低限理解して欲しいことで、他は「個性」で済ませてしまうぐらいどうでもよいことなのか、それを理解してもらうのが実は本質だったりするのだが…という所で、次回に続く。

2007年8月17日

雨が降るーー

うれしい。

やっと雨が降ってくれた。
外気温がものすさまじい勢いで下がり、降雨前32度あったのが先ほどの車の温度計では26度に下がっている。

今日は軽度の熱中症で調子を崩していただけに、ハッピーハッピー。

あとはこの涼しさを利用して大爆睡すれば健康状態は回復だっ!

2007年7月24日

「考え方」と「インターネットの実装のされ方」: その3

「あなーたをー、感じてーいーたーいー」

しまった、これは坂井泉水さんの歌だったのか…。どうやら森高千里とZARDが一部混ざっているらしい…。



まずはこれを書いている段階で、もらった答を一つ紹介しましょう。
匿名 さんは書きました...

問3の答え:
小学校時代に読んだ本の中に書かれていたガウスの逸話を思い出して、そこに書かれていた解法をなぞりました。
「なぜ思い出したか」に対しては「1から100までの数」「合計」という語から私の脳において連想記憶が働いたのだと思います。

ふむ、微妙な答ですね。

入力を「1から100までの数」と「合計」を入れると、black box があってそれが「連想記憶」というシステムで解き方を引き出してくれたわけですか。

この答には4つのさらなる質問が発生します。

1) その「連想記憶」という black box はどういう実装になっているのでしょうか?

2) その「連想記憶」というメカニズムを「使おう」という意思判断はどのようにして実装されているのでしょう?

3) その検索されてきた「解き方」が正しい(つまり間違った答を引っ張ってきたのではない)
かどうかはどうやって判断したのでしょうか? また、計算結果はどのようにして検算したのでしょう?

4) そもそも、あなたの頭の中に「連想記憶」システムがあると言うことはどうやって検証したの?

意地悪? そうかもしれない。でも「考える」という動作を分解していくと必ずこうなります。


1つのブラックボックスは、かならず「入力」と「出力」を持ちます。ブラックボックスを分解しようとすると、2つ以上の「入力と出力を持つブラックボックス」の組み合わせが出てきます。しかし、「最小単位」が判らない限り、「ブラックボックス」はどこまでもブラックボックスに分解できてしまうという性質を持ちます。しかも、あるところにブラックボックスを想定すると、そのブラックボックスを使おうとしたメカニズムも必要になります。

「電子回路ならトランジスタに帰着するじゃないか」というのは原因と結果を取り違えています。「トランジスタに帰着する」のではなく、

「トランジスタを使って、論理回路の最小セットを作り上げ、
それで十分であることを数学的に証明した人がいる」

のです。その上で、論理回路の組み合わせを考えて、等価な出力を得るために必要なトランジスタ数を減らしていく、という努力(時には、トランジスタ数を増やして出力を得るまでの時間を短くする、という努力だったりもしますが)の結果が、今の電子回路なのに過ぎません。電子回路はあくまでも演繹によってもたらされたものであって、帰納的分解法の結果ではないのです。

ブラックボックスをトップダウンで分解していくと、Atomic 回路を定義しない限り、どこかで nand 回路になり、nand 回路は not 回路と and 回路になり、not 回路も and 回路も nand 回路で表現でき…と、どこまでも分解できます。意味の無い分解ではありますが、どこまでも分解できるのです。従って、ブラックボックスモデルは、回答へ導いてくれるわけではないのです。


きちんと証明できるわけではありませんが、思考というのは言葉で説明できる中間状態その中間状態を繋ぐ、言葉で説明できないネットワークでできているのだ、と言うことができます。我々が共有できるのは 言葉で説明できる中間状態 だけであって、中間状態を繋ぐ言葉では説明できないネットワーク は説明もできなければ共有もできないのです。

「どうやってその結論に至ったのですか?」

という質問に対して、「中間状態の羅列」で答えてくる人しかいない事がこのモデルの一面の正しさを物語っています。


しかし、「考え方」というのは、実は 言葉で説明できる中間状態 のことではなく、ネットワークの方です。

中間状態 A から中間状態 B へと遷移するのと同じように、中間状態 A' から 中間状態 B' へと遷移することで結論Z'へと到着する、という考え方のパターンは「中間状態」で説明できるものではありません。逆にネットワーク的には中間状態 A → B → C →… →W→X→Y→Z という経由さえたどっていれば、各矢印の部分がどのように作られていようと「等価である」とする以外ありません。

しかし、それではたまに存在する天才がいきなり A → Z へとジャンプしてみせる場合の考え方を説明することはできません。この人が、BからYまでのどこを経由したのかすら、知ることはできないのです。


これは The Internet におけるパケットの伝達と似ています。IP パケットは発信源からスタートして、複数の router を経由して目的地に到着します。router がいくつあって、それぞれがどういう IP アドレスなのかは、traceroute などの技術を使うと追跡することが(ある程度は)可能です。

しかし、発信源から router、router から router、router から目的地へと、パケットがどのように伝達されるべきなのか、Internet は定義しません。Ethernet だろうが Token Ring だろうが、伝書鳩だろうが、何であっても構わないのです。まさに Internet は「network が存在する」事を大前提として、それらを繋ぐ方法を提供しているのであって、

networkを実装する方法

を提供しているのではありません。しかし、「このパケットはどうやってここからそちらに届くの?」という質問が本当に尋ねているのは、network の実装方法であって、Internet が network をどうやって繋いでいるのか、ではありません。それは似て非なる問題をミスリードして解いているのに過ぎない。


network が非現実的な性能しか出せないなら Internet に価値が無いのと同様、いくら中間状態を説明できても、その中間状態同士をどうやって繋ぐのか判らないのでは、「考え方」は学習できません。いくら中間状態を教えても、それだけでだと

運よく中間状態同士を繋げた人だけ

しか考え方は判らないのです。その意味において、考え方は「見せる」ことはできません。


いや、それだけではありません。中間状態同士の接続が正しいかどうか検証できないのですから、「実行してみることなしに」検証することもできません。しかも実行してみるとなると、turing の定理が悪さをします。そう「正しさ」を検証するすべは無く、運が良くても「あなたは間違っている」事が判る程度なのです。今回、こんなに長い時間が経由してから「あなたを感じていたい」は 森高千里の歌ではない、という事を発見した私のように…

「考え方」と「インターネットの実装のされ方」: その2

いけない!
一月も更新をサボってしまった。

Ottawa Linux Symposium 2007 とか、帰ってきたらお客様の所での障害がえらいことになっているとか、いくつか要素が固まって、落ち着いて考える暇がなくなってた…というのはいいわけだな。

さて、話を1ヶ月前に戻して。

ちょっとした例を考えよう。

「1から100までの数を全部足した合計を求めなさい」

という問題があったとする。これを解いて欲しい。

一応答を先に行っておくと 答は 5050 なのだが、重要なのは 5050 という数字ではない。
どうやってその 5050 という答にたどり着いたのか、だ。


まずもって、1+2+3+4+....とやった人はそんなに多くはいないだろう。いないだろうが、いるかもしれない。その人は次の質問に答えて欲しい:
問1) もっと早く解く方法があったかもしれないのに、真面目に 1から 100までを足すことに腐心した理由は何?
多くの人は 『1から nまでの和は n*(n+1)/2 で求められる』という公式を使ったと思う。確か中学ぐらいで教わったはずだ。その人は次の質問に答えて欲しい:
問2) その中学のときに教わった公式は、どうやって思い出しましたか?
少なくともこの問題を読むまではこの公式を思い出してなどいなかったはずです。と言うことはこの問題を読んでから、何らかの思考が働いて、この公式を思い出したわけですよね?その思考パスを説明しなさい、という意味です。
中には「一から n*(n+1)/2 の公式を求めた」あるいは、「1+2+3+4+ ....+100 という式と、100+99+98+....+1 という式を縦に並べて、両方足すと 101 が 100個になる。2回同じ式を足しているから2で割った」というやり方をしている人がいるかもしれません。多分、このパターンが一番頭がいいんでしょうが、そういう人は多分この質問の答が難しいことも知っていると思います:
問3) 問題を読んでから、あなたがそのやり方に到着するまでの思考を他人が判るように説明しなさい。

問1から問3までは全て、同じ事を聞いています。
あなたの頭はどのように動作しているのですか? というのが問いです。

もし、この問いの真の答を世の中の平均より少し優れた人から聞くことができたら、それだけで世界中の人々の知性は少しだけ向上するはずです。最高の天才から答が得られたら、世界中の人々の知性は相当に向上するでしょう。芸術家からこの答が得られたなら、芸術のバリエーションは一気に広がるに違いありません。

いや、もっと身近な例でも。親が子供に「ものの考え方」を直接伝達できたなら、子供は学習にかかる手間を相当省けるでしょうし、子供の学力の最低ラインは親によって保証されている、と考えてもいいでしょう。

しかし、実際にはこのようなことは一度も起こっていません。
「考え方」の本質を教わって全人類のレベルが一斉にあがったことなど過去に一度もありません。
天才によるそのような貢献もありません。
芸術家は、自分がどうしてその芸術作品に行き着いたのか、ろくに説明できたためしがありません。

そして、どんな人間も生まれてからこの方、1から物事を学習し、考え方も自分で開発する必要があったために、「鳶が鷹を産む」のの何倍もの確率で 鷹が鳶を生む という状態に陥っています。


そして何よりも悲惨なことに、「考え方」を表現する方法が無いこと自体を理解しない「考え」の持ち主を生み出してしまいます。


さ、真の謎は2つです。

1) 考え方を表現できないのはなぜか?
当然理由があるはずです。

2) 考え方を伝えられないのはなぜか?
プラナリアのような下等生物は、ぶった切ってもそれぞれが個体になって
生き続けることができますが、その際に切る前の個体が持っていた記憶をある程度
継承するそうです。

また、プラナリアに「光と電撃」を条件反射として学習させた後、そのプラナリアをぶつ切りにして
別のプラナリアに食べさせると、「学習したプラナリアを食べたプラナリア」も「光」に反応する…
つまり条件反射が「伝わる」そうです。

ということは、頭の中身を伝える、という機能は少なくともプロトタイプは存在していることに
なります。なぜ、進化の過程でそれが人間に継承されなかったのか? 何か都合が悪いのか?
それともその機能を持った生物が進化するにはもっと時間が必要なのか?
これも楽しそうなテーマです。

というのを楽しみに、問1-3の内、自分が該当するものを解いてみてください。

2007年6月19日

「考え方」と「インターネットの実装のされ方」: その1

6/10 から、マサチューセッツ州Hopkintonの周りに来ている。Training を受けるのが理由の一部、知り合いに会うのが理由の一部、OLS2007に参加するのが理由の一部だ。

で、最初の1週間は Training。タイトルは "IP Network Troubleshooting"。タイトルどおり、Internet を使ったネットワークにおける障害解析についての初歩入門コースだ。障害解析をするためには、当然

Internet ってどうやって機能しているの?

という点を教えなくてはいけない。ので、最初の3日ぐらいが学習、あとの2日が実習になっている。ISO/OSI モデルにマップした上で、下位4層… TCP port の辺りまでを主に説明するのだが、

滅茶苦茶楽しかった

いや、やっぱりこっちのプロの講師は本当に上手だわ。英語でガンガン説明されているはずなのに、全然辛くない。いや、その内容を全部知っていたのだから言語的に辛くないのは当然なのだが、逆に退屈することも無いのだ。話し方といい、例の出し方といい、自然に見えて実は結構研鑽を積んだ結果に違いない。



で、丁度夜が暇…というか腹が一杯で動けない状態に陥っているので、/.J の日記を見ていたのだが…まさか「考え方」ってどういうものなのか、知らない人がいるとは思わなかった。まさに

「は?」

と言う感じ。


びっくりしたときは blog のネタである。せっかくなので、習ったばかりのネットワークの話にマップして、「考え方」がなぜ説明できないのか、を説明してみよう。

今回のネタはさすがにすさまじく思いつきなので、上手くいかないかもしれないが、ま、とりあえずごろうじろ。

2007年6月12日

Content-addressable storage -6- CASをどこに使うのか?

さて、第3回の時に青の領域で使う技術として CAS が出てきている、と言う話を終わりのほうに書きました。それはどういう意味なのか?


青の領域はIOが少ない。中でも write はもう滅茶苦茶に少ない。と言うことは、ファイルの内容が変更される可能性はほとんどない、と言うことです。

このような状態のファイルを集めてきましょう。多分、あなたのPC上のファイルだって、1年ぐらい使い続けていればそのようなファイルが結構あるはずです。普段は使うわけではないのですが、HDD上に無いとそれはそれで困るようなファイル。生半可にHDDの肥やしとなっているようなファイル。それらのファイルを CAS に入れることを考えてみましょう。



まず、そのようなファイル、実はあちらこちらのディレクトリに同じファイルが複数あったりしませんか?ここでいう「同じ」というのは、中身がまったく同じと言うこと。なぜそのようなファイルに着目するかと言うと、CAS の場合中身がまったく同じファイル同じファイルとして扱うことになるから。つまり、ディスクスペースがそれだけで何分の一かになるわけです。一種のデータ圧縮がかけられる。


次に、青の領域にいるファイルの定義からして、当然そうなわけですが滅多にアクセスされることは無いという特徴もあるはずです。と言うことは、IO速度は気にしなくていいから、遅いHDD上にCASを作ってそこに置けば、かなり「保存ビット単価」が下げられるはずです。たとえば 15,000rpmのHDDって滅茶苦茶早いですけれど、価格.com によると、73.4Gbyte で26,979円っていう値段だったりします。
367.5円/1Gbyte。SAS。

これが 5400rpm のHDDになると12388円で 500Gbyte…24.7円/1Gbyteにまで落ちてしまうわけです。SATA。値段は 1/15 です。滅多にアクセスが無いならこれでかまわない。壊れやすさとかは念頭におく必要がありますが、それでもRAID1で5重化するという、ウルトラリッチなモデルを作っても、ビット保存単価はまだ 1/3 です。5重化を全部遠隔地に分散させても痛くもかゆくも無い。だってアクセスしないんだもの。とは言え、これで本当に性能が足りるのか?

CASではファイルが上書きされることはありません。と言うことは、ファイルシステムに対するデフラグをかけると、ものすごく効果的である、と言うこと。しょっちゅう書き換えられるファイルを管理する NAS ではフラグメンテーションによる動作効率低下が結構問題になって、それを解決するために高速なHDDを使ったりするんですが、CASの場合はちゃんとデフラグすればその効果は一生もの。と言うことは、HDDの回転速度が遅くても、ファイルを読むために必要なヘッドシーク量が少なくできるCASの場合、実は性能劣化は通常のファイルシステムにおける15000rpm対5400rpm ほどは発生しないと言うことで…ただし、CAS用に使うファイルシステムが、ちゃんとしたデフラグ機能を持っている必要がありますけどね。

CASでもファイルシステムなので、管理情報は更新されていきます。これに対してファイル本体はほとんど更新されません。と言う事は、管理情報はHDDの高速な部分(外周部)に、データ本体は内周部に置くと効果があるわけで…。



CASはファイルシステムとしてはほとんど変わることがありません。と言うことは、ここにかんしてはデータを一度バックアップしたら、新規データが保存されるまで、バックアップは必要ない、と言うことです。また、そのバックアップも極力差分バックアップでよい。と言うのは、古いファイルを上書きすることが無いので、新しい更新は常に新しいファイルの発生を意味するからです。新しいファイルの発声しか存在しないなら、古いバックアップイメージ中に無駄なビットは存在していない、と言うこと。全体のバックアップを取り直しても意味はありません…。

CAS の部分は5重化してデータを持っていても大丈夫、と言いました。また、それらは遠隔地にあっても痛くは無い、と。また、前回、Lazy にファイルのレプリカを取るシステムの話をしました。どこかから、CASにファイルを移動する際に、CAS同士のレプリケーションが3重以上になったら「大本」を消す、というルールを適用できるような移行システムがあったら…多重化に必要な時間を大きく気にする必要はなくなります。「いっせーのーでー」という感じで同期しようとするからいけないんです。Lazyに、ずるずると多重化するなら、むしろ気楽になる。



どうでしょう? 何か見えてきましたか? そう、青の領域のファイルを意識し、CASというシステムを導入すると、従来サーバ用途としては使い物にならないとされてきたHDDや、HDDの内周部分などの使い道が出てくる、と言うことです。これらをCAS用に使い、従来の高性能な部分を赤や緑の領域用にと専門に割り振ることで、全体の性能を向上させつつ、ビット保存単価を下げることができるようになる、と言うことです。赤や緑の箇所が1年経っても2年経っても、システムの50%以上を占めているとするなら…もし、企業であれば何かおかしい、と考えたほうが良いでしょう。青い部分のファイルが勝手に消えている危険性があります。

実際、赤の領域は NetApp の Filer に、緑の部分は高性能な NAS に、青の部分は CAS に割り振り、ファイルをその間で自動的に移行させながら、データを管理するのが最も効率よくなるはずです。



別の考え方として、HDDをパーティションに分割するのをやめて、単一ファイルシステムで全てを管理させてしまう、という考え方もあります。赤、緑、青の各世代にあるファイルを、どのように管理するのか、その管理方法を世代ごとに変更する。赤はHDDの最外周の高速な所に、青はCAS 型管理にしてHDDの最内周の低速なところに集めた上で、デフラグをしっかりかけ、多重化して持っているデータは(unix file system における、ハードリンクの要領で)重複を消してしまう。



他にもこういう使い方が考えられますね。



CAS はファイルの変更が起こらない。と言うことは、内容をよく精査して、Indexing などをしっかり行えば、検索が速くできる。

検索…そう、Google が行っているサービスなんかも、実は CAS に対する検索の高速化、とみなすことができます。Web上にあるページのコピーをとる。このコピーは、Google に到着した後は変更されない。この段階で一種の CAS のように管理できるようになります。で、このCAS内のファイルに対する Indexing を行う。Google の場合、同一HDD上の多重化を消して、代わりに複数のサーバが互いに持っているイメージは互いが互いのレプリカとして考える事にすれば、バックアップはすでに取られている状態になる。

日付が変更されて、同じ内容のままなページは過去に行われた Indexing の結果を引っ張ってくれば終わり。新しく変更されたものだけ Indexing を行えばよい…。

こう考えると、Google のサーチエンジンは、CAS の考え方が背後に存在する、とみなすと、その多重化、高速性能、分散性などが一気に判り易くなります。あれは CAS 相手だからこそ、多重化できるし、複数に分散しているもの同士の「同一性」が判別できる。




Winny の話を前回しました。Winny を使ったことがある人なら判るでしょうが、Winny には「分割ダウンロード」の機能があります。つまり同じファイルイメージを複数のマシンが持っている場合、各サーバからはそれぞれが持っているファイルイメージの一部分だけを送ってもらい、手元で再結合して全体を再構成する機能があります。

これは CAS のように「同一の内容」を識別しているからこそできることですが、実はこれをやると、分散ファイルサーバにとって、とても効率の良い状態が発生します。

RAM が 1Gbyte しかないマシンが10台あるとしましょう。ダウンロードしたいファイルは 3Gbyte あります。このファイルを一度に4台のクライアントが欲しい、と言い出したとします。

従来の NAS などですと、4つのサーバがそれぞれのリクエストを担当します。各サーバには 1Gbyte しかメモリがありませんから、結局 HDD が 3Gbyte 読み出す速度でしか、クライアントに答えることはできません。

しかし、この分割方式ですと、10台のサーバがそれぞれ 300Mbyte を読み出し、それをキャッシュに貯め、4台のクライアントに向かって送信すればよいことになります。1台目のクライアントは HDD の速度でしか転送できませんが、残り3台は Cache に乗った状態の速度で転送できるようになる。

10台のサーバが、同期問題を抱えているのでは、このようなことはできません。むしろ、300Mbyte づつに分割したせいで、どこかのタイミングで「書き込み」リクエストが来た場合に、変更するべき部分を持っているのは誰? という疑問に答えるための準備をしつづける、というびくびくした状態で動作し続ける必要があります。CAS であれば、そのような心配は絶対ありません。



今までの話をまとめなおすとこうなります(一部、前回以前に出てきている話も含めてあります)。

  • 既存のNASサーバは、アクセス頻度を調べた上で、透過的に CAS 上に動かしたほうが良いファイルを CAS に動かすとよい。結果として高速アクセスが必要なファイルだけに、速度を稼ぐための投資を集中させることができ、システム全体のパフォーマンスが向上する。
  • ファイルシステムは、ファイルのライフサイクルを意識したファイル管理を行うようにするとよい。特にCAS化したものに対するデフラグと、重複の除去、それらを HDD などのメディアの低速域に押し込む、などという事を意識したつくりになっていると、まったく新しいアイディアを盛り込むことができる。
  • Winny は分散 CAS の一種である。というか、もっと分散 CAS としての性質を前面に押し出すと、その構造は「分散システム全体としての、ファイルシステムの IO 性能」向上のためのヒントが隠れている
  • Google の分散サーチエンジンシステムは、背後に CAS の考え方があるからこそ、あのすさまじい分散構造を作ることができる。
これら全てが、青の領域に CAS の考えを取り入れることによって発生しているわけです。


というわけで、おそらく、今後、CAS と言うものに対する「注目」はもっともっと必要になると思います。また、製品を作る際に CAS の考えを取り入れるのは重要になると思います。

そして最後に、EMC の CAS 製品にとって最大のライバルは、Winny と Google である、と言うことも判ったかと思います。

と言うわけで、(今回も)長くなりましたが、CAS に関する話、今回は以上とさせていただきます。

2007年6月2日

Content-addressable storage -5- CASの特徴

CAS は SAS や NAS に比べて何が特徴で、何がうれしいのさ??

ごもっともな質問でございます。それに答えるには、やはり SAS や NAS との比較が一番でしょう。


SAS の場合、セクター番号を指定するとセクターの中身を教えてくれます。セクター番号を指定して、データ列を指定すると、そのセクターが保持しているデータを書き換えることができます。

と言う事は、SAS にセクター番号を指定すると、何が返ってくるのかは判らない、ということです。まぁ、当たり前ですよね? SAS は「自分が格納したいデータを保存する場所」であり、その内容は日々更新できるからこそ意味がある。一度書いたら二度と変更できない HDD なんて…5年もしたら、使えるセクターがほとんど残らないじゃないですか。


NAS の場合も似ています。ファイル名を指定するとファイルの中身を教えてくれます。ファイル名を指定して、データ列を指定すると、そのファイルが保持しているデータを書き換えることができます。

このように、検索キーに対して出てくるデータの内容を変更できる事を更新可能性といいます。この更新可能性は、ごくごく当たり前の機能なんですが、システムの複製と保全 という観点からは実は非常に厄介な問題とペアになっています。この問題の名前を 同期問題 といいます。


コンピューターシステムに限らず、多くの高信頼システムは多重化というデザインによって高信頼性を確保しています。Storage ですと Raid なんかがそうですね。Raid 1 から 5 までのデザインは、すべて

データを複数の HDD で重複して持たせよう。
そうすればひとつひとつの HDD は簡単に壊れても、
Raid 全体が提供できる機能は HDD 単体よりもずっと長持ちする。
安物のHDDをたくさん使う事でコストを下げれば
トータルで見たコストも下がるに違いない

というコンセプトで成り立っています。どう重複させるか、そのやりようが違うだけです。


このコンセプト、確かに正しいんですが、一つ弱点があります。たとえば Raid 1 のミラーを考えてください。あるセクター番号 xxxx にデータを書き込むとします。

HDD単体にデータを書き込む場合は、文字通りその HDD のセクター番号 xxxx に対応するセクターにデータを書き込めば終わりです。

しかしミラーリングをしている場合、Raid が仮想的に見せているセクター番号 xxxx に対応するセクターは複数(HDD の数だけ)あるはずです。並列に書き込めるとはいえ、ミラーリングにおいては全部のセクターに書き込みが終わらない限り、セクターへの書き込みが終わったといってはならないはずです。

たとえば、ある HDD ではデータ更新が完了しており、別の HDD ではデータ更新が完了していない状態で、「データ更新が完了した側の HDD が壊れたら」 Raid 全体としてはデータ書き込みがまだ終わっていない状態のセクターしか残っていないことになってしまいます。ここで、さらに電源断のような障害が発生したら、そのデータは完全にロストしてしまうでしょう。OS などに「書き込み終わったよ」と報告しておきながら、データがなくなってしまうのは許される状態ではありません。そのような Storage は信頼できないからです。

すべての HDD が所定のセクターへの書き込みが終わるまで待つ、というこのような動作を同期といいます。同期を必要とするシステムは全て、一番遅い奴に足を引っ張られるという特徴があります。結果として、平均IO速度は通常の HDD よりもどうしても遅くなってしまいます


この問題は、SAS やNAS 一般に議論を拡張しても同じでして、データを保護する、となると2つ以上の Storage にデータを書くことになります。それぞれの Storage が『書き込み完了』と報告してくるはずですが、その報告が全てそろってからでないと、SAS として、あるいは NAS として、書き込みが完了したことにしてはいけないわけです。

天災などを回避するために、多重化した Storage のいくつかが、遠隔地に存在する場合、遠隔地との通信による遅延も発生します。一般に10m以内の計算機同士で通信するより、100km離れた場所にある計算機との通信のほうが遅くて、時間がかかるものです。

遠隔地での書き込みを待たずに処理を行う方法もあります。この場合、遠隔地にある Storage には最新のデータはおいてありません。何らかの理由で遠隔地の Storage を使う必要が出た場合、最新の更新データは一部失われることになります。どれぐらい失われるのか、というのは通信回線やシステムデザインとのご相談になりますし、それを許容できるかどうかはアプリケーションならびに計算機全体が提供するサービスの要求仕様に依存します。一般に距離の3乗に比例してコストは跳ね上がっていく、といわれます。

この同期問題を考えないで、SAS や NAS の複製を作りますと、検索するたびにあっちのマシンやこっちのマシンから別々なデータイメージが飛んできます。あるものは ver 2.0, べつのものは ver 6.2…ちゃんとバージョン管理されていてその情報も飛んでくるならいいほうです。いつのバージョンだか判らないものが飛んできた日には…もうどれを信頼すればいいのか、client からはさっぱり。

かといって、これらを信頼できるようにすると…今度はめちゃくちゃ遅いシステムになってしまう…そういうジレンマがあります。


さて、これに対して。CAS の場合はどうでしょう?

CAS の場合、ファイルの内容でファイルの本体を検索します。特にファイル内容の完全一致に対応するのが絶対条件。となりますと、面白い性質が出てきます。

CAS にはファイルを作る・消すという操作はありえても、更新可能性は無いんですよ。ファイルの内容を変更すると、それは別のファイルにせざるを得ない。なぜなら「変更前」のファイルを検索するために使える検索キーと、「変更後」のファイルを検索するために使える検索キーは違うから。検索キーが違っちゃうって事は、前の検索キーで更新後のファイルは探せないって事で…。

これを、CAS は WORM (Write Once Read Many) の性質がある、と表現します。
別の言い方をしましょう。 CAS に乗っているファイルは、全て ver 1.0 しか存在しない んです。


この性質は多重化された Storage の同期問題に画期的な解決策をもたらします。

話を簡単にするために、一番最初は手元の CAS Storage にしかコピーをおかないことを考えましょう。で、CAS システムは自動的に、かつダラダラと暇なときに、こいつのコピーをレプリカサーバーにコピーしていくとします。

あるとき、このファイルに対する検索をかけたとします。まぁ、もちろん手元の Storage が答えてくれてもいいんですが、たまたまこいつが手一杯だったとします。で、遠隔地のサーバーが答えた。「あるよ」って。

NAS や SAS の場合、
「それは本当に最新のもんですかぃ?」
と疑わなくちゃいけないんですが、CAS の場合この心配をしなくていい。

- ファイルの内容が変更できないから -

あるといわれたら、ある。ないといわれたら、ない。

したがって、CASの場合
  • 取り合えず一番手近な Storage に書き込んでおく(この段階ではまだ信頼性は低い。データを失う可能性がある)。
  • で、徐々にコピーを別の CAS にも分散させていく(時間が経つに従って信頼性があがっていく)
などという、こジャレたシステムの作り方ができる。


もし、ファイル共有ソフト…えー Bit Torrelant でも Winny でもいいんですが、使ったことが一度でもある人なら判るでしょう。この挙動、ファイル共有ソフトのそれと同じだ、という事がわかると思います。

これらのソフトにおいて、ファイルの「ファイル名」ってのはあまり意味を持ちません。同じファイル名の、ファイルサイズだの ID だのが違う代物がいっぱい出回っています。

でも、同じ ID のものは1種類しかない。最初誰かがこのファイルを ファイル共有のネットワークに登録したときに、割り振った ID があって、多分それはファイルのバイト列からhash値を作ってそれをベースに作っている。

ファイル共有ソフトはこのファイルのレプリカを周囲の PC に作っていく。自動的に、だらだらと。

で、どこかのPCがそのコピーが欲しい、と言ったら誰が持っているのか教えてくれるけれど、IDが中身から作られているから、IDが一致していれば中身は絶対一致していると考えていい。だから、いちいち中央サーバーなんか作らなくても P2P でファイルをダウンロードするので間に合う。

最初のうちは、コピーは1箇所ぐらいにしかないからそのPCが止まっている間は欲しいデータは入手できない。でも徐々にコピーが広まるに従って Servicability が向上して、いつでも手に入るようになる。また手近なマシンから手に入るようになるので、徐々にダウンロード速度もあがっていく。


CAS ってのは、このようなファイル共有ソフトのP2P通信の部分を取り除いたようなものだ、と表現することができます。


で、その CAS がファイルの一生とどう関わるのか? それは、刮目して待て、次号!!
#誰が少年探偵団だ。

2007年5月29日

Content-addressable storage -4- CASの定義

枕を話し始めたら興が乗ってしまって、いつまでも本ネタに入れなくなった落語家のような状態ではあるが、ようやっと本題だ。というわけで CAS

CAS の定義はその名前そのもの「Content」で「addressable」な「Storage」のことだ。
……ぜんぜんわからねぇ…… orz

というわけで、比較のために、もう2つ単語を定義する。SASとNASだ。

SAS: Sector Addressable Storage
NAS: Name Addressable Storage

先に断っておくと、SAS も NAS もここで定義しているようなものは、この場限りの定義だから。EMC用語でもないし、IBM用語にも無い。世の中一般にもこんな風には言わない。なので、SASとかNASをこれから定義する意味で使って、意図が通じなくても文句は言わないように。


あ、そうか。用語の定義から。

Storage:
これは判ると思っていいよね? HDDとかフラッシュROMとか…とにかく、「外部からの電力供給を断っても、(しばらくの間)データを保持してくれる外部デバイス」のこと。外部というからには内部があるわけで、それはメモリとかCPUとかの事を言う。
深く突っ込まないが、この辺も歴史的な背景があってこういう名前になっているものなので、あまりこだわらないように。

Addressable:
うーん。アドレス指定できるとかそういう意味になるのだが、この場合は「検索できる」とか「見つけられる」という風に捕らえるとよいかと。つまり
「この条件のものがほしいんですが?」
と言うと
「ほぃ、これね?」
と出してくれるもの。できれば O(1) …つまり常に一定時間で。ただし、最近はO(1)はだんだん難しくなっているらしくて、O(log n)とかでも許しちゃうけど。




で、まずはSAS。これは「セクターを指定すると、そのセクターに存在するデータを返してくれる」Storage。HDDとかがそうだ、といえば判りやすかろう。

昔は シリンダーだの、プラッターだのを指定した上での「このトラック上の何番目のセクター」とか言っていたが、最近はもう ATA だと48bit, SCSI だと 64bit のアドレス空間を目いっぱい使って、
「全体を通じて xxxx 番目のセクターを頂戴」
と言うと、1セクター分のデータをくれる。


実は、あなたの HDD の中にあるセクター数は、あなたが使えるセクター数よりも多い。あるセクターが調子が悪くなった場合、HDDは勝手に代替セクターというものにデータを移し変えてくれたりするのだが、この「代替セクター」は全体の 1/4 も用意してあったりする。勝手に移し変えられるのは、ユーザーから見ると、前に使っていたセクターも代替セクターも同じ「xxxx番目のセクター」でアクセスできるからだ。

だから、「xxxx番目のセクター」と言っても、使いはじめと、5年ぐらいたってからでは、物理的なセクターの位置は違っている可能性がある。と言う事は、実は「xxxx番目のセクター」とあなたが言ったとき、HDDは内部で
「はて、こいつが言う xxxx 番目のセクターって本当はどこ?」
という検索を行っているのだ。逆に言えば、ちゃんと検索して正しい答えを返してくれさえすれば、もう内部構造なんてどうなっていても良い。垂直磁気だろうが、小人さんがいようがかまわないのだ。そう。xxxx というセクター番号は仮想的な番号なんである。

SANはこの「セクター番号なんて仮想的なものだ」に「物理的なHDDだって仮想的ジャン」という考えをつないで、さらに「ネットワークでつなげば仮想かどうかはばれないよね」という考えにいたった SAS の最終進化系だ、と言うこともできる。



NAS: Name Addressable Storage。そう。名前を指定すると内容を教えてくれる Storage。

ようするに Network Attached Storage、通常言うところの NAS と同じ。ファイル名というか、パス名を与えると、
「あぁ、そのファイルはこれでございますな」
と内容を教えてくれる(あるいは、「それはあなた様は触ってはいけないものでございます」と文句を言われるかもしれないが)。別の言い方をすると、パス名をキーにファイル実体を検索してくれるわけだ。

ファイルシステムって全体的にそうだよね。ただ、「物理的な箱」という感じで言うと普通に言う NAS なんかがこれにあたる。もちろん、プロトコルはいっぱいあって NFSv2,v3,v4, SMB, CIFS なんかのほかに AFS, DFS, などなど。NFSv2,v3 や SMB, CIFS は NAS としては結構初歩的な機能しかなかったりするので、これがはやる理由が良く判らない(SIer が不勉強であるっていう場合以外は)。

まぁ、とにかく。これは多分一番判りやすいと思う。



で、これで考えると CAS ってのは
「すみません。『hogehoge. Ahage,ufuu … Heppero-pon』という内容のファイルがほしいんですが」
と言うと
「あぁ、ありますよ。これですね。中身は『hogehoge. Ahage,ufuu … Heppero-pon』です」
と言ってくるという…そういう Storage。ファイルの中身をキーにファイルを検索するわけだ。

え? ファイルを指定するのに中身を指定しなくちゃいけないなんて、間抜けだ?! まずもって、その感想は正しい。でも、こういう場合を考えてごらん。

a) 「すみません。ファイルの中身のハッシュ値が 58200g8d7sd.....Z なファイルがほしいんですが」
「あぁ、ありますよ。中身は『hogehoge. Ahage,ufuu … Heppero-pon』です」

b)「すみません。ファイルの中に Ahage という文字列があるファイルがほしいんですが」
「あぁ、ありますよ。中身は『hogehoge. Ahage,ufuu … Heppero-pon』です」

c) 「すみません。ファイルの中身が MS-Word のフォーマットになっているファイルがほしいんですが」
「えーーー、それは無いですね、今は」

c は unix でいう find コマンドと、file コマンドの組み合わせみたいな感じだよね。

b は自分のマシンだけだと grep とか、google desktop とかで、インターネット全体になると検索エンジンそのものだ。

a … a の例ねぇ。ファイルを指定するのに中身のハッシュ値を使う、有名なものとなると… Winny!! そう、Winny の ID ってのはようするにそういうものですな。こう考えると、Winny ってのも CAS の一種です。


このように「ファイルの中身」から「ファイル」を指定するものを一般に CAS と言います。



で、ここからが問題。CAS の何がそんなにいいのさ? …これが次回のテーマになります。
ヒントは Winny。

2007年5月28日

Content-addressable storage -3- 続々・ファイルの一生

というわけで、前回の続き。ILM(Information Lifecycle Management: ジョージ・ルーカスの有名なCGエフェクト集団ではない)ってのが提唱しているファイルのライフサイクルの話。こっちのほうが正しい、と言う話。ちなみに、私自身は ILM の考えは正しいと思うが、ILMという名前はいただけないと思う。FLMだろ、これ。

さて、ILMではファイルの一生を3つに区分けする。

1つ目は赤の領域で、write 優勢。これは前回と同じなので詳しく説明しない。

もんだいは2つ目と3つ目、緑と青の領域だ。これはどちらも read 優勢であることに変わりは無い。
違うのは、ファイルに対する参照頻度。緑は参照頻度が高いが、青は参照頻度が低い。

緑はいっぱい参照されている。ファイルはいっぱい読み出される。もしかするとコピーもいっぱい取られているかもしれない。そのコピーはコピー先で変更されているかもしれない。とにかく読み込み専用ではあっても活発なのだ。

これに対して青は、参照もされない。まったくされないわけではないが、そんなに頻度は高くない。こう…引退して、縁側で渋茶すすっている爺さんって感じ?取り合えず青で表現しているけど気分的には、ロマンスグレー。


このようにファイルの一生を分割すると、図にもう描いてあるように、赤と緑の領域は高速なIOが可能な高性能HDDや、HDDの中でも外周部と呼ばれる読み込みが早い領域に置くのが正しく、青の奴はゆっくりな低性能HDDや、同じHDDの中でも内周部で十分、必要ならばデータ圧縮をかけてさらに小さくしてやれ、という態度でかまわないことが判る。計算機のリソースは高性能なものと低性能なものではやはり値段に差があるのだから、高いものはよくアクセスするファイルに割り当て、安いものはめったにアクセスしないものに割り当てるのが正しい。

「アクセス頻度」を念頭に置くことで平均的なビットの保存単価を下げる事に頭が行っていれば。たとえトップスピードが低くてもいくらでも市場はあったのに orz これは明らかに私が馬鹿だった証拠だ。


ちなみに、このような分類だと、赤い所はやはり NetApp が強い。
緑の所はデフラグ機能がしっかりしている NAS 製品であれば、きっと大抵のものが良いスコアを出す。
そして青の所は、値段とメンテナンサビリティのバランスが取れた製品を使うことができるはずだ。
あとは、ファイルのライフサイクルにあわせて、
赤のマシン緑のマシン青のマシン
と、ファイルをユーザーから見て透過的になるように移動する機能があればよい。

そう、IBMの時に思いつくべきは「NetApp以上の性能を出せるマシンを作る」事ではなく、NetAppを赤の領域用管理システムとして配下に置く システムだったのだ。

...........................

まぁ、過去に対する反省はこれぐらいにするとして。問題は青の領域。

なにぶん、私も思いつかなかったのだが、他の人も大抵思いついていなかったらしく、この青の領域で何ができるのか、実はあまり製品研究は始まったばかり。そして、その過程でいくつもの
「昔聞いたときは何じゃそりゃだった代物」
が脚光を浴び始めている。

CAS もその一つだ。

というわけで、第4回目にして始めて! 本題に入れるようになった。

2007年5月27日

Content-addressable storage -2- 続・ファイルの一生

さて、私が考えたのは次のようなものだ。ファイルの一生を大きく2つに分ける。1つは書き込みが結構存在する時代、そしてもう一つは書き込みがほとんど無い時代だ。


赤の領域は書き込み頻度が極めて高い。ここで要求されるのは「書き込み速度の速さ」だ。しかし、これは言うほど簡単ではない。特に NAS のように複数のクライアントから同時に書き込みや読み込み要求が飛んでくる場合は、きわめて難しい。

HDDが、書き込み要求に高速に対応するには、連続した領域に、書けといわれたデータを到着した順に書くのが最も効率が良くなる。というのは、HDDはいったんヘッドの位置を決めてしまえば、そのトラックに対する読み書きの速度は完全に一定になるからだ。つまり、ヘッドがまったく動かない状態が最も高速な書き込み速度で、ヘッドシーク時間が無駄時間になる。書き込み要求を高速にこなす、とはつまり書き込みに際してヘッドシーク時間の割合を減らす、ということに他ならない。と言う事は「あるトラックにヘッドを移動したら最後、トラック一周が完了するまでヘッドを動かさなくて良い」場合が最高速度になる。HDDの「ヘッドシークなしの」書き込み速度は4Gbit/sec 近い速度を誇れるので、本当にそれだけの書き込み要求が1つのファイルについて、シーケンシャルに、存在できるならば最高だ。

しかし実際は、NASであれ、通常のアプリケーションであれ、このような大量のデータを、シーケンシャルに、書き込むよう要求することは、まれだ。実際には複数のクライアントやアプリケーションが、それぞれはちまちまとした分量の書き込みを要求することになる。必然的にファイルシステムに到着するデータは異なるファイルの異なる部位が到着することになる。これを「連続した書き込み」にするには、到着した順にHDDに書いて、なおかつそれを意味のあるものとできる必要がある。


このような性質を持つファイルシステムは存在する。Log Structured File System と言われるものがそうだ。ただし、これは定期的な Garbage Collection を必要とする。この弱点を補ったのが NetApp が彼らの Filer といわれる製品シリーズに利用している WAFL で、バッテリーバックアップの RAM Disk を中間バッファーとして利用し、これが抑えられる範疇でデフラグを施した上で、RAID に一気に書き込む、という事をやっている。


赤の領域の間は、あまり読み込み速度のことは気にしなくて良い。なぜなら、ここで何か読み込み速度のための改善を行っても、次の瞬間にはまた書き込みが発生して、せっかくの改善が水泡に帰すからだ。




緑の領域は書き込みがほとんど無い。つまり、書き込み性能はIO性能にほとんど影響を与えない。この場合、ファイルはデフラグされ、連続した領域に1つのファイル情報が集まっていることが望ましい。というのは、昨今のOSは十分なメモリ容量を背景に、大量の先行読み込みを行うからだ。

HDDのヘッドシークオーバーヘッドという観点からすれば、10kbyteを読むためにあるトラックにヘッドシークを行うのも、1Mbyteを読むためにあるトラックにヘッドシークを行うのもコストは変わらない。であれば、ファイルをなるべくヘッドシーク量が最小ですべて読める領域に配置し、OSの先行読み込み機構に期待すれば、無駄なヘッドシーク量は最小で済み、その分IO性能が上がって見える計算になる。



実はこのような状態には WAFL は非常に不利だ。WAFLは「RAM Disk 1block分」の範囲内ではデフラグを行う能力があるのだが、block 間デフラグをデフォルトでする能力は無い。非常に多くのクライアントがバラバラに、それぞれ複数のファイルの書き込み要求をしてしまうと、1つのファイルの情報が複数の block 間にまたがってしまう。赤の領域では無敵を誇る RAM Disk + バースト書き込み機構は、緑の領域では逆に不利になるわけだ。

で、IBMにいる間に私が提案したのは、
HDD自身にある程度のファイルシステムとしての機能を持たせる
というものだ。具体的には uFS などでいう、inode 管理はHDDが行う。

HDDは、赤の領域に属するファイルに関するものの場合、まるで Log Structured File System のようにプラッターに書き込む。つまり、書き込み順序は到着順序どおりとし、同じファイルのデータがなるべく集中するように、などということは考えない。

逆に緑の領域に属するファイルの場合は、なるべく同じファイルのデータが1箇所に集まるようにレイアウトを決める。

さらに、赤から緑に属性が変化するタイミングで、ディスクの異なる場所へと内容をコピーする。この際にデフラグを行う。また、IOが少なく、暇なタイミングを狙って、赤の領域、緑の領域とも、再デフラグを行う。特に赤の領域は、本当に使っている部分と使っていない部分がまだら模様になるはずなので、これを集約して使える連続領域を確保するのだ。計算機システムにおいてIOが少ないタイミングは2種類ある。1つはメイン計算機が「計算」に謀殺されているとき。もう一つは本当に暇なとき。従来は「本当に暇なとき」にしかデフラグできなかったが、HDDがファイルシステムとしての役割を果たし、ディスク上のレイアウトを決定できるように書き換えれば、通電しておきさえすれば勝手にデフラグし続けることができる。

おそらく、このような HDD 自身に対する大改造を行わない限り、NetApp Filer 以上の性能を出すシステムを開発するのはきわめて困難だろう、というのが私の結論だった。



さて、この結論から5年後。私はEMCに入って、自分が馬鹿だったことに気がつかされる。

EMCが提唱する ILM(Information Lifecycle Management) によるならば、ファイルの一生は次のように分類する。そして、私が考える限り、私が考えた赤緑の2フェーズよりも、この3フェーズモデルのほうが正しい。
というわけで、次回は、この3フェーズモデルについて説明しよう。

…おかしいな、CASに行く前の「前フリ」がこんなに長くなるとは思わなかったぞ?

2007年5月20日

Content-addressable storage -1- ファイルの一生

日本語版には存在しないが、英語版のWikiPedia の CAS の項には存在する。Content Addressable Storage、略してCAS。EMCの社員研修の一環として教わったことのうち、一般知識に属する項目と、その昔出したアイディア(ただし特許等を出願済なので公知)をちょっと並べてみよう。

昔々、IBMの基礎研究所にいた頃、Linuxを使ったあるプロジェクトが発生した。そのプロジェクト自体は巨万の金額をどぶに投げ捨て、人の話を聞かないリーダーによって大崩壊のうちに終わり、相応の数の首が飛び、それ以上に理不尽な数の人間が不当に低い評価を受け、結果として甚大な人材流出を引き起こしたのだが…まぁ、そのあたりはいいとしよう。


実はこのプロジェクトが終わった直後に、反省会というかなんと言うか、「ようやっと」本来プロジェクトを開始する前に調査するべき事を調べる時間ができたので、
  1. そのプロジェクトがターゲットとしていて、 5% の性能も出せなかったライバル製品はどういうつくりになっていたのか、とか
  2. そもそもこの問題の本質はどこにあったのか、とか
ま、そういう事を調べることになったわけだ。で、出てきた結論:
  1. こんなん、勝てるわけねーべ(理由は後で述べる)
  2. 問題の本質はファイルシステムへ向かってのIOアクセスパターンにあり
1 はまぁ、いいとしよう。


問題は2だ。ファイルシステムに対する要求が、ファイルの一生の間に変わっていく事がわかった。これを単一のファイルシステム、単一のサーバーで解決しようと言う点に問題があったのだ。
# もちろん、これは2002年の段階で報告書を出している。

あるファイルの一生と言うものを考えてみよう。どんなファイルでもいいのだが、ごく普通の…そうだな、大学か何かのレポートのテキストファイルを考えてみてほしい。

一番最初。ファイルは作られる。
まったく何もない所に、ファイル名が指定され、デフォルトの属性が与えられる。そして、最初の何バイトかが書き込まれる。そう。ファイルの一生は「書き込み」からはじまる。

しばらくの間、1回読み込むたびに数回の書き込みが行われる。ファイルエディターは一度読み込んだファイルを覚えておいて、セーブ要求があるたびにそれを書き出す。従って、最初のうち、IOの頻度は高く、かつ write/read 比率は 1.0 を超える。

徐々にファイルが完成に近づくに従って、write/read 比率は 1.0 に近づく。このファイルの内容に対する推敲が始まると、原著者だけでなく、推敲のために複数の人間が読み始めるからだ。書き込み頻度は徐々に低くなり、読み込み頻度が上がる。IO頻度全体はこの頃がピークになる。

ファイルがほとんど完成に近づくと、write/read 比率はどんどん 1.0 以下に落ちていく。同時に、読み込み頻度はさらに増えていく。完成版を大勢の人が参照し始めるからだ。

write/read 比率が 1.0 を大幅に下回るようになった頃…そう。0.01ぐらいを下回る頃、IO全体の量が急速に減り始める。情報は他の人達にもいきわたり、このファイルへの参照頻度自体が下がり始めるのだ。

やがて、write の頻度は限りなく0に近づき、read の頻度もかなり少なくなる。このファイルは利用されなくなりつつある。しかし、たまに。ごくまれに、まだ参照されることがある。ほとんど引退まじかといった感じ。

最後に、このファイルは誰からも参照されなくなる。永久にHDDの肥やしになるか、どこかでHDDが飛んでアクセスできなくなるか、「邪魔だっ」の一言と共に消されてしまうか、いずれになるのかはともかく、もう誰もreadもwriteもしなくなる…。ファイルの終焉である。

以上のお話を図にするとこんな感じ。
横軸が時間軸、縦軸がIO頻度。最初は write がドバーッときて、後追いで read がグググーッときて、write がシューンと落ちた後も read はずるずるずるーーーと引きずる…ただ全体的に徐々に落ちていくーー。頭の悪い表現の仕方をすると、こんな感じになる。


当時の解析では、この「あるファイルに対するIOパターン」は大雑把に2種類に分けていた。write/read 比率が 1.0 を超えている時期と、1.0を下回っている時期だ。

CASの世界では、このファイルに対するIOパターン、大雑把に3種類に分割している。なおかつそれぞれが別の性質を持っている、としている。write/read 比率が 1.0 を下回っている時期をさらに2つに分割するわけだ。それぞれがどのような性質を持っているのか…それを次回のテーマにしよう。

2007年5月19日

Amazon であまり本を買わない理由

私のページは、あちこちに Amazon の広告が張ってある。しかも、私は山のように本を読むし、本を買う。なのに、実はその大半は Amazon では購入していない。

実は、私は金券ショップなどで図書券や図書カードを買って、それで本を買っている。3%-5%程度のものだが、これであれば和書も大抵割安で買える。日本では再販制度があるため、Amazon と言えども本の価格自体を下げることはできない。だからといって Amazon ポイントを山のように稼げるわけでもなく(だって、先月の Amazon の収入は 42点だぜ? これで 3% 割引になるって事は購入総額が 1400円以内でなくてはいけない…)。

洋書の購入にはAmazonを良く使う。洋書は再販制度の縛りが無いので割引セールがあるし、普通の書店で入手はほとんど不可能。専門店では定価の上に1ドル200円近い金額を請求される、というおまけがつくからだ。


一応、本の紹介のページには Amazon の個別商品へのリンク等がおいてあるが、これは利便性のため。どういう本なのか本の表紙を表示したかったのと、他の人はどういう感想を持っているのかなどの情報へのアクセスをよくするために過ぎない。


まぁ、そういうスタンスを貫いているから、Amazonでの売り上げが全然伸びないんですけどね (^^;)。

Be Negative!

ビジネス書などを見ていると「頭のいい人は、失敗の原因ばかり探しているからダメだ」とか「いいからとりあえずやってみろ」とか書いてある。

冗談ではない

私は、何かを行うに当たって、事前に失敗要因を挙げられない人を信頼しない。なぜならそういう人は、
  1. 何も考えていない/予測能力が無い
  2. 嘘をついている/詐欺にはめようとしている
のどちらかに決まっているからだ。2は論外として、予測能力はどんなジャンルにおいても成功するための絶対条件じゃないか。これを否定するような人間は偶然成功した人間か、詐欺師ぐらいなものだ。

簡単な例を考えよう。

例えば大学受験。あなたは慶應義塾大学を受けることにした。


この時、予測能力が無い人は、同じ受験生の学力など考えることも無く、特に準備もせずに受験する。これで合格するならあなたはほとんど天才で、大学に通う必要自体無いかもしれない(学士号が欲しい、と言うのはあるかもしれないので受けるなとは言わないが)。

予測能力のある人は「周りの人間のほうが学力が高いから受験しても失敗する」と予測する。この予測はこの段階では「仮説」なので、これを検討するために過去の合格者・不合格者の学力レベルや自分の現在の学力レベルを検討する。もし不足分があったら、それを補うための方策を考えるはずだ。


予測能力の無い人は、筆記用具が必要になる、と言うこと自体忘れるかもしれない。
予測能力のある人は、筆記用具が必要だから忘れないようにする方策を立てる。またどのような筆記用具が必要になるか検討する。


このように「失敗要因」を挙げ、それに対処する方法を考える事はとても重要だ。エンジニアに必須の能力であり、エンジニアが徹底して鍛えられなくてはいけない能力と言っても良い。この時に対処方法を思いつかず、あるいは思いついても高コストでとても払えない、と思って手を出さないというのは、決して悪いことではない。

むしろ、深く考えずに「とりあえずやる」事の方がよほど迷惑だ。できもしないのに「できます」と言い募り、任せてみたら「できませんでした、てへ」で済まされては、周りが迷惑する。しかも、十分な方策を練っても失敗したならやむをえないと思うが、対策なしでは…。


このように失敗要因を考慮する能力はエンジニアに絶対必要な能力だ。この能力が高い人間は、「対策を立てる」段階で竦んでしまう場合がある。というのも「対策がうまくいかない理由」も思いついてしまうため、失敗要因の連鎖が頭の中で構成されてしまい、絶対失敗するかのように思われるからだ。

しかし、この恐怖は教育と訓練で消すことができる。一定確率以下の失敗要因は無視して構わないはずだ。一連の失敗連鎖の中には、「メタ失敗要因」とも言うべきものが見つかるはずで、時にはそちらを先に解決することで一気に実現可能性が高まるかもしれない。失敗要因が大量に出てくる理由のひとつに、システムが複雑すぎるから、という事がありえる。もっと単純にすると、逆に robustness があがるかもしれない。いきなり大掛かりに実地をすると被害が甚大になる場合は、小規模なプレテストを実行することで解決策が見出せるかもしれない。

こうして教育された、「失敗要因ばかり考えてくよくよする人」が作り上げるものは、製品であれ、システムであれ、きわめて高品質で、よく考えられた、堅牢なものになる。どこぞのOSのように毎月のように update してもなお、緊急 update が発生するとか、カタログ上のスペックは優れているが、毎日のようにどこかが壊れているとか、そういうものにはならない。


というわけで、もしあなたが成功したいなら、私は次の事を勧める。
Be Negative!!