1正しく失敗しながら進むプロダクト開発Rails Developer Meetup 2018 Day 2関口亮一(@ryopeko)
View Slide
2関口亮一 (@ryopeko)株式会社 Kaizen PlatformApplication EngineerパーフェクトRuby共著者
3Q.Kaizen Platform って何やってる会社ですか?
4Q. Kaizen Platform って何やってる会社ですか?● A/Bテストの会社?● なんかリクルート出身の人が起業した会社?● rebuild.fmでたまに出てたけど名前ぐらいしか知らない
5A.
6A. Kaizen Platform って何やってる会社ですか?● Webの改善活動に関わる様々なことを提供する会社● Kaizen に日々蓄えられているWeb改善の知識経験技術人材を駆使して顧客の改善活動をサポートする会社● そのためのツールとして様々なサービスを SaaS として提供している会社● A/Bテストはその一部
7今日のお話し
8この2年ぐらいの間に起きたものづくりのプロセスの変化のお話し
9
10様々な変化があったが今回は開発に寄ったお話しをします
11Kaizenでの日々の開発
12Kaizenでの日々の開発● 以下のロールの人たちがチームを組んで仕事をする○ Backend Engineer○ Frontend Engineer○ UI/UX Designer○ Analyst○ QA Team○ Product Manager
13Kaizenでの日々の開発● 規模や内容によって役割を兼務することもある● チームで組んだり1人で完結させたり様々● 作るものの規模によって2週間 ~ 2ヶ月など● 仕事場はオフィスと各所からのリモート
14Kaizenでの日々の開発● 四半期に1度全社合宿とProductチーム合宿● 次の四半期、半期、1年、その先について議論し認識を合わせる● ロードマップ、プロダクト理解、業務の振り返り棚卸し● etc...
15以前は大きなロードマップの中で仕事をしていた
16以前までのプロダクト開発● CEOやPMが優れたアイディアを披露● そうして見定めたものをみんなで作っていく● 合宿などで議論しつつロードマップを作る
17以前までのプロダクト開発● これほんといるの?ちゃんと使われるの?● キャッチアップし続けるのが大変
18以前までのプロダクト開発● 作るものが大きい故の不確実性● 作ったものが刺さらなかった時のリスク増● 一気に作るのでフィードバックを受けても反映されにくい
19そうしつつも事業は成長していく
20進むと見えてくるたくさんのこと
21進むと見えてくるたくさんのこと● 足元の課題の顕在化● 複雑化する業務プロセス、プロダクト● 複雑でも変化し続けるので更に複雑に
22個々に頑張ってしまい知見やノウハウが横展開されない...
23
24最恐のツール Google Spreadsheets の乱立
25ここまでのまとめ
26ここまでのまとめ● 会社、事業が順調に成長してきた● 先を見越して大きく作って大きく出す● 業務やプロダクトの複雑化● 個々で進む業務効率化● 知見が横展開されず暗黙知に溢れる
27プロダクト開発チームはどう対処したか
28対処方法● 問題点を整理しあるべき姿を定義する● Kaizen の中で積み上げられてきた知識、仕事の棚卸し● 暗黙知からベストプラクティスへの型化● 型化したものをよりスケールする形でツール化する
29
30巨大なモノリシックなアプリケーションに構築
31
32小さく作る
33小さく作る● 小さく作ってすぐに出す● フィードバックを受けて改善する● 試しやすく捨てやすく統合しやすくしてスピードを上げる● コンテキストを明確にしてシステムの中で迷子にならないようにする
34Microservices?
35Microservices?
36小さく作るということ
37小さく作るということ● スピードを出すために組織、役割を分割すること● チームの生産性を維持したまま事業のcapabilityを上げることを狙う● 事業、組織、役割の理解分解再構築の結果としての小さなサービス※ちょうど ajito.fm #20 でも似たようなことが言われていたhttps://ajito.fm/20/
38プロダクト開発のパターン分類
39プロダクト開発のパターン分類● 小さく作りつつも事業全体として統率を取るために● 分類によっては必要なもの不要なものがある● 全部のものづくりをひとつのパターンに当てはめても無駄なことをしてスピードや安心、信頼性を損ねてしまう
40プロダクト開発のパターン分類
41プロダクト開発のパターン分類● MVP○ 先々ローンチしたい機能/UXのProof Of Conceptをとることを目的とする● α○ 基本的には社内での利用● β○ 一部の顧客に対して closed なもの、public なものを含む● GA○ 全ての顧客に対して公開されていて高いSLOを担保する
42その結果リリースの頻度とスピードが上がった
43
44フィードバックの受け方
45フィードバックの受け方● 開発するものの具体像を決める前に対処したい問題を見極める● 見極めた上でどうあるべきかのドラフトを作る● 開発するものの主ユーザーに↑と対処したい問題をセットで見せることで方向性を一致させる● 開発を進める
46フィードバックの受け方● ある程度動くものになってから触ってもらう● その段階で見えてくるもの = 開発前に提示したものとのギャップ をプロダクトにフィードバックする● 時にはデータを持って問題、対処、フィードバックをリードする
47これらのサイクルに携わる人
48フィードバックサイクルに携わる人● UI/UX Designer● Product Manager● Engineer● Analyst● ユーザー(顧客、社内の様々なロールの人)
49フィードバックの重要性
50フィードバックの重要性● 間違い、失敗、認識違いを最速で認知、対処するため● 期待値の維持● 間違ったものを作っていないという安心感● 巻き込み、一体感
51まとめ
52まとめ● 大きく作って間違えないことはかなり難しい● 間違えてなくても事業、顧客、ユーザーの成長により求められるものは変化する● 小さく作って間違えても大丈夫なようにする● 失敗しやすく、気付きを最速で得られるようにする