okkyの銀河制圧奇譚

sched_clock() overflow after 208.5 days in Linux Kernel

2011-12-29T22:52:00.007+09:00

えーっと、久しぶりに Linux Kernel にダメダメなバグが発見されて、よりにもよってうちの製品も影響を受けたので、ここに詳細を書くことにした。

つーか。新しい Kernel を使うなら皆で使おうよ。なんだよその「1つだけ」影響を受けて残りは「影響も受けないぐらい古い」ってのは…

概要
大雑把に 208.5日連続運転した Linux Kernel が突如として reboot する。

実機でなおかつ Time ~~Slice~~ Stamp Counter を内包している必要があるので、Pentium4以降のプロセッサ(が、それはようするに今ある Intel 系CPU全部)か、その互換CPUである必要がある。32bit モード、64bit モードの区別はない。
逆に VMware や Xen など、仮想マシン上で動いている kernel に影響はない。これはそもそもバグを内包したルーチンを、仮想マシンで動いていると検出した Linux Kernel は使わなくなるからだ。

一切の予防的挙動は取られていないので、file systemなども含めて、non-volatile メディアに対する影響は甚大かつ破壊的。回避策はパッチの当たった Kernel をインストールしてrebootするか、200日以内に計画的に reboot する事のみ。

影響範囲
Linux Kernel 2.6.28 で導入されたパッチにバグがあり、3.1.5 で修正された。この間にリリースされた distribution は多分全部影響を受ける。

なお、具体的には
2.6系列:  2.6.32.50でfix
3.0系列:   3.0.13でfix
3.1系列:   3.1.5でfix
らしい。

商用 distribution で影響を受けているもの。

まずは SuSE11 SP1。fix パッチはこうなっている:
http://kernel.opensuse.org/cgit/kernel-source/commit/?id=413af9e6f17a1a1519cae0bfd1c1fe4409bb42a3

RHEL6も 2.6.32 base らいいのでこれも影響を受ける。

~~多分Fedoraとかも影響をうけるはずだが、マシンを上げていないので判らない(何その手抜き)。~~
Fedora マシンを上げたら
「3.1.1→3.16 に kernel を更新」
という update が出ていた。 Fedora16使いは速攻で上げることをお勧めする。
また、Fedora15使いは速攻で Fedora16 にして、update を最新に持っていくことをおすすめする。

3.1.5のバグ修正後のコードはこう:
http://lxr.linux.no/linux+v3.1.5/arch/x86/include/asm/timer.h#L58
(LXRとか、こうやってソースコード丸ごと指定できるからありがたい)

なお、VMware とかの仮想環境では、このバグっているルーチンはそもそも利用されない。なのでこれは実機上で動かしている Linux Kernel でのみ、発生する。なので、VMで実験を…とかは一切効かない。

技術的詳細
最近の Intel processor やその互換CPUには Time ~~Slice~~ Stamp Counter (TSC) という 64bit レジスタがある。

こいつは Intel の場合だと CPU 駆動クロックでカウントアップしていて、1tick ごとに+1していく。例えば 2GHz のCPUの場合、1秒で2Gづつ増えていくのだ。

また、AMDの場合だとCPUに投入されるクロックで 1tickごとに+1していく。大抵の場合は 800MHz なので1秒で800Mづつ増える。

判ると思うが、ほぼ nano 秒オーダーの時計として使えるので、リアルタイム制御をしたい場合、TSCはとてもありがたい。しかし、最近の電力消費量制御機構は、CPU駆動クロック周波数を変更してしまう。すると TSC の値は何がなんだか判らなくなる…
そこで、Linux Kernel 内部には cycles_2_ns() という関数があって、TSCの値をナノ秒に修正してくれる事になっている。

しかし、不幸はここに内包されていた

すごく簡単に言うと、TSCの値を必要な Scale Factor 倍すれば　nano sec になる。しかし、TSCの値は nano sec に近い。当然 Scale Factor は 1.0 に近い、微妙な浮動小数点になってしまう。

そうだ! Scale Factor を分数で表そう!!

SC/1024 で表現して、

SCを整数にしておけば、

SCを掛け算した後、

右に10bit シフトすれば済むよっ!!!

…この段階で何か嫌な予感がしなかったんだろうか、こいつらは…

とにかく、元の式は、TSCの値を 64bit 変数に代入し、それに 32bit のSC ( コード上は per_cpu() という関数の戻り値) を掛けて、10bit 右にシフトする、というものになった。

さて。ちょっとここで視点を変えてほしい。
「TSCに SC を掛けて、その後 1024 で割ると nano sec になる」
って事は、

TSCにSCを掛けると

大雑把に pico sec の精度の数字ができる

って事だ。

2¹⁰ = 1024 ≒ 1000 = 10³

なので、メートル法の縮尺単位が1つ変化する度に10bit消費される。
(ここは試験に出ます)

すると、pico sec レベルでの数字を扱うと、1秒を扱うには 40bit 必要、ということだ。しかるに、この値は 64bit の変数に代入されいてる。って事は「1秒以上」の表現には 24bit しか有効桁数がないって事だ。

2²⁴ / ( 24 * 60 * 60 ) = 194.180741日

実際には、1024の方が若干大きいので、その端数が載る。具体的には 64bit変数を最後に 10bit 右にシフトするので、有効桁数は 54bitになる。これが nano sec で表された時刻なのだから、

2⁵⁴ / ( 24 * 60 * 60 * 1000 * 1000 * 1000 )

= 208.499983日

めでたく、今回 overflow を起こした日数そのものが出てくる。64bitは、無限にでかいに等しい桁数ではないのだ。

かくして、cycles_2_ns() は、208.5日経つと、桁あふれを起こして 0 に近い値を出力する。sched_clock() はこの値を利用しているため、ここもぶち飛ぶ。

スケジューラーはここの値に強く依存しているので、突如として 54bit の数字が 0 になると、カーネルのあちこちがぶっ飛んでしまい、reboot に至る。

感想

497日問題の反省

全く活かされておらずっっ!!!

lunar eclipse

2011-12-11T03:47:00.002+09:00

On year 2011, Dec. 10th around 21:30 - 00:00, we had Lunar Eclipse here at Japan.

Here's some of the photos I took.

Camera: RICOH CX1
Mode: ... ah .. I kept on changing it in the dark. So I'm not sure.

And .. Battery run out ..... gosh ...

ホームゲート

2011-11-24T01:56:00.001+09:00

都営大江戸線の青山一丁目駅。

ホームゲートが設置されているのに、まだ稼動していない。

ゲートは全開でその先にレールが見えている。

実運用が始まるとこんな光景はもう見られない。珍しいので撮影。

< 2.6.17 な Linux に存在する flock の double free バグ

2011-09-23T00:35:00.005+09:00

Linux Kernel 2.6.17(正しくは 2.6.16.x で入ったのかもしれないが…) で新しく入った修正の一つに、flock(2) システムコール起因でカーネルがメモリをダブルバインドする、というものがある。

これを修正するパッチ自体は、2つ。
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=993dfa8776308dcfd311cf77a3bbed4aa11e9868
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9cedc194a7735e5d74ad26d3825247dc65a4d98e
最初のパッチが問題の本質を直して、2つ目のパッチはその修正の際に、異常系処理が甘くてエラーが還らなくなっていたのを直した、というものだ。

あぁ、あれね、と判っている人はこのバグが高負荷時に結構酷い確率で頻発することも知っているでしょう。
~~RHEL4U4でもまだ直っていないので、是非 RedHat にギャーギャー言ってください。~~
^*1

当然、ここでは「で? それはどういうバグなの?」という質問してくれる、ヨイ子のみんなのためにある。つーてもいきなり答はタイトルに書いてありますが。

*1) morikawaさん、情報ありがとうございます _o_。

つーかこれは修正し忘れですね。大昔、これを書き始めた時の情報を更新し忘れてました。

なぜコレをここに書くのかと言うと、理由は2つ。

1つ目は Linux Kernel の内部構造が double free に弱い(コレ自体はしょうがない)ため、類似のバグがあると、このバグを踏んだかなり後になってからいきなり kernel がぶっ倒れる、という事が多々あるからだ。この症状から真の原因を直接求めるのははっきり言って不可能に近い。が、なぜ不可能なのかをよく判っていない人に説明するのもかなり困難だ。なのでここに書いておけば、再びそういう目にあったときもここを見れば判る。

2つ目は、このバグがタイミング依存性の高い、かなりいやらしい構造をしたバグだから、だ。同期系のプログラムはかなり丁寧に動作を追わないと、いつ足元を掬われるか判らない。そのためには、いろいろな「実在したバグのケース」を記録しておくのが一番だ。というか、ややこしすぎて厳密に覚えていないと意味がないのに、すぐ忘れるからここに書くわけ。

とりあえず、パッチは上記にあるが、ソースコードはこんな感じだ。

2.6.16: http://lxr.linux.no/linux+v2.6.16/fs/locks.c の flock_lock_file()
2.6.17: http://lxr.linux.no/linux+v2.6.17/fs/locks.c の flock_lock_file()

で、この flock_lock_file() を呼び出しているのは sys_flock() 関数… flock() システムコールの入り口だ:
2.6.16: http://lxr.linux.no/linux+v2.6.16/fs/locks.c#L1495
2.6.17: http://lxr.linux.no/linux+v2.6.17/fs/locks.c#L1535

sys_flock() の中で flock_lock_file_wait() という関数が呼ばれている:
http://lxr.linux.no/linux+v2.6.17/fs/locks.c#L1569

flock_lock_file_wait() はここだ：
http://lxr.linux.no/linux+v2.6.17/fs/locks.c#L1496
で、flock_lock_file_wait() の中のここで flock_lock_file() が呼ばれている:
http://lxr.linux.no/linux+v2.6.17/fs/locks.c#L1501

これが、全体の流れだ。

で、メインの処理は flock_lock_file() が受け持っている。

まず、flock_lock_file() の中で kernel 全体を lock している。つーてもシングルプロセッサの場合は何もしていなくて、SMPの場合だけ、lock が必要な場所で lock をかけている。これが lock_kernel() と unlock_kernel()。もし、kernel_lock がすでに取られていたら、SMPの場合はこのロックが解除されるのを待つことになる。

先に 2.6.17 …つまりバグが修正された後のコードを見て欲しい。lock_kernel() が呼ばれているのはここだ:
  http://lxr.linux.no/linux+v2.6.17/fs/locks.c#L739
一方、unlock_kernel() が呼ばれているのはここ:
  http://lxr.linux.no/linux+v2.6.17/fs/locks.c#L788

ようするに入り口の所すぐで kernel_lock を取得し、この関数から出ていくまで一度も解放しない。これが正しいやり方だ。この間のどこかで kernel_lock を解放してしまうと、仮にそのあとすぐ kernel_lock を再取得したとしても、その間に別CPUが処理に入り込んでくる危険性がある。

で、一方で 2.6.16 は
2.6.17と同様、関数の入り口でkernel_lock を取得している。
http://lxr.linux.no/linux+v2.6.16/fs/locks.c#L722
で、関数の出口で kernel_lock を解放している:
http://lxr.linux.no/linux+v2.6.16/fs/locks.c#L768

が、その途中で一度 kernel_lock を解放し:
  http://lxr.linux.no/linux+v2.6.16/fs/locks.c#L737
再度取得し直している。
  http://lxr.linux.no/linux+v2.6.16/fs/locks.c#L749

問題は、この L737 出の開放の後、L749 での再ロックまでの間に、別のCPUが flock_lock_file() 関数に入ってくる危険性がある、ということだ。最初の git パッチにはこうある:

sys_flock() currently has a race which can result in a double free in the
multi-thread case.

Thread 1 Thread 2

sys_flock(file, LOCK_EX)
sys_flock(file, LOCK_UN)

If Thread 2 removes the lock from inode->i_lock before Thread 1 tests for
list_empty(&lock->fl_link) at the end of sys_flock, then both threads will
end up calling locks_free_lock for the same lock.

ちょっと見辛いし判りづらいな：

SMP環境において

Thread1: sys_flock(file, LOCK_EX)
Thread2: sys_flock(file, LOCK_UN)

がほぼ同時に呼ばれたとする。ただし、最初に kernel_lock を取得したのは Thread1 の方だ。で、Thread1 が最初の unlock_kernel() を呼んだ。

この瞬間に Thread2 は kernel_lock を取得できる。で、ここ:
http://lxr.linux.no/linux+v2.6.16/fs/locks.c#L734
この場所で、inode->i_lock を解放する。

で、ここを通り抜けた後、Thread2 が unlock_kernel() を呼ぶと、Thread1 が flock_lock_file() の後半部を通り抜け、flock_lock_file_wait() へと戻り、そこから sys_flock() へと帰る。

問題は、Thread1 が sys_flock() へと帰った後。ここ:
http://lxr.linux.no/linux+v2.6.16/fs/locks.c#L1532
で、lock_free_lock() を呼んでしまうことだ。結果として、同じロックを2重解放してしまう。

lock_free_lock() のコードはここだ:
2.6.16: http://lxr.linux.no/linux+v2.6.16/fs/locks.c#L157
2.6.17: http://lxr.linux.no/linux+v2.6.17/fs/locks.c#L169

ここで問題なのはただ1点、kmem_cache_free() を呼び出すところだ。これを同じ構造体に対して行なってしまう。結果として、2重解放が行われる。

で、これはどういうバグなのか? というのがここで書くお話。
なのだが、まだ書いてない(酷いっ)。でもとりあえず、そういうのがあるよ、と言うところまで公開しておく。
# git serverが復活したっぽいのと、lxr 上で説明したほうがある程度判りやすいので、
# その両方の準備をする。

Brave to stay

2011-09-16T23:59:00.002+09:00

This brave Mantis has been on "outside" of the window of 29th Floor elevator hall since noon.

I shoot this photo on my way back to home, 17:48, and (s)he was still there!

Hanging upside down on the glass must be tremendously tough job. And since (s)he have a wing to fly, it's not hard for h(im|er) to give up and fly a little bit aside for better environment. What a brave.

...

Well ... it might simply be that this insect was stupid as to stay though ... staying on tough situation for nothing ...

リサイクルループに着目しよう

2011-06-11T11:54:00.003+09:00

節電が叫ばれている。一般家庭も企業も15%ぐらいは節電して欲しいそうだ。

で、老人が「ペカペカ光るもの」は「電気を食うに違いない」とボケを垂れ流している。が、正直、それではたいして節電にならない。本当に電気を食うものってそんな所にはないからだ。

というか、「ペカペカと光る」とか「キンキンに冷える」とか、そういう擬音付きキーワードな代物は、別に昨日今日目の敵にされたわけじゃない。なのでアチラコチラに工夫がしてあって、実はかなり電力を食わないようになっているのだ。だからそんな所を今更攻めたって、たいして節電になどならぬ。

じゃぁ、どこにエネルギーは消費されているか?

エコロジーだともてはやされたもの。CO2削減にはこれ、ともてはやされたものにこそエネルギー消費は隠れている。

というわけでリサイクルを槍玉にあげてみよう。

リサイクルって言うのは「モノ」の形状を変えて、同じ物体をなんども変形させながら使い回しする、っていうのが基本発想だ。ペットボトルを粉砕して溶かしてもう一度ペットボトルにするとか。紙をパルプに戻して漂白してまた紙にするとか。「モノ」を無駄に破棄しない、と言う意味では素晴らしい。

でもちょっとまってくれ。そもそも、その「モノ」は何のために消費されているのだ? 我々は「ペットボトルを買いたい」わけじゃない。我々は「紙が欲しい」わけじゃない。

ペットボトルなら、その中にあるジュースが欲しいのだ。紙が欲しいのではなく、紙に印刷されている情報が欲しいのだったり、紙に包まれている中身が欲しかったりするのだ。まさに輸送のためのケースがペットボトルであり、紙なわけだ。だからこそリサイクル出来るぐらい損傷少なくペットボトルや紙を回収できる。

しかし、リサイクル・ループはエネルギー的に見れば決してただじゃない。輸送にはガソリンが、加工には電気が使われているはずだ。

じゃぁ、ペットボトルを使わない、紙を使わないで目的を達することは出来ないだろうか?

非炭酸系の飲み物をペットボトルから紙容器に切り替えるとか。

新聞を紙から電子版に変えるとか。

本来の目的からすれば別に欲しいわけじゃないモノを使わないようにする事で、リサイクル・ループを流れるモノの絶対量を減らす。しかも「本来の目的」は別にセーブしなくてよい事になる。

今回の節電は、目先の電力消費量を変えるのではなく、リサイクル・ループを流れる物流を減らしつつ、無駄にモノを廃棄しない、という形を取らないと苦しいと思う。目先のペカペカしたものを排除するような発想では、長期的に見ると必要なエネルギーが減らないままだ。

【DS】A列車で行こうDS 「青葉経済開発区」「標準」

2010-12-05T02:54:00.008+09:00

というわけで、新しい地図「青葉経済開発区」…と言っても、演習問題でやった最後の地図だが。これの「標準」モード。

目標は複数。

総資産1000億円
2年連続黒字
子会社数10社

以上を10年以内で。

とはいうものの、これだけだと簡単だ。そこで追加の条件。

株式公開しない
借金しない
地下鉄駅は作らない(陸橋上に駅は作るし、一部は地下鉄にする)
鉱脈は掘らない
資材置き場は全部地面の下(だって地上に用意するのもったいないじゃん)

最初の資本金は600億円で、この一部が土地だの電車だのになった状態でスタートする。2年連続で黒字になれば、株式公開できる。すると資産が一気に増える。ここに借金分を追加すれば総資産1000億円は実は簡単だ。子会社だって黒字・赤字を無視すれば10社ぐらい簡単に作れる。運がよければ黒字になって、総資産を増やしてくれるだろう。

が、株式公開も借金もしないとなると、一気に条件が難しくなる…はず。

この土地は丘の上と下に別に町があるので、それぞれについて小さなループを作ってやる。とりあえず、一方づつ片付けつつ、もう一方もある程度発展してもらうには、この小さなループが一番。ただし、あとでループを伸ばせるように、伸張部分相当の土地は買っておく。

丘の上のループと丘の下のループそれぞれ上下の水平線路の間隔が10マスになるように取る。すると駅をうまく配置すると、町が発展したときに複数の駅が同時に発展する事ができる。並列な線路それぞれの駅の影響範囲をオーバーラップさせればいいわけだ。で、それを丘の上と下でも実装するために、丘の上と下の間、丁度10マスの所に水平に土地を買っておく。

で、とりあえず子会社を10個作って稼がなくちゃいけない。そこで上の範囲指定。離れ半島の根元、一番左側だ。
ここに工場地帯を作る。目的は画面外の「隣町」への資材の輸出。

一番最初は線路を引いて、隣町から資材を輸入。資材が1つでも発生したら、速攻で工場を建て始める。で、工場ができたらこれまた速攻で輸出に切り替える。これで期限内に黒字になるに違いない…と思ってやってみたのだが…

実際には、工場を建てるコストが結構高いので、10年以内に黒字になりませんでした。つまり計画倒れ。

もう一つ、打った対策がこれ。上のループ側に工場があるように見えなかったので、下の工場から道路を引っ張って上のループのそばに1つバス停を設置、その真下に資材置き場をたくさん用意して、資材不足にならないようにした。

というわけで、以上の敷設が終わった直後の地図がこれ。
線路とか、ほとんどまだ撤去できていません。撤去費用がもったいないんだもの。その間に地下鉄の技術を開発する。

さて。しばらくして人口が増えてきたら、路線を延ばします。伸ばし方はこう:
下のループを解除してうねうねと南の端まで。南の端で線路が切れてる?!いいえ。では見てみましょう。
見てのとおり、南の端は地下に潜っています。
で、出てくる側はここ。とりあえず、地下を通って一気に北上します。

さらに時間が過ぎて、人口が増えてきたら、さらに鉄道を延ばします。こんな感じ:
この段階で、南の端から潜った電車は、画面右端の一番北側…右の方に「山」があるんですがその根元から湧き出しています。B1だとまっすぐ伸ばすのが難しいのでB2まで沈んで、一気に北東へ、で必要な高さまで再び上昇。

さて。会社運営は初年度を除いて毎年ギリギリ黒字でして。ですので2年連続黒字は簡単。子会社も工場を建てたり、マンションAを建てたので10社は楽勝。唯一の問題は資産1000億円なんですが。

10年目の8月。ギリギリ、なんとか資産1000億円クリア。
見ての通り、どうにか全部あわせて月20億円づつ収益が上るようになったので、それを子会社に再投資…を続ける。あ、あと福利厚生は毎年ガッチリプランに入れて、社員のやる気を高めます。
1月から5月までは一切投資せず、6月から12月に一気に子会社を作ると、だいたい収入の40%を税金用にプールできるので。8月だから残り7ヶ月ですか。結構ヤバかったかも。

さて、条件をクリアしたら、あとはひたすら発展させていくのみ。

見ての通り、10マスごとに東西に平行な線路を引いていくわけですが、一気に伸ばすと人口密度が薄くなってしまうので、とりあえずは上下方向に伸ばすようにしました。左右方向はとりあえず上下方向が一通りそろったら。

で、左右方向の左端から半島に、半島から南の島へと線路を延ばそうかと。あ、半島の右にある島は開発対象にしません。面積が狭すぎて駅が建てられねぇ。

で、この辺まで伸ばすと、資材不足が頻発します。工場から遠すぎて、資材を必要とする場所と、工場との間に別の資材不足が発生すると、資材が届かなくなる。そこでカーソルのある場所にも工場を建てることにしました。

もちろん、画面ギリギリに作っているのは、これらの工場群の第一目標はあくまでも隣町への資材の輸出だから。資材が必要ないときは輸出量を多く、必要になったら少なく調整する。

というか、これは発展させていく過程で判ったのですが、巨大な1つの循環路は、線路を延ばすたびに貨物列車が一周する時間が長くなります。で、そうすると工場から資材を回収する頻度が下がり、輸出量を多くしなくちゃいけない。でも我々の町側も実はあちこちで資材を必要としていて、貨物列車の数が足りていない(資材不足が発生しまくる)という問題が…。

そうこうしているうちに、新たなる問題が。
判りますか? 駅が建設できないんです。
…さっっ、先に言ってくれぇ(T.T)

って言うか、少なすぎるだろう。80って。

とりあえず、駅を増やせない以上、どこかの駅を引っぺがして新しく配置するしかない。

幸か不幸か、今の駅の配置はほぼ全ての土地を2つ以上の駅が共有するようになっている。なので、どこか…そう。南側の土地を集中的に開発してしまい、その場所については急激な人口増加を必要としない状態にしてしまえば駅密度は半分…つまり土地の発展に影響される駅の数が1つになるようにできる。に違いない。
で、とりあえず、駅を引っぺがせるようになるまでの間に、残りの線路を引いておく。

半島に入る線路は、北側が半島に入るほう、南側が半島から出る。

半島に入ったらまず、最初に作った工場のそばを通り、ここで資材を拾う。で、その直後に地下に潜って、島の北側へ。島をグネグネと移動したら、今度は半島の南端へ橋を渡る。で今度はグネグネと半島を北上する。海岸が東西方向に近い部分は一部の引き戻しを地下で行うけれど基本は地上を通るように線路を引く。で、最後に半島を抜けて、大陸側のループに戻る。

ここまでで61年目。
なのだが、ここからが長かった…

結局ループが長すぎて、地図全体で4箇所も工場地帯を作っているのに、資材配給がどんどん滞るようになっていく。とりあえず、全体開発完了の目標として、総人口100万人を目指したのだが、資材が届かないのではいかんとも発展しがたい。当然子会社の上限とかが先に来るわけで…作っては売り、を繰り返すと社員のやる気がすごい勢いで落ちていくし…。
結局、我慢比べ大会のような状態でジリジリと開発を進めていって、総人口が100万人を超えたのは 190年後の事に。全体はこんな分布:

会社の状態はこんな感じ:
やはり、もう社員の不満はどうしようもなく。

会社沿革はこう:

なによりも残念なのは、人口を100万人にしても会社沿革に載らない事。いや、総資産10兆円オーバーも、100兆円オーバーも載らないんですけどね。

結局地図全体はこうなりました:

最終的な反省点。

巨大循環路は退屈だ。
なにしろ時間を掛ければ絶対成長する事が判りきっている。一方で、資材不足とかが頻発しすぎる。循環路自体はともかく、全部を1つの循環路にするのは考え直したほうがよさそうだ。
隣町との交易専用の駅は、駅舎の無駄。
隣町へ輸出するために工場のそばに駅を作るのはいいのだが、距離を最適化しすぎると、輸出にしか使えない駅になってしまう。結果として、その工場群から「自町用の資材」を拾うための駅をもう1つ作る羽目になり、これが駅の無駄遣いになる。
1つの駅で両方の目的をクリアし、ついでに町の発展分(21x21マス)の計算にも入れられるよう、配置するべき

というわけで。以上の反省点を踏まえて、「いばらの道」を攻略する事にしよう。

【DS】A列車で行こうDS 「青葉湾岸工業区」「いばらの道」

2010-11-13T17:38:00.006+09:00

では、「青葉湾岸工業区」マップの最後、「いばらの道」だ。クリア条件は一緒。人口を1万人にすること。

地図の初期状態は「標準」と一緒。

最初の人口も一緒、6508人。

産業などの初期状態も一緒である。

で、すでに知っている事実として、人口を1万人にすること自体は簡単である。当然ながらその後をどうするかが焦点になる。そこで、今回設けたルールは次の3つ。

線路を前回のようなぐちゃぐちゃな状態にしない(もう少し計画的な路線にする)
地下駅は極力使わない(発展を阻害する要因になる)
株式公開をしない
スタート直後に港を作って隣町に資材を輸出、お金を稼ぐ

1 は「標準」のマップがあまりにも醜くかったので。

2 は「標準」での失敗から学習。地下鉄…というよりも地下街が野放図に作られると、その後の制御ができなくなりすぎる。

で、1, 2 だけで本気を出すとあまりにも簡単なので、3。株式公開をしないことで資本金を減らす。とはいえ、これは「配当を気にしなくて良い」という性質も持っているので、必ずしも悪い面ばかりじゃない。

で、4。このゲーム、隣町との交易を盛んにすると儲かりやすい。株式公開をしない分、資金をどこから得るかというと、最初にこれをやってしまうことで。

実は後で、発想はともかく、この地図で、港で実装するのは賢くない、という事を学ぶはめに陥るのだが…

というわけで初手。まず時間を動かす前に、コンビナートを1つ買いあげて潰す。で、その場所に港を作る。
実は最初に手に入れたお金で隣接するコンビナート2つを買取り、潰して、港を設置する事はできない。港を作るのに少しだけ資金が足りないのだ。土地だの何だの売りまくればできなくはないが、それだと鉄道網に手がつけられない…本末転倒なゲームになる。

そこで、上記の場所のコンビナートを1つだけ買って・潰して・港にし、完成し次第「高稼働」で交易を開始する。

で、港を作った分資金的に苦しい状態になるので、その分をどうやって補填するかというと、人口密集地の初期ループの横幅を狭くすることで補う。あと、地図縦方向の駅は、初期段階では建てない(既存の駅1つはあとで潰す。新規には作らない)。このためか、人口1万人達成は2年目の11月までかかることになるのだが…ま、それは十分だろう。

お金が溜まってきたら、ループを伸ばす。まずは鉄道網的には左右に引き伸ばして、上下2本の平行な線と、それを結ぶ垂直(若干斜めな)線になる。

が、地図をよーく見てもらうと、実は水平に何本か土地が購入されているのが判ると思う。不自然に更地になっている線がある。これは将来の路線のための土地確保だ。

今回の線路は、前回の失敗から、計画的に拡張することにした。で拡張ルールはこうだ。

まず、最初の線路は見ての通りにつくる
水平方向に線路を延ばすことを考える。水平な線路は上下方向には10マス程の隙間を開けて平行に何本も走らせる。
下から順に「左」、「右」、「左」、「右」…となるように電車を走らせる。最初はループにするが、拡張に際しては、下から順に上に上がっていき、最後に一番上から一気に一番下の線に戻す形のループを作る。
で、最初から全域をカバーしようとはせずに少しだけ左に行ったらすぐ右に戻ってくるように線路を引く。で、この線路を徐々に左方向に伸ばしていく。
駅は、互い違いになるように配置する。上下で同じ場所に置くより、交互にしたほうが人口が広がりやすい。
一番上から一番下へは、地下を通す。B2Fまで一気に沈めて、一気に一番下へ持ち込む。ただし、途中に地下駅はつくらないこととする。

線路を敷く予定になっている土地が勝手に開発されては困る。しかし、土地が発展しないのも困る。そこで、なるべく早い段階で線路用の土地を手に入れることにした。あ、あとこの際には、線路用の1マスの他に、緊急時用の一マス分、あわせて2マス分の太さで確保することにした。

で、そのルールに従って延々拡張した結果がこれだ。

実は上記のルールは客車については完璧なのだが、これだと貨物車が困ったことになる。路線が伸びるに従って、途中で資材が使い尽くされてしまい、なかなか遠方まで届けられないのだ。しょうが無いので、予備の土地を使って貨物車だけ工場地帯に戻し、資材を積み直す…という線路のひき方をしている。

もう一つ、今回発見した小細工がこれ。

港を最初に作ったのは良いが、資材の回収範囲が狭いためか、生産が追いつかない。一方で全然資材を使っていない工場もある。そこで、港をもう1つ作ったのだが…そうしたら最初の港から輸送される資材の量が減ってしまった……
おかしいと思い調べたところ、港を沢山作っても、輸送に使われる船は1艘だけだったのだ… orz これでは港を2つにしても、輸送量は2倍にならない。

