2009年11月28日

新人じゃなくなった人は何を気にするべきか -3- Scalable Organization

あなたの会社は、今、年間の粗利が n 円だとしよう。粗利だから売値から原材料費を引いた残りだね。それが n 円。

この n 円を稼ぐために、m人の「下っ端従業員」が必要だとする。平社員だけじゃなくアルバイトとかも含めて 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千万円から給料を捻出しなくちゃいけない。仮に給料を変えないとすると…売上をどんどこ増やしていくとどこかで赤字になる。赤字にしないためには給料を減らさなくちゃいけない…

あれ~??
売り上げを伸ばして粗利を増やしたのに
給料減っちゃったよ???

会社としての収入の伸びを下っ端の頭数に依存した価格設定にしている会社は、必ずこうなる。
多くの場合、グループ企業の子会社とかは、親会社に対して「何人がかりで何時間働いたのでいくら」というお値段のつけ方しかできなかったりするが、実はこれは子会社が大きくなれないようにするための秘策だったりするのだ。もしあなたが勤めている会社がお客様にそういうチャージの仕方しかしていないなら…転職を考えたほうが良い。規模が大きくなるほど忙しくなるが、儲けはむしろ減っていくのだから。

この状態を回避する方法は全部で4つある。
  1. 規模を大きくしない
  2. 定期的に組織構造を根こそぎ書き換える
  3. mがnに比例している部分をアウトソースしてしまう
  4. nを増やしても比例してmが増えたりしないようにする
1の「規模を大きくしない」と言うのは「京都で600年間続く老舗」とかではよくある。手広く商売するのではなく、限定された規模のお客様だけを相手にし、その代わりそのお客様を手放さないようにする。これを可能にするためには、収入を他人と分け合わない 必要がある。株式公開なんかもってのほか。借金をしたら利子を取られるのでそれもなし。何らかの希少性を前提にできるならば、この戦略はありだ。
ただ、一般的な企業はそうは行かない。株式は公開されているし、拡大再生産しないと経営陣が突き上げを食らう。

2はようするに「リストラクチャリングを定期的に行う」と言うものだ。ようするにこれは富の再分配の問題なのだから、会社の構造を書き換えて、再分配ルールを変更してしまえばよい。
ただ、これをやると必ず「今までよりも手取りが減る」人が出てくる。そりゃそうだ。そのために構造を変更しているんだもの。大抵この手のしわ寄せは「下っ端」に押し付けられる。問題はほぼ全ての職種で「下っ端」はいくらでも交換可能な存在 ではない という点だ。旧来の高給取りを首にして、安い給料で働く人間を入れると、必ず一人当たりの粗利自体が悪化する。市場で急激に売り上げを伸ばしたので会社の構造を変えたら、品質が悪化、売り上げが縮退し、そのまま倒産…なんて会社があるが、それは リストラに失敗した という事だ。この手段は意外とリスクが大きい。

3はよくある「グループ企業」って奴だ。自分では構造改革できない部分を切り離して外に押しやり、
「自分たちでどうにかしろ」
というかなり無責任な行為。もしあなたが、「人月」でしか値段をつけられないのにこのようにアウトソースされたのなら、すでに万策は尽きている。親会社の方を切り捨てるしかない。他の企業は人月によるチャージにならないよう、値段交渉できるが、親会社は政治的圧力をかけてくるからだ。

で。結局3の場合も独立したあとは 4 の問題を解かなくちゃいけない。10倍の粗利を得るのに10倍未満の人口増でまかなわなくてはいけないのだ。最低限度でも 管理職をも含めた全人数 が粗利の倍率に比例するように、人数が増えると作業効率がよくなるようにしなくてはいけない。

Automation の本領発揮だ

Scalability を確保する方法は、今知られている範囲では、3種類ある。
  1. 分割
  2. 機械化
  3. off demand
…あう。ずんどこ書いていったら終わらないよ。というわけで上記3種類、それぞれの詳細は次回。
ただ、上記3種類、いずれも「無限の scalability」は持っていない。どうしても 一定の n の範囲内で という条件を外すことができない。単に発見されていないだけなのか、存在しえないのかは、不明。

2009年11月25日

新人じゃなくなった人は何を気にするべきか -2- Market fundamentalism

まずは 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 の話です。

2009年11月24日

新人じゃなくなった人は何を気にするべきか -1- やっぱり CS と AT

昔書いた日記、「新社会人にあなたならまず何を教えるか? -1- CS と AT」から始まる10回 が思ったより好評だった。ので、久しぶりに続きを書こうと思う。今回は「新人じゃない人」は何を気にするべきかという話。

