To be happy as a engineer

Web開発、機械学習・・・

Wantedlyでプレミアムスカウトをもらって訪問したが、気分悪く帰った話

プレミアムスカウトをいただく

細かい会社の説明は省くが、投資家向けにサービスを作っている会社で他にも堅い仕事をしており、単なるスタートアップではない会社だったので訪問することにした。

「力を貸して欲しい」、「気軽に話したいと強く思っている」などと書かれていたので、それなりに私のプロフィールに魅力を感じてくれたのかと思っていた。

採用担当の人間はいないようなので、若いエンジニアの方が兼務している様子。その方の紹介文には、「エンジニアリングよりコミュニケーションが得意」などと書かれている...

面談なのに三人が出てきて、いきなり自己紹介

面談というと気軽に情報交換するというもので、一般的に例えば志望動機などの面接に近い質問はこれまで訪問したどの会社もすることはなかった。

おそらくWantedlyのガイドラインのようなものに記されているのだろうと思っていた。

まず、三人が登場したことに驚いた。普通は一人か二人。

採用判断する気満々なのかと少し不安になった。

そして、プレミアムスカウトを送っておきながら、いきなりCTOの方が「自己紹介」をして欲しいと。いや、普通は呼んだ方がはじめにするでしょうと思った。

これまで訪問した10社程度はまず会社の説明をしてくれる企業だったので違和感を感じた。

どうやら、「面談」の意味と、横にいる採用兼務している若手エンジニアが「スカウトを送った事」を知らない様子。そのぐらい共有しておいて欲しい。

無感情&圧迫CTOと、ヘラヘラ採用担当

CTOの方から前職を辞めた理由だけでなく、なぜ辞める時に他のチームに移動しなかったのか、など面接染みた質問があった。

普通にやんわりと聞いてくれるのなら良いのだが、無感情で圧迫的な雰囲気で気分が悪い。一般的にはコミュ障の部類に入るのだが、CTOという看板を持って強めに出てくる。プライベートだと絶対に絡みたくないタイプ。

そして、採用しているJavaについての話になり、「今まで、PythonやPHPを使っており、今後オブジェクト指向をもっと勉強したいためJavaをやることは苦ではなない」と言うと、「別にオブジェクト指向は言語に関係ないよね」と強めに反論してくる。面談や面接で反論してくる人は初めてだったので、私は呆然とした...

また、採用担当のエンジニアはなぜか終始ヘラヘラしている。「何個か資格持っていますよね？」と聞いてくると自身のPCをみながらなぜかにやけ出した。

何か別の情報を見ている様子だったが、非常に不快だった。

この人はコミュニケーションを得意と自負しているようだが、飲みサーなどにいる大学生のようにコミュニケーション能力を勘違いしているようだ。名刺も逆向きで渡してきたし、ほんとに何なんだ。

また、これまた別の人だが、「この部屋のディスプレイ大きくした方がいいですよね」などと今話す必要あるかな、という私語がところどころあり全く訪問者へのリスペクトを感じなかった。

私はなぜ呼ばれたのだろうか

訪問者へのリスペクトもなく、サービスの説明は少しあったが、会社の規模やメンバ構成など基本的な情報はスキップされ、また「最後に質問ありますか」と面談では必ず必要とされるステップもなかった。

その時は私から積極的に聞く気は無かった。なぜなら、初めて面談途中で「帰りたい」と思っていたから。

CTOは早めに切り上げたい感満々で、30分程度で面談は終了した。「また採用担当の方から連絡させます」とあったが、以降連絡はない。望んでいるわけではないのだが、テキトーなことを言うな、ということ。

振り返ってみると、会話の中身自体はそれほど問題なかったのだが、何より態度の不快感が大きかった。それと面談という気軽な情報交換の場を理解していないことが気になった。

学んだこと

  • なぜスカウトを送ってきたのか理解できない時がある
  • スカウトを送ってくる人間と、他の採用権限を持っている人間で十分に情報を共有していない事がある
  • 特に人事のメンバがいない会社は無礼になりやすい
  • どんなに技術やプロダクトが優れていたとしても、入りたくない会社がある

後記

私はその後、小さなIT企業に入社しすぐに、Wantedly経由で訪問があり、企業側として席に参加する機会があった。いきなり参加するよう言われたので、「企業側からスカウトしたのか」を尋ねる時間がなく、また三人で出席することになった。

この投稿で自分が愚痴った状況を作る側になってしまった・・・

訪問者には申し訳ない気持ちになったが、もちろん失礼な態度や質問をしたつもりはない。

小さい企業で人事もいないと人的リソースが少なく何回も面談や面接を行う余裕がないので、面談が気軽な情報交換ではなく「選考」じみた面接になってしまうのは少ししょうがないのかな〜とも思ってしまった。

RESTの定義

Web Application

Roy Fieldingの博士論文はWebサービスに関するREST構造を、以下の６個の特徴を定義して説明している。

Client-Server

クライアントとサーバーの明確な区別がなされていなければならない。

Stateless

クライアントのリクエストはその達成に必要なすべての情報を含んでいなければならない。 サーバーはリクエストを繰り返すクライアントにのいかなる状態も保持してはいけない。

Cache

サーバからのレスポンスはcacheableかnoncacheableとしてラベル付けされることで、クライアント（またはクライアントとサーバ間の仲介）は最適な目的に対してキャッシュを使用できる。

Uniform Interface

クライアントがサーバ資源にアクセスする際のプロトコルは一貫性があり、well-definedで、標準化させていなければならない。一般的に使われるWebサービスの同型インターフェースはHTTPプロトコルである。

Layered System

