大規模サービスにおける価値開発の“これまで”と“将来”～新たな“じゃらんnet”のチャレンジに関して～
•
2 gefällt mir•4,759 views
Developers Summit 2018での発表資料です。 リクルートライフスタイル 坂東 塁
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 大規模サービスにおける価値開発の“これまで”と“将来”～新たな“じゃらんnet”のチャレンジに関して～
Ähnlich wie 大規模サービスにおける価値開発の“これまで”と“将来”～新たな“じゃらんnet”のチャレンジに関して～ (20)
Mehr von Recruit Lifestyle Co., Ltd.
Mehr von Recruit Lifestyle Co., Ltd. (20)
大規模サービスにおける価値開発の“これまで”と“将来”～新たな“じゃらんnet”のチャレンジに関して～
- 2. ⾃⼰紹介01 坂東塁 ＜略歴＞ • 楽天株式会社に新卒⼊社 ü 新サービスの企画・開発 ü 楽天技術研究所とOSS開発・プロモーション ü 社内インフラサービス構築 ü Rakuten Technology Conference • 2016年 株式会社リクルートライフスタイルに転職 ü プロダクトデザインユニット配属 ü リーン開発Tのリーダー（PO）として、じゃらんnetの改善に携わる • 2017年〜 ü じゃらんnet（宿）のWEB/APP・じゃらんnet横断UXデザインリーダー ü プロダクト開発グループの兼務となり、プロダクトマネージャーとして新しい体制構築に携わる プロダクトマネージャー/UXデザイナー ネットビジネス本部 旅⾏事業ユニット UXデザイングループ 兼）ディベロップデザインユニット プロダクト開発グループ
- 3. 全社内でのリクルートライフスタイルの位置づけ02 リクルート HD Media ＆ Solutions HR Technology Stuffing Holding Company SBU (Strategic Business Unit) リクルートキャリア リクルートジョブズ リクルートライフスタイル リクルート住まいカンパニー リクルートマーケティングパートナーズ リクルートアドミニストレーション リクルートテクノロジーズ リクルートコミュニケーションズ Company
- 8. “じゃらんnet”に関して07 『宿』だけでなく『旅⾏』という 優れた体験を提供する • 年間約9,600万泊予約 • 約2.7万軒宿泊 • プラン件数:約300万件 • 観光スポット情報：約18万件 • クチコミ掲載数：約68万
- 9. 現在の私の仕事とは？08 リーン開発体制 etc 新規 チャレンジ 横断 カスタマー（UX） クライアント ü リクルートライフスタイル内でのこれまでと⽴ち位置 • プロダクトデザインユニットにおいて”宿予約”兼リーン開発体制のリーダー（PO）として従事 • リーン体制に加えてAPP・じゃらんnet横断のUX全体も⾒る • SSL導⼊や外部提携案件周りのPLとして⼤規模開発のディレクション • 旅⾏業務⽀援の⽴ち上げ時のAI学習周りの構築 • 新しい体制構築含め、PMとしてから新規チャレンジ案件を模索 ü ⽴ち位置と役割イメージ Android/iOS 開発部
- 11. ”じゃらんnet”での仕事とは
- 12. 10 これまでの”じゃらんnet”における仕事 仕事 ＝ 企画 & 管理・調整 & 管理・調整 企画 外部パートナー 開発者
- 13. 11 これまで“じゃらんnet”の歩んできたプロセス V字モデル + α ü 企画側の社員はビジネス検討と効果振り返りに注⼒ ビジネス検討 要件定義 基本設計 実装・UT 結合テスト 受⼊テスト 効果振り返り アーキテクチャ構成 ü アーキテクチャ／インフラともに 共通化して全体最適を図ってきた 開発プロセス オンプレミス Java HTML・CSS Javascript DB
- 14. ⻑い歴史における”じゃらんnet”の開発体制とは12 採⽤された理由 • 信頼性・安定性 • 不確実性がないように進められる • ⼤規模なサービス開発である ●通常サイクル：2-3か⽉ 振り返り報告 振り返り 資料作成 リリース受入テストテストケース 作成 開発 デザイン/ HTML発注/ 作成 ワイヤー作成 要件定義案件決定決裁会議 ビジネス 詳細検討 案件出し ●通常開発フロー
- 15. ⻑い歴史における”じゃらんnet”の開発体制とは13 l これまで（通常案件）の考え⽅ 企画と開発に対する考え⽅ ゴールが⾒えている分、作って終わりになりがち 深いビジネス検討をしてゴールを設定、描いたゴールに突き進むゴールが⾒えている場合は、 この⽅法が最適とされていた 現 状 理 想 見えている ゴールに 最短で進む
- 18. リーン開発体制の⽴ち上げ
- 20. リーン開発体制へ向かったきっかけ16 当時のIndeed の考え⽅：圧倒的な⾼速開発 üカスタマに実際使ってもらわないとわからない、まず試してみる üゴールが⾒えない場合は、仮説ベースでまず試してみることが有効 üカスタマーからのフィードバックを⼤事にする 当時のRLS の考え⽅：⾼いレベルのビジネス企画 ü 深いビジネス検討をしてゴールを設定、描いたゴールに突き進む ü ゴールが⾒えている場合は、この⽅法が最適であり、 ⾒えているゴールに最短で進む ⽉次リリースかつリードタイムも 2-3 か⽉ ⇔ 週次レベルのリリースが基本
- 21. リーン開発体制で実現したかったこと17 1. 意志決定・判断の簡略化 ü 基本的な意思決定は決裁者（プロデューサーやGM）を通さずPOによる判断 ü 案件は優先度順にエンジニアが着⼿ ü リソース状況に応じて、スケジュールを柔軟に調整 2. パフォーマンス最⼤化のため、フロー最⼩化 ü 豊富な分析リソースの利⽤ ü データサイエンティストの協業 ü モニタリングのダッシュボード化・⾃動化 ü 要件定義の簡略化とフォーマット化 ü 同⼀ロケーションによる開発とのコミュニケーション最適化 ■実現に向けて変えたこと
- 22. リーン開発体制で実現したかったこと18 1. 意志決定・判断の簡略化 ü 基本的な意思決定は決裁者（プロデューサーやGM）を通さずPOによる判断 ü 案件は優先度順にエンジニアが着⼿ ü リソース状況に応じて、スケジュールを柔軟に調整 2. パフォーマンス最⼤化のため、フロー最⼩化 ü 豊富な分析リソースの利⽤ ü データサイエンティストの協業 ü モニタリングのダッシュボード化・⾃動化 ü 要件定義の簡略化とフォーマット化 ü 同⼀ロケーションによる開発とのコミュニケーション最適化 ■実現に向けて変えたこと
- 24. リーン開発体制における”意思決定” 〜After〜20 ■案件決定の権限を現場に委譲 ü 案件の決定はリーン開発体制内で⾏う ü 決裁者（決裁会議やプロデューサー・GM）の承認を都度とらない この体制内で ・実施内容 ・実施可否 ・リリース時期 などを決定 PDCAサイクルを回す
- 25. リーン開発体制で実現したかったこと21 1. 意志決定の簡略化 ü 基本的な意思決定はプロデューサーとGMを通さずPOによる判断とする ü 案件は優先度順にエンジニアが着⼿ ü リソース状況に応じて、スケジュールを柔軟に調整 2. パフォーマンス最⼤化のため、フロー最⼩化 ü 同⼀ロケーションによる開発とのコミュニケーション最適化 ü 豊富な分析リソースの利⽤ ü データサイエンティストの協業 ü モニタリングのダッシュボード化・⾃動化 ü 要件定義の簡略化とフォーマット化 ■実現に向けて変えたこと
- 26. リーン開発体制における”組織・開発体制”とは22 ■通常開発における開発体制 ü 役割的には⼤きく変わらないが既存の開発体制をリーン開発に適応させるには課題があった ディレクターの外注 調整や検討コストが ⾼く、負荷が⾼い 別ロケーションであ ることもあり、デザ インへの意志の反映 が難しい。UI/UXへの 認識齟齬など発⽣ エンジニア リーン開発を導⼊する際の懸念点 • ディレクター・エンジニア・デザイナーが別ロ ケーションによる認識の齟齬などからの⼿戻り • ディレクターとエンジニア側との相談が気軽にで きないなど調整コストの増⼤ • ディレクターの検討・調整負荷が⾼い 担当者も変動するこ ともあることで、品 質リスクの可能性。 案件ごとにスキルの 異なるメンバーが集 まる可能性。
- 27. リーン開発体制における”組織・開発体制”とは23 リーン開発体制を導⼊した結果 ü 同⼀ロケーション・ 権限移譲で管理コ ストを減少されることで検討に注⼒ ü ⽉次リリースより、週次リリースによる リリースタイミングの変更 ü 当時、IndeedとRLSの体制を⽐較検討し た結果、 UIのABテストについても、 Indeed同様の⾼速開発が最適 ■リーン開発における開発体制について ü PDCAサイクルを回し、案件を数多く実現し成功数も増加 ü コミュニケーションロスが激減し、開発コストも削減・品質向上に貢献 ⼈が固定なので、ナ レッジの蓄積が可能 ロスが最⼩限になる 同⼀ロケーション・ 管理コス ト減で検討 に注⼒可
- 28. リーン開発体制を⽀える豊富な分析リソース24 WEB Log 基幹DB App Log SaaS Log 担当者 Excel Etc. Amazon S3 Amazon Redshift ■仮説の質を⾼める データ分析基盤はRLS内では誰でも利⽤可能 • Tableau • Amazon Redshift / S3 • TREASURE DATA • Adobe Analytics • Google BigQuery • SQL × × TREASURE DATA
- 31. リーン開発体制を⽀えるデータエンジニアリング体制26 リンク： https://www.slideshare.net/RecruitLifestyle/ss-77062076 動画： https://cloudnext.withgoogle.com/tokyo/schedule#target =-3db6d974-c318-49b3-b03c-a4f58c55b601 Google Cloud Next での事例発表 ■データエンジニアリング（Capture Every Thing）体制の概要 ü サービス横断でリアルタイムにデータを収集 • 約 300GB /⽇ ü リアルタイムデータ分析に必要な処理を ⼀気通貫で実施 ü 分析結果を WebAPI として各サービスへ提供
- 33. リーン開発体制を⽀えるデータエンジニアリング〜実践例１28 ■⾮エンジニアでもデータをアップロードするだけで Web APIにできる仕組み • TSV をアップロードするだけで、誰でも⾃由に API を作れる →常時20くらいのAPIが更新/利⽤されている • 書き込み側はS3 + SNS + SQS の構成（以前は Lambda を挟んでいたが、最近簡素化した） • APIにGKEを利⽤したかった
- 34. リーン開発体制を⽀えるデータエンジニアリング〜実践例２29 ■Beam SDKによるリアルタイムなデータ提供の仕組み • リアルタイムなデータをビジネスに還元する仕組み • 機械学習を取り⼊れ、最適なデータを提供 • リアルタイム処理は Dataflow (Beam) を採⽤ • Dataflowはある程度マネージドである点とプログラミングモデルが良い • BigQueryを副⼊⼒に使ったりはする
- 35. モニタリング指標を⼤切にする30 ■モニタリング指標を設ける ü 多くの指標を⽇々確認（ROI/UX最⼤化） ü 以前はDirが数値をTablueaを⽤いて可視化 →現在はSlackに⾃動通知 ü ⽇次でABモニタリングを実施し、有意差判定を実施 ü Redshift, BigQuery, Adobeデータの連動 × ×
- 36. これまでのリーン開発体制での取り組み31 「プロダクトオーナー・エンジニアのパフォーマンスの最⼤化」 ü プロダクトオーナーのパフォーマンスの最⼤化 ü 削れるものを徹底的に削る ※開発以外でも⽇々の業務で⾃動化できるものだったり、フォーマット化でき るもは徹底 ü 決裁 ü 報告 ü モニタリング üエンジニアがパフォーマンスを発揮するためにはどうすればよいかを追求 ü 仕様検討・デザイン（UI/UXなど）観点の徹底 ü エンジニアとの健全な議論 ■パフォーマンス最⼤化に向け取り組んだ点 結果、週次で⾼いクオリティで⼀定数のリリースを実現
- 38. 現在のリーン開発体制とは33 ■スクラム/アジャイルの導⼊ 当時のIndeedを意識したスクラムだったものを”じゃらんnet”の体制に合わせる ü タスク管理をJIRAを⽤いたPBL最適化 ü バーンダウンチャートの導⼊ ü スプリングプランニングMTG・レトロスペクティブ ü チーム全員で案件に取り組む・⾃主性を促す活動 ü チーム全員で楽しむ（全員でのモニタリングの導⼊） ü 他社の⾒学会や事例のヒアリング ⼀緒に進めるメンバーが⽣まれる
- 39. その分、やりがいもあって楽しいし、何でもできる！ PDCAに取り組むためのプロダクトオーナーの役割34 ■プロダクトオーナーの責任は重⼤ • チームのゴールミッションの責任者 • 勝ちを最⼤化し、チームのROIを最⼤化する • チームへのインプットの質（PBL）が結果に即繋がる • チーム内外での信頼を勝ち取る • UXにおける責任者 • 企画・開発という垣根を取っ払うこと 意思決定に時間をかけるのではなく、カスタマーに聞くことを第⼀優先に
- 40. リーン開発体制に取り組んだ結果としてチームが得られた観点 リーン開発体制を振り返る〜リーン開発で得られたこと〜35 企画･ビジネス検討 要件定義 123… A B コミュニケーション 技 術 マネジメント U X
- 41. リーン開発体制に取り組んだ結果としてチームが得られた観点 リーン開発体制を振り返る〜リーン開発で得られたこと〜35 企画･ビジネス検討 要件定義 123… A B コミュニケーション 技 術 マネジメント U X 過渡期の中でリーン開発体制の⼤切さを感じとれた 既存開発体制との住み分け（SoR/SoE観点）を意識する
- 43. ”チャレンジ“の必要性〜変わるもの〜36 ü 今までは作るまでに時間をかけていた。どちらかという と安全な守りの⽂化は少なくともあった ü SoRとSoEの住み分けを整理する ü 改めて、『リリースしたら終わり』ではなく『リリース 後の検証と⾒直し』を繰り返す体制へ
- 44. ”変わるもの“としてのチャレンジへ37 ■これまでのリーンTの考え⽅ カスタマに実際使ってもらわないとわからない、まず試してみるゴールが⾒えない 場合は、仮説ベースでまず試してみることが有効 ü 案件と企画に対する考え⽅→これまでの企画に対する考え⽅が異なる 現 状 PDCAサイクルを回す 理 想
- 48. チャレンジ〜プロダクトマネージャーとして〜40 ”じゃらんnet”のチャレンジにおいて必要だったもの... プロダクトに成功に専念するプロダクトマネージャーとして考える ü プロダクトチームを構築（ゼロからの仮説検証の体制の構築） ü プロダクトのあるべき姿を考える（プロダクトの成功にこだわる） ü リーン開発を意識したMVPを検証（継続的に⾒る） これまでの『リリースしたら終わり』ではなく、リーンスタートアッ プのような『リリース後の検証と⾒直し』を⾼速で繰り返す体制構築
- 50. チャレンジ〜ゼロから体制を〜42 ü 後悔しない体制を ü 求めるものは何でも ü 予算 ü etc... リクルートならでは？ 好きにしていいから、 好きなように作ってみて 好きに...
- 51. チャレンジ〜ゼロから体制を〜43 ü 後悔しない体制 ü 求めるものは何でも ü 予算 ü etc... 好きに... 基本的には何も与えてくれない ⾃分でどれだけ⼈を集めれるのか ⾃分で動くしかない
- 53. チャレンジ〜ゼロから体制を〜45 ü ⾔えばフォローしてくれる環境 ü リクルートの⽂化→個⼈の尊重・チャレンジを⽀える ü 各部⾨のスペシャリストがリクルートには多い 気づけば⼈が集まる環境 理想的な体制を創る プロダクトのあるべき姿、成功にこだわり抜ける体制にできた Engineer Designer Analyst Director Client Q A TechLead Frontend Sales Scrum Master
- 55. チャレンジ〜プロダクトマネージャーとして〜47 ■RLS（じゃらんnet）におけるPMに関して Engineer Designer Analyst Director Client Q A TechLead Frontend Sales Scrum Master ü プロダクトマネージャーの⽴ち位置 • ゴールは数値などで明確に決めるが、具体的な実現⽅法は PMのアイデア次第。『やる』と決まれば、後は⾃由にや らせてくれる点はスタートアップに近い • ⼈を集めて、予算も集める（必要なものは何でも⾔える） • リクルートという企業⽂化との適合 ü 結果を出すために適切に深い検証をとことん繰り返す ü プロダクトマネージャーは実験台としてのチャレンジ ＜結果を求められる＞ ü プロダクトのあるべき姿、成功にこだわり抜く • 周囲に受け⼊れられ、⼀緒にやろう！を増やす信頼の獲得 • TL（エンジニア）との建設的な議論・判断の速さ
- 56. チャレンジ〜プロダクトマネージャーとして〜48 ü ⼤規模サービスにおけるプロダクトマネージャーの⽴場 他では実現できないビジネスインパクト・やりがい・出会い 全てが相乗効果として膨れ上がっていく ステークホルダーが膨大 （歴史との共存） コミュニケーションと信頼 技術的興味 変化を好む あるべき姿の定義 ビジネス興味
- 57. チャレンジ〜開発環境の検討〜
- 58. これまでのリーン開発体制でチャレンジできなかった課題49 ü 新規プロダクト・新機能開発において、利⽤する基盤が既存リソースのた め、既存の開発環境やプロダクト・開発スケジュールに依存せざるを得な かった 画⾯（密結合） 画⾯（疎結合） これまでの環境 チャレンジしたい環境 ü システムの密結合による開発の限界 ü 利⽤リソースの制限あり ü プログラムの疎結合を⽬指す ü 既存システムからの脱却 API
- 59. じゃらんnet チャレンジ〜開発環境50 ■現在のチャレンジ環境⼀例 ü マルチクラウドによるフェイルオーバー • ヘルスチェックにRoute53を利⽤ ü GCPを利⽤することでIAM設定を容易 ü Kubernetesがデファクト • マネージドサービスのGKEでk8sの運⽤が容易 • スケーラブル（⽴ち上がりのスピード含め） • コンテナ化による切り戻し・デプロイが簡単 • 環境の複製が簡単 Web サーバ API サーバ Amazon Route 53 Amazon S3 Cloud Load Balancing Cloud Load Balancing Container Engine Cloud CDN Cloud Storage ヘルス チェック GCPのLB障害時は S3リソースへ Cloud Datastore カスタマー データ BigQuery アクセスログ データENG 環境 ログ収集 機械学習 API サーバ CI APIリクエスト
- 62. Engineer Designer Analyst Director Client Q A TechLead Frontend Sales Scrum Master 管理・調 整 企画 外部パートナー 開発者 チャレンジ〜開発環境・エンジニア53 事業成⻑のための技術選定は全て現場 ü 様々な観点で興味を持つといった⾊んなことを考えられる エンジニアが必要 ü サービス・プロダクト全体を考えて作れる⼈ ü 事業成⻑に合わせた技術的な成⻑を意識 ü ⾃分たちでKPIの達成を楽しめる⼈ 企画と開発と⼀体となる リンク：https://www.slideshare.net/RecruitLifestyle/ss-72258738 デブサミ2017での事例発表 企画と開発