で、いろいろ調べた結果さらにわかったのは、一度に輸送船に乗る資材の個数はともかく、それを隣町に持って行くには「航行距離に比例した時間」がかかる、ということ。つまり画面範囲の端ぎりぎりの場所に港を作れば高頻度で資材を運ぶが、地図の中央だったり地図から出て行くまでの航路が蛇行していて長かったりすると、輸送に時間がかかり、時間あたりの輸送量が減ってしまう。

それなら、ぎりぎりの場所に簡易駅を作り、その周りに工場を立てたら良くないか？とかなり後になって気がついてつくってみたのがこれ。大正解。というか輸送量ありすぎ。工場Cが2つ、工場Aが3つがかりで、全力輸送されると資材が足りずに、資材置き場の備蓄を浪費されるので、一日4往復に制限する必要があったぐらい。というわけで、今度からこれで行こう。

で、最終結果。

98年目で飽きた。というか、一応一通りビルが建ってしまい、これ以上どうにかするには「潰しては立て直し」を繰り返さなくてはいけない。多少はやってみたが、操作が重たくて重たくて…。子会社が100社あって、さらに1x1規模のビルが林立していると、さすがに何をやっても重たいわ。

職業分布。

微妙に商業都市になった。ギリギリ直前までは、娯楽の方が多くて観光都市だったのだが。

剰余金は「標準」のときよりも多い。これは地下街をほとんど作らせなかったので、高層ビルをたくさん立てることができ、結果として収益が増えたからだ。

娯楽と商業が突出したため、景気にかなり左右される年収になった。その辺をどう考えるか、が今後の課題だろうか。

じゃ、次あ「青葉経済開発区」だ。

【DS】A列車で行こうDS 「青葉湾岸工業区」「標準」

2010-11-04T02:02:00.004+09:00

2つ目の地図…「青葉湾岸工業区」の「標準」に移ります。

マップの詳細は、A列車で行こうDS Wiki の「マップ/青葉湾岸工業区」を参照。

スタート時の人口は 6508人。これを人口1万人にして欲しい、というのがクリア条件。

期限	標準(5年)
資本金	標準(300億円)
景気動向	標準
売却査定	標準
融資金利	標準(5～15%)
アドバイス	あり

実は非常に簡単にクリアする方法があります。

このように、すでに人口がある程度いる場所を環状線で囲い、環状線の外側に資材置き場を用意した上で、3輌編成の客車を5台ぐらいグルグル回してやる。車両数が多いと運営コストがかかりすぎるので赤字になってしまいますが、３両ぐらいであれば台数が多いほど効果的なようです。

貨物車を１両だけ用意し、この環状線の外側を湾の下側の工場地帯と、環状線の左と上側に最初から存在する駅の間を往復させ、資材を運ばせます(運営計画を使って、必ず工場で「全部積む」、他の駅では「全部降ろす」にしてください)。

で、あとは金の続く限り環状線の内側にマンションCを建てては売りさばく…を繰り返せば、本気を出すと２ヶ月ぐらいでクリアすることができるでしょう。

万が一の倒産を回避したいなら、工場が明らかに生産能力過剰に陥っているのを利用します。

貨物車両をもう１つ用意し、工場と隣町との間を往復させます。ここでも、工場のそばの駅では「全部積む」のを忘れないように。他のすべてが赤字になっていても、この資材販売だけは確実に黒字になってくれます。お金に余裕ができたら、地図右下側にあるコンビナートをいくつか買取り、潰して、港にしてこれまた資材を隣町に売り払うとよいでしょう。

今回は、条件をクリアするまで自発的にマンションを作らない、という制限をかけてみましたが、それでも最初の年度の１月にはクリアしてしまいました。

さて。本腰を入れるのはここからです。「青葉リゾート区」に比べて圧倒的に面積が広いため、これを全部開発し尽すのはきっと楽しいに違いない。そこで、なるべく駅は全部地下にしてしまおう…というか地下鉄網に置き換えて行こう…と、頑張りました。結果はこんな感じ:

地上の線路は下の方にある資材販売用路線と、そのそばにある貨物を載せるためのパスだけです。

というか、貨物を載せるための線は実は地下にもあるのです。ただ、路線を巨大な１つの環状線にしたら、工場から離れるに従って資材不足に陥る可能性が跳ね上がってしまったので、資材を載せなおすために工場のそばをもう一度通し直そうとしたのですが…なんと地下街が発達しすぎてて地下だけでは上手く資材回収用地下鉄を引き回せなかったという…

地下鉄をも含めた路線は、こんな感じになっています:
ぱっと見ただけで判るように、「どうしてこうなった」状態。ループをあっちからこっち、そっちからどっち?! と引き回した結果、直しようがなくなってしまったのでした。実際、地下2階から高架2階までの5フロアを使い切っているこの路線を引き直そうとしても、地下街が邪魔をして引き直せないでしょう。

今回学んだ教訓:

地下街は、潰せない

なので、発展にともなって地下街が邪魔になったり、再開発の際に地下街がじゃまになる可能性を考慮すると、地下街はなるべく発展させないようにブロックしておいたほうがよさそうです。直上に高層ビルが建てられないだけでなく、線路を引き直す上でもじゃまになるのですから。

さて、これがとりあえずゲームを止める直前の状態:

比較的発展してますよね。人口とかはこんな感じ:

資金が35兆円とかになっています。はっきり言って子会社を100個持っていても投資しきれません。走らせられる車両数にも限りがあって、こちらもあまり多すぎると操作性にすら問題が出ます。

「効率のよい投資先がない」というのが大問題になってしまい、会社の評価をこれ以上落とすわけにもいかないので、ゲームとしてここまでにしました。

えぇ、４０年ほどでこれぐらいに…嘘です。「1４０年」です。

マップを見ると分かりますが、人口が27万人ちょいで、黄色いところはポツポツとある程度。実はあまり高層ビルが建っていないので、人口密度が高くありません。これは地下街が想像以上に発達し、高層ビルが建てられなくなっているのと、マンション群がやたらと「マンションA」の山になっているのが原因です。建て直しラッシュでもかけて、かたっぱしから「マンションC」と「マンションB」にしてやろうかと思いましたが…地下街等の障害物があると、「雑居ビルE」以上に密度をあげられないこと、デパートも「デパートC」が限界になること、などを発見して取りやめ。

とにかく地下街が邪魔で邪魔で…

でも、地下鉄にすると、地上の利用効率が非常に良いのも事実。どうしたものだか…うーむー。

と、このように、課題を残して終わったのでした。

【DS】A列車で行こうDS -1- 「青葉リゾート区」「いばらの道」 -1-

2010-10-21T22:24:00.002+09:00

さて、では「いばらの道」…普通に言う『難しい』だ。地図は相変わらず「青葉リゾート区」。

いや、だってさ。地図を思い出すの大変じゃないですか、このゲーム。一度1つの地図をクリアしたら、同じ地図を難易度を変えて繰り返し攻略するのがコツですよ。どう考えても。

というわけで「いばらの道」ですが、クリア条件は「標準」と同じ。

ご存知「苗羽駅」。あそこの1日あたりの利用者を500人以上にする。これをクリアするまで駅設定のみ不可。
6年目の3月31日までに、人口を5万人以上にし、総資産を1000億円以上にする。

で、相変わらず1の条件はど楽勝。

問題は2なのだが、資本金が 500億円あるので、資産的には400億円ぐらいにはなるはず。株式公開すれば700億円手に入るので、合計で1100億円。やはり株式公開すれば、お金はどうとでもなる。どちらかというと「アドバイス無し」が痛いか?

最初に張った線路はこう。相変わらずいきなりループ路線。

線路だけ切りだしても同じ

いきなり「買取」⇒「撤去」攻撃。地形的には2箇所。でもビル的には4つだったか5つだったか(ちゃんと覚えていない)。

2つめのなんか、公園がどうしても避けられないので、わざわざ買い取るべき不動産を最小にするために線路をねじ曲げてる。強欲ですなぁ…

で、このように電車を配置。進行方向は左方向:

なんとなく財政的にまだどうにかなりそうだったので、早い目にもう2台客車を追加投入:

一台あたりの乗客数を見ると:

279人。なので2台通せば苗羽駅を通る客は500人を超える。何割降りるにせよ、客車4セットがかりなら間違いない…当たり前のように最初の条件はクリア。

で、速攻で貨物車の開発に取り掛かる:

連結力は1だけアップ。こうすると豆腐が4つ同時に運べる…というかそれ以上運ぼうとすると途中で余る。これ以下だとループが長くなるに従って不足している地域が広がりすぎて開発が進まない…で、すべてを省エネに注ぎ込む。

駅は最初のループの段階では当たり障りなく(なにそれ)。1年半ぐらい経由したところで、左下のブロックに手を伸ばす。つーかその順序でないとお金が足りない。

正直、この段階ではまだ島の左端をどうやって開発するのか考えていない。クリアできるかどうか自信がないんだもの。特に人口。

というわけで、ゲーム開始からほぼ2年後:

「マンションB」を建てまくったおかげで人口は 3.5万人。つーか2年かけて1万人増加ですか。6年かけて3万人…大本が2.5万人ぐらいだから…ギリギリだなぁ。しかも、もうそろそろ余剰資金尽きかけてるし、黒字にしなくちゃいけないし…

困りながらマンションを建ててはあがりの悪い所を即座に売り…を繰り返す。ゲーム開始から3年後:

!!!!! おおぉぉぉおおうっっ、4万人突破。よし、これで3年間であと1万人増やせばよい。少し余裕ができた。

さらに半年後:

えっへんっ!! この段階で2年連続黒字だ。

…というわけで、めでたくこのマップもクリアしましたとさ:

ちなみに。その後の写真は無いが…

ちゃんと島の左端もきっちり上まで開発しました。今回は地下鉄を駆使して走らせました。
ちょっと知らなかったのは、地下街。勝手に3方向に発展するのなー。そうと知ってればもう少し地下鉄駅の方向とか気にしたのに。山の真下だけ繁盛させるとか…

この地下街、実は最強。取り壊せない、上にビル建てられない。勝手に伸びる。つながる。
そういうのは先に言って欲しい。もっと真面目にB2Fの使い道を考えたのに…
つーかB2FもB2Fで駅作れないのはどうにかならんのかと…

寂しいのは、地下街も地下鉄も、全景を知る方法がない、ということ。全体をパッと見渡す図がないので、載せられないのでした…

ま、とにかく。
これにて、「青葉リゾート区」は攻略完了。

【DS】A列車で行こうDS -1- 「青葉リゾート区」「標準」 -2-

2010-10-16T13:34:00.006+09:00

1回失敗して気づいた事、判った事は次の通り:

条件をクリアするまでは、人口の伸びが悪い。これはマンションのような「住む場所」が無いからで、実際人口はマンションを建てるたびに伸びた。つまり究極的には、必要な数だけマンションを建てればよい。別の言い方をすると、「勝手にマンションを建ててくれない」(あるいは、マンションを建てる率が悪い)のはクリア条件を満たすまでの制約の一つだと思われる。
マンションなどの子会社の収入は著しく悪い。経営方針を「経費節約」にしてもギリッギリ。ちょっとでも気をぬくと赤字になる。これは高層マンションほど酷い。状況的にはあまりにも酷いので、おそらく「クリア条件」を満たすまで、なんらかの制約がかかっていると思われる。
鉄道の収益はよい。そもそもがループ自体がかなり短くて済むのに人口は決して少なくない。なので、線路をループにしたうえで極限まで列車を増やす事で収益を得る事ができる。
もともとの資本金は700億円。株式公開をすればさらに700億円が資本金として手に入る。よほど酷い使い方をしなければ、資本金≒資産額になるので、株式公開をすれば資産額が1400億円になるに違いない。あとは、どうやって余剰金を10億円分作るか

まぁようするに。人口の伸びの悪さに驚いてしまい、高層マンションを建てて乱暴な運営をしたら子会社が赤字化しまくってしまい、2年連続の黒字と言う条件を満たせず、株式公開に失敗してゲームオーバー … だったわけですよ。

なので、2回目の戦略は次のようにしました。

まず、線路をループ状に作る
可能な限り「3両編成の」電車を多く走らせる
貨物を開発、1車両だけループの中を巡回させる。積み下ろしは工場のそばは「全部積む」それ以外は「全部降ろす」
で、「鉄道にゆとりができてから」、マンションBタイプを建てる。このタイプが収容人数と、建築にかかる日数と、消費する土地の面積のバランスがよい。
マンションはできたその日に経営方針を「経費節約」にする。建てる場所は駅前であれば深く考えない。2年経っても黒字にならなければ売却。
ギリギリ黒字経営を目指す。で、2年連続で黒字経営に成功したら、余剰金を10億円貯めて、株式公開

で、結局。先に人口が5万人を突破してくれたおかげで、6がクリアできた瞬間に、イベントはクリア。

と同時に、マンション運営が一挙に改善した。やはりリミッターが掛かっていたらしい。

人口増加は次の通り(6年目までがまずはリミッターなのでそこまでをまず見て欲しい)

見ての通り、3年目と4年目の間にものすごい成長が発生している。4年目の初めに5万人を突破し、ほぼ同じ頃に株式公開したため、ロックが解除されたようだ。

同じようなことは産業推移図からも判る。3年目までは私もかなり努力してマンションを建てていたが「住宅」はあまり伸びていない。が、ロックが解除された途端一気に増えている。一旦爆発的に増えたあとは、むしろ減っている。住宅が減ったのに人口が落ちないのは、住宅がマンション等の大規模住宅に入れ替わったからだろう。

ともあれ。とりあえずクリアできたので、その続きを。これが7年目の地図だ。最大の違いは島の一番下、従来ど田舎だった部分が開発されているところにある。
これは地図をもっと大きくすると、理由がわかる。

苗羽駅から線路が山に突っ込んで、そのまま反対側から出てきているのが見えるだろうか?そう。地下鉄技術を開発して、山に穴をあけたのだ。というか、右のループの周りはすでにかなり開発が進んでしまっており、うかつに穴を空けられなかった(出費がすごくかさむ)のと、トンネルと地下鉄を作ってみたかった、というのがこのデザインの理由だ。

これこのとおり。トンネルのあとは地下鉄である。
で、丁度島の右下の部分、地上でもループしている部分と一部重なるように、地下鉄を掘った。おかげで、初めて見ました。地下街。勝手に成長するんですね。それもかなり不規則かつ「オメーそりゃ不便だろう」と言いたくなるような形に。

なるほど。と、いろいろ操作方法とかを学習したところで、次も同じ地図行ってみよう。

【DS】A列車で行こうDS -1- 「青葉リゾート区」「標準」 -1-

2010-10-15T00:40:00.003+09:00

一通りの操作ができるようになったので、これで本格的にプレイできる。というわけで、一番最初のマップ、「青葉リゾート区」の「やさしい」を…あれ? 操作パネルが元に戻っている…そうか。「やさしい」だと一番最初に戻っちゃうんだな。じゃぁ、これではなく、「標準」で行ってみよう。

立ち上がりの地図は一緒。

で、今回は大きく2つのミッションに分かれている。

ご存知「苗羽駅」。あそこの1日あたりの利用者を500人以上にする。これをクリアするまで駅設定のみ不可。
6年目の3月31日までに、人口を5万人以上にし、総資産を1000億円以上にする。

1の条件をクリアするのはとても簡単。ただし、2の邪魔にならないように注意深く実施しないと酷い目にあう。

というわけで、こんな風に線路を引いた(写真自体は1の条件をクリア後)。

「苗羽駅」(この写真だと左下)へのアプローチはわざと反対側から。これ、逆にアプローチすると写真左側からぐるっと回るコースがギリギリ引けない。

丁度島の中央にある駅…何駅なんだろう、早々に消したので覚えていない…はガン無視。だってこいつ山に近すぎて反対側から線路引けないんだもの。

島の右上、マンションとかがいくつか建っていてそのままだと袋小路。が、環状線のために「買収」＆「撤去」!! 大雑把に3件分ぐらい。で強引に線路を引いた。

こうすると、最初から持っている電車を2台とも一気に動かせる。これを時計回りに、ほぼ隣接した状態で動かす。一瞬で 1 の条件がクリアできる。

1の条件をクリアしたら、駅の増設ができる。ので、駅を増設する。すでに工場がいくつかあるので、それらに対応するように1つづつ。あと、地図上で赤色の領域に1つづつ(工場とダブっている場合は建てない)。最後に地図右下の空間に合計2つ。

各駅に停車する時間は10分に調整。休みなく動かす。何しろ、この段階では人口は2万人ちょいなのだ。これを5万人に…それも大雑把に5年以内にしなくちゃいけない(1年ぐらい余裕がないとやばいだろう?)。車両を休ませている暇はない。同時に、客車を3両編成でつくっては間に走らせ…を繰り返す。

最終的には15セット走らせた。

（順に「あ」「い」「う」…という名前をつけていって、「そ」まで行ったので間違いない)

貨物車両の開発を並列して行う。車両的には3両つなげればよい。これだと資材が4つ運べる。残りは省エネに振り向ける。客車が低速なのに、貨物が高速なのは意味がない。開発ができたら、1セットだけ動かす。各工場最寄の駅では「全部積む」、それ以外では「全部降ろす」

最後に、各駅の周辺に適当に「1マス資材置き場」を散らす。どこかに集めて3x3とかするより、この方がカバー領域が広い。無駄に積んである資材は使い切るまでは放置。資材置き場だけになったら撤去して、1マスだけ残す。

ここまではほぼ共通なのだが、この面、実は2回やっている。

そう。1度目は総資産1000億円の条件を満たせずに Game Over になってしまったのだ。人口がなかなか伸びなかったので総資産の方に意識が回らなかったのが原因。というのは、子会社で「高層マンション」ばかり建ててしまい…

ここから先は、全条件をクリアした2回目について、どうやったのか書くことにする。

【DS】A列車で行こうDS -1- 「青葉経済開発区」「やさしい」 -4-

2010-10-11T20:28:00.004+09:00

/.J の日記の日記の続き。写真がないと状況が説明できないゲームにとうとう業を煮やしてこちらに。

とは言っても、「青葉経済開発区」の「やさしい」レベルに関してはもう、何がどうということはなく…

もう子会社はすでに100社。これ以上作れません。効率の悪いところを切り捨てて新しく作るのにも限界が。
電車の車両はすでに50両。つまりこれ以上は知らせることはできません。
実はバス・トラック類があまり好きではないので、道路がものすごく効率の悪いことに。なのでこれ以上車両を走らせることもできない。
開発できる土地もほとんど残っていません。

なので、もうこれぐらいで終わりかなーと。

とりあえず、こんな感じの現状:

見ての通り、未開発の部分が殆ど無い。そして白い線を追い回すと判るが、全体で1つの巨大なループ線になっている。最初は右上のDを横にしたような部分と、半島の右半分のループから始まったのだが、半島の右半分を伸ばして、伸ばして、伸ばして…こうなった。

会社の状況的にはもうイッパイイッパイ。子会社と列車はこれ以上動かせない。というか列車なんか運行スケジュールが一発で全範囲を指定できない有様…。まぁまぁと言えましょう。

公共が常にぱっつんぱっつん。これは超高層マンションBを建てる度に、その周囲に2x2の公園だの寺社だのを建てまくるから。そうすると超高層マンションが比較的速く埋まって黒字になる。と同時に人口がそこに集中してくれる。

運輸はどうやっても人が溢れ返るのでどうしようもない。

住宅の供給が微妙に足りない気がするが、実を言うとこれ以上どうしろと…という気もしている。。なにかいい手があるんだろうか…

「やさしい」だからだろうか。人口が減ることは一度もなかった。まぁ、反乱が起きなくてなにより(そんな機能はない)。

会社格付けAAAもクリアしたし。こんなもんかな。

札幌へ行ってきた -2-

2010-09-18T23:48:00.018+09:00

明けて二日目。二日酔い。当たり前ですな。

視界がぼけています…

いえ、頭がぼけててフォーカスが合っているかどうかの

チェックを怠っただけです。

とりあえず、札幌駅のコインロッカーに荷物をおいて、再び南口から出ると…

雨～～～

It's a rainy blue, it's a rainy blue

ゆれる心ぬらす涙

はっ、そうじゃなくて。

こんな感じのところに行ってみました。

えぇ、ここ。

有名な「北海道庁旧本庁舎（赤れんが庁舎）」

しかし、二日酔いの頭にはよく判らず

南側の池では、蓮が咲いていました。

うーん。とはいえ、手持ちのカメラではめいっぱい寄ってもこのレベル。

ちっ、もう一グレード上のカメラも持ってくればよかった。

一泊二日の荷物とは思えない重さになったかもしれないが…

季節的にはもう外れなので、ほとんどの花は泥中に沈んだあとなのでしょう。

で、今度は南東の方に移動。

それにしても道が広い。車線も広いが、

車線の外が広い = 路肩がゆったりととられている。

運転しやすそうだ

さて、次の観光はここ。

そう。時計台。

なんというか…さすがは

日本一残念な名所

と言われるだけのことはある。

何がどうすごいのやらさっぱり。

こう…パッと見ても微妙に花がないというかなんというか…

むしろ、観光中のお姉さんのほうが花があるというか。

あぁ、そういえば。お馬さんがいました。

これは何度か出会って、そのたびに撮影をトライした中で最もできが良かったもの。

つーか、それ以外はボケてたり、断ち切れてたり…

orz

そうこうしているうちに、酒が抜けてきたのでご飯。

ゆで卵に店名が書いてあります。で、Google Map で引けばどこら辺にあるのかは判るというもの。

んー、ラーメン自体の味は…普通。

コレといってすげぇ、というわけではありません。

ただ、餃子のタレに

味噌ダレ

があるのを発見して慌てて、餃子を追加。

こちらは、私の好みでした。

で、あとは適当にブラブラしてから帰りましたとさ。

つーか帰りの新千歳空港がひどい状態だったのだが、

ひどすぎてカメラを向ける気になれず。

あと、セキュリティーを通ると、

その先にはろくにご飯が食べられる場所がない。

ちょっと想定外。

結局その日は晩ご飯を食べ損ないましたとさ。

札幌へ行ってきた -1-

2010-09-18T23:06:00.010+09:00

出張です。札幌まで行ってきました。初北海道です。ヒャッホ～～～

行きはAirDoとの共同運航便です。

すでに遅れが確定しています orz

着きました。

あ、いえ。この機体に乗ったのではありません。

でも見てください。飛行機から降りたら、いきなり地平線攻撃です。
つーか、着陸段階で外を見ると、まーーーーーーーーっすぐな道路がゴロゴロと。鉄道もまーーーーーーっすぐ。

うおーーー、どこのオレゴン州じゃ

と思いましたよ。

おっと。証拠、証拠。

新千歳空港から、札幌駅までの切符です。

で、札幌駅を降りて北口から出たら、これです。札幌、恐るべし。
もしかして、お笑いの街として大阪と覇を争うつもりか?!

お仕事終了。
翼よ、これがすすきのの灯だ。
とりあえず、お仕事先の方に一席設けていただきました。

ありがとうございました。

北海道、旨すぎです。

素晴らしすぐる。秋葉原と神保町を北海道に移植することを、真剣に考えるべきだな、これは。

そう。国連事業として。

とにかくそのようにして、17日は過ぎていったのでした…。正確には18日にかかってましたが。

新人じゃなくなった人は何を気にするべきか -8- まとめ

2010-08-01T02:20:00.003+09:00

というわけで、まとめ。

ようするに、新人じゃなくなっても意識しなくちゃいけないことが CS と AT であることに変わりはない。

ただ、より幅広い範囲に渡る権限を持ち、その分収益に対しても部下に対しても責任を持たなくちゃいけないので Customer Satisfaction 側がよりヘビーになる。しかもその中から利益を得なくちゃいけない。

利益は売上からコストを引いたもの。なのでコストが増大する組織拡大は極力抑えなくちゃいけない。そのためには Automation が大事になる。逆にいうと Automation として何が出来るのか、先に手持ちの武器を確認しなくちゃいけない。また、組織を運営する場合も、その人達がほうっておくと何をしでかすのかをきちんと見抜かなくちゃいけない。ルールを多用した運用はほぼ確実に監視のためのコストが莫大になり失敗する。可能な限り司法と行政の等価交換則を利用して、放っておいても目的通りになる、ことを目指さなくちゃいけない。

売上を上げるには、人間が持つ限定合理性から来る壁をいくつも突破しなくちゃいけない。取引コスト、プリンシパル・エージェント問題の2つをちゃんとおさえなくちゃいけない。

また、組織を運営する上でどうしても発生する問題については、所有権問題をちゃんと意識しなくちゃいけない。

最後にターゲットとするべきマーケットは上質/手軽さのどちらにするのか、I18NとL10Nのどちらにフォーカスするのか、これが重要になる。どちらにフォーカスを当ててもよいが、徹底するのが重要になる。中間には何も無い。

まーね。

言うは易しなのはその通りだけどね

でも、この程度すら

ほとんどの人は知らない

そしてこの程度で解決することすら

解決できないでいるんだから

新人じゃなくなった人は何を気にするべきか -7- I18N/L10N

2010-07-10T22:04:00.013+09:00

I18N: Internationalization (国際化)

L10N: Localization (地域化)

グローバライゼーション(Globalization/G11N) が叫ばれて久しい。世界は平らだとかいう本も出てるよね。

でも、本当にそうなんだろうか? 日本の市場と、韓国の市場と、アメリカの市場と、ポルトガルの市場と、ロシアの市場と、南アフリカの市場は同じ性質を持っていて、単にお金持ち度が違うだけなんだろうか?

言葉の違いもある。うん、それもあるよね。でもそれだけ? もっと根本的に 同じに扱っちゃ駄目 なポイントがあったりしないだろうか。

「もちろんあるとも。それについて書かれた本も」

そう。国や地方ごとに条件は違う。食生活が違うのに冷蔵庫に求める機能が同じなわけがない。

例えば日本とアメリカでは、製品に対する品質要求がぜんぜん違う。

アメリカでは、製品が壊れるのは大きな問題ではない。製品が壊れたときに直せないのが問題だ。ものを買った場所から自宅までの距離は、時には車で2時間以上もかかる(それも100miles/hour=161km/hourで)。壊れたときに修理にだしてから直って帰ってくるまでの時間も長いし、その間の代替物がない事が問題だ。だから、壊れたことそのものよりも、すぐ直せないことを問題視する。自分で直せるなら、あるいはリセットボタンを押せばそれで済むなら、問題ではないのだ。

逆に日本では、製品が壊れることを問題視する。
一つには大昔、アメリカで「日本製」が「安かろう=悪かろう」の代名詞としてさんざん叩かれた頃のトラウマが未だに残っている事があげられる。日本製品を日本に送り返して直していたのでは、数日では直らない。かといって日本製品を普通のアメリカ人が大雑把に叩けば、トドメを刺すだけだ。だから、日本製の壊れる = それっきりを意味したのだ。だから壊れるのは悪。
もうひとつは、日本という国の地理的な条件がある。日本は古典的に「街の電気屋さん」のように住んでいる場所に密着した形で小売店が存在する。何かが故障した場合、修理はもちろん、取替え、修理から返ってくるまでの間のスペアの手配等、全てこの「密着した小売店」が何とかしてくれる。だから、修理して再び使えるようになるのは当たり前。ただし、この「密着した小売店」がサポートのために支払わなくてはいけないコストがバカにならない。小さなエリアで小規模でしか売れないのに、売った後に高いコストを払わされるのではたまったものではない。だから壊れちゃいけない。

だから、大きく見ると世界中どこでも売れるように感じる商品も、その地域に持って行ってみるとニーズが微妙に違う。それぞれに合わせた作り込みをしないと、その地域で同じようなものを作り、売っているメーカーに勝てない。すると、グローバライゼーションはコストがかかるばかりで、全然売上に貢献してくれない。ゲマワットさんの本には「商品の売上はHQからの距離に反比例する」例をあげているぐらいだ。

でも、全部が全部そうじゃない。例えば Intel の CPU。世界中どこに行っても同じものだよね。アフリカ版と日本版とアメリカ版で消費電力が違ったり、演算能力が違ったりはしない。こういうパーツ…とくにすでにデファクト・スタンダード化が済んでいる製品は世界中どこへ行っても同じだ。

でもデスクトップPCになると日本やアジアでは小さめのデスクトップの売れ行きが良い。アメリカではタワーと呼ばれるデカいやつの方が売れてる。ノートPCも、アジアではキーの小さい奴が売れるが、アメリカではキーの小さい奴はあまり売れない。ところが、たまに例外もあって、ネットブックはどこでも売れた。ただし、OSはアメリカだとLinuxでよかったのが、日本では Windows を入れなくちゃいけなかった。

この違いはどこから来るんだろう? どうやって回避すればいいんだろう?

多分、同じことは「地方」単位でもあるはずだ。北海道と沖縄ではニーズが違うだろう。愛媛と新潟も違うはずだ。山形と東京だって違うだろう。逆に東京と神奈川、千葉辺りはニーズが似ているに違いない。
アイダホ州とニューヨーク州は違うニーズを持っているだろう。ニュージャージー州とカリフォルニア州も違うに違いない。ニューメキシコ州のように暑い所と、アラスカ州のように寒いところも違う。
どうやってそれぞれに合わせればいい? それには何を気にしてデザインすればいい??

Customer Satisfaction に関する最後の項目は I18N/L10N だ。

ただし、ここでいう I18N/L10N は単に「国単位」とか「文化単位」に限定しない。究極的には「個人単位」とか「購買する度」で微妙に変化するニーズや、それに対応する事を意識する、という話。

これは Focus の話だ。ただし、Focus は「一人のお客様に対して」の話だった。

これが Focus の話と判れば、同じ　と分類されるものであっても、世界中の地域ごとにエンドユーザーのニーズは微妙に異なることも判るだろう。このため、完全に1種類だけの製品を作って、それを世界中に販売展開すれば全顧客のニーズを満足できる…とした Globalization は幻想に過ぎない。

