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!!

2007年5月6日

マークシート用鉛筆-6- 代替物

そんな鉛筆を器用に削るなんてできない

という意見があるかと思います。事の真偽はともかく、確かに

今頃こんなもの発見してもナイフで鉛筆削る練習している暇なんかあるか


というのはあるかと。

マークシートの一大利用タイミングである神奈川方式と言われるアチーブメントテストは廃止されたらしいので、それはめでたいのだが、まだセンター試験とか、企業の採用試験とか、頭痛の種はいくらでもある。そして、この手の「最後の手段」に関する調査は、最後の最後までやらないものだからね。

というわけで、鉛筆を削る代わりになるような何かは無いのか? というのが今回のテーマ。
いくつか手がございます。えぇ、奥様、ございますとも。
ただし、お値段が少々張りますことよ (^o^)。


1) 全芯鉛筆
奥様、サクラ クーピーペンシル をご存知でしょうか? えぇ、あの全部が芯になっている色鉛筆でございます。あのような鉛筆があれば、太い目に削っておけば、今回の鉛筆と同じように使えるとは思われませんか? 単純に太く、太く削るだけであれば、通常の鉛筆削りでもできるはず…。

ございますとも。少なくとも Faber Castell の PITT GRAPHITE 2900 の HB というものがございます。伊東屋や紀伊国屋、東急ハンズなどであれば入手可能か、少なくとも数週間のうちに輸入してくださいますでしょう。また、Faber Castell でなくてもいくつかのメーカーがこのような鉛筆を作っていたかと思います。到底、鉛筆の値段とは思えない単価ではございますが、それでも10本買ってもせいぜい2000円程度でございます。

なお、サクラクーピーペンシル 自身をマークシートにお使いになるのはお勧めできません。基本的にマークシートは反射型といいまして、特定の方向から光を当てて、反射光を別の角度から読んで濃淡を調べるのが基本機構ですが、色鉛筆は全般的に油分の含有率が高く、角度と塗り方によってはきれいに反射してしまって、読み取らなくなる危険性があるのでございます。あくまでも「通常の鉛筆と同じ芯で、全芯鉛筆」をお使いになるのがよろしいかと思われます。


2) 極太シャープペンシル
製図用シャープペンシルというものがございます。製図用に所定の太さの線が引けるよう、なおかつ一般筆記用と異なり定規等を当てるための芯繰り出し部が長い目に作られているシャープペンシルでございます。このようなものの中には、0.3mm, 0.5mm, 0.7mm, 0.9mm と 0.2mm 刻みで多種ございます。
ステッドラー社はそのような製図用品を作らせたら1,2を争う名門でございますが、そこの
ステッドラー・シルバーシリーズ シャープペンシル
というものに 2.0mm という芯の太さを誇るシャープペンシルがございます。これであれば、お望みの効果が得られるに違いありません。 2.0mm と申しますのはほとんど鉛筆の芯と同じ太さでございますから…。
ステッドラー以外に 伊東屋、ロットリング などのブランドもあるようでございますね。

ステッドラーのこのシャープペンシル、画材・製図用品店でもなかなか品薄なようでございますが、少なくとも たまプラーザ東急SC の 5F 文房具売り場には数本残っているのをこの目で確かめてございます。
価格も本体が 1050円、芯がHBなどで 6本 210円ほど。

ただ、先端が大きくなっているため、相対的に衝撃に弱い、と言う弱点がございます。取り扱いは丁寧にお願いいたします。なにしろ、壊れてしまった場合の替えは、通常の鉛筆やシャープペンシルほど容易ではございませぬゆえ…



マークシート専用鉛筆・消しゴムセットなどというものも売っているらしいのですが、それは普通の鉛筆と普通の消しゴムじゃん、それじゃつまらない…と言うわけで、ちょっと効率の良いやり方をまとめてみました。

少なくとも私自身が使った記憶があるので、今から 24-5年前には存在するノウハウです。もしかすると、一部のマークシート成績上位者の中にはこの業を使って、最後の 5点、10点を稼ぎ出している人もいるのやもしれません。

マークシート用鉛筆-5- 効能

さて、この鉛筆の効能について述べよう。そのためにはまず、マークシートのおさらいを。とはいえ、マークシート読み込み機を作った事は無いので、多少の間違いは許してください。


大抵の受験用マークシートと言うのは、左の図のように楕円形の中に A とか B とかの選択肢(1,2,3 かもしれないし、あいうかもしれないが)が書いてあって、正しい答えのものを鉛筆で塗りつぶせ、と言うことになっている。

で、これはどの欄がマークされているのか、機械で読み取って、その結果を元に採点するわけだが、いくらなんでもマークシート用紙を1つ1つ、デスクトップスキャナーで読み込むわけではない。どちらかと言うと PFU の ScanSnap のようにシートフィーダーを経由して、コピー機のような感じでゴリゴリと読んでいくわけだ。


すると、いくら機械精度が高くても、左の図のように、楕円形の中だけを検出し、その外はまったく検出しない、なんて判定システムは作れない。いや、作れなくは無いだろうけれど、ものすごくゆっくりとしか読み取れないだろう。





一応、周辺部には位置決めのためのしるしがたくさんついているけれども、現実問題としては、左の図のように楕円形を含むなんらかの形状があって、その中の一部が一定量以上塗られていればOKという判定ルールになっているはずだ。ツーかそれ以上複雑なことを判定している暇は無いはずだ。


一方で、大抵のマークシート型問題は3択や4択になっており、2つの印にマークがついているだけでもNGであることがほとんど。