プロキシサーバやキャッシュ、ゲートウェイはクライアントとサーバ間において、性能や信頼性、拡張性を改善するために不可欠なものとして配置される。

Code-on-Demand

クライアントは自らの環境で実行するために選択的にコードをダウンロードできる。

【メモ】データビジュアライゼーションの形態

Visualization

Interactive Visualizaion

【目的】発見・探索のために

【対象】一人の調査者または　協力者に向けて

【インプット】ユーザからのインプットに対して、画面が更新される

【コントロール】ユーザはすべて（データセットを含む）をコントロールできる

【開発】試作して質を確認

【レンダリング】リアルタイム

【媒体】ソフトウェア、インターネット

Presentation Visualization

【目的】コミュニケーションのために

【対象】大きなグループや大衆に向けて

【インプット】ユーザのインプットを受け付けない

【コントロール】ユーザは観察のみ可能

【開発】表現は高く洗練されている

【レンダリング】事前

【媒体】スライド、ビデオ

Interactive Storytelling

【目的】上記の両者の中間的な役割、interactiveなウェブページを通してpresentationをする

【対象】多くのユーザに対して

【コントロール】ユーザはあらかじめ決められたデータセットの詳細をフィルター、調査できる

【レンダリング】リアルタイム

【媒体】インターネット

Bias - Varianceのトレードオフ

機械学習つぶやき

目次

Biasが大きい時

モデルが単純すぎて表現能力が限定されている状況。

e.g. データ点が曲線なのに対してモデルは直線

未学習（under-fitting）といわれ、データに対して「バイアスが大きすぎる」と表現される。

Varianceが大きい時

モデルが複雑すぎて訓練データに対して過敏に適合している状況。

e.g. 次元数１００の回帰

過学習（over-fitting）といわれ、データに対して「バリアンスが大きすぎる」と表現される。

トレードオフ

上の２つの例は両極端な場合で、ほとんどの機械学習の問題がその間のどこかに最適なモデルがある。

バイアスが大きい場合の対処法

  • 特徴量を増やす
  • モデルをより複雑なものにする
  • モデルを変更する

バリアンスが大きい場合の対処法

  • より多くのデータを集める
  • モデルの複雑さを減らす

＊「実践　機会学習システム」を参考にしています。

DatoのGraphLab Create : 機械学習ライブラリ

GraphLab Create

目次

「GraphLab Create」とは

Dato(正式には GraphLab, Inc.)という企業が運営しているpython用の機械学習ライブラリです。Courseraの機械学習のコース（以下ＵＲＬ）

Specialization | Coursera

の中で僕は知りました。このコースの講師はワシントン大学の教授でかつ、DatoのCEOもしてます。

python用の機械学習ライブラリといえばscikit-learnが有名ですが、初学者の僕が使った感じscikit-learnより簡単に使えます。ライブラリとして使いやすく、わかりやすく設計されている印象があります。逆に言えば拡張性や柔軟性には疑問がありますが現在の僕にはわかりません。

ライブラリの種類

Rやpandasではdataframeを使いますが、それに対応するのがSFrameというデータ型です。基本的にデータを扱う場合はこれらのデータ型に変換します。 ライブラリの種類としては基本的な機械学習手法（回帰や分類）はもちろんのこと、recommender、sentiment analysis、topic model、deep learningもサポートしています。以下のドキュメンテーションをざっと見ればどのような事ができるのかわかると思います。

GraphLab Create API Documentation — GraphLab Create API 1.8.4 documentation

僕はレコメンダーに興味があるので以下の以下でレコメンダーに関するDatoが用意しているギャラリー（実践的なチュートリアルみたいなもの）をまとめておきます。

GraphLab CreateのDocumentation, user guide, how-to, gallery

GraphLab CreateのよいところとしてDocumentなど学習を進めていく上で必要不可欠なサポートが充実しています。

レコメンダー関連のGalleryまとめ

Galleryはデータの準備からレコメンダーであれば推薦、評価まで説明してくれています。python、ipython notebook用のプログラムをダウンロードできます。

レコメンダー用の基本的な機能を紹介。graphlab.recommender.util.random_split_by_userはhold-out-data(validation_set)を作る時に便利そう。

dataset : 評価値付きの映画データ

algorithm : baselineをpopularity_recommender（予測値はアイテム毎の評価値の平均）として、factorization_recommender、ranking_factorization_recommenderのRMSEを比較。アクション好きのユーザとロマンス好きのユーザをデータセットに加えて、 彼らにアイテムをレコメンドする。

dataset : 音楽データ(ratingなし)

algorithm : popularity_recommender、item_similarity_recommender

特にratingがない場合のimplicitなデータのみの場合のレコメンダーのつくり方。createする際にtargetを指定すればrmseを計算できるが、そうでない場合はprecisionとrecallのみの評価になる。 graphlab.recommender.item_similarity_recommender.createはデフォルトではjaccordが類似度の計算に使われるので注意。他にはcosine、peasonが使える（implicitな場合の計算方法はよく理解していない）。最後の方ではユーザが実際に見た映画とレコメンデーションリストの内容を比べるのでそこは面白いです。

レコメンダー生成、トピックモデル生成の基本的な構文を紹介。

今後

今回はGraphlab Createのレコメンダー関連のGalleryをまとめました。これからGallerを分類したいです。

機械学習における良い特徴量とは

機械学習つぶやき

２つの条件を同時に満たすもの

１．重要なことには敏感に反応するもの

２．重要でないことには反応しないもの

 

「実践　機械学習システム」より

 

興味のある方は「特徴エンジニアリング(feature engineering)」、「特徴選択（feature selection）」で調べてみてください。