@kyanny's blog

My thoughts, my life. Views/opinions are my own.

マイ・インターン

面白かった。アン・ハサウェイで仕事がテーマの話だと「プラダを着た悪魔」を思い出さずにいられなかった。最後までベンがデ・ニーロだと気づかなかった。

マイ・インターン (字幕版)

マイ・インターン (字幕版)

  • Nancy Meyers
  • コメディ
  • ¥1000

マイ・インターン ブルーレイ&DVDセット(初回仕様/2枚組/デジタルコピー付) [Blu-ray]

マイ・インターン ブルーレイ&DVDセット(初回仕様/2枚組/デジタルコピー付) [Blu-ray]

最後、ベンがCEOになるものとばかり思ってたので、ちょっと拍子抜けだった。でも、そうなってしまっては、上司が女性で部下が男性という時流に即したテーマが台無しになってしまっただろうから、人生の先輩からのアドバイス止まりでよかったのだろう。

その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か? - Kindle

仕事でエンジニア採用に関わっているので、挑発的な書名に煽られて読んでみた。

得るものは少なかった。ほとんど当たり前のことしか書いてなかった。一部、身につまされるところもあったが、総じて読む必要なし。

全体通して、著者の主張には一定の正しさがあると認められるものの、文章からにじみ出る「雰囲気」が嫌な感じだった。

採用者の立場
  • 求人は広告出稿と思え。採用はマーケティングと思え。
  • 人事部門の仕事は人事制度・人材育成・新卒採用・中途採用の順なので、そもそも中途採用は人事の業務の中ではマイナーで、従って経験値が少ない。
  • 人事は採用人数を KPI に置いたりしがちなので、採用 0 人だと人事が無能だと評価されるのをおそれてイマイチな人材でも雇おうとする。
  • 現場は目先の開発を乗り越えることしか考えずにエンジニアの採用を決めてしまう。会社や採用されるエンジニアの将来のことを考えない。

求人広告も広告である以上、 「どのようなターゲットか?」 「そのターゲットはどこにいるのか?」 「何を決め手に応募してくれるのか?」ということを突き詰めて考える

もうおわかりでしょう。応募者集めは、「転職する意向のあるエンジニアを集客する業務」なのです。営業・マーケティングに近い業務といっていいでしょう

良い採用担当者の条件として、次のことが挙げられます。 ●自社の技術力や開発力を正しく理解して、応募者の実力を正しく評価できること ●エンジニアの特性や志向性と適性を理解し、求職者とコミュニケーションできること ●エンジニアに必要なキャリアパスを理解していること ●人事制度や採用のルールを正しく理解していること ●人事採用担当者として、公平でわかりやすい対人能力があるこ

グループ2のエンジニアの採用で最も注意しなければならないのは、「そのエンジニアがどのようなキャリアプランを持っているのか?」です

グループ3のエンジニアの採用で注意しなければならないのは、前職でのインターネット・ITサービスの開発の成功の理由を本人が理解していないケースがある、つまり自己分析ができないエンジニアがかなりいるということです

CTOは、次のようなことを真摯に説明するのが重要です。 「技術開発のポリシーや開発現場のカルチャーはどのようなものか」 「どのような技術、どのような開発手法で、開発・運用をおこなっているのか」 「エンジニアのキャリアに関して、どのようなビジョンと制度があるか」 「どのような考えで、開発部門をマネジメントしているか

Twitterで他者を罵倒するCTOならば、「社内でもそのようなマネジメントスタイルではないか? だとすれば、彼の罵倒に合理性はあるのか?」といった感じです。

SNSでエンジニアとつながりを持っていく場合、低スキルで暇なエンジニアを採用に関与させてはいけません

