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

正しく失敗しながら進むプロダクト開発/railsdm2018

 正しく失敗しながら進むプロダクト開発/railsdm2018

Ryoichi SEKIGUCHI

March 25, 2018
Tweet

More Decks by Ryoichi SEKIGUCHI

Other Decks in Technology

Transcript

  1. 1
    正しく失敗しながら進む
    プロダクト開発
    Rails Developer Meetup 2018 Day 2
    関口亮一(@ryopeko)

    View Slide

  2. 2
    関口亮一 (@ryopeko)
    株式会社 Kaizen Platform
    Application Engineer
    パーフェクトRuby共著者

    View Slide

  3. 3
    Q.
    Kaizen Platform って何やってる会社ですか?

    View Slide

  4. 4
    Q. Kaizen Platform って何やってる会社ですか?
    ● A/Bテストの会社?
    ● なんかリクルート出身の人が起業した会社?
    ● rebuild.fmでたまに出てたけど名前ぐらいしか知らない

    View Slide

  5. 5
    A.

    View Slide

  6. 6
    A. Kaizen Platform って何やってる会社ですか?
    ● Webの改善活動に関わる様々なことを提供する会社
    ● Kaizen に日々蓄えられているWeb改善の知識経験技術人
    材を駆使して顧客の改善活動をサポートする会社
    ● そのためのツールとして様々なサービスを SaaS として提供し
    ている会社
    ● A/Bテストはその一部

    View Slide

  7. 7
    今日のお話し

    View Slide

  8. 8
    この2年ぐらいの間に起きたものづくりの
    プロセスの変化のお話し

    View Slide

  9. 9

    View Slide

  10. 10
    様々な変化があったが
    今回は開発に寄ったお話しをします

    View Slide

  11. 11
    Kaizenでの日々の開発

    View Slide

  12. 12
    Kaizenでの日々の開発
    ● 以下のロールの人たちがチームを組んで仕事をする
    ○ Backend Engineer
    ○ Frontend Engineer
    ○ UI/UX Designer
    ○ Analyst
    ○ QA Team
    ○ Product Manager

    View Slide

  13. 13
    Kaizenでの日々の開発
    ● 規模や内容によって役割を兼務することもある
    ● チームで組んだり1人で完結させたり様々
    ● 作るものの規模によって2週間 ~ 2ヶ月など
    ● 仕事場はオフィスと各所からのリモート

    View Slide

  14. 14
    Kaizenでの日々の開発
    ● 四半期に1度全社合宿とProductチーム合宿
    ● 次の四半期、半期、1年、その先について議論し認識を合わせ

    ● ロードマップ、プロダクト理解、業務の振り返り棚卸し
    ● etc...

    View Slide

  15. 15
    以前は大きなロードマップの中で仕事をしていた

    View Slide

  16. 16
    以前までのプロダクト開発
    ● CEOやPMが優れたアイディアを披露
    ● そうして見定めたものをみんなで作っていく
    ● 合宿などで議論しつつロードマップを作る

    View Slide

  17. 17
    以前までのプロダクト開発
    ● これほんといるの?ちゃんと使われるの?
    ● キャッチアップし続けるのが大変

    View Slide

  18. 18
    以前までのプロダクト開発
    ● 作るものが大きい故の不確実性
    ● 作ったものが刺さらなかった時のリスク増
    ● 一気に作るのでフィードバックを受けても反映されにくい

    View Slide

  19. 19
    そうしつつも事業は成長していく

    View Slide

  20. 20
    進むと見えてくるたくさんのこと

    View Slide

  21. 21
    進むと見えてくるたくさんのこと
    ● 足元の課題の顕在化
    ● 複雑化する業務プロセス、プロダクト
    ● 複雑でも変化し続けるので更に複雑に

    View Slide

  22. 22
    個々に頑張ってしまい知見やノウハウが
    横展開されない...

    View Slide

  23. 23

    View Slide

  24. 24
    最恐のツール Google Spreadsheets の乱立 

    View Slide

  25. 25
    ここまでのまとめ

    View Slide

  26. 26
    ここまでのまとめ
    ● 会社、事業が順調に成長してきた
    ● 先を見越して大きく作って大きく出す
    ● 業務やプロダクトの複雑化
    ● 個々で進む業務効率化
    ● 知見が横展開されず暗黙知に溢れる

    View Slide

  27. 27
    プロダクト開発チームはどう対処したか

    View Slide

  28. 28
    対処方法
    ● 問題点を整理しあるべき姿を定義する
    ● Kaizen の中で積み上げられてきた知識、仕事の棚卸し
    ● 暗黙知からベストプラクティスへの型化
    ● 型化したものをよりスケールする形でツール化する

    View Slide

  29. 29

    View Slide

  30. 30
    巨大なモノリシックなアプリケーションに構築

    View Slide

  31. 31

    View Slide

  32. 32
    小さく作る

    View Slide

  33. 33
    小さく作る
    ● 小さく作ってすぐに出す
    ● フィードバックを受けて改善する
    ● 試しやすく捨てやすく統合しやすくしてスピードを上げる
    ● コンテキストを明確にしてシステムの中で迷子にならないようにする

    View Slide

  34. 34
    Microservices?

    View Slide

  35. 35
    Microservices?

    View Slide

  36. 36
    小さく作るということ

    View Slide

  37. 37
    小さく作るということ
    ● スピードを出すために組織、役割を分割すること
    ● チームの生産性を維持したまま事業のcapabilityを上げることを狙う
    ● 事業、組織、役割の理解分解再構築の結果としての小さなサービス
    ※ちょうど ajito.fm #20 でも似たようなことが言われていた
    https://ajito.fm/20/

    View Slide

  38. 38
    プロダクト開発のパターン分類

    View Slide

  39. 39
    プロダクト開発のパターン分類
    ● 小さく作りつつも事業全体として統率を取るために
    ● 分類によっては必要なもの不要なものがある
    ● 全部のものづくりをひとつのパターンに当てはめても無駄なこと
    をしてスピードや安心、信頼性を損ねてしまう

    View Slide

  40. 40
    プロダクト開発のパターン分類

    View Slide

  41. 41
    プロダクト開発のパターン分類
    ● MVP
    ○ 先々ローンチしたい機能/UXのProof Of Conceptをとることを目的とする
    ● α
    ○ 基本的には社内での利用
    ● β
    ○ 一部の顧客に対して closed なもの、public なものを含む
    ● GA
    ○ 全ての顧客に対して公開されていて高いSLOを担保する

    View Slide

  42. 42
    その結果リリースの頻度とスピードが上がった

    View Slide

  43. 43

    View Slide

  44. 44
    フィードバックの受け方

    View Slide

  45. 45
    フィードバックの受け方
    ● 開発するものの具体像を決める前に対処したい問題を見極め

    ● 見極めた上でどうあるべきかのドラフトを作る
    ● 開発するものの主ユーザーに↑と対処したい問題をセットで見
    せることで方向性を一致させる
    ● 開発を進める

    View Slide

  46. 46
    フィードバックの受け方
    ● ある程度動くものになってから触ってもらう
    ● その段階で見えてくるもの = 開発前に提示したものとのギャッ
    プ をプロダクトにフィードバックする
    ● 時にはデータを持って問題、対処、フィードバックをリードする

    View Slide

  47. 47
    これらのサイクルに携わる人

    View Slide

  48. 48
    フィードバックサイクルに携わる人
    ● UI/UX Designer
    ● Product Manager
    ● Engineer
    ● Analyst
    ● ユーザー(顧客、社内の様々なロールの人)

    View Slide

  49. 49
    フィードバックの重要性

    View Slide

  50. 50
    フィードバックの重要性
    ● 間違い、失敗、認識違いを最速で認知、対処するため
    ● 期待値の維持
    ● 間違ったものを作っていないという安心感
    ● 巻き込み、一体感

    View Slide

  51. 51
    まとめ

    View Slide

  52. 52
    まとめ
    ● 大きく作って間違えないことはかなり難しい
    ● 間違えてなくても事業、顧客、ユーザーの成長により求められ
    るものは変化する
    ● 小さく作って間違えても大丈夫なようにする
    ● 失敗しやすく、気付きを最速で得られるようにする

    View Slide