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はもう少し勉強を進めていきたいなと思いました。

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