そもそもは、ある会社の社長さんが社内メールで悲鳴を上げたことに始まる。いや、その内容は内緒だが、ようするにそれを見ていて思ったのは、
「そういえばこの会社、新社会人以外も問題のある人が多いよな」
というもの。なに? お前もだ? うむ。その通り。だから、今回の話を書くに当たっては、まず、心の中に 大きな、大きな、大きな 棚を作った。そりゃもう ギアナ高地 のような、大きな奴だ。どうにか自分をそこに置くことに成功したので、棚が壊れる前に先に進む。

で、いろいろ考えたわけだ。どういう事を気にするべきかとか、どういう問題があるかとか。で、いろいろまとめていくと…結局新社会人に教えたことと同じ枠組みから一歩も外に出る必要がない、という事に気が付いた。やはりお金を稼ぐには2つの項目:
  1. Customer Satisfaction
  2. Automation
の2つに神経を集中する必要がある。逆に、この2つのためにその他の注意すべき項目は存在するし、それらに関してどうやって解くべきか、を考えるとどうやら答は一通りではないようだ。各々、自分が好きな、得意な解き方というのがあってよいように思う。


で。今回の議論。新社会人が相手じゃない。社会人になって、後輩とか部下とかができる辺り…って2年目からジャン…以降の人、社長さん(つーか CEOな)の辺りまでが考慮対象だ。活躍する経済圏としてはまだ開放系を前提とする。世界中を全部1つの経済圏として見なくてはいけない人(銀河皇帝になる私とか)は、経済圏を閉鎖系として見なくちゃいけないのだが、そこまで大きなものを見据えなくちゃいけない人たちは考慮対象としない。つーか下手にその辺を教えると、支配者のライバルが続出するしな :p

経済圏が開放系だ、という事は、あなたの活動によって世の中の経済が大躍進を遂げたり、逆に大打撃を受けたりはしない、という事を意味する。あなたの会社の趨勢はあくまでも局地的な問題で、あなたの会社が上手くいかなかったら、他の会社がその位置を占めるだけのこと。そういう大前提を念頭に置いてほしい。

また、「新社会人にあなたならまず何を教えるか? -1- CS と AT」から始まる10回 で述べたことは繰り返さない。基本的に、あそこに書いたことはすでに知っている、という辺りからはじめる。でも、同じことは書くかもしれない(どっちやねん)。いや、新人の時とは違う意識を持って同じ事をね…

書く内容はこんな感じ:
  1. Automation
    1. Market fundamentalism (市場原理主義)
    2. Scalable Organization
  2. Customer Satisfaction
    1. Who's Customer(で、お客って誰さ)
    2. Communication(Transfer の大事さ)
    3. Annoucement
    4. I18N/L10N
さて。今回の議論だが、 Automation から始めよう。考慮しなくちゃいけない項目は Customer Satisfaction の方が多いのだが、そうなる理由は Automation 側のニーズが起因となっているものが多いのだ… と言うわけで次回に続く。

2009年9月27日

【DQ9】 くもの大王 ハンティング

今度は いかずちのたま が足りない。これをもっているのは くもの大王 と ヘルクラウダー 。が、ヘルクラウダーは強すぎる。いきおい、 くもの大王 を狙うことになる。

で、くもの大王、実は結構あちこちにいる。いるのだが、「シンボルとして出てくる」のではなく、別のモンスターにくっついて出てくる 事が多い。これだと偶然を待たなくてはいけないので困る。宝の地図 だと、もっと強いモンスターが同じフロアにいたりして、これまた困る。あくまでも地上マップで済ませられるならば、済ませたい。

で、あちこちうろついて探した結果、見つけたのがこちら:

丁度この丸でかこんである部分。竜のしっぽ地方の中でもこの部分だけ、くもの大王がシンボルで出てきます。

一緒にうろついているのは、主に サイクロプス と メガザルロック です。 また戦闘シーンにだけ出てくるモンスターとして、 ベホイムスライム 、 ギガントヒルズ 、 ヒートギズモ がいます。いずれも雑魚ではありますが、いつまでも生かしておくと戦闘ターンが長くなる元です。とっとと倒してしまいましょう。ただし、勢いに乗りすぎて くもの大王 まで殺してしまわないように。

なお、 くもの大王 はやたらと「いかずちを呼び寄せる」技が好きです。と言うか、もうほとんど毎回そればかりです。装備を 雷耐性 のある方向にし、いやしのうでわ が毎ターン補充できる程度の被害に収まるようにしておくとよいでしょう。

【DQ9】 青空スローライフ な おっきー さんからのお便り

なんか最近、いじめられているような気がするんです。

