拝啓、プロダクトオーナー様。
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

拝啓、プロダクトオーナー様。

  • 335 views
Uploaded on

11/15 スタートアップ・リーダーシップ・プログラムにて、事業起業を考えている皆さんに向けてお話した内容を加筆修正して公開しました。

11/15 スタートアップ・リーダーシップ・プログラムにて、事業起業を考えている皆さんに向けてお話した内容を加筆修正して公開しました。
http://startupleadership.jp/

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment

Views

Total Views
335
On Slideshare
333
From Embeds
2
Number of Embeds
1

Actions

Shares
Downloads
2
Comments
0
Likes
4

Embeds 2

https://twitter.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Toshihiro Ichitani All Rights Reserved. 拝啓、 プロダクトオーナー様。 Ichitani Toshihiro 市谷聡啓 サービス開発を進める上で プロダクトオーナーにお願いしたい たった2つのことについて
  • 2. Toshihiro Ichitani All Rights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市谷聡啓 @papanda
  • 3. Toshihiro Ichitani All Rights Reserved. 受託→SIer→サービス→受託→旗揚 関西で組み込み系のプログラマー→(省略)→ プロダクトオーナー(企画者)支援 アジャイル開発プロジェクトマネージャ アジャイル開発コンサルタント ここまでのあらすじ 「リーン開発の現場」 現場コミュニティの運営
  • 4. Toshihiro Ichitani All Rights Reserved. http://guildworks.jp/
  • 5. Toshihiro Ichitani All Rights Reserved.
  • 6. Copyright (c) 2014 Guild Works Inc. 本日のアジェンダ 仮説検証型のサービス開発で 求められるチームモデル 開発チームにおいてPassionateな プロダクトオーナーが果たす役割 どのようにしてチームを ビルディングしていくか
  • 7. Copyright (c) 2014 Guild Works Inc. 仮説検証型のサービス開発とは? リーンスタートアップ… 顧客開発…
  • 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を育てる
  • 18. Toshihiro Ichitani All Rights Reserved. What How Why アクション Whyを実現 する手段 何のためにやる ゴールデンサークル Start With 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でチームを導く
  • 21. Copyright (c) 2014 Guild Works Inc. ただし、Whyを押し付けても 自分事にはならない
  • 22. Copyright (c) 2014 Guild Works Inc. サービス開発が自分事になるためには それぞれがWhyを共感できる必要がある ゆえに、プロダクトオーナーはWhyを語る そして、Whyをチームと育てる
  • 23. Copyright (c) 2014 Guild Works Inc. 本日のアジェンダ 仮説検証型のサービス開発で 求められるチームモデル 開発チームにおいてPassionateな プロダクトオーナーが果たす役割 どのようにしてチームを ビルディングしていくか
  • 24. Copyright (c) 2014 Guild Works Inc. どのようにしてチームを ビルディングしていくか インセプションデッキ ドラッカー風エクササイズ
  • 25. Toshihiro Ichitani All Rights Reserved. インセプションデッキ われわれは なぜここに いるのか エレベーター ピッチ パッケージ デザイン やること やらないこと リスト プロジェクト コミュニティ 技術的な 解決策 夜も眠れない 問題 期間を 見極める トレードオフ スライダー なにが どれだけ 必要か Whyを明らかにする Howを明らかにする
  • 26. Toshihiro Ichitani All Rights Reserved. なぜインセプションデッキ? 「プロジェクトが然るべき方向を  向いているか」 を明らかにする チームメンバーが誰もいないところ で合意したことを前提にしているか ら、プロジェクトがダメになる アジャイルサムライP44
  • 27. Toshihiro Ichitani All Rights Reserved. 関係者同席のデッキ作り ワークショップ 10個のタフクエス チョン PJを始める前 に関係者の認識をあ わせる PJの状況や背景につ いてチームで話しあっ ておくことで、チーム は状況に応じた適切な 判断が下せる。 デッキのゴールデンサークル なぜインセプションデッキを作るのか?
  • 28. Toshihiro Ichitani All Rights Reserved.
  • 29. Copyright (c) 2014 Guild Works Inc. ドラッカー風エクササイズ 自分は何が得意なのか? 自分はどうやって貢献するつもりなのか? 自分が大切に思う価値は何か? チームメンバーは自分にどんな成果を 期待してると思うか? 自分と他のメンバーの間で期待のGapを露わにする
  • 30. Copyright (c) 2014 Guild Works Inc. まとめ
  • 31. Copyright (c) 2014 Guild Works Inc. What How Why つくるサービスが 自分事になっていること リーダーはWhyを語る Whyをチームと共に育てる インセプションデッキ ドラッカー風エクササイズ サービス開発チームに 必要なゴールデン・サークル