エンジニアの立場
  • 日本の中小企業の人事制度はエンジニアのキャリアパスと合ってない。
  • 就職と就社の違いを意識せよ。会社勤めしてたら口で何を言おうが就社。「手に職」はフリーランスの道。
  • 生涯賃金は転職回数が0か1回が最も多い。なぜなら日本のほとんどの会社の人事制度は年功序列が色濃くて、長く勤めないと出世できず、昇給しないから。
  • 技術力が高いと会社に定着して長く活躍できるので、結果として生涯賃金も高くなる。
  • 銀行員や営業・販売など多くの仕事は給料と安定で選ぶもの。エンジニアのようにやりがいにこだわって仕事を選ぶほうが特殊。
  • 人材紹介会社に紹介すればライバルは技術の知識レベル低いし仕事も楽で簡単にできそう、と考えるエンジニアもいるが、甘い。シビアな営業職。
  • エンジニアから他の職種(経営企画)へのキャリアチェンジは経営管理部門から見るとナンセンス。未経験の職種に簡単にはかわれない。
  • エンジニアはキャリアプランの検討が不十分。評価(報酬)に不満があって転職するのに「働きやすさ」で転職先を決めるなど、ちぐはぐ。

「私は大企業での開発経験があるので、中小企業での開発などかんたんにできる。大企業での経験を活かして、中小企業で活躍しよう」 そう考えるエンジニアは、要注意です。大企業と中小企業では、そもそも企業としての行動様式がまったく異なるからです

社内・業界をリードする人材5・6万

日本のエンジニアは、技術力のプライドが人格を侵食するまでになっている

エンジニアは、自分の技術をはじめとする能力と、目標、そしてキャリアパスと真剣に向き合う必要があります。「開発のことだけを考えて努力すれば道は開ける」という、20世紀の日本企業が持っていた就業観にとらわれてはいけませ

悪い意味で印象に残ったフレーズ

〇〇さんのキャリアラダーは美しく充実したものになりますね

「Q社のエンジニアって、どんな感じの方が多いんですか? 無骨で真面目ひと筋な印象があるんですけど」 そう質問すると、女性のキャリアコンサルタントは答えました。 「ご家庭で奥様に大切にされている方はほとんどいらっしゃらないと思います。やさしさとか愛情に飢えていらっしゃるような感じです」 これは、彼女の事実上の勝利宣言でした

●開発エンジニアの開発時の思いを手紙にして、納品先へ写真つきで添付す

あと、小説仕立てで軍事・防衛系ソフトウェアの開発者を引き抜く、というエピソードが、「ライバル会社の優秀なエンジニアを、社内で同じ仕事をしている美人女性エンジニアに色仕掛けで落としてこいと命ずる」という内容で、読んでいて非常に胸糞悪かった。

追記: ソフトウェアエンジニアの採用について知りたければ、「ソフトウェア開発者採用ガイド」を読むとよい。この本は全編に渡って素晴らしい。電子書籍版が無いのが惜しまれる。

ソフトウェア開発者採用ガイド

ソフトウェア開発者採用ガイド

「はてなブログ大賞2016」の選者になりました

ご縁があって、「はてなブログ大賞2016」という企画で“推しエントリー”を選ばせていただきました。

blog.hatenablog.com

はてなブログの企画にお声がけいただくのは、「はてな エンジニアブロガー祭り」以来です。もう三年も経ったとは...。

私がイチオシに選んだエントリーは...「はてなブログ大賞2016」をご覧ください!

ちなみに、イチオシが他の選者の方とかぶったときに備えて次点に選んだエントリーは「結婚披露宴の写真を頼まれても、お断りする理由がある - 紺色のひと」で、コメントは、

いわゆる「カメラ女子」と対決、もとい、さりげなくフォローにまわったエピソードが印象に残りました。かくいう私も友人の結婚式の写真撮影を引き受けたことがあるのですが、デジタル一眼レフカメラを買ったばかりで写真撮影の基本的な知識も無い素人には荷が重すぎました。幸い、友人はプロの写真撮影も手配していたので事なきを得ましたが、自分が撮った写真はあまりにもクオリティが低く、ショックでしばらく直視できませんでした(おかげで友人に写真を渡すのがずいぶん遅くなりました)。この記事を読んで、二度と結婚式に本格派っぽいカメラを持っていくまいと心に誓いました(苦笑)。

でした。かぶらなかったので、お蔵入りとなりましたが、もったいないのでここで公開しちゃいます。

“推しエントリー”を選ぶにあたり、大変だったのは、「自分が読んだことがある、2016年に公開されたはてなブログのエントリー」を知ることでした。幸い、琴線に触れたエントリーについて、はてなブックマークや Twitter でコメントする習慣があり、はてなブックマークと Twitter を連携させていたので、自分のブックマークを見返すことで、イチオシに値するエントリーを発見することができました。はてなブックマーク便利ですね。最近は、「とりあえずブックマーク」という用途にはもっぱら Pocket を使っていますが、とにかく速度優先で放り込むばかりなので、文脈を思い出すためのメタ情報が欠けており、今回のような用途には不向きでした。はてなブックマークを少し見直しました。

