読者です 読者をやめる 読者になる 読者になる

St_Hakky’s blog

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

Effective python シリーズ1:Know Which Version of Python You’re Using

Python Effective python データサイエンス

こんにちは。

○読んでいる本

以下の本を勉強がてら読んでいます。

www.effectivepython.com

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

まとめページは以下より。

st-hakky.hatenablog.com


さて、今回は1つ目:「Know Which Version of Python You’re Using」をやります。

○Know Which Version of Python You’re Using

Pythonのバージョンを知ろうっていうやつですね。普通にコマンドラインからせめてやる方法としては、

python --version

または、

python -V

のどちらかを叩けば、

Python 3.5.2 :: Anaconda 2.5.0 (x86_64)

みたいな感じで結果が出力されるはず。

でも、pythonのプログラム実行中に確認したいっていう時もあるかもしれない(まぁ僕は一回もない笑)。そんな時は、

import sys
print(sys.version_info)
print(sys.version)

ってすると、

sys.version_info(major=3, minor=5, micro=2, releaselevel='final', serial=0)
3.5.2 |Anaconda 2.5.0 (x86_64)| (default, Jul  2 2016, 17:52:12) \n[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)]

って出てくる。

他にも、

import platform
print(platform.python_version())


ってすると、

3.5.2

って出てくる。

他にもタプルで情報を取る方法もあるみたいですが、まぁ使う時になったらでいいでしょう。

それでは今日はこの辺で。

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

Effective python python データサイエンス

こんばんは。

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

www.effectivepython.com

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

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

○環境

OS:Mac
Python:3.5.2

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

データサイエンス

こんにちは。

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

○調べた動機

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

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

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

○調べてみた結果

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

最高ですね。

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

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

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

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

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

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

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

わーい!

ってなわけで、もう悩まなくてもいいのかしら笑。

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

グロースハック 読んだ本 データサイエンス

こんばんは。

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

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

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

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

○読んだ本

読んだ本は以下の2冊です。

どちらも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文字のタイピングが本当に無駄だし、割と謝罪文を考えるのって時間がかかるじゃないですか笑(経験談)



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

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

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

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

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

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

それでは。