あらすじ
※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字だけを拡大することや、文字列のハイライト、検索、辞書の参照、引用などの機能が使用できません。
Part1では、データ駆動戦略の全体像を説明していきます。事業を科学的に捉え、数値モデルやKPIモデルへと落とし込む過程で生まれる「データ」というファクターをもとに事業を捉えていきます。
Part2では、データ駆動戦略を進めるために重要な体制づくりについて説明していきます。「データ」を武器として、事業をグロースさせるための仮説検証プロセスをアジャイル開発で実現していく流れやデータから学習できる組織の作り方などが体験できます。
Part3では、DMM.comが実践するデータ駆動戦略を体系的に紹介していきます。データ民主化という観点やデータを集約するデータ基盤の作り方を説明していきます。最後には、DMM.comの多くのサービスを支える基盤となっている「商品レビュー」をベースに、実際の［データ駆動戦略］を体験することができます。
エンタープライズのみならず、ECサイトの運営に悩む方にも読んでいただきたい書籍です。
感情タグBEST3
Posted by ブクログ
DMM社のデータ活用のノウハウが詰まった一冊。データ活用基盤の構築だけでは、データ活用の推進は難しく、会社全体の文化まで落とし込まないとうまく回らないことが改めてよくわかった。
ここら辺は、情報システムとマーケ系人材がチームを組んでプロジェクト的に進めないと難しい領域だと思う。
Posted by ブクログ
業務でデータ分析に関わる人にとっての必読書。
データ分析のKPI設定から、KPI改善のための分析の仮説・切り口設定、プロジェクトへの落とし込み、運用、組織構築まで、データ分析の実務において避けられない重要なテーマが広くカバーされている。
ケーススタディがDMMさんのため、ECサイトの例となっているが、内容そのものはどの業界でも適用できる内容となっている。
データ分析者はもちろん、分析の経験がないがプロジェクトを推進する立場にある人にも読んでいただきたい一冊。
Posted by ブクログ
数字に関してはPL強めの観点で記載されていて、BSの観点がちょっと弱い感じがします。
2-4-2で、ECサイトのKPIモデルが紹介されてたんですけど、これだと商品がECに並ぶ前のオペレーションと、商品受注後のオペレーションが考慮されてない時点で片手落ちな感じがします。
あくまでもこれはPLでも流通総額がてっぺんにあってシステム利用手数料で儲けてるSaaSのECのKPIや、在庫リスクを限りなく0に近づけてCtoCに近い取引してる委託販売ECのKPIじゃないかと感じました。
実際のECはBSでリスキーなことが多いです。だから、このKPIは在庫リスク抱えてECを運営する側のKPIじゃないのでは。
KPIのてっぺんは1日の売上じゃなくて、営業利益にしないと、商品並ぶ前のオペレーションコストとか商品受注後のオペレーションコスト、あと、受注が入っていない時にかかる費用もろもろ、つまりBSまで改善のスコープに入らない状態になったりしませんかね。
BSまでスコープに入れないと、PVやsessionのような量じゃなくて、CVRや在庫回転率、粗利率みたいな率の改善に強いエンジニアの強みを生かせないような気がします。
量は正直、人海戦術だったり設備投資でなんとかするしかないんです。で、PVやsessionとかの量のアップって、広告在庫そのもの増やす話なんです。でも、せっかくエンジニアが本を書いているので、ライターやセールスが何とかするしかない量の改善より、率の改善に焦点を当てた方がエンジニアリングの強みが生かせて良いのではないでしょうか？
あと、3章でナラティブストーリーを作っていますが、商品を検索するナラティブストーリーから入るECは今やほんの一部でしかなく、今のECですと、検索されなくてもページ回遊を促す仕組みにして購入されるようにしたり、意図しない衝動買いを増やす方針にしないと、粗利率や併売率を改善出来ません。そして、ナラティブストーリーの後ろには、返品しないとか退会しないなどのアクションもあるでしょう。
札束で他社を殴る施策を打てる会社は良いですが、それ以外の会社が真似すると非常に危険なナラティブストーリーだと思います。ユーザーの今の動きを定性的に観察するようなフローが先に入っていないので、観察抜きにEC使うユーザーってこうだろう、問い合わせ使うユーザーってこうだろう、という都合のいいユーザー像を作ると、これからの市場を作っていけず、単純に既存市場の競合をいち早く札束で殴るためのKPI設計と改善の解説書になってしまいます。先行企業が先に作った市場に後からお金で参入したい企業であればこのやり方で良いかと思いますが、それ以外の企業で真似すると体力持ちません。
最後の章の商品レビューをデータ駆動させる件も、どういうレビューなら書きやすいのかデータで分析しているわけじゃなくて、まずポイントというお金でレビューを駆動させるてるのがありきですよね。SNSへ一言二言お礼を呟かせるだけでいいのか、珍しい商品や店に対する他のユーザーへのガイドのつもりで書くのがいいのか、どういうフォーマットのレビューだとレビュー投稿への動機付けがされやすいのか、商品購入へのフックになりやすいのかを分析することなしに、先にまずお金で解決することはユーザーのサービス利用動機を深堀しなさすぎてないと思います。
数字の見方自体は特に退会対策に言及するロジックが書かれてある『エンジニアリング組織論への招待』や多様な事業のKPIを解説した『仕事の説明書〜あなたは今どんなゲームをしているのか』の方が良いと思います。
それ以外の改善活動の記載はいい感じがします。 ただし、どんな改善も最初のユーザーや市場を特定や方向性を間違えると、間違ったものを爆速で作ってずっと突き進むことになりかねませんが。
Posted by ブクログ
データ分析するエンジニアが読んでも、
視座を高くでき、為になると思いました。
特に以下3点。
・ゴール（KGI）から具体的数値（KPI）に落として、何のデータを見える化すれば良いかをまず把握する
＝＞エンジニアは、技術面や、どう実現するかに注目しがちなので、データ分析する際に事業観点を持つ大事さを理解できる
・科学的手法（サイバネティクス）に則って、可観測性(Observability)を高める
＝＞事業をモデル化して、「操作可能変数」、「キードライバー」を把握することの大切さを理解できる
・組織を戦略的にUnlearn（学びほぐし）させる
＝＞なぜ、チーム開発がすんなりうまくいかないのかをタックマンモデルから理解し、上手く自己組織化するチームにできないか考えることができる
