「100 Tricks to Appear Smart in Meetings」で学ぶ英語圏の職場でのサバイバル術

「100 Tricks to Appear Smart in Meetings」がなんか面白い。ちょっと前にSNSなんかで話題になっていたようだ。英語のキンドル本を買って読んだらやけに面白く、かつ海外の職場でのサバイバルに関して参考になった。

本書の趣旨はシンプル。英語を使う職場でも、その職場や会議で発せられる言葉に実はそんなに価値はない。だからテキトーにこなしておけばいい。くだらない会議の中でもあなただけはクールに見える魔法の言葉を紹介します、というのが趣旨。

ミーティングで使われている時間（本書より）
© Sarah Cooper

６　気まずい沈黙
５　スマフォを見る
４　ちゃんと聞いてなかったから「もう１回言って」と言う
３　会議じゃなくてメールでよかったかもと気がつく
２　次のミーティングを計画する
１　早く終わらせたいからなんでも賛成しておく

みんながさも真面目そうにミーティングに参加しているのを面白おかしく揶揄してしまう本書のエピソードはなんかプッと笑ってしまう。

100 Tricks to Appear Smart In Meetings

本書の一部を紹介する。

会議でクールに見せる方法

エンジニアが話した最後のセリフを繰り返す。（ただしすごくゆっくりと）

エンジニアが難しいこと言い出したら、その話の後で「繰り返すね」と言って、そいつが言った最後のセリフをそのままそっくり繰り返す。ただしとってもゆっくりと。
そいつの賢さは全部あなたが持っていけます。

「その質問って問うべき正しい質問かしら？」と言う

それが正しい質問かどうかを聞くことほど賢そうに見える質問はない。

みんなが気に入りそうなアイデアだったら、「Ship it!（よし出せ、出荷しよう）」と大きめの声で言う

みんながアイディアに興奮して、気に入っているようならこう叫ぶ。「Ship it!（よし出せ、出荷しよう）」ちょっととっぴな印象で、笑う人もいるかもしれない。しかしあなたはこれによって、あたかも会議の結論を導き、ミーティングを成功に終わらせる権限が（実際は無くても）あるように見える。

感想

最後のShip it!の男のドヤ顔と両手を頭の後ろにしたその姿勢にウケた。意識高い系の登場人物の挿絵がまたなんとも面白い。

著者のSarah Cooperは元Googleでデザイナーをしていた経歴の持ち主。
この本を単なる笑いを狙った本とだけ思って読むのはもったいない。多かれ少なかれ英語圏の職場においては「目立ったモノ勝ち」なところはある。海外で働くことになった際に本書のノウハウをそのまま使うのはどうかと思うが、Ship it!の男のように何も考えてなくてもとりあえず目立っておくことは大切なことだと思った次第。

日本語版もあるようだけど、英語版の方が面白さのツボには直接響いてくる。英語が読める人なら英語版の方がおすすめ。

100 Tricks to Appear Smart In Meetings

会議でスマートに見せる100の方法 (早川書房)

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

RubyのblockやProcを分かったつもりになっていて見事にハマった

反省した。RubyのblockやProcを分かったつもりになっていて、しょうもないところでハマった。自戒を込めてブログに残しておくことにした。

$ ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]

例１

def method_1
  if block_given?
    puts 'Yes'
    yield
  else
    puts 'No'
  end
end

method_1 { puts 'I am a block' }

つまりmethod_1にI am a blockの出力というブロックを渡して、ブロックが有ればYesと共にそれを出せと。
method_1にはブロック引数が無いが、この例のようにそれが問題になることもなく、yieldすればちゃんと実行される。

実行結果

$ ruby block_sample_1.rb
Yes!
I am a block

例２

def method_1
  if block_given?
    puts 'Yes :method_1'
  else
    puts 'No  :method_1'
  end
  method_2
end

def method_2
  if block_given?
    puts 'Yes :method_2'
    yield
  else
    puts 'No  :method_2'
  end
end

method_1 { puts 'I am a block' }

blockが渡されたmethod_1からmethod_2を呼び出す例。

実行結果

$ ruby block_sample_2.rb
Yes :method_1
No  :method_2

渡されたblockはmethod_1まで。method_2には到達していない。

例３

つまり&引数名にしてブロックをProcオブジェクト化して渡す必要がある。その対策後のコード例がこれ。

