Age of Agile Development 2.3

Slide 1

Slide 1 text

アジャイル開発の時代川口恭伸アギレルゴコンサルティング株式会社シニアアジャイルコーチ一般社団法人スクラムギャザリング東京実行委員会代表理事一般社団法人 DevOpsDays Tokyo 代表理事

Slide 2

Slide 2 text

川口恭伸かわぐちやすのぶ Twitter: @kawaguti アギレルゴコンサルティング株式会社シニアアジャイルコーチ一般社団法人スクラムギャザリング東京実行委員会代表理事一般社団法人 DevOpsDays Tokyo 代表理事

Slide 3

Slide 3 text

さあ、すぐに動ける組織へアギレルゴアジャイル研修検索海外著名講師が直接教える Scrum Alliance® 認定トレーニング (通訳付き)

Slide 4

Slide 4 text

私が受けたい研修を集めました。アギレルゴアジャイル研修検索

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

この本が扱うのは人間だ。それもソフトウェアを書く人間である。ここ10年ほどの間、我々は、共同作業によってソフトウェアを生み出す方法について研究してきた。優れたソフトウェアを効率的に次々と生み出す能力に関心があるのだ。

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

そのような環境にいるスクラムマスターは、チームの秘書になっていきます。かなりつまらない役職です。秘書になったスクラムマスターは、チームが仕事に集中できるように、スクラムボードにあるカードの世話をしたり、どんな障害物もすぐに取り除いたり、チームにコーヒーを出したりします。よくある話ですか？でも、本来のスクラムマスターは全然違うものなんです。それでは、スクラムマスターの⽬標とはなんでしょうか？スクラムマスターは⾃⼰組織化したチームを構築し、企業のあらゆる階層で基本原則として⾃⼰組織化が⾏われるよう努⼒します。⾃⼰組織化は当事者意識と責任感をもたらします。その結果、⼈々はより活動的になり、説明責任を果たすようになります。さらに、チームメンバーは⾃分たちなりの解決法を考え出す機会を持つようになり、グループ全体をもっと効率的にします。

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

本日お話ししたいこと

Slide 11

Slide 11 text

雪で電車が止まって、動くまで小一時間。

Slide 12

Slide 12 text

見知らぬ人に、アジャイルってなにかを説明してみる。

Slide 13

Slide 13 text

自分たちにとってあたりまえになりすぎて説明を端折りがちなことをちゃんと説明してみたい。今日の目標

Slide 14

Slide 14 text

1. アジャイルってなんですか？ 2. うちの会社でもできるのかな？ 3. 上司を説得するには？ 4. 成果を出すにはどうしたら？

Slide 15

Slide 15 text

アジャイルってなんですか？ 1.

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

agilemanifesto.org アジャイルマニフェスト来年二月で20周年。

Slide 18

Slide 18 text

1970-80年代コンピュータの普及 1990年代パーソナルコンピュータの普及ソフトウェア工学の黎明 2000年代 Webブラウザ、仮想化、クラウド、スマホ 2010年代スマホ/クラウド中心、ビッグデータと機械学習軽量ソフトウェア開発方法論の進展フリーソフトウェア OSS 2001 アジャイルマニフェストアジャイルの普及リーンスタートアップ 2009年リーマンショック 2010年東日本大震災 DevOps MIT, Xerox PARC, DEC, シリコンバレー Unix, Mac, Windows IE4-, VMware/Xen, Chrome, iPhone, Android ドットコムバブル崩壊クラウドの普及ユニコーン企業 GAFA+M ざっくり年表日米経済摩擦 1985年プラザ合意 2001年同時多発テロ自動車、半導体産業 1991年バブル崩壊

Slide 19

Slide 19 text

agilemanifesto.org アジャイルマニフェスト来年二月で20周年。

Slide 20

Slide 20 text

https://kawaguti.hateblo.jp/ entry/20110213/1297531229 アジャイルマニフェスト10周年 – アジャイルマニフェストはどう生まれたのか来年二月で20周年。

