石垣雅人のレビュー一覧
-
-
-
-
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（学びほぐし）させる
＝＞なぜ、チーム開発がすんなりうまくいかないのかをタックマンモデルから理解し、上手く自己組織化するチームにできないか考えることができる