たとえば、今日も「怒れる花の地図 Lv.45 発見者: かりん」という地図に潜っていたのです。
きっとこんな端っこの方なら誰も来ないだろうなって思って。
本当に端っこにいたんですよ。
じっとしてました。
本当です。
なのに…
普段は、
人の気配を感じただけですぐ逃げ出すはずの、
はぐれメタルさんまでが
ガンをつけにくるんです…

…あぁ、また…

2009年9月25日

【DQ9】おどるほうせき ハンティング

DQ9をやっている。

ま、一応メインストーリーは終わったのですが、皆様ご存知の通り、このゲームは そこからが 本番。クエストとか、宝の地図とか、錬金コンプリートとか、いやそれどころか錬金しないと得られないアイテムだとか…もう盛りだくさん。

一説には「クリスマスにロックが解除される、きわめてシーズンを狙った追加クエスト」というものまであるらしく…半年以上引っ張るつもりか… SQUARE ENIX。FF12 とバッティングするぞ?!!

で、やってらっしゃるとわかると思いますが、問題の一つが錬金。ハイパワーな武器、鉄壁の防具の類を作ろうとすると、材料がすでに錬金した結果のもの。それらを作るためにさらに材料を集める…と、いくつもの材料が圧倒的に不足する。

「xxxx を作るには yyyy が 3つ必要なんだけど、yyyy を作るには zzzz が 3つ必要」

ってこの段階で、zzzz が9つ必要やんけっ!! などというのはざら。これをキャラクター人数分作る段階で4人分…つまり36個。で、実はこれが2段階程度じゃすまなかったりする。
売ってるものならまだいい。Goldを稼げば話は終わる。でも拾ってくるしかなかったりすると…。


というそのようなアイテムの一つが ひかりの石 。もちろん、フィールドにも落ちている場所はあるけれど、一度に拾えるのは6個とかその程度。その後30分ぐらいは復活しないのだ。それより おどるほうせき というモンスターに ぬすむ を仕掛けた方がよほど効率が良い。もし おどるほうせき がどこに出没するのかさえ判れば。

もちろん判っていて、一つ目が カルバド大草原 。ただし、ここはとても広くて「待ち伏せる」なんてできない。しかも出没頻度がものすごくレア。で、二つ目がこれから紹介する 魔獣のどうくつ 。ここでも出現確率はレアなのだが、良いポイントを見つけたのだ。これからそれを紹介しよう。

魔獣のどうくつ がどこなのか?世界地図を紹介しているページがあるので探してくれ。
一応、左はしに近い、上下ではまんなから辺だ。まさか、自宅のすぐそばにこんな大事な場所があったとは…。

で、魔獣のどうくつの B1F が目的地。待機ポイントはここ:
魔獣のどうくつ B1F の、地図ほぼ一番下。

で、これが待ちの体制。

この場所の近くで下向きキーを押すと自動的にここに ハマる 。で、ここに到達したらすぐ X ボタンをおして、図のように「どうぐ」とかを選択するモードに設定する。こうしていると、モンスターはあなたの事を無視してくれる。余計な奴が出てきても、素通りしてくれるのだ。


で、最も多い出現パターンはこう:

私の感覚だと、だいたい 3/4 ぐらいがここに現れる。出現したら B ボタンをおしてダンジョンワールドに復活、即効ダッシュで捕まえる。

即効ダッシュで捕まえるには、あいだに余計なモンスターがいては駄目だ。一分ぐらい待つと、2,3匹よけいな奴らがうろつき始めるので、 掃除の意味をこめて モンスターを討伐する。


たまに発生するのがこれ。

みずらい画像で申し訳ない。このひん曲がった大福餅のような奴も、おどるほうせき だ。実は画面左側にもう1箇所モンスターの出現場所があり、そこから出てくる場合がある。

どうも一度に2つ以上の おどるほうせき シンボルが発生する事はないらしい。
「あれ~?出てこないなぁ」
と思ったら大抵左から出てくる、と思っていい。大雑把に30秒待っても最初のポイントに出現しないなら、このパターンが多い。


この場所、右側が坂になっており、普通は見えないはずのモンスター出現場所が2箇所、画面に映っている。また、左側にも出現場所があるのだが、こちらはモンスターにとっては行き止まりらしい。必ず左から右へ現れる。結果、3箇所の出現場所どこで発生したモンスターも捉えることができる。

これだけ出現ポイントがあると、モンスターを一発倒して出現しているモンスターをリセットしてから大雑把に30秒から1分ぐらいで、どこかしらで おどるほうせき は現れるらしい。

2009年8月30日

