St_Hakky’s blog

Data Science / Human Resources / Web Applicationについて書きます

Effective pythonを勉強します【これはまとめページ】

こんばんは。

Pythonを猛烈に使うので、一回Pythonしっかり勉強しようと思いまして、Effective pythonっていう本が研究室にあって何気なくパラパラめくったら「おぉ…いい本だ…!!!」ってなったので、読むがてら自分で調べたこともまとめておこうかなーと。

www.effectivepython.com

ここにある通り、Pythonプログラムを改良する59項目が掲載されています。詳細は本に書かれているので、それを読めば良しとして、大事そうなところと、これに関連して勉強したことを書きます。

このページはまとめページとして、随時更新していこうかと思いまする。

○環境

OS:Mac
Python:3.5.2

データ分析をするときのフォルダ構成をどうするのか問題について

こんにちは。

今回は、データ分析をするときのフォルダ構成をどうするのか問題について、ちょっと調べてみたので、自分のこれまでやってきたことを振り返りつつ、まとめます。

○調べた動機

某データサイエンス系のインターンシップでの反省点でもあり、これは普段研究などでコードを書くときに悩みながら作っているのですが、どうしたものかと思って悩んでいました。

  • データの保存どこでどういうフォーマットでするんだよ!
  • くっ、このモデルも試したい、、、でもファイルとフォルダの構成ガァァァァ
  • Aさん、基礎分析とモデルのファイルをごっちゃにするんでない!(ウワァァァァァ!!誰かしっかり共有しておけヨォォォ!!!)

とまぁこんな感じで、複数人でやるとより露骨になってきたのと、いつもだいたいやるフローとしては同じなので、共通化や一般化がある程度できるはずと思っていました。

○私がこれまでやっていたこと

├── README.md
├── analysis # データの基礎分析
├── config # 環境設定など
├── data  # データの保管場所。loadingのところで行った整形データもここに入る
├── loading # データのクレンジングや、ロード、整形処理を行う
├── model # モデルの処理
│   ├── predict # 予測を行う処理
│   └── train # 学習を行う処理
├── report  # 報告用の綺麗な画像などを保存したり、そのための処理を書くところ
├── result   # ログとか、解析の結果を保存する場所
│   ├── analysis  # analysisで行った結果を保存する場所
│   ├── loading  # loadingで行ったログを保存する場所
│   ├── model  # モデルの結果を保存する場所
│   │   ├── predict   # 予測結果の保存する場所
│   │   └── train   # 学習結果の保存する場所
│   └── validation  # 検証の結果を保存する場所
└── validation  # 検証を行うための場所

この構成にしてからは、あんまり不満もなく、これで一旦みたいな感じで書いていたんですが、もう少しなんとかできるよなーとか考えていました。

○機械学習では色々試行錯誤していると死んだとならないために

モデルを試行錯誤したりしていると、いつの間にか「なんなんだこのクソみたいなコードは、、、」となりますし、モデルの精度が向上しない時に、「おい、どこ直せば良いんだ、、、そして治すとこっちが、、、あぁ、、、」ってなります。

その気持ちをもってTwitterを見ていたら以下のスライドを見つけました。

www.slideshare.net


全人類が悩んでいるんじゃないかという気持ちを凄い綺麗に表現されている上に解決方法も具体的に載っているという笑。

画像認識系の話は以下でみれます。

www.slideshare.net


○調べてみた結果

ということで、調べてみました。その結果は以下。

  • もう、悩まなくていい
  • pipで一発インストール。
  • テンプレートをコマンド一発でジェネレートできる

最高ですね。

○調べて行き着いたところ

見つけました。もう少しなんとかしたいと思った点を克服しているサイトが!!

qiita.com

このサイトに書いてある、

あなたは機械学習のプロジェクトを毎回違う構成で作っていませんか?
何をどこに配置するかで悩んで時間がかかっていませんか?

すげー共感した。そして、「コマンド一発」で書けるなんて、、、以下のサイトがデータ分析で使用するテンプレートとして用意されているもの。

github.com

フォルダの構成はご覧の通り。

├── LICENSE
├── Makefile           <- Makefile with commands like `make data` or `make train`
├── README.md          <- The top-level README for developers using this project.
├── data
│   ├── external       <- Data from third party sources.
│   ├── interim        <- Intermediate data that has been transformed.
│   ├── processed      <- The final, canonical data sets for modeling.
│   └── raw            <- The original, immutable data dump.
│
├── docs               <- A default Sphinx project; see sphinx-doc.org for details
│
├── models             <- Trained and serialized models, model predictions, or model summaries
│
├── notebooks          <- Jupyter notebooks. Naming convention is a number (for ordering),
│                         the creator's initials, and a short `-` delimited description, e.g.
│                         `1.0-jqp-initial-data-exploration`.
│
├── references         <- Data dictionaries, manuals, and all other explanatory materials.
│
├── reports            <- Generated analysis as HTML, PDF, LaTeX, etc.
│   └── figures        <- Generated graphics and figures to be used in reporting
│
├── requirements.txt   <- The requirements file for reproducing the analysis environment, e.g.
│                         generated with `pip freeze > requirements.txt`
│
├── src                <- Source code for use in this project.
│   ├── __init__.py    <- Makes src a Python module
│   │
│   ├── data           <- Scripts to download or generate data
│   │   └── make_dataset.py
│   │
│   ├── features       <- Scripts to turn raw data into features for modeling
│   │   └── build_features.py
│   │
│   ├── models         <- Scripts to train models and then use trained models to make
│   │   │                 predictions
│   │   ├── predict_model.py
│   │   └── train_model.py
│   │
│   └── visualization  <- Scripts to create exploratory and results oriented visualizations
│       └── visualize.py
│
└── tox.ini            <- tox file with settings for running tox; see tox.testrun.org

私のよりも見通しが良くて、どこに何を書けばいいかわかりやすい、、、


しかも使用者が気をつければ、上で紹介した機械学習のコードで泣くポイントをほとんど回避できる気がしている。。。


というか、このプロジェクトの大本のサイトにあるこの記事で書かれている通り、フォルダ構成がほぼすべてを表現できるように設計されている。。。



このテンプレートを使用する方法も、コマンド一発、、、しかもパッケージもpipでインストールできるし最強かよ、、、

pip install cookiecutter 

わーい!

後は、自分の使いたいテンプレート(上で紹介したテンプレート)を指定して、使用するだけという。

cookiecutter https://github.com/drivendata/cookiecutter-data-science

後は指示に従って頑張るだけ。


わーい!

◯この記事のテーマからは外れるかもだけど

基本的にはフォルダ構成を決めて、どこに何を書くかさえモデルを書く際に決めれば、基本的に機械学習系のコードでは泣かなくて済むことが増えるんじゃないかなという印象です。

実際のアプリレベルでの運用とかまでは私はまだやったことがないですが、個人でKaggleとか出たり、研究とかで開発する分には上のレベル感で十分かなと思いました。

実際のビジネス運用まで考えると、テストとかのことも考えないといけないですし、そうなるとちょっと話はまた変わってくるのかなと。

