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

113 Views

November 15, 14

スライド概要

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

profile-image

白と黒の魅惑

シェア

埋め込む »CMSなどでJSが使えない場合

各ページのテキスト
1.

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

2.

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

3.

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

4.

http://guildworks.jp/ Toshihiro Ichitani All Rights Reserved.

5.

Toshihiro Ichitani All Rights Reserved.

6.

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

7.

仮説検証型のサービス開発とは? リーンスタートアップ… 顧客開発… Copyright (c) 2014 Guild Works Inc.

8.

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

9.

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

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

13.

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

14.

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

15.

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

16.

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

17.

Passionateな プロダクトオーナーが果たす役割とは? 強いリーダー… サーヴァントリーダー… Whyでチームを導く チームと共にWhyを育てる Copyright (c) 2014 Guild Works Inc.

18.

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

19.

Why チームメンバー ??? How What Whyが見えない中でHowやWhatを いくら考えても、実行してもムダ Copyright (c) 2014 Guild Works Inc.

20.

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

21.

ただし、Whyを押し付けても 自分事にはならない Copyright (c) 2014 Guild Works Inc.

22.

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

23.

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

24.

どのようにしてチームを ビルディングしていくか インセプションデッキ ドラッカー風エクササイズ Copyright (c) 2014 Guild Works Inc.

25.

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

26.

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

27.

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

28.

Toshihiro Ichitani All Rights Reserved.

29.

ドラッカー風エクササイズ 自分は何が得意なのか? 自分はどうやって貢献するつもりなのか? 自分が大切に思う価値は何か? チームメンバーは自分にどんな成果を 期待してると思うか? 自分と他のメンバーの間で期待のGapを露わにする Copyright (c) 2014 Guild Works Inc.

30.

まとめ Copyright (c) 2014 Guild Works Inc.

31.

サービス開発チームに 必要なゴールデン・サークル つくるサービスが 自分事になっていること Why リーダーはWhyを語る Whyをチームと共に育てる How What インセプションデッキ ドラッカー風エクササイズ Copyright (c) 2014 Guild Works Inc.