相手のカンは気をつけろ 自分のカンは検証しろ

ん…別段「達人」を吹聴するつもりもないのですが。
まぁ色々と修羅場とかド修羅場とか瀕死修羅場とかくぐってますと、生存本能の関係から「相応のデンジャーセンス」が磨かれるものでして B-p
いわゆるハインリッヒにいうところの、29の気配とか300の臭いに、相応に敏感になるわけです。

とはいえ。
そのカンがまぁぶっちゃけ「面倒だからヤダなぁ」とか「変更したら自分が今までがスキルが否定されたようでヤダなぁ」とか、大変に「駄目な」あたりに立脚するケースも、もちろん、多々あるわけです。

なので。

まず「下の子のカン」は、受け流さずに検証をします＆「いやな予感がしたら、予感〜、でいいから、伝えてね」と、口を酸っぱくして教え込みます。
知識不足からくる不安も多くて、その場合はよい教育のネタになりますし。時々「こっちが気づいていなかった」事に対しての気づくきっかけになるので、大変に重宝したりもします。

一方で「自分のカン」は、徹底的に検証をします。最低限「言語化できるまで」。…ただまぁ「言語化出来てしまった」カンは、困ったことに大抵「ビンゴ」するのですが orz
もちろん「言語化できたカン」ってのはあくまで予測でしかないのですが…誰かが言ってましたねぇ「誤算はなかった、それが一番の誤算だった」って orz

ともあれ。
検証が難しいものではあるのですが、一方で、そうはいっても「野生のカン」というのは、きっちりと存在するわけなので。
それに対していかに「誤謬を排除した」うえで「有効に使うか」ってのは、結構大切なんじゃなかろうか、って思うです。

向かい合って話し合うことの大切さ

元ネタはこちら
“対話”を欠く経営者は組織実行力を失う、今こそ“対話”を！
http://mag.executive.itmedia.co.jp/executive/articles/1105/02/news005.html
http://mag.executive.itmedia.co.jp/executive/articles/1105/02/news005_2.html

うん…多分、 http://d.hatena.ne.jp/gallu/20110428/p1 で書いたことをものごっつ想起させる、気が、する。

「対話は、日常行われているか？　」と問えば、多くの経営者・管理者は「Yes」と答えるだろう、しかも心底から。現実と異なるその重大さに気も付かず、お人好しにも程がある。

一文目からど真ん中剛速球ｗ

現実に、新製品原価が予想売価に対して高すぎることが会議席上で隠蔽（いんぺい）されたり、新製品について量販店を持ち回って評価を聞く会議決定をしたにもかかわらず、都合の良い話を聞ける一部店にしか持ち込まなかったり、"対話"がいかにもいい加減である例は枚挙にいとまがない。特にかねてからの閉塞状態下で展望が開けず、しかもこの非常事態に置かれた日本企業にとって、強力な組織行動力が必要だ。そのために「真の対話」が求められる。　

「一文」でも「一単語」でもなく、「一文字」の単位で、否定する要素が見つかりません。

日本ではこの種の対話は、評価する方もされる方もできるだけ早く終わらせ、できるだけ事を荒立てたくない。しかし、日本式評価では「真の対話もなければ、フィードバックもない。」「自己の成長と育成に役立つものを社員に学ばせる機会がない」。「如何に優れた給与体系でも、忌憚のない対話とリーダーの毅然たる態度が欠如していれば、無意味でしかない。部下の欠点を指摘するという対話はマネージャーにとっても嫌なものだ。したがって、こうした厳しいフィードバックが与えられるかどうかでリーダーの強さが試される。」（上掲書）

で。実際問題として「その強さをお持ちなリーダー」さんって、いるの？
せめて「絶滅危惧種」くらいに存在していればいいんだけど…どっちかっていうと「伝承上の生物」とか、そのレベルちゃう？

「忌憚のない意見を」とよく言われるが、建前論の忌憚のなさではなく、本当の気持ちや口にしにくいことを発言すること、それが「対話」である。

御意 ＆ 同意。
あえてここに足すのであれば「本当の気持ちや口にしにくいことを、相手を思って建設的に"愛言として"発言すること」。

ここから、猛毒。

とはいえ。上述のために必要なのは「上でふんぞり返ってる連中のカイゼン」であって。
で、彼らは「下をカイゼンすることによって組織を"より一層自分にとって都合が良い方向に舵取りする"ことに有能」なので。
その辺を考えると…まぁさらっと「絶望的だなぁ」っと。

そもそも。「部下の苦言」に対して真摯に向かい合える管理職/経営者って、いるんですかねぇ？ 「どれくらい」とかってい数の問題以前として「存在」します？ B-p

胡坐をかいちゃいけない重要性って、どこに行っても変わらんのだろうなぁ、っと(老害 http://d.hatena.ne.jp/gallu/20110327/p1 )。
というか。「注意をしてくれる人が減る」から、上に行けばいくほど「より一層、自省内省」せにゃならんのではなかろうか？ と。

でっかいテーブルをまりっと更新する方法のひとつ

んと…例えば「郵便番号をkeyにした住所テーブル」なんてのが、割とわかりやすいところであるのですが。
この子を更新する場合、普通に考えると

begin;
trancate 郵便番号テーブル;
loop insert into 郵便番号テーブル(...) values(...);
commit;

ってな処理かと思うのですが(エラー時の処理は省略してるので気をつけてね)。
この場合、トラン中が結構長いのと、そのために、結構なDB負荷がかかります(いやまぁ真面目に計測はしてないんですが)。
そこで。若干荒っぽく、こんな処理の仕方があります。

trancate 郵便番号テーブル_tmp;
loop insert into 郵便番号テーブル_tmp(...) values(...);
begin;
trancate 郵便番号テーブル;
rename table 郵便番号テーブル_tmp to 郵便番号テーブル;
commit;

いやまぁたいした手段でもないのですが「こーゆーやりかたもあるでよ」ってことで。
これだと、極論「insert１文ごとにマイクロスリープ」とかぶち込んだり「DBハンドルの接続数を確認して、一定数以上ならしばらくwait」とか、まぁ細かい小手先技が、色々と盛り込めるもんでｗ

でっかいテーブルをまりっと更新する方法のひとつ の応用編と困ったこと

んで。
これの亜種として「部分的に入れ替える」事を、やることがあります。
んと…住所だと「東京都だけ入れ替える」とか。

trancate 郵便番号テーブル_tmp;
loop insert into 郵便番号テーブル_tmp(...) values(...);
begin;
delete from 郵便番号テーブル where 都道府県='東京都';
insert into 郵便番号テーブル(...) select ... from 郵便番号テーブル_tmp;
commit;

で…まぁ「結構でかい」のをやったら、とっても嫌がられました orz

The total number of locks exceeds the lock table size

えと…「でけぇよ！！」って感じ？
基本的には
my.cnfの中にある「innodb_buffer_pool_size」をでっかくしてあげると良いみたい。

…さて。いくつにしたらよかんべ orz