それでは。

KPIについてぼんやりしかわかってなかったので、本を2つ読んで見た

こんばんは。

2月に行ったとある某企業のインターンシップであったり、今運営しているメディアであったりで、KGI/KPIを使って目標や成果の管理をしているのですが、webにある断片的な情報だけで運営していました。

メディアのようにPVとか離脱率とか、そういうデータをしっかり取れるような事業ならなおさらデータドリブンな意思決定は大事になってくると思います。

そのため、KGI/KPIなどを使って目標を数値管理などをできるようにしておけば、振り返りもできやすいし、指標も明確になるので、すごくこれは便利なのですが、うまく運用できていなかったし、どう決めていけばいいかを体系的に勉強したことがありませんでした。

このような経緯があり、2冊ほど本屋で目に留まったものを読んで見ました。

○読んだ本

読んだ本は以下の2冊です。(何故かタイトルが出ていないという話をきいたでの、一応タイトルも文字で書いておきます笑)

KPIで必ず成果を出す目標達成の技術 計画をプロセスで管理する基本手順と実践ポイント
2時間でわかる図解KPIマネジメント入門

どちらもKPI運用の基礎から、運用時の悩みポイントであったり、運用時の注意事項などがわかります。本の内容はすごく良かったです。

○学んだこと

学んだことは主に以下の3点。

  • 成果までのフローを全て洗い出した上で、KGI/CSF/KPIを階層的にトップダウンで決める
  • 絶対にKPIは数値化する(できる)
  • PDCAをちゃんと回す仕組みを作る

以下、それぞれ書いていきます。

○成果までのフローを全て洗い出した上で、KGI/CSF/KPIを階層的にトップダウンで決める

プロジェクトの大雑把なビジョンとかはあると思いますが、そこからKGIをまず決めます。その時に、KGIに至るまでの過程をフロー(orKGIに対する要素分解)を全て洗い出した上で、CSF(重要成功要因)を決めます。

ここで、全て洗い出すということが大事だそうです。なんとなく雰囲気で「ここら辺大事じゃね」みたいな決め方をするとドツボにはまりますし、「これって本当に本質なんだっけ」とかをプロジェクトが進んだ時に生まれます(これはマジで本当にそう)。

そのCSFを元に、KPIを決めるという流れです。

f:id:St_Hakky:20170323004824p:plain

階層構造的に決めていくというイメージを持って、上から順番に決めていくというのがわかりやすいかと。

そして、このKPIが次はKGIとしての役割を持って、KPI(KGI)→CSF→KPI(KGI)→CSF→KPI・・・みたいな感じでどんどん細かくしていくイメージで決めるとスッキリ決まるそうです。

まぁ概念的には簡単なんですけど、本を読んだ時にこれ実際にやるのむずくねと思っていたら、「目標を分割して行った際に、それを役職(例えばメディアならライターやエンジニア、広報など)ごとや、大きな組織だと部署単位レベルで分けれれば、いい感じになる」という記述が本の中にありました。

オォーなるほど!みたいなのになりました笑(これってもしかして当たり前なのかしら笑)。例えば、「KGI:10PV/月間」とすると、CSFとして、PVに至るまでの経路を洗い出した時に、
・ライターがより達成してできること
・広報がより達成できること
・エンジニアが達成できること
みたいな感じで別れると思うんですね。そうした時に、その役職単位でKPIを設定して、各作業レベルにまで落とし込めば、やることが明確になり、振り返りも容易になるという流れです。

自分の中で割と腑に落ちた感じがしたので、勝手に感動していました笑。役職単位で、もっと言うと個人単位でKPIを決めておけば、「できたか、できていなかったか」が明確になり、目標の設定も振り返りも楽になるなぁと思いましたし、これは本当に私にとっては感動でした笑。

○絶対にKPIは数値化する(できる)

これが大事だそう。絶対に数値化する。できないわけはないという感じらしいです笑。

これは実際にやってみて思ったんですが、できますね。笑

できる理由ですが、数値化するということは、数値でしっかり「測れる」ということ。測れさえすれば、数値化できるので、逆に測れるレベルにまで具体化することが大事というイメージでしょうか。

測れる指標などは分野などによって違うと思いますが、ある程度は共通していると思いますし、本の中でも紹介されていましたので、すごく参考になりました。

まぁ意識的な話になっちゃいますが、数値化できないと思うと、そこで思考停止になっちゃうので、しっかりを決めることを意識するといい感じだとも思いました。笑

○PDCAをちゃんと回す仕組みを作る

PDCAをちゃんと回す仕組みを作ることも大事なんだなぁと。

仕組みというのは、「意識も含めて」です。

特に「C(check)」の部分がおろそかになりやすいので、毎月や毎週といった単位でしっかりとKPIに対してどのくらい達成できているかを見ることが大事だそうです。

本とは少し違いますが、読んで考えたこととして、達成しているかどうかを振り返るために、以下のようにすればいいのではないかと思いました。

  • 期間を区切ってKPIなどを決める
  • 期間の終わりだけでなく定期的に、KPTなどの振り返り手法を使い、しっかり振り返る
  • KPIへの達成度は割合と「達成 or 未達成」の2つの見方でみる
  • 反省点を元にしながら次の期のKGI/CSF/KPIを決める

当たり前のことしか書いていないですが、これをプロジェクトメンバー全員に「意識」してもらうために、プロジェクトのリーダーはこまめに振り返りを行い、目標管理をするのがいいと思いました。

○まとめ

データを生かして利益やビジョンの達成につなげるための目標管理手法として、KPIはもう少し勉強を進めていきたいなと思いました。

頑張りたいです。それでは。

「すみません」よりも意義のある言葉を

こんにちは。


「すみません」

「申し訳ございません」


これらは割とよく日本人が使う言葉なのかなぁと思います。今日はこれについて書きます。

○謝っても気持ち的な意味以外の状況は一ミリも改善されない

これは最近、私の身の回りのいくつかの団体で発生している出来事ですが、広く日本的にみても、会社などで不祥事が起きるとその会社の社長が辞任(謝罪とか責任を取ってという意味で)するといったような出来事が多く発生しているかと思います。

気持ち的な面で謝ることは大事なのは事実で、またこれが常に当てはまる訳ではないとは思うんですが、大抵の場合「謝っても気持ち的な意味以外の状況は一ミリも改善されない」ことが多いんじゃないかなぁと。

私自身の行動として振り返って見ると、恐ろしいことに、以下のようなシチュエーション(謝って終わったが一ミリも状況が変わっていないシーン)って今までも結構あったなぁと。

〜遅刻した場合〜
A氏:「遅刻しました。すみません。」
B氏:「おけ」

〜締切に間に合わなかった場合〜
A氏:「すみません、〇〇が間に合いません。大変申し訳ございません。」
B氏:「いつ出せる?」

とまぁこんな感じで、「すみません」までは言ったとしても、そこから先のアクションが一ミリもなく、完全に受け身状態になるということです。

確かに謝ることは大事かもしれませんが、それで「君の責任をどうやってこの状況から挽回するのか」の方が、その謝る姿勢を本当の意味で示す、つまり行動として示すことの方が大事なんじゃないかなぁと、最近思うようになりました。

