Upgrade to Pro — share decks privately, control downloads, hide ads and more …

1時間で徹底解説!『DMM.comを支えるデータ駆動戦略』出版記念イベント! / Data- ...

1時間で徹底解説!『DMM.comを支えるデータ駆動戦略』出版記念イベント! / Data- Strategy

2020/11/11 『DMM.comを支えるデータ駆動戦略』出版記念イベント!【オンライン】
https://dmm.connpass.com/event/193716/

Masato Ishigaki / 石垣雅人

November 11, 2020
Tweet

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Transcript

  1. About me Masato Ishigaki / 石垣 雅人 DMM.com 総合トップ開発部 部長

    
 2015年度 エンジニア 新卒入社 2017年より、DMMにおける3000万のアカウント(ID)、認証(Auth) のバックエンド 周りのプロダクトオーナーを経て、 2018年7月にリードナーチャリング領域を強化す るチームの立ち上げを行う。 2020年より、DMMの総合トップなどを管轄する総合 トップ開発部の部長を務める。 現在は『DMM PointClub』アプリやモバイルSDKのプロダクトオーナーにも 従事 @i35_267 i35-267
  2. - まずは対象をすることが大事 - なんとなく利益が出ているのは駄目 - きちんと事業を計測し、数値モデルとして捉える。 - システム理論的な事業理解が必要 - あらゆる対象を「システム」として定義する

    - システムの3つの特徴 〜システムが形を成す過程〜 - 入出力からシステムは作られる - システムの階層性 - ミクロからマクロまでをズームイン / ズームアウト - 事業を「システム」として定義する - 何をインプットとするか - インプットに対してどのような処理が行われているか - 何をアウトプットしているか  事業→システム理論で理解する
  3. 事業の可観測性(Observability) を高める - 事業モデルを定量的な数値モデルで捉える - ソースコードで定義する - 科学的手法を意識する - 1.

    測定可能性 2. 定量性 3. 再現性 4. 統計的有意性 5. 論理的整合性 - 一連の動作をログデータでプロットする - あらゆる挙動をトラッキングし、ログデータとして出力する - ログデータとして出力することで「データ」として表現できる - 事業ソフトウェア = 記録できる - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 背景としては大規模データの並列処理基盤の進化
  4.  事業構造をKPIで表現し、 予測可能性をつくる - 事業構造の計算式が見えてくる - 事業の入出力に対するシステム処理パターン = 計算式が 見え てくる

    - ということは変数に対して代入すれば出力を予測できる - 科学的な事業構造把握 = KPIツリー - プロダクトにおける一連の動作を数値モデルとして表現しただけでは事 業の現状を可視化しただけで事業改善は生まれません。 - 継続的な 事業改善を行うためには指標を決め、それに向かって改善を 進めていく必要があある - 可観測性が高ければ高いほど、より細かくツリーを要素分解できる - KPIツリーは事業の健康診断
  5. 予測値と目標値による事業改善の流れ - 目標値 - あとは目標値を設定してその差分を埋めていく作業に入りま す - Ex. 売上KGIを1,000万円 →

    2,000万円 - 予測値と実測値のズレを検知する - 施策のROIやコスト面を意識して施策を実施 - 結果と予測値が合っているかどうかを中心にモニタリング - 施策実施のプロセスは後述します
  6. 仮 説 → 実 験 → 学 習 → 意思決定

    - 不確実性と どう戦っていくか - 不確実性が高いプロダクト開発の現場では、どんな施策が ユーザーに受け入れられるかはとても難しい問題 - 事業の寿命は無限にあるわけではなく、常に予算を中心とし たタ イムリミットを意識する必要がある - 実験しながら学習していく - "実験"をすることが大事 - 実験とは言葉のとおり「実際の経験」という 意味 - ユーザーという指針を頼りにしながら、実験を繰り返し、そこか ら得られる結果を「データ」というファクトをもとに学習しなが ら、意思決定をしていく - 仮説検証のプロセスが大事
  7. 型を学び、組織を方向付ける - これらの手法は決して"成功"を保証するものではない - ある種の「型」であり、このプロ セスや方法論さえ守っていれば事業が必ず成長す る、といった銀の弾丸ではありません。 - プロセスや方法論は、手段であり目的ではありません。 -

    「型」を何も考えずに組織へ導入すると思考停止になり導入自体が目的となりがち です。 - 例えば、開発手法 1つ取っても「アジャイル開発を導入したからうまくいくはずだ」「スクラムではこうなっているから組 織もこうなるべきだ」というように混同しがちです。
  8. 型を学び、組織を方向付ける - 実際にはあらゆる型を組織に適用して、組織文化とマージ(併合)すると必ず差分 が出てきます。 - その差分を組織としてどう馴染ませていくかが肝心なわけですが、 例外が出てくる と「この方法論ではダメだ」「私たちの組織には合わなかった」という結論に陥る ケースを多く見られます。 -

    一方、「型」というものは提唱者の思想を肉付けする形で、世の中にわかりやすく 適用できるようにパッケージ化されたものです。 - つまり、作られた背景や思想の部分を理解していれば、提唱者の肉付け部分 (パッケージの部分) を独自にアップデートしていく形で、組織に順応されて、新た な組織文化を更新していけるのではな いかと考えています。
  9. 失敗できる環境をつくり出すことで 組織は加速する - 失敗の恐怖。PDCAのPを重視しない - 事業をスケールさせるには、改善施策を合理的に正しい方 向 でどれだけ数多く実行できるかが鍵になる。 - ハードルとなっているのが、失敗への恐怖心です。誰もが思う

    「失敗したくない」 という壁が、あらゆる改善の実施に歯止めを かけている。それが組織として存在する - = 前段階にある計画の部分に時間をかける - 失敗をコントロールする - 失敗を”なくす”のではなく、事業構造を理解した上で失敗でき る範囲(予算など)を明確にし、その影響範囲の中で適切に失 敗をさせるこ
  10. A/Bテストによる実験 - A/Bテスト - A/Bテストとは、元の機能に変更を加える際に Aパター ンとBパ ターンを用意してテストする手法 - A/Bテストの比重と期間の考え方

    - A/Bテストの比重については、統計学的な分析でサンプル数を 満たす割合を見極める必要 - 必ずAAテストを実施して、統計的誤差を正しく把握する
  11. アジャイルはつらいもの - アジャイルはつらい - アジャイル型の開発は、小さくプロダクトをつくりながら、ある種 の石橋を叩いて渡りながら、失敗をコントロールしていくプロセ スです - プロセスとして理想的には良いと頭でわかっていても、実現す るには難しい部分も沢山あります

    - - ケーキの例でも各工程に分かれて大量生産したほうがゴール も明確 - コツを掴んでいくことで個人の生産性も徐々に上がっていくで しょう。 - アジャイルは、それを大量生産ではなく小さく形にして、ユー ザーのフィードバックも見ながらショー トケーキの単位で変更 させていくものです。トッピングがいちごではないかもしれませ ん
  12. アジャイルにおけるインクリメントの誤解と解消方法 - 「どの単位でユーザーの機能を提供するか」 - 実際の開発現場では「どの単位でユーザーの機能を提供する か」は頭を悩ませる部分です - イテレーションの中で incrementにならないようにする。 -

    あまり、機能を削り過ぎても、もともと提供しようとしているプロ ダクトの価値が見えなくなり、逆 に機能を盛り込みすぎると開 発に時間がかかりすぎ、市場への仮説検証が遅る - ユーザーストーリーピッングを作ろう!
  13. ユーザーストーリーマッピングとは 商品を検索する 商品を購入する 商品を検索する 商品ページを見る アカウント 登録・認証する 支払い方法を 選択する 商品を購入する

    ジャンルで検索 商品名で検索 価格が見える 商品レビューが見える メールアドレスで 登録する SNSアカウントで 登録する ゲストで登録する カートに入れる クレジットカードを 登録する クーポンを使う 電子マネーを使う 購入完了メールを送る ポイントを配る カートに入れる ジャンルで検索 商品名で検索 価格が見える 商品レビューが見える メールアドレスで 登録する SNSアカウントで 登録する カートに入れる クレジットカードを 登録する 購入完了メールを送る
  14. 仮説検証プロセスで実験を加速させる - 「仮説検証プロセス」 1. KPI選定 2. 仮説 3. 検証 4.

    計測 - プロセスをつくるということは型をつくることに等しい - 組織の中で属人的にはならない改善の流れ をつくることで成果物を安 定させることができます。 - そして、そのプロセスの中で数多くの実験を繰 り返すことで、組織として ノウハウが蓄積され、プロセスの精度も上がり、事業のブラックボックス も徐々に明らかになっていきます - BMLループという「型」
  15. BMLループでプロセスの型を作る - BMLループのプロセス 1. Learn → Idea = 仮説を考える 2.

    Build → Product = どう作るか 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - Single Piece Flow(1つのサイクルで1つの仮説) - 仮説の1つ流しを意識する - 2つの改善を同時に満たすような施策だとバッチサイ ズ(1つの処理で 回す量)として大きすぎる - 結果として、どの施策が効果があったのかの依存関係が見えづらくな る。
  16. BMLループは、逆回転のプロセスで考える - 計画ループ - 1. 学習からの仮説がつくられる( Idea) - 2. 仮説から何を学びたいか、確証を得たいか(

    →Learn) - 3. そのために必要なデータの形は何か( →Data) - 4. どんな指標をどのように計測するか( →Measure) - 5. プロダクトの形は何か( →Product) - 6. どのようにつくるか( →Build) - 実行ループ - 1. 構築する(Build→) - 2. MVPができる(Product→) - 3. 指標に基づいたログデータが出力される( Measure→) - 4. データが可視化される( Data→) - 5. データから学習する( Learn→) - 6. 次の仮説を考える( Idea→)
  17. 学習する組織とは何か - 学習する組織の必要性 - 事業や仮説検証プロセスだけでなく、組織も短いサイクルの 中で学習していかなければいけない - 組織の中にいるメンバーのメンタルモデルを考える - 学習する組織とは

    - 目的に向けて効率的に行動するために - 集団としての意識と能力を - 継続的に高め、伸ばし続ける組織 - 能力の高い人たちが集まれば「学習する組織」になるかとい えばそうではなく、その個人が集まった「集団」としての学習 能力を高めていかなければいけない
  18. 組織を戦略的にUnlearnさせる - Unlearnとは - Unlearnとは、学習する上で必要な知識をどう積み上げてい くべきかという概念 - 組織や個人に よって、外からのさまざまな情報や知識をイン プットしながら、それをどう適応していくか、アップ

    デートして いくかの考え方です - 人はどうしても今までの経験値や学んで きた経験の視野の 中に囚われていることが多くあります - Unlearnという言葉は、直訳すると学ぶ( Learn)の否定(un) なので「学ばない」「脱学習」といった 印象を持ちますが、少し ニュアンスが異なる
  19. 組織を戦略的にUnlearnさせる - 「知」について - 既存の知識に対して、新しい知識の「型」が相互作用する中 で、知識と知識が結びつき言語化されたり、自 分が普段思っ ている課題や不安に対しての理解が深まったりします - これは、新しい知識を入れたと

    きに発生する不安定な「ゆら ぎ」のプロセスによって生まれます。知識と知識が不安定に ゆらぎながら、 結びついていきます。 - プロダクト開発の現場でも「いまよりも良いやり方はないか」を 常に探 していく探求心をもちながら、戦略的 Unlearnすること が大事
  20. 戦略的Unlearnの着想は、XP(エクス トリーム・プログラミング) - XPのパラダイム「注意して、適応して、変更する」 - 運転というのは車を正しい方向に走らせるのではなく、常に注意を 払いながら、こちら に行ったら少し戻して、あちらに走らせてしまったらまたこちらに戻して、と「小さい軌道 修正」をしていくものです -

    ソフトウェア開発の周りにあるものは常に変化を続けています。事業環境も組織にい る人も、つくる べきものの要件の変化やソフトウェア技術の変化などが存在する中 で、私たちが考えるべきことは、 周辺の変化ではなく、その変化にどのように対応して いくかでしょう - ソフトウェア開発における変化への対応で大事なことは、新しいプラクティスを身軽に 試せる環境です。また、常に新しい変化を柔軟に取り入れ、自分たちを変化させる中 でフィードバックをもらい、 積極的に改善を受け入れることが重要。
  21. 戦略的Unlearnの着想は、XP(エクス トリーム・プログラミング) - 継続的な改善とは何か - 継続的な改善と聞くと、絶え間なく連続的に改善を続けていると思われがちですが、 そうではありま せん。継続的に注意して、適応して、そこからフィードバックをもらい、 積極的に改善を受け入れる 準備体制ができていることが継続的な改善

    - XPの理論構成には、「価値」「原則」「プラクティス」の3つがあります。特にプラクティス の部分についてはあらゆる問題の改善アプローチが用意されています。 - その理由は、開発チームが継続的改善のプロセスをやめさせないことだと考えられま す。何もない状態で、自ら改善策やアプローチ方法を見つけ出すことは難しく時間が かかります。そんなときは、 XPで用意されているプラクティスをその価値を理解した上 で、自分たちの問題点と照らし合わせて みて適応し、変更してみましょう。そこから出 てきたフィードバックをもとに学習していけば良いのです
  22. 戦略的Unlearnの着想は、XP(エクス トリーム・プログラミング) 価値 - コミュニケーション( Communication) - シンプリティ(Simplity) - フィードバック(Feedback)

    - 勇気(Courage) - リスペクト(Respect) 原則 - 人間性(Humanity) : 機会(Opportunity) - 経済性(Economics) : 冗長性(Redundancy) - 相互利益(Mutual Benefit) : 失敗(Failure) - 自己相似性(Self-Similarity) : 品質(Quality) - 改善(Improvement) : ベイビーステップ(Baby Steps) - 多様性(Diversity) : 責任の引き受け(Accepted Responsibility) - 振り返り(Reflection) : 流れ(Flow) プラクティス - 共同のプラクティス - 開発のプラクティス - 管理のプラクティス - 顧客のプラクティス チームが継続的改善が行えるように観点が提供されている。 一方、これらは銀の弾丸ではない。
  23. 暗黙知から差分を出する - 暗黙知と形式知 - 私たちが「知る」という行為には大きく分けて、暗黙知と形式知があります。 - 「暗黙知」とは、一言でいうと言語化されていない感覚的で身体的な知識のことで す。経験知ともいい、 経験として体に馴染んでいるが言葉として説明できない知識 のことです。この暗黙知には、大きく分

    けて2つあります。メンタルモデルを代表とす る「認知スキル」と、ノウハウや技巧、熟練といった「身体スキル」 - 一方、「形式知」とは、言語化、理論化されている知識のことです。感覚的な知識を 形式化して全員に わかるような形で知識を共有することができるようになります。
  24. 暗黙知から差分を出する - SECIモデル(セキモデル) - SECIモデルとは、暗黙知と形式知の 2つの知識形態が、相互 作用して変換を繰り返すことで「知識変換」 が行われ、新しい 知識が創造され拡大するという集合知モデル •

    共同化(Socialization)(暗黙知→形式知) • 表出化(Externalization)(暗黙知→形式知) • 凍結化(Combination)(形式知→形式知) • 内面化(Internalization)(形式知→暗黙知)
  25. パターン化して広げる - パターンを「作る」 - パターン化とは、差分から生まれたその組織の独自プロセスを 形式知として新たにつくり出すことです。 - どんな「状況」のときに - どんな「問題」が発生しやすい

    - そんなときには、この「解決」を適用すれば改善するかも しれない - この「状況(Context)」「問題(Problem)」「解説(Solution)」の3 つ記載した上で、「名前(パターン)」 をつけていくことで、 1つのパ ターンができあがります。
  26. パターン化して広げる - パターンを「広げる」 - パターンをつくったのならば、その型をつくったチームでブラッ シュアップしていくのはもちろん、 ほかのチーム、組織にも広げて いきましょう。 - 各々がパターンをつくっていき、それを型としてあらゆるチームや

    組織に落とし込み、「ゆらぎ」をつく りながら暗黙知へ落とし込ん でいきます。 - そして、それぞれの「状況」「問題」にあったパターンとし てアップ デートしていき、それを違うチームがまた参照していくというサイ クルを回していくことで、 強い組織にしていきます。
  27. 組織のサイロ化と向き合う - サイロ化 - ドメイン単位で縦割りの組織がある中で、問題になるのは「サイ ロ化」です - 良くも悪くもプロダクトチームで完結するため、横との連携が少な くなる組織設計となってしまうこ とです

    - 組織文化も閉じられた状態になり、良い情報や有益な情報が横 に伝わりにくい状態になります。 - サイロ化という文脈では、以下の 2つを防ぐように対策します。 - 事業改善ノウハウのサイロ化を防ぐ - 技術領域のサイロ化を防ぐ
  28. 事業改善ノウハウのサイロ化を防ぐ - レポーティング - DMM.comでは、週次レポート / 月次レポートという形で各事業 単位やチーム単位でレポートを書くことで、誰でも他事業の施策 状況などを参照できるようにしています -

    本来、サイロ化という文脈よりも、正しく組織階層に沿ったレポー ティングとして機能し、事業の健康状態を理解することに活かさ れていることが多いのですが、 Wikiとして公開され ているため、 誰でも改善の知見ノウハウやその組織文化に触れられます - - ここに書かれている施策や改善について詳しく担当者にヒヤリン グすることはよくある光景で
  29. データパイプラインの構築 - データパイプライン - データレイク(Data Lake)・・データの湖 - データウェアハウス( Data Warehouse)・・データの管理倉庫

    - データマート(Data Mart)・・価値があるデータ - データガバナンス - GDPR(一般データ保護規則)の策定 - 権限や役割、個人情報の扱いで - 個人が特定できる情報は入れない
  30. データの民主化 - ダッシュボードをつくろう! - KPIダッシュボード - 事業モデルの指標から導き出された KPIツリーをもとに つくっていきます。 -

    施策ベースのダッシュボード - 日々事業を伸ばすために実施している施策ごとのダッ シュボード。A/Bテストの結果など - 経営向けダッシュボード - 各事業単位のダッシュボー ドではなく、事業全体を俯瞰 して見れるようなマクロの財務諸表ダッシュボード
  31. 毎日ダッシュボードを見る仕組みをつくる - 仕組み作り - KPIマネジメントと同じで、 BIツールのダッシュボードも一度つくっ て終わりではなく運用が必要です。 事業環境は刻一刻と変化し ていくため、できれば、毎日チーム全員で見る習慣をつけること が大事です

    - • 前日のDAUはどうだったか - • 前日の売上はどうだったか - • UI改善施策のA/Bテストの結果はどうか - • 追加した機能は使われているか - 毎朝、前日分のデータをチャットツールへ通知 - デイリースクラムで毎日確認