サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2>はじめに</h2>

<p>こんにちは。EC＆デジタルコンテンツ本部にてEngineering Managerを務めている、植田隼人です。</p>

<p>今回は、DMMの社内勉強会のひとつである「開発マネジメント勉強会」の番外編として「仮説検証」をテーマとした勉強会が開催されましたので、そのレポートをお届けします。<br />
当日は、仮説検証とアジャイル開発の分野において著名な市谷聡啓さんをゲストにお招きし、「仮説検証」をテーマにした講演と、DMMのマネージャー及びプロダクトオーナーによるパネルディカッションを行いました。</p>

<p>なお、過去の開発マネジメント勉強会のレポートは以下にアップされておりますので合わせてご覧ください。</p>

<p>過去記事リンク<br />
<a href="https://inside.dmm.com/entry/2019/11/27/management-meetup-3">https://inside.dmm.com/entry/2019/11/27/management-meetup-3</a><br />
<a href="https://inside.dmm.com/entry/2019/11/11/management-meetup-2">https://inside.dmm.com/entry/2019/11/11/management-meetup-2</a><br />
<a href="https://inside.dmm.com/entry/2019/07/30/management-meetup">https://inside.dmm.com/entry/2019/07/30/management-meetup</a></p>

<h2>概要</h2>

<h3>コンテンツ</h3>

<ol>
	<li>オープニング<br />
	司会の荒井さんによる「ゼロイチ開発における失敗ケースあるある」</li>
	<li>市谷さんによる講演「仮説検証とアジャイル開発」</li>
	<li>パネルディスカッション「何をつくるべきかの課題と、仮説検証の活用法について」</li>
</ol>

<h3>本イベントの対象者</h3>

<ul>
	<li>プロダクトチームをリードするマネージャ</li>
	<li>プロダクトオーナー</li>
	<li>プロダクトチームを構成するメンバー</li>
	<li>その他、新しい価値をつくろうとするすべての人</li>
</ul>

<p>市谷さんの講演に先駆けて、テクノロジー本部開発推進部の荒井伸二郎さんに「ゼロイチ開発における失敗ケースあるある」を紙芝居形式で語っていただきました。</p>

<p><img alt="" height="389" src="https://image.dmm-corp.com/o0mhvd86vw37713752367yi3cc4y" width="800" /></p>

<p>ある日、突然偉い人から「年内にローンチするぞ！」と新規プロダクト計画をぶち上げられ、開発チームは何を作るかよく理解しないまま開発に突入する。なんとか頑張ってリリースしたものの誰も使ってくれない。挽回するために機能追加するがなんの仮説もないまま実装し、結局鳴かず飛ばずのままひっそりクローズしていく、という誰でも一度は耳にしたことある（架空の）お話から読み解く、仮説検証の有用性についてのセッションでした。</p>

<p>そして、続きまして、こんな思いをしないためのお話を市谷さんに講演いただきました。</p>

<h2>市谷さんによる講演「仮説検証とアジャイル開発」</h2>

<p>すべてのスライドと解説を掲載したいところですが、掲載スペースにも限りがあるので、要点と個人的に心に刺さった箇所をご紹介します。</p>

<p><img alt="" height="513" src="https://image.dmm-corp.com/wcbj4iur7g4lsqznmi6o6at4dxd0" width="800" /></p>

<p><strong>仮説検証の重要性における要点</strong></p>

<ul>
	<li>「何を作っていくべきか」がなければ手ぶらでイテレーションを回すことになってしまうので、「仮説」を立てる必要がある</li>
	<li>「仮説」とは「前提＋仮定＋期待結果」である</li>
	<li>前提（事実）が少ないほど、仮説の部分が多くなる（不確実）</li>
	<li>つまり前提を増やしていくことが重要である</li>
	<li>前提（事実）を作るための根拠はデータや知見である</li>
	<li>ゆえにデータによる理由付けが不可欠であり、データを補う知見が全体の速度を上げる</li>
	<li>事実を増やすとは「情報」を増やして「理解」を得ること</li>
</ul>

<p>しかし検証や調査で<strong>情報だけを増やしても解釈が難しくなり、誤った理解になりやすい</strong></p>

<p><strong><img alt="" height="505" src="https://image.dmm-corp.com/n37j8ls19r4j2o3h2s8b9xrh9q98" width="800" /></strong></p>

<p><strong>ゆえに正しい理解を得るためには「解釈」を鍛える必要がある</strong></p>