○これはもはや文化的な背景なのか

これは文化的なものなのかもしれないと最近は思うようになりました。外国人と話す機会も増え、ふと言われたのが「日本人よく謝るね」みたいなことです。例えば以下の動画とかにも取り上げられてますね。

youtu.be

あんまり日本と外国の比較って一般論すぎて好きではないけど、確かに外国人の人からあんまり謝られたことはないなぁと笑。あとは以下の記事。

日本人の謝罪文化を知ることの大切さ | 「人」の視点から、グローバル化を。
日本人は謝りすぎ?日本人にとっての「すみません」外国人との違い

上の記事を見ると、いわゆる「謝る」シーンのような状況になった時に、

・日本:「謝ってきちんと気持ちを示すこと」に重きを置く
・諸外国:「謝ることよりも、責任をきちんと果たす or 責任の所在が自分にないことを示すこと」に重きを置く

というような感じで別れるのかなぁと。もちろん、これはあくまで一般論ですが、文化的な背景が強い事象なのかもしれないです。

○そうは言ってもビジネスシーンで且つ身内ではこれはイラナイ

対会社間であったら、まずはしっかり「謝る気持ち」を示し、そのあとで対応を練るのがいいでしょう。



しかし、こと身内(会社内)に関しては、これはいらないなぁと。



「すみません」の5文字のタイピングが本当に無駄だし、割と謝罪文を考えるのって時間がかかるじゃないですか笑(経験談)



その時間を使うのなら、その謝るべき事象に対して「こうします」のアクションを言って、それをするべきなんじゃないかなぁと。それが本質的には「謝った」ことになるんじゃないかと。

謝るよりも、実はその後の行動の方が難しいって思ってとりあえず謝っているのであれば、それは本当にダメで、全然謝っていないことになっちゃうんじゃないかな、と。

身内だったら、そんなのお昼ご飯とか食べた時とかお酒飲んでいる時に、「ごめんなさい」っていえばいいじゃないと思うし、行動で示すことが多くなったら、こういう「謝る」って本当に少なくなるだろうし、みんなでカバーってそういうことなんじゃないかなぁと。

この手の本質ではない活動に、どれくらい時間を使っているのだろうと思うと、それって結局時給換算にすると本当に無駄で、もっと他にするべきことがあるんじゃないかなぁと思うわけです。

起きてしまったことは起きてしまったんだから、それにクヨクヨ謝罪を求める方も、やる方も、本当に有益なことに時間を割いているとは思えない訳なのです。

もちろん、そうじゃない空間もあるはずで、状況によって変わるだろうし、一概にこれがいいというわけでもないと思うのですが、いろんな団体で同時期にこのような事象が起こっていたので、体感的に多いなぁと思ったので書きました。

それでは。

他人からの感情的ラベリングによる再帰型自己陶酔と他者への攻撃的ランク付け増大効果

こんにちは。最近、これについて考える機会が多かったので、書きまする。

それはそうと、意味のわからないタイトルすぎて草ですよね、全く。一つ一つ説明するスタイルで書こうと思います。

以下の順番で行きます。

  1. 他人からの感情的ラベリング
  2. 再帰型自己陶酔
  3. 他者への攻撃的ランク付け増大効果

○他人からの感情的ラベリング

これは、俗にいう「〇〇さんって、〇〇ですよね〜」という会話です。ちなみにいうと、私は他人がどう思っていようが「どうぞご自由に」と思うので、あんまり気にしないのですが、これが良くも悪くも影響するシーンがあるな、と思ったのでこの話をまず書きます。

先日、某意識高い系ビジネスインターンのアフターイベントに行ってきたのですが、その際に幼少期の振り返りみたいな時間があったのですが、以下のような発言がありました。

・小さい頃、お母さんに褒められたいから、〇〇をした
・〇〇と言われることが嬉しくて、〇〇をした
・〇〇な子だね、と言われたので、〇〇をすることが増えた

他者からの感情的なラベリングが影響した例だなぁと思って聞いていました。ここで「感情的」と行っているのは、その人の主観によるものだからです。何もその人が客観的な尺度を持っているわけでもないのですが、その人の経験値から「感情的な主観」に基づき、ラベリングしている例です。

私はこの影響は、幼少期ほど強くその人に影響を与えると思っていて、例えばこれはよく言われることですが
・「〇〇さんは良い子だね」と言われて育った子
・「〇〇さんは悪い子だね」と言われて育った子
では、その後の人生に影響を強く与えるといったようなことです。これがここで言う「感情的なラベリング」を指します。

○再帰型自己陶酔

幼少期には限らず、これは影響を与えると思うのですが、特に幼少期の価値観形成のフェーズにおいて、「何を良し」とし、「何を悪し」とするかはすごくその後のその人の人生に影響を与えるのだなぁと。

そして、この「価値観」は周りにいる人たちの影響が大きく現れます。周りが良いと言っていたら良いと判断し、悪いと判断していたら悪い。その「集団の価値観」が個人に絶えず与えられ続けるのですから、「それを当たり前」とし、集団としての変化への思考が停止していきます。

そして、この集団としての変化がなくなった集団からの影響は個人にも影響を与え、再帰的に自己を酔わせます。

  1. 周りから感情的ラベリングが行われる
  2. ラベリングに基づき行動を行う
  3. 行動を行うと、周りから更に評価される

集団に変化がないことにより、この繰り返しが行われます。そして、その集団の中である程度の地位を獲得したとすると、その人はどうなるか。自分で自分をより集団に沿わせるような形にしていくため、自分でも気がつかないうちに、その集団の中での価値基準に染まって行きます。

別の集団の他者から見て「異常」となる人はこの例が多いような気がします。

○他者への攻撃的ランク付け増大効果

さて、このように価値観に染まった人はどうなるか。

例えば、以下のような話はよくあるかと思います。

・コードが書けないビジネスサイドはダメで、コードが書けるエンジニアほど良い
・学歴が低く、高所得でないやつはダメで、学歴が高く、高所得であればあるほど良い

私はこれが良い悪いと言っているのではなく、ここで私が言いたいのは、このような思想が生まれるのは、

  1. 感情的ラベリングが繰り返され、
  2. 集団の中で再帰的に自己を陶酔させていったから、
  3. それに沿わない他者を異常とみなし、
  4. 攻撃的な形で高位・低位を感情的ラベリングに基づき、ランクづけを行う

からではないかなぁと思うのです。そして、この効果は再帰的に自己をそまらせていけばいくほど、そうなるのではないか、そして、この効果をより受けている人ほど、自分がその集団でどのように思われているかを気にするのではないか、他者をラベリングするのではないか、と言うことです。

しかし、この価値基準は集団により大きく変わり、価値基準の平均より上か下かで分類すれば、それはおおよそ1:1になるだろうなぁと。

集団によって価値基準が変わり、評価が変わるのであれば、評価がされる集団に行けば良いわけで、評価がされない集団に行くことはほぼ意味をなさないし、たとえ行ったとしても評価がされないからと嘆く必要もなく、努力をすれば良いと思うわけです。自身が評価され、評価されない空間があるわけなので。

