はじめに
こんにちは、プラットフォーム事業本部の石垣雅人(@i35_267)です。
DMM.comのサービスで利用されるプラットフォーム基盤においてProduct Ownerを務めております。
今回は、2018年12月15日に開催された『Developers Boost～U30エンジニアの登竜門～』で登壇してきた内容を補足説明を加えながらご紹介したいと思います。
このイベントは登壇者及び参加者までが、30歳以下(U30)ということで非常に若いエンジニアたちが集まったイベントとなっています。
- はじめに
- 登壇内容
- 『開発プロセス』を思考する重要性
- Problem : LeadTimeの重要性
- Solution : Evidence-Based Management
- Action / Result : VSM(Value Stream Mapping)
- まとめ
- 最後に
登壇内容
セッションは、以下のタイトルで登壇してきました。
プロダクト成長のために『開発プロセス』を思考せよ。
〜EBMを軸とした『プロセスの見える化』 と 『ムダからの解放』を実践したインパクトについて〜
当日は、以下の4点を主にお話しました。
1.『開発プロセス』を思考する重要性
2. Problem : LeadTimeの重要性
3. Solution : Evidence-Based Management
4. Action / Result : VSM(Value Stream Mapping)
流れとしては以下になります。
理想の『開発プロセス』を追い求めていく中で
- どういった問題があったか(Problem)
- どのような解決策を見つけたか(Solution)
- どういったアクションをしてその結果どうなったか(Action/Result)
の順にポイントを整理していきます。
この記事では、4. Action / Result : VSM(Value Stream Mapping)以外の部分について述べていきます。
※ 4. に関しては様々なところで言及しているので参考資料を記載しておく程度に留めます。
『開発プロセス』を思考する重要性
まずは、『開発プロセス』を思考する重要性についてです。
理想とする『開発プロセス』の全体像は以下です。
以前は、Scrumのみを取り入れておりましたが以下のような問題がありました。
- Product Ownerやステークホルダーが思いついた仮説を開発チームに下ろし中長期かけて開発からのリリース。しかし仮説の妥当性を担保していないため、リリース後全然利用されない。
- 機能をリリースした後、効果測定の面でデータドリブンになっておらず、ユーザーに使われているかわからない。
こういったことから、開発プロセスとして以下のフレームワーク・概念を取り入れました。
- Scrum
→ 仮設に対する開発フェーズの担保 - Lean(リーン開発) New
→ 仮説の妥当性の担保 - Design Thinking(デザイン思考) New
→ 仮説の妥当性の担保 - Data Science(データ科学) New
→ リリース後のデータ計測・データドリブンの担保
ポイントしては、Leanにおけるリーンキャンパス、BMLループを軸として上で述べたScrumやLean, Design Thinking, Data Scienceのサイクルを回していきます。
※ リーンキャンパスとBMLループの図。
開発プロセスの流れについては3つのフェーズがあります。
Customer Problem Fit = ユーザの痛み(問題)はどこか。
まずは、その仮説が本当にユーザーの痛み(問題)を解決しているかどうかの仮説の妥当性を担保します。
ここのフェーズを構成する要素としては『Lean』『Design Thinking』の手法が有効だと考えています。例えば、仮説に対して必ずA/Bテストをしたり、ペルソナ分析、カスタマージャーニー、Leanで言うならば顧客開発・ユーザストーリーマッピングの手法で妥当性を担保します。
Product Solution Fit = 顧客の問題を解決しているか。
Customer Problem Fitで検証した仮説に対して、どのような解決方法で開発していくかがProduct Solution Fitのフェーズです。MVP*1という最小限のプロダクトを構築していかに早く市場へ投入するかを考えていきます。ここではScrumやXPの手法を利用して、効果的でかつ効率よくMVPを構築することが良いです。
Product Market Fit = 市場にマッチしたプロダクトを提供できているか。
最後にMVPをリリースして市場へ投入した後にどういった反応があるかをモニタリングしていく必要があります。
MVPをリリースして、データ基盤から設定しているKPIの数値が上がっているのか、下がっているかを見ていきます。
ここで正しいデータが計測できていなかったりすると学習が出来ず、ピボット*2して再度プロダクトを改修する必要がでてきたりします。
必ず、正しいデータから学習し次の施策、仮説を考えていきます。
以上、3つのフェーズですが要約すると一番言いたいことは以下です。
結局のところ、仮説の妥当性を担保しても、リリースしたものすべてがヒットというプロダクトはありません。
そのため、ROI*3やROAS*4を高めながら、プロダクトを『最速』で、仮説検証を『高速』に繰り返して、Product Market Fitに近づける必要があります。
Problem : LeadTimeの重要性
次に理想の開発プロセスを目指す中でのProblemを述べていきます。
まず、BMLループで一番大事な部分はどこでしょうか？
私の中の結論では以下になります。
つまり、開発のフェーズです。
経験上、ここが遅れると仮説検証は『高速』で繰り返せなくなり仮説ばかりが山積みになります。
そうするとプロダクトバックログだけが溜まり続け、市場への価値が提供できない組織になってしまいます。
Solution : Evidence-Based Management
Problemの部分で開発フェーズのLean Timeの重要性を述べましたが、では何を削減すれば良いかがわかりません。
そこで指標として使ったのが、Evidence-Based Management(略 : EBM)という概念です。
EBMとは、前提としてAgileの問題提起から入ります。
よくあるケースとしては以下があります。
- 自身のチームのベロシティーは安定している。
- スプリントも毎回バーンダウンしている。
といった形で、スクラムがうまく回っているといったことに満足している組織を多く見られます。
もちろん、このこと自体は素晴らしいことですがスクラムがうまく回っているからといって、組織としてビジネス価値を提供できているとは限らない。というのがEBMからの問題提起です。
EBMは、組織が提供した『価値』にフォーカスし、その設計方法まで提供しています。
4つの重要価値領域（KVA: Key Value Areas）で構成されています。
また、それぞれのKVAsの中で何を指標として見ていけばいいかをKVM(Key Value Measure)を提供しています。
そして、4つのKVAsの中で、今回、ProblemであったLean Time削減の指標とするのは『T2M : Time to Market (市場投入までの時間)』のKVAです。
T2M : Time to Marketの『KVA』と『KVM』の意味・概要は以下です。
『KVA』
『KVM』
見て分かる通り、T2Mとは市場までの投入時間を常にモニタリングすることが重要としています。
今回、4つのKVAsのすべては説明しませんが、興味がある方は以下をご覧ください。
www.scrum.org
Action / Result : VSM(Value Stream Mapping)
EBMにおける『T2M : Time to Market』を指標として可視化すれば良いことがわかりました。
では、その指標をどうやって可視化していくかについて述べていきます。
ひとつの答えとしてVSM(Value Stream Mapping)を使っていきます。
VSMとは、IdeaがValueになるまでを可視化する手法になります。
※VSMについての詳しい説明や書き方については、以前書いた記事がございますのでご覧ください。
VSMについての説明は上の記事に譲るとして、T2M : Time to Marketの指標を可視化した結果について述べます。
これはひとつの例にはなりますが、リードタイムの項目やサイクルタイム(リリース作業時間)に大きな時間がかかっていることがわかります。
自チームとしては、Action→Resultとして以下の数値程度にLead Timeを短縮することに成功しました。
こちらも、そこまで難しいことはしておらず不要なMTGをなくしたりすることでこのくらいの短縮時間になります。こういった数値を常にモニタリングすることでより開発プロセスが良いものになっていくと確信しております。
まとめ
今回は、プロダクト成長のために『開発プロセス』を思考する重要性について述べました。
プロダクトを成長させる上で、開発プロセスを設計することはプロダクトをProduct Market Fitに近づける近道になると考えておりますので、皆さんもぜひ参考にしてみてください。
最後に
最後に採用情報をお伝えさせてください。 私がプロダクトオーナーを務めるプラットフォーム事業本部 Customer Decision Support Teamでは、一緒に働いてくれる仲間を探しています。 2018年7月に立ち上げたばかりでまだまだポテンシャルを秘めたチームです。 少しでもご興味のある方はぜひご応募ください！