<p>ここはとてもに心にヒットしました。私の事業部でも現在は、データ分析をベースとした仮説検証を行う文化になっています。施策をリリースし効果測定（検証）するのですが、出てきた結果は一つであるのに、その分析が人によって違うことがあります。つまり市谷さんのおっしゃる「解釈」が違うという状態です。ここで解釈を誤ると、次の施策の「前提」が変わってきてしまうので、「解釈を鍛える」ことが非常に重要であるというのが分かりますね。</p>

<p><img alt="" height="503" src="https://image.dmm-corp.com/tw0124vz0nz9f4vpo722mzin17l7" width="800" /></p>

<p>「仮説検証の具体的な進め方はいくつかのパターンがあり、引き出しを増やしておくことが重要である」<br />
進め方に絶対的な正解はないというお話です。いくつかのパターンを経験し、引き出しを増やしていきたいですね。</p>

<p><img alt="" height="508" src="https://image.dmm-corp.com/1tsj10dcc9erkid8ib4px4xsy0vl" width="800" /></p>

<p>「不確実性は必ずしも回避すべきものではなく、不確実であるからこそ新たな価値を引き連れてくる可能性もあるため、分からないことを分かるようにしつつ、分からないことを同時に増やすことも大事である」<br />
このあたりは仮説検証における非常に奥深い世界ですね！ 今世の中で成功しているプロダクト、サービスは「不確実性を引き寄せた結果」とも言えそうですね。</p>

<p>今回はおよそ40分に渡って市谷さんに熱のこもった講演を行っていただきましたが、開催後のアンケートでは「<strong>市谷さんの講演をもっと長く聞きたかった</strong>」という声が寄せられていました。市谷さんの講演内容がとても参考になる内容であったことが伺い知れますね。</p>

<h2>DMMマネージャー・プロダクトオーナーによるパネルディスカッション</h2>

<p>市谷さんの講演に続いては、現場のマネージャーやプロダクトオーナーにパネラーとして参加してもらい、テーマごとに実際の開発チームにおける仮説検証の事例や悩みなどのパネルディスカッションを開催しました。</p>

<p>■登壇者<br />
モデレーター :<br />
　&nbsp;市谷聡啓<br />
パネラー :<br />
　石垣雅人 : 総合トップ開発部 部長 兼 DMM PointClubグループ グループリーダー<br />
　池田西秀 : 動画配信事業部 プロダクトオーナー<br />
　高山巧 : life+事業部（MENUS） 前プロダクトオーナー<br />
　寺西一平 : プラットフォーム事業本部 不正対策グループ グループリーダー<br />
　松野広志 : 情報システム部 HR-Techシステム開発チーム チームリーダー</p>

<h3>トークテーマ</h3>

<p><img alt="" height="526" src="https://image.dmm-corp.com/b4cdqvrbgnr97ys8rdlwv4nkepzh" width="800" /></p>

<p>では、実際のディスカッションの様子を一部お届けします。</p>

<h4>仮説立ての具体的手順</h4>

<p>石垣：DMM全社としてデータ戦略を打ち出しているので、KPIが策定されている事業部が多いという認識です。よって、施策を打ち、KPIが動いていくことで、成功か失敗かをデータを見て判断していける状態にはなっていると思います。ただし、失敗した時はなぜ上手くいかなかったのか原因が分からないこともあるので、それは悩みでもありますね。</p>

<p>池田：私のチームは動画配信事業部の売上を最大化させるというミッションを持っています。サイト改善施策を検討した際は、ファーストアクションとしてGoogle Analyticsなどを活用して、ユーザが商品を見つけてコンバージョン（購入）するまでの流れを分析し、ユーザ視点でUXエラーがないかを細かく分析していきました。明らかに使い勝手の悪い箇所、UXエラーがある箇所を改善していくことで効果を得ることができました。競合サイトも分析し、自社が劣っている点がないかも細かく分析しましたね。</p>

<p>市谷：すでに仮説検証が上手く回っている部署も多いのですね。ちなみにDMMの全体で整理されている知識はあるのでしょうか？</p>

<p>石垣：CTOがデータ戦略をパッケージ化していて、それを各事業部でブレイクダウンするなりして活用しているイメージです。</p>

<p>高山：MENUSはデータに詳しいメンバーがいなかったので、本などを読み手探りで進めていました。途中からCTOからKPIツリーを作るフォローをしていただいたことで手順が明確になり、仮説検証が前進していきました。手探りのチームも多いと思いますし、これをやったら鉄板というものはないと思っています。</p>

<h4>施策のヒット率、精度の上げ方について教えてほしい</h4>

<p>池田：売上への貢献は、打席数（施策数）&times;ヒット率 &times; インパクト（効果の大きさ）だと思うのですが、打席数を増やそうとするとどうしても小粒な施策になりがちで、しかし小粒だとKPIはあまり動かないという悩みがあります。逆に大粒な施策を実施しようとすると年間であまり打席に立てないので、そこが悩みですね。</p>

