エンジニアリングにおける生態濃縮問題
毒危険。
…いや今回まぢで結構しゃれになってないので。
そもそもとして…
IDE周りの話。
元ネタ群
vimやEmacsを「使いこなす」なんてやっていいのは20世紀までだろ
http://togetter.com/li/130686
「vimやEmacsを「使いこなす」なんてやっていいのは20世紀までだろ」だって？
http://d.hatena.ne.jp/JavaBlack/20110506/p2
モダンな箱庭 と 古典的だけどシームレスな世界
http://d.hatena.ne.jp/minekoa/20110506/1304701055
えと…ど真ん中剛速球で一言。
「IDEに振り回されず、使われず、ちゃんと使いこなしてる人」って、どれくらいいるんですか？ B-p
振り回されてる人とか使われちゃってる人は、たくさん見るんですがねぇ B-p
そもそも。
「ソースコードが書きやすい」とか言われても、おいちゃん「そんな大量にソースコード書かない」し。「できるだけシンプルに簡素にストレートに」ソース書いた方が、メンテしやすいっしょ？
チーム開発なんちゃら言われても、ふつ〜にSVNとかは亀さん使えばいいし(亀さんは割と好きかなぁ扱いやすいし)。
それ以外でも…「IDEがなくて困った」ケースって、あんまり遭遇したことない。
どちらかというと「遅かったり重かったりバグったり落ちたりして」思考の邪魔をされる方が、よっぽど迷惑。
ん…まぁ。たとえば「クラス名・メソッド名・変数名の補完」とかは、すっげぇ便利だとは思うンだけど(特にメソッドで、ヒンティングとか出してくれるやつ)。
でもまぁそれくらいでいいかなぁ、と。
言い方を変えると「コンピュータに自動生成してもらわないといけないほど潤沢なソースコードを書かざるを得ない仕様なり設計なりプログラミングなり」って、その時点で一つなにか間違えてると思う。
YAGNIとかKISSとかって、どこに消えちゃったんだろう？
でっかいテーブルをまりっと更新する方法のひとつ の応用編と困ったこと
んで。
これの亜種として「部分的に入れ替える」事を、やることがあります。
んと…住所だと「東京都だけ入れ替える」とか。
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
でっかいテーブルをまりっと更新する方法のひとつ
んと…例えば「郵便番号を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」とか、まぁ細かい小手先技が、色々と盛り込めるもんでｗ
向かい合って話し合うことの大切さ
元ネタはこちら
“対話”を欠く経営者は組織実行力を失う、今こそ“対話”を！
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 )。
というか。「注意をしてくれる人が減る」から、上に行けばいくほど「より一層、自省内省」せにゃならんのではなかろうか？ と。
相手のカンは気をつけろ 自分のカンは検証しろ
ん…別段「達人」を吹聴するつもりもないのですが。
まぁ色々と修羅場とかド修羅場とか瀕死修羅場とかくぐってますと、生存本能の関係から「相応のデンジャーセンス」が磨かれるものでして B-p
いわゆるハインリッヒにいうところの、29の気配とか300の臭いに、相応に敏感になるわけです。
とはいえ。
そのカンがまぁぶっちゃけ「面倒だからヤダなぁ」とか「変更したら自分が今までがスキルが否定されたようでヤダなぁ」とか、大変に「駄目な」あたりに立脚するケースも、もちろん、多々あるわけです。
なので。
まず「下の子のカン」は、受け流さずに検証をします＆「いやな予感がしたら、予感〜、でいいから、伝えてね」と、口を酸っぱくして教え込みます。
知識不足からくる不安も多くて、その場合はよい教育のネタになりますし。時々「こっちが気づいていなかった」事に対しての気づくきっかけになるので、大変に重宝したりもします。
一方で「自分のカン」は、徹底的に検証をします。最低限「言語化できるまで」。…ただまぁ「言語化出来てしまった」カンは、困ったことに大抵「ビンゴ」するのですが orz
もちろん「言語化できたカン」ってのはあくまで予測でしかないのですが…誰かが言ってましたねぇ「誤算はなかった、それが一番の誤算だった」って orz
ともあれ。
検証が難しいものではあるのですが、一方で、そうはいっても「野生のカン」というのは、きっちりと存在するわけなので。
それに対していかに「誤謬を排除した」うえで「有効に使うか」ってのは、結構大切なんじゃなかろうか、って思うです。
上司と部下は交互にやった方がよい 草案
大分かた経験則な部分があるのですが…元ネタは、どこぞの書籍にあった、こんな一言(書籍思い出したら追記しやす)。
人間、40歳になるまでは人の上に立たない方がよい。
一方ではすごくわかる部分もあって。ただ、一方で「管理職は40歳以上」とかいうと現場が立ち回らなくなる部分もあって。
そんなあたりから「管理はしても上には立つな http://d.hatena.ne.jp/gallu/20101030/p1 」というエントリーを書いていたりしたのですが。
今回は、それにプラスして「ふと自分の経験を回顧したときに」気づいたことを。
結論から書くと「マネージャと現場を、適当に何回か往復したほうがよくない？」っていう提案ざんす。
んと…まぁ正直「上が下を見る」よりも「下が上を見る」ほうが、正確かつ的確であることが多くて。
なので、部下として働いているときは、現場の一番細かいところも見えているし、そこから上司のアラも見えるので。
結果として、まぁ上司に対する不満や愚痴が発生します。
で、上司になって。
…そうすると今度は、上に立たないと見えない「俯瞰的視点」からの問題があって、結果として「なんで部下はこう無能なんだろう？ なぜオレが尻ぬぐいしなきゃなんねぇんだよ」となります。
…あれ？ って思いません？
えと…とりあえず快刀乱麻を偽装してみると。
部下の視点って狭いことが多くて。たとえばそれが「部分最適」すぎて全体最適から外れていたり、短期的にはよいんだけど中長期的には問題があったり。
一方で上司の視点は依存度が高いことが多くて。意訳すると「俺の心を読み取って動け」であったり「おれの責任はおまえがとれ」であったり。
この辺の矛盾をじゃぁ「どうやって解決するか」なのですが。
そこで「部下になったり上司になったり」してみるです。
それぞれの視点を何度か往復すると…ふと気づく時があるですよ。
部下としての不満、上司としての不満の、それぞれが「ある程度、正鵠を射てて」「ある程度、己の無能や無知に根ざしている」ことに。
まぁ…普通の会社でやるのも色々難しいのでしょうが。
可能なら「使う側」と「使われる側」と、両方ともを交互に体験すると。多少なり「相手の立場に立った」見方も発言も、できるんじゃないかなぁ、と。
どんなもんなんですかね？
