RLSにおけるプロダクト:プロジェクトマネジメント

RLSにおけるプロダクト/
プロジェクトマネジメン
ト
ネットビジネス本部 Air事業U プロダクト開発G
佐橘一旗

• 2007年 web開発初バイト (11年目)
• 2010年 Web系学生起業と敗北
• 2013年リクルート新卒入社 (5年目)
#未踏ユース’09 #roomdonor.jp #AgileJapan2015 #CSM #Java
#ruby #Python #PHP #JavaScript #FlashLight #妻子持ち #猟友会
所属
自己紹介
佐橘一旗 (Itsuki Sakitsu)
株式会社リクルートライフスタイル
ネットビジネス本部
Air事業ユニット
プロダクト開発グループ
グループマネジャー

プロダクト開発グループ
0円でカンタンに使えるPOSレジアプリ”Airレジ”を中心
とした複数のプロダクトを展開し、店舗経営にまつわる様
々な負を解消する
次世代に向けたRLSのチャレンジ事業
を支えるエンジニア組織の組織長
プランニン
グG
UX デザイ
ンG
プロダクト
開発G

(参考)Airレジを中心とした
複数のプロダクトたち

2013 2014 2015 2016 2017
Engineer
Project Mgmt
Product Mgmt
入社後やってきたこと
E2E test tool開発
入社後はほぼAir関連プロダクトに従事
エンジニアを軸足に、短期プロジェクトの遂行及び
開発プロセス改善(スクラム導入等)に関わる
※スクラム導入に関してはAgileJapan2015にて登壇
xx
大規模スクラム
コード全面
リプレイス
Square
会計freee
Apple
Pay

あなたがエンジニアとして
充実感を持って働くために大
切なものは何ですか？

自分の仕事はどれだけ誰かの役に立てているのか?
≒ プロダクトマネジメントの質
そのために自分の生産性をどれだけ高められる環境か?
≒ プロジェクトマネジメントの質

• 自分の仕事が世の中の役に立っている実感が欲しい
• 試行錯誤の結果が無駄になるのは辛い
• 無駄/面倒(=非生産的)な仕事はしたくない

自分的にどれくらい
満たせているか

≒ プロダクトマネジメントの質
≒ プロジェクトマネジメントの質
… 50%
… 80%

まだまだ試行錯誤中ですが
充実感を高めるためにやってきた取り組み
を紹介します

Agenda
1. RLSにおけるプロジェクトマネジメント
2. RLSにおけるプロダクトマネジメント
3. まとめ

大きな失敗から、学んだ
SIer x Waterfall
スクラム導入
〜大規模化
2013 2014 2015 2016 2017 現在
プロジェクトに合わせた
カスタマイズ

大きな失敗
SIer x Waterfall
スクラム導入
〜大規模化
2013 2014 2015 2016 2017 現在
カスタマイズ
大規模スクラムの失敗から学んだこと
AgileJapan 2015にて登壇

大規模スクラムの失敗から
学んだこと：まとめ
従来のRLSはSIer x Waterfall開発がベース
社員エンジニアの採用強化に後押しされ、
仮説検証のサイクルを効率化するためにスクラムを部分導入

大規模スクラムの失敗から
学んだこと：まとめ
単チーム導入の範囲では成果が出たが、むやみに
全面導入を試みた結果スクラム運営に振り回されるようになり
結果的に生産性が逆に悪化したという話

手段を目的化しない
SIer x Waterfall
2013 2014 2015 2016 2017 現在
カスタマイズ
スクラム導入
〜大規模化

カスタマイズ
Step1. 全てをWhyから始める
Step2. 道具の特性を理解する
Step3. チーム/プロダクトにプロセスをあわせる

1. 全てをWhyから始める
このプロジェクトは何のために？
この中間成果物は何故必要？
この会議の実施目的は？
この技術を使う理由は？

2013 2014 2015 2016 2017
Engineer
Project Mgmt
Product Mgmt
(再掲)入社後の職務遍歴
E2E test tool開発
エンジニアを軸足に、技術系短期プロジェクト
及び開発プロセス改善(スクラム導入等)に主に携わる
xx
大規模スクラム
コード全面
リプレイス

