okkyの銀河制圧奇譚

2010年1月21日

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

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

商売は、基本的に 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 は管理効率を向上させる数少ない…ほとんど唯一の手段だ。

2010年1月11日

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

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

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

これが機械化の始まり。

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

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

そうやって作られた自動車も機械化だ。モノを移動させるのに抱えて運ぶとしんどいが台車にのせると楽になる。抱えて運ぶと荷重を支えるための力をずっと必要とするが、台車だと平地を移動する限り必要なのは初期速度を得るまでの力 + 摩擦分のロスを埋めるための力だけだ。その力の供給もエンジンからの力にしてしまえ、というのの究極の形の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といえども規模問題を回避したわけではない、と言うことが判る。

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

2010年1月8日

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

分割は 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倍ぐらいにはなる。ほら、マネージャを養う余裕ができた。

「機能の分割」の辛い所は、一連の作業を一旦全て明文化しなくてはいけない事。何をやっているのか理解していないと、分割できない。

「とりあえず先輩の仕事ぶりを見て、それを盗んで」

などという、 自分でも何やってるか判りません 的な、あまっちょろい状態は許されない。

くっきり、すっきり、はっきりと、何をするべきかわかってくると、この先に進める。そう。機械化だ。

2009年11月28日

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

あなたの会社は、今、年間の粗利が 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 の範囲内で という条件を外すことができない。単に発見されていないだけなのか、存在しえないのかは、不明。

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つの項目:

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 側のニーズが起因となっているものが多いのだ… と言うわけで次回に続く。

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分ぐらいは復活しないのだ。それより おどるほうせき というモンスターに ぬすむ を仕掛けた方がよほど効率が良い。もしおどるほうせきがどこに出没するのかさえ判れば。

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

魔獣のどうくつがどこなのか?世界地図を紹介しているページがあるので探してくれ。

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分ぐらいで、どこかしらでおどるほうせきは現れるらしい。

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

まずはここから 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年8月16日

無駄な謙虚さ

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

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

言う人に限って、

お前が言うか

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

まず、ほとんどの人が信じられないでしょうが、私は謙虚であるべきときには謙虚です。「信じられないだろうが」と「謙虚であるべきときは」という条件が付く、と言うことは、

ほとんどの場合は謙虚じゃない
「どういうときに謙虚であり、どういうときには謙虚であってはいけないか」について、ルールがある

という事です。さらに言うと 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
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 から参照、実行可能だから。