Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Product
Search
Yasunobu Kawaguchi
PRO
June 14, 2021
Technology
210
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Product
Yasunobu Kawaguchi
PRO
June 14, 2021
More Decks by Yasunobu Kawaguchi
See All by Yasunobu Kawaguchi
What the customer really needed
kawaguti
PRO
3
240
AI de Idea
kawaguti
PRO
2
140
Scalling up Excellence and Friction
kawaguti
PRO
3
220
OKRの本質 / Scrum Fest Osaka 2026
kawaguti
PRO
7
5.3k
Project Based Learning at TUT
kawaguti
PRO
1
94
Zoom2Youtube.Claude
kawaguti
PRO
4
770
アジャイルな経理と Claude Code と経営の未来
kawaguti
PRO
3
330
AIエージェントが教えてくれたプロダクトオーナーシップの本質
kawaguti
PRO
1
470
Claude Code x Accounting
kawaguti
PRO
2
470
Other Decks in Technology
See All in Technology
[2026 Oracle Technical Deep Dive] オンプレミスDBのCloud移行アプローチ:移行計画に基づくメソッドとツールの選択 (2026年9月17日開催)
oracle4engineer
PRO
0
120
生成AIと進める探索的データ分析(2026.10.03 第122回Tokyo.R勉強会)
tatamiya
2
1.3k
[2026 Oracle Technical Deep Dive] OCI AI Resilience -OCIのセキュリティ対策機能をきちんと使いこなす- (2026年9月17日開催)
oracle4engineer
PRO
0
100
freeeらしさをAIとともに作る / Creating the freee Experience with AI
ymrl
0
150
高負荷プロダクション環境におけるAWS Lambdaのリアル 〜スケールとコストを左右する実行ライフサイクルの技術仕様〜
maimyyym
2
860
メルカリにおけるAI時代の高速プロトタイピング基盤「Arca」
ryotarai
18
14k
Datadog の学び方 - あるいは、オブザーバビリティを学ぶとは何か
mananyuki
0
130
Deep Data Security 機能解説
oracle4engineer
PRO
2
650
OpenClawでAzure DevOpsのWiki更新を自動化する - クラウドAIだけでは届かない場所へ
yutakaosada
0
150
個別開発で終わらせない。 現場の課題をプロダクトの強さに変える StockmarkのFDE
ktkrhr
0
560
Databricksメトリクスビューはじめてのもくもく会
taka_aki
0
180
Incremental HTTP
kazuho
5
2k
Featured
See All Featured
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
290
First, design no harm
axbom
PRO
2
1.3k
Accessibility Awareness
sabderemane
1
230
Raft: Consensus for Rubyists
vanstee
142
7.7k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.4k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
69
66k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
12k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
63
46k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.8k
How to train your dragon (web standard)
notwaldorf
97
6.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
35
2.9k
Transcript
プロダクトを作ろう
二枚のピザのチーム
3 アマゾンの初期の頃、ジェフ・ベゾスは「すべての社内チームは、ピザ2枚 で食べられるくらいに小さくすべきだ」というルールを制定しました。目標 はケータリング代を削減することではありませんでした。それは、Amazon が行うほとんどすべてのことと同じように、効率性とスケーラビリティという 2つの目的に焦点を当てたものでした。前者は明らかです。小規模なチー ムであれば、スケジュール管理や最新情報の提供に費やす時間が減り、や るべきことに多くの時間を割くことができます。しかし、Amazonにとって本 当に重要なのは後者です。 https://www.theguardian.com/technology/2018/apr/24/the-two-pizza-rule-and-
the-secret-of-amazons-success 多くの小さなチームを持つというこ とは、大きな目標を達成するために は、チーム全員が協力して仕事がで き、会社の共通のリソースにアクセ スできる必要があるということです。
アギレルゴコンサルティング株式会社シニアアジャイルコーチ 一般社団法人スクラムギャザリング東京実行委員会代表理事 スクラムフェス大阪、三河、札幌実行委員 一般社団法人DevOpsDays Tokyo 代表理事 品川アジャイル 今期の推しは 「Vivy」 「86」
「ゴジラSP」 ハマってい るものは Fortnite 温かいソバ の存在が許 せない
ビジョン
ビジョン チームが効果的に機能するためには、 メンバー全員が同じ方向を向いていなければなりません。 未来は本質的にわからないものです。長い時間をかけて最終的 な結果や計画にコミットすることは、危険を伴います。考慮すべ き外力が多すぎるのです。しかし、チームが結束してパフォーマ ンスを発揮するためには、目標を共有することが必要です。 したがって: この新製品にかける情熱を体現している人がプロダクトオー ナーとなり、その周りにいるステークホルダーや将来の同僚候
補が集まって、ビジョンを明確にし、一緒に定義し、洗練させて いきます。 https://sites.google.com/a/scrumplop.org/published-patterns/value- stream/vision DeepLにて機械翻訳 Scrum Patterns : Vision
どんなものでもそうだと思うんですけど、 なにかをつくるときって、 「あちらを立てればこちらが立たず」 という問題がつねにあるわけです。 だから、なにかのことに対して、 「こうしたらよくできる」 「こうしたら悪くなる」 という選択があるわけですが、 現実になにか商品をつくるときには、 「ひとつだけ困ったことがある」という
恵まれた状態になることなんてまずなくて、 あちこちに困ったことがいくつもあるんです。
で、ゲームの話に戻っていうと、多くの場合、 おもしろさが足りなくて悩むわけです。 当然ネタがたくさん仕込まれてるほど、 おもしろいわけだし、人は満足してくれる。 でも一方で、つくるのに割り当てられる 人材の量や時間は有限です。 有限の中で「多いほどいい」って言われたって、 解決できないわけですよね。
でも、ときどき、たったひとつのことをすると、 あっちもよくなって、こっちもよくなって、 さらに予想もしなかった問題まで解決する、 というときがあるんですよ。 そういう「ひとつのこと」を、 宮本さんは「ないか、ないか」って いつも考えてるんです。 ものすごくしつこく、延々と。
そうなんです。 ひとつ思いついたことによって、 これがうまくいく、あれもうまくいく‥‥。 それが「いいアイデア」であって、 そういうものを見つけることこそが、 全体を前進させ、ゴールへ近づけていく。 ディレクターと呼ばれる人の仕事は、 それを見つけることなんだって 宮本さんは考えているんですね。
1. 目的は、共通のゴールに向かって チームが仕事できるようにすること 2. 利用者にとっての問題を観察し、 実験を繰り返しながら、 一つピースがはまれば解決する アイデア(引き出し)を多く持っておく。 3. 複数の問題が一つのピースで解決する、
もしくは問題の連鎖が解けるようなアイデア を発見する。 4. 実際に作ってみて、フィードバックを受ける
体験に根ざす
https://www.youtube.com/watch?v=s-zUWCQkUa4
https://www.youtube.com/watch?v=s-zUWCQkUa4 一つは、本田宗一郎が 前進全霊で ライダーに共感している 写真なんです。
https://www.honda.co.uk/engineroom/ bikes/60-years-of-honda-racing/ 一つは、本田宗一郎が 前進全霊で ライダーに共感している 写真なんです。
https://www.youtube.com/watch?v=s-zUWCQkUa4 徹底的に目線を合わせ て暗黙知を対話の中で 形式知に変換するわけ です。
徹底的に目線を合わせ て暗黙知を対話の中で 形式知に変換するわけ です。
現実の体験を 洗い出してみよう Pain(つらい) Gain(ありがたい) ポイントを探そう
https://www.ted.com/talks/derek_sivers_how_to_start_a_movement/
肝心なのは 自分ではなく 運動だということです https://www.ted.com/talks/ derek_sivers_how_to_start_a_movement/
最大の教訓は リーダーシップが 過大評価されて いるということです https://www.ted.com/talks/ derek_sivers_how_to_start_a_movement/
一人のバカを リーダーに変えたのは 最初のフォロワー だったのです https://www.ted.com/talks/ derek_sivers_how_to_start_a_movement/
23
未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan
Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (慣用句?ニコラス・ネグロポンテ→石井さん) 学際っていう場合、多くの場合、例えば技術系の人がアート系の人と協力し合って、コラボレートすることだと 思っている方がいます。それはどういう仮定を含んでいるかというと、アーティストは、ハンダ付けしない、電気 工学わからなくていい、C++のLanguageが書けなくていい。一方、技術者は、アートの本質的なConcept とかTheoryに貢献することを期待されていない。 これはわれわれにとって本当のコラボレーションだと思っていません。すなわち各人が、各研究者も教授も、 アーティストでありデザイナーでありサイエンティストでありエンジニアであり、なおかつ教授の場合ビジネス マンでもなきゃいけない。一人の人間がすべてでなきゃいけない。すなわち、ひとつのラベルを貼って、レッテ ルを貼って、あなたは技術者、あなたはCognitive Science(認知科学)、あなたはSociology、といった時 代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう終 わっている。もちろんすべての学問でNo.1にはなれませんけども、それぞれの言語をfluentに話し、深く尊 敬し、そういうチームをまとめられるリーダーでないと、これからやっていけない、というふうに思います。 それがわれわれの学際の違いです。(石井裕さん)
未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan
Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (慣用句?ニコラス・ネグロポンテ→石井さん) 学際っていう場合、多くの場合、例えば技術系の人がアート系の人と協力し合って、コラボレートすることだと 思っている方がいます。それはどういう仮定を含んでいるかというと、アーティストは、ハンダ付けしない、電気 工学わからなくていい、C++のLanguageが書けなくていい。一方、技術者は、アートの本質的なConcept とかTheoryに貢献することを期待されていない。 これはわれわれにとって本当のコラボレーションだと思っていません。すなわち各人が、各研究者も教授も、 アーティストでありデザイナーでありサイエンティストでありエンジニアであり、なおかつ教授の場合ビジネス マンでもなきゃいけない。一人の人間がすべてでなきゃいけない。すなわち、ひとつのラベルを貼って、レッテ ルを貼って、あなたは技術者、あなたはCognitive Science(認知科学)、あなたはSociology、といった時 代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう終 わっている。もちろんすべての学問でNo.1にはなれませんけども、それぞれの言語をfluentに話し、深く尊 敬し、そういうチームをまとめられるリーダーでないと、これからやっていけない、というふうに思います。 それがわれわれの学際の違いです。(石井裕さん) 未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (ニコラス・ ネグロポンテ)
未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan
Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (慣用句?ニコラス・ネグロポンテ→石井さん) 学際っていう場合、多くの場合、例えば技術系の人がアート系の人と協力し合って、コラボレートすることだと 思っている方がいます。それはどういう仮定を含んでいるかというと、アーティストは、ハンダ付けしない、電気 工学わからなくていい、C++のLanguageが書けなくていい。一方、技術者は、アートの本質的なConcept とかTheoryに貢献することを期待されていない。 これはわれわれにとって本当のコラボレーションだと思っていません。すなわち各人が、各研究者も教授も、 アーティストでありデザイナーでありサイエンティストでありエンジニアであり、なおかつ教授の場合ビジネス マンでもなきゃいけない。一人の人間がすべてでなきゃいけない。すなわち、ひとつのラベルを貼って、レッテ ルを貼って、あなたは技術者、あなたはCognitive Science(認知科学)、あなたはSociology、といった時 代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう終 わっている。もちろんすべての学問でNo.1にはなれませんけども、それぞれの言語をfluentに話し、深く尊 敬し、そういうチームをまとめられるリーダーでないと、これからやっていけない、というふうに思います。 それがわれわれの学際の違いです。(石井裕さん) すなわち各人が、各研究者も教授も、アー ティストでありデザイナーでありサイエン ティストでありエンジニアであり、なおか つ教授の場合ビジネスマンでもなきゃいけ ない。
未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan
Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (慣用句?ニコラス・ネグロポンテ→石井さん) 学際っていう場合、多くの場合、例えば技術系の人がアート系の人と協力し合って、コラボレートすることだと 思っている方がいます。それはどういう仮定を含んでいるかというと、アーティストは、ハンダ付けしない、電気 工学わからなくていい、C++のLanguageが書けなくていい。一方、技術者は、アートの本質的なConcept とかTheoryに貢献することを期待されていない。 これはわれわれにとって本当のコラボレーションだと思っていません。すなわち各人が、各研究者も教授も、 アーティストでありデザイナーでありサイエンティストでありエンジニアであり、なおかつ教授の場合ビジネス マンでもなきゃいけない。一人の人間がすべてでなきゃいけない。すなわち、ひとつのラベルを貼って、レッテ ルを貼って、あなたは技術者、あなたはCognitive Science(認知科学)、あなたはSociology、といった時 代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう終 わっている。もちろんすべての学問でNo.1にはなれませんけども、それぞれの言語をfluentに話し、深く尊 敬し、そういうチームをまとめられるリーダーでないと、これからやっていけない、というふうに思います。 それがわれわれの学際の違いです。(石井裕さん) もちろんすべての学問でNo.1にはなれま せんけども、それぞれの言語をfluentに話 し、深く尊敬し、そういうチームをまとめ られるリーダーでないと、これからやって いけない、というふうに思います。
チームにとって うまくいきそうな アイデアを 選んでみよう
アウトプット とアウトカム
「多かったら少なくしよう」 「足りなかったら増やそう」というふうに、 いま起こってる事象をそのまま しらみつぶしに解決していくのは、 誰でもできることだし、工夫もいらない。 たとえば、ある料理店で、お客さんが 出てきた料理について「多い」と言ってる。 そのときに、「多い」と言ってる人は、 なぜ「多い」と言ってるのか。 その根っこにあるものは、
じつは「多い」ことが問題じゃなくて、 「まずい」ことが問題だったりするんです。
最小のアウトプットで 最大のアウトカム (成果)を得たい
ユーザーストーリー (Connextra形式) As a XXX(利用者の役割), I want XXX (欲しいモノ) So
that XXX (得られる成果)
しかし、 プロダクトバックログの 順位は常に並び替えられる
まず、どのユーザーの 問題解決を優先すべきか 考える。
None
None
None
解決策として提示する 機能を考えよう それを実現するために 必要な機能のステップ を洗い出そう
できそうなことの 組み合わせで考える
None
None
None
実現する順番を 考えてみよう
しかし、 我々は 一歩ずつしか 登れない
None
None
全体を計画して 部分を作っていく 全体像を考えて 詳細度を上げていく
プロダクト バックログ ストーリー マップ (全体像) (リスト)
https://openviewpartners.com/blog/scrum-jeff- sutherland-on-what-happens-after-done/ 1. チームがすぐに 行動できる 2. 話し合える 3. 価値がある 4.
見積もり可能 5. 受入テストがある 6. サイズが適切
プロダクトバック ログにしてみよう
フィードバックを もらう
https://openviewpartners.com/blog/scrum-jeff- sutherland-on-what-happens-after-done/ 実際にエンドユーザー に聞いてみると、バック ログの約3分の1はエ ンドユーザーにとって価 値がないことがわかり ました。 これをジャンクストー リーと呼んでいます。
相互レビューを してみよう。
最良のアイデアは たぶん明日ふってくる
https://www.waicrew.com/2013/04/03/
https://www.waicrew.com/2013/04/03/
なぜこんな研修を やっているか