つまり例えば左の図のようにAの楕円からはみ出していても、Aを囲む判定用の箱からはみ出していなければOK だが、





このようにAの楕円以外塗られていなくても、Bの判定用の箱まで塗られていると、読み取り精度の関係で、AとBの両方を塗ったことにされてしまう危険性がある、と言うことだ。

「楕円の中だけを塗れ」
「はみ出さないようにしろ」
とくどいほどいわれる理由はここにあるわけだね。


さて、このような領域に対して、シャープペンシル(0.5mm芯)で楕円の領域を塗ろうとすると、どうなるだろう?私の場合、こうなります。

1. まず、楕円の外周に沿って一周楕円を描きます。これが基本の外枠。


で、一周した後、最も動かしやすい方向に左右させながら(なので、微妙に右上と左下の間を往復する感じになるんですが)、この楕円形の中を塗りつぶしていく。


このやり方、大雑把に5-6秒かかって1つの楕円を塗りつぶすことになります。この塗り方は、少なくとも高校時代は周りに比べて結構良いタイムを出していた気がします。と言うことは、これを読んでいる皆さんも大抵、楕円1つに5-10秒ぐらいかけているのではないでしょうか?

このやり方は弱点がいくつかあります。

弱点1: 正確に塗りすぎ。
先ほども言ったように、正確に楕円形に塗る必要は無いのですが、なにぶんペン先が細かいため、「正確に塗れてしまう」のです。もう少しラフに塗って、その代わりスピードが出せるのならば、そのほうがよいはずです。

弱点2: 塗る面積が、ペン先の大きさに対して広すぎ。
0.5mmのシャープペンシルは、最も広く使われているものですが、この楕円形は大抵横幅が 3mm以上、縦方向も 5mm 以上あります。楕円形ですから 6*10=60倍と言うわけではないでしょうが、ペン先のおおよそ40倍もの面積を塗りつぶすのは、明らかに戦略として間違っています。


というわけで、これが、今回のマークシート用鉛筆だとどうなるか。もちろん、塗り方にもよるのでしょうが、私はこうやっている、という例を。

1. まず最も広くぬれるように鉛筆を持った状態で左図のように楕円の左半分に沿って、塗ります。





2. で今度は右側に沿って塗ります。








3. 最後に真ん中を塗りますが、芯の太さ(正確には、間違って削っちゃった量)によって、一発ですむ場合もあれば、2度縦塗りをする必要がある場合もあります。




このやりかた、私の場合ですと、芯の状態にもよりますが、 2.2秒から 3.0秒ぐらいでマークし終わります。大雑把に 1/2 の時間、2-3秒のタイムが短縮できるわけです。


「2秒なんてたいした時間じゃないな」
などと言うなかれ。

TOEICのリスニングコースですと、この2秒の間に次の問題の設問部をちょっと眺めることができます。これをやるかどうかで、設問文を読み上げている際に、何を覚えて何を忘れても構わないのか、その心構えができます。

同じくリーディングコースですと、全100問(ちなみにリスニングも100問)あるわけですが、合計で200秒= 3分も時間差ができます。リーディングコースは 75分しかありません。1問0.75分 = 45秒で解かなくてはいけないはずなのですから、3分差があると4問余計に解けることになります。


いや、仮に解けなかったとしても、「ラスト3分はあきらめて全部Aを塗る」暇ができるわけです。所詮マークシートは、四択であればマークしているだけで確率 1/4 で当たります。もちろん、TOEICのスコアはこのことを念頭において割り振られていますが、逆に言うとここで何もマークしないとひどい点数になるわけです。

同じことは、マークシートを使っているあらゆるテストについて言えます。「何もまったく手が出せなくて、時間があまりまくっている」場合はともかくとして、「あともう少し時間があれば…」という場合(実はテストと言うのはそういうケースが大多数になるようにレベルを設定するものなのですが)、1個当たり数秒しかメリットが無かったとしても、積算した時間は相応に意味のある時間になるものなんです。

えぇ、おかげで、今回の TOEIC も、安心して「勘を働かせる」時間が稼げました。
# あっ…

2007年5月5日

マークシート用鉛筆-4- 作り方の弐

続き。

今度は左の図のように削っていく。芯を削らずに木の部分を削って芯を露呈させていくのだ。













ただし、この例は削りすぎ。

90度回した写真がこれだが、芯が削れてしまっている。

本当はここまでは削ってはいけない。

芯の周りにある木の部分を剥がして、可能な限り芯をそのままの形で露呈させたいのだ。そのためには木の部分をまず荒っぽく削りだしておく必要がある。

とはいえ、まぁ、よくある失敗ではある。







ちなみに、斜めから見た図がこの2つ。





ここまできたら、後は具体的な説明がしづらくなる。

ここからは芯を露呈させるために芯にまとわりついている木の部分をこそげ落としていくだけなのだが、その過程で再度芯も含めて削りだしたほうが楽な場合もある。

その辺は実は「適宜やってくれ」としか言いようが無い。





で、露呈させるとこうなる。
これは「人差し指で押さえる面」側からの映像だ。

よく見ると芯が少し削れてしまっているのがわかるが、これが少なければ少ないほど良い。



さて、ここまできたら、あとは「仕上げ」。

と言っても何をするでもない。この鉛筆を使って何度か「太い線」を引っ張るだけだ。その過程で芯の先端のでこぼこが適度に削れる。



ある程度使って、芯が短くなってきたら、ここまでの工程を繰り返せばよい。基本的に周囲の木の部分を削ろうとするのが主眼で、芯を削る量は最小限にとどめるよう、注意すればよい。