Firefox3の sqlite ファイルを vacuum して reindex する

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 をしろ、と言うことだ。

  1. まずはここから sqlite3.exe を手に入れる。
    http://www.sqlite.org/download.html
    "Precompiled Binaries for Windows" から zip ファイルを持って来る。で、適当な場所にインストール。つーても zip を解くと、sqlite3.exe というファイルが出てくるので、それをどこか Path が通っているか、自分が判っている所に置く、というだけですが。

  2. すでに出てきているように Application Data のどこかに Firefox3 の sqlite ファイルがある。拡張子は「.sqlite」なのでそれを見つける。私は Cygwin を入れているので、unix の find コマンドが使える。のでそれで
    bash-3.2$ find . -name '*.sqlite'
    で発見できた。

  3. 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年8月16日

無駄な謙虚さ

まぁ、なにしろこのような日記を書くぐらいですので、ときどき人から言われます。

「もっと謙虚になりなさい」

言う人に限って、
お前が言うか

というぐらい謙虚じゃないだけでなく、無能で、無駄なところでだけ謙虚な人なので無視していますが。今回はその「謙虚さ」についてのお話。


まず、ほとんどの人が信じられないでしょうが、私は謙虚であるべきときには謙虚です。「信じられないだろうが」と「謙虚であるべきときは」という条件が付く、と言うことは、
  1. ほとんどの場合は謙虚じゃない
  2. 「どういうときに謙虚であり、どういうときには謙虚であってはいけないか」について、ルールがある
という事です。さらに言うと 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 の前半です。

で、後半。ここで謙虚になるとはどういうことか??

俺には解けないかもしれない…

と引いてしまう事です。それでは解ける物だって解けない。

俺に解けないなら
誰にも解けんわいっ!!

というぐらいの気概で問題に当たらなければ、人生やってられません。

ちなみに。何事にも例外はあるもので。

私の場合、あまり もてませんな、この戦略で生きていると。

2009年7月22日

Linux kernel zero-day exploit

備忘録。

対象2.6.30, 2.6.30.1
真の原因null pointer check をしていないコード & gcc optimization
修正コード2.6.30.2
demohttp://www.youtube.com/watch?v=UdkpJ13e6Z0
解説しているページ
原因となっているパッチ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 から参照、実行可能だから。



ちなみに、2.6.18 base のはずの RHEL5.4 beta にはこれらのバグが存在した(NULL pointer check 関係の最適化がバックポートされた)が、それぞれ修正されているそうだ。

2009年6月22日

A. 笑わない数学者の問題

まだ確定していない予想はここに書く。

3. 笑わない数学者の問題
2. 笑わない数学者の問題
笑わない数学者の問題

なんとなく見えてきた。これは Pn が問題児なんじゃない。

Pn を決めると、 P3 から Pn-1 までの値の範囲が決定する ( P1 と P2 は固定なので影響しない )。特に Pn-1 の値の範囲には強い影響力がある。

また、 Pn = ( n*(n-1)/2 - x ) の 「x の値」が大事。x の値に応じて、同じ Pnに対して、 2x 組のパターンが発生する。

で、x が決まったときに Pn の周りにどのように数字を配置できるのかを突き詰めていくと、x ごとに有効な n の範囲が出てくる。また、その n が成り立つための拘束条件も出てきて、Pn周りのボールの何個かが確定する。そこから先は n ごとの探索になるが、ここまでは「nとは関係なく」求められる。そういう問題なのだろう。

だから 「n を与えられたときに解を求める」という探索戦略を使うと、いったん x の範囲を求めることになり、その後各 x について解を探すことになるが、これは「与えられた n 以外についての解」を大量に探索することになる。その次の n を与えるとこれまた同じような x の範囲について同じような探索をする必要があり…ここが大量に存在する重複した計算部分なのだろう。これは x ごとに n を求めた look up table をまず用意して、次に n ごとにその lookup table を探索するべきなんだ。

2009年6月13日

んー、何がどうなっているのやら

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 はエラーになった。よかったよかった。

2009年5月6日

RAWデータを操れるのか…UFRaw…こりゃ便利だ

デジカメとして ニコンのD70 と PanasonicのLUMIX-G1 を持っている。で、この2つのカメラ、どちらも RAW フォーマットをサポートしている。

サポートしているのはよいのだが、これを読み込むためのソフトがPhotoshop等の有料ソフトしかなかった。メーカーごとにフォーマットが違い、JPEGのように標準化されていないからだ。そのため、今まではJPEGで撮影していたのだが…

UFRawというソフトがある事を知った。各社のRawファイルを読み込み、ある程度の色調調整などは自分でもできるソフト。
最大のポイントはGIMPのプラグインとしても動作するので、RAWデータをGIMPで操作して、結果を別のフォーマットなどにも保存できることだろう。

G1はRawとJpegを同時保存できるので、それで見ていると、たまにバグって色調がおかしくなっている場合があるが、それ以外は快調。

今までは操作もできなければプレビューすらできないRawモードは避けてきたんだけれど、これからは使ってみようかと思う。