def method_1 &block
  if block_given?
    puts 'Yes :method_1'
  else
    puts 'No  :method_1'
  end
  method_2 &block
end

def method_2
  if block_given?
    puts 'Yes :method_2'
    yield
  else
    puts 'No  :method_2'
  end
end

method_1 { puts 'I am a block' }

実行結果
これでしっかりblockがProc化されてmethod_2にまで到達していることが分かる。

$ ruby block_sample_3.rb
Yes :method_1
Yes :method_2
I am a block

例４

def method_1 &block
  if block_given?
    puts 'Yes :method_1'
  else
    puts 'No  :method_1'
  end
  method_2 plus_one 1, &block
end

def plus_one number
  number + 1
end

def method_2 number, &block
  if block_given?
    puts 'Yes :method_2'
    puts number
    yield
  else
    puts 'No  :method_2'
  end
end

method_1 { puts 'I am a block' }

実行結果

$ ruby block_sample_4.rb
Yes :method_1
No  :method_2

method_2にまでブロックが到達していない。これでハマった。とくに例３と変わったことをしているようにも思えない。ただdef plus_one numberを加えただけで、そこにblockはまったく関係無さそう。なぜmethod_2にまでブロックが到達しないのか、しばらく分からなかった。

見つけた答えがこれ。

例５

def method_1 &block
  if block_given?
    puts 'Yes :method_1'
  else
    puts 'No  :method_1'
  end
  method_2 plus_one(1), &block
end

def plus_one number
  number + 1
end

def method_2 number, &block
  if block_given?
    puts 'Yes :method_2'
    puts number
    yield
  else
    puts 'No  :method_2'
  end
end

method_1 { puts 'I am a block' }

実行結果

$ ruby block_sample_5.rb
Yes :method_1
Yes :method_2
2
I am a block

例４との違いはここの（）だけ。

  method_2 plus_one(1), &block

つかれた。。。

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

Railsの生みの親、DHHのロックな発言に惚れた

Railsの生みの親であるスゴ腕エンジニアでしかもプロのカーレーサーで、イケメンで、嫁さんは超美人で、もう金も才能も成功も全部持っていってしまっているDHHのイキな発言が心に響いた。

元ネタはこちら。
https://hashnode.com/ama/with-david-heinemeier-hansson-cizf90u8w000ro353hnz8v4f5

私なりの意訳

= 質問者の投稿 =
なんでエンタープライズ向けの製品はASP、.NET、Javaのプラットフォームに偏ってるんですかね？なんでエンタープライズ向けでRails、Node.js、Pythonなんかの素晴らしいフレームワークを使った製品って出て来ないんでしょうか？近々これらの状況に変化はあるのでしょうか？

= DHHの回答 =
エンタープライズ向けの製品って技術的な優位性だけで決まるって訳じゃないんだよ。長期的なサポートとか、なんかあった時の言い訳や責任逃れのしやすさとか。売り込むにもそれを本当に必要としている人に売り込むんじゃなくて、そこから遠い所にいるマネージャー様に売り込む必要があったり。
そういう状況だと「ここはIBM製品を買っておけば、誰もクビにならずに済む」ってなるんだ。そんな基準では技術的優位性なんてちっとも重要でなかったりする。重要なのは箱にオラクルやマイクロソフトのマークが付いているってことなんだ。
まー彼らは自由を愛する俺達とは違うってことだね。

Rubyの顔がまつもとゆきひろ氏になっているようにRailsの顔はDHHになっている。そうなると単にコードを書くことだけが仕事ではなく、その思想や態度がRubyやRailsのコミュニティに影響する。

DHHのこうした発言に「あ、おもしろ」と思う人がRailsプロジェクトなんかに賛同してRailsが活気付いていく。

「おたくの製品はエンタープライズ向けにはちっともウケてませんね。ダメねー」なんて突っ込まれても「あんなダサい連中は放っとくに限るわ」とロックンローラーみたいな受け答えをする人がRailsのリーダーであることってまーまー幸運なことだな、と。
並の人間なら「いえいえ、エンタープライズのお客様にもご満足いただけるようにRailsのサポート体制も強化中でして、、」とやってしまうだろうが、我らがRailsのDHHはイケメンゆえにそんなダサい発言はしないのだ。惚れました。その調子でいってください。

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com