プロダクトを作ろう

二枚のピザのチーム

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 (得られる成果)

しかし、 プロダクトバックログの 順位は常に並び替えられる

まず、どのユーザーの 問題解決を優先すべきか 考える。

No content

No content

No content

解決策として提示する 機能を考えよう それを実現するために 必要な機能のステップ を洗い出そう

できそうなことの 組み合わせで考える

No content

No content

No content

実現する順番を 考えてみよう

しかし、 我々は 一歩ずつしか 登れない

No content

No content

全体を計画して 部分を作っていく 全体像を考えて 詳細度を上げていく

プロダクト バックログ ストーリー マップ (全体像) (リスト)

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/

なぜこんな研修を やっているか