Slide 21

Slide 21 text

ボブ・マーティンがミーティングを招集して、こう言った。「私たちが言っていることって、似ているように聞こえるんだけど、これって偶然の一致なのかなぁ？」彼はマニフェストを書くことに関心があることを付け加えた。(私はマニフェストを書くことには全く関心がなかったので、マニフェストへの世間の反応は、私はボブ以上に驚いたんじゃないかと思う)。ボブはワンダフルな人々をミーティングに招待していた。 “軽量プロセス”の提案者として、他の誰より知られた人たちだ。北米だけでなく、イギリスを基盤とするDSDMの代表とも話すことができた。 Ari van Bennekum はオランダからこのミーティングのためだけに来ていた。 XP、スクラム、クリスタル、アダプティブ、FDD、DSDM、軽量で実践的な開発といわれるひとたち (Andy Hunt, Dave Thomas, Brian Marick) が集まっていた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229

Slide 22

Slide 22 text

「こんにちは、私は xx です」というやり取りが一周した後、車座に座って、お互いをしばらく凝視した後、誰かが言った。「我々は、アジェンダ(今日話す議題)をどうやって作ればいいんだろう？」すると、誰かがアジェンダ項目をインデックスカードに書くことを提案した。XPの人たちは研修用にインデックスカードを持ち歩いていたのですぐに取り出して書き始め、書き終わったものを中央の床に放り込んだ。急に、過半数の人々が床にインデックスカードを入れ始めた。残りの人も、同じようにやり始めて、アイデアが尽きたときには、床のインデックスカードは山になっていた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229

Slide 23

Slide 23 text

誰かが尋ねた。「このカードをどうやってまとめて、アジェンダにするんだろう？」誰かが言った(私はこのときすでに、誰がなにを言ったかを記録するパワーはなかった)。「アジェンダの順番に意見がある人は、このカードを並べ替えよう。そうでない人は、ここを離れてもいい。」私はトピックの順番は気にしていなかったので、休憩をとった。私が戻ったとき、インデックスカードは壁にテープで貼られていた。後で、誰かが「私は他のアジェンダ項目を考えているんだけど、どうしたらいい？」と言い出した。誰かが「アジェンダの空いているところ、好きなとこに貼りなよ」と答えた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229

Slide 24

Slide 24 text

私はこの作業にずっと付き合ったのだが、それは、このグループの２つの特徴が私の心を打ったからだ。リスペクト(Respect) その部屋にいた全ての人が、他の人に対して、絶大な信頼を置いていたこと。だれもミーティングをハイジャックすることを試みたりしなかった。全員が他の人の意見を極めてじっくりとよく聞いていた。常に、話している人に最大の信頼をおいていた。自己組織化(Self-organization) そこは、最も優れた人々の自己組織化の場だった。それまで経験した他の場では、常に一人の人（または、もっと悪い場合は複数の人）がミーティングを "動かそう" とするものだった。偉い人が部屋にいて、お互いをよく知らない場合、まず最初に権力闘争が始まりやすい。そこでは、そんなことは一切起こらなかった。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229

Slide 25

Slide 25 text

リスペクト自己組織化

Slide 26

Slide 26 text

agilemanifesto.org アジャイルマニフェスト来年二月で20周年。

Slide 27

Slide 27 text

agilemanifesto.org

Slide 28

Slide 28 text

agilemanifesto.org 個人と対話動くソフトウェア顧客との協調変化への対応

Slide 29

Slide 29 text

agilemanifesto.org 個人と対話動くソフトウェア顧客との協調変化への対応コミュニケーション方法ソフトウェア開発手法ビジネスの進め方リスクへの反応の仕方

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

https://kawaguti.hateblo.jp/ entry/2018/10/31/114305

Slide 32

Slide 32 text

https://kawaguti.hateblo.jp/ entry/20130217/1361047033

Slide 33

Slide 33 text