それでは。

何故求職者の情報は開示要求があるのに面接者の情報は開示されていないのか問題に対して

こんばんは。

今日は、「企業の求職者の情報をインターネット上で確認する」という行為について、そういえばと思ったことがあるので書く。

○そういえば何故面接官の情報は開示されないのか?

採用面接のシーンにおいて、求職者の情報は開示され、面接官は準備のため色々ググることは広く就活生の間では囁かれているし、実際にそういうのをしている企業も多いと思います。

このためにTwitterとかを就活間際になると削除しまくるなどする人もいるわけですし、ちょっと具体的には忘れてしまいましたが最近だと、その人にまつわるsnsとか論文とかネットに上がっている情報を自動で集約するサービスとかもあるようなので、怖いもんだなぁと。

普通の採用のシーンでは、
・求職者情報を確認し、その人がいかなる人かを想定する
・その上で、質問を考えたり、多少選考の流れにアレンジを加える
などを企業側(ここでは面接官を指します)はするはずですし、このために求職者の人にはCV(履歴書)なりを送るわけだと思うんですね。

ただ、ここで思ったのが「そういえばなんで面接官の情報をこちらに渡さないんだ?」っていうことです。フェアじゃない。うん。

いや、まぁフェアじゃないとかはおいておいて、普通に開示した方がお互いにとってメリットが大きいはずです。以下は就活をして思ったことも加味して、それを書く。

○面接官がどのドメインの知識を持っていて、どんな仕事をしているのかがわかっているとやりやすい

これはもう面接をしている時にわかっていればこれほどいいものはないと、死ぬほど何回も思いました。

■メリット1 : より具体的な質問ができる

まず、メリットとして一つ目は、具体的な質問ができます。

「先日、〇〇な手法について勉強しました。面接官氏さんは〇〇の手法をお仕事で使っているかな、と思うんですけど、〇〇なポイントの克服はどうしていますか?現場でのデータの性質などで克服できたりするのでしょうか?」
「面接官氏さんは、〇〇学会に出られたと拝見しました。〇〇学会で特に面白かった技術はなんですか?」

とか。

僕ら学生ベースだと、一つ目みたいなこういう実世界の業務とかは割とイメージしにくかったりするので、これがあるとクソいいなぁって思ったりしました。

また、面接官氏さんがどんなことに興味を持っているのかとかは、実際にどんな人が働いているかを見る一つの指標になるので、こういうのもできればなぁと思っていました。職場でご飯食べた時とかに気の合う会話ができそうかとかも大事だと思いますし。

あとは、所属部署の名前が特殊だと、「いやそれ何しているねん」みたいなのになりますし、「逆に他の部署はどんな風になっているの?」ってなるので、基本情報とかは教えてもらってもいいんじゃないかなぁと就活時とかに思っていました。

■メリット2 : 自分の説明もしやすくなる

他のメリットしては、自分の説明が鬼しやすくなるということです。

つい先日あったのが、強面のなんか技術わかっていそうな雰囲気の人が出てきてかつその人がデータサイエンス系の分野の部署に所属だったので、手法の名前とかビシバシ出して自分の研究の説明とかをしたら(割とベーシックな手法だと思われる)、もう一度説明し直すという罠にかかったのでつらみってなったという笑(その人は部署はそこだけど、自分は専門外で、最近設立され加入したそう)。

○「この人じゃない人でお願いします」と言える

僕はこんなこと言えたやつではないですが、例えば技術力がすごい人がいて、その人が自分の技術力をアピールしようとした時に「1時間」みたいな限られた時間でアピールをしようとすると、それを受け止められるのは「同等かそれ以上」くらいのレベル間の技術を持った人しかできないはずなんですよね。

そうなった時に、同じレベル感以上の人で、かつ同じドメインの知識を持っている人に会った方がいいと思いますというのを要求できるようにするのは、ありなのかもしれないというやつです。

これは本当にそうで、例えば画像処理専門の人だといくら画像のことをアピールしたとしてもそれが例えば自然言語処理ラブみたいな人にアピールしたとしても「違うよね」ってなります。

なので、採用担当者側はできる限り求職者に合う人をということで、面接官を選ぶと思いますが、それだけじゃなくて求職者も面接官を選ぶことができれば、なおいいのではないかなと思いました。

○個人の情報の保護と会社の機密情報保護はどうするのか

ただ、この話は問題があると思っていて、個人の情報の保護と会社の機密情報保護が一番のネックになりそうだなぁと。

企業側はどういう管理をしているのかわからないですが、人事情報などは重要度の高い情報だと思いますので、厳重に社内でも管理されていると思います。その反面、僕らみたいな一般の人に公開したデータというのが、漏洩されるリスクを考えれば、これはなかなか実施は難しそうです。

また、質問がより具体的になることや、情報として提示するレベルが大きくなることで、会社の機密情報を外に漏れやすくなることも心配の種かと。ここはある程度コントロールできる範囲だと思うので、大丈夫だとは思いますが。

この当たりさえ克服できればできるんじゃないかなぁと思います。某会社とかは、採用時にほぼ全ての情報をオープンにしてくれていたので、その点は採用においてはミスマッチを防ぐことができそうで、すごくいいなぁと思いました。

○とは言え、「求職者と面接官の相互面接試験」とかやりたい

これやりたい。笑

手順は以下の通り。

■1. 面接官の人を3人くらい、個人が特定されない範囲で情報を公開。求職者側から面接官を選ぶ手順を踏む

匿名化の処理を施したレジュメを用意する感じですね。これで匿名化された感じになるので、先にあげたデメリットを考慮しつつ、求職者側のメリットもゲットできます。

■2. 求職者はそれを読んでから面接に挑んでもらい、面接官を面接してもらうために時間を半分与えることを告げておく

求職者と面接官が両者それぞれ1:1の割合で面接をそれぞれしてもらうようにします。そのために、面接官に面接というと変ですが、質問できるように考えてもらうようにするという感じのノリでいいと思います。

これで、面接側としては質問してくるレベル感や議論のレベル感から求職者のレベルもわかりますし、よりフェアな面接ができるようになって楽しいのではないかと。

■3. 面接後は、求職者と面接官の両方から採用・不採用の連絡を相互にする

採用と不採用の連絡を相互にするようにする感じです。組み合わせは4パターンありますが、相互マッチの時のみ次に進むというような方向でいいかと思います。

なんか選考を受ける身として、その過程を通して思ったのが、「この企業は本当に自分に合っているか」を、受け身だとどうしても考えなくなっちゃって、面接通過の連絡が来ると「あっ、受かったんだ。次ですねー」みたいな感じにどうしてもなっちゃうんじゃないかなぁと。

そうなると当然ミスマッチも起こるわけで、これはこれで問題だなぁと。しっかり選択の権利があり、考えることをしてもらうのが一番いいのかもしれないなぁと(もし何も考えずに職が欲しいということで、企業側に採用の連絡を求職者がしてきた場合は、それは今まで通りなので特に問題はないのでこれをするデメリットも少ないかな、と)。

