三木谷浩史がテレビに出ているのを見たときに、紹介されていて衝動買いした「成功のコンセプト」を読みました。
たとえば、かわらで拾った石ころを、机の上に置いてペーパーウエイトとして使っているとしよう。2年、3年も使っていれば、きっと愛着が湧いている。それが一日中、川原を歩き回って探した石ころなら愛着はさらに大きいはずだ。
石ころだってそうなのだ。自分の仕事の方法論への愛着は、おそらく自分で思っているよりもずっと大きいと考えるのが自然だ。 (p.45)
この思考実験は、愛着の大きさを見積もるのに有用だと思います。正確な大きさは分かりませんが、かなりな大きさだということが分かるのでは。私はモノに対する愛着が小さいのですが、考え方なんかには執着するほうだと思います。「あ、それいいね」とあっさり自分の立場を捨てられる人はステキです。捨てればいいってものではありませんが。
変化に対する抵抗は、変化によるリスクを回避できますが、変化しないことによるリスクを背負うことになります。ちゃんと両方のリスクを見られるようになりたいものです。
「Pro JavaScript TEchniques」は、jQuery の作者 John Resig による JavaScript テクニックの本です。
for (var i=0; i<=100; i +=5 ) {
(function() {
var pos = i;
setTimeout(function() { // pos を使って何かする }, (pos+1)*10);
})();スコープに関しても理解が深まりました。
In JavaScript, scope is kept within functions, but not within blocks (such as while, if and for statements). (p.25)
Using a self-executing, anonymous function you can essentially hide all normally global variables from being seen by other code [...] (p.29)
However, it [a closure] does not provide the value of the variable at the time it i screated; it provides the last value of the variable within the parent function. (p.29)
「スコープの範囲は関数ごと」「関数がファーストクラスオブジェクト」であることから、クロージャの使い方と注意点が分かります。グローバルになってしまいがちなオブジェクトを関数に隠蔽してしまうのが、クロージャの役割である、と。それから、変数のスコープは関数ごとなので、親関数の実行が終了するときに、クロージャ内の変数に値がバインドされるらしい。
In the specification it is stated that no GET request should have damaging side effects (such as deleting a message), which is why the Google Accelerator did what it did. (p.131)
だから、オンラインアプリに保存したはずのデータがどんどん消されちゃうわけですね。
デイヴィッド・ストラウスによる「チームが絶対うまくいく法」、原題は「How to make collaboration work」です。複数人、複数グループによって何かするときに、うまく進める方法論を説いたもので、基本的にコンセンサスを得る方法を紹介しています。
そもそも問題がきちんと定義されないまま多数決で賛否を語ろうとするからうまくいかないのだ。(p.22)
コンセンサスづくりの作業の大半は、問題領域で行われる。[...] もしも解決領域に早く移りすぎると、各人が自分たちの立場を強く主張しようとするため、チームが分裂してしまう。(p.81)
問題の発見や定義をして、関係者の同意を得てから、解決にあたりましょう、と。問題発見の重要性を過小評価することがありますね、私は。問題が自明であるという前提で議論や思考を進めると、解決する必要のない問題を解決することになります。と、ワインバーグがあれほど言っているのに。
模索的なアプローチは、臨機応変で手軽だが、成功を保証してはくれない。ひるがえって、体系的なアプローチは機械的で融通がきかず時間はかかるが、必ず成功する。 (p.34)
ここで言う体系的なアプローチというのは、解探索を総当りに近い方法で行うアプローチを指します。木の探索なら、depth-first か branch-first かみたいなこともありますが、とにかく愚直な方法。なので「有限時間内に最適解が見つかる」ことは保証されません。模索的なアプローチというのは、ヒューリスティックのことです。どっちかではなくて、両方をうまく使うほうがよいですね。どのアプローチを使うか、というメタ問題の解決に時間がかかったりしますが。
議事次第を計画することは、会議を成功に導くためのもっともパワフルなツールと言ってよい。(p.111)
だいたいの目安だが、一時間のかいぎには一時間くらい時間をかけて準備をすればよいだろう。(p.117)
段取り重要。会議時間と同じくらいの準備をするのが、どのくらい現実的なのかよく分かりません。直感的に、そのくらいの時間をかけると、円滑に議論が進む気はします。
日経ビジネスアソシエ 2008.03.04 号の特集は「ハートを強くする めざせ！メンタルタフネス」です。落ち込み気味の今日この頃なのでちょうどよいです。
[プレッシャーに克つための]準備をする際には、絞り込んだ小さな目標をいくつか設定し、一つひとつ達成していくことが効果的だ。(p.26)
成功体験の蓄積は大切ですね。まあ、失敗してしまったわけですが（と更に落ち込む）。
「失敗を否定せずに、あえて頭の中で何度も映像化する。何度も追体験してなれることにより、客観的な経験にしてしまう」（岡本さん）。つまり、失敗したことがきにならなくなるまで追体験すれば、その経験は他人事のようになってくるのだ。(p.26)
客観的に見れるようになるのは大事ですね。自分が当事者なときには、余りに当事者すぎて客観的に課題を解決するのに時間がかかるものです。ところで村上龍の「2 Days 4 Girls」にも、追体験によって過去を受け入れるみたいなことが書かれていました。効果があるのか気になります。
プレッシャーに負けてしまう人は、「自分の力で変えられること」と「変えられないこと」を明確に分けることができない人ではないかと思います。 (p.28)
あー、これも重要。特に起こったことは起こったこと、という積極的な割り切りは必要だと思います。サンクコストですからね。
あと、サプリメントの紹介なんかもありました。お手軽♪
ROBO-ONE onPC/Sat 2nd を見に行ってきました。宇宙空間用格闘ロボットの設計、シミュレーション、制御の大会です。今回は、放り投げられて着地するロボットの、設計、シミュレーション、実装を競うというもの。光子力研九所のマジンガアBパーツが見事優勝。3投したうち、最後の投げで着地しました。すごいなぁ。ロボット作りたくなります。
Inventor、Simulink、LabVIEW を使うという課題があって、これは結構しきいが高かったようです。慣れてないと使えないでしょうねぇ。私も Inventor や Simulink 使えませんし。
Jim Kring 氏が作っている、LabVIEW 用オープンソースライブラリのパッケージマネージャ VI Package Manager の 1.1 がリリースされました。パッケージマネージャは、もちろんよくできています。ネットワーク経由でライブラリの最新版を拾ってきてインストールします。以前にどこかで「本物のアプリを作りたかったから作った」と書いていた気がしますが、見当たりません。いずれにしても、ふつーのアプリっぽい動作をする、数少ないアプリです。
このパッケージで入手できる、Dictionary というライブラリが秀逸です。これは Python でいうところの辞書で、key と value に variant を使って連想配列を実現しています。あまりまともな応用例を思いつかないのですが、すごいなぁと思いましたとさ。
日経ビジネスアソシエの連載を単行本化したもので、姑息なテクニックが解説されています。「姑息な」は「すぐに役立つ」とほぼ同義の誉め言葉です。
「ええと、あれ、あの資料は、確かここに……」などとカバンをまさぐっている人は、たとえどれほど優秀な大学を卒業していようが、優れたキャリアを有していようが、なんとなく「ダメな奴」というイメージを与えるものである。(p.48)
ダメかどうかはともかく、どんくさそうには見えると思います。ほんとちょっとしたことなんですけどね。なんかこう、大丈夫かなぁ、みたいな印象を与えてしまします。という自戒。
では、どうすれば自己奉仕バイアスを減らせるのかというと、それは意識的に「最悪の状況」を頭に思い浮かべるようにして、それを口にすればいいのである。 (p.67)
自分の能力を過大評価して、2週間かかる仕事を「1週間もあればできますよ」と見積もってしまうことを、自己奉仕バイアスというそうです。私の生活も、そんなのだらけです。頑張るのはいいんでしょうけど、もう少し物事を正確に予測する能力を磨く必要があると思います。
気になる本リストに入れていたのですが、たまたま本屋で見かけたので衝動買いです。経営者側から見た、残業しないことの有効性に興味がありましたので。
そこで、仕事には必ずデッドラインをつけ、さらにそれを会議の席上で発表して、守らざるをえない状況を社内に作り、そのうえで残業を禁止とするのです。(p.26)
うわあ、このプレッシャーに勝てるのでしょうか。モチベーションとプレッシャーは異なるので、デッドラインだけがあるのは危うい気がします。そこらへんの判断が難しいです。
私の答えは「優先順位を考えたり、スケジュール表を作ったりするひまがあるなら、その間に仕事の一つも片付けたほうがいい」というものです。(p.55)
なんと GTD 的な。片付けるか、しないか、という選択ですね。「明日やる」的な先延ばししない。
要するに、にぎやかで活気あふれるオフィスというのは、誰も仕事に集中していない状態なのです。 (p.147)
ピーター・ドラッカーが「ちゃんとした工場は退屈」と書いていた話と通じると思います。会議以外で人と話さないような習慣を身に着けることは可能だろうか、と考えてみました。ある程度まとまった量の仕事が明確に分担されて、必要な情報が共有できていれば、難しくないのかも知れません。突発的な出来事が頻繁に起こるようであれば、頻発する出来事を根本から治さないといけない、と。だんだん話が大きくなってきました。吉越も10年以上かけて実現したわけですし。
あと「フランス人の妻」という制約条件も効いている気がします。