この問題を回避する最終的な戦略はただ1つ。Internationalization (I18N) / Localization (L10N) を組み合わせる以外、手はない。ようするに製品の大枠を I18N で定め、最終的な地域単位/顧客単位でのチューニングを L10N で行う。

L10Nの範囲が本当の意味で「地域」なのか、「個別顧客」なのか?
どれぐらいをI18Nで共通化し、どのぐらいを L10N で個別対応にするのか?
どこを I18Nで共通化するのか? (部品なのか、材料なのか、それとも加工技術/ノウハウ/職人の技と言われるものなのか?) どこを L10Nにするのか? (組み立てた製品なのか、皮から切りだして製品を作る部分なのか、オーダーメイドなのか)

これらを組み合わせ、コスト/商品価格と顧客満足のバランスするポイントを見つける。これは Focus がどこにあったお客様がどれぐらいの数存在するのか、という問題だ。Focus の逆問題だね。

I18Nの部分を大きく取り、L10Nの部分を小さく取る。部品以上のものを提供しない。世界中で同じものを売る…という戦略で成功している好例が Intel の CPU x86 シリーズだろう。世界中どこでも同じ製品しか供給しないが、それが許されるのは「部品」だからだ。国ごとに好みの色をパッケージングに塗る、なんぞというサービスは一切しない。そのようなエンドユーザーの好みに合わせたチューニングは、CPUを利用した製品を作る側の自由であり、チューニングに伴うリスクテイクも、それによる利益幅の増大も、CPUを使って最終製品を作る側の問題だ。Intelはあくまでも部品を提供する所に留まることで、スケールメリットを得る。

逆に I18N の部分はほぼ外部から部品を買取り、L10Nだけで勝負する方法もある。これはサービス業の多くがそうだ。オーダーメイドのスーツを売る店は、布地まで自前で作ったりはしない。あくまでもそれをどう裁断するか、どう縫い合わせるかを、顧客のニーズ単位で実装することで高い満足を売っている。

喫茶店もそうだな。顧客の細かい要求(もしあれば、だが)に答えたものを提供し、時間と空間を提供することで、高い満足を売っている。同じようなパターンに床屋も入れられるだろう。

L10Nが高いものは、地域密着性が高い。たとえばあなたが東京都に住んでいるとして、沖縄の床屋が1000円だとしてもわざわざ髪を切りに沖縄に行く人はそうそう多くはないだろう。でもQBハウスのように1000円でカットしてくれる床屋ならば行くかもしれない。移動コストのようにサービスを受けるまでの潜在コストが高い場合、市場サイズがグローバルにならない。その場合、その狭い地域にチューンしたサービスが競争基準になる。時にはそれがとんでもないガラパゴスなサービスへと進化してしまう場合もある。

別の言い方をしよう。もしあなたが売れる商品を作りたいと思ったら、世界中向けには「部品」を作るのがよい、ということだ。例えば冷蔵庫について考えているなら、ヒートポンプとか断熱材とか。で、各地域でその部品を組み立てて、その地域のニーズに合致した冷蔵庫に仕立て上げる。

「部品」と言うと語弊があるかもしれないな。たとえば車。車は世界中どこへ売る場合でも「ほとんど」違わない。ただし、右ハンドル・左ハンドルのようにオプションが変更できる。販売国の法律に合わせてハンドルをどちら側につけるのかはカスタマイズ可能なわけだ。この場合 L10N のために部品を交換しているだけで車としてはほとんど完成品なのだが、こういう場合も「部品」と考えよう。

実際、車は想像以上に多くのカスタマイズポイントを持っている。例えばウィンドウウォッシャー液。日本ではウォッシャー液のメーターなんか運転席についてない。ところがアメリカにはある。日本は法定点検がやかましいので、定期的に販売店や車検屋にチェックをお願いする。するとウォッシャー液とかはちゃんと補充してくれる。アメリカはそんなものはないので「空になったらユーザーが補充する」事になる。が、ウォッシャー液なんてめったに気にしない。このため、運転席にはウォッシャー液のメーターがあるのだ。

例えば…そうだな。Storageとか。この場合国によって何が監視できるべきか、どうなったらどう報告するべきか、違う。例えばアメリカで多いのは、HDD を Active の他にスペア Standby を用意して、Standby に切り替わったら、その次の定例メンテナンスの時に新しくパーツを補充する。

しかし日本だと

「Standby がもうないぞ、どうしてくれるんだ、早くパーツを補充しろ、壊れた原因をさぐれっ」

と大騒ぎになる。いや、HDDは壊れるもんですってば。こういう客が多いので、日本の場合は、Active/Standby/Standby 構成にするのがよい。で、Active が壊れたら Standby1号に切り替える。で次の定例でパーツ補充するが、Standby2号がまだいるのでお客様も騒がない、と言うわけ。こういう多重 Standby ができる構造にできるよう、柔軟なカスタマイズが出来るようにできるべきなのだ。I18Nの段階ではこのように、国ごとのお客様特徴に適用できるようにカスタマイズしやすく作っておく。で、各国で L10N を施すときに、きっちり作り込む。

こう考えると判るだろうが、I18N 用の開発部隊の他に、L10N 用の開発部隊を各国に用意するべきなのだ…いや、「国」単位じゃなく「文化」単位で構わないが。逆に言うと「文化」単位での開発部隊を持たないメーカーというのは I18N ではなく G11N と称して、どこか一国(たいていはアメリカとかヨーロッパ)にチューンしてしまっているため、他の国に売るのはいいがその後、その国のサポート部隊が悲鳴をあげることになる。こういうメーカーやベンダーの製品は避けたほうが無難だ。

「上質」と「手軽さ」という分類の仕方もある。これはケビン・メイニーが「トレードオフ」という本の中で紹介している分類の仕方だ。

上質であるとは、お客様一人ひとりに対するチューニングのレベルが高く、快適さが高い。値段も高いがそれでもこの商品を選ぶ、という事自体が一種のステータスにつながる(「トレードオフ」ではこれを「オーラ」と呼んでいる。ブランド力の一種だ)。L10Nの割合が高く、その分お客様ひとりひとりのニーズにきっちり合わせることができる。

この場合 L10N として提供している商品そのものが、買ったお客様のキャラクター(なにに強いのか)を宣伝している。技術力が高い(iPadとか iPhoneとか)、選美眼が高い(ティファニー)、品質に拘る(グッチ)…そしてもちろん、これらに共通して「金持ち」というのもある。お客様はそれらを使うことで、自分のアイデンティティを宣伝しても居るわけだ。

一方手軽であるとは、お客様ひとりひとりに対するチューニングは殆ど行わない。商品がお客様に合わせるのではない。お客様が商品に合わせるのだ。あるいは、「商品をお客様に合わせるための商品」というものが別にあって、値段が高いほど利便性が高くなる。しかし、その商品が提供する機能は便利すぎて、それがなかった世界など考えられない。電子レンジ、冷蔵庫、ガスコンロ、室内照明、携帯電話、鍋、テレビ、ラジオ、インターネット、Windows、マクドナルド…どれ一つとしてあなたのために造られ、あなた用にチューンされたものは存在しないが、これらなしの生活はもはや考えられない。

このような商品は I18N の部分がその商品の性質のほとんどを決定する。L10N の部分…電源を100Vにするか120Vにするか220Vに対応させるか…表示する文字を日本語にするか英語にするか韓国語にするか…などの部分は確かに違いとして存在するし、そこに掛かっているコストは決して安くはないかもしれないが、そこに高い付加価値を見出してくれるお客様はほとんどいない。Windows7 の英語版と日本語版では明らかに日本語版の方がメッセージ等の翻訳コストがかかっているが、だからといって日本語版の方が20%高い値段で売っている…などとなったら、日本の顧客は買ってくれないだろう。これは、Windows7が「手軽さ」を…ひいては「どこにでもある」事を目標として作られた商品であることを示している。ビル・ゲイツが立てた Microsoft の目標「PC everywhere, MS product everywhere」は変わっていないのだ。

ケビン・メイニーによると、「上質」と「手軽さ」は相反する性質を持つという。「上質」という性質は「選民性をもつ」という意味でもある。「手軽さ」は「選民性を持たない」という意味だ。誰でも手に入れられるものは、それを使っていても「使っている人のアイデンティティ」など宣伝してくれない。故に「手軽さ」と「上質さ」を同時に目指そうとするとどちらつかずになり、「上質」を選ぶ人からは捨てられ、「手軽さ」を選ぶ人からは「高すぎる」とそっぽを向かれる。スターバックスがまさにその状態に陥った。ティファニーもそれに近い状態に陥り、慌てて戦略を変更している(だからティファニーのネックレスを持っているティーンエイジャーはもういないでしょう?)。

しかし、多くの企業がここを間違える。それは(AOL元副社長の)テッド・レオンシスが表現したように、「上質」と「手軽さ」を「愛される」と「必要とされる」のように表現を置き換えて理解してしまうからだ。確かに「上質」なものは「愛される」と表現するしか無いぐらい、お客様から多くのリソースを投資してもらえる。「手軽」なものは「必要とされる」と表現するしか無いぐらい、誰も彼もが入手する。しかし、「愛されて・必要とされる」という表現だと存在し得るように聞こえる商品は、実際には「上質でもなく、手軽でもない」というどっちつかずに成り下がる。

だから「上質」を選ぶなら「上質を突き詰める」べきだ、とケビン・メイニーは言う。逆に「手軽さ」を選ぶなら、「手軽さを突き詰める」べきだと。そのどちらかを行えば、ライバルを遥か彼方に引き離すことができ、その市場を席巻することができる。

逆に、市場が「上質」か「手軽さ」のどちらかに偏っている場合、もう一方側に大きな市場が眠っている、ともケビン・メイニーは言う。

たとえば大学。大学は単にモノを教える場ではない。大学の生活、友人との連帯感、大学祭、試験やレポートの地獄…これら全体で「上質な体験」(もちろん、この場合は「快適な」という意味ではない)を与える事にフォーカスしている。

これに対する「手軽さ」のマーケットはまだほとんど開拓されていない、という。うーん、本とかがそれに相当するんじゃないか、という気がするが…。でも、確かにそのような専門書は本質的に入手が難しいし、パッと開いても普通の書物とのギャップが酷過ぎる。もっと分量があって、その代わりもっと判りやすい解説書があってしかるべきだろう。

…ようするに I18N と L10N はどちらを優先するべき、というものはない、ということだ。

ただし、一方に徹底しろ、中途半端が一番良くない。お客様は I18N に偏った端と、L10N に偏った端にいる。真ん中にはだれもいないぞ、と。

あなたの会社は、あなたの部署は、この事を意識しているだろうか?

商品開発の段階では I18N を徹底しており「手軽さ」の境地に居るはずの商品なのに、実際には品質が低くサポートへの負担が高く L10N でヒーコラとカバーしてたりしないだろうか?

あるいは L10N を徹底して「上質」が売りなのに、自由度が低くてお客様からみると I18N の極みのような商品で、なおかつ値段だけは高かったりしないだろうか?

逆の視点から見てみよう。

よく「グループ企業内コンサルテーション」というものをやりたがる人達がいる。例えば Linux に関する知識をグループ企業内で共有して、全体のコストダウンとスキルアップを図る、なんて奴だ。一見素晴らしいお題目に見える。でも I18N と L10N の視点からすれば、これほど駄目な発想もない。実際、大抵の場合、この手の目論見は大失敗する。「失敗じゃない」と言い張る連中は大勢いるが、誰がどう見ても失敗、と言う状態に陥るのだ。

「グループ企業内」ということは、コスト的には最低限で済ませたい、という意識がありありとある。でも、じゃぁ、グループ企業内部で欠落しているのは「グループ内部で共通している部分」だけだろうか? 誰もが知っていなくちゃいけない部分すら知らない奴が、どうしてその先にある「自分たちのお客様のための L10N サービスのために別途知らなくちゃいけない知識」を持っていると??

結果としてこのようなコンサルテーションを利用する人達は「コストは I18N クラスで、要望は L10N の極みを」という無茶苦茶な事を言うことになる…というかそういう事を言ってテンとして恥じない連中、別の言い方をすると「グループ会社全体としてのコスト意識」が欠落した「自分だけよければ後は野となれ山となれ」的な発想しかしない連中ばかりがたかってくるのだ。そう「新人じゃなくなった人は何を気にするべきか -5.2- エージェンシー」で説明した「モラル・ハザード」と「逆淘汰」の世界に突入する。

グループ企業内のコンサルタントを行ないたいならば、まず I18N にフォーカスするのか、L10N にフォーカスするのかを決めるべきだ。

手軽なものならば「コンサルタント」ではなく「情報提供」に徹する。情報をまとめてイントラネットの Web に掲載し、検索エンジンを立てて検索しやすくする。さらに社内の別の検索エンジンと協力して「相互に」検索できるようにする事で誰からも発見されやすくする。しかし「問い合わせ」のような個別案件には一切かかわらない。その代わり固定費だけで抑える。

上質なものにするならば「コンサルタント」でいいだろう。ただし、要求するコストは社外コンサルタントと同じかそれ以上のコストにするべきだ。値段が高い分は「社内の、より信頼できるリソース」という付加価値を主張する。その上でその顧客専用に Focus を当てた対応をするのだ。L10N の極みを提供する。

このどちらかだけが正解で、その間の中途半端なところには、客が居ないか、売上が伸びるほど赤字になる地獄か、どちらかしか存在しない。

上質を極めようとすると、どうしても人手がかかる。このまま巨大になろうとすると、「-3- Scalable Organization」で述べたように組織を維持するためのコストが増大し、破綻してしまう。だから

上質を極めたければ

絶対客数を増やしちゃ駄目だ

同じお客様になんどもリピートしてもらうようにし、そのお客様のあらゆるニーズをカバーするようになるのはよいが、お客様の絶対数を増やそうと考えてはいけない。

手軽さを極めようとするなら、

お客様の絶対数がいくら増えても

組織が大きくしない

方法をを考えなくちゃいけない。あらゆる自動化を駆使して、お客様一人当たりのコストを下げることを考えつづけなくちゃいけない。

最後に。この手の状態にあると必ずクレーマーが一定の割合で発生する。手軽さを極めようとしているのに上質を求めたり、上質を極めようとしているのに手軽さを求めたり。

そういう客は切れっ!

情け容赦なく、切り捨てろっっ!!

大丈夫。問題はない。

手軽さを極めようとしているなら、お客様は他に大勢いるはずだ。そしてそれらのお客様は「手軽さ」を気に入っているのだ。何千人ものお客様の中から一人減ったところでそもそも利益幅が薄いのだからほとんど影響はない。むしろその客を特別扱いしているのを見せつけられ、不快感を感じたために二度とこなくなる「大勢」が発生する方がよほど被害が大きい。

上質を極めようとしている店で値切るような客は、その店の品位を下げる。製品がまとっているオーラを曇らせる。下品な客が製品を使ったためにくすんでしまったオーラを復活させるのは至難の業だ。

判ると思うがこのようなクレーマーは大抵「上質と手軽さの中間点」にあなたを追い込もうとする圧力の一つだ。この一点を考えただけでも、クレーマーは切捨てるべきだ、と判るだろう。

クレーマーは客じゃない

これは、他のなによりも Focus から演繹される話なのだ。

新人じゃなくなった人は何を気にするべきか -6- Announcement

2010-05-23T01:54:00.007+09:00

さて。次は Announcement についての話だ。

…え? 所有権問題はどこへ行ったかって?

うむ。実は Announcement は所有権問題を解決するために必要なのだ。

そもそも、Annoucement というのは Communication の特殊ケースである。Communicationが双方向通信なら Annoucementは単方向通信。

会社の偉い人が

「これからわが社はこれこれ、こうするぞーーーー」

と社内に宣言するのも Announcement なら、社外に向けて

「新商品 wxy 新登場!! 従来にない操作感と、やまだかつてない噛み心地をあなたにっ!!」

と宣伝するのも Announcement だ(…操作感と噛み心地がありえる商品が何なのか、に関しては聞かれても答えるつもりはないのでそのつもりで…なんだろうなぁ)。

「運は天にあり。鎧は胸にあり。手柄は足にあり」

という上杉謙信の名台詞をご存知な方もいるだろう。あれも Announcement だ。

しかし、会社においてもっとも重要な Annoucement は、そしてその重要性が軽ろんじられており、故に大抵の無能な上司がやらない Annoucement は、こういう形式のものだ:

「この度、xxxxというプロジェクトを新規に立ち上げることになった。

このプロジェクトの存在意義はこれこれこういうことだ。

プロジェクトの責任者として yyyy 君を任命した。

いろいろあるだろうが、どうか皆、yyyy君を支援して欲しい。よろしく頼む」

さて。なぜこの Announcement はそんなに重要なのか? 無能な上司が…特に取引コストについても、エージェンシー問題についても、丸っきり理解していないことを態度で示している無能な輩が… Announcement についても間違っている、となるその限定合理性が示している問題とは何か?　これを理解してもらうために、ここからしばらく、「所有権問題」について説明しよう。

所有権問題は、すでに述べたように限定合理性に伴って発生する3種類の問題の1つだ。

前の二つはそれぞれこう：

取引コスト問題:: 取引する人全員が同じように影響を受ける問題。ようするに取引をする人達同士の間で対称形になっている。
エージェンシー問題:: 取引をする人達が非対称形になっている。

なら、最後の1パターンは? もちろん

所有権問題：: 取引をするはずの片方が居ない/所有していることを意識していない/全員が所有者で意思決定ができない

たとえば、大気汚染を考えてみよう。ある企業が有害物質を大気中にまき散らした。そのために大気汚染が起こった。人間は皆、空気がないと生きていけないし、汚れた空気だと健康を害する。だから怒る。

…でも待って。じゃぁ、この企業はどうすればよかったと? 誰に許可を貰えば有害物質をまき散らしても良くなるのだろう? あるいは

「それは有害物質だから撒き散らしちゃ駄目」(有害物質だと判っていたとして)

と不許可を言明できる 大気の持ち主 って誰だろう??

我々は皆、空気を吸っているよね。正確には酸素を吸い込んで二酸化炭素とかを吐き出している。他にもアンモニア等、微量成分を色々吐き出していて、ある意味我々は全員大気汚染をしているとも言える。これは誰が許しているの?

体が大きい人は、体が小さい人よりも大気の汚染量が大きいよね? それは許してる(誰が許しているんだか知らないが)。企業は ものすごく体が大きい人 と同じ扱いをされちゃいけないの??

現実問題として、多くの人は自動車に乗ったりバイクに乗ったりしているよね。これも大気汚染を引き起こすよね? 光化学スモッグなんか典型的に自動車の排気ガスが主原因だと判ってる。これが OK なのはなぜ??

なんとなくみんなのものだと思っているが、いざ特別な使い方をしようとすると、誰に許可を得たらいいのか判らない。逆にどこまでが特別な使い方なのかもよく判らない。決定権を持っている人が居ない。所有権を持っているのだかもっていないんだかよく判らない。そういうものについて、何かしようとすると、一種のデッドロック状態が発生して話が前に進まなくなる。これが所有権問題。古典的には「共有地問題」として知られていた。

みんなの財産。共有財産。でも、それは誰のものでもない。だから誰かがその財産を枯渇するまで消費してしまっても気がつかない。止められない。それ以前にそれは止めていいことなのか?止める権利があることなのか?

「必要な者が必要なだけ消費する」

というルールは共有財産自身が自動で生産する能力の範囲内であればうまくいく。でも共有財産自身の生産能力を上回ったら破綻する。

逆もある。たとえば里山問題。

大昔、人は田んぼと同じ面積だけ里山を必要としていた。里山は人が手入れをする。木の実だのなんだのも手に入るが、一番大事な生産物は里山から得られる有機肥料。これを田んぼにまく事で生産性を上げていた。

でも化学肥料の発達のおかげで、里山は要らなくなった。誰もメンテナンスしなくなったので、里山は荒廃し、もはや昔のような有機肥料などの生産能力も失われた。保水力もなくなり、洪水の遠因にもなっている。

人が共同で管理しているからうまく動いていたシステム。誰も管理しなくなったら壊れてしまった…里山は誰のもの? 誰が管理「する義務があった」の? サボったのは誰??

このように、「そこにあるが、誰のものでもない。でも全員のものである」ようなリソース。そのようなものに対する、消費権利、管理コスト支払い義務は、かなり難しい解決不能な問題だ。何しろ調停するべき片方がいないのだから。

実は、この所有権問題。リソースだけが対象じゃない。問題も所有権問題の対象になり得るのだ。

は？何言ってんの

在日米軍基地問題とかを考えてみて欲しい。

「負担を沖縄にばかり求めるのはよくない」
うん。皆これには賛成するよね。
「じゃ、申し訳ないけど、あなたの家の隣に米軍基地が越してきます。騒音とか排気とかひどいことになるけど、許してね」
まてぇええええええっっ!!! そんなことを OK した覚えはないっっ!!!
「だって『負担を沖縄にばかり求めるな』っていうのに賛成したじゃん」
同じぐらい、俺にばかり求めるな、というのにも賛成するわいっっ!!!

米軍基地移設問題が何時まで経っても解決しないのは、この「総論賛成・各論反対」のせいだ。

総論賛成

各論反対

これも所有権問題なのだ。もうちょっと別の言い方をすると

それは全員の問題である
私だけの問題ではない

故に、全員で均等に発生する負担には従うが
私に集中的に負担が発生するのは許容しない

これはようするに、「問題の所有者が不明瞭」なために、全員がその問題の所有者であることを放棄し、その問題に対して他の人よりも多くの負担を求められることを拒否するがゆえに、問題解決が前に進まなくなる。デッドロックする。

会社のような組織において、問題点がどこにあるのかを探すのは簡単だ。また、それが問題であることを経営陣に納得させるのも比較的簡単だ。しかし、解決しようとすると突如として難しくなる。俗に「関係各位」と言われる連中から、大量の横槍が入るのだ。

「コスト削減が必要です」
うん、そうだそうだ。うちの会社は売上に対して利益率が低すぎる。

「コストの内訳を調査したところ、開発部が使っているPCの台数が多すぎることが判りました。
一人当たり3台ある計算になります。これを一人2台に減らしましょう。
電気代も節約できますし、中古品を売れば現金になります。」
いや待て。うちの部隊はそもそも開発をやっていてだな。計算機が3台無いとまわらんのだ。1台はOA用に必要で、これはIT部隊が要求するようなソフトを入れ、それ以外を入れない、と言う状態にしてある。もう一台は開発用で、最後の1台がビルド・テスト用だ。ビルドやテストの最中はCPUやメモリを大量に消費するので、開発マシンと一体化することはできん。すると最低限でも3台は必要なのだ。

「じゃぁ、ITのルールを緩めれば2台で済むんですね? では　ITさん、ルールを緩めてください」
いや、それじゃセキュリティ上危険じゃないか。開発用マシンにはその目的上、クラッキングにも使えるツールが満載だろう? もしそのマシンを乗っ取られたら、会社のシステム全体を乗っ取るための道具をクラッカーに提供しているようなもんじゃないか。
もし、そんな事になったら誰が責任をとってくれるんだね?!

いやいや、そもそも、そこまで侵入された段階でお前のせいに決まってるだろうが。ツールが有るかどうかの問題じゃないし、内部のマシンのありようなんか関係なかろう。

何を言うんですか。うちのネットワークセキュリティは外部からの攻撃に対しては万全です。唯一の例外は、社内の人間が愚かにも釣りページに引っかかって、余計なツールをインストールした場合だけですよ。こうなると内側から内側を攻撃している状態になりますからね。さすがに我々が手を下すより早く、攻撃が完了してしまう。だから、余計なツールなんぞ入れずに、我々が許可したものだけを使っていてくれるのが一番安全なんだよ。

何が安全だ。安全に餓死するのと、病気覚悟でメシを食うのとで、お前は餓死することを選ぶのかっ!!

「…わかった。わかりました。とりあえず、開発部のマシンが3台ある件については後回しにします」
(やれやれ、これでどうやってコストダウンしろって言うんだ…)

こんな状態は、どこの会社でも、しょっちゅうなんじゃないかと思う。

どの部署も、誰もが、自分たちが使っているものを使い続けること、自分たちが欲しいものについての正当化はすでに出来ているのだ。そのためのコストは妥当だ、と思っている。だからコストダウンは当然やらなくてはいけないだろうが、それはうちの部署じゃない。あるいはうちの部署でも構わないが、正当性の前提である鬱陶しい拘束条件をたたき潰してくれ、という事になる。

いや、実際には上記の例はとても平和な例だ。実際にはこう言われることがほとんどだ。

お前はなんの権利があって、

うちの部署の予算の使い方に
文句をつけるんだ?!

Announcementをろくに行わない上司の元で、何かをやろうとした場合に必ず直面するのは、この形式の抵抗だ。

お前は俺の領分を侵しているぞ

お前の問題提起は正しいかもしれんが

俺の領分を侵犯せずに問題解決しろ

しかし、無能な上司の方はこう考えている。

お前にやれと俺が言ったんだから

やれないのはお前が無能な証拠だ

待てやボケナス。

「お前が俺にやれといった」事を示す

証拠はどこにある?!

その証拠なしに、

既得権を主張している奴らを

説得できるわけがなかろう?!

Announcement が重要な理由はこの一点につきる。有能な上司は、部下に仕事を割り振るときに、必ず Announcement をかけるが、そこには

私が仕事を割り振ったのだ
問題提起があり、私はそれを問題と考えた
解決のために権限委譲をした。yyyyが担当だ。この件に関しての権限は私が承認した
故に、yyyyから「これこれこういうふうに問題がある」と言われたら、お前はそれを直せ。
このその部分問題に関する限り、それはお前の問題だ。所有者不明ではない。
私はこの問題が早急に解決されることを望んでいる。もし十分に納得のいく意見なくyyyyの要求を蹴飛ばす事は俺が許さん

と、これだけのメッセージが含まれている。これによって所有権問題を解決しておかなくては、yyyy君は問題を解決できない。yyyy君自身にはあなたとおなじ特権は、デフォルトでは与えられていないのだ。

逆に Announcement を利用して所有権問題を解決しない上司というのは、いつまでたっても問題が解決しない、いつの間にか解決活動自体がフェードアウトしている…という経験をし続けることになる。

「うちの会社には実行力がない。全くもってけしからん」

それはあなたの部下が無能なのではない。所有権問題を最初に解決しない

あなたが無能なのだ

優秀な上司は Announcement を最初に行い、最後に行う。所有権問題解決のために最初に行い、真に解決したい問題が解決されたことをアナウンスして特権を解除するためにもう一度 Announcement を行うのだ。

新人じゃなくなった人は何を気にするべきか -5.2- エージェンシー

2010-04-10T03:37:00.008+09:00

取引コストは、誰にでも存在するコストだった。構造的には対称形をしている。と言うことは、次からは当然非対称な状態についての話になる。

エージェンシー理論では、取引をする2者は非対称になる。一方をプリンシパル(依頼人)、もう一方をエージェンシー(代理人)と呼ぶ。

エージェンシー理論においては、プリンシパルは何かをしたいのだが、自分ではできない。そこでエージェンシーを立てて自分の財産の一部操作する権利をエージェンシーに渡す。エージェンシーはその権利を利用してプリンシパルの目的を達成し、同時に自分でも利益を得る。これが理想的な状態。

プリンシパルは限定合理的なので、エージェンシーについて完璧な情報を得ることはできない。さらに、エージェンシーを常に監視し続けるととても高いコストを払うことになる。もちろん、プリンシパルとエージェンシーの利害が完璧に合致することはありえない。プリンシパルを裏切るとエージェンシーの儲けが増えるなら、エージェンシーは情け容赦なくプリンシパルを裏切るだろう。

また、プリンシパルがあるエージェンシーを雇うのは、そもそもがそのエージェンシーの方がプリンシパルの目的達成に関しての知識があるからだ。と言うことは、プリンシパルにはエージェンシーが秘匿している情報を知るには高いコストが必要になる。

このような条件下で、どのような問題が発生しうるのか、どのようにすれば問題の発生を抑えられるのか、というのがエージェンシー理論。

ぱっと考えて判るように、これ、意外と適用範囲が広い。

株主と経営者
雇用者と被雇用者
規制当局と被規制者
内閣の大臣と各官庁の官僚

など、規制やサービスなどはもちろん対象になるが、実はこの理論が有名なのは「中古車販売」だったりする。「自分の欲しい車を探している購入者」と「中古車を中古車市場から探し出し、購入者に転売して利ざやを稼ぐ中古車販売業者」もプリンシパルとエージェンシーだ。

大雑把に2種類の問題が発生することが知られている。1つ目は「モラル・ハザード」。もう一つが「逆淘汰」だ。より単純なモラル・ハザードから見ていこう。

モラル・ハザード

モラル・ハザードは…そのまんまだ。情報的にはエージェンシーの方が多い。プリンシパルはエージェンシーを監視できない。プリンシパルの利害とエージェンシーの利害は合致していない。

ヒャッホー

俺(エージェンシー)の好きにさせてもらうぜっ!!

こうしてプリンシパルは裏切られ、プリンシパルの利益は最大化されない。最大化されないどころか、下手をすると食い物にされちゃう。これがモラル・ハザード。

モラルハザードはいろいろな場面で頻繁に起こる。

例えば銀行の預金保護。あなたが銀行に預けた預金は保護される。銀行が破産しても国が元本分は保証してくれるのだ。銀行が持っている借金分は破産によって(資産分を充当した後)棒引きされる。株式会社って奴だからだ。

結果として、銀行はあなたの預金をよりリスキーだが当たればでかい博打に投入することができる。

勝負に勝てば、利益は俺のもの

勝負に負ければ、損害は国のもの

これで大博打を打たない方がおかしい。

もちろん、実際には銀行がやって良い業務には膨大な規制が掛かっていた。そのため、ここまで悪辣な方策は打てなかったのだが…。

