伊藤徹郎のレビュー一覧
-
Posted by ブクログ
ビフォー
仕事でデータサイエンティストをしているので、自分の仕事や現在地を確認する上で、よく読まれているこの本を手に取った。
気づき
約1年半前プロジェクトに参画する前に知っておきたいことが書かれていた。特にこれ以上精度を上げていくことが厳しいということが伝わらず、期待値調整をミスっていたり、データ分析に携わっていないメンバー、クライアント向けに翻訳できていなかったりしていた。またうまくいかないと時にどうすべきかを決めきれておらず、苦労した。事前に読んでおくことができたら、ここらへんで悩むことがなかったかもしれない。
TODO
今後のプロジェクトでは上記の失敗をしないように、期待値調整や説明が伝わるような翻訳を意識していきたい。 -
Posted by ブクログ
データ分析を通じた課題解決のプロセスを、順を追って幅広い観点からまとめている。
分析手法などの技術的な話ではなく、プロジェクトをうまくマネジメントするには、という視点で語られている。
データ分析を通じた意思決定支援をやっている身として、どれも頷くものばかりだった。
とくに、経営層や発注者とのコミュニケーションについては、私自身苦労が多い部分でもあるため、非常に勉強になった。
技術的な話をメインに据える書籍はこれまで数多くあったが、本書籍のような、プロセス全体が俯瞰的に、かつ、簡潔にまとまっている本は無かったと思う。
初学者にとっては教科書的な意味合いで、経験者にとっては知識経験の整理という意味合いで、重宝したいものである。 -
Posted by ブクログ
第1章がビジネス活用編と第されたこ書籍を象徴していると思います。
--------------------
①データ分析によるビジネス成果を金額換算して示せ
└金額換算して初めて分析価値が評価される
②スゴイ分析よりも「成果が出る分析」を優先せよ
└学問的ではなく、実践的な読み方をすること
③分析結果を現場に丸投げするな
└ビジネス成果まで「分析者が」責任を持ちやりきる
④「現場」を知る努力をせよ
└現場感覚を捉えて初めて信用される
└信用されて初めて分析の話を聞いてもらえる
⑤業務プロセスレベルまで現場を把握せよ
└誰が、どのタイミングで、どの分析結果を基に、どう動くべきなのか。この4つが明確になっていること。
└分析を基に現場業務がどう変わるかまで見据える
⑥小さく初めて大きく波及させよ
⑦問題解決に積極的に関与せよ
└課題先行で逆算思考で挑む。結果、分析が課題解決に寄与しないならそれはそれで良いのスタンス
--------------------
技術的な分析スキルが高い=ビジネス成果を出せるわけではない。分業したほうが良いかもしれないレベルで分析結果と活用は大きな隔たりがあると思います。上記、忘れがちなので、何度も初心に返って、立ち戻ってこようと思わされました。
▼他の章も多くの気付きがありました。
第2章
・ヒアリング→ニーズの洗い出し→分析テーマ洗い出し→カテゴリ化→優先順位付けとキレイに整理して皆が理解・納得して進められたら理想なんだろうけど、実際には現場がイニシアチブを握ることはない「お任せ」だからうまくいかない事が多い気がする。実際には活用×インパクト確度が高そうなテーマを一つやってみて事例化して横展開がスピーディなんだろうなと思う。
第7章
・統計モデルと機械学習モデルの使い分け。どういうケースでどちらをもちいるか判断できるように。機械学習モデルでは予測区間の推定ができない。統計モデルは解釈ができる。係数を用いて何が目的変数に影響を与えるか、ビジネス的な示唆を得ることができる。但し、これは現時点での整理。将来的には予測精度が高く、解釈性も高い手法も出てくるかもしれない。DataRobotもその一つ。
第10章
・people analyticsの領域ではハイパフォーマーのコンピテンシーの定量的裏付けは有用なテーマ。人事領域に詳しくないと土地勘ある分析が難しい領域でもある=外部の専門家に頼むのも手。なのでシステムベンダー選定から入らないこと。
・マッキンゼーでは「obligation to Dissent」という概念がある。批評や否定的な意見の述べることは義務であるという考え方。データ分析では偉い人が決めたことが進むことが多い。そうではない議論がPMには求められる。 -
Posted by ブクログ
ネタバレデータ分析基盤を成長させていくにはどうすべきか、実践的なノウハウをまとめた書籍。
データ整備・エンジニアリング・組織作りといった観点に分かれていて、必要なところを都度読むのが良さそう。
データ分析基盤の基本を学んだ方向けと思われる。
【ポイント】
・データ分析基盤はユーザーが維持・成長させていくもの。開発し終えてからがスタート
・データの品質はデータソースで担保する。問題があれば、下流からのフィードバックが大事
・現状の業務を業務レイヤ(ロール・オペレーション・アプリケーション・ストレージ)に分けて整理することで、やりたいこととボトルネック間のギャップを明らかにする
・データウェアハウス(DWH)は共通指標をまとめるので、ユースケースに沿ったデータマートが使われるようになってから設計する
・データマートが増えすぎる・BIツールに集計ロジックが分散するといった問題がありがち。整理・集約が大切
・ユースケースを最重要視する。思考の9割はここでいい。この便益以上にコストをかけてはならない
・ETLの選び方は、コネクタが充実している
・コネクタをソースコードレベルでデバッグできること
・列指向DBは性質上、UPDATEやDELETEより、DROP→CTAS(CREATE TABLE AS SELECT)の方がいい -
Posted by ブクログ
個人的にはメルカリのBIチームの話題がとてもおもしろく参考になった。
横断組織としてのBIチームがあり、プロダクトやプロジェクト単位でアサインする体制をとることでのメリデメおよびデメリットへの対策がかなり具体的に書かれていてすぐにでも真似したい内容がたくさん。
またメルカリでは取締役や執行役員クラスでも必要に応じてSQLを書きデータに主体的に触れる文化があり、それも全社的に職種関わらずあるということで、レガシー企業のマイクロソフトOffice並に当たり前にデータ分析に取り組んでいるというのも読んでいて感服した次第。
そりゃグロースするわメルカリ。と思わずにいられない。
データ分析にあまり親和性がない人でも読みやすく、またぜひ読んでほしい本だと思った。