話すだけで書ける究極の文章法 人工知能が助けてくれる

↓ここが一番良かった。著者はリープフロッグと呼んでいるが、茹でガエル現象ともいう。

これまでスマートフォンの仮想キーボードを頻繁に使っていた人たち(とくに、フリック入力方式に習熟していた人たち)は、音声入力の価値を過小評価し、それを利用できることを知っていても利用していない人が多いのではないかと思われます。つまり、スマートフォンの使い方が、携帯電話時代のものに固定化されているわけです。

音声入力はテキスト入力方式として、非連続的な革新の部類に入ると思う。キーボードもフリック入力も、手と指を使って一文字ずつ入力していくという点で連続的だが、音声入力は利用する器官が全く違うし、文字ではなく文章の単位で入力していく点も大きく違う。まるで、携帯電話のメールのかな漢字変換の革新を彷彿とさせる(初期の携帯電話は文節単位のかな漢字変換ができず、メールの文章を打つ時は「ぶんしょう」と打って「文章」に変換するのではなく「ぶん」と打って「文」に変換し、次に「しょう」と打って「章」に変換する、というやり方しかできなかった)。

俺も音声入力に前から興味はあったものの、積極的に使ってきたとはいえなかった(いざ文章を話そうとすると言葉が出てこなくて疲れるので)。タイマーのセットと Google 検索をたまに、くらいで、長い文章を入力することはほとんどやらず(できず)、この文章もキーボードで書いている。だが、全く新しいものが登場したときに、これまで慣れたやり方に固執して新しいものを軽く見る態度はとても良くない。頭ではわかっていてもだんだん考え方から柔軟性が失われていくのが老化だ。だから音声入力に挑戦することは、自分が茹でガエルにならないためのいいきっかけになると思う。

話すだけで書ける究極の文章法 人工知能が助けてくれる

話すだけで書ける究極の文章法 人工知能が助けてくれる

以下、ハイライトした箇所。

これまでスマートフォンの仮想キーボードを頻繁に使っていた人たち(とくに、フリック入力方式に習熟していた人たち)は、音声入力の価値を過小評価し、それを利用できることを知っていても利用していない人が多いのではないかと思われます。つまり、スマートフォンの使い方が、携帯電話時代のものに固定化されているわけです。

Read more at location 138

とくに愕然としたのは、「自分は話す内容を持っていない」と気付く場合があることです。散歩時間にスマートフォンに話しかけようとしても、何も出てこないことがあるのです。つまり、「私は何も考えを持っていない」ということです。  当たり前のことですが、話す内容を持っていなければ、いかに音声入力機能が発達しても、無意味です

Read more at location 148

「文字を書く」という作業が簡単ではなかったからです。それを意識するようになったのは、「話す」という行為自体は、格別の努力なしにもできる簡単なものだからでしょう。「それにもかかわらず、話せないのは、話す内容を持っていないからだ」ということが、明白になってしまったのです。

Read more at location 153

ITの進歩については、「一時的で暫定的な技術なのか、あるいは将来発展していく技術なのか」の見極めを行なうことが必要です。

Read more at location 307

これまでは書くスピードに限界があったので、「考えていることのすべてを書き終わらないうちに忘れてしまう」ということもありました。

Read more at location 387

したがって「メモすべきかどうか」などと思い悩まず、なんでもメモしたほうがよいのです。「

Read more at location 398

思いついたこと、アイディア、新聞や書籍に書いてあったこと、買いたい書籍、買いたいもの等々。どんなことでもメモできるし、したほうがよいでしょう。そのうちに使い方が分かってきますし、

Read more at location 400