https://kawaguti.hateblo.jp/ entry/20130217/1361047033

Slide 34

Slide 34 text

https://hbr.org/1986/01/ the-new-new-product-development-game

Slide 35

Slide 35 text

自己組織化されたプロジェクトチームプロジェクトチームは、既成概念にとらわれない「情報ゼロ」の状態に追い込まれることで、自己組織化の性格を帯びてきます。この状態では、曖昧さや揺らぎがあふれています。プロジェクトチームは、まるでスタートアップ企業のように、率先してリスクを取り、独自のアジェンダを展開していくようになります。プロジェクトチームは、スタートアップ企業のように、イニシアチブとリスクを取り、独自のアジェンダを持ち始めます。

Slide 36

Slide 36 text

平均年齢27歳のホンダ「シティ」プロジェクトチームには、経営陣から「若者が乗りたいと思うような車を作れ」という指示が出されていた。ある技術者は、「全く新しいコンセプトの車を設計するために、自分たちのような若い技術者を会社が呼び寄せ、自由にやらせてくれたことが信じられない」と語っている。

Slide 37

Slide 37 text

ホンダシティのプロジェクトチームもまた、現状を超えたブレイクスルーを達成した。若者のセグメントで競争力のある2つの特徴、すなわち資源と燃料の効率性と、低価格で妥協のない品質を備えた車の開発が求められていた。チームの直感では、ホンダのベストセラーモデル「シビック」のスケールダウン版を開発するのだろうと考えていた。しかし、議論の末、チームはまったく新しいコンセプトのクルマを開発することにした。それは、「クルマは長くて低いもの」という常識を覆し、「短くて高いもの」をデザインするというものだった。マシン・ミニマム、ヒューマン・マキシマムへの進化は避けられないと確信したチームは、リスクを冒してでも業界の常識を覆そうとしたのだ。

Slide 38

Slide 38 text

フジゼロックスでは、FX-3500を作る多機能チームを、企画、設計、生産、販売、物流、評価の各部門からなる一つの大きな部屋に配置した。この理由を、プロジェクトメンバーは次のように語っている。「全員が一つの部屋にいると、誰かの情報が勝手に自分のものになる。そうすると、自分の立場だけではなく、全体にとって何がベストか、何がセカンドベストかを考えるようになります。みんなが相手の立場を理解すれば、それぞれが譲歩したり、少なくともお互いに話し合おうという気持ちになるのです。その結果、イニシアチブが生まれるのです。」

Slide 39

Slide 39 text

6. ミスを許容し、予測するホンダの技術者たちは、「1％の成功は99％のミスによって支えられている」と口癖のように言っている。研究開発を担当するブラザーの幹部は、「若い技術者が多くのミスをするのは当然です。大切なのは、そのミスを早く見つけて、すぐに修正することです。そのために試作のサイクルを早くするなどの工夫をしています」。 3Mの幹部は、「成功よりも失敗から学ぶことのほうが多いと思います。だからといって、簡単に失敗するべきというわけではありません。もしミスをするならば、創造的にミスをするべきです」。

Slide 40

Slide 40 text

7. サプライヤーの自己組織化を促進する。設計の初期段階でサプライヤーを巻き込むことは正しい方向への一歩です。しかし、プロジェクトチームはサプライヤーに何をすべきかを指示することは控えなければなりません。 Xerox社が発見したように、サプライヤーは問題の説明を受け、部品をどのように供給するかを決めることができるなら、もっとよい結果を出すことができるようになります。

Slide 41

Slide 41 text

https://kawaguti.hateblo.jp/ entry/20130217/1361047033

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

https://www.nhk.or.jp/ professional/2008/0415/ index.html 工場再建山田日登志

Slide 44

Slide 44 text

自分で考える社員を作る

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

https://www.scrumguides.org/download.html

Slide 48

Slide 48 text

透明性検査適応

Slide 49

Slide 49 text

フィードバックサイクルを回す

Slide 50

Slide 50 text

うちの会社でもできるのかな？ 2.