<p>市谷：学んだことをどうやって結果として残すか、次に使えるものとして残すかも大事ですよね。学びを得たことをその後に使えないともったいないので。そういった学びの管理ができているところはさらに少ないですよね。</p>

<p>石垣：私のチームでは、数ヶ月に一回、「今のチームっぽさは何か」をチームにアウトプットしてもらいながらドキュメンテーションしてもらっていて、それをパターン化につなげられていると思っています。</p>

<h4>作ってリリースしたほうが早い病との戦い方</h4>

<p>松野：私たち（HR-Techシステム開発チーム）はBtoBのサービスを開発しています。お客様と会話できる機会が多いので、そこでお客様の声を優先して聞くことで、&quot;リリースしたほうが早い病&quot;をおさえていますね。競合もいるだけに「いいことを思いついたので早くリリースしたい」という状況が生まれることもあるのですが、それをおさえるのは大事だと思っています。</p>

<p>寺西：私たちは不正アクセスを検知するシステムを作っているので、私達にとっての「ユーザ」は不正アクセスする側。なので攻撃者の視点からどう見えるか、こちらの反応から相手がどうするか、リリースを早くするか待つかは判断が難しい時はありますね。</p>

<h4>仮説検証の成功事例・失敗事例</h4>

<p>石垣：よくあるのが、急いでリリースしたけどログが仕込まれていなくて、「これが知りたい」となってもデータが上手く貯まっていなくて見れない、というケースですね。</p>

<p>市谷：いっそのことDONE（完成の定義）の条件に、検証の仕組み（例えばログ仕込み）を入れてしまうというのもありですね。</p>

<p>池田：電子書籍事業は当時施策の実施が先行していたので、他のサービスで成功している施策は、うち（動画配信事業部）でも当たるだろうという前提で優先的に試してみました。ただ、最初の2つは成功したのですが、電子書籍事業で一番成功したものがうちで成功しなかったことがありました。他で成功した施策が、どんな仮説で実施されたものだったのかというのを知っておくのは大事だという教訓になりました。</p>

<p>高山：同時期に複数の施策を実施して、成否の因果関係が分からなくなってしまったことがあります。自サービス内でも施策を打って、マーケティング側も施策を打って、どっちが功を奏したのか分からなかったこともあるので、基本的に施策は一つずつ実施するか、複数実施する場合はしっかり因果関係が判断できるように設計することが大事ですね。</p>

<p>松野：特定の顧客の意見をそのまま聞き入れて大きな売上をあげるわけではないけれど、地味に使われている機能になってしまい、捨てるに捨てられない状況になってしまったことが反省点です。</p>

<h4>高速の検証を行うノウハウ</h4>

<p>石垣：毎日ABテストが回るような状況にはしています。また、全ユーザに施策を打つと失敗リスクが甚大なので、全ユーザではなく10%のユーザに施策を打つなどしてリスクを最小化して実施しています。そうすることで現場でなるべく施策の決済が通るような状況も作り出せます。</p>

<p>池田：一個の施策に注力しすぎると、その施策を外したあと、次の施策の準備ができていなくて、要求整理で歩留まりが起こるので、ある程度は施策のストックが必要だと思っています。開発の観点では、チームの開発サイクルをしっかり見極めたり、開発サイクルを日頃から改善したりすることが大事だと思っています。</p>

<h2>さいごに</h2>

<p>さて、今回は「仮説検証型アジャイルのすすめ」というテーマで勉強会を開きましたがいかがでしたでしょうか。仮説検証の重要性、各チームが工夫していること、失敗談などいろいろな話を聞ける時間となり、大変有意義な会になったと思っています。</p>

<p>&nbsp;</p>

<p>DMM.comでは一緒に働いてくれる仲間を募集しています。ご興味のある方はぜひ下記募集ページをご確認ください！</p>

<div data-oembed-url="https://dmm-corp.com/company/">
<div>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 52.5%; padding-top: 120px;"><iframe allowfullscreen="" src="//if-cdn.com/CT81w3o?app=1" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" tabindex="-1"></iframe></div>
</div>
<script async="" charset="utf-8" src="//if-cdn.com/embed.js"></script></div>

<p>&nbsp;</p>


開発組織マネジメント勉強会レポート番外編「仮説検証型アジャイルのすすめ」

シェア

開発組織マネジメント勉強会レポート 番外編「仮説検証型アジャイルのすすめ」

シェア

開発組織マネジメント勉強会レポート番外編「仮説検証型アジャイルのすすめ」