More Related Content
Similar to RLSにおけるプロダクト:プロジェクトマネジメント
Similar to RLSにおけるプロダクト:プロジェクトマネジメント (20)
RLSにおけるプロダクト:プロジェクトマネジメント
- 2. • 2007年 web開発 初バイト (11年目)
• 2010年 Web系学生起業と敗北
• 2013年 リクルート新卒入社 (5年目)
#未踏ユース’09 #roomdonor.jp #AgileJapan2015 #CSM #Java
#ruby #Python #PHP #JavaScript #FlashLight #妻子持ち #猟友会
所属
自己紹介
佐橘 一旗 (Itsuki Sakitsu)
株式会社リクルートライフスタイル
ネットビジネス本部
Air事業ユニット
プロダクト開発グループ
グループマネジャー
- 5. 2013 2014 2015 2016 2017
Engineer
Project Mgmt
Product Mgmt
入社後やってきたこと
E2E test tool開発
入社後はほぼAir関連プロダクトに従事
エンジニアを軸足に、短期プロジェクトの遂行及び
開発プロセス改善(スクラム導入等)に関わる
※スクラム導入に関してはAgileJapan2015にて登壇
xx
大規模スクラム
コード全面
リプレイス
Square
会計freee
Apple
Pay
- 23. 2013 2014 2015 2016 2017
Engineer
Project Mgmt
Product Mgmt
(再掲)入社後の職務遍歴
E2E test tool開発
エンジニアを軸足に、技術系短期プロジェクト
及び開発プロセス改善(スクラム導入等)に主に携わる
xx
大規模スクラム
コード全面
リプレイス
- 26. 2. 道具の特性を理解する
アーティファクト 特性
Waterfall
- 確認プロセス強化でリスク/属人化排除
- ステークホルダが多い、スコープのトレ
ードオフが効かない場合は特に有効
Agile - 仮説検証の繰り返しに特に有効
StoryPoint見積り
- 納期コミットよりもROI判断や計画立案用
- 見積り大=不明瞭な点が多い=リスク
- 人月に変換するのはバッドプラクティス
Daily Meetup
- 課題の早期検知/対処
- 情報の伝達漏れ回避
基本設計書
- システムの概要の把握
- 運用コストが高い
詳細設計書
- 設計者から実装者への伝達齟齬防止
- より詳細なレベルでのシステム仕様把握
- 運用コストが高い
API I/F仕様書
- web/iOS開発者間の認識齟齬防止
- 運用コストが高い
改めて使ってきた道具の特性/目的を整理することで、
手段の目的化を回避する
- 28. 3. チーム/プロダクトに
プロセスをあわせる
アーティファクト 特性 採用 備考
Waterfall
- 確認プロセス強化でリスク/属人化排除
- ステークホルダが多い、スコープのトレ
ードオフが効かない場合は特に有効
○ - 関連するプロダクトが多岐にわたる場合、全体で
のスコープ/スケジュール認識共有が重要
- 変更の度に全域で再計画コストが発生
Agile - 仮説検証の繰り返しに特に有効 ×
StoryPoint見積り
- 納期コミットよりもROI判断や計画立案用
- 見積り大=不明瞭な点が多い=リスク
- 人月に変換するのはバッドプラクティス
×
- 納期の頻繁な変更は関連プロダクトのブランチ/
案件戦略に影響するため、要求/要件定義を完全
に終えてから人月で見積りを算出
Daily Meetup
- 課題の早期検知/対処
- 情報の伝達漏れ回避
○
- Slack / Jira / Confluenceを活用
- 情報共有目的で実施
基本設計書
- システムの概要の把握
- 運用コストが高い
○
- 関連プロダクト(=別チーム)のエンジニアからも参
照される可能性を考慮
詳細設計書
- 設計者から実装者への伝達齟齬防止
- より詳細なレベルでのシステム仕様把握
- 運用コストが高い
△
- 認証周辺など難易度の高い案件では時として具体
的実装まで明らかにする必要あり
API I/F仕様書
- web/iOS開発者間の認識齟齬防止
- 運用コストが高い
○
- 関連プロダクト向けに配布する必要性があるため
- docletを活用してコードから自動生成
プロダクトの性質によっては
時としてWaterfallの方が最適という判断もある
- 29. 3. チーム/プロダクトに
プロセスをあわせる
アーティファクト 特性 採用 備考
Waterfall
- 確認プロセス強化でリスク/属人化排除
- ステークホルダが多い、スコープのトレ
ードオフが効かない場合は特に有効
× - プロダクトディスカバリーの過程であり、クライ
アント様とMVPの検証を繰り返していきたいため
Agile - 仮説検証の繰り返しに特に有効 ○
StoryPoint見積り
- 納期コミットよりもROI判断や計画立案用
- 見積り大=不明瞭な点が多い=リスク
- 人月に変換するのはバッドプラクティス
△
- 納期コミットよりもプロダクトの仮説検証が重要
- 相対見積りは活かすが、最終的に人日換算
- 代わりに大きいタスクは必ず細分化
Daily Meetup
- 課題の早期検知/対処
- 情報の伝達漏れ回避
△
- Slack / Jira / Confluenceを活用
- 週2頻度に削減
基本設計書
- システムの概要の把握
- 運用コストが高い
△
- 重要概念、設計思想、コードから内容の類推が難
しい一部処理のみ作成
詳細設計書
- 設計者から実装者への伝達齟齬防止
- より詳細なレベルでのシステム仕様把握
- 運用コストが高い
×
- 設計者と実装者の住み分けは行わない
- 速度を求めるのである程度属人化を許容
- コードレビュー等で可読性に投資
API I/F仕様書
- web/iOS開発者間の認識齟齬防止
- 運用コストが高い
○
- I/F認識齟齬がバグの多くを占めるので実施
- docletを活用してコードから自動生成
チームメンバの練度、プロダクトの性質
によっては中間成果物定義を含めてカスタマイズ
- 34. (今後) ソリューション事業
Why / Whatの発見と優先度判断
ユーザーがどんな課題を抱えているのかを探すところから
深いユーザー行動を理解と洞察が重要であり、
大胆かつ実現可能な仮説の立案、優先度判断、ピボットの繰
り返しが求められる。加えてtoB事業ゆえに自身の経験がユ
ーザー体験に直結しづらい。
プロジェクトマネジメント + プロダクトマネジメントが必
須
Editor's Notes
- RLSにおけるプロダクト/プロジェクトマネジメントというタイトルで私
Air事業Uの佐橘から話をさせていただきます。
着てる人は大半がエンジニアだと思っている。
→どれくらい？それ以外の人はどういう人？
聞きたいと思ってた話と違うという方は申し訳ありません。。。
折角着ていただいた皆さんには満足して帰っていただきたいので、
ビールで腹を満たすなり、懇親会パートで一緒に雑談に興じられれば幸いです。
- 2006年が最初の開発経験
PHP/flashLightでガラケー向けのポケモンgoもどきを作った
意識が高い学生だったので一回学生起業をして、案の定敗北したりしています。
今は新卒５年目
- リクルートは従来「集客」に特化してきた。
Air事業は、AirレジというPOSレジアプリを中心に、集客以外にも店舗経営にまつわる様々な負を解消していこうという事業
- 図が汚くて申し訳ないが
レジの他にも予約台帳や顧客管理/CRM機能などお店の経営にまつわるあらゆる負を解消し、
それを通じて集まるデータを活かして更なる価値を提供しようとしている。
- 入社後はほぼAirプロダクトにいます。
エンジニアを軸足に、コードも書いてきたがプロジェクト遂行やプロセス改善に関わる仕事を多くやってきました。
- 優秀な仲間、フリーフード、経験値が積めること
- 個人的には
- 「何のために働いているのか」
人の役に立っていたい
- 一度大きく失敗をして改善した
- 全然エンジニア社員がおらず、社員は企画、開発はSIerさんにお願い。
社員エンジニアの採用を強化するにつれて、もっと仮説検証のサイクルを変えられるんじゃないかというのでスクラムを部分してみた
- スクラムチーム間でどうやってVelocityを揃えるのか？
チームレベル
全体レベル
リリーストレイン管理
ブランチ管理
詳しくはSlideShareに挙がってるのでご参照ください
- 何を学んだか。手段を目的化しないこと。
型にはめるのでなく、型を使いこなす事を最近は意識しています
- ３つのことを大事にしている
Whyから始める、道具の特性を理解する、チーム/プロダクトに合わせる。
- サイモン・シネック
手段を目的化しないために。全てにおいてWhyから始めている。
- まさに大規模スクラムで失敗した次に取り組んだプロジェクト
AirWAIT。銀行とかドコモショップにある発券機わかります？
あれを模した待ち行列の順番管理アプリで、順番管理機能が基本
・SMSやメールを使った呼び出し機能があるのでお客さんは待ち時間中周囲を散策できたり
・待ち行列や、窓口当たりの処理時間等のログデータが貯まるので分析ができるようになるプロダクト
- プロジェクトを始めるにあたっても、Whyを強く意識した。
プロトタイプに近いコードで２年ぐらい色んな店舗様に導入いただいて試行錯誤をしていて、やっと売り筋がたったタイミング。
「技術的負債解消プロジェクト」
→ やりたいことはたくさんでてくる。細部のリファクタリング、
- 同じような話を開発プロセスにも適用していて
- 今まで使ってきたプロセス、テクニック、中間成果物 全部をあらためて整理してみる
- そのうえでチーム/プロダクトに合わせて考えると
- たとえば AirID 共通認証基盤のようなプロダクト。
複数のサイトが刺しに来る
- はい
- 従来リクルートが得意としてきた事業は「お店とお客さんのマッチング」
フリーペーパーを配る、TV CMを打つ、SEO最適化施策、キャンペーン実施。
面白いのは表出できる面があればなんでも表出する。Apple TV Appまでリリースする。
お店に対しては営業が足を使い、掲載してもらう
- 今後のリクルートは、今までと全く違う戦い方をしていかなければならない
集客メディアから一歩足を踏み出して、「何がユーザーにとって課題なのか」をみすえなければならない。
また「」
- 掃除その他お店の開店準備
実際の接客でおすすめ商品を聞かれて答えてみるなど
ヒアリングだけではわからないことを知る
- 検品環境にも同じ仕組みを導入して、リリース前にも検知できるように
- はい
- Bizreachの丹野さんblogから引用。分かりやすくて好き。