Slide 51

Slide 51 text

大丈夫できるまでやればできるハイキュー！！ 30巻より

Slide 52

Slide 52 text

Linda Rising さんの答え

Slide 53

Slide 53 text

Linda Rising さんの答え “It takes a long time”

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

System1: 直感的な速い思考 System2: 論理的な遅い思考

Slide 56

Slide 56 text

https://speakerdeck.com/ kawaguti/hagechabin 現場感覚や当事者感覚がない人のSystem1で棄却される問題 System1 System2

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

ちゃんと相手と話せるように勉強してみよう

Slide 59

Slide 59 text

整理しよう • 成果を出したいのは同じ • 何が悪いのかわからない • やってみたいだけでは？ • ほんとにうまくいくの？

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

予備調査(4) ふりかえりの時間(5) 小さな成功(2) ステップバイステップ(3)

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

エバンジェリスト(1)

Slide 64

Slide 64 text

私たちは何人もの正式な推進担当者(29)として雇われた人たちから話を聞いてきた。中にはイノベーションの導入に失敗してしまった人もいた。彼らは導入のために雇われたという立場で、売り込みには関わらなかった。すなわち、エバンジェリズムつまりイノベーションへの信仰心など持っていなくても、職務を遂行できると考えたのだ。しかし、私たちはそうではないと発見した。情熱とか熱狂とか信条とか決意というものは、チェンジエージェントにとっての必須の要素であり、「ただ自分の仕事をこなすだけ」という態度では成功が難しいのだ。正式な推進担当者(29)のバッチをつけていようが、マネージャーの権限を持っていようが、エバンジェリストになるのは必須条件だ。

Slide 65

Slide 65 text

情熱信条熱狂決意

Slide 66

Slide 66 text

でも、新しモノ好きのレッテルに注意

Slide 67

Slide 67 text

イノベーター(16)

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

しかしながら、あなたはイノベーターに長い間、頼ることはできないだろう。イノベーターは次から次へと新しいものに興味を持つので、違う方に興味が移ってしまうのである。さらには、イノベーターは新しいアイデアをすぐ受け入れてしまうので、他の人には疑念を抱かせることにもなる。したがって、一般的にはイノベーターは良いオピニオン・リーダーにはなれないのである。イノベーターからの協力は、短期の門番のようなものと考えよう。もしそれ以上の働きをしてくれたら、ラッキーだと思おう。

Slide 70

Slide 70 text

https://gihyo.jp/dev/serial/01/agile/0006 信頼貯金を増やす。

Slide 71

Slide 71 text

Linda Rising さんの答え “It takes a long time”

Slide 72

Slide 72 text

だが希望はある

Slide 73

Slide 73 text

https://kawaguti.hateblo.jp/ entry/2019/01/03/190517 世の中が先に変わる。

Slide 74

Slide 74 text

https://kawaguti.hateblo.jp/ entry/2019/01/03/190517 世の中が先に変わる。

Slide 75

Slide 75 text

結局我々が知りたいのはデプロイの前に「ちゃんと動くと思われるアプリケーション」を作ることだ。「完全に動く」と保証は残念ながらできない。どんなに慎重になったとしても。しかし、そこに極限までに近づけるように努力をする。 https://simplearchitect.hatenablog.com/ entry/2020/11/17/080148

Slide 76

Slide 76 text

まず自分がアジャイルを体現しよう

Slide 77

Slide 77 text

“高齢者が対象となるワクチンの接種予約については、システムトラブルを含め、全国で混乱が生じている。平井氏は記者会見で「予約システムに関しては各自治体それぞれ独自で作っている。デジタル庁が発足していれば、こういう予約システムが乱立するようなことは避けられただろうと、今となっては思う」と述べた。”

Slide 78

Slide 78 text

Linda Rising さんの答え “It takes a long time”

Slide 79

Slide 79 text

好調なうちに仕込んでおく https://kawaguti.hateblo.jp/ entry/2019/07/31/153513