ベンチャーの投資も同じだ。ベンチャーが立てた企業目論見書を見て、ベンチャーキャピタルはカネを貸すことを決める。しかし、ベンチャーがその目論見書通りに働くという保証はない。勝てば自分の利益、負ければキャピタリストの損、という状態なので、特に上手くいかない状態が続いたベンチャーは最後の博打を派手に打ちたがる、という傾向がある。

似て非なるけれど、やはり似ているのが、サブプライムローン問題。リーマンショックに至る原因ですな。

アメリカのローンは、借りる側をクレジットスコアで評価している。信頼ができる客をプライム層、それよりも評価が劣る人達をサブ・プライム層と呼ぶ。

プライム層に金を貸してもほぼ確実に金は返ってくる。なのでこれらの人達にお金を貸しても余りリスクは高くない。リスクが高くないので、様々な側面で利率が低い状態でしかお金を貸せない。そこでハイリターンを狙うなら、ハイリスクなサブ・プライム層の借金をどうにかして、リスクを下げることは出来ないか?! という事になる。

で、サブ・プライムローン問題の場合、住宅ローン…つまり担保があることを利用しての借金…を狙うことになった。さらに、債権を全部ひとりで背負うと大変なので、これを小さな単位に分割する。で、さらに他のサブプライム・ローンの借金の一部と組み合わせて、一種のポートフォリオを作り上げ、それを証券として売り出す、と言うことを考えた人がいたわけ。

担保があるので取りはぐれる可能性は低い。また、複数の借金を組み合わせてポートフォリオ化しているので、一人の借金が焦げ付いても被害は簡単には甚大にはならない。そういう発想なわけだ。

え？これだといいように聞こえる？えぇ、実際、この場合のエージェンシー…つまり借金を証券化した人達…自身も自分たちが一種の詐欺を働いているとは気がつかなかった。

サブ・プライムローンの問題は、ようするに各借金並びに担保回収の可能性は一次独立である、とした仮定にある。ある一人の借金が焦げ付いても、別の人の借金は焦げ付かない。ある一人の借金の担保である家の価格が下がっても他の借金の担保である家の価格は下がらない。そういう仮定があったわけ。

でも、景気にはトレンドというものがある。景気が悪くなれば最初に首を切られるのは誰か?サブプライムにクラス分けされている人達はまさにその「最初に首を切られる可能性が高い人達」だからサブプライムにクラス分けされているわけで…で、その時に担保として取り上げた家の評価額は? そら下がってるわな。多少なら下がっても大丈夫だろうけれど、バブル経済は

バブルがはじけた時の評価額下落量が、

さらなる焦げ付きを発生させる程酷くなったら

バブルはハジケる

気がついたら、プリンシパルはとんでもない博打を打たされていた、という状態に陥る。

逆淘汰

プリンシパルは、エージェンシーの裏切りに耐えるしか無いのか? いや、そんなはずはあるまい。何らかの対策が打てるはずだ。そう考えた人は沢山いる。何よりも、そんなに裏切り行為ばかりだったら、そもそもほとんどのサービス市場は成立しないじゃないか。でも、多くの人は裏切り行為を経験することもなく、サービスを手に入れている。きっと、なにかあるんだよ…

最も簡単な対策は、エージェンシーからのアガリにリスク分を最初から含める、というものだ。

先程のサブプライムローンの場合を考えて欲しい。借金を必ず返せるだろうとされるプライム層と、借金が返せない可能性があるサブプライム層では、同額を借りても利率が違う。サブプライム層にカネを貸すと裏切られる可能性があるから、その分割高にすることでリスクを相殺しよう、という考え方だ。やれやれこれで一安心…だろうか?(つーか一安心なら逆淘汰なんて項は作らないよね)

一番有名な「一安心じゃなかった」例が レモン市場 と呼ばれる現象。特に中古車市場で起こったケースが有名だ。そう、実際問題は起こっている。

中古車を買ったことがある人はわかると思うけれど、中古車の品質を調べるのは大変だ。年数、走行距離程度じゃ車の品質はほとんど判らない。事故歴・故障履歴はもちろん、改造されている可能性だってあるわけだから。

もちろん、中古車を売る側…この場合のエージェンシー…はそれらの情報を全て持っている、と仮定しよう。中古車を買う側…この場合のプリンシパル…はエージェンシーの詐欺行為からどうやって身を守ればよいだろう？

容易に考えつく手の一つが、リスクに応じてプレミアムをつける、と言うやり方だ。ある中古車は30万円の価値がありそうだ。でも騙されているかもしれない。だから20万円までしか出さないぞ、というわけ。相手が正直であれば10万円分得をする。不誠実だったら20万円の損だが30万円の被害よりはましだ。

実際にこれをやると何が起こるだろう?

正直なエージェンシーが中古車を売りに出す場合を考えよう。実際には30万の価値がある。エージェンシーは30万円だと見積もっている。プリンシパルも30万円の価値があると考えたが、プレミアム分を引くので、プリンシパルは20万円しか出さない。結果、この良質な中古車は中古車市場に流通しない。

嘘つきなエージェンシーが中古車を売りに出す場合は？実際には10万円の価値しかない車を、30万円の価値があるかのように偽装してうりに出したとする。プリンシパルは20万円で勝負を挑む。エージェンシーは +10万円を濡れ手で粟で手にいれた。この場合この悪質な中古車は中古車市場で流通する。

プレミアムは悪質な車だけが流通する状態を作る。良質な車はプレミアム分の値下げに耐えられず市場から出て行く。こうして悪質なものばかりが流通する市場が出来上がってしまう。

このようにプリンシパルが目的とした結果と逆方向に市場全体が流れてしまう状態を 逆淘汰 と言う。

逆淘汰を防止するにはどうすればよいか? 実は解は見つかっていない。一見解になっていそうな解決策が致命的な弱点を持っていることが多々ある。

一般解としてよく言われるのが「インセンティブ」的な考え方だ。エージェンシー理論における諸問題は全て、エージェンシーとプリンシパルの利害関係が合致しないために起こる。なら合致させればいいじゃん、というわけ。

例えば営業。営業マンに会社の商品をより積極的に売ってもらうにはどうすればよいか？喫茶店やパチンコ屋で一日を過ごすのではなく、お客様を訪問し、ニーズを聞き出して商品を売り込んでもらうにはどうすればよいか? よくあるのがインセンティブ制の考え方だ。つまり売上の一部を営業マンの利益としよう、と言う考え方。これで、営業マンは働けば働くほど収益が増え、プリンシパルもエージェンシーも万々歳…一時期とても流行った考え方だ。今でもこの方式をとっている会社がほとんどだろう。

生憎、この方法は非常に悪質な営業マンを呼び寄せる。

インセンティブ制の弱点は、「売上」にしか注目していないことにある。商品を買った客は、自分が買ったものが自分が欲しかったものと合致しないと、企業に対する評価を下げる。消費財の場合下がった評価はもとに戻らない。耐久消費財の場合、サポート部隊がお客様の直面している問題を改善するべく活動し…結果、営業が不適切な商品を売ったことを発見する事が結構あるのだ。

売上は、契約が成立し売掛金を回収した段階で成立する。お客様に不適切な商品が売られたことが判明するのはその後のことだ。優秀で悪質な営業マンは、お客様のニーズに対して微妙に性能不足な…しかし価格的には安い商品を売り込む。複数のお客様に同時に売り込み、インセンティブを一気に稼ぎ、転職する。問題が発覚しても、その営業マンはもういない、会社に被害が残る、というわけだ。

似ているが、さらに問題がややこしい例として「社員持ち株制度」があげられる。社員自身が会社の株を持つことで、会社の業績と社員の収益の間に相関性を持たせることができる。会社の業績がアップすれば株価もアップし、配当も受け取れる。社員は会社の業績をアップさせるために精勤する事が、自身の利益へと直結する…

生憎これは最悪のシナリオを考えていない。

会社の業績に関連する、会社内部要因に社員の精勤率があるのは事実だ。しかし、同じぐらい、経営者の能力がモノを言う。経営者が馬鹿な指示を出し、社員がそれを精力的に実現しようとすると、会社の業績は急激に悪化する。悪化するためのシナリオを精力的に実現しているんだから当然だ。

会社の業績と精勤率の間に逆相関が現れた事は、社員が誰よりも早く気がつく。この瞬間から、社員の忠誠心が急速に失われて行く。持株の価値を下げまいとするためにサボタージュを行うものもいれば、損害を最小化するために持株を売り払おうとして市場に売り圧力を発生させ、さらに持株の価値を下げてしまう社員もでる。結果、事態は加速度的に悪化して行く。

社員の精勤率が下がった状態で、仮に経営者が過ちに気がつき、修正をかけようとしても誰も動いてくれない。そもそも、その「修正」を提示している経営者への信頼がすでに無くなっているのだ。一見正しそうに見えるからと言って、どうしてそれで事態がよくなると言える? それよりこのボロ船から取れるだけのものを取って、とっととおさらばしようぜ……

結果、修正は実行されることなく、事態はさらに悪化する。

経営的には正しいが、社員への負担を要求するような施策を経営者が出してきたとする。社員にはジレンマが生じる。株主としての社員はこの施策で利益を得る。社員としての社員は損害が出る。プラスマイナスを勘案するとどちらが大きいか? これは持株を多く持っている社員…大抵は古株の社員…程プラスに、新人ほどマイナスになるだろう。この施策は、会社の結束力を分断する結果を産んでしまう。

もっと困ったことも起こる。持株を多く持っている社員が自らの利益を最大化しようとすると、この会社に対しては純粋に株主であるのが最適になる。つまり古株の、多くのノウハウをもった社員が転職するきっかけを作ってしまうのだ。逆淘汰圧を社内にかけたのと同じ状態に陥る。

これらの問題を回避しようとすると、経営陣が打てる手として残っているのは非常に穏当なものしか無い、と言う状態に陥る。これでは急激な市場変化…リーマンショックによる世界同時不況とか…に対応出来ない会社になってしまう。これはこれで、プリンシパル(株主)の利益が阻害される…

実はエージェンシー理論が、通常の方法では解決出来ないのには理由がある。解決策として提示されているものが全て、価格ベースの解決策なのだ。

『Who is Customer』の所で示したように、市場において価格はゼロサムに為るように流通する。つまり、私と貴方が取引をした場合、そこを流れるモノやお金は取引前も、取引後も0になる。何も残らないし、何も残さない。取引によって取引をした人達双方の価値の総和は増える。しかし価格はゼロサムなのだ。

価格ベースの解決策は、会社が手に入れたお金の分配法則だけでプリンシパルとエージェンシーの利害を合致させようとする。しかし分配できるお金の総和は固定だ。そのため、プリンシパルの取り分が増えるとエージェンシーの取り分が減る、と言う状態が発生する。

会社が成長しているときは、それでも双方の取り分が増え続けるので、問題は発見されにくい。しかし、会社の成長がとまったり、何らかの理由で収益が減った場合、プリンシパルとエージェンシーは取り分をめぐって争いを始めることになってしまう。利害が一致する、とは利益が出ているときは良いが、被害が出ている時も一致してしまうのだ。

ここまで説明すれば自明だろうが、エージェンシー理論の真の解決策は 価値ベースの解決策 を見つけることでしか得られない。足して0にならないのは価値だけなのだ。プリンシパルからみて価値の低い、しかしエージェンシーから見て価値の高いものを取引材料に、プリンシパルから見て価値の高い、しかしエージェンシーから見て価値の低いものを引き出させる。この状態を作り上げて、エージェンシーが正直であるほどエージェンシー自身が得をするように、しかしそれによってプリンシパルが手持ちの資産の価値の総和を大幅に引下げなくても済むようにしなくてはいけない。

実際、世の中のプリンシパルはエージェンシーを選ぶ際に、単純に能力や価格だけで選抜しているわけではない。エージェンシーの持つ価値観を調べ上げ、その価値観に合致し、エージェンシーの資産価値が上昇するように報酬を設定することで、エージェンシーの忠誠心を引き出している。これがエージェンシー理論のような問題が、現実の世界ではなかなか発生しない…とくに個別の取引において発生しにくい…理由だ。逆にそのような状態が作りにくい中古車市場などでは、エージェンシー理論通りの問題が発生する。

優れた経営者は「価値観の共有」を唱えたり、逆に現場主義を唱えて自ら社内の状態を調べ社員の意見を聞き出そうとする。これは社員ひとりひとりの価値観を調査し、また価値観を会社のそれと合致させることで、会社と社員の利害を「価値観レベルで」合致させようとしているからだ。また、会社として社員へ報酬を与える場合に、単に金銭的なものだけではなく休暇や仕事上のチャンスを与えるという形をとるのも、価格という形ではなく価値のレベルでの報酬を最大化しようとするからだ。このために、優れた経営者は社内というマーケットの調査を怠らない。

逆に無能な経営者は、この社内というマーケットの調査を怠る。何よりも自分から進んで調査しようという発想がない。

非常によくあるのが、オープンドア・ポリシーを誤って使うケースだ。

「俺はここにいる。ドアが開いている時はいつでもやってきて問題を伝えてくれ」

まぁ、確かに。常にドアを閉じているよりはましだが、これは雛が口を開けて「餌を頂戴」と叫んでいるのと同じ。しかし、そのような人に今自分が直面している問題を伝えたからと言って、それをどう使うのか? その経営者を信頼できる理由はなんだろう? 解決策が優れていると判断出来る理由はなんだろう? 過去に実績がないのに。

この人は、社員が抱える取引コストを

一切下げようとしていない

そんな人に相談をして、それが相談者に取って不利に扱われない、と考える理由はどこにもない。

積極的に問題を発見し、解決しようとしてくれる人ならば実績も存在する。そのような人がオープンドア・ポリシーを使っているならば、社員は積極的に相談に行くだろう。しかし、そうじゃない場合、オープンドア・ポリシーはただの自己満足に過ぎない。情報は何も集まらない。そして、この場合

情報が集まらないのは

最悪の情報

なのだ。

これで判ったと思うが、優れた経営者であるためには社員の、優れた上司であるためには部下の、ニーズを探り、問題点を発見し、社員を/部下をお客様として、彼らにとって自社で働くことの/自分の部下であることの価値を最大化しようとしなくてはいけない。

「あぁ、この会社で働いていてよかった」

「この人の下で働いていてよかった」

と思えるためには、相手の価値観を知らなくてはいけない。このために、Communication がとてつもなく重要になる。

そして、それは決して社員の/部下のためではない。彼らがあなたを裏切らないように、信頼できるエージェンシーとして使えるようにするために、必要な作業なのだ。

あと、一点、重要なポイントがある。よく優秀な経営者の実績を調査すると、彼らは仕事時間を

社内問題に20%

社外問題に80%

となるように使っている、という調査が出てくる。これを見て、

「やはり優れた経営者たるもの、自らが社外に出て営業して回らなくちゃな」

とか馬鹿を言い出す奴がいる。

それは原因と結果を取り違えている

優れた経営者は、自分の部下を十分に把握している。そのためにたっぷりと時間をかけて価値観を調べ、共有し、信頼されるべく実績を積み、それでも価値観が合致しないものは取り除く、と言うことをしてきた。

だから今、社内には20%の時間を掛けるだけでよいのだ

優れた経営者は、社内に問題が発生すれば 30% でも 40% でも100％でも時間をそちらに振り向ける。社外問題を解決しようとしている最中に、背中から撃たれるほど効率を下げ、やる気をくじくことはない。だから、まず先に味方を完璧に支配するのだ。

十分なコミュニケーションを取ることで、このような状態にすることは可能だし、優れた経営者の実績がそれが可能であることを示している。

新人じゃなくなった人は何を気にするべきか -5.1- 取引コスト

2010-04-04T18:22:00.017+09:00

まずは取引コスト(Transaction Costs)から始めよう。

…何についてでもいいのだが…そうだな、たとえばパソコンについてちょっと考えてみて欲しい。

あなたはそろそろ新しいパソコンを買おうと考えている。どこのメーカーのどの機種にするか…

はい。ストップ。

今考えたメーカーは、今使っているメーカーと同じじゃないだろうか?

今考えたパソコン上で動いているOSは、今使っているものと同じ(あるいはその後継)じゃないだろうか?

なぜ、それらを選んだのでしょう?

OSはいまや沢山あるよね。普通の人がちょっと考えて出てくる選択肢だけでも、Windows7、MacOS X、Linux ぐらいはある。Windows上で作ってきたファイルはほぼ全て MacOS X や Linux 上でも使える。逆は若干苦しいが…特に MacOS X 上で動く Keynote のカッチョ良さに匹敵するものはないし…でも、Keynote を使いこなしまくる人以外は MacOS X である必要性はそんなに高くないはずだ。

合理的に考えれば、新しいパソコンで使うOSを何にするか、新規に一から検討をするべきだ。当然、そのOSに合わせてハードウェアを選択するべきだろう。

しかし、現実にはそのようなことをする人はほとんどいない。新しいOSは古いOSと同じか、その後継OSだし、ハードウェアも今使っているのと同じメーカーで、ほぼ確実に他のOSがサポートしている互換性とかは気にもしない。

車を買う時も同じだ。トヨタの車を最初に買うと、ほぼ確実にずっとトヨタ。マツダならマツダ。ホンダならホンダ。日産なら日産。メーカーを変えるのは外車に買い換える時か、なにか画期的なものが出てきたか(ハイブリッドカーとかね)、よほど車メーカーが酷い形で信頼を失った時ぐらいなものだ。

限定合理的な我々は、知らないメーカーや知らないOSについて知らない。文字通り、情報が不足している状態なのだ。しかし調査しようとするとコストが発生する。そのコストを払ってまで情報収集するべきか? それともコストを払わずに候補から外して真の最適からは程遠い状態になるリスクを取るか? この決断をしなくちゃいけない。もし、調査対象がこのコストに見あうほど品質に大きな差があるとは思えないならば、このコストは払うに値しない。

パソコンはどこでもハードウェアはインテルかAMDで演算パワーも大差なく、メモリ容量も似たようなもので、HDDのサイズも同じ。ならOSが多少違ってもできることは似たようなものだろう。天と地ほど違いはないなら、いちいち全部調べるに値するとは思えない。じゃぁ、今のままでいいや…

車はどこでも同じようなもんだろう? 燃費がリッターあたり2倍も違ったりするかい? 同じような値段で、同じような形の車なのに、運転のしやすさは変わらずに一方だけ空を飛べて今の後継だと飛べない、なんてことはないよな? じゃぁいいじゃん。今のままで…あ、ハイブリッド。そうね。じゃぁトヨタかホンダを候補に入れよう…

判るだろうか?見知らぬ候補は調査コストと言う名のハンデを持っているのだ。

『今と同じ(後継)』　＞(価値) 『見知らぬ候補自身の価値』－『調査コスト』

という不等式が成り立つ限り、ほとんどの人は「今のままでいいや」「今の後継でいいや」となる。これを上回るほどの価値が「見知らぬ候補」側にはあるのだ、という事が事前に伝わっていなければ、そもそも検討の候補にすら上がらない。

ここの『調査コスト』のように、知らないモノに関して取引を行う場合は、知っているモノに関して取引を行う場合に比べてコストがかかる。これを 取引コスト と呼ぶ。

買い物をするなら、見知らぬ店より行きつけの店の方が良いのは、見知らぬ店の信頼度について新たに調査するコストを掛けたくないからだ。同じ値段で同じものを売っているように見えても、見知らぬ店の場合騙されているのかもしれないじゃないか。

だからこそ贔屓という概念が出てくるし、そのような贔屓を沢山作った店は、他店より微妙に高くても客が離れることはない。あまり高いと離れていくが。どれぐらい高くても大丈夫か…という辺りはブランド力と呼ばれる。ブランド力は、同業他社製品に対し取引コストを引き上げる効果がある。また、同一ブランドネームの他商品に対して取引コストを引き下げる効果もある。

多くの企業が広告を打つのは、自社を知ってもらい、自社製品を知ってもらうことで、取引コストを少しでも下げようとしているからだ。無限にコストを掛けるわけにはいかないから、どこにどうやってアプローチすればいいか? と考える必要が出る。これが マーケティング というものだ。

取引コストにはコミュニケーションがよく効く。取引コストとは無知であるが故に生じるコストだ。じゃぁ、自分のことを相手に伝えることで相手の自分に対する無知を軽減させ、相手の事を知ることで自分の相手に対する取引コストを下げればいいじゃないか。コミュニケーションのためのコストが掛かるが、「モノが売れないことで生じるコスト」だの「より良いサービスをより安く手に入れ損なうことで生じるコスト」の方が大抵の場合大きい。なによりも、その状態だと「価値としての損失」よりも「金額としての損失」が大きい。

「あなたが作っている/扱っている商品を買ってくれるお客様」という Customer の場合、こういう事が言える。

仮にあなたの作っている/扱っている商品が本当に良いもので、でも売れない。他社のもっと質の悪いものは売れているのに…というなら、

あぁ、これは取引コストが高いせいですね

と言えば、100% 正しい。とはいえ、これじゃ何も言っていないに等しいが。

あなたの会社名がお客様(あるいはお客様候補)に全く知られていない
あなたの会社が扱っている商品が何か全く知られていない
商品が何をするものなのか知られていない
自社内のニーズが見えておらず、商品の必要性が分からない
お客様のニーズが見えておらず、商品の方向性/宣伝の方向性がダメダメ
商品を入手するための連絡先が判らない
商品の説明カタログが、日本語じゃない
商品のマニュアル類が日本語じゃない
そもそも必要なマニュアル類が無い事が露呈している
…

これらは全部お客様候補に取引コストを生じさせる。大抵の外資系企業が日本に来て「モノが売れない、非関税障壁だ」などと呻いている場合は、絶対これらの取引コストを引き下げようとする努力が 全くもって、丸っきり、全然、馬鹿かと言うぐらい 足りていない。IT業界の製品を考えただけでも、NEC, 日立, 東芝, 松下, 富士通などが一般家電からPCから何からで常に名前を見ない日はない、という状態な所に割り込む必要があるのだ。どれほど売り込みが必要か…IBMぐらいだろう、取引コストが十分下がったのは。逆に富士通はエフサスとかPFUとか、無駄に取引コストをあげるブランディングを打ちすぎている。

逆に日本製品がアメリカとかで売れている場合というのは、これらの取引コストを引き下げるための努力がもの凄まじい。"you asked for it, you got it, Toyota," というキャッチフレーズなど、１９７６年にアメリカにおいてラジオを付けていると GM, Ford, Chrisler のCMの合計に匹敵するぐらい聞こえてきたことがあるぐらいだ。自動車を買うわけがない幼稚園児までがToyotaの名前を知っている、これぐらいじゃないと海外勢の取引コストは下がらない。
"YAMAHAはアメリカの会社だ"
と思い込んでいる人が過半数を占めるぐらい、現地に馴染まなくちゃ「会社を知られていない」という取引コストは下がらないのだ。

無知に伴なう心理的コストには恐ろしいものがある。これは特に日本において顕著な特徴だが

未知のバグより既知のバグ

という顧客傾向がある。
古いバージョンは「既知のバグ」が１００個ある。それらは全て正体が判っている。新しいバージョンは「既知のバグ」は一個も無い。そんな怪しげなモノは使えるか。そう言って、既知のバグの多い古いバージョンのソフトウェアを使いたがるのだ。
ちょっと考えれば判るように、新しいバージョンでは古いバージョンにあった１００個のバグは直っている。直したから、既知のバグが０になったのだ。もちろん未知のバグはあるだろう。しかし、それは古いバージョンだって同じなのだ。従って、ソフトウェアであれファームウェアであれ、fixそのものに大きな問題が無い事を確認したら、可及的速やかに新しい版に移るのが正しいあり方なのだが、そうしない。

「未知のバグ」と「既知のバグ」で前者の方が取引コストが大きい場合、「既知のバグがある方が安心できる」という状態に陥るのだ。え？未知のバグの数はわからないだろうって? いやいや。バグの総数から１００個、既知のバグの分だけ未知なるものが減っているんですからそちらの方が安心ですよ、えぇ。

バグの総数は一定なんて誰が決めたっ

でも、総数が判らないのは一緒なんだから…と考えると、総数は同じのように感じるよね？ようするにある無知が、別の無知と既知のコスト差を逆転してみせることすらもある、と言うことだ。

取引コスト問題を解決するには、本質的には啓蒙とか宣伝とか…ようするに情報を与えるしか無い。だからセミナーとかをやっている会社は多いが…そもそも「よく分からない会社」のやっているセミナーに出たいと思う、あるいは時間を割くべきである、と考える人はいない。ここにも取引コストがいるのだ。いくらセミナーの案内に
「御社が抱える問題を解決するソリューションがここにある」
とか書かれてもねぇ、それを鵜呑みにするには殆どの人はすれているし、人生ですれていないほど学習能力のない人がセミナーに来ても何も学ばずに帰るのがオチだ。

新規顧客が持っている取引コストはこのように非常に高い。だから一度お客様になってくださった方がいたら、リピーターになってもらう方が良い。せっかく相手との取引コストが下がり始めたのだ。お客様が持っている不平・不満を聞き出し、煽り立て、うちの会社の製品がそれをいかにスマートに解決するか刷り込まなくてはいけない。状況によっては他社製品をお勧めする場合でも、その製品が良ければ良いほど、勧めた人の価値も一緒に上がるように、それによって結局取引コストが下がって自社に戻ってくるように、きめ細かくコンタクトを続けろ…営業マンがもっともハッパをかけられるのはここだし、優れた営業マンがやっているのも要するにこういう事だ。

優秀な営業ほど口下手で、自分から物を話す量は少なく、相手にたくさん話しをさせる、というのも実は同じこと。お客様はしゃべればしゃべるほど、営業マンに対する取引コストを引き下げてくれる。
「こんなに私のことを理解してくれてはるんやから」
いや、おばちゃん、あんたが独りでペラペラ喋くってるだけですがな。
逆に営業マンが喋くりすぎると、話に割って入りたいとか、よく解らん事を言われてだけど質問するのも恥ずかしいし(これも取引コストだ)…と、相手に対する心象が悪くなる。心象の悪いヤツに自分が困っている事を打ち明ける人はいないわけで…こうして取引コストは高いままになる。下手をすると最初より高くなったりすらする。

そうそう。はてなブックマークにコメントを書いている人がいたが、床屋は確かに良い例だ。

新規顧客が来たら、床屋は相手に関する情報を引き出そうと色々話しかけてくる。髪を切っている間は特にそうだ。しかし、シャンプー、髭剃りと進むに連れて徐々にしゃべる量が減る。
一見床屋が話しているように見えるが、実は床屋は「お客様が話せない状態」では話しかけない。椅子が横倒しになって客が眠くなったら邪魔をしない。話せるときに話す、というのは取引コストを下げる。話せない時に話をさせないのも取引コストを下げる。

軽く居眠りをしてから髪型を整えると、ほぼすべての人はすっきりと快適になって床屋を出る。他の未知の床屋よりも取引コストが下がった状態になり、故に一度行ったことのある床屋は再び訪れる率が高い。
実際にはほとんどの床屋で同じことを経験することができるので、よほどひどい場合を除いて、どこへ行っても「その床屋との取引コストは下がる」のだが…そこでは「未知より既知」のルールが働く。全く同じなら、なにも未知の床屋にチャレンジしなくてもいいじゃん。既知の床屋の方が確実なんだから。

こうしてはてブにあった事を取り込む事自体も取引コストを下げるための方策だ (^^;)

さて、逆にあなたが材料を買ったり、サービスを買ったりする場合。

当然予測されることだけれど、情報収集を怠るな、というのは一つ目の大事なポイントになる。意図的に新規・未知の取引相手に対する取引コストを引き上げちゃいけない。

と、同時に。すでに取引のある相手との取引コストが下がるように働きかける必要がある。あなたが商売するうえでリピーター顧客が大事であるように、あなたがサービスだの材料だのを買う相手もリピーター顧客は大事なのだ。ちょっとしたアイディア…そう -3.3- off demand で書いた、ルンバを使う話とか…は積極的に相手に与えるべきだ。どうせ自分で抱えてても現金化できないんだから。
くだらない話かもしれない？うん、それは相手の営業はよく判っている。でもあなたを邪魔したりはしない。１００本に１つぐらいは、どうにか使えるアイディアがあるのを営業マンは知っている。１万に１つぐらいになると、まじで商品化できるものがあるのも知っている。そうじゃないハズレの話であっても、少なくとも客(あなただね)の取引コストが下がる事を直感的に理解している。だから、そうそうムゲに無視したりはしない…というか聞く耳を持たないのは無能な営業マンの証だ。
万が一、本当に商品化したら？
「お客様に教えていただきまして」
「お客様にご意見をいただいて、二人三脚で開発いたしました」
100%自前で作ったとしてもそう言って売り出すはずだ。既存顧客を満足させ、また新規顧客に「他の人が欲しいと言うなら何かあるに違いない」と興味を湧かせる事で取引コストを下げるために。

で、だ。あなたの取引コストを下げている時に、実はあなたは

営業マンのあなたに対する取引コストを引き下げている

事に気がついているだろうか? 新規顧客へ飛び込み営業するのがすごく苦痛な営業マンは多い。それは「営業マン側にも取引コストがある」からだ。どうせ取引をするなら「飛び込みが苦手そうな営業マンが飛び込み営業をかけてきたとき」にするのが良い、と言うことが判る。営業マン側の取引コストを上手に下げてやれば、その営業マンは他の新規顧客に飛び込み営業をする必要性が減る。少々の無理を聞くコストと、新規顧客に対する取引コスト、どちらが安いか…

もちろん、その際にさらに相手の口車に乗ってしまって、結局自分の出費の方が大きくなっちゃった…というのでは全然意味がないが…。

さて。物やサービスを「売る側」「買う側」がはっきりしているこれら２つは、とても判りやすい対称形なので、単純に取引コストだけを考慮してもいろいろ言えることがある。ところが会社と社員のような形になると、この取引コストがものすごくいびつな形で現れることがある。エージェンシー理論の中には取引コストの一形態、あるいはミクロなレベルでの取引コスト理論が積み上がってマクロレベルでの問題として発現しているものがある。