1. 全てをWhyから始める
プロジェクトの背景/目的
短期ピボットを繰り返してきたプロダクトの勝ち筋が定まり、営業販売体制強化を決定
ロジック散在や不要コード残存によるバグ/障害発生率が高まっているので販拡前に足場を整えたい
Do’s
利用廃止機能のコード/テーブル除却
C1カバレッジ 70%達成
Java6 → Java8化 (規模拡大前に実施)
SJIS→UTF-8移行 (販拡後は移行影響大)
Dont’s
リファクタリング (工数余力でのみ実施)
設定画面機能拡充 (一切やらない)
APIレスポンスフォーマットの修正etc
Whyを明らかにすることでスコープを明確化
→ プロジェクト遂行リスクや工期を大きく削減

2. 道具の特性を理解する
アーティファクト特性
Waterfall
- 確認プロセス強化でリスク/属人化排除
- ステークホルダが多い、スコープのトレ
ードオフが効かない場合は特に有効
Agile - 仮説検証の繰り返しに特に有効
StoryPoint見積り
- 納期コミットよりもROI判断や計画立案用
- 見積り大=不明瞭な点が多い=リスク
- 人月に変換するのはバッドプラクティス
Daily Meetup
- 課題の早期検知/対処
- 情報の伝達漏れ回避
基本設計書
- システムの概要の把握
- 運用コストが高い
詳細設計書
- 設計者から実装者への伝達齟齬防止
- より詳細なレベルでのシステム仕様把握
API I/F仕様書
- web/iOS開発者間の認識齟齬防止
改めて使ってきた道具の特性/目的を整理することで、
手段の目的化を回避する

3. チーム/プロダクトに
プロセスをあわせる
アーティファクト特性採用備考
Waterfall
○ - 関連するプロダクトが多岐にわたる場合、全体で
のスコープ/スケジュール認識共有が重要
- 変更の度に全域で再計画コストが発生
Agile - 仮説検証の繰り返しに特に有効 ×
StoryPoint見積り
×
- 納期の頻繁な変更は関連プロダクトのブランチ/
案件戦略に影響するため、要求/要件定義を完全
に終えてから人月で見積りを算出
Daily Meetup
○
- Slack / Jira / Confluenceを活用
- 情報共有目的で実施
基本設計書
○
- 関連プロダクト(=別チーム)のエンジニアからも参
照される可能性を考慮
詳細設計書
△
- 認証周辺など難易度の高い案件では時として具体
的実装まで明らかにする必要あり
API I/F仕様書
○
- 関連プロダクト向けに配布する必要性があるため
- docletを活用してコードから自動生成
プロダクトの性質によっては
時としてWaterfallの方が最適という判断もある

3. チーム/プロダクトに
プロセスをあわせる
アーティファクト特性採用備考
Waterfall
× - プロダクトディスカバリーの過程であり、クライ
アント様とMVPの検証を繰り返していきたいため
Agile - 仮説検証の繰り返しに特に有効 ○
StoryPoint見積り
△
- 納期コミットよりもプロダクトの仮説検証が重要
- 相対見積りは活かすが、最終的に人日換算
- 代わりに大きいタスクは必ず細分化
Daily Meetup
△
- Slack / Jira / Confluenceを活用
- 週2頻度に削減
基本設計書
△
- 重要概念、設計思想、コードから内容の類推が難
しい一部処理のみ作成
詳細設計書
×
- 設計者と実装者の住み分けは行わない
- 速度を求めるのである程度属人化を許容
- コードレビュー等で可読性に投資
API I/F仕様書
○
- I/F認識齟齬がバグの多くを占めるので実施
- docletを活用してコードから自動生成
チームメンバの練度、プロダクトの性質
によっては中間成果物定義を含めてカスタマイズ

より柔軟かつ
生産性の高い組織へ
SIer x Waterfall
スクラム導入
〜大規模化
2013 2014 2015 2016 2017 現在
カスタマイズ

“プロダクト”視点が弱かった
集客/メディア事業ソリューション事業