こんな感じで、面接官を求職者が面接するくらいの勢いがあった方が本当はいいはずで、そうして求職者側も「企業の採用判定」のようなものをして行く方が最終的にはミスマッチも起こりにくいんじゃないかなぁと思いました。

今日はこの辺で思ったことをまとめておく感じで。さて、研究するか。

推薦システムについて調べたのでまとめる

こんにちは。

今日は、推薦システムについて調べたのでそのことについてまとめます。

推薦システムとは

推薦システムとは、特定のユーザーに対して、アイテムへの嗜好を予測し、提示すべきアイテムを決定するシステムのことを指します。AmazonなどのECサイトで表示される「この商品を買った人はこれも買っています」みたいなのを思い浮かべるとわかりやすいと思います。

また、Konstanの定義によれば以下のようなものが紹介されていました。

Recommenders: Tools to help identify worthwhile stuff
(推薦システム:どれに価値があるかを特定するのを助ける道具)

大規模なサービスになってくると、ユーザーが自分のほしい情報や商品がどこにあるかを特定することは、検索やカテゴリから情報を選ぶという手段だけでは非常に難しくなります。

そのため、ユーザーの趣味嗜好に合わせた推薦を行うことで、自分好みのコンテンツに到達しやすくなります。これについては、Netflixのブログが参考になりました。


要素技術

推薦システムには、大きく分けて次の3つの要素技術があります。

  • 人間から 必要な情報を収集し,人間との対話を扱うヒューマン・コンピュータ・インターフェー ス技術
  • 収集したデータから推薦情報を生成し,それを目的に応じて変換 する機械学習,統計的予測,そして情報検索の技術
  • 推薦に必要な情報を 蓄積し,処理し,流通させる基盤技術であるデータベース,並列計算,そしてネット ワーク関連の技術

このブログでは基本的に、推薦情報の生成とそのアルゴリズムについて説明します。

非個人化推薦と個人化推薦

推薦には大きくかけて二つの分類があり、これらの組み合わせもある。以下が説明では参考になる。

非個人化推薦とは,たとえばビュー数の多い記事や,編集者のピックアップ記事など,全ユーザを対象(=非個人)として行った推薦(情報の優先度の付け方)を指します。

もう一方の個人化推薦とは,先ほどあったイメージの通り,個人を対象とした推薦のことです。
引用:第2回 推薦システムの概念:情報推薦システムの基本|gihyo.jp … 技術評論社

何故推薦システムが必要か

なぜ推薦システムが必要になったかという背景は、大量の情報が発信され、探したい情報がどこにあるか、またそもそも探したい情報が何かを特定できなくなった(情報過多)ことに集約されると書かれている(参考)。

今であれば、AmazonやNetflix、Youtubeなどのサービスで、ユーザーにとってメリットの大きい動画などを見ることができるようなるのは、純粋にメリットである。

If I have 3 million customers on the Web, I should have 3 million stores on the Web

    • Jeff Bezos, Amazon

主な手法

一覧

手法名 手法の概要
デモグラフィックフィルタリング
協調フィルタリング
ユーザーベースフィルタリング
内容(コンテンツ)ベースフィルタリング
ハイブリッドフィルタリング

協調フィルタリング

st-hakky.hatenablog.com

推薦システムの代表的な問題点とその改善策

■一覧
問題点 概要
コールドスタート問題 新しいアイテムやユーザが追加された時に類似のアイテムを見つけるのが難しい問題
少カバー率問題 ユーザの評価が少ないアイテムは類似するアイテム等のレコメンデーションの提示が不可能になること
同類推移問題 スパースなデータベースの場合、類似のユーザであっても、全く同じアイテムを共に評価しないと類似であると判別されない問題

Rで協調フィルタリングをやってみた

こんにちは。

実際のレコメンドシステムでは、こういったパッケージを利用するのではなく、独自アルゴリズムなどを開発して自社パッケージとして持っておくのが普通かなぁと思う。

んだけど、PoC(Proof of Concept)の段階、つまりレコメンドを実業務に導入する前の手間では、パッケージを使うのが手っ取り早いなぁと思うので、今回はパッケージを使っていく。

○Rのパッケージ:recommenderlab

このパッケージでは、「レーティングの予測」と「Top-Nリストの生成」の2種類のレコメンデーション機能を持っている。独自アルゴリズムを実装する際のコストも比較的小さく済むなど、拡張性に優れている。これらに興味がある場合や、Top-Nリストの生成についての興味がある場合は、以下の論文が参考になる。

Hahsler, Michael. "recommenderlab: A Framework for Developing and Testing Recommendation Algorithms." Southern Methodist University (2011).

○recommenderlabのインストールとパッケージの読み込み

普通にCRANから落としてこれるので、以下のコマンドを叩けば基本的には大丈夫。

# パッケージのインストール
install.packages("recommenderlab")

# パッケージの読み込み
library(recommenderlab)

○データの取得

■recommenderlabに用意されているサンプルデータ

今回使用するデータは、recommenderlabの中にあるデータセットである。recommenderlabには3つのデータセットが用意されている。

[工事中]

■recommenderlabの各種便利メソッドを使うためのデータ整形法

[工事中]

■データのロードと概要把握

今回は、MovieLenseというデータを用いて解析を行う

# dataのload
data(MovieLense)

# dataの確認
# 出力 : 943 x 1664 rating matrix of class ‘realRatingMatrix’ with 99392 ratings.
print(MovieLense)

# データのクラスの確認
# 出力:"realRatingMatrix"
class(MovieLense)

# "realRatingMatrix"のままではデータの中身が見れない。
# R汎用データ型の「data.frame」に変換してから出力。
head(as(MovieLense, "data.frame"))

f:id:St_Hakky:20170211183616p:plain

→こんなデータセットになっている。どうやらuser, item, ratingのカラムがあって、それぞれ値があることがわかる。user 1は、Toy Storyが好きな様子笑

ちなみに、ユーザーがすべての映画に評価をつけていることはないので、評価がついていない映画に対するratingはどうなっているかというと、

# 今度は「matrix」に変換して出力
as(MovieLense, "matrix")[100:110, 1:4]

f:id:St_Hakky:20170211184208p:plain

と、こんな感じでNAが入っているんだなぁってことがわかる。結構スパースだなぁ。ってか当たり前か。

次はデータの全体像を俯瞰するために、可視化させてみる。今回のデータのクラスである"realRatingMatrix"には、image関数がデータの特徴を俯瞰するために用意されている。

image(MovieLense, main="Raw Ratings")

f:id:St_Hakky:20170211184537j:plain


ユーザーを軸に、ユーザーごとのrating件数とratingの平均の傾向を確認する。今回のデータのクラスの"realRatingMatrix"には、rowCounts関数とrowMeans関数が用意されているので、これを使う。

# userごとのrating件数について
summary(rowCounts(MovieLense))

f:id:St_Hakky:20170211185007p:plain

# histgramを書いてみる
hist(rowCounts(MovieLense))

f:id:St_Hakky:20170211185708j:plain