そこで、会社と社員の取引コスト問題は、エージェンシー理論の方でまとめて書く。

そうそう。取引コストについて述べる時にはこの本を紹介するんだった。「あなたの会社が90日で儲かる!」。この本の中身は玉石混交ではっきり言って自分で何を言っているのか判ってかいているとは思えない内容なのだが、当然玉の部分がある。それは、広告を打つときの姿勢。この本に書いてあることを書き換えるとこうなる。

広告は、商品を買ってくれることが確定している人をターゲットに打つのではなく、何らかの理由で取引コストが高くなっている人にもアプローチするように打て。そのためにも、「これを買え」的な広告ではなく、「情報を提供する」とか「サンプルを渡す」とか、そういう形のアプローチを取れ。
商品を買おうとする人にとって、取引コストには大雑把に「必要性の不足」と「魅力の不足」の形で発現する。

「面白い商品だけれど、それは今必要なわけじゃない」…これが必要性の不足。
「必要なのはわかるけど、もうちょっと待てばもっと良いもの/安いものが出てくるかもしれない」…これが魅力の不足。

両方共不足している場合は、買ってくれる確率はとても低い。でも片方だけならどうにかなるかもしれない。そこで、まず広告を打つ。両方共満たされているお客様は即座に買ってくれるだろうが、片方が不足しているようなお客様でも何らかの反応を示すように、広告を打つ。
で、このような「片方が不足していそうなお客様」に対して営業マンをアプローチさせる。最初から取引コストがある程度低い人な上に、ある程度コミュニケーションを取ればどちらが不足しているのかは明瞭になる。そこを集中して攻めさせれば、成約率は高くなる。そうなれば営業マン一人当たりの効率も良くなる。

この本には、広告の見てくれだとか、お願いする形で文章を書けとか、本質とは全く関係ない内容が大事そうに書かれている。そういう「石」な部分を取り除くと、「取引コストに注目しろ」という非常に正しい本質が出てくる。

新人じゃなくなった人は何を気にするべきか -5- Communication

2010-03-20T03:57:00.011+09:00

『新社会人にあなたならまず何を教えるか -2- CS』において説明したように、Customer Satisfaction は3つの要素から成り立っている。

CS = T × T × F

最初のT	Technology つまり「技術力」
次のT	Transfer/Translate つまり「伝える力」
F	Focus 「焦点」

この内、Technology についてはもう、ほぼ予測がついているのではないかと思う。商品に価値を加えるのも技術なら、商品を量産して不良品を出さないようにするのも技術だ。すべての作業を手作業で行うのではなく、一連の自動化された作業に変換するのも技術だ。これらによって、商品に付加価値を加える事、それも安定した品質で(商品ごとのばらつきを少なくした状態で)提供出来ることは、お客様に安心感を与える。

「これ…そっちのと同じに見えるけど、本当に同じかなぁ…」
「いや、普通は同じやろうけど、このメーカー、昔から信頼ないからなぁ…」

なんぞと評価されるようでは、顧客満足度は向上しないのだ。ここに Automation と、それを実装するための Technology の重要性がある。

さて、問題は二つ目の T … Transfer/Translate あるいは Communication だ。これはなぜ重要なのだろう?

Customer が商品を買ってくれる人だとして、Communication が大事な理由は?
Customer が材料を売ってくれる人だとして Communication が大事な理由は?
そして Customer が社員だとして、Communication が大事な理由は何だろう?
なぜ Communication を重視すると顧客満足度は向上するのだろうか?

限定合理性を解決するため

実はこれだけで説明がつく。うん、判ってる。問題を「限定合理性」にすり替えただけだよね。まぁ、でもご想像の通り、ここから先は限定合理性の話になる。この限定合理性というのはこの次の Announcement でも重要なので

早速だが本を一冊紹介。この本はすごく簡単に言うと

第二次世界大戦で日本軍が行った数々の
どう考えても負けるだろ、それは
的な戦略的失敗は、従来は非合理性によって説明されていたが、実は限定合理性で説明すると論理的に説明出来る上に、他の組織の失敗についてもに多様なことがあるんじゃないかぁ？と言うことまで判る。

と言う話。太平洋戦争の日本軍には限定合理性から来る失敗が全てあります、と言わんばかりの勢い。いや、たぶん本当に全部あるんじゃないかと…。

限定合理性の話が判ると、組織運営においてどういう落とし穴があり得るのか、特に参加者全員が善意から参加していたり非常に頭が良かったりしても、組織全体としてはうまく回らないことがなぜ起こるのか、よく判ります。たぶん、以下に述べる私の説明よりも。

とまぁ、逃げを打つのはこれぐらいにしておいて :p

仮に神様であれば、何かを判断する際に次のような前提を立てても大丈夫でしょう。

判断をくだすために必要な情報がどんなに膨大でも、取得コストは0である
判断をくだすために必要な情報がどんなに膨大でも、それを保持・参照するコストは0である(つまり時間をかけずにそれらを検討対象に加えることが出来る)
判断をくだすために必要な計算量・演算量がどんなに膨大でも、必要な時間は0で計算が終了する
判断をくだすために必要な情報が何なのか、わからなくなるなどと言うことは絶対にない(判断に必要な情報が何かを把握する、というコスト自体が0である)

あ、ここでいう「コスト」は、時間がかかるとか、お金がかかるとか、何かの作業をするために別のことを諦めなくちゃいけなくなるとか、そういったもの全てをさします。単にお金だけの話ではありません。

さて、人間は神様ではありません。ですから上記のような仮定は取れません。しかし、だからといって全ての判断がサイコロを振っているのと同じ、と言うほど非合理的でも無い。そこで、

人間は限定合理的である

と仮定し、その場合に様々なことが説明できないか？というアプローチがあります。経済学では新制度派経済学（ new institutional economics ) というのがそれだそうです。で、このアプローチで見て行った場合に、個々人の挙動について、(少なくとも)次の3つの理論が成り立つことがわかっています。

取引コスト理論
エージェンシー理論
所有権理論

これらは全て、

判断をくだすために必要な情報を取得するにはコストがかかる
判断をくだすために必要な情報がを保持・参照するにはコストがかかる
判断をくだすために必要な計算量・演算量に応じてコストがかかる
判断をくだすために必要な情報が何なのか、わからなくなる事があり、それを解決するにはコストがかかる

という4つのコストの存在から出発しています。これらのコストが存在するのに、経済効果を最大化しようとすると…つまり欲の皮を突っ張らかせると、起こる現象に関する説明です。

次からは順に内容の説明と、それが Customer とのコミュニケーションにおいてどう大切なのか、見ていきましょう。あ、Customer は先に定義したCustomer の方ね。

新人じゃなくなった人は何を気にするべきか -4- Who is Customer

2010-03-06T22:50:00.006+09:00

さて、Automation 関連の話が終わったので、次は CS … Customer Satisfaction に関連する話だ。

ここで最も重要なのは…実は次の2点:

Customer って誰?
Satisfy ってどういう状態??

…ちょっ、今更何言いますのん

そう言うなかれ。新人の頃は上司なり先輩なりが「この方がお客様だ」「お客様に納得、満足していただくのが我々の仕事だ。そのためには…」と　Customer も Satisfy も明示してくれた。新人はこれらのことを意識する必要はあったが、Customer の定義は何かとか、 Satisfaction の定義は何かとか、考える必要はなかったのだ。

しかし、今やあなたがその上司なり先輩なり。部長なり、常務なり、専務なり、社長なり。Customer の定義をするのはあなたなのだ。だからこういう問題の本質から考えなくちゃいけない。そして、問題の本質を考えると、あなたがとんでもない勘違いをしていたことに気がつくわけだ。

まずは最初の問題からいこう。

あなたのお客様は誰ですか?

「お金を払って商品を買ってくれる人の事でしょう?」

うん。新人の時にはそう習ったね。それはあなたのお客様の一部ではある。でも全部じゃない。

実はお客様って言うのは、

あなた以外全員

つまり

あなたの扱っている商品を買ってくれる人

原材料を買い付ける先

事務所を貸してくれるビルオーナー

清掃サービスを提供してくれる清掃会社

そしてもちろん

御社の社員

あなたの部下

これらは皆、あなたのお客様だ。これは経済学の定義から自動的にそうなる。

これを理解するためには、物々交換まで話を戻して基本を理解してもらわなくちゃいけない。テーマは「商売成立ってなに?」

いま、AさんとBさんがいます。

Aさんは、今日カレーを食べたかったのでカレーの材料を集めたのですが、人参が足りません。人参3本ほど欲しいのです。が、彼は大根を一本持っています。

Bさんは、今日おでんが食べたかったのでおでんの材料を集めたのですが、大根が手に入りません。大根1本欲しいのです。が、彼は人参を3本持っています。

この状態でAさんとBさんが出会いました。

AさんはBさんが持っている人参3本が欲しい。つまり Aさんにとっての価値はこうなります:

大根＜(価値) 人参3本

BさんはAさんが持っている大根が欲しい。つまり Bさんにとっての価値はこうなります:

大根＞(価値) 人参3本

ここで、AさんとBさんが大根と人参3本を交換すると、ふたりとも自分が持っているものの価値が高まります。そこで、AさんとBさんは大根と人参3本を交換します。

大根 =(価格) 人参3本

二人とも食べたいものが食べられてまんぞくまんぞく…

おおっと、待ちねぇ。今、私はものすごく大事なことを言った。それも2つ。

一つ目： 価値は個人のもの。価格は取引時に発生するもの。

この2つは全然別のものである。

二人の価値観に違いが出るときに、商売は発生する。

二つ目: 商売は等価格交換

一部の人に取っては「何を当たり前な」と言うかもしれないが、実はこれがものすごく重要。Aさんにとっての大根と人参の相対価値は、Bさんのそれとは逆転していた。と言うことは、

価値っていうのは、個人個人が持っているもの

私とあなたで共通化することはありえないもの

なのだ。たとえば、仮にここにCさんがいて、Cさんもおでんが食べたいとする。で、Cさんも大根を持っている（他の材料も揃っている）。さて。BさんとCさんが出会った。物々交換は起こるだろうか?

起こる訳ないよな

Cさんが大根をBさんにあげたら、Cさんはおでんが作れなくなって、代わりに人参が余る。BさんにとってもCさんにとっても大根は同じように大事で、人参は同じように不要なもの。この場合は物々交換は起こらないのだ。

価値に違いがある

だから取引が発生する

これが商売における重要なポイントの一つ目。

あなたと取引をしてくれる人が

あなたのお客様

これは、直感的に問題ないと思う。単にそう定義しているだけだし。

あなたのお客様は、

あなたとは違う価値観の持ち主

これは忘れちゃいけない事実。

さて。物々交換が起こった。このとき、AさんとBさんは何をしたんだろう? AさんとBさんは人参3本と大根を交換した。どちらもそれ以上何も求めなかった。この場合、この交換においては人参3本と大根は同価格と呼ぶ。つまりAさんは大根1本を提供すれば人参3本を得られると考えた。Bさんは人参3本を提供すれば大根1本を得られると考えた。この意味において「人参3本」と「大根」は互換性があるわけだ。本当は価格ってのは貨幣が出てこないと成立しないんだけど、その順序だと議論が面倒になるので物々交換のレベルから価格があると考えてくれ。

大根とか人参は日持ちがしない。そこで交換の仲介としてもっと日持ちのする、価値の変動の少ないものを考えた。これが貨幣。同じ量の貨幣で入手出来るものが「同じ価格」。同じ価格のものでも、貨幣で持っている方が価値が高いのか、物で持っている方が価値が高いのかは、一人ひとり条件が違うので同じ結論にならない。これが市場経済が成り立つ理由だ。

さて。

以上の話を聞いた段階で、「お客様」が意外と幅広い存在だと言うのは判ったと思う。

あなたの会社の商品を買ってくれる人というのは、「あなたの会社の商品」の方が「自分が持っている貨幣」よりも価値があると思ってくれたわけだ。一方であなたの会社は「商品よりも売値分の貨幣の方が価値がある」と思った。だから商売が成立した。よって、商品を買ってくれた人はあなたのお客様だ。

会社が商品の材料を仕入れるためには、材料を持っている人から材料を買わなくちゃいけない。材料を持っている人は、その「材料」よりも「材料の売値分の貨幣」の方が価値があると思った。会社はその材料を使って商品を作れば高い値段で売れると思った。つまり「材料」の方が「材料の売値分の貨幣」よりも価値があると思った。だから商売が成立した。よって、材料を売ってくれた人はあなたのお客様だ。

会社が自分の社員に会社の清掃をさせるよりも、あるいは清掃を一切せずに汚れるに任せるよりも、清掃会社に清掃サービスをお願いした方がよい、と考えたなら、清掃会社は会社に取ってお客様だ。おそらく社員を清掃に使うコストよりも清掃会社のお値段のほうが安いのだろう。また、清掃しないことで起こる、社員の健康状態の悪化やモチベーションの低下による被害よりも、清掃会社のお値段の方が安いのだろう。結果、会社は「貨幣」と「清掃サービス」を交換した。清掃会社はこの会社から見てお客様だ。

同じことが社員と会社の間にも言える。社員は労働力を提供する。力仕事だったり、知恵や知識だったり、お客様と対面する際の印象の良さだったり、いろいろだろうがそういうもの全部をひっくるめて「労働力」とする。この労働力を提供する代わりに、給料として貨幣をもらう。

社員であるあなたは、自分の労働力を温存するよりも給料として貨幣をもらう方が価値がある、と思ったのだ。会社は、貨幣を維持するよりも社員に労働力を提供してもらう方が価値がある、と思ったのだ。結果として、ここに「労働力」と「給料」の等価格交換が発生したわけ。

さて。等価格交換が成立したのはよいが…考えてみて欲しい。

あなたが会社の購買だったとしよう。材料を買う係だ。同じ材料なら、少しでも安く買った方が良くないかね? しかし、値切りすぎると提供される材料の品質が下がるはずだ。値切った分のコストはどこかで回収しなくちゃいけない。それは材料を採掘・加工するコストに転嫁されるはずで、と言うことは品質の悪化となって現れるはずだ。だから、値切りすぎちゃいけない。

同じことが会社と社員の間についても言える。同じだけ労働力を提供してもらえるなら、少しでも安く提供してもらう方が良くないかね? でも、給料を下げると社員のモチベーションも下がる。その給料で満足出来る社員のレベルも低い。結果として提供される労働力は下がってしまう。
逆に給料を上げたら? 給料を2倍にしても提供される労働力は2倍にはなるとは限らない。2倍の時間働いたら疲労が蓄積して、間違いが増える。だから、値切りすぎちゃいけない。

社長をはじめとする管理職の仕事と言うのは、社員のモチベーションを上げたり、働く環境を整えたり、あるいは社員にやらせる労働内容をコントロールすることで、同じ金額の給料でより多くの労働力を引き出すことにある。つまり、彼らはあなたの労働力を値切るのがお仕事なのだ。しかし提供される労働力が下がるほど値切りすぎてはいけない。

もちろん、トータルの労働力を値切るのが仕事なのであって、給料を減らすのが仕事なわけではない。

たとえば、今よりも性能のよいPCを提供すると、同じ7時間30分の労働でより多くの仕事がこなす事ができ、結果として投資したコスト以上に成果が得られるのならば、より多くの労働力をほんの少しの追加投資で引き出せたことになる。

よりよい広告を打つことでより多く、より正確な見込み客からの反応が得られるようになれば、営業職の社員の成約率は向上するし、同じ期間での成約量も増大する。これもより多くの労働力を同じ給料で引き出せた成果、と言うことが出来る。

社員はお客様

とは、そういう意味だ。

さて、2つ目の問題。

Satisfy とはどういう状態か

取引が成立した直後の「価値」の状態をお客様側から見てみよう。

「商品」　＞(価値) 「払った金額」 ....... (1)

商品のほうがその商品のために払った金額よりも価値がある、という評価状態のはずだ。

問題は、お客様は常に自分の中の価値を再評価できるので、(1)の式は永久にこのままである保証はない、と言う点にある。商品を購入してみたら思ったようなものではなかった、失望した、と言う場合、商品の評価はすぐこのように変化するだろう：

「商品」　＜(価値) 「払った金額」

簡単に言えば「金返せ～」という状態。この状態に陥ると、お客様は「騙された」と感じ、あなたと(あるいはあなたの会社と)の取引を今後も繰り返したいとは思わなくなる。

ここまでは『新社会人にあなたなら何を教えるか -2- CS』に書いた内容に非常に近い。ようするに

お客様がリピーターになってくれる状態

が Satisfy な状態だ。しかし、「お客様」の定義が変わったので、この状態になるとはどういう事なのか? も意味が変わってくる。

優れた労働力を提供してくれた社員がいるとしよう。この状態でお客様…つまりはこの社員…がリピーターになるとはどういう事か?身も蓋もない言い方をするなら

転職しないと言うことだ

優れた社員が会社を去ると、社員から得られる労働力が大幅に下がる。そうならないためには、

この会社で働いてよかったという満足感

を与えなくてはいけない。しかし、満足感と言うのは複数の要因が絡みあって成り立つものだ。給料が安すぎず、労働環境が悪すぎず、仕事の内容が退屈するような内容でも失敗するほど困難な内容でも無い。社員ひとりひとりごとにバランスポイントは違う。さらに人は成長するものなので、今の時点でのバランスポイントは将来のバランスポイントとは違う。

逆にこの条件を満たすことが出来ると、仮に何らかの理由でこの社員が退職する必要が出たとしても、再び就職する際にまた戻ってきてくれる可能性が出る。優れた社員が戻ってくるのは会社に取って大きな利得になる。

あるいは退職した後もその会社のファンで居続けるならば、何らかの商取引の際に心因的に優遇してくれる事もあるだろう。同じものを同じ条件で提供するならサイコロを振るのではなく御社で、と言う奴だ。

リピーターになると言うことを別の方向から観てみよう。同じ相手との商売を繰り返すと、繰り返し囚人のジレンマ状態になる。つまり詐欺などの行為は行えない。商売を繰り返すことによるメリットが、詐欺などで一時的に得られるメリットを上回るからだ。

詐欺などの被害による潜在的被害を小さくしたいならば、お客様がリピーターになるように仕向ける必要がある。

もし、あなたの会社が社員の定着率が低い(外部から社員をやとってもすぐ辞めてしまう)としよう。この場合、社内のどこかで繰り返し囚人のジレンマ状態が崩れていることを意味する。つまり、優れた労働力を提供するものが適切に評価、処遇されていない(必要なリソースや自由、予算などが与えられていない)ために、社員定着率が悪化している、と言うことだ。大抵の場合、経営陣のどこかに、経営陣たる資格の無い奴がいる。

こうなると、社内での繰り返し囚人のジレンマ状態が崩れているので、社外のお客様に対して提供されているはずの製品品質も保持できなくなっているはずだ。結果としてお客様もリピート率が低くなる。この状態を無理矢理何とかしようとすると、材料を買う際に値切りすぎる、などさらに状態が悪化する。

一見これらは全部違う現象のように見えるが、

お客様が満足していない

という意味では全く同じなのだ。

お客様が満足していないという状態は連鎖する

のだ。最悪、会社が潰れてしまうほどに。

お客様の定義と Satisfy の定義がそれぞれ何で、どうしてそれが大事なのか、についてはこれぐらいにしよう。次は Communication の話だ。

新人じゃなくなった人は何を気にするべきか -3.3- off demand

2010-01-21T02:14:00.009+09:00

まず最初に一番大事なことを。

商売は、基本的に on demand である

お客様に

「これこれこういう物にならば、こんぐらいまでのお金を払ってもよい」

という要望・欲求が発生する。それを実現するものをその場で提供する。あなたにお金が入る。これが商売。だから、「要求に応じて」(on demand)。

Amazon.co.jp ウィジェット

エリヤフ・ゴールドラット博士が制約理論を振り回して言っているのも、ようするに on demand で商売をしろ、 on demand を徹底しろ、と言う事に他ならない。

「なーんだ。じゃぁ、どうやったって無理じゃん」

あー、いや、そうじゃないんだな。確かに商売の基本は on demand なんだけれども、あなたの元に「要求」がやってくる頃には、お客様の demand はなんかおかしなものが一杯ぶら下がった状態になっている。それら、「おかしな demand」を外していこう、というのがここでいう off demand。

例として。あなたがサラリーマンで、どこかの事務所に務めているとしよう。多くの事務所では、18:00 ぐらいになると清掃の人が入ってきて、ゴミの回収と床の掃除機がけをしてくれたりしないだろうか?

では、ここで質問。

清掃の人が、18:00ぐらいにゴミ回収と床の掃除機がけをする、

その理由は?

うん。仕事の最中に掃除の人がうろうろするのは邪魔だよね。機密情報を見られるかもしれないし。だからせめて定時を回ってから掃除をして欲しい。それは清掃会社からするとお客様の demand だよね。

でも、じゃぁ、なぜ 18:00? 19:00 とか 20:00 とか… 22:00 とかじゃなくて。いや、03:00 とかでもいいはずだよね? なぜ 18:00?

清掃をする人からすれば、そんな夜中に仕事をしたくない。清掃会社も自分の社員に深夜手当を出したくない。コストがかかるから。だから、なるべく早い時刻帯に清掃をやりたいわけだ。これは 清掃会社側の demand だよね。

このように見てみると、実は「18:00ぐらいにゴミ回収と床の掃除機がけをする」という、たった１つの作業項目には、お客様の demand 以外のモノが含まれていることが判る。そして、お客様側の demand はなかなか手をつけられないかもしれないが、自分側の demand は取り外せるかもしれない。

上の話に関して、清掃会社側の demand を一部、off demand する一例をあげよう。ルンバを知っているかい?　iRobot社が出している自動清掃ロボットだ。似たような物にロボクリーナーというものもある。

どちらも、部屋を掃除させるとその動きはものすごく馬鹿だ。人間ならその何百分の一かで掃除出来るような所をえっちらおっちら掃除してくれる。でも、十分な時間をかければそこそこの掃除はしてくれる。でも、やはりその結果はそこそこ。はっきり言って

四角い部屋を丸く掃く

と言う表現がぴったりだ。

このルンバに毎晩あなたの事務所を掃除してもらったらどうだろう?そう… 22:00とかにスタートさせるんだ。多分一晩かかるだろうし、掃除出来るのは床全体の 80%を超えることはありえないだろうが、まぁまぁ、きれいになる。で、週に１度だけ人間が掃除機をかけて、残り20%…主に部屋の角になるんだろうけれど…に掃除機をかけてもらう。

ルンバは一晩中掃除をし続けるだろうけれど、その頃には事務所にはあらかたの人はいなくなっているから邪魔ではあるまい。一晩中掃除をし続けるとしてもロボットだから就労規則もへったくれも無い。文句をいうこともなく、深夜手当も必要ない。

ゴミ回収は相変わらず人間に毎日やってもらって、その時にルンバの中のゴミも回収してもらう。

これで、清掃会社側の demand 「夜遅く掃除機を掛けると深夜手当が必要だから、なるべく早い時間帯に掃除機をかけたい」の一部は解消されたよね。人間が掃除機を掛けるのは相変わらず 18:00 からだけれど、それは週に一度になった。

ゴミ回収の時刻は 18:00 じゃなく 18:30 からにできるかもしれないね。掃除機を掛ける時間が不要になった分時間が短縮できて、ルンバのゴミも回収しなくちゃならない分時間が伸びるから、多分稼げるのは30分程度だろう。

似たような事は前に買いた日記「新社会人にあなたならまず何を教えるか? -8- Automation の種類 - 補助頭脳型」でも説明した。こちらは、乾燥機能付き全自動洗濯機の例だった。濡れたままの洗濯物は腐っていくが、乾かせば腐らない。洗濯機に乾燥機能がつく事で、あなたが洗濯物の demand に縛られる必要がなくなったわけだ。

off demand は機械化との相性がものすごく良い。大抵の制約は人間に起因しているので、人間じゃないものを使うと demand が消えることが良くあるのだ。ただし、機械の demand が発生することを忘れちゃいけない。ルンバの例だと、電気を沢山消費するようになるはずだ。

off demand を実現するために demand を分類しそれぞれの発生原因を考え始めると、実は Market Fundamentalism について考慮・実現方法を探っている事と同じだ、と言う事に気がつく。当たり前の話だ。

ルールというのは demand の一形態に過ぎない

偉い人が、下の人に自分の demand を押し付けるための形態がルール。けれど、その demand は実現するために常にコストがかかることを気にした方が良い。demand をルールにする前に、

そもそもなぜそんな demand が発生するのか

検討した方が良い

大抵のおかしな demand は、問題の設定が間違っていることにそもそもの原因がある。「自分では原因だと思っていること」が単なる症状に過ぎず、故に解決するべき問題を間違っているわけだ。症状をいくら隠そうとしても、根本原因は直っていないので、別の形で何度でも吹き出してくる。

「真の問題は何か？」

「それは誰にとっての問題か？」

という観点が曖昧だったり、定義がいい加減だったり、感情論でスタートしていたりすると、狂った demand が発生し続け、コストばかりかかって結果がでない、と言う状態が続く。このような無駄が内在していると、お金がいくらあっても足りなくなる。だから、まず最初に「ライト、ついてますか」を読んで、問題とは何か、を考えなおすことから始める必要がある。

そして、可能な限り demand を消す方向で、検討をした方が良い。demand がなくなれば、そもそも demand が満たされているかどうかを確認する必要がなくなる。つまりコストダウンに直結するのだ。demand が満たされていることを確認する人件費よりも、demandを消滅させるための機械化に掛けるコストのほうが、長期的に見て安い場合が多い。

効率のよい企業は、ルールは少ないものだ

off demand が進んだ会社では多くの物事が Market Fundamentalism に基づいて定義されている。つまり「放っておくと望む方向になる」ように設定されている。すると 管理職が少なくて済む という状態が生まれる。一人の管理職が面倒をみることが出来る部下の数が増えると言うことは、組織のピラミッド構造が深くならずに済むと言うことで…組織化に伴うオーバーヘッドが減るのだ。

off demand は他の方式と異なり、下っ端数 n がいくつになっても成立するが、ピラミッド構造がなくなるわけではない。Scalabilityという観点で見るならば、off demand は管理効率を向上させる数少ない…ほとんど唯一の手段だ。

新人じゃなくなった人は何を気にするべきか -3.2- 機械化

2010-01-11T22:46:00.003+09:00

分割していくと、作業手順の中身が徐々に明確化していく。で、どこかで気がつく。

「これ、機械で出来るんじゃないの?」

これが機械化の始まり。

機械化はかなり広い範囲で行われている。

ネジを素手ではなくねじ回しで回す、なんていうのも機械化の一種だ。あれは力をネジにいかに効率的に伝え、なおかつそのための機械が簡単に着脱出来るようにするか、かなり熟慮した結果できたものだ。ねじ回しを今度はモーターにつないで、あっという間にねじ込む、というのも機械化だ。機械化された作業を、さらに機械化して便利にしたもの。で、その電動式ねじ回しをロボットアームの先につけて、ビデオアイで位置決めして…とやっていくと、自動車工場とかで働いている組立ロボットになったりする。

そうやって作られた自動車も機械化だ。モノを移動させるのに抱えて運ぶとしんどいが台車にのせると楽になる。抱えて運ぶと荷重を支えるための力をずっと必要とするが、台車だと平地を移動する限り必要なのは初期速度を得るまでの力 + 摩擦分のロスを埋めるための力だけだ。その力の供給もエンジンからの力にしてしまえ、というのの究極の形の1つが自動車になる。

機械化にはいくつものメリットといくつかのデメリットが有る。まずさきにデメリットを。

機械に何をさせるのか、どうやってさせるのか、決めるまでが一苦労
人間なら「適当にやっておいて」で済む手順をいちいち考えなくちゃいけない。適当にネゴるとかそういう機能は機械にはない。
さらに、その手順を機械に実行させるためのメカニズムを考えなくちゃいけない。
機械を準備するのが、これまた一苦労
人間なら適当に人を雇って、「これこれこうやって」と言えば適当にやってくれる。完璧じゃないかもしれないが、十分役に立つレベルのものが出てくる。
機械だとそうは行かない。必要な機械を買ってくるなり組み立てるなりする。設置する場所に荷重制限があったり、十分平らじゃない、などの問題があったらそれも解決しなくちゃいけない。
さらに設置したからと言って100%うごくと言う保証はない。機械にトラブルはつきものなので、それを解決しなくちゃいけないし、解決出来る人を用意しなくちゃいけない
メンテナンス要員を用意しなくちゃいけない。
…これは人間でもマネージャーが必要だ、という意味においては似ているかもしれない。が、世話のかかり具合が桁違いだ。

その代わり、こういうメリットがある。

人間と違って疲れを知らない。なので24時間365日動け、と言っても問題はない。
もちろん、実際には故障するかもしれないし、メンテナンスも必要なので、そういう動かし方はしてはいけないが。
この一種の応用として、人間には出来ない作業が出来る、というのもある。「人間には対応出来ないほど時間をかけて、ゆっくりと鍋をかき混ぜる」のような作業をさせることも出来るのだ。人間だと、どうしても「ちゃちゃっとかき混ぜてしばらく放置」を繰返すが、機械なら「ずーーーっとかき混ぜ続ける」事が出来る。
Webでいろいろなサービスを提供する、というのも基本的にはこのパターンだ。マシンを管理している人は24時間365日働いているわけじゃない。サービスを提供しているマシンが24時間365日働いているわけだ。
人間よりも高出力/低出力/高精度を必要とする作業も出来る
プレス機とかは端的にこの例だろう。強い力で一気に均等に金属に力を掛ける。金型を使って力のかかり方を制御してやると、切ったり、曲げたり、伸ばしたり出来る。一度に必要な力が少しでいい場合は、一度に複数のものを同時に作ることが出来る。
逆に人間の限界を超えて微妙な力加減で何かをなさなくてはいけない場合も、機械のほうが有利だ。というよりこちらも人間には出来ない仕事。
精密工作の中には人間の限界を超えるものもある。こういうのも結局は機械を経由させることで、人間の荒い行動を精緻な行動に変換してから伝達することで実装出来る。あ、逆のほうが判りやすいか。精緻な情報を、レンズなどを通じて拡大することで人間の目でも判るようにする、なんていうのも機械化の一種だ。
計算機なんかだと、人間の何億倍もの速度で計算できる。量を必要とする演算は人間は到底叶わない。というか、人間単体だとあまりにもアテにならないので、ソロバンが発明されたぐらい。
人間がやると健康に被害が出るような事も出来る
自動車の塗装なんかは、もうロボットに切り替わって久しい。あれは人間がやるとムラが出る上に健康被害もひどいから、ロボットにやらせるに限るわけ。