(従来) 集客/メディア事業
howの磨き込み
課題設定は「行きたいお店が見つかる」「お客さんが来る
」
アプローチは時間とともに変わっていくが、ユーザー課題に
大きな変化は無い
プロジェクトマネジメントが主眼

(今後) ソリューション事業
Why / Whatの発見と優先度判断
ユーザーがどんな課題を抱えているのかを探すところから
深いユーザー行動を理解と洞察が重要であり、
大胆かつ実現可能な仮説の立案、優先度判断、ピボットの繰
り返しが求められる。加えてtoB事業ゆえに自身の経験がユ
ーザー体験に直結しづらい。
プロジェクトマネジメント + プロダクトマネジメントが必
須

新たに始めた取り組み
1. プロダクトディスカバリー
1. 実クライアント様との仮説検証
2. ユーザビリティの磨き込み
1. 実業務体験の機会
2. 定量計測アプローチ

実際クライアント様との
仮説検証
データエンジニアが実際にホットペッパーグルメのクライアント様の協力を得て
Airレジを使ってどうすれば店舗経営に貢献できるかを模索

実際クライアント様との
仮説検証
例えば…アソシエーション分析とパラメタ調整による「おすすめメニュー」の抽出と、
注文時のおすすめ運用の装着などによって店舗経営に貢献できるという仮説を立案、実
証

新たに始めた取り組み
1. プロダクトディスカバリー
1. 実クライアント様との仮説検証
2. ユーザビリティの磨き込み
1. 実際のユーザーになる
2. ユーザビリティを定量で捉える

実際のユーザーになる
実際にAirレジを利用頂いているク
ライアント様の店舗において、RLS
社員であれば誰でも1日従業員とし
て働く事ができる取り組み
機能軸だけで語れない課題を身をも
って体験できる
都内の飲食店2店舗、小売店1店舗
と提携、2017/06から本格始動

ユーザビリティを
定量で捉える
会計画面
描画
会計API通信レシート印字
n秒 m秒 o秒
機能軸だけでは見えない「処理時間」等をアプリから収集
分析基盤に流し込み、定量的にユーザビリティを把握
TreasureData
リアルタイム
ログ送信
S3 RDS
Tableau
蓄積ダンプ work
分析

A社製
B社製
特定プリンタの特定処理が顕著に遅いことを検知→改善
アプリリース後から印字速度が悪化していることを検知→改修
などなど

クライアント様との接点を
活かしながらさらなる進化を！

まとめ
toBプロダクトでもユーザーに寄り添える環境作り
今後はエンジニア出身のプロダクトマネージャーも輩出していきたい
目的に応じた手段を正しく選定できる状態に
生産性向上に貢献できるプロセス構築
今後はプロセスだけでなく、開発環境を含めて更に改善していきたい

どれもメンバの提言から始まった取り組みばかり
文化やプロセスも模索しながら成長を続けている組織

一緒にチャレンジしたい仲間
絶賛募集中！
ご清聴有難うございました。

言葉の定義
プロダクトマネージャーの視点
・ユーザー課題の解決
・技術的実現可能性
・経済性（ビジネスモデル、4P整合性）
プロジェクトマネージャーの視点
・品質（要件の充足と不具合の少なさ）
・開発コスト
・リリーススケジュール
【引用元】
tannnomizuki「プロダクトマネージャーとプロジェクトマネージャーはどう違うのか - 小さなごちそう」
http://tannomizuki.hatenablog.com/entry/2015/08/15/092259 (2017年06月09日)

プロダクトとプロジェクトは
両輪の存在
Sprint 1 Sprint 2 Sprint 3 Sprint 4
プロダクト開発はプロジェクトの繰り返し
脆弱なプロジェクトマネジメント → プロダクトの成長鈍化
脆弱なプロダクトマネジメント → プロジェクトの迷走
プロダクト開発
プロジェクト

RLSにおけるプロダクト:プロジェクトマネジメント

More Related Content

What's hot

Similar to RLSにおけるプロダクト:プロジェクトマネジメント

RLSにおけるプロダクト:プロジェクトマネジメント

Editor's Notes