Gmailには、タグをつける機能などがありますが、それらは一切使用していません。「あるときに重要と考えてつけたタグが、その後重要でなくなり、新しいキーワードが重要になる」ということがしばしば発生するからです。検索機能が強力であれば、タグは不必要なのです(

Read more at location 485

むしろ、論理構成がはっきりせず、できるだけ長いほうがよいのです。ですから、思いついたことを、音声入力で次々に入力していけばよいでしょう。

Read more at location 556

序章で、「話そうとしても何も思い浮かばない場合がある」と言いました。このとき、頭の中は空っぽになっているのではありません。あまりに多くのことを考えているために、考えが集中していないのです。

Read more at location 658

では、集中するにはどうしたらよいでしょうか?  きわめて有効な方法は、メモを「見る」ことです。それによって、考えが、その案件に固定されます。

Read more at location 676

メモを書く理由は、「備忘」ということだけではなく、「集中の支援」ということもあるのです。

Read more at location 687

しかし、それにただ従うというよりは、むしろ、「アドバイスに触発されて、あなた自身が新しい解決策を思いつく」という場合のほうが多いのではないでしょうか?

Read more at location 733

ですから、発想のためには、あるテーマに頭の活動を固定化する必要があるのです

Read more at location 796

文字は、もちろん他人とのコミュニケーション手段として重要なのですが、自分自身とのコミュニケーションでも重要な役割を果たすのです

Read more at location 801

序章で述べたとおり実際に話してみると、内容があまりないということが分かって、愕然とすることもあります。音声機能が入力受け付け状態になっているにもかかわらず、「あー」とか「うー」と言うだけで、意味のある言葉が出てこないのです。これでは、音声入力機能でいくら文章を速く書けるといっても、何の価値もありません

Read more at location 867

まずは、文章化することによって、あなたがその問題についてどの程度の分量の考えを持っているかを把握しましょう。5分間話せる内容を持っているのか、あるいは求められれば1時間でも話せるのか。それとも、1分も話せないのか? それを把握しておくのは大変重要なことです

Read more at location 873

文字にしてみれば、他人のものとして見ることができます。自分の頭の中を、あたかも他人が見るように覗くことができるのです。これは、自分自身との対話です。それによって、自分の考えの問題点を知ることができます

Read more at location 891

キーボードで入力をする場合には、それまで入力した文章を見て、論理展開を頭で考えながら文章を打ちます

Read more at location 927

このため、講演の際に、私は全体の構造を示すレジメを必ず配ることにしています

Read more at location 933

日本の講演の大部分は一方通行で質疑の時間はないのですが、英語の場合には最初のプレゼンテーションは半分程度であり、残り半分程度が質疑になるのが普通で

Read more at location 950

明日プレゼンテーションがあるなら、音声入力でメモを作ろ

Read more at location 987

こうした場合、「考えはすべて頭の中にあるから大丈夫」などと考えず、スマートフォンに向かって話しかけて、考えを文字化すべきです

Read more at location 991

さらに、考えていることを順番に話してみましょう

Read more at location 994

5分でも10分でも良いから、あることをスマートフォンに向かって話し、その内容を見て、どこが足りないかを考えるのです

Read more at location 1022

処理した後のGoogleドキュメントのメモは、削除してしまうのがよいでしょう

Read more at location 1124

ところが、これは、NHKのアナウンサーのスピードで話し続けた場合の約5分の1の分量でしかありません。  音声入力が途中で中断することの影響もありますが、考えながら話しているので、原稿を読み上げるように淀みなく話し続けられないことが、一番大きな理由です

Read more at location 1174

文章を書くために最も重要なのは、「とにかく書き始める」ことです

Read more at location 1190

「どうしても言いたいことがあるかどうかを、まず確かめるべきだ

Read more at location 1233

文章を書く作業で最も難しいのは、文章の最小単位を適切に結合し、全体として説得力のある論述に仕上げてゆくことです

Read more at location 1312

頭の中にあったあまり整理されていないさまざまな考えを、そのまま並べていくだけでは、まとまった主張になりません。自分が最も主張したいのはどれかをはっきりさせ、不要なものは捨てる。そして、主要な論点を補強するための材料を揃えることが必要です

Read more at location 1356

どのデータをどのように分析するかを指示する必要があります。ところが、それは実際にやってみないと分かりません。つまりデータ分析とは、自分自身で試行錯誤しながらでしか、進めることができない作業なのです

Read more at location 1423

ところが、クリストファー・スタイナー『アルゴリズムが世界を支配する』(角川EPUB選書)によると、音楽の分野では、人間の作品と区別がつかないような作品をすでにコンピュータが作るまでになっています

Read more at location 1469

セマンティック検索の目的は、文字列(strings)ではなく、モノゴト(entity)を探し当てることだとされます

Read more at location 1806

つまり、「月といっても、moonと、月がついた名前はまったく別のものである」ということを、コンピュータが認識しているのです。これは考えてみれば驚くべきことです。Googleのコンピュータは、世界を構成する概念を理解しつつあるということになり

Read more at location 1814

異なる言葉であっても同じ意味を持つ場合、それらを同じと解釈する」ことが強調される場合が多いように思われます。  確かにそれは重要なことです。しかし、これはシソーラス(類義語辞典)を持っていれば、かなりの程度は解決できる問題です

Read more at location 1822

知りたいことがあったらすぐに話して検索する」習慣をつけることです

Read more at location 1867

重要なのは、このような技術がすでに利用可能になっていることを知り、それを応用するために仕事の仕組みを変えていくことです。これが、本書で強調してきたことです

Read more at location 2055

補助的な仕事、つまり創造を行なわない単なる中間的な仕事では、人間が排除されていくでしょう。付加価値を加えることなく、情報伝達の仲介しか行なっていなかった人々は、不要になるでしょう

Read more at location 2152

私は仮に翻訳機能がいま以上に発達して実用段階に達したとしても、なお外国語の勉強が必要だと考えています

Read more at location 2170

ゲーテの『ファウスト』は、ドイツ語でしか成り立たない作品です。ドイツ語と比較的近い言語である英語に翻訳しただけでも、その価値は大きく損なわれます

Read more at location 2174

知識の教育は今後も必要不可欠だと考えます。なぜなら、知識がないところに創造活動があるはずはないからで

Read more at location 2179

このままでは、日本のすべての経済活動が、Googleの支配下に入ってしまうと危惧する声もあります。優秀な大学院生が、日本企業に入ると力を発揮できないため、外資系企業に入ろうとする傾向があるとの警告もあります

Read more at location 2204

手書き文字の認識。多くの人は、これに期待しています。しかし、これもあまり意味がありません。なぜなら「書く」ことは、それほど簡単ではないからです。キーボードを打つほうが早く、疲れも少ない。より効率的な手段が利用できるのですから、非効率な手段である手書きを利用する必要はありません。手書き文字は、写真に撮ってアナログ情報として保存しておけばよいでしょう

Read more at location 2253

音声入力の進歩に、問題がないわけではありません。最も大きな問題は、この技術を提供できるのが、ごく一部の企業に限られてしまうことです

Read more at location 2261

こうした状況に対して、日本は一体どのように対応できるのでしょうか? われわれは、それを真剣に考える必要があります

Read more at location 2264

マル カイギョウ」と言えば、句点を打って改行します(逆に言うと、「改行」という言葉を文字としては表示してくれないわけです)。また、( )「 」なども音声で入力できます(それぞれ、カッコ、カッコトジ、カギカッコ、カギカッコトジ)。中丸、アスタリスク、星印も変換します

Read more at location 2305

homebrew-versions で MongoDB 3.2 を今すぐインストール

今すぐ == 2016-12-06 13:30:00 時点。

homebrew-versions 用の MongoDB 3.2 Formula はすでに Pull Request が出ている。

github.com

が、俺はいますぐ Homebrew で MongoDB 3.2 をインストールしたいんだ...!! というときの手順。

0. homebrew-versions をインストールしておく

$ brew tap homebrew/versions

1. ローカルファイルシステム上のどこに homebrew-versions の Formula 群が置いてあるか調べる

$ find /usr/local -name 'mongodb30.rb'

2. Pull Request されてる mongodb32.rb をそのパスに置く

$ cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-versions
$ wget https://raw.githubusercontent.com/lancespeelmon/homebrew-versions/1a668aa878ec22b593122afc9161eca2d50d8509/mongodb32.rb

3. MongoDB 3.2 をインストールする

# 念のため MongoDB 3.2 の Formula が利用可能になってるか確認する
$ brew search mongodb

# インストール時に mongodb32 という Formula 名を指定する
$ brew install mongodb32
  1. 後片付けをする(しないと後でハマりそうなので)
$ rm mongodb32.rb