適切な作業内容を選んでやると、メリットがデメリットを大幅に上回るようになる。そうなると人間は機械を管理するために必要なだけになるので、人間一人当たりの生産性は飛躍的に高まる。

単純作業ほど機械化しやすい。そして機械化した場合、その機械の管理は決して単純作業では収まらない。

単純作業の大量の繰り返し

を

少量の複雑な管理作業

に置き換える、仕事の変換が行われた、と言い換えても良い。

よく比較優位貿易論とかで、「賃金の安い国に、単純作業が輸出される」とか言っているけれど、機械化を考慮に入れると事はそうそう簡単ではなくなる。準備に必要な時間やコストを吸収出来るなら、単純作業を輸出するよりも、機械化して国内でまかなった方が安い可能性があるのだ。

この辺をやらせたら天下一品なのが、岡野雅行さんだ。リチウムイオン電池のケースを絞りで作ってみせたり、とんでもなく細い注射針…無痛針を作ったりした人。

この人の場合、

モノを作る機械を作り、それを運用してモノを作って出荷する
モノを作る機械とそのノウハウを、他社に売る

という2段階を行うことで、常に他の人に真似が出来ない(そんな値段じゃ作れないとか、そもそも大量になんか作れないとか、根源的に人の手では作れないとか)事を成し遂げている。

だから岡野さんの所は5人の社員で回る。お金になってくれるもの自体は、社員が作っているのではなく、機械が作っているからだ。社員の仕事は、手法の確立と、機械の作成、管理。

岡野さんとは規模が桁違いで、やっているジャンルも全く違うが、実はやっていることは全く同じ、と言うのが Google。Googleも検索であれGmailであれ、サービスそのものは機械が行っている。Googleの社員がやっているのは、機械の管理と、その機械に何をやらせるか・どうやらせるかの開発、あとお金の管理。Googleと岡野さんの違いは、「機械に機械を管理させる」ための研究をやっているかどうか、ぐらいじゃなかろうか。だからGoogleのサービス規模、営業規模と、社員数は全く比例しない。

しかし、機械化もやはり限度がある。いや、機械に機械の面倒をみさせたとしても、やはり限度が来る。人間が人間を管理するのと同様、管理コストはO(n)よりも速い速度で上昇するのだ。末端のサービスを提供する機械の必要台数は、提供するサービス量 n に対して O(n) で必要になる。これらを管理するための機械を含めると、必要な機械の総量は O(n) よりも速い速度で膨れ上がっていく。

この観点で行くと、Google が他社を圧倒しているのは機械化の力であり、機械の労働力単価が世界中のどこに住んでいる人間の労働力単価よりも安いからだけれども、Googleといえども規模問題を回避したわけではない、と言うことが判る。

岡野雅行さんは経営方針として規模拡大をしない、としている。どちらかというと京都の老舗と同じ戦略だ。

新人じゃなくなった人は何を気にするべきか -3.1- 分割

2010-01-08T00:06:00.004+09:00

分割は Scalable Organization の基本。

そもそも仕事が分割できないなら、「複数の人間で構成された組織」を作ったり、その一員になったりする意味ないし。

分割には大雑把に2種類ある。

同じ作業を二人がそれぞれやる、というのが「負担の分割」。

一連の作業を2つのパートに分けて、前半のパートをAさん、後半のパートをBさんがやる、というのは「機能の分割」。

「負担の分割」はO(n)のスケーラビリティがある。10人きて、10人同じことをすれば(十分なリソースがあれば)、10倍の速度で仕事は仕上がっていく。ただし、10人に何をすればいいのか教えなくちゃいけない。10人の仕事を評価しなくちゃいけない。マネージャーがいる。だから仕事はO(n)だけど、必要な人数はnの倍数よりも早く増えていく。なので、nが大きな数になると苦しい。しかし、nが小さな数字の間は、管理負荷は仕事の速度向上で相殺されることが多い。それはようするに、仕事がハードすぎて効率が落ちていたって事でもあるのだけれど…

近代といわれる時代以降、ほとんどの分割は「機能の分割」。別名「専門化」。

たとえば、鉄鉱石から自動車を作る仕事を考えてみる。これを全部一人でやるとなったら大変だ。鉄を精製することから始めなくちゃいけない。製鉄が終わったら一部をネジとかにして、別のものは鉄板にして、鉄板はさらに切って削って叩いてカタチ整えて…。その多くのステップそれぞれに必要な道具が異なるし、必要な技能も異なる。さらに作業の結果出てきたゴミを毎回片付けて…

仮に必要な技能は完璧にマスターしているとしよう。必要な道具も全部ある。ゴミ掃除もいらない。

でもそれでもそれらを全て使って自動車を作ろうとしたら、作業手順1つ1つに対して、必要な道具を取り出し、片付ける、という作業が必要になる。

ここで…たとえばネジのカタチをした鉄の塊にネジ溝を掘っていく部分を考えよう。バイトという道具を使ってネジを切る。本来なら、必要なバイトを取り出して、ネジを切って、余計な破片捨てて、バイトを片付ける。

が、仮にあなたはこの「ねじ切り専門師」になったとしよう。あなたの仕事はネジのカタチをした鉄の塊にネジ溝を掘ることだけ。もうバイトを取り出すとか、片付けるとかしなくていい。

仮にネジを切るのが全工程の1%かかっていて、車を1台仕上げるのに20日かかったとしよう。ネジを切るのは本来は 1/5 日。これが一日中ネジを切っていられるとなったら、おそらくあなたは一日に5台分のネジよりもはるかに多くのネジを作れることだろう。また、できたネジの品質は遥かに高いものになっているだろう。

「機能の分割」…つまり「専門化」は、「負担の分割」の場合と違って効率の向上を見せる場合がある。これは、「準備」「片付け」などの生産に直接寄与しない部分を大幅に省略出来る可能性があるからだ。逆に言うと、このような生産に直接寄与しない部分が少なくなってくると、生産効率の向上より、生産物を受け渡しするオーバーヘッドの方が大きくなってくる。

乱暴な話、チャーハンを作る作業を次のように、全部別の人に割り当てたとして効率があがるとおもうかい?

中華鍋を加熱する
中華鍋に油を馴染ませる
中華鍋に油をしく
溶き卵を投入する
具材を投入する
ご飯を投入する
最初の一振り
次の一振り
…

絶対無理だわな。ということは、機能の分割もやはりｎの大きさに縛りを持った方法に過ぎない、と言うことだ。

でも、nの大きさの範囲内であれば、10人に同じ作業をやってもらうより、作業内容を10個に分割してそれぞれに専門の仕事をやってもらった方が、作業の進み具合は速い。10倍の人数で12～15倍ぐらいにはなる。ほら、マネージャを養う余裕ができた。

「機能の分割」の辛い所は、一連の作業を一旦全て明文化しなくてはいけない事。何をやっているのか理解していないと、分割できない。

「とりあえず先輩の仕事ぶりを見て、それを盗んで」

などという、 自分でも何やってるか判りません 的な、あまっちょろい状態は許されない。

くっきり、すっきり、はっきりと、何をするべきかわかってくると、この先に進める。そう。機械化だ。

新人じゃなくなった人は何を気にするべきか -3- Scalable Organization

2009-11-28T20:18:00.006+09:00

あなたの会社は、今、年間の粗利が n 円だとしよう。粗利だから売値から原材料費を引いた残りだね。それが n 円。

この n 円を稼ぐために、m人の「下っ端従業員」が必要だとする。平社員だけじゃなくアルバイトとかも含めてｍ人だ。従業員とかを管理する、管理職は m人の中には含めない。ただし、部長なんだけれど仕事の1割はお客様の所に行くことです、なんて場合もあるだろう。その場合 m人の一部として 0.1 人と考える。ようするに n 円を稼ぐ原動力になっている人たちの頭数だけを数えて m人を算定する。mが大きくなってくると人事とか、総務とかそういう仕事も多くなってくるだろうが、それらの人たち無しでは n 円は稼げなかったのだから、それも mに含める。だけど、「営業マンを束ねる営業部長」とか、そういう人たちの「管理職務分」は含めない。

さて。ここで、n の値が 10倍、100倍、1000倍になったとしよう。mの値はそれぞれどれだけの大きさになるだろうか? ここで市場がそんなにでかくならないとか、そういう話にはならないことにしよう。10000倍にだって簡単になる市場において、粗利を増やすと直接必要な頭数はどう増えるか、という問題だ。

単純に mも 10倍、 100倍、 1000倍になりますという組織構造だったら、早晩その会社はつぶれる。

判りやすくするために、今 m = 1 …つまり一人で1億の粗利を稼いでいるとしよう。粗利を合計で10億にしたい。そこでお客様の所に行く営業マンを10倍の10人にしたとする。m=10だ。

一人であれば、営業以外も全て自分ひとりでこなしていただろうが、10人の営業マンがいたら指導や管理をしなくちゃいけなくなる。そのために管理職という仕事が出てくる。ここで仮に10人の営業マンを管理するには一人の管理職…部長としようか…が必要だとしよう。すると、会社にいる頭数の合計は11人になる。

100倍にするとなると100人の営業マンが必要だ。10人の営業マンごとに一人の部長が必要なので、部長が10人必要になる。すると、それらの部長の意思統一を図り管理監督するために部長を管理する管理職…専務としようか…が必要になる。すると、会社にいる頭数の合計は 100+10+1 = 111人になる。

1000倍にするとなると、1000人の営業マンと、100人の部長と、10人の専務が必要になる。10人の専務の意思統一を…もういいだろう?…ようするに一人の社長が必要になる。会社にいる頭数は 1111人だ。

粗利が1000倍の1000億にしかなっていないのに、人手は 1111人必要だ。この粗利の中から1111人分の給料を捻出する必要がある。最初は一人1億のなかから給料を捻出すればよかったのに、今は9千万円から給料を捻出しなくちゃいけない。仮に給料を変えないとすると…売上をどんどこ増やしていくとどこかで赤字になる。赤字にしないためには給料を減らさなくちゃいけない…

あれ～??

売り上げを伸ばして粗利を増やしたのに

給料減っちゃったよ???

会社としての収入の伸びを下っ端の頭数に依存した価格設定にしている会社は、必ずこうなる。

多くの場合、グループ企業の子会社とかは、親会社に対して「何人がかりで何時間働いたのでいくら」というお値段のつけ方しかできなかったりするが、実はこれは子会社が大きくなれないようにするための秘策だったりするのだ。もしあなたが勤めている会社がお客様にそういうチャージの仕方しかしていないなら…転職を考えたほうが良い。規模が大きくなるほど忙しくなるが、儲けはむしろ減っていくのだから。

この状態を回避する方法は全部で４つある。

規模を大きくしない
定期的に組織構造を根こそぎ書き換える
mがnに比例している部分をアウトソースしてしまう
nを増やしても比例してmが増えたりしないようにする

1の「規模を大きくしない」と言うのは「京都で600年間続く老舗」とかではよくある。手広く商売するのではなく、限定された規模のお客様だけを相手にし、その代わりそのお客様を手放さないようにする。これを可能にするためには、収入を他人と分け合わない 必要がある。株式公開なんかもってのほか。借金をしたら利子を取られるのでそれもなし。何らかの希少性を前提にできるならば、この戦略はありだ。

ただ、一般的な企業はそうは行かない。株式は公開されているし、拡大再生産しないと経営陣が突き上げを食らう。

2はようするに「リストラクチャリングを定期的に行う」と言うものだ。ようするにこれは富の再分配の問題なのだから、会社の構造を書き換えて、再分配ルールを変更してしまえばよい。

ただ、これをやると必ず「今までよりも手取りが減る」人が出てくる。そりゃそうだ。そのために構造を変更しているんだもの。大抵この手のしわ寄せは「下っ端」に押し付けられる。問題はほぼ全ての職種で「下っ端」はいくらでも交換可能な存在ではない という点だ。旧来の高給取りを首にして、安い給料で働く人間を入れると、必ず一人当たりの粗利自体が悪化する。市場で急激に売り上げを伸ばしたので会社の構造を変えたら、品質が悪化、売り上げが縮退し、そのまま倒産…なんて会社があるが、それは リストラに失敗した という事だ。この手段は意外とリスクが大きい。

3はよくある「グループ企業」って奴だ。自分では構造改革できない部分を切り離して外に押しやり、

「自分たちでどうにかしろ」

というかなり無責任な行為。もしあなたが、「人月」でしか値段をつけられないのにこのようにアウトソースされたのなら、すでに万策は尽きている。親会社の方を切り捨てるしかない。他の企業は人月によるチャージにならないよう、値段交渉できるが、親会社は政治的圧力をかけてくるからだ。

で。結局3の場合も独立したあとは 4 の問題を解かなくちゃいけない。10倍の粗利を得るのに10倍未満の人口増でまかなわなくてはいけないのだ。最低限度でも 管理職をも含めた全人数 が粗利の倍率に比例するように、人数が増えると作業効率がよくなるようにしなくてはいけない。

Automation の本領発揮だ

Scalability を確保する方法は、今知られている範囲では、3種類ある。

分割
機械化
off demand

…あう。ずんどこ書いていったら終わらないよ。というわけで上記3種類、それぞれの詳細は次回。

ただ、上記3種類、いずれも「無限の scalability」は持っていない。どうしても 一定の n の範囲内で という条件を外すことができない。単に発見されていないだけなのか、存在しえないのかは、不明。

新人じゃなくなった人は何を気にするべきか -2- Market fundamentalism

2009-11-25T23:23:00.005+09:00

まずは Automation の1つ目。市場原理主義。Market Fundamentalism。

うん。普通は経済の用語だよね。だから Customer Satisfaction 側の説明じゃないのか? と疑問に思ったあなたは、おそらく市場原理主義をある程度理解している。が、理解が足りない。

Automation を理解するうえで最も重要なのは何か? Automation の究極奥義とは何か。それは

放っておいたらどうなるか知ること

だったりする。手に持っているボールを放す。すると重力に引かれて落ちる。まずこれを理解するからこそ、「ボールが落ちないようにするにはどうすればいいか」という発想が生まれる。物事を制御する、と言う考えが生まれる。で、常にそれを意識してやってなんぞいられないから、自動化する。

市場原理主義というのは、人間を放っておいたらどうなるか、そしてそれは何故か、を理解する上でとても重要な知恵だ。何故これが大事か? だってあなたは今、後輩を持ってるんですぜ? 部下を持ってるんですぜ? 組織の親玉として、組織全体がどう動くのかに責任を持ってるんですぜ?

こいつら、放っておいたらどこへ行く?

って知るのは大事じゃないかい? さらに、それが自分の目的と合致していたら? 難しく考えなくても、放っておくだけで目的が達成されるって事だよね?! いちいち、あーしろ、こーしろ、あーするな、こうするな、と指示しなくても自動的に目的が達成されるなら、これ以上楽なことはないじゃないか。

もちろん、世の中そんなに甘くなくて、一事が万事放任主義でどうにかなったりはしない。しかし、だからといってルールをガチガチに作って、社則で縛り上げたら目的が達成されるかと言うと、これまた間違い。

これを理解するには…そうだな。セキュリティが一番判りやすいだろう。USBメモリーについて考えてみようじゃないか。

昨今では、多くの人が理解していると思うが、USBメモリーと言うのは非常に危険なデバイスだ。基本的に不揮発性の記憶媒体だが、ものすごく小さくて持ち運びしやすい。故に、輸送したいデータなんかを入れて、思わず持ち運んでしまう。

しかし、そのようなデータの中にはお客様情報などの、プライバシーやら守秘義務やらに関連したデータがありえる。つーか、そういうものを運ぶ上でUSBメモリーというのは非常に便利な輸送デバイスだったりする。なにしろ、インターネットのような「どこ通ってるんだか判らなねー」ようなものを経由しない。容量も結構でかい。思わず使って、USBメモリーごと失くして、さぁ大変、ってな状態に陥る。

だから、大抵の大手会社は USBメモリーの利用を制限したり、持ち込み自体を制限したり、と言ったルールを使っているはずだ。

にも拘らず。USBメモリーを失くした、という失敗談が減りもしなければ無くなりもしない、と言うのも事実。USBメモリーを作っていた会社が、売れ行き不振で倒産したという話も聞かない。という事は、それだけ多くの人が、USBメモリーを禁止された後も使っているって事だ。

ここでは、事の是非を議論したいわけではない。USBメモリーを禁止するべきじゃない、と言う話をしたいのでもない。議論したいのは、何故、USBメモリーは使われ続けているのか? という事だ。禁止されているんだから、おそらく破ったら罰則があるはずだ。にも拘らず、使われ続けるのは何故?

別の事例を考えよう。仮に、USBメモリーを使っても良いとする。今あなたの手元に X というファイルがあるとしよう。
「Xのコピーを頂戴よ」
と私が言ったとしたら? 多分あなたは USBメモリーを取り出してそいつにXをコピーし、
「はい」
と言って渡してくれるだろう。私は USBメモリーを自分のPCに挿し、Xを取り出して、USBメモリーは返す。

じゃぁ、
「Xのコピーを、a, b, c, d, e, ... さん達に渡してあげてくれない?」
と頼んだら? あなたは USBメモリーを使うだろうか?? 多少は環境にも寄るだろうが(メールに添付できるファイルのサイズとかに上限があるかもしれない)、それら、コピーを渡さなくちゃいけない人たち全員を To か Cc に入れたメールに、添付ファイルとして X をつけて、一気に送るんじゃないだろうか?
間違っても USBメモリーを回覧したりはしないと思う。

はい、ここで質問。最初のケースではUSBメモリーを使ったのに、2つ目のケースではUSBメモリーを使わなかったのは、何故?

最初のケースでは USBメモリーを使うのが最もコスト対効果がある、と判断されたから。2つ目のケースでは USBメモリーを使うよりもメールを使ったほうがコスト対効果が高い、と判断されたから。だから、1つ目のケースでは USB メモリーを使ったし、2つ目のケースでは USBメモリーを使わなかった。
同様に、セキュリティルールで禁止され、罰則まで規定されているのに USBメモリーを使う人が後を絶たないのは、罰則までをも含めてもなお、USBメモリーを使うほうがコスト対効果が高い、と判断されたからだ。

実は、ここには市場原理が働いている。USBメモリーはその市場原理に基づいて、ある条件下では採用され、別の条件下では採用されなかったのだ。禁則・罰則の導入はUSBメモリーを完全に排除できるほど、市場に対する影響力は無かったのだ。

後輩や部下の面倒を見る上で重要なのは、あなたの後輩や部下は、市場原理に基づいて動いている事を理解することだ。ルールや罰則は、ある程度は市場に影響を与えるが、完璧からは程遠い。そのことを理解しないで、ルール策定にまい進する偉い人が非常に多いが、そんなのは何の役にも立ちはしない。

市場原理主義が Automation を考慮するうえで、第一番目に来る理由はここにある。

法律と罰則を持って人の行動を拘束すれば、良い世の中ができる、と信じた人たちがいる。法家といわれる人たちで、秦の始皇帝の時代の少し前、春秋戦国時代の百家のひとつだ。彼らは、悪しき行いを法で禁じ、法を破るものには厳罰をもって処す事にすれば、必ずや人々は法に従い、この世はすばらしいものになると信じた。今から2200-2300年ぐらい前の話だ。もちろん結果は大失敗。

法を破る行為をするかしないか、逡巡している人がいるとしよう。法を破ると罰則以外のメリット、デメリット全部勘案して +10 の効果が得られるとする。法を破らないと 0 だ。もし、ここで罰則が -10 よりも大きくなかったら、どんな人でも毎回法を破ろうとするだろう。だから罰則は -10 かさらに厳しいのががふさわしい。じゃぁ、どれぐらい大きければいいのか?
まず、最初に考えなくてはいけないのは、罰則の適用は法を破ったときに必ず行われるわけではない、と言うこと。法を破ったことが発見されなくちゃいけない。たとえば10回に1回ばれるとするなら、「罰則を食らう期待値」が -10 を超えなくちゃいけないから、-100 かさらに厳しい必要がある。逆に、この値が厳しくても、法に反しない人たちにとっては何の影響もないはずだ。だから厳罰で構わない。法家の人たちはそう考えたわけだ。

しかし、実際にはこのようなルールを適用するとなると、ルールを理解しそれに基づいて人々を監視する者が必要になる。監視役が甘ければ発見確率は著しく小さくなり、どんな罰則を以ってしても法を守ることは割に合わなくなる。さらに、罰則を強化すると、

監視役が違法を見逃す代わりに賄賂を受け取る

という状態が始まった。ようするに役人の腐敗がスタートしたわけ。監視役を複雑に強化して相互監視させ、さらに秘密警察まで用意した国では、密告が横行し、さらに嘘の密告が横行しだして、さらに法の運営が崩壊してしまった。何のことは無い。罰則を強化したために Premium Cost と呼ばれるものが発生し、それが新たなる闇市場を作り出してしまったわけだ。

これは USBメモリの場合についてだっていえる。原則がUSBメモリーの利用禁止だったとしても、それを禁止しすぎたら仕事が動かなくなる。だから皆互いに見てみぬ振りをする。このような状態が横行すると、社則などによる禁止項目全体が運営の危機にさらされる。

さらに監視するためのコスト、と言う問題もあるのだけれど、それは、この次の Scalable Organization の所で言うことにしよう。

とにかく。厄介なのは、法で禁止して、厳罰を科せば、何かが実行されなくなると思ったら大間違いだ、と言うこと。罰則で何かがなくなることは無いし、単なる禁則は何であれ地下に潜らせる、と言うのが自然な流れだという事を理解しなくちゃいけない。

じゃぁ、打つ手無しなのか? そうじゃない。

USBメモリを使っているシーンと、使わなかったシーンをもう一度思い起こして欲しい。

一人に対してファイルを渡す場合は、USBメモリを使った。
多人数に対してファイルを渡す場合は、USBメモリを使わなかった。

何故？

多人数の場合は、USBメモリはオーバーヘッドがでかかったからだ。逆に言うと、

一人にファイルを渡す際にネットワークを使うのは、
オーバーヘッドが大きすぎる

という事だ。多分、100Mbpsぐらいしか出ない上に、共有ドライブのIO速度も遅いのだろう。

じゃあ。ネットワークが 10Gbpsぐらい出て、共有ドライブのIO速度が USBメモリの 10倍ぐらい早く、なにより容量が一人当たり Tbyte クラスだったら? USBメモリを取り出してPCに挿すほうが余程オーバーヘッドだわな。

ファイルのコピーを渡すのではなく、そのファイルを作成・管理している SubVersion Repository を教えるのならどうだろう?
SubVersion はファイルを保存するたびに、差分だけをサーバーに送りつける。このため、10Gbps などという、まだちょっと無理目な性能じゃなくても十分早く機能する。過去のバージョンを差分管理しているので、昔のバージョンまでも全部保持しているのに、全ファイルの合計サイズよりもはるかに小さい共有ディスク容量しか必要としない。10Gbps+Tbyteディスクよりは現実的な解だ。

そのような環境では、USBメモリが使われる可能性は大幅に減るはずだ。大幅に減る、という事はUSBメモリを持っている人自体少ない、という事を意味する。

このように環境を整備してから、
USBメモリを禁止したら
どうなるだろう?!

罰則をはるかに軽くしても、違反者はほとんど出ないはずだ。だって、使う価値の無いものを禁止されてるんだもの。「禁止されなくたって、使わないよ」と言う人がほとんどな状態で、禁則を犯す人はほとんどいない。だって、メリット無いもの。市場原理に従って、USBメモリ利用者はほとんど出ない。

市場原理に従って、USBメモリを利用するものがいないのだから、USBメモリを利用していないかどうか、監視する必要もない。監視者がいないし、違反者も見つからないので、監視者の腐敗も起こらない。監視するためのコストも要らない。となると、環境を整備するためのコストは、実は十分おつりが来るぐらい安いのだ、と言うことも判る。

市場原理主義に立つと、「行政と司法の等価交換」と言われる行為が取れるようになります。

法というのは大抵目的を持って設置されるわけですが、その目的を満たすのには、「法律を作り罰則を作り司法を強化する」方法と、「環境を整備する」方法がある。どんなときでも司法と等価な行政が存在するわけではありませんが、存在する場合は、司法の代わりに行政をもって目的を達成する事ができるようになる。しかも、環境を整えさえすれば、自然と目的が達せられる。

実は、市場原理主義を十分利用しないと、Scalable Organization という2つ目の Automation ルールに抵触する事になります。そして、これに抵触すると、あなたの会社は大赤字で倒産する危険性が出てくるのです。

…というわけで、次は Scalable Organization の話です。

新人じゃなくなった人は何を気にするべきか -1- やっぱり CS と AT

2009-11-24T17:41:00.005+09:00

昔書いた日記、「新社会人にあなたならまず何を教えるか? -1- CS と AT」から始まる10回が思ったより好評だった。ので、久しぶりに続きを書こうと思う。今回は「新人じゃない人」は何を気にするべきかという話。

そもそもは、ある会社の社長さんが社内メールで悲鳴を上げたことに始まる。いや、その内容は内緒だが、ようするにそれを見ていて思ったのは、

「そういえばこの会社、新社会人以外も問題のある人が多いよな」

というもの。なに? お前もだ? うむ。その通り。だから、今回の話を書くに当たっては、まず、心の中に大きな、大きな、大きな棚を作った。そりゃもうギアナ高地のような、大きな奴だ。どうにか自分をそこに置くことに成功したので、棚が壊れる前に先に進む。

で、いろいろ考えたわけだ。どういう事を気にするべきかとか、どういう問題があるかとか。で、いろいろまとめていくと…結局新社会人に教えたことと同じ枠組みから一歩も外に出る必要がない、という事に気が付いた。やはりお金を稼ぐには2つの項目:

Customer Satisfaction
Automation

の2つに神経を集中する必要がある。逆に、この2つのためにその他の注意すべき項目は存在するし、それらに関してどうやって解くべきか、を考えるとどうやら答は一通りではないようだ。各々、自分が好きな、得意な解き方というのがあってよいように思う。

で。今回の議論。新社会人が相手じゃない。社会人になって、後輩とか部下とかができる辺り…って2年目からジャン…以降の人、社長さん(つーか CEOな)の辺りまでが考慮対象だ。活躍する経済圏としてはまだ開放系を前提とする。世界中を全部1つの経済圏として見なくてはいけない人(銀河皇帝になる私とか)は、経済圏を閉鎖系として見なくちゃいけないのだが、そこまで大きなものを見据えなくちゃいけない人たちは考慮対象としない。つーか下手にその辺を教えると、支配者のライバルが続出するしな :p

経済圏が開放系だ、という事は、あなたの活動によって世の中の経済が大躍進を遂げたり、逆に大打撃を受けたりはしない、という事を意味する。あなたの会社の趨勢はあくまでも局地的な問題で、あなたの会社が上手くいかなかったら、他の会社がその位置を占めるだけのこと。そういう大前提を念頭に置いてほしい。

また、「新社会人にあなたならまず何を教えるか? -1- CS と AT」から始まる10回で述べたことは繰り返さない。基本的に、あそこに書いたことはすでに知っている、という辺りからはじめる。でも、同じことは書くかもしれない(どっちやねん)。いや、新人の時とは違う意識を持って同じ事をね…

書く内容はこんな感じ:

Automation
1. Market fundamentalism (市場原理主義)
2. Scalable Organization
Customer Satisfaction
1. Who's Customer(で、お客って誰さ)
2. Communication(Transfer の大事さ)
3. Annoucement
4. I18N/L10N

さて。今回の議論だが、 Automation から始めよう。考慮しなくちゃいけない項目は Customer Satisfaction の方が多いのだが、そうなる理由は Automation 側のニーズが起因となっているものが多いのだ… と言うわけで次回に続く。

【DQ9】くもの大王ハンティング

2009-09-27T23:59:00.006+09:00

今度は いかずちのたま が足りない。これをもっているのは くもの大王 と ヘルクラウダー 。が、ヘルクラウダーは強すぎる。いきおい、くもの大王を狙うことになる。

で、くもの大王、実は結構あちこちにいる。いるのだが、「シンボルとして出てくる」のではなく、別のモンスターにくっついて出てくる事が多い。これだと偶然を待たなくてはいけないので困る。宝の地図だと、もっと強いモンスターが同じフロアにいたりして、これまた困る。あくまでも地上マップで済ませられるならば、済ませたい。

で、あちこちうろついて探した結果、見つけたのがこちら：

丁度この丸でかこんである部分。竜のしっぽ地方の中でもこの部分だけ、くもの大王がシンボルで出てきます。

一緒にうろついているのは、主に サイクロプス と メガザルロック です。また戦闘シーンにだけ出てくるモンスターとして、 ベホイムスライム 、 ギガントヒルズ 、 ヒートギズモ がいます。いずれも雑魚ではありますが、いつまでも生かしておくと戦闘ターンが長くなる元です。とっとと倒してしまいましょう。ただし、勢いに乗りすぎてくもの大王まで殺してしまわないように。

