More Related Content Similar to 拝啓、プロダクトオーナー様。 (20) More from toshihiro ichitani (20) 拝啓、プロダクトオーナー様。1. Toshihiro Ichitani All Rights Reserved.
拝啓、
プロダクトオーナー様。
Ichitani Toshihiro
市谷聡啓
サービス開発を進める上で
プロダクトオーナーにお願いしたい
たった2つのことについて
3. Toshihiro Ichitani All Rights Reserved.
受託→SIer→サービス→受託→旗揚
関西で組み込み系のプログラマー→(省略)→
プロダクトオーナー(企画者)支援
アジャイル開発プロジェクトマネージャ
アジャイル開発コンサルタント
ここまでのあらすじ
「リーン開発の現場」
現場コミュニティの運営
6. Copyright (c) 2014 Guild Works Inc.
本日のアジェンダ
仮説検証型のサービス開発で
求められるチームモデル
開発チームにおいてPassionateな
プロダクトオーナーが果たす役割
どのようにしてチームを
ビルディングしていくか
8. Copyright (c) 2014 Guild Works Inc.
仮説検証型のサービス開発
8
根底にあるのは、
「正しいものを探し」「正しくつくる」こと
「間違ったもの(=ニーズや目的に沿わないもの)」
をどれだけ正しく作りこんでも、ムダ
9. Copyright (c) 2014 Guild Works Inc.
仮説検証型の開発が求めること
仮説検証を実施している=サービスに
関する意思決定がいつ起きてもおかしくない
①期待の可視化
②着地点を常に追う
③先読みする
④目線をあわせる
⑤期待を現実にあわせる
⑥期待に早めに近づいておく
⑦幅で合意、深さで調整
⑧ビジネスと開発一方に偏らない判断
参考
GuildWorks Blog「顧客開発に適応するためのプロダクト開発8つの原則」
http://blog.guildworks.jp/2014/09/29/product_dev_for_customer_dev/
10. Copyright (c) 2014 Guild Works Inc.
仮説検証に忠実であればあるほど開発は
不安定になるジレンマ
開発チームに求められる
ハードルは高い!
11. Copyright (c) 2014 Guild Works Inc.
サービス開発に求められるロール
・プロダクトのオーナーとしての判断
・仮説検証プロセスの企てと遂行
・ビジネスモデルの設計と組み立て
:
・プロトタイプを素早く作る
・プロダクトコード、テストコードを書く
・インフラの設計、構築
・開発プロセスのデザイン
:
・ユーザーエクスペリエンスのためのデザイン
・ユーザーインターフェースのデザイン
・フロントプログラミング
:
プロダクトオーナー
デザイナー
プログラマー
12. Copyright (c) 2014 Guild Works Inc.
つまりは、全部入り!
1人のメンバーでカバーできる
範囲には限界がある
範囲をカバーするための
人数が多くなる
人数が多い=コミュニケーションコストが高い
仮説検証型なサービス開発に向いていない
どんなロール(=キーワード)が必要か?よりも
どんなスキルが必要か?で考える
13. Copyright (c) 2014 Guild Works Inc.
プロトタイプを素早くつくる
スキルの水平分散
プロダクトコードを書く
テストコードを書く
インフラの設計、構築
開発プロセスのデザイン
プロトタイプを素早くつくる
プロダクトコードを書く
テストする
インフラの設計、構築
開発プロセスのデザイン
スキルの状況分散
プロトタイプを素早くつくる
プロダクトコードを書く
テストコードを書く
インフラの設計、構築
開発プロセスのデザイン
プロトタイプを
素早くつくる
プロトタイプを
素早くつくる
インフラの設計
構築
プロトタイプを
素早くつくる
インフラの設計
構築
プロダクト
コードを書く
プロダクト
コードを書く
開発プロセスの
デザイン
MVP作り
α公開
β開発
2つの分散戦略
14. Copyright (c) 2014 Guild Works Inc.
プロダクトもチームも実用最小限から
仮説検証に必要なプロダクト
実用最小限のプロダクト
実用最小限のプロダクトを作るのに必要な最小限のチーム
チームのスケール(水平分散)は仮説が検証されてから
プロトタイプを
素早くつくる
プロトタイプを
素早くつくる
インフラの設計
構築
プロトタイプを
素早くつくる
インフラの設計
構築
プロダクト
コードを書く
プロダクト
コードを書く
開発プロセスの
デザイン
MVP作り
α公開
β開発
15. Copyright (c) 2014 Guild Works Inc.
コミュニケーションコストを最小限に押さえ
かつ、より良いサービスを求める姿勢
=「自分事として捉えられる」こと
チームメンバーに求められること
スキル…
経験…
チームがサービス開発を自分事として
捉えられるようになるためには?
16. Copyright (c) 2014 Guild Works Inc.
本日のアジェンダ
仮説検証型のサービス開発で
求められるチームモデル
開発チームにおいてPassionateな
プロダクトオーナーが果たす役割
どのようにしてチームを
ビルディングしていくか
17. Copyright (c) 2014 Guild Works Inc.
Passionateな
プロダクトオーナーが果たす役割とは?
強いリーダー…
サーヴァントリーダー…
Whyでチームを導く
チームと共にWhyを育てる
19. Copyright (c) 2014 Guild Works Inc.
What
How
Why チームメンバー
???
Whyが見えない中でHowやWhatを
いくら考えても、実行してもムダ
20. Copyright (c) 2014 Guild Works Inc.
What
How
Why
プロダクトオーナー
チームメンバー
中心となってWhyを考える
Whyを実現するためのHow
をチームで考える
具体的なアクション(What)を
プロダクトオーナーとチームが
一体となって実行していく
Whyでチームを導く
22. Copyright (c) 2014 Guild Works Inc.
サービス開発が自分事になるためには
それぞれがWhyを共感できる必要がある
ゆえに、プロダクトオーナーはWhyを語る
そして、Whyをチームと育てる
23. Copyright (c) 2014 Guild Works Inc.
本日のアジェンダ
仮説検証型のサービス開発で
求められるチームモデル
開発チームにおいてPassionateな
プロダクトオーナーが果たす役割
どのようにしてチームを
ビルディングしていくか
25. Toshihiro Ichitani All Rights Reserved.
インセプションデッキ
われわれは
なぜここに
いるのか
エレベーター
ピッチ
パッケージ
デザイン
やること
やらないこと
リスト
プロジェクト
コミュニティ
技術的な
解決策
夜も眠れない
問題
期間を
見極める
トレードオフ
スライダー
なにが
どれだけ
必要か
Whyを明らかにする Howを明らかにする
26. Toshihiro Ichitani All Rights Reserved.
なぜインセプションデッキ?
「プロジェクトが然るべき方向を
向いているか」
を明らかにする
チームメンバーが誰もいないところ
で合意したことを前提にしているか
ら、プロジェクトがダメになる
アジャイルサムライP44
27. Toshihiro Ichitani All Rights Reserved.
関係者同席のデッキ作り
ワークショップ
10個のタフクエス
チョン
PJを始める前
に関係者の認識をあ
わせる
PJの状況や背景につ
いてチームで話しあっ
ておくことで、チーム
は状況に応じた適切な
判断が下せる。
デッキのゴールデンサークル
なぜインセプションデッキを作るのか?
29. Copyright (c) 2014 Guild Works Inc.
ドラッカー風エクササイズ
自分は何が得意なのか?
自分はどうやって貢献するつもりなのか?
自分が大切に思う価値は何か?
チームメンバーは自分にどんな成果を
期待してると思うか?
自分と他のメンバーの間で期待のGapを露わにする
31. Copyright (c) 2014 Guild Works Inc.
What
How
Why
つくるサービスが
自分事になっていること
リーダーはWhyを語る
Whyをチームと共に育てる
インセプションデッキ
ドラッカー風エクササイズ
サービス開発チームに
必要なゴールデン・サークル