Slide 80

Slide 80 text

上司を説得するには？ 3.

Slide 81

Slide 81 text

アジャイルしたいけど上司の許可がおりません

Slide 82

Slide 82 text

そんな上司は今すぐクビだ！

Slide 83

Slide 83 text

大丈夫できるまでやればできるハイキュー！！ 30巻より

Slide 84

Slide 84 text

いや、上司を味方につけたいんです

Slide 85

Slide 85 text

身近な支援者(35)

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

No content

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

支援してくれる評判のいい管理者を探そう。

Slide 90

Slide 90 text

https://speakerdeck.com/ kawaguti/hagechabin 現場感覚や当事者感覚がない人のSystem1で棄却される問題 System1 System2

Slide 91

Slide 91 text

マリーアントワネット問題

Slide 92

Slide 92 text

支援してくれる評判のいい管理者を探そう。

Slide 93

Slide 93 text

Linda Rising さんの答え “It takes a long time”

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

Culture Bubble 新しい文化を社内に維持して、大切に育てる

Slide 96

Slide 96 text

https://shift314.com/

Slide 97

Slide 97 text

https://shift314.com/

Slide 98

Slide 98 text

成果を出すにはどうしたら？ 4.

Slide 99

Slide 99 text

いい質問です

Slide 100

Slide 100 text

https://www.1101.com/president/ iwata-index.html

Slide 101

Slide 101 text

https://www.1101.com/president/ iwata-index.html 成功を体験した集団を、現状否定をして改革すべきではないと思います。その人たちは善意でそれをずっとやってきて、しかもそれで成功してきている人たちなんですから、現状否定では理解や共感はえられないんです。

Slide 102

Slide 102 text

https://www.1101.com/president/ iwata-index.html 誰かのお役にたったり、誰かがよろこんでくれたり、お客さんがうれしいと思ったり、それはなんでもいいんですが、当事者になれるチャンスがあるのにそれを見過ごして「手を出せば状況がよくできるし、なにかを足してあげられるけど、たいへんになるからやめておこう」と当事者にならないままでいるのはわたしは嫌いというか、そうしないで生きてきたんです。

Slide 103

Slide 103 text

https://speakerdeck.com/ kawaguti/hagechabin 現場感覚や当事者感覚がない人のSystem1で棄却される問題 System1 System2

Slide 104

Slide 104 text

マリーアントワネット問題

Slide 105

Slide 105 text

当事者になる例 https://takaking22.com/ 2018/mob-advent/

Slide 106

Slide 106 text

https://takaking22.com/ 2018/mob-advent/ 当事者になる例

Slide 107

Slide 107 text

https://www.agilealliance.org/ resources/experience-reports/ mob-programming-agile2014/

Slide 108

Slide 108 text

翻訳しました。 https://kawaguti.hateblo.jp/ entry/2021/03/30/082537

Slide 109

Slide 109 text

There are two roles: The Driver, and the Navigator. The Driver sits at the keyboard and types in the code. The Navigators discuss the idea being coded and guide the Driver in creating the code. This means the Driver has a much more mechanical job than when coding solo. The Driver listens to the Navigators, and must trust the Navigators. The Driver is focused on the typing/coding. The Navigators are expressing their ideas to the Driver in a slow, metered approach so the Driver only has to focus on the next thing to type at any given time. 2つの役割があります。ドライバーとナビゲーターです。ドライバーはキーボードの前に座り、コードを入力します。ナビゲーターは、コード化されたアイデアを議論し、コードを作成する際にドライバーをガイドします。これは、ドライバーがソロでコーディングする場合よりもはるかに機械的な仕事をしていることを意味します。ドライバーはナビゲーターの話に耳を傾け、ナビゲーターを信頼しなければなりません。ドライバーはタイピング/ コーディングに集中しています。ナビゲーターは、ゆっくりとしたペースでドライバーに自分たちのアイデアを伝えているので、ドライバーはいつでも次のタイピングに集中することができます。 https://www.agilealliance.org/ resources/experience-reports/ mob-programming-agile2014/