なお、くもの大王はやたらと「いかずちを呼び寄せる」技が好きです。と言うか、もうほとんど毎回そればかりです。装備を雷耐性のある方向にし、いやしのうでわ が毎ターン補充できる程度の被害に収まるようにしておくとよいでしょう。

【DQ9】青空スローライフなおっきーさんからのお便り

2009-09-27T21:05:00.004+09:00

なんか最近、いじめられているような気がするんです。

たとえば、今日も「怒れる花の地図 Lv.45 発見者: かりん」という地図に潜っていたのです。

きっとこんな端っこの方なら誰も来ないだろうなって思って。

本当に端っこにいたんですよ。

じっとしてました。

本当です。

なのに…

普段は、

人の気配を感じただけですぐ逃げ出すはずの、

はぐれメタルさんまでが

ガンをつけにくるんです…

…あぁ、また…

【DQ9】おどるほうせきハンティング

2009-09-25T23:05:00.006+09:00

DQ9をやっている。

ま、一応メインストーリーは終わったのですが、皆様ご存知の通り、このゲームはそこからが本番。クエストとか、宝の地図とか、錬金コンプリートとか、いやそれどころか錬金しないと得られないアイテムだとか…もう盛りだくさん。

一説には「クリスマスにロックが解除される、きわめてシーズンを狙った追加クエスト」というものまであるらしく…半年以上引っ張るつもりか… SQUARE ENIX。FF12 とバッティングするぞ?!!

で、やってらっしゃるとわかると思いますが、問題の一つが錬金。ハイパワーな武器、鉄壁の防具の類を作ろうとすると、材料がすでに錬金した結果のもの。それらを作るためにさらに材料を集める…と、いくつもの材料が圧倒的に不足する。

「xxxx を作るには yyyy が 3つ必要なんだけど、yyyy を作るには zzzz が 3つ必要」

ってこの段階で、zzzz が9つ必要やんけっ!! などというのはざら。これをキャラクター人数分作る段階で4人分…つまり36個。で、実はこれが2段階程度じゃすまなかったりする。

売ってるものならまだいい。Goldを稼げば話は終わる。でも拾ってくるしかなかったりすると…。

というそのようなアイテムの一つが ひかりの石 。もちろん、フィールドにも落ちている場所はあるけれど、一度に拾えるのは6個とかその程度。その後30分ぐらいは復活しないのだ。それより おどるほうせき というモンスターに ぬすむ を仕掛けた方がよほど効率が良い。もしおどるほうせきがどこに出没するのかさえ判れば。

もちろん判っていて、一つ目が カルバド大草原 。ただし、ここはとても広くて「待ち伏せる」なんてできない。しかも出没頻度がものすごくレア。で、二つ目がこれから紹介する 魔獣のどうくつ 。ここでも出現確率はレアなのだが、良いポイントを見つけたのだ。これからそれを紹介しよう。

魔獣のどうくつがどこなのか?世界地図を紹介しているページがあるので探してくれ。

http://www7.big.or.jp/~sosan/dq/dq9/dq9wmap.html

一応、左はしに近い、上下ではまんなから辺だ。まさか、自宅のすぐそばにこんな大事な場所があったとは…。

で、魔獣のどうくつの B1F が目的地。待機ポイントはここ:

魔獣のどうくつ B1F の、地図ほぼ一番下。

で、これが待ちの体制。

この場所の近くで下向きキーを押すと自動的にここにハマる。で、ここに到達したらすぐ X ボタンをおして、図のように「どうぐ」とかを選択するモードに設定する。こうしていると、モンスターはあなたの事を無視してくれる。余計な奴が出てきても、素通りしてくれるのだ。

で、最も多い出現パターンはこう:

私の感覚だと、だいたい 3/4 ぐらいがここに現れる。出現したら B ボタンをおしてダンジョンワールドに復活、即効ダッシュで捕まえる。

即効ダッシュで捕まえるには、あいだに余計なモンスターがいては駄目だ。一分ぐらい待つと、2,3匹よけいな奴らがうろつき始めるので、 掃除の意味をこめて モンスターを討伐する。

たまに発生するのがこれ。

みずらい画像で申し訳ない。このひん曲がった大福餅のような奴も、おどるほうせき だ。実は画面左側にもう1箇所モンスターの出現場所があり、そこから出てくる場合がある。

どうも一度に2つ以上の おどるほうせき シンボルが発生する事はないらしい。

「あれ～?出てこないなぁ」

と思ったら大抵左から出てくる、と思っていい。大雑把に30秒待っても最初のポイントに出現しないなら、このパターンが多い。

この場所、右側が坂になっており、普通は見えないはずのモンスター出現場所が2箇所、画面に映っている。また、左側にも出現場所があるのだが、こちらはモンスターにとっては行き止まりらしい。必ず左から右へ現れる。結果、3箇所の出現場所どこで発生したモンスターも捉えることができる。

これだけ出現ポイントがあると、モンスターを一発倒して出現しているモンスターをリセットしてから大雑把に30秒から1分ぐらいで、どこかしらでおどるほうせきは現れるらしい。

Firefox3の sqlite ファイルを vacuum して reindex する

2009-08-30T00:23:00.004+09:00

Firefox3 は sqlite3 形式のデータベースを内部で使っているらしい。たとえば私のマシンだと

