St_Hakky’s blog

心理学/人事/就活/留学/データサイエンス/バイオインフォマティクス/日頃思ったことについて書きます。

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になるだろうなぁと。

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

それでは。