Slide 110

Slide 110 text

While expressing these things to the Driver out loud they are also being expressed to the rest of the people on the team. We discuss and work out the possibilities verbally and at the white board so everyone is gaining a full understanding of the idea. This creates a sort of collective intelligence of the Navigators and the team as a whole. これらのことをドライバーに声に出して表現すると同時に、チームの他の人にも表現しています。口頭やホワイトボードで可能性を議論し、ワークアウトすることで、全員がアイデアを完全に理解することができます。これにより、ナビゲーターとチーム全体の集合知性が生まれます。 https://www.agilealliance.org/ resources/experience-reports/ mob-programming-agile2014/

Slide 111

Slide 111 text

Sometimes this can be at a very high level when the Driver understands the concept to be coded and can proceed without detailed instructions. It can also be at a very detailed level if necessary, even at the level of keystroke instructions when needed. This will change from person to person, and will also change for the same person throughout the day depending on the idea being worked on, and the ability of the Driver to understand the instructions. ドライバーがコード化すべきコンセプトを理解していて、詳細な指示がなくても進めることができる場合には、非常に高いレベルであることもあります。また、必要に応じてキー操作の指示が必要な場合には、非常に細かいレベルになることもあります。これは人によっても変わってきますし、一日を通して同じ人でも、取り組んでいるアイデアや、ドライバーの指示を理解する能力によっても変わってきます。 https://www.agilealliance.org/ resources/experience-reports/ mob-programming-agile2014/

Slide 112

Slide 112 text

大丈夫できるまでやればできるハイキュー！！ 30巻より

Slide 113

Slide 113 text

「人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。」(第一章 P.13-14)

Slide 114

Slide 114 text

明日はもっとうまくなろう

Slide 115

Slide 115 text

Linda Rising さんの答え “It takes a long time”

Slide 116

Slide 116 text

長く続けるにはどうしたら？

Slide 117

Slide 117 text

https://ameblo.jp/oka-naoya/entry-12435303761.html 成果が出ないときもある

Slide 118

Slide 118 text

手柄を横取りされる勝手に祭り上げられる何もしてないのに怒られるその気はないのに競争相手と認知される使えない人認定される自分勝手と言われる給料を下げられる気持ちが落ち込んだら思い返そう。「私が望んでいることは何？人気を集めたり、尊敬されたり、そんなことのためにやってないよね？」当事者であろう次の実験をしてみよう説明を端折るのを我慢しよういま自分に貢献できることをやろう他の人がカバーしていない落とし穴を埋めようやめたくなることもある

Slide 119

Slide 119 text

• 当事者であろう • 次の実験をしてみよう • 説明を端折るのを我慢しよう • いま自分に貢献できることをやろう • 他の人がカバーしていない落とし穴を埋めよう

Slide 120

Slide 120 text

高い山の頂も深い谷底も、眺めて想像するのはそこそこに、いまの一分一秒を大事にして、クレバスや脆い地盤にも十分気をつけながら、一歩ずつ進んでいくのだ。自分の旅の終着点は選べない。一歩ずつ進もう

Slide 121

Slide 121 text

私たちは、うまくいっていることを認識すること、またさらに良くする方法を探すことによって、多くの価値を得ることができると発見しました。私たちはこれを「いいこと探し(Turn Up the Good)」と呼んでいます。問題を特定し、それを解決しようとすることは有用ですが、うまくいっていることを増やす方法を見つけることで、さらに多くの価値を得ることができることがわかりました。 https://speakerdeck.com/agilesingapore/mob- programming-a-whole-team-approach-woody-zuill- agile-sg-2016?slide=18 https://kawaguti.hateblo.jp/entry/2021/03/30/082537 いいこと探し

Slide 122

Slide 122 text

https://www.1101.com/umeda_iwata/2008-11-18.html 適切なサイズの問題を作り続ける