bash-3.2$ cd 'c:/Documents and Settings/*/Application Data/Mozilla/Firefox/Profiles/'
bash-3.2$ ls -alF default.jc3/*.sqlite
----------+ 1 okuyama なし    7168 Aug 29 21:41 ./default.jc3/content-prefs.sqlite
----------+ 1 okuyama なし  104448 Aug 29 21:41 ./default.jc3/cookies.sqlite
----------+ 1 okuyama なし    2048 Aug 29 21:41 ./default.jc3/downloads.sqlite
----------+ 1 okuyama なし  940032 Aug 29 21:41 ./default.jc3/formhistory.sqlite
----------+ 1 okuyama なし    5120 Aug 29 21:41 ./default.jc3/goodictionary.sqlite
----------+ 1 okuyama なし    2048 Aug 29 21:41 ./default.jc3/permissions.sqlite
----------+ 1 okuyama なし 1241088 Aug 29 21:41 ./default.jc3/places.sqlite
----------+ 1 okuyama なし    2048 Aug 29 21:41 ./default.jc3/search.sqlite
----------+ 1 okuyama なし   50176 Aug 29 21:41 ./default.jc3/signons.sqlite
----------+ 1 okuyama なし 2710528 Aug 29 21:41 ./default.jc3/urlclassifier2.sqlite
----------+ 1 okuyama なし    2048 Aug 29 21:41 ./default.jc3/webappsstore.sqlite

のように sqlite ファイルが存在する(cd するパス名中一箇所 * になっているのは本当はユーザー名)。上記はもうすでに作業しちゃった後なのでこれでも結構小さくなっているが、Firefoxをインストールしてちょっといじった直後だと、結構でかい。

で、どうやらこれを小さくする方法があるらしい。本当は slashdot.jp で最初にリンクを見たのだが、その日記がどこに行ったのか判らなくなったので、代わりに先ほど見つけた所を参考資料として。

http://d.hatena.ne.jp/dolphinkick/20090309/Firefox_Batch_SQLite_reindex_vacuum
http://www.gettingclever.com/2008/06/vacuum-your-firefox-3.html

ようするに sqlite3 を取ってきて、vacuum と reindex をしろ、と言うことだ。

まずはここから sqlite3.exe を手に入れる。
http://www.sqlite.org/download.html
"ＰｒｅｃｏｍｐｉｌｅｄＢｉｎａｒｉｅｓｆｏｒ Windows" から zip ファイルを持って来る。で、適当な場所にインストール。つーても zip を解くと、sqlite3.exe というファイルが出てくるので、それをどこか Path が通っているか、自分が判っている所に置く、というだけですが。
すでに出てきているように Application Data のどこかに Firefox3 の sqlite ファイルがある。拡張子は「.sqlite」なのでそれを見つける。私は Cygwin を入れているので、unix の find コマンドが使える。のでそれで
```
bash-3.2$ find . -name '*.sqlite'
```
で発見できた。
sqlite3.exe がカレントディレクトリにあるとして。あとはこう:
```
bash-3.2$ for i in $(find . -name '*.*sqlite'); do
> ./sqlite3.exe $i vacuum
> ./sqlite3.exe $i reindex
> done
```
意外と簡単にずどん、と終わる。

前後でファイルサイズを比較すると判るが、これが結構なサイズダウンになる。

データベースのパフォーマンスは、「一定量 DBMSファイルを読む中にどれだけ Tuple が詰まっているか」と「Indexが適切に張られていて、無駄な読み書きを必要としない状態になっているか」が決める。

vacuum 命令は DBMS ファイルから無駄な空間を削り、Tupleを詰めてくれる。
reindex 命令は DBMSのどこにどの Tuple が置いてあるのかを示す、インデックスを作り直してくれる。

vacuumを実行すると Tuple の位置が動くので、reindex は vacuum の後でなくてはいけないはずだ。その辺が、参考にしたページとはちょっと違うところ。

速度向上ですか? まぁ、なんとなく早くなった気はしますが…そもそもが起動するまでが時間がかかるソフトですから…15秒が12秒になっても…うーん、どうよ、と言う感じ。とはいえ、まぁ、参考にはなります。

というわけで、私もあくまでも参考として。

無駄な謙虚さ

2009-08-16T08:22:00.002+09:00

まぁ、なにしろこのような日記を書くぐらいですので、ときどき人から言われます。

「もっと謙虚になりなさい」

言う人に限って、

お前が言うか

というぐらい謙虚じゃないだけでなく、無能で、無駄なところでだけ謙虚な人なので無視していますが。今回はその「謙虚さ」についてのお話。

まず、ほとんどの人が信じられないでしょうが、私は謙虚であるべきときには謙虚です。「信じられないだろうが」と「謙虚であるべきときは」という条件が付く、と言うことは、

ほとんどの場合は謙虚じゃない
「どういうときに謙虚であり、どういうときには謙虚であってはいけないか」について、ルールがある

という事です。さらに言うと 1 のせいで

観察力のない人から見れば、

謙虚な所が無いように見える

とまぁ、ここまで大見得を切れば当然答えなくてはいけないのが、

どういうときに謙虚なのさ

どうしてそれ以外は謙虚じゃないのさ

どうして普段は謙虚に見えないのさ

どうしてそれがいいのさ

というわけで、今回はそれに答える、というテーマ。

意識するかどうかはともかくとして。大抵の人は PDCAサイクルというものにそって行動している、と言われています。

Plan: 計画を立てる(報)

Do: 実行してみる (因)

Check: どうなったのか観察する(果)

Act: 計画との齟齬をチェックする、分析する(応)

ようするに、何かをしようとする前に『何をするかを決める』。何かをしたら『どうなったかを見る』。そして『分析する』。その結果を次の『何をするのか決める』段階に生かす。

実行してみる、の段階は、実際に実行しようとしてうまくいったり失敗したりします。ここには謙虚もへったくれもありません。もし、他者から見て、この段階で謙虚さが欲しいなら、それはその前の Plan が大胆すぎた、という事です。そして私に言わせれば、Plan の段階で謙虚さなんぞ発揮しても無駄です。Planの段階で謙虚だ、と言うことは「やればできるかもしれないことに手を出さない」という事です。そんな所に謙虚さは不要です。

もちろん、失敗した場合のリカバープランは立てる必要があるでしょう。あるいはリスク分析をして、失うものについては覚悟が必要です。しかし得失を計算して、黒字になると考えたら、失敗覚悟でやってみる。この段階で萎縮する必要は何もありません。

問題は「正しく得失を予測できるか?」と言う点です

できないなら、何故?

実は、大抵の人間に欠落しているのは

観察(Check) の段階の謙虚さ

と、

分析(Act)の謙虚さ

都合の悪いデータを排除する。そのための言い訳を用意する。そのため、観察の段階では非常に都合の良い結果が出ます。しかし、自分自身は観察の段階に手心を加えたと知っていますので、その後の Plan において、分析結果をそのまま使うことができません。

どうしても安全サイドに倒した Plan になる

そのような Plan と Do を

謙虚と言いたくなる

しかし、これは謙虚さではありません。単なる誤魔化しと、他人も自分と同じような誤魔化しをやっているのではないか、という猜疑心です。

多くの人、特に私に謙虚さについて一言述べたくなる人は、大抵、このパターンのようです。

ちょっと前ですが、爆笑問題の二人が出ていた、転職サイトのCMにこんなのがありました。確か en-Japan だったと思うんですが…

結局、大胆だったのは、

いちばん慎重な人でした。

ここでいう「慎重な人」と言うのは、CheckとActの段階で十分な情報収集をする人、自分に都合の悪い情報もきちんと受け止める、入力に対して謙虚な人です。そういう人は、その次の Plan の段階で大胆な手を打てる。自分が入力情報に対して謙虚だ、という事から来る自信こそが Plan と Do の大胆さにつながる。

というわけで。多分、これで答がわかったと思います。

私は Check と Act に対して謙虚です。

Plan と Do に関しては謙虚さなんぞ微塵もありません。

だから、私の行動がどのような背景に基づいているのか、ちゃんと観察できない人からみると、私には謙虚さは微塵もありません。

実際問題としては。

実は Act の途中から後、すでに若干謙虚じゃありません。

Act は「問題の発見と解決」です。観察の結果、問題が発見されるのが Act の前半です。

で、後半。ここで謙虚になるとはどういうことか??

俺には解けないかもしれない…

と引いてしまう事です。それでは解ける物だって解けない。

俺に解けないなら

誰にも解けんわいっ!!

というぐらいの気概で問題に当たらなければ、人生やってられません。

ちなみに。何事にも例外はあるもので。

私の場合、あまりもてませんな、この戦略で生きていると。

Linux kernel zero-day exploit

2009-07-22T14:43:00.010+09:00

備忘録。

対象	2.6.30, 2.6.30.1
真の原因	null pointer check をしていないコード & gcc optimization
修正コード	2.6.30.2
demo	http://www.youtube.com/watch?v=UdkpJ13e6Z0
解説しているページ	http://www.milw0rm.com/exploits/9191 http://tamo.tdiary.net/20090719.html#p01 http://yebo-blog.blogspot.com/2009/07/linux2630.html http://isc.sans.org/diary.html?storyid=6820 http://lwn.net/Articles/341773/
原因となっているパッチ	http://mirror.celinuxforum.org/gitstat/commit-detail.php?commit=33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554

問題はこの部分。

@@ -461,7 +476,8 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
 {
  struct tun_file *tfile = file->private_data;
  struct tun_struct *tun = __tun_get(tfile);
- unsigned int mask = POLLOUT | POLLWRNORM;
+ struct sock *sk = tun->sk;
+ unsigned int mask = 0;
 
  if (!tun)
   return POLLERR;

まず、前提として理解しておくべきことは、C言語においては NULL Pointer へのアクセスの結果は「未定義」だということ。なのでコード的には何が起こっても不思議はない。当然、「未定義」以降に実施されるコードも未定義になる。

次に理解するべきことは、「未定義とはいえ、大抵のgccを利用する環境では NULL ポインタへのアクセスは SIGSEGV などを発生させる」事。つまり NULL ポインタアクセスを行えば、その段階でプログラムは停止するので、そこを通過したコードが持っているポインタは NULL ではない、と仮定して構わない事。どうせ、NULL だったら未定義なんだから何しても構わないし。結果として出力されるコードは論理的には必要な条件をすべて満たすが結果として安全サイドに倒れたコードにはならない。

以上のことを念頭において、先ほどのパッチを見る。

+ struct sock *sk = tun->sk;

このコードは tun が NULL だった場合、ユーザープログラムであれば SIGSEGV を発生させる。しかし、 kernel の場合はそのような割込の類は発生しない(正確にはしなかった)。

gcc は、「tun->sk を通過できたコードは、tun が NULL ではない、という保証が得られた、と言うことだ。その後 tun は変更されていない」と考えつつ、次のコードを見る。

  if (!tun)
   return POLLERR;

で、続けてこう考えるわけだ。
「ふむ。ここまで来た段階で、tun != NULL は真であり、それ以降変更されていない。ならば
if (!tun) は常に偽だ。」
結果として上記のコードは全部なくなる。

結果として全体はこうなる:

static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
 {
  struct tun_file *tfile = file->private_data;
  struct tun_struct *tun = __tun_get(tfile);
  struct sock *sk = tun->sk;
  unsigned int mask = 0;
 
  poll_wait(file, &tun->read_wait, wait);
　：

POLLERR を返すパスはなくなり、エラーチェックが消失する。

エラーチェックが無くなれば、今度はこっちの問題を使って NULL pointer 近くのページに予め mmap しておいたコードを実行できてしまう。なにしろ、ユーザー空間は全て kernel から参照、実行可能だから。

http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f9fabcb58a6d26d6efde842d1703ac7cfa9427b6

ちなみに、2.6.18 base のはずの RHEL5.4 beta にはこれらのバグが存在した(NULL pointer check 関係の最適化がバックポートされた)が、それぞれ修正されているそうだ。

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1897

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1895

A. 笑わない数学者の問題

2009-06-22T03:15:00.003+09:00

まだ確定していない予想はここに書く。

3. 笑わない数学者の問題
2. 笑わない数学者の問題
笑わない数学者の問題

なんとなく見えてきた。これは P_n が問題児なんじゃない。

P_n を決めると、 P₃ から P_n-1 までの値の範囲が決定する ( P₁ と P₂ は固定なので影響しない )。特に P_n-1 の値の範囲には強い影響力がある。

また、 P_n ＝ ( n*(n-1)/2 - x ) の「x の値」が大事。x の値に応じて、同じ P_nに対して、 2^x 組のパターンが発生する。

で、x が決まったときに P_n の周りにどのように数字を配置できるのかを突き詰めていくと、x ごとに有効な n の範囲が出てくる。また、その n が成り立つための拘束条件も出てきて、P_n周りのボールの何個かが確定する。そこから先は n ごとの探索になるが、ここまでは「nとは関係なく」求められる。そういう問題なのだろう。

だから「n を与えられたときに解を求める」という探索戦略を使うと、いったん x の範囲を求めることになり、その後各 x について解を探すことになるが、これは「与えられた n 以外についての解」を大量に探索することになる。その次の n を与えるとこれまた同じような x の範囲について同じような探索をする必要があり…ここが大量に存在する重複した計算部分なのだろう。これは x ごとに n を求めた look up table をまず用意して、次に n ごとにその lookup table を探索するべきなんだ。

んー、何がどうなっているのやら

2009-06-13T08:35:00.004+09:00

www.ascii.jp はご存知 ascii.jp へのアドレスだ。
では、これは? www1.ascii.jp …うん。これも ascii.jp へのアドレスだ。

ではでは、ともちゃ日記で指し示されていた www2.ascii.jp は? …ともちゃさんご指摘のままだ…いいのか? これ…

ではではでは、 www3.ascii.jp は??!

Apache 2 Test Page
powered by CentOS

…おいっっ!!! いきなりかっ!!! いきなりテストページですかっっ!! インストールしたままのっ!!!!
それは、渋谷の町を下着姿で歩いているのと一緒だっ!!!
とっとと上着を着ろっっ!!!!

ちなみに、www4.ascii.jp はエラーになった。よかったよかった。

RAWデータを操れるのか…UFRaw…こりゃ便利だ

2009-05-06T18:46:00.004+09:00

デジカメとしてニコンのD70 と PanasonicのLUMIX-G1 を持っている。で、この2つのカメラ、どちらも RAW フォーマットをサポートしている。

サポートしているのはよいのだが、これを読み込むためのソフトがPhotoshop等の有料ソフトしかなかった。メーカーごとにフォーマットが違い、JPEGのように標準化されていないからだ。そのため、今まではJPEGで撮影していたのだが…

UFRawというソフトがある事を知った。各社のRawファイルを読み込み、ある程度の色調調整などは自分でもできるソフト。
最大のポイントはGIMPのプラグインとしても動作するので、RAWデータをGIMPで操作して、結果を別のフォーマットなどにも保存できることだろう。

G1はRawとJpegを同時保存できるので、それで見ていると、たまにバグって色調がおかしくなっている場合があるが、それ以外は快調。

今までは操作もできなければプレビューすらできないRawモードは避けてきたんだけれど、これからは使ってみようかと思う。

複数のクレジットカードを持つのは効果的なのか?

2009-04-11T17:30:00.005+09:00

いま、あちこちの銀行の定期預金とかの利率を調べている。金額的には100万円未満の利率。期間的には3年以内。円建てに限定する。

一例としては、こんな感じ。

みずほ銀行	普通預金金利	0.040％
	定期預金	0.15％ - 0.25％
	貯蓄預金	0.07％
三菱東京UFJ銀行	普通預金	年0.040％
	スーパー普通預金	年0.050％
	スーパー定期	年0.150％ - 年0.250％
	自由金利型定期預金（大口定期）	年0.150％ - 年0.350％
	貯蓄預金	年0.040％ - 年0.050％

見ての通り、出し入れ自由だと 0.04% - 0.05%, 出し入れ不自由だと 0.15% - 0.35% と言った所。3年預けたとして、利子は

0.04%	1.0004^3 = 1.00120048	0.12%
0.05%	1.0005^3 = 1.00150075	0.15%
0.15%	1.0015^3 = 1.00450675	0.45%
0.35%	1.0035^3 = 1.01053679	1.05%

と言った所。

なぜこんなことを計算しているかと言うと、実はこの本を読んでいるから。

この「新・資本論」という本の中に、こういう記述があるのだ。

日本でお金を稼いだとき、私はそれを三つに分けることを推奨する。三分の一をドルに、三分の一をユーロに、そして残りを円建ての金融商品に転換するのである。(p.142)

為替相場が乱高下しているときに「三分の一」にするのはどうかと思うが、これは結構面白いポイントをついていると思う。つまりこういうことを考えるのだ：

普段から銀行口座を3種類持つ。ドル建て、円建て、ユーロ建ての3つ。
そして、それぞれに対してクレジットカードを1つづつ作る。
収入を得たら、日常に使うお金は円建てに、残りを為替相場に応じて、適当に分配する。

何か買い物をする場合は、そのときの為替相場を考慮して、もっとも効果的な口座から引き落とされるカードを利用する。

例えば円高ドル安ユーロ安の場合は、すべての決済を円口座カードで済ませる。また、ドルやユーロ建ての講座に多い目にお金を預ける。

逆に円安ドル高になったら、決済をドル口座カードで済ませる。この場合、円高ドル安だった頃に買ったドルで決済をすることになるので、為替差額がそのまま利子として働く。

このような運用をした場合と、すべてを円建てで運用して定期預金などを使った場合と、どっちがお徳か考えてみよう、というわけ。話を簡単にするために、期間は3年限定とする。また、為替相場は現在の1ドル100円を基準として、1ドル最低95円、最高105円の範囲で動くとしよう。ユーロは考えない。とりあえず面倒だから。最後に、カード破産はしない、という前提も必要だね。

ようするに、1ドル95-100円の範囲の場合、ドル建てを 60%, 円建てを40%で、100-105円の場合、ドル建てを40%, 円建てを60%で普通預金に入れる事を考える。どうせ利子は付かないに等しいので、考慮しない。

一方で、消費する場合は1ドル95-100円の範囲の場合は円建てカードを優先、100-105円の場合はドル建てカードを優先で使うことにする。不足したらもう一方のカードで支払う。

これをすべて円建てで見ると、円建て口座の方は入れた金額が貯蓄金額だ。一方でドル建て口座の方は、1ドル97.5円平均で入金して、1ドル102.5円平均で出金することになる。利子としては 5.12% ついているのに等しい。円とドル半々で利用するので、実質利子はこの半分、2.5%…さらに不足分が出た場合のソンを考慮すると… 2%ぐらいか。

なんだ。

各通貨の銀行預金を作り、それぞれを引き落とし先とするクレジットカードを作り、為替相場に応じてどのカードで引き落とすかを変える
という比較的リスクの少ない戦略を使っただけでも、銀行の定期預金よりも利率が良い結果になるじゃないか。

解答を書いておく -3- 部分解の2

2009-03-07T19:32:00.003+09:00

request2

meminfo.awk が存在する、と言う前提からはじめる。

SLAB=$(( awk -f meminfo.awk /proc/meminfo >> $LOGFILE ) 2>&1 )

で $SLAB に現在の /proc/meminfo 中のSLABの値が取得できているとしよう。他に次のような値を bash スクリプトレベルで取得、定義できているとする。

# We only have 876Mbytes of memory space for kernel.
KERNELMEMORY=$( expr 876*1024 )
PREVIOUSSTATE="GREEN"

# 358809kbyte is 40% of 876*1024Kbytes
YELLOWBORDERSIZE=358809

# or define this.
# YELLOWLIMIT=0.4

# 627916kbyte is 70% of 876*1024Kbytes
REDBORDERSIZE=627916

# or define this.
# REDLIMIT=0.7

KERNELMEMORY はコメントにあるとおり。32bit モードの Linux は 876Mbyteしかカーネル用空間が無いのでこれが利用できる最大値。

PREVIOUSSTATEは「前回計算した際のステート」。ステートは GREEN, YELLOW, RED のどれかしかないとし、全部文字列で表すことにする。

YELLOWBORDERSIZE は Slab がこの値を超えていたらステートを YELLOW として出力する値。
YELLOWLIMIT は KERNELMEMORY サイズにこの値を乗じて得られた結果を YELLOWBORDERSIZE として用いる、という値。
もし、YELLOWLIMIT と YELLOWBORDERSIZE の両方が定義されていたらどちらか小さい方を採択する。
片方がそんざいしてもう一方が存在しないなら、存在する方が有効になる。どちらも存在しなければ YELLOWBORDERSIZE=358809 が定義されているものとして処理する。

REDBORDERSIZE は Slab がこの値を超えていたらステートを RED として出力する値。
REDLIMIT は KERNELMEMORY サイズにこの値を乗じて得られた結果を REDBORDERSIZE として用いる、という値。
もし、REDLIMIT と REDBORDERSIZE の両方が定義されていたらどちらか小さい方を採択する。
片方がそんざいしてもう一方が存在しないなら、存在する方が有効になる。どちらも存在しなければ REDBORDERSIZE=627916 が定義されているものとして処理する。

もし、YELLOWLIMIT や YELLOWBORDERSIZE が何らかの理由で REDLIMIT や REDBORDERSIZE よりも大きい場合は、自動的に REDLIMIT, REDBORDERSIZE と同じ値にまで下がったものとみなす。

何らかの理由でREDLIMIT, REDBORDERSIZE が KERNELMEMORY 以上の値になった場合は、REDBORDERSIZE=$KERNELMEMORY と見なす。これが意味のある制約かどうかは微妙だが…。

YELLOWLIMIT, YELLOWBORDERSIZE が 0以下の場合はデフォルト値が採択される。

REDLIMIT, REDBORDERSIZE が 0以下の場合はデフォルト値が採択される。

これで判るとおり、実は境界問題はかなり厄介な問題をはらんでいる。与える境界値が適切な場合は特に問題ないのだが、境界値が異常値の場合、妥当に動かすのは著しく困難を伴う。その最大の理由は、プログラマが妥当な状態を決めなくてはいけないからだ。

この問題の本当の難しいところは、条件判断ではない。

妥当ではない計算条件を与えられたときに、それをいかにして跳ね除けるか、という点だ。

さて、プログラムだ。浮動小数点演算を bash で実行するのは難しいので、awk で実装する。いくつかの定数については、awk側に埋め込む。残りの引数は gawk の -v オプションを用いて引き渡す。

CalculateStatus.awk

#! /bin/gawk -f
BEGIN {
  KERNELMEMORY = 876 * 1024;
  DefaultYELLOWBORDERSIZE = 358809;
  DefaultREDBORDERSIZE    = 627916;
  GreenName               = "GREEN";
  YellowName              = "YELLOW";
  RedName                 = "RED";


# First, calucate PreYELLOWBORDERSIZE without thinking about RED.
  if ( YELLOWLIMIT > 0 ) {
    PreYELLOWBORDERSIZE  = KERNELMEMORY * YELLOWLIMIT;
  } else {
    PreYELLOWBORDERSIZE  = 0;
  }
  if ( YELLOWBORDERSIZE > 0 ) {
    if ( PreYELLOWBORDERSIZE > 0 ) {
      if ( PreYELLOWBORDERSIZE > YELLOWBORDERSIZE ) {
        PreYELLOWBORDERSIZE = YELLOWBORDERSIZE;
      }
    } else {
        PreYELLOWBORDERSIZE = YELLOWBORDERSIZE;
    }
  } else {
    PreYELLOWBORDERSIZE = DefaultYELLOWBORDERSIZE;
  }

# First, calucate PreREDBORDERSIZE without thinking about YELLOW.
  if ( REDLIMIT > 0 ) {
    PreREDBORDERSIZE  = KERNELMEMORY * REDLIMIT;
  } else {
    PreREDBORDERSIZE  = 0;
  }
  if ( REDBORDERSIZE > 0 ) {
    if ( PreREDBORDERSIZE > 0 ) {
      if ( PreREDBORDERSIZE > REDBORDERSIZE ) {
        PreREDBORDERSIZE = REDBORDERSIZE;
      }
    } else {
        PreREDBORDERSIZE = rEDBORDERSIZE;
    }
  } else {
    PreREDBORDERSIZE = DefaultREDBORDERSIZE;
  }

# OK. Re-calculate YELLOW according to RED.
  if ( PreREDBORDERSIZE < PreYELLOWBORDERSIZE ) {
    PreYELLOWBORDERSIZE = PreREDBORDERSIZE;
  }

  YELLOWBORDERSIZE = PreYELLOWBORDERSIZE;
  REDBORDERSIZE    = PreREDBORDERSIZE;

  if ( SLAB > REDBORDERSIZE ) {
      NewStatus   = RedName;
  } else if ( Slab > YELLOWBORDERSIZE ) {
      NewStatus   = YellowName;
  } else {
      NewStatus   = GreenName;
  }

# Ok. check old status in mind.
  if ( PREVIOUSSTATE == RedName ) {
    NewStatus     = RedName;
  } else if (( PREVIOUSSTATE == YellowName )&&( NewStatus = GreenName )) {
    NewStatus     = YellowName;
  }

  print NewStatus;
  exit 0;
}

結果は stdout で出て行くので、bash 変数に取り込めばよい。

解答を書いておく -2- 部分解

2009-03-01T20:26:00.004+09:00

まずは request3 から

request3 は比較的簡単だ。sed でも awk でもできる。

sed ならばこう:

sed 's/^/# /g' /proc/slabinfo

awk ならばこう:

awk '{ print "# " $0; }' /proc/slabinfo

awk の場合は正規表現を必要としない分早いかもしれない。でもそもそも sed の方がプログラムとして小さいのでこちらの方が早いかもしれない。どちらがいいのかはよく判らない。

つぎに request1

/proc/meminfo の各行から数字の部分を切り出すだけなら

awk '{ print $2; }' /proc/meminfo

だけで済む。しかしここには悪魔が潜んでいる。

難しいポイントは3つ。

時刻を出力する

/proc/meminfo の中身の順序がカーネル依存である

/proc/meminfo の Slab フィールドの値は、request2 でも使う

時刻を出力するには、最初に date 出力を getline で取得すればよい。

BEGIN {
  "date +"%Y/%m/%d %H:%M:%S" | getline DATEVAL;
  DATETAG="date";
}

/proc/meminfo の中身自体は適当なバージョンにあわせるとしよう。':' よりも左側の文字列を取ってくるには:

sed 's/^\(.*\):.*$/\1/g' /proc/meminfo

とやればよい。結果として

MemTotal
MemFree
Buffers
Cached
SwapCached
:

のような出力が得られる。これをベースに、<各エントリ名>TAG という変数と、<各エントリ名>VALという変数を作ろう。こんな感じだ:

for i in $(sed 's/^\(.*\):.*$/\1/g' /proc/meminfo ); do
  echo "/^${i}:/ { ${i}VAL = \$2; ${i}TAG=\"${i}\"; }"
done

結果はこんな感じになる。

/^MemTotal:/ { MemTotalVAL = $2; MemTotalTAG="MemTotal"; }
/^MemFree:/ { MemFreeVAL = $2; MemFreeTAG="MemFree"; }
/^Buffers:/ { BuffersVAL = $2; BuffersTAG="Buffers"; }
/^Cached:/ { CachedVAL = $2; CachedTAG="Cached"; }
/^SwapCached:/ { SwapCachedVAL = $2; SwapCachedTAG="SwapCached"; }
:

各行が awk スクリプトにおける「対応する値をとってくるためのスクリプト」になっている。
同様にして、出力するコードを吐かせる。

for i in $(sed 's/^\(.*\):.*$/\1/g' meminfo ); do
  echo " printf(\"\\\"\" ${i}VAL \"\\\"\\t\" );"
done

結果はこんな感じ。

 printf("\"" MemTotalVAL "\"\t" );
 printf("\"" MemFreeVAL "\"\t" );
 printf("\"" BuffersVAL "\"\t" );
 printf("\"" CachedVAL "\"\t" );
 printf("\"" SwapCachedVAL "\"\t" );
:

あと、「VAL」の部分を「TAG」に変えたものも用意する。

TAGをいつ出力するのか、その制御は bash 側からすることにしよう。PRINTTAGという変数を用意して、これが 0 だったら TAG を出さない。それ以外だったら出す。

printf の最後の要素だけは \t を \n に直す。また、date を出力するコードを加える。

以上を全部行うとこうなる:

BEGIN {
  "date +'%Y/%m/%d %H:%M:%S'" | getline DATEVAL;
  DATETAG="date";
}

/^MemTotal:/ { MemTotalVAL = $2; MemTotalTAG="MemTotal"; }
/^MemFree:/ { MemFreeVAL = $2; MemFreeTAG="MemFree"; }
/^Buffers:/ { BuffersVAL = $2; BuffersTAG="Buffers"; }
/^Cached:/ { CachedVAL = $2; CachedTAG="Cached"; }
/^SwapCached:/ { SwapCachedVAL = $2; SwapCachedTAG="SwapCached"; }
/^Active:/ { ActiveVAL = $2; ActiveTAG="Active"; }
/^Inactive:/ { InactiveVAL = $2; InactiveTAG="Inactive"; }
/^HighTotal:/ { HighTotalVAL = $2; HighTotalTAG="HighTotal"; }
/^HighFree:/ { HighFreeVAL = $2; HighFreeTAG="HighFree"; }
/^LowTotal:/ { LowTotalVAL = $2; LowTotalTAG="LowTotal"; }
/^LowFree:/ { LowFreeVAL = $2; LowFreeTAG="LowFree"; }
/^SwapTotal:/ { SwapTotalVAL = $2; SwapTotalTAG="SwapTotal"; }
/^SwapFree:/ { SwapFreeVAL = $2; SwapFreeTAG="SwapFree"; }
/^Dirty:/ { DirtyVAL = $2; DirtyTAG="Dirty"; }
/^Writeback:/ { WritebackVAL = $2; WritebackTAG="Writeback"; }
/^Mapped:/ { MappedVAL = $2; MappedTAG="Mapped"; }
/^Slab:/ { SlabVAL = $2; SlabTAG="Slab"; }
/^CommitLimit:/ { CommitLimitVAL = $2; CommitLimitTAG="CommitLimit"; }
/^Committed_AS:/ { Committed_ASVAL = $2; Committed_ASTAG="Committed_AS"; }
/^PageTables:/ { PageTablesVAL = $2; PageTablesTAG="PageTables"; }
/^VmallocTotal:/ { VmallocTotalVAL = $2; VmallocTotalTAG="VmallocTotal"; }
/^VmallocUsed:/ { VmallocUsedVAL = $2; VmallocUsedTAG="VmallocUsed"; }
/^VmallocChunk:/ { VmallocChunkVAL = $2; VmallocChunkTAG="VmallocChunk"; }
/^HugePages_Total:/ { HugePages_TotalVAL = $2; HugePages_TotalTAG="HugePages_Total"; }
/^HugePages_Free:/ { HugePages_FreeVAL = $2; HugePages_FreeTAG="HugePages_Free"; }
/^Hugepagesize:/ { HugepagesizeVAL = $2; HugepagesizeTAG="Hugepagesize"; }

END {
    if ( PRINTTAG != 0 ) {
        printf("\"" DATETAG "\"\t" );
        printf("\"" MemTotalTAG "\"\t" );
        printf("\"" MemFreeTAG "\"\t" );
        printf("\"" BuffersTAG "\"\t" );
        printf("\"" CachedTAG "\"\t" );
        printf("\"" SwapCachedTAG "\"\t" );
        printf("\"" ActiveTAG "\"\t" );
        printf("\"" InactiveTAG "\"\t" );
        printf("\"" HighTotalTAG "\"\t" );
        printf("\"" HighFreeTAG "\"\t" );
        printf("\"" LowTotalTAG "\"\t" );
        printf("\"" LowFreeTAG "\"\t" );
        printf("\"" SwapTotalTAG "\"\t" );
        printf("\"" SwapFreeTAG "\"\t" );
        printf("\"" DirtyTAG "\"\t" );
        printf("\"" WritebackTAG "\"\t" );
        printf("\"" MappedTAG "\"\t" );
        printf("\"" SlabTAG "\"\t" );
        printf("\"" CommitLimitTAG "\"\t" );
        printf("\"" Committed_ASTAG "\"\t" );
        printf("\"" PageTablesTAG "\"\t" );
        printf("\"" VmallocTotalTAG "\"\t" );
        printf("\"" VmallocUsedTAG "\"\t" );
        printf("\"" VmallocChunkTAG "\"\t" );
        printf("\"" HugePages_TotalTAG "\"\t" );
        printf("\"" HugePages_FreeTAG "\"\t" );
        printf("\"" HugepagesizeTAG "\"\n" );
    }

    printf("\"" DATEVAL "\"\t" );
    printf("\"" MemTotalVAL "\"\t" );
    printf("\"" MemFreeVAL "\"\t" );
    printf("\"" BuffersVAL "\"\t" );
    printf("\"" CachedVAL "\"\t" );
    printf("\"" SwapCachedVAL "\"\t" );
    printf("\"" ActiveVAL "\"\t" );
    printf("\"" InactiveVAL "\"\t" );
    printf("\"" HighTotalVAL "\"\t" );
    printf("\"" HighFreeVAL "\"\t" );
    printf("\"" LowTotalVAL "\"\t" );
    printf("\"" LowFreeVAL "\"\t" );
    printf("\"" SwapTotalVAL "\"\t" );
    printf("\"" SwapFreeVAL "\"\t" );
    printf("\"" DirtyVAL "\"\t" );
    printf("\"" WritebackVAL "\"\t" );
    printf("\"" MappedVAL "\"\t" );
    printf("\"" SlabVAL "\"\t" );
    printf("\"" CommitLimitVAL "\"\t" );
    printf("\"" Committed_ASVAL "\"\t" );
    printf("\"" PageTablesVAL "\"\t" );
    printf("\"" VmallocTotalVAL "\"\t" );
    printf("\"" VmallocUsedVAL "\"\t" );
    printf("\"" VmallocChunkVAL "\"\t" );
    printf("\"" HugePages_TotalVAL "\"\t" );
    printf("\"" HugePages_FreeVAL "\"\t" );
    printf("\"" HugepagesizeVAL "\"\n" );
}

このスクリプト全体を、meminfo1.awk として保存する。で、/proc/meminfo を食わせてみるとこんな感じになる。

$ gawk -v PRINTTAG=1 -f meminfo1.awk /proc/meminfo 
"date" "MemTotal" "MemFree" "Buffers" "Cached" "SwapCached" "Active" "Inactive" "HighTotal" "HighFree" "LowTotal" "LowFree" "SwapTotal" "SwapFree" "Dirty" "Writeback" "Mapped" "Slab" "CommitLimit" "Committed_AS" "PageTables" "VmallocTotal" "VmallocUsed" "VmallocChunk" "HugePages_Total" "HugePages_Free" "Hugepagesize"
"2009/03/01 23:00:00" "1001008" "200708" "43400" "395740" "0" "557556" "178624" "97216" "140" "903792" "200568" "2096472" "2096472" "224" "0" "356492" "47820" "2596976" "689048" "6192" "114680" "4560" "107264" "0" "0" "2048"
$ gawk -v PRINTTAG=0 -f meminfo1.awk /proc/meminfo 
"2009/03/01 23:00:37" "1001008" "200708" "43400" "395740" "0" "557556" "178624" "97216" "140" "903792" "200568" "2096472" "2096472" "224" "0" "356492" "47820" "2596976" "689048" "6192" "114680" "4560" "107264" "0" "0" "2048"
$ gawk -f meminfo1.awk /proc/meminfo 
"2009/03/01 23:00:37" "1001008" "200708" "43400" "395740" "0" "557556" "178624" "97216" "140" "903792" "200568" "2096472" "2096472" "224" "0" "356492" "47820" "2596976" "689048" "6192" "114680" "4560" "107264" "0" "0" "2048"

-v を使って PRINTTAG 変数をスクリプト外部から制御した。最後の -v を指定しない例は、ようするに「デフォルトの挙動」と言う奴になる。

やれこれで一安心…ではない。Slab の値だけ、別途別パスで外に出してやる必要がある。幸い、stderr という文明の利器があるのでこれを使う。

    print SlabVAL > "/dev/stderr";

これを END {} セクションの最後に加えるのだ。そうすると Slabの数字の部分だけが stderr で取り出せる。

request1に対する最終 meminfo.awk スクリプトはこうなる:

BEGIN {
  "date +'%Y/%m/%d %H:%M:%S'" | getline DATEVAL;
  DATETAG="date";
}

/^MemTotal:/ { MemTotalVAL = $2; MemTotalTAG="MemTotal"; }
/^MemFree:/ { MemFreeVAL = $2; MemFreeTAG="MemFree"; }
/^Buffers:/ { BuffersVAL = $2; BuffersTAG="Buffers"; }
/^Cached:/ { CachedVAL = $2; CachedTAG="Cached"; }
/^SwapCached:/ { SwapCachedVAL = $2; SwapCachedTAG="SwapCached"; }
/^Active:/ { ActiveVAL = $2; ActiveTAG="Active"; }
/^Inactive:/ { InactiveVAL = $2; InactiveTAG="Inactive"; }
/^HighTotal:/ { HighTotalVAL = $2; HighTotalTAG="HighTotal"; }
/^HighFree:/ { HighFreeVAL = $2; HighFreeTAG="HighFree"; }
/^LowTotal:/ { LowTotalVAL = $2; LowTotalTAG="LowTotal"; }
/^LowFree:/ { LowFreeVAL = $2; LowFreeTAG="LowFree"; }
/^SwapTotal:/ { SwapTotalVAL = $2; SwapTotalTAG="SwapTotal"; }
/^SwapFree:/ { SwapFreeVAL = $2; SwapFreeTAG="SwapFree"; }
/^Dirty:/ { DirtyVAL = $2; DirtyTAG="Dirty"; }
/^Writeback:/ { WritebackVAL = $2; WritebackTAG="Writeback"; }
/^Mapped:/ { MappedVAL = $2; MappedTAG="Mapped"; }
/^Slab:/ { SlabVAL = $2; SlabTAG="Slab"; }
/^CommitLimit:/ { CommitLimitVAL = $2; CommitLimitTAG="CommitLimit"; }
/^Committed_AS:/ { Committed_ASVAL = $2; Committed_ASTAG="Committed_AS"; }
/^PageTables:/ { PageTablesVAL = $2; PageTablesTAG="PageTables"; }
/^VmallocTotal:/ { VmallocTotalVAL = $2; VmallocTotalTAG="VmallocTotal"; }
/^VmallocUsed:/ { VmallocUsedVAL = $2; VmallocUsedTAG="VmallocUsed"; }
/^VmallocChunk:/ { VmallocChunkVAL = $2; VmallocChunkTAG="VmallocChunk"; }
/^HugePages_Total:/ { HugePages_TotalVAL = $2; HugePages_TotalTAG="HugePages_Total"; }
/^HugePages_Free:/ { HugePages_FreeVAL = $2; HugePages_FreeTAG="HugePages_Free"; }
/^Hugepagesize:/ { HugepagesizeVAL = $2; HugepagesizeTAG="Hugepagesize"; }

END {
    if ( PRINTTAG != 0 ) {
        printf("\"" DATETAG "\"\t" );
        printf("\"" MemTotalTAG "\"\t" );
        printf("\"" MemFreeTAG "\"\t" );
        printf("\"" BuffersTAG "\"\t" );
        printf("\"" CachedTAG "\"\t" );
        printf("\"" SwapCachedTAG "\"\t" );
        printf("\"" ActiveTAG "\"\t" );
        printf("\"" InactiveTAG "\"\t" );
        printf("\"" HighTotalTAG "\"\t" );
        printf("\"" HighFreeTAG "\"\t" );
        printf("\"" LowTotalTAG "\"\t" );
        printf("\"" LowFreeTAG "\"\t" );
        printf("\"" SwapTotalTAG "\"\t" );
        printf("\"" SwapFreeTAG "\"\t" );
        printf("\"" DirtyTAG "\"\t" );
        printf("\"" WritebackTAG "\"\t" );
        printf("\"" MappedTAG "\"\t" );
        printf("\"" SlabTAG "\"\t" );
        printf("\"" CommitLimitTAG "\"\t" );
        printf("\"" Committed_ASTAG "\"\t" );
        printf("\"" PageTablesTAG "\"\t" );
        printf("\"" VmallocTotalTAG "\"\t" );
        printf("\"" VmallocUsedTAG "\"\t" );
        printf("\"" VmallocChunkTAG "\"\t" );
        printf("\"" HugePages_TotalTAG "\"\t" );
        printf("\"" HugePages_FreeTAG "\"\t" );
        printf("\"" HugepagesizeTAG "\"\n" );
    }

    printf("\"" DATEVAL "\"\t" );
    printf("\"" MemTotalVAL "\"\t" );
    printf("\"" MemFreeVAL "\"\t" );
    printf("\"" BuffersVAL "\"\t" );
    printf("\"" CachedVAL "\"\t" );
    printf("\"" SwapCachedVAL "\"\t" );
    printf("\"" ActiveVAL "\"\t" );
    printf("\"" InactiveVAL "\"\t" );
    printf("\"" HighTotalVAL "\"\t" );
    printf("\"" HighFreeVAL "\"\t" );
    printf("\"" LowTotalVAL "\"\t" );
    printf("\"" LowFreeVAL "\"\t" );
    printf("\"" SwapTotalVAL "\"\t" );
    printf("\"" SwapFreeVAL "\"\t" );
    printf("\"" DirtyVAL "\"\t" );
    printf("\"" WritebackVAL "\"\t" );
    printf("\"" MappedVAL "\"\t" );
    printf("\"" SlabVAL "\"\t" );
    printf("\"" CommitLimitVAL "\"\t" );
    printf("\"" Committed_ASVAL "\"\t" );
    printf("\"" PageTablesVAL "\"\t" );
    printf("\"" VmallocTotalVAL "\"\t" );
    printf("\"" VmallocUsedVAL "\"\t" );
    printf("\"" VmallocChunkVAL "\"\t" );
    printf("\"" HugePages_TotalVAL "\"\t" );
    printf("\"" HugePages_FreeVAL "\"\t" );
    printf("\"" HugepagesizeVAL "\"\n" );

    print SlabVAL > "/dev/stderr";
}

STDOUT はログファイルに出力させる。その後 STDERR を stdout にリダイレクトして、変数に食わせてやる。実行する側のシェルはこんな感じ:

SLAB=$(( awk -f meminfo.awk /proc/meminfo >> $LOGFILE ) 2>&1 )

これで SLAB 変数には Slab: の数字のフィールドが入り、かつ全部の出力が $LOGFILE に出力される。

解答を書いておく -1- 課題

2009-03-01T10:26:00.009+09:00

仕事で、ある人にスクリプト作成を依頼している。
内容的には単純なのだが、ちょっとややこしい部分があって、論理的に考えないと答が出ないようになっている。半分、演習問題のようなテーマだ。

順調に遅延しているのはいいのだが、私自身他に3件も受け持っているので、
「いざ、もう間に合いません」
と言うときになってからスクリプトを書き始めると、ちょっと間に合わなかったりする。なので、ここに模範解答の形で答を書いておこうか、と思う。いざとなったらここを参照すればよいわけだ。

他の人の演習問題にもなったらな、と思うので、問題も全部公開しよう。秘密といえるような部分は一切無い。

課題

request1

/proc/meminfo の内容を定期的に参照して欲しい。/proc/meminfo のデータは1項目一行形式になっているので、これを1行の TSV に直して欲しい。最初の一回だけ、どの項目がどこにあるのかを示すラベルもつけて欲しい。また、最初の要素に、/proc/meminfo の情報をいつ取得したのか、date の情報を "YYYY/MM/DD hh:mm:ss" の形式で保存して欲しい。

request2

/proc/meminfo には Slab という項目がある。ここの値がある閾値を超えたら、定期的に参照するその参照頻度を上げて欲しい。ようするにデータを取る間隔を短くして欲しいのだ。問題は、いったん間隔を短くしたら、二度と長くしないで欲しい、と言うことと、「閾値」は2つ、Yellow と Red があるので、それぞれに応じて間隔を短くして欲しい。また、この閾値はあとで簡単に変更できるように、スクリプトの上のほうの行で名前で宣言して欲しい。もちろん、その際の「間隔」もそれぞれ名前で宣言しておいて欲しい。

request3

Yellow の閾値を超えたら /proc/slabinfo のデータも取ってきて欲しい。こちらは、/proc/slabinfo のファイルの情報の各行の前に "# " (シャープがきて、その次に空白が1つ) をつけた形で、/proc/meminfo のデータを保存しているログファイルと同じ所に保存して欲しい。

課題の詳細

request1

/proc/meminfo を読んでくると次のようなフォーマットで値が出力される。

MemTotal:      1001008 kB
MemFree:        200708 kB
Buffers:         43400 kB
Cached:         395740 kB
SwapCached:          0 kB
Active:         557556 kB
Inactive:       178624 kB
HighTotal:       97216 kB
HighFree:          140 kB
LowTotal:       903792 kB
LowFree:        200568 kB
SwapTotal:     2096472 kB
SwapFree:      2096472 kB
Dirty:             224 kB
Writeback:           0 kB
Mapped:         356492 kB
Slab:            47820 kB
CommitLimit:   2596976 kB
Committed_AS:   689048 kB
PageTables:       6192 kB
VmallocTotal:   114680 kB
VmallocUsed:      4560 kB
VmallocChunk:   107264 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB

request 1 はようするにこれを


"1001008"<tab>"200708"<tab>"43400"....

のように1行に直して欲しい、という事だ。ただし、<tab> の部分は実際にはタブ文字コード (awk とかだと "\t")で分けて欲しい。また、数字は " で囲ってもらえると助かる。

また、最初の1回だけラベルの部分も欲しい。これはつまり

"MemTotal"<tab>"MemFree"<tab>"Buffers"....

のような行を出して欲しい、と言うこと。

さらに、一番最初にデータを取得した情報が欲しい、とある。これはようするに

date +"%Y/%m/%d %H:%M:%S"

の出力を取り込んで、最初に表示して欲しい、という事だ。当然ラベル行も実際には:

"date"<tab>"MemTotal"<tab>"MemFree"<tab>"Buffers"....

でなくては困る。

request2

/proc/meminfo のSlab:の項目が 358809 未満を Green,
358809 以上 627916 未満を Yellow,
627916 以上を Red
という状態とする。これは32bit Linux Kernel のメモリ領域が 876Mbyte しかなく、それぞれ 40%、70% の所に閾値を用意した、という事だ。実際には Slab が Yellow になることすらめったに無いはずで、Red に突入したら、間違いなく oom-killer が近々発動するだろう。その傾向を見たいのだ。

状態が Green の間は 300秒(5分)間隔で request1 を実施して欲しい。
Yellow になったら 60秒(1分)間隔で request1 と request3 を実施して欲しい。
Red になったら 30秒間隔で request1 と request3 を実施して欲しい。

いったん Yellow になったら、Slab の値が改善しても Green には戻らないで欲しい。同様に Red になったら、Yellow, Green には戻ってはいけない。なので、「今回の Slab の値だけで、次にデータ取得するまでの間隔を決める」のでは困る。

request3

cat /proc/slabinfo を実施するとこんな感じの出力が得られる。

slabinfo - version: 1.1
kmem_cache            60     78    100    2    2    1
blkdev_requests     5120   5120     96  128  128    1
mnt_cache             20     40     96    1    1    1
inode_cache         7005  14792    480 1598 1849    1
dentry_cache        5469   5880    128  183  196    1
filp                 726    760     96   19   19    1
buffer_head        67131  71240     96 1776 1781    1
vm_area_struct      1204   1652     64   23   28    1

これの頭に "# " をつけて

# slabinfo - version: 1.1
# kmem_cache            60     78    100    2    2    1
# blkdev_requests     5120   5120     96  128  128    1
# mnt_cache             20     40     96    1    1    1
# inode_cache         7005  14792    480 1598 1849    1
# dentry_cache        5469   5880    128  183  196    1
# filp                 726    760     96   19   19    1
# buffer_head        67131  71240     96 1776 1781    1
# vm_area_struct      1204   1652     64   23   28    1

としてほしいわけだ。これは、/proc/meminfo の次の行から出力して欲しい。だから:

"2009/03/01 10:48:58"<tab>"1001008"<tab>"200708"<tab>"43400"....
# slabinfo - version: 1.1
# kmem_cache            60     78    100    2    2    1
# blkdev_requests     5120   5120     96  128  128    1
# mnt_cache             20     40     96    1    1    1
# inode_cache         7005  14792    480 1598 1849    1
# dentry_cache        5469   5880    128  183  196    1
# filp                 726    760     96   19   19    1
# buffer_head        67131  71240     96 1776 1781    1
# vm_area_struct      1204   1652     64   23   28    1

  :

のような出力が延々続くログファイルが欲しい、という事になる。

背景

oom-killer が発動したシステムがあった。
/var/log/messages に残る oom-killer の行動痕跡によると、slab が異常に大きい。
そこで、slab の状態を記録すると同時に、自分たちが何をやっていたのかを記録する。

slab がでかくなったタイミングで何をやっていたのか知れば、問題点がわかるに違いない。そのための監視用ログシステムが欲しい、と言うわけ。

参考資料

スクリプト言語であれば何を使っても良かったのだが、とりあえず bash と sed と awk ということなので、参考資料は次の通り。

似たようなことがしてみたい人へ

2009-02-13T01:07:00.004+09:00

えー、一応。似たようなことをしたい人がいる可能性を考えて、参考資料を。まずは上司/スポンサー説得資料。

基本的にこれらの本に書いてあるのとやっていることは同じである、と主張しても大きく嘘にはならないと思います。いや、本当に同じ様なことをしているんですけれどね。統計学を仕事に応用しているんだし。ただ、あまりすさまじくかっこいい具合にありえないようなものを発見できる、と言う風に誤解されるとそれはそれで後が大変でしょうから、こう…加減と言うものは各自で調整してください。

で、これで何を手に入れるかと言うと、もちろん「計算機」です。大事なのは「64bit」と「メモリがたくさん」。いまどきのx86マシンならば EM64T対応な段階で SSEとかも相応に早いです。もちろん、Core2Duo とか Core2Quad とか Corei7 とかがいいわけですが、動作クロックは最低でも構わないかと。むしろ大事なのはメモリ。

Windows はやめておいた方がよいです。メモリの利用効率が悪い、あれは。ファイルキャッシュのデザインが unix 以前(1969年以前、と言うこと)のOSそっくりだ。計算用データを保持するために1pageでも余計にメモリを使いたいときに、ガッツリ kernel 内部のファイルキャッシュがページを握って離さない、というWindows NT/Longhorn デザインは勘弁して欲しい(つーか Windows7 では是非その辺りも改善していただきたいものだ)。と言うわけで、とりあえずお勧めは Linux 。マルチコア、HT対応、Intel & AMD 御謹製のプロセッサコントロールコードが使えるのは Linux ぐらいですから。

次に。あなた自身のための入門本。

多分、この一冊と Wikipedia 辺りが入門には丁度良いのではないかと。もちろん、前出の2冊も読んでいただくのですがあれは「どういう場面で統計を使うか」なのに対して、ここからは「その場面で何を使うか」。

で、最後に「なんとなく判ったけど、コーディングが面倒だな」とか「もっと詳しく知りたいが、できれば数学的なほうじゃなくて…」という人のための本。

多分これぐらいあれば、1年はここに書いてある内容で遊べます。

えぇ、「遊んで暮らせます」というオチだったらよかったんですけどねぇ。残念ながらそこまでは…

okkyの銀河制圧奇譚

sched_clock() overflow after 208.5 days in Linux Kernel

lunar eclipse

ホームゲート

< 2.6.17 な Linux に存在する flock の double free バグ

Brave to stay

リサイクルループに着目しよう

【DS】A列車で行こうDS 「青葉経済開発区」「標準」

【DS】A列車で行こうDS 「青葉湾岸工業区」「いばらの道」

【DS】A列車で行こうDS 「青葉湾岸工業区」「標準」

【DS】A列車で行こうDS -1- 「青葉リゾート区」「いばらの道」 -1-

【DS】A列車で行こうDS -1- 「青葉リゾート区」「標準」 -2-

【DS】A列車で行こうDS -1- 「青葉リゾート区」「標準」 -1-

【DS】A列車で行こうDS -1- 「青葉経済開発区」「やさしい」 -4-

札幌へ行ってきた -2-

札幌へ行ってきた -1-

新人じゃなくなった人は何を気にするべきか -8- まとめ

新人じゃなくなった人は何を気にするべきか -7- I18N/L10N

新人じゃなくなった人は何を気にするべきか -6- Announcement

新人じゃなくなった人は何を気にするべきか -5.2- エージェンシー

モラル・ハザード

逆淘汰

新人じゃなくなった人は何を気にするべきか -5.1- 取引コスト

新人じゃなくなった人は何を気にするべきか -5- Communication

新人じゃなくなった人は何を気にするべきか -4- Who is Customer

新人じゃなくなった人は何を気にするべきか -3.3- off demand

新人じゃなくなった人は何を気にするべきか -3.2- 機械化

新人じゃなくなった人は何を気にするべきか -3.1- 分割

新人じゃなくなった人は何を気にするべきか -3- Scalable Organization

新人じゃなくなった人は何を気にするべきか -2- Market fundamentalism

新人じゃなくなった人は何を気にするべきか -1- やっぱり CS と AT

【DQ9】 くもの大王 ハンティング

【DQ9】 青空スローライフ な おっきー さんからのお便り

【DQ9】おどるほうせき ハンティング

Firefox3の sqlite ファイルを vacuum して reindex する

無駄な謙虚さ

Linux kernel zero-day exploit

A. 笑わない数学者の問題

んー、何がどうなっているのやら

RAWデータを操れるのか…UFRaw…こりゃ便利だ

複数のクレジットカードを持つのは効果的なのか?

解答を書いておく -3- 部分解の2

request2

解答を書いておく -2- 部分解

まずは request3 から

つぎに request1

解答を書いておく -1- 課題

課題

request1

request2

request3

課題の詳細

request1

request2

request3

背景

参考資料

似たようなことがしてみたい人へ

【DQ9】くもの大王ハンティング

【DQ9】青空スローライフなおっきーさんからのお便り

【DQ9】おどるほうせきハンティング