拝啓、プロダクトオーナー様。

Toshihiro Ichitani All Rights Reserved.
拝啓、
プロダクトオーナー様。
Ichitani Toshihiro
市谷聡啓
サービス開発を進める上で
プロダクトオーナーにお願いしたい
たった２つのことについて

http://about.me/papanda0806
Ichitani Toshihiro
市谷聡啓
@papanda

受託→SIer→サービス→受託→旗揚
関西で組み込み系のプログラマー→(省略)→
プロダクトオーナー(企画者)支援
アジャイル開発プロジェクトマネージャ
アジャイル開発コンサルタント
ここまでのあらすじ
「リーン開発の現場」
現場コミュニティの運営

http://guildworks.jp/

Copyright (c) 2014 Guild Works Inc.
本日のアジェンダ
仮説検証型のサービス開発で
求められるチームモデル
開発チームにおいてPassionateな
プロダクトオーナーが果たす役割
どのようにしてチームを
ビルディングしていくか

仮説検証型のサービス開発とは？
リーンスタートアップ…
顧客開発…

仮説検証型のサービス開発
8
根底にあるのは、
「正しいものを探し」「正しくつくる」こと
「間違ったもの(=ニーズや目的に沿わないもの)」
をどれだけ正しく作りこんでも、ムダ

仮説検証型の開発が求めること
仮説検証を実施している=サービスに
関する意思決定がいつ起きてもおかしくない
①期待の可視化
②着地点を常に追う
③先読みする
④目線をあわせる
⑤期待を現実にあわせる
⑥期待に早めに近づいておく
⑦幅で合意、深さで調整
⑧ビジネスと開発一方に偏らない判断
参考
GuildWorks Blog「顧客開発に適応するためのプロダクト開発8つの原則」
http://blog.guildworks.jp/2014/09/29/product_dev_for_customer_dev/

仮説検証に忠実であればあるほど開発は
不安定になるジレンマ
開発チームに求められる
ハードルは高い！

サービス開発に求められるロール
・プロダクトのオーナーとしての判断
・仮説検証プロセスの企てと遂行
・ビジネスモデルの設計と組み立て
：
・プロトタイプを素早く作る
・プロダクトコード、テストコードを書く
・インフラの設計、構築
・開発プロセスのデザイン
：
・ユーザーエクスペリエンスのためのデザイン
・ユーザーインターフェースのデザイン
・フロントプログラミング
：
プロダクトオーナー
デザイナー
プログラマー

つまりは、全部入り！
１人のメンバーでカバーできる
範囲には限界がある
範囲をカバーするための
人数が多くなる
人数が多い=コミュニケーションコストが高い
仮説検証型なサービス開発に向いていない
どんなロール(＝キーワード)が必要か？よりも
どんなスキルが必要か？で考える

プロトタイプを素早くつくる
スキルの水平分散
プロダクトコードを書く
テストコードを書く
インフラの設計、構築
開発プロセスのデザイン
テストする
スキルの状況分散
テストコードを書く
プロトタイプを
素早くつくる
素早くつくる
インフラの設計
構築
素早くつくる
構築
プロダクト
コードを書く
プロダクト
コードを書く
開発プロセスの
デザイン
MVP作り
α公開
β開発
２つの分散戦略

プロダクトもチームも実用最小限から
仮説検証に必要なプロダクト
実用最小限のプロダクト
実用最小限のプロダクトを作るのに必要な最小限のチーム
チームのスケール(水平分散)は仮説が検証されてから
素早くつくる
素早くつくる
構築
素早くつくる
構築
プロダクト
コードを書く
プロダクト
コードを書く
開発プロセスの
デザイン
MVP作り
α公開
β開発

コミュニケーションコストを最小限に押さえ
かつ、より良いサービスを求める姿勢
=「自分事として捉えられる」こと
チームメンバーに求められること
スキル…
経験…
チームがサービス開発を自分事として
捉えられるようになるためには？

Passionateな
プロダクトオーナーが果たす役割とは？
強いリーダー…
サーヴァントリーダー…
Whyでチームを導く
チームと共にWhyを育てる

What
How
Why
アクション
Whyを実現
する手段
何のためにやる
ゴールデンサークル
Start With Why

What
How
Why チームメンバー
？？？
Whyが見えない中でHowやWhatを
いくら考えても、実行してもムダ

What
How
Why
プロダクトオーナー
チームメンバー
中心となってWhyを考える
Whyを実現するためのHow
をチームで考える
具体的なアクション(What)を
プロダクトオーナーとチームが
一体となって実行していく
Whyでチームを導く

ただし、Whyを押し付けても
自分事にはならない

サービス開発が自分事になるためには
それぞれがWhyを共感できる必要がある
ゆえに、プロダクトオーナーはWhyを語る
そして、Whyをチームと育てる

どのようにしてチームを
ビルディングしていくか
インセプションデッキ
ドラッカー風エクササイズ

われわれは
なぜここに
いるのか
エレベーター
ピッチ
パッケージ
デザイン
やること
やらないこと
リスト
プロジェクト
コミュニティ
技術的な
解決策
夜も眠れない
問題
期間を
見極める
トレードオフ
スライダー
なにが
どれだけ
必要か
Whyを明らかにする Howを明らかにする

なぜインセプションデッキ？
「プロジェクトが然るべき方向を
向いているか」
を明らかにする
チームメンバーが誰もいないところ
で合意したことを前提にしているか
ら、プロジェクトがダメになる
アジャイルサムライP44

関係者同席のデッキ作り
ワークショップ
10個のタフクエス
チョン
PJを始める前
に関係者の認識をあ
わせる
PJの状況や背景につ
いてチームで話しあっ
ておくことで、チーム
は状況に応じた適切な
判断が下せる。
デッキのゴールデンサークル
なぜインセプションデッキを作るのか？

自分は何が得意なのか？
自分はどうやって貢献するつもりなのか？
自分が大切に思う価値は何か？
チームメンバーは自分にどんな成果を
期待してると思うか？
自分と他のメンバーの間で期待のGapを露わにする

まとめ

What
How
Why
つくるサービスが
自分事になっていること
リーダーはWhyを語る
Whyをチームと共に育てる
サービス開発チームに
必要なゴールデン・サークル

拝啓、プロダクトオーナー様。

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 拝啓、プロダクトオーナー様。

Similaire à 拝啓、プロダクトオーナー様。 (20)

Plus de toshihiro ichitani

Plus de toshihiro ichitani (20)

拝啓、プロダクトオーナー様。