→まぁ当然っちゃ当然みたいな結果だけど、それにしても結構みんなratingつけてるな笑

# userごとのrating平均について
summanry(rowMeans(MovieLense))

f:id:St_Hakky:20170211185112p:plain

# 同じくhistgram
hist(rowMeans(MovieLense))

f:id:St_Hakky:20170211185830j:plain

→結構4近いところで集中はあれど、って感じですな。

これらの結果から、全体的な傾向としては同じでも、人によって幾ばくかのレーティングバイアスがあることがわかるので、正規化を行う。center法をここでは使う。

summary(rowMeans(normalize(MovieLense, method="center")))

f:id:St_Hakky:20170211190432p:plain

# histgramも書いてみる
hist(rowMeans(normalize(MovieLense, method="center")))

f:id:St_Hakky:20170211190526j:plain

ふむ。だいたい正規化できたかなーと。

○レコメンデーションアルゴリズムの適用

■"realRatingMatrix"で使えるアルゴリズム

ここで、今回のデータ型である"realRatingMatrix"では、どんなアルゴリズムが適用可能なのかをみる。そのためには以下のコマンドを叩けば良い。

recommenderRegistry$get_entries(dataType = "realRatingMatrix")

ぶっちゃけここに出てくる内容を眺めるのは割と苦痛なのと、分かりにくいので、以下の表が参考になるかと。

Algorithm 概要
RANDOM アイテムをランダムに選んで、レコメンド
POPULAR 購入ユーザー数に基づいて人気度が高いアイテムをユーザーにレコメンド
UBCF ユーザーベース協調フィルタリング
IBCF イテムベース協調フィルタリング
PCA 次元削減手法の代表例である、主成分分析
SVD Singular Value Decompositionという、次元削減手法の代表的なものの一つ
アルゴリズムの実行の流れ

アルゴリズムを実行するには、大きく分けて以下の二つの処理が必要。

1. レコメンダーの作成
→訓練データを使ってレコメンダーを作成する
2. レコメンデーションの予測
→ユーザーへのTop-Nリストを作成したり、ユーザーへの未レーティングアイテムのレーティングを予測したりする。

■UBCFを適用してみる

とりあえず、MovieLenseのユーザー900人のデータを使ってレコメンダーモデルを構築する。

# methodはUBCF。パラメータは調整できるが、ひとまずデフォルトで攻める。
r <- Recommender(MovieLense[1:900], method="UBCF")

構築したレコメンダーを使って、901番目〜910番目のユーザーのレーティングを予測してみる。

# 構築したレコメンダーを使って、901番目〜910番目のユーザーのレーティングを予測
p <- predict(r, MovieLense[901:910], type="ratings")

# 結果の出力
print(as(p, "matrix")[1:10, 1:5])

以下が結果の図(一部)。
f:id:St_Hakky:20170211194614p:plain

結果は一部だけ表示されているが、以下の元のデータの中身と結果を比較すると、レーティング済みの映画は予測対象外となっていて、レーティングされていないところは、予測値が入っている。

f:id:St_Hakky:20170211194959p:plain

(→これは元のデータ)

アルゴリズムの評価

レーティングの予測結果としては、Netflix Prizeにも使われていたRMSEが有名。なので、今回もこれを使う。

今回は、8割を学習に使い、2割を評価用に使う。

# splitを使って、評価データを作成
# train=0.8で、8割のデータを使うとしている
# given=15で、残り2割の評価データのうち、15件を予測用評価データとして使うことを示し、その他のデータは予測誤差計算用評価データとして利用することを示す。
e <- evaluationScheme(MovieLense, method="split", train=0.8, given=15)

今回は、UBCFとRANDOMを比較してみる。

# 学習
r.ubcf <- Recommender(getData(e, "train"),method="UBCF")
r.random <- Recommender(getData(e, "train"),method="RANDOM")

# 予測用評価データとレコメンダーを使って、レーティング予測を実施
p.ubcf <- predict(r.ubcf, getData(e, "known"), type="ratings")
p.random <- predict(r.random, getData(e, "known"), type="ratings")

# 予測誤差計算用評価データを使って、予測用評価データより計算された、それぞれの誤差を計算
e <- rbind(calcPredictionAccuracy(p.ubcf, getData(e, "unknown")), calcPredictionAccuracy(p.random, getData(e, "unknown")))

# 結果を出力
rownames(e) <- c("UBCF", "RONDOM")
print(e)

f:id:St_Hakky:20170211200930p:plain

とまぁこんな感じで、UBCFの方が小さくなっていることがわかる。

今日は以上!!!!

Rでアソシエーション分析:アプリオリアルゴリズム編

こんにちは。

○arulesを使ってアソシエーション分析

■arules関係のパッケージ

以下のサイトにまとまっている。

lyle.smu.edu

■インストールと読み込み
# “arules”のインストール
install.packages("arules")

# ライブラリの読み込み
library(arules)
■データの読み込みと中身の確認

今回は、arulesパッケージ付属のサンプルデータセット「Groceries」を使う。

# データの読み込み
data(Groceries)

# 型を確認
class(Groceries)

# 中身を上5件出力
inspect(head(Groceries))

# 基本統計量の出力
summary(Groceries)

# 相対出現頻度によるヒストグラムを出力
itemFrequencyPlot(Groceries, support=0.06, cex.names=1.0)

以下の図は、相対出現頻度によるヒストグラムを出力をした結果である。

f:id:St_Hakky:20170207173730j:plain

■ちょっとここで脱線:arulesのデータ型ってどんな風になってんの?笑

[工事中]

アプリオリアルゴリズムの適用
# アプリオリアルゴリズムの実行
rules <- apriori(Groceries, parameter=list(support=0.005, confidence=0.01))
■結果の出力・可視化

arulesVizパッケージを結果の可視化には使います。

# パッケージのロード
library(arulesViz)

散布図の出力をする。

# 散布図

plot(rules)

f:id:St_Hakky:20170207191952j:plain

バブルチャートも出力して見る。

# アソシエーションルールのバブルチャート

plot(rules, method="grouped", control=list(k=10))

f:id:St_Hakky:20170207192319j:plain

グラフで表示して見る。

# アソシエーションルールをグラフで書く

plot(rules_high_lift, method="graph", control=list(type="items"), interactive=TRUE)

f:id:St_Hakky:20170207193222j:plain

以上!

MacへのRstanのインストール

以下の本を読んでいます。

この本では、OSがwindows対象なので、Macとの差分を書いて行こうかと。あと、余力があればPythonでstanを用いた場合のコードとかも書いていく。

インストール方法は、すぐに廃れてしまいますが、以下のような感じで行うというのをメモ。

○Prerequisites

・R version 3.0.2 or later
→Rの3.2.0以下のバージョンでは、一部動作しないらしいので、3.2.0以上を入れるのが良さそう。

・Toolchain
C++ compiler and GNU-compatible versionをインストールする必要があります。これは、Xcodeをインストールしていればおっけー。

○RStanのインストール

以下のコマンドを叩くだけです。

# note: omit the 's' in 'https' if you cannot handle https downloads
install.packages("rstan", repos = "https://cloud.r-project.org/", dependencies=TRUE)

もし失敗したら、こっちを試してください。

install.packages("rstan", type = "source")

○確認

インストールが終了したら、Rを再起動して、以下のコマンドからstanが実行できているかを確認しましょう。

fx <- inline::cxxfunction( signature(x = "integer", y = "numeric" ) , '
    return ScalarReal( INTEGER(x)[0] * REAL(y)[0] ) ;
' )
fx( 2L, 5 ) # should be 10

10が帰ってきたら、正常にインストールされていると思います。

インストールできました。早速使っていくか。

○参考サイト

github.com

Mac上にAtomでLatex環境を整えて論文を書く

こんにちは。私も世に言う博士前期課程でして、論文を書く身分ですので、環境を整えようと思った次第です。

最近は非エンジニア相手でなければ、なんでもAtomで済むことが多いので、latexもそうするかぁと思って、そうしようと思いました。

そして、タイトルにあるような内容を書こうと思ったら、以下のサイトを見つけました。

qiita.com

神か。

上に従って環境を整えたら、以下のコマンドを叩く。

・ただのコンパイル

latexmk sample.tex

コンパイルしてPDFで閲覧

latexmk -pv sample.tex

・監視(自動更新)

latexmk -pvc sample.tex

・中間生成ファイルを削除

latexmk -C sample.tex






そして一言。








名も知らぬ誰か様。とっても、とってもありがとう。









これに従って環境を整えました。



さて、論文でも書きます。


○補足情報

みんなhomebrew-caskって知ってるか? - Qiita
Macのセッティングが楽チンに!『Homebrew Cask』でソフトを簡単インストール | ライフハッカー[日本版]
macOS Sierra に Homebrew と Cask をクリーンインストールする - 時と場合によりけり
定期的に自動でコミットさせるスクリプト - Qiita
シェルスクリプト入門 書き方のまとめ | Memo on the Web

コンピューターで「脳」がつくれるか を読んだ

こんにちは。最近研究室にあった本で気になっていた本を読んでみたので、その感想でも書きます。

○読んだ本

「コンピューターで「脳」がつくれるか」という、以下の本を読みました。

○本の対象読者とざっくりとした内容

この本は、ある程度予想はしていたのですが、基本的に内容としては深く入りすぎず、全体像をさらうイメージの本でした。なので、想定の読者としては、

・数式なんてわからぬ。見たくも無い。
・でも、人工知能とか機械学習、Deeplearningって何だ?わけわからんけど、一通り知っておきたい。

的な人かと思います。マジで「人工知能ってニュースでよくみるけど、よくわからん」みたいな人にはオススメです。

一応、この本の立ち位置的には汎用AI(強いAI)は作れるのかという観点で話が進んでいますが、特化型AI(弱いAI)の方も引き合いで出てきますし、Deeplearningの話もされていて、かつ脳の話も出てくるので、普通に人工知能ってなに?みたいなことをさらうにはいい本だと思います。

対象読者として100パーセント引っかからないと思うのは、

・「人工知能などに何らかの形で従事している人」
・「機械学習やDeepLearningなんて普通に知っとるわタコ

みたいな人は、1680円+税をドブに捨てるようなものですので、絶対に読まなくていいでしょう笑。人生は限られていますので笑。

しかし、「あんまり統計や数学がわからない人が、人工知能系や機械学習に詳しく無い人がどう言った形で人工知能を学び、イメージするのか」をイメージできる本でもあるので、その意味で、全然知らない人に人工知能機械学習を説明するための参考になる本だと思います。

特に、誤差逆伝搬がなぜ層がDeepになるとうまくいかないか、とかは「あーこういう説明の仕方もあるのかぁ」となりました。

○読んだ感想とメモ

汎用人工知能の研究などは僕は普段追いかけていないので、その部分周りの話とか、いつも聞いてよくわからないなぁってなってた脳の話とかは結構整理できてよかった。

■メモ
・モラベックのパラドックス:「コンピュータにとっては(AI)、人間には難しいことほど簡単で、人間には簡単なものほど難しい」という逆転現象のこと
・汎用AIの研究:Hierarchical Temporal Memory/PredNed/BESOM

2時間もかからずに読めたので、まぁ休日にコーヒー片手に読むのには良かったですね。

それでは。

むしゃくしゃしたのでOffice 2016 for MacのPowerpointのショートカットキー一覧をまとめてみた

こんにちは。

最近、パワーポイントを使うのですが、むしゃくしゃします。理由は、数式をぶち込むからです。

数式をぶち込むとき、GUI(マウス)でいちいち「挿入タブ→数式」としないといけません。人生は限られています。もったいない。

そう考えていたときに、そういえば、「パワーポイントのショートカットキーってどういうものがあるんだろう?」って思ったので、調べてみました。普段使っているものは、一部いれて一部のぞいています。

○よく使いそうなショートカットキー

■テキストやオブジェクトを編集する
目的 コマンド
カーソルの右側の 1 文字削除する ファンクション + DELETE
文字を大きくする command + shift + >
文字を小さくする command + shift + <
直前の操作をやり直す command + Y
直前の操作を元に戻す command + Z
中央寄せ command + E
右寄せ command + R
左寄せ command + L
下付き文字 command + shift + =
上付き文字 control + shift + ^
■テキスト内を移動する
目的 コマンド
単語の先頭または左方向に 1 単語分 Option + ←
カーソルの右側の 1 単語 Option + →
行の末尾へ command + ←
行の先頭へ command + →
■オブジェクトを操作する
目的 コマンド
選択したオブジェクトをグループ化する command + Option + G
選択したオブジェクトをグループ解除する command + Option + Shift + G
選択したオブジェクトを時計回りに回転する Option + →
選択したオブジェクトを反時計回りに回転する Option + →
図形の回転微調整 option + control + ← or →
図形の複製 command + D
図形の複製2 option + ドラッグ
図形の平行移動 option + alt + ドラッグ&ドロップ
■プレゼンテーション
目的 コマンド
スライドを新たに挿入する command +Shift + N
縮小 command + -(マイナス記号)
拡大 command + Shift + ; (command + 正符号)
選択したテキスト、画像、またはオブジェクトにハイパーリンクを追加する command + k
■表示を変更する
目的 コマンド
標準表示に切り替える command + 1
スライド一覧表示に切り替える command + 2
ノート表示に切り替える command + 3
アウトライン表示に切り替える command + 4
スライド ショーに切り替える command + Shift + Return
全画面表示に切り替える (メニューを非表示にする) command + Control + F
配布資料マスター表示に切り替える command + Option + 2
スライド マスター表示に切り替える command + Option + 1
ノート マスター表示に切り替える command + Option + 3
■スライド ショー
目的 コマンド
指定した番号のスライドに移動する 表示するスライドの番号と Return
黒い画面を表示するか、黒い画面からスライド ショーに戻る B
白い画面を表示するか、白い画面からスライド ショーに戻る W
最初のスライドからスライドを再生する command + Shift + Return
現在のスライドからスライドを再生する command + Return
発表者ツールに切り替える option+ enter

私は気をつけようと思う人事担当者の思考と行動あるある

こんばんは。

今日は、最近就活で感じた、「私は気をつけようと思う人事担当者の思考と行動あるある」について書きます。僕もいま担当している事業で採用側に立つことがあるので、以下は気をつけたいなぁと思ったことを書きます。

○学生扱いをしない。例えば、メールやメッセージで「くん」は使わない。

「〇〇くん」はよくあるフレーズだと思います。これが言いたいというよりは、「学生さん」扱いをしないっていうことを言いたいです。

僕がいいたいことの大半はこちらに書いてありますので、そちらをどうぞ。

nabeharu.hatenablog.com

別に問題はないのかもしれませんし、気にしすぎなのかもしれませんが、この文言を使うと、少し上から目線になってしまいますし、どうしても「学生さん」扱いをしてしまいます。

普通に「社会人の一員」として「プロジェクトに関わってもらおう」というのであれば、このようなフレーズは絶対に使わないべきだと思っています。

もちろん、会社の中などで「〇〇くん」とかを使うのは仲のいいメンバーという感じでいいと思いますが、少なくとも採用の場面では必ず意識したいところです。

○たとえ工数が若干かかっても、テンプレに一言は添える

おそらく、メールはいつも同じものを送ると思います。ですが、前回の選考の内容や結果といったところで、その人だからあったことを一言添えることで、印象はだいぶ変わるもんだなぁとメールをもらう側になって思いました。

気持ちや感謝、来てほしいという思いを表現する上でもすごく大事だなぁと思いました。

○他社の不評は言わない

他社の不評は絶対に口にしない、ということです。もちろん聞かれれば別ですが、こちら側から何か積極的に悪い点について発信するということは、よほどの確証がなければするべきではないと思います。

あとで話す内容にも関係しますが、

「〇〇会社とうちでは、ここが違うくて、ここは〇〇会社のほうが良くて、ここはうちが良いと思う」

と正直に話す、伝えるのがいいと思いました。

正直な姿勢を持って、最後の判断は求職者に委ねるのがベストだと思いました。そちらのほうが印象が良いですし、しっかり求職者のことを考えてくれていると受け取ることができます。

絶対評価で話すべき部分と、相対評価で話すべき部分を分けて話すこと

たとえばですが、

・うちは技術力はすごい。優秀な人達が集まっている
・あなたは、社内の文化とすごくマッチしていると思う。

このような話をしていただいた時に、いつも思うんです。

Googleに勝てるくらいすごいのか?レベル感は業界全体の中でどこにあるのか?
・文化とマッチしているのを決めるのは、採用側と求職者の両方

こういった、「技術力」や「社内文化のマッチ度」、「資金力」などといった、相対評価として話すべき内容を絶対評価として話しているシーンが本当に多い。

確かに条件には合致しているかもしれませんが、「相対的に見てどうか、という観点でバイアスをかけすぎていないか?」、これは注意すべきポイントだと思いました。

逆に、相対評価ではなくて絶対評価で話すべき内容としては、

・うちめっちゃ楽しいよ〜!
・こんなことが今まであって、本当に色々考えるときもあったけど、充実してた

といった「感情」や「エピソード」は、絶対評価として話すべきだと思います。比較できないですからね。

ここらへんを混合して話されると、議論ができないなぁーと思ったり。笑

○遅刻しないように、と言っている以上、こちらも絶対に遅刻しない。

Skype面談などでよくあることかもしれませんが、3分〜5分の遅刻です。これは絶対にするべきではないと思いました。

誠実な人ほど、相手の時間を大事にします。

そして、もしそういった人たちと働きたいと思っている場合、採用担当者もしっかりこの時間の面では死守するべきだと思いました。

○準備はしっかりする。

採用側が、求職者に求めるレベル感くらいには、採用側もしっかり準備をする。

これってすごく大事なんだなって思いました。

基本だと思いますが、履歴書の確認、これまでの選考記録の確認、質問を考える、どういった話の流れにしようかを考える、どんな話をしてあげたらいいかを考える、これらのことです。

忙しいし、本当に時間もないし、採用できるかもわからない学生にここまで時間をさくのもどうかと思うときもあるのだろうけど、しっかり準備してあげたいところです。

「面接って緊張するし、普段しゃべらない大人だし、なんか面接官は怖いし、わーー」ってなっている学生に対して、出来る限り本当の姿を見せてもらえるように、準備するほうがいいんだなぁと思いました。

○学生は社会人から見たら暇かもしれないが、忙しいものだと思ってしっかり時間の調整は対等にする

僕達、学生は社会人から見たら暇かもしれない。それでも、日程調整などをするときは、必ず向こうの予定を気にするべきだと思います。

僕もやっていて思ったのが、そんなにひょいひょい長距離移動できるわけではないし、その中で簡単にそういったことを言われると気持ち穏やかではないのは必然だな、と思ったものです。

日程調整なども、しっかり対等に。

相手を尊重して行うべきだと思いました。

これは、普通にお客様にやるときには絶対にしないであろうことを、やっぱり「学生さん」だと油断してしまうところはあるんじゃないのかな、って思いました。

メールなどの連絡や、締切などの提出についても、学生の予定を事前に聞いて、対応をするのがいいと思いました。

○最後に:採用担当者は「会社の第一印象」ですね。

正直、私は採用担当者は最も会社の中で優秀な人をぶつけるべきと書いてあるリクルートの本とかを読んで、「ほんとうにそうなのか?」と思っていました。



しかし、実際に就活などを通して思ったのは、「これ本当やな」ということです。



理由は、「会社の第一印象」だからです。本当に。

少し粗相をしただけで、「こんな人が採用担当の会社って大丈夫なのか?」と思ってしまいます。

また、優秀な人は優秀な人を引きつけるというように、この意味でもそうするべきなんだなぁと思いました。



採用は、本当に微妙なバランスでなりたっているな、って思っていて、本当に難しい。でも、楽しい。

僕も社会人になって、学生と接するときはこういったところに必ず気をつけようと思いました。


それでは。

「劣モジュラ最適化と機械学習」を読んだ&輪講会をしたのでまとめておく

こんばんは。

最近、機械学習プロフェッショナルシリーズの「劣モジュラ最適化と機械学習」を読んで、輪講会を勉強会でしたので、スライドとか参考情報をまとめておきたいと思います。

そもそも興味を持ったきっかけ

劣モジュラ最適化と機械学習について興味を持ったきっかけは、以下の動画が始まりでした。普通に数式なども出て来ず、面白い内容になっているので、ぜひどうぞ。

www.youtube.com

この動画を見て、「なるほど、これは面白そう!」と思っていたところ、機械学習プロフェッショナルシリーズで「劣モジュラ最適化と機械学習」というタイトルの本があるということを知り、これはやるしかねぇなとなりました笑。

これがきっかけですね。

読んでいる本

ということで、読んでいる本は、以下の本です。


劣モジュラ最適化ってそもそも何?な方へ

はい、これは私でしたね。以下が参考になると思います。