アジャイルとスクラムとは～価値、原則、プラクティス～

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2001年ごろアジャイルと出会い、開発者、チームリーダー、トレーナー、導入支援と多様な立場で関わってきた。(株)永和システムマネジメントにて2010年頃からアジャイルコーチを主軸として活動。2014年独立。プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング現場導入支援スクラムマスター支援ふりかえりアジャイルコーチ (ものづくり面) モブプログラミングテスト駆動開発テスト自動化学びのゲームをデザイン、製作、デリバリー宝探しアジャイルゲームカンバンゲーム心理的安全性ゲーム著書・訳書 tsutomu.yasui@gmail.com twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ)

Slide 3

Slide 3 text

今日の内容 • アジャイルな企業の例 • アジャイルとはなんなのか？ • アジャイルの価値・原則・プラクティスとは？ • アジャイルに向き不向きはあるの？ • アジャイルをやってみるには？質問歓迎します！

Slide 4

Slide 4 text

アンケート: アジャイルやスクラムのイメージ • www.menti.com をアクセスして、番号を入力してください • ご自分のアジャイルやスクラムのイメージと近いものを3つ選んでください • 録画視聴の方も手元で書き出してみてください

Slide 5

Slide 5 text

ある変わった企業の話

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

どこが変わってるの？ • 顧客が毎週やってきて、開発チームと一緒に成果について話す • プログラマーは全員ペアを組んで仕事をする • 毎週納期、でも残業はぜんぜんない • ハイテク人類学者がユーザーを研究する • 地下の広大なオフィス(駐車場を改装)で、座席・デスクが移動自由 • 赤ん坊や動物がいる • 喜びがある (※基本的に2016年時点の話になります)

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

他の写真？なにか適当なやつ？ https://www.flickr.com/photos/kitlvcollections/5497319028/ ハイテク人類学者 High-Tech Anthropologists

Slide 10

Slide 10 text

顧客による計画おりがみ

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

自律的な進捗管理

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

ペアプログラミング

Slide 16

Slide 16 text

顧客を巻き込んだデモショウ＆テル

Slide 17

Slide 17 text

すなわち…… 要件定義プロジェクト計画実装受入テストハイテク人類学者顧客と計画おりがみペア作業タスクボードショウ＆テル 1週間

Slide 18

Slide 18 text

MAKE MISTEAKS FASTER 失敗をはやくたさくんしよう

Slide 19

Slide 19 text

2021年のアップデート • 2020年はファイナンスの危機 • 収益60％ダウン • 一時的な給与カット • 手元資金とPPPローンで乗り切った • 全員リモートワーク • 「リモートで上手くやれる方法を探究するのが楽しみだ！」 • リモートペアプロ • リモートでハイテク人類学 • 紙やホワイトボードの仕組みをデジタル化 • オフィスツアーはバーチャルツアー • 採用インタビューもバーチャルで実施(2021年2月) https://menloinnovations.com/stories/culture/culture-storytelling-joy

Slide 20

Slide 20 text

またある変わった企業の話

Slide 21

Slide 21 text

https://www.sonicgarden.jp/201407_family_trip 株式会社ソニックガーデン

Slide 22

Slide 22 text

どこが変わってるの？ • 家族旅行をする • 全社員リモートワーク • オフィスをなくした • 顧客には顧問プログラマが１人で専任する • 企画から設計、コーディング、運用まですべて • マネージャがいない • 業務ハッカー募集中 • 納品しない受託開発 • プログラマを一生の仕事に

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

http://getnews.jp/archives/1510240 全社員リモートワーク(2016年から)

Slide 25

Slide 25 text

https://www.flickr.com/photos/124247024@N07/13903385550/ 顧問プログラマ

Slide 26

Slide 26 text

https://www.slideshare.net/rootmoon/ss-48797871

Slide 27

Slide 27 text

https://www.slideshare.net/rootmoon/ss-48797871

Slide 28

Slide 28 text

https://kuranuki.sonicgarden.jp/2014/11/innoswdev_fse.html

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

1人ひとりがセルフマネジメントチーム全体がみんなで協力

Slide 31

Slide 31 text

小さな組織で個人の価値を尊重すること中間に入る無駄をなくして直接つなぐこと判断に理解と納得を持ち思考停止しないこと動くサービスを常に最高品質で提供すること小口化し繰り返すことで持続可能にすること日々学びを続けて自ら変化に取り組むこと情報をオープンにし常に公明正大であること価値観を共有 https://www.sonicgarden.jp/company

Slide 32

Slide 32 text

「こうした問題を何とかできないか、一体何が原因なのかを考え尽くしたところ…ビジネスモデルそのものに問題があると分かった」「もともと私たちはリモートチームを… 目的にしてきたわけではありません。… ビジネスモデルを追究した結果として、リモートチームで仕事ができるように」「変化を受け入れる変化を恐れない自らの変化を広げる」変化試行錯誤 https://www.sonicgarden.jp/company

Slide 33

Slide 33 text

アジャイルなソフトウェア開発とは

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

アジャイルソフトウェア開発宣言私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/ 2001年

Slide 41

Slide 41 text

アジャイル宣言の背後にある原則私たちは以下の原則に従う: 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 (続く) http://agilemanifesto.org/iso/ja/principles.html

Slide 42

Slide 42 text

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。動くソフトウェアこそが進捗の最も重要な尺度です。 (続く) http://agilemanifesto.org/iso/ja/principles.html

Slide 43

Slide 43 text

アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。シンプルさ（ムダなく作れる量を最大限にすること）が本質です。最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 http://agilemanifesto.org/iso/ja/principles.html

Slide 44

Slide 44 text

http://agilemanifesto.org/iso/ja/ Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Slide 45

Slide 45 text

アジャイルとは

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Alistair Cockburn “Heart of Agile” http://alistair.cockburn.us/HeartOfAgile 2014年

Slide 48

Slide 48 text

https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/ Joshua Kerievsky “Modern Agile” 2016年

Slide 49

Slide 49 text

安全を必須条件にする • よい仕事の前提条件 • 心理的安全性 • アンゼニアリング (Anzen-eering)

Slide 50

Slide 50 text

高速に実験＆学習する • よりよいやり方をつねに模索する • 現状が上手くいっていたら、それを壊す • 自分の経験から、相互の知識から、外のリソースから学ぶ • 実験から新たな情報を獲得する

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

モブプロの実験と改善の例

Slide 55

Slide 55 text

雑談 • クリエーションライン社の取り組み • https://www.creationline.com/blog/tadahiro-yasuda/31156 • なお講師がアジャイルコーチとして支援しています • Weekly朝会で全社員がお互いに雑談する • たくさんの実験 • 時間設定 • 人数 • メンバー • 雑談テーマ • 効果 →

Slide 56

Slide 56 text

継続的に価値を届ける • ユーザー価値に集中する • 継続的に、頻繁にデリバーする • 毎週～毎日程度 • サービス内容にもよる • 届けた結果を見る • フィードバックを得る • 新たな実験の材料とする

Slide 57

Slide 57 text

人々を最高に輝かせる • 成果を得るために最も大切なのは人 • 個人と人々 • 最高に輝いている個人・チームが最高の結果を出せる

Slide 58

Slide 58 text

従来型ウォーターフォールアジャイル

Slide 59

Slide 59 text

従来型ウォーターフォールアジャイルプロセスやツール個人と対話

Slide 60

Slide 60 text

アジャイルなソフトウェア開発の4側面

Slide 61

Slide 61 text

https://speakerdeck.com/kawaguti/kanban-and-scrum

Slide 62

Slide 62 text

1999 1995 2003 2001 参考: 1991 - Linux 1996 - Java 1.0 2001 – Windows XP 2002 - .NET Framework 1.0 1986 1994 (GoF)

Slide 63

Slide 63 text

アジャイルとは？ • 「アジャイルな開発」を実現できるような人、組織、環境、ビジネスを作ること？ • アジャイルな開発から得た知見を人、組織、環境、ビジネスに応用すること？どちらにしても、開発だけ運用だけビジネスだけ。。。の話ではない！経営だけ人事だけ

Slide 64

Slide 64 text

アジャイルな開発の特徴 • ビジョンや目標を共有し、全体がそこに向かっている • ルール、プロセス、手法が常に変わり続けている • アウトカム(結果)を重視している • 「そこにいる人びと」ならでは、になっている • 顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けているこうした観点からKPI・KGIを選ぶ

Slide 65

Slide 65 text

アジャイルな人や組織の特徴 • ビジョンや目標を共有し、全体がそこに向かっている • ルール、プロセス、手法が常に変わり続けている • アウトカム(結果)を重視している • 「そこにいる人びと」ならでは、になっている • 顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けているこうした観点からKPI・KGIを選ぶ

Slide 66

Slide 66 text

アジャイルの指標例 • 実験の頻度、健全な割合で失敗しているか • ビジョンの認知と腹落ち度 • 顧客やユーザーからのNPS(ネットプロモータースコア) • 価値提供の頻度 • メンバーの成長と流動性 • ソフトウェア開発の場合 • リリースと測定の頻度 • CI、CDの頻度と所要時間 • テストの自動化カバレッジ ※コードカバレッジではなく、テストの自動化カバレッジ • ソースコードの変更頻度(既存コードをちゃんと直しているか)

Slide 67

Slide 67 text

アジャイルは形容詞 agi・le [形] 素早い、敏捷、しなやかな • Be Agile, not Do Agile • アジャイル「を」やる ⇒ できない！ • アジャイル「を」使う ⇒ 誤り • アジャイル「に」開発する • アジャイル「な」態度 • 「もっと」アジャイル

Slide 68

Slide 68 text

形容詞「アジャい」 • アジャい開発 • 「うちのチーム、結構アジャいんですよ」 • 我が社でもアジャイルを導入する → 我が社もアジャいくなる • 「アジャイルをやるのに必須のツールです」 → 「今よりアジャいくなるのに、お勧めツールです」 ※誰も言ってません。流行ったらいいな

Slide 69

Slide 69 text

開発運用ビジネス経営人事ビジョンプロダクトの価値プロダクトの価値長期世界・世間組織文化変化能力を発揮するチャンス能力を発揮するチャンス差をつけるチャンス常に・あたりまえスキルアップ・チェンジアウトカムユーザーにとっての価値ユーザーにとっての価値新たな展開コアバリューの不変現場の声信頼と実績フィードバックを生かすフィードバックを生かす三方良し現場を信頼採用より成長重視いきいき個々の強み、チームの力、モチベーション、誇り

Slide 70

Slide 70 text

マインドセットの違いガチガチマインドセット • 能力 – 不変、背の高さなど • ゴール – 良く見られる • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力アジャイルマインドセット • 能力 – 成長、筋肉など • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント)

Slide 71

Slide 71 text

アンケート: 自分にとってアジャイルとは？ • ここまでの話から、アジャイルという考え方が自分にどう関わるか、自分ならどんなところにアジャイルをあてはめたいか、思いついたことを書いてください。 • 複数回答可です(送信した後で追加できます) • 時間が余ったらおすすめのランチやおやつについて書いてください • 録画視聴の方も手元で書き出してみてください

Slide 72

Slide 72 text

アジャイルへのたどり着き方

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

価値、原則、プラクティス • 価値 = 究極の目的 • プラクティス = 実際の具体的なやり方 • 原則 = プラクティスがなぜ価値につながるかの説明

Slide 75

Slide 75 text

価値、原則、プラクティス • メンローイノベーションズ • 価値 = 喜び • 原則 = 個人を生かす、学び合う、仕事を楽しむ • プラクティス = ペアプログラミング • ソニックガーデン • 価値 = 個人を尊重、試行錯誤 • 原則 = 一生プログラマ、納品しない、やってみる • プラクティス = リモートワーク、顧問プログラマ、定額契約、師弟制度 • 数えると、おおむね価値 < 原則 < プラクティス

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

お仕事頑張ってますか？

Slide 78

Slide 78 text

何のためにお仕事頑張ってますか？

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

何のため＝価値 • 価値とはほしいもの • ただでは手に入らない

Slide 81

Slide 81 text

プログラム機能フィーチャ価値コスト

Slide 82

Slide 82 text

C B どれを選ぶ？ A D 価値コスト

Slide 83

Slide 83 text

B A D 価値が大きく早くできるものから C 1 2 3 4

Slide 84

Slide 84 text

コスト≒時間 B A D C コスト

Slide 85

Slide 85 text

価値は時間累積 B A D C 時間価値累積価値

Slide 86

Slide 86 text

価値は時間累積 B A D C 時間価値累積価値

Slide 87

Slide 87 text

B A D 大価値短期間＝高ROI C 1 2 3 4

Slide 88

Slide 88 text

A A A A A

Slide 89

Slide 89 text

価値とはほしいもの • 顧客価値 • 情報、リスク対策 • 生産性

Slide 90

Slide 90 text

早いほうがいい細かいほうがいい先のことも考えたほうがいい

Slide 91

Slide 91 text

簡単ですね♪

Slide 92

Slide 92 text

簡単なわけがない 💀

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

お仕事頑張ってますか？

Slide 95

Slide 95 text

誰のためにお仕事頑張ってますか？

Slide 96

Slide 96 text

誰が誰のためにお仕事頑張ってますか？

Slide 97

Slide 97 text

コミュニケーション

Slide 98

Slide 98 text

情報帯域

Slide 99

Slide 99 text

コミュニケーションパスパス＝3本 1人2本パス＝10本 1人4本パス＝66本 1人11本

Slide 100

Slide 100 text

伝言ゲームと情報劣化

Slide 101

Slide 101 text

価値を提供するすべてのスキルを一緒にビジネスも技術もマネジメントも一緒にユーザーも顧客も開発も一緒にできるだけ少人数で

Slide 102

Slide 102 text

簡単なわけがない 💀

Slide 103

Slide 103 text

手戻り

Slide 104

Slide 104 text

技術的負債

Slide 105

Slide 105 text

機能追加とコスト時間価値

Slide 106

Slide 106 text

価値コスト時間圧縮技術的負債利子コスト時間圧縮技術的負債技術的負債

Slide 107

Slide 107 text

技術的負債 • 一時的なメリットを与える(レバレッジ) • 開発したソフトウェアに内在する • 開発の作業効率を悪化させる • 除去作業をしないと取り除けない • 放置すると増殖する

Slide 108

Slide 108 text

技術的負債 • 不適切なエンジニアリングで発生する • 能力不足 • 圧力、プレッシャー • 考慮不足 • 将来は本質的に予測できない • 「考慮不足」は不可避 • 「キレイ」な状態を… 最初にちゃんとする → 不可能 or どこかで破綻する維持する → 常時リファクタリングを続ける • 負債をためすぎないうちに返済する • 将来予測 → 変更容易

Slide 109

Slide 109 text

変更容易性 • 設計がシンプル • 変更箇所と内容が自明 • 依存関係が少ない • 特に隠れた依存関係 • 実装もシンプル • 誰でも安心して変更できる • 自動化したテスト • リグレッション • 常にこの状態を維持する • 厳しい規律 • だんだん難しくなる

Slide 110

Slide 110 text

品質と規律

Slide 111

Slide 111 text

簡単なわけがない 💀

Slide 112

Slide 112 text

人

Slide 113

Slide 113 text

こんなに難しいことを実現する仕組みを作るのは困難こんなに難しいことを実現する工夫を作れる人

Slide 114

Slide 114 text

https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/ Joshua Kerievsky “Modern Agile”

Slide 115

Slide 115 text

モチベーション3.0 • 自律 • 熟達 • 目的自分のやり方で集中することでより上手になり、できることも広がりそうして大きな目標を目指せればモチベーションが上がる

Slide 116

Slide 116 text

チームによる学習

Slide 117

Slide 117 text

責任大 ← → 小能力 →高低← 学習パニック快適

Slide 118

Slide 118 text

責任大 ← → 小能力 →高低← 学習パニック快適

Slide 119

Slide 119 text

「チームの心理的安全とは、対人のリスクを取っても安全であるという、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams” Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 心理的安全 (Psychological Safety) 「「心理的安全」とは、関連のある考えや感情について人びとが気兼ねなく発言できる雰囲気をさす。」

Slide 120

Slide 120 text

図3. グループレベルで研究した心理的安全性の関係

Slide 121

Slide 121 text

集団的学習を促す行動 • 質問する • 情報を共有する • 支援を求める • 証明されていない行動を試みる • 失敗について話す • 意見を求める

Slide 122

Slide 122 text

イノベーションを産み出し続ける組織 SECIモデル http://www.atmarkit.co.jp/aig/04biz/seci.html http://current.ndl.go.jp/ca1518

Slide 123

Slide 123 text

学習する組織 • システム思考 – 全体を考える • メンタルモデルへ意識を向け見直す • 共有ビジョン ― 「自分たちはなにを創造したいのか？」 • チーム学習とアラインメント(合致) • 経営者を含むマネジメント全体の意識変革『学習する組織』ピーター・M・センゲ

Slide 124

Slide 124 text

•価値 •コミュニケーション •技術 •人

Slide 125

Slide 125 text

簡単なわけがない 💀

Slide 126

Slide 126 text

No content

Slide 127

Slide 127 text

価値とは…… • 製品のユーザーが何を望んでいるか知りたい • ワクチンの効率的配送サービスを実現する • 会社の資金が底をつきそう • 製品が遅い • 開発スピードが遅い • 猫の画像でにっこりさせたい → 情報 → 人命 → 会社存続 → 実行速度 → 開発速度 → しあわせ

Slide 128

Slide 128 text

No content

Slide 129

Slide 129 text

No content

Slide 130

Slide 130 text

プラクティス •Practice = 練習実践 • HOW •なぜやるのか、なんのためにやるのか • ノウハウではない • 必須でもない必要性から要請される •実験の対象 • うまくいくかどうかやってみて改善 • 実際のやり方はみな違う

Slide 131

Slide 131 text

超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル / イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ

Slide 132

Slide 132 text

朝会 / デイリースタンドアップ • チーム全員 • 毎日、同じ場所、同じ時間で • 状況と問題を共有する • 立ったまま、15分以内 • 現状を踏まえて計画を見直す https://www.slideshare.net/yattom/project-facilitation-from-hiranabe

Slide 133

Slide 133 text

イテレーション • 1～4週間程度をサイクルとして、仕事を完成する • 仕事を完成する • 1機能の要件定義、設計、実装、テストまで • できるように仕事を小さく分割する • イテレーション冒頭で計画づくりをし、終わりでふりかえりをする • イテレーションの成果から毎回フィードバックを得る

Slide 134

Slide 134 text

ふりかえり / レトロスペクティブ • チーム全員 • 仕事のやりかたを見直す • 改善アクションを出す • チームが自分自身で実験する

Slide 135

Slide 135 text

タスクボード • チーム全員のタスクを見える化 • 状況を日々アップデート • 見れば誰でも全体の様子がわかる • 順調でなければ誰でもアクションできる

Slide 136

Slide 136 text

朝会、ふりかえりを学ぶ • プロジェクトファシリテーション http://objectclub.jp/community/pf/ • 朝会ガイド http://objectclub.jp/download/files/pf/MorningMeetingGuide.pdf • ふりかえりガイド http://objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf • 見える化ガイド (タスクボード) http://objectclub.jp/download/files/pf/ManagementBySeeingGuide.pdf • ふりかえりの書籍 • 『アジャイルレトロスペクティブズ』 https://www.amazon.co.jp/dp/4274066983 • 『アジャイルなチームをつくるふりかえりガイドブック』 https://www.amazon.co.jp/dp/4798168793

Slide 137

Slide 137 text

朝会イテレーションタスクボードふりかえり作る現状更新見直しリズム思い出す見返す次回に生かすプラクティス同士の相互作用

Slide 138

Slide 138 text

アンケート • 質問として、詳しく聞きたいプラクティスを書いてください • 具体的に導入を検討していたり、やっているけれど困っているなど • 資料で触れていないものでもOKです

Slide 139

Slide 139 text

XP(Extreme Programming)のプラクティス主要プラクティス • 全員同席 • チーム全体 • 情報満載のワークスペース • いきいきとした仕事 • ペアプログラミング • ストーリー • 週次サイクル • 四半期サイクル • ゆとり • 10分ビルド • 継続的インテグレーション • テストファーストプログラミング • インクリメンタルな設計導出プラクティス • 本物の顧客参加 • インクリメンタルなデプロイ • チームの継続 • チームの縮小 • 根本原因分析 • コードの共有 • コードとテスト • 単一のコードベース • デイリーデプロイ • 交渉によるスコープ契約 • 利用都度課金

Slide 140

Slide 140 text

XP(Extreme Programming)のプラクティス

Slide 141

Slide 141 text

https://speakerdeck.com/kakutani/xpmatsuri2019-keynote

Slide 142

Slide 142 text

スクラムのプラクティス •3つの役割 • プロダクトオーナー、開発者、スクラムマスター •スプリント、プロダクトゴール、スプリントゴール •5つのイベント • スプリントプランニング、スプリントレビュー、デイリースクラム、レトロスペクティブ、リファインメント •3つの作成物 • プロダクトバックログ、スプリントバックログ、プロダクトインクリメント

Slide 143

Slide 143 text

https://www.servantworks.co.jp/resources/scrum_overview_figures/

Slide 144

Slide 144 text

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

No content

Slide 147

Slide 147 text

プラクティスの難しさ: マニュアルではない • 実際にやるのはプラクティス • プラクティスをやるだけでは価値に近づかない • 「なんのため？」と「なぜ？」を意識し続ける • 自分たちがねらっている価値を共有し、理解を深める • 価値に到達する原則について全員で勉強する

Slide 148

Slide 148 text

• ただやろうとしても、なかなか上手くいかない • 我流になってしまって効果が上がりにくい • 実践(=プラクティス)の中で、繰り返し練習(=プラクティス)する • 繰り返しながら、自分たちで常に見直し続ける × やれているか △ 型通り・お手本通りか ○ 価値に近づいているか • お手本、ガイド、指導者などを活用するプラクティスの難しさ: 練習しないと上達しない

Slide 149

Slide 149 text

守破離 • 能、茶道、剣道などの教え • 守 • 師匠につき、言われたとおりのことが完璧にできるよう修練する • 基礎を身につける • 破 • 自分なりの試行錯誤をしたり、他流のやり方を取り込んだりする • 精神、メカニズム、理論を身につける • 離 • 自分自身が独立し、流派を作る、自らが師匠になる • 新たな価値を生み出す

Slide 150

Slide 150 text

• プラクティス同士の相互作用がある • 単体では効果が上がりにくい • 同時にたくさん導入すると失敗する、難易度が高くなる • やりやすい、導入しやすい順序がある • ひとつずつ導入する • ちゃんとできるようになるまで、他のことに手を出さないプラクティスの難しさ: 独立したテクニックではない

Slide 151

Slide 151 text

https://www.amazon.co.jp/dp/B08711ZCPY

Slide 152

Slide 152 text

• 期待したようにも、予定通りにも進まない • 予想外の出来事や結果は、自分たちについての新たな発見 • 試行錯誤しながら自分たちについて理解を深めていく • 計画通りに進まないことを計画する • 全員で計画づくりをする • 計画変更を計画に含める • 計画変更につながる情報収集を計画する • 計画変更の工数が小さくなるよう、計画の詳細度をコントロールする • 計画変更の量や回数を指標とする(少なかったら問題) プラクティスの難しさ: 計画通りには進まない

Slide 153

Slide 153 text

アジャイルな見積りと計画づくり • アジャイルで計画はたいへん重要 • 必要なだけ計画する • 変化を前提として計画する • 出来上がった計画よりも計画づくりを重視する • プランニング・オニオン EMZERO Vol.3.1(マナスリンク)より引用 http://www.manaslink.com/articles/75 参考：「アジャイルな見積りと計画づくり」マイク・コーン著角谷信太郎、安井力訳 https://www.amazon.co.jp/dp/4839924023

Slide 154

Slide 154 text

• 難しいので、あきらめがち • 難しいので、簡単な方法を探しがち • 難しいので、自分はいいやと思いがち • 難しいので、非難されがち • 信念と熱意のある人が必要(知識もあるとよい) プラクティスの難しさ: 難しい

Slide 155

Slide 155 text

新しいことに取り組むのは常に難しい • 信念と情熱のある人が必要 (1 エバンジェリスト) • 小さく試して小さく成功させる (2 小さな成功) • 大きな理想を一歩ずつ実現する (3 ステップバイステップ) • 自分の不足を認めて助けを請う (6 協力を求める) • 先見性のある人を集める (11 アーリーアダプター) • とにかく試してみる (17 やってみる) • 権限ある人に認められる (28 経営層の支持者) • やるといいことがあるという気配で人を引き寄せる (40 成功のにおい) https://www.amazon.co.jp/dp/462108786X

Slide 156

Slide 156 text

アジャイルと向き不向き

Slide 157

Slide 157 text

アジャイルの向き不向き • 効果が期待できるプロジェクト、プロダクト • 能力を発揮する個人の性向 • チームや組織の、ルールや文化

Slide 158

Slide 158 text

カオス複雑込み入ったシンプル

Slide 159

Slide 159 text

https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba Stacey Matrix 要求、スコープ、市場技術、テクノロジー不明確明確不明確明確

Slide 160

Slide 160 text

Stacey Matrix https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba 要求、スコープ、市場技術、テクノロジー不明確明確不明確明確

Slide 161

Slide 161 text

Stacey Matrix https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba 要求、スコープ、市場技術、テクノロジー不明確明確不明確明確

Slide 162

Slide 162 text

On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html

Slide 163

Slide 163 text

よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない • 他部門、顧客が理解してくれない • 契約やコンプライアンスの壁がある • 開発スキルが足りない • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない

Slide 164

Slide 164 text

よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない • 他部門、顧客が理解してくれない • 契約やコンプライアンスの壁がある • 開発スキルが足りない • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りないよくある！対処し乗り越える対象障害を発見するのがスクラム

Slide 165

Slide 165 text

マインドセットの違いガチガチマインドセット • 能力 – 不変、背の高さと同じ • ゴール – 人から良く見られる • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力アジャイルマインドセット • 能力 – 成長、筋肉などと同じ • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント)

Slide 166

Slide 166 text

アジャイルマインドセット • 実験：「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは？ • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset

Slide 167

Slide 167 text

Slide 168

Slide 168 text

障害を乗り越えるアジャイルマインド • 結果を出すのが大事 → 努力するのが大事 • 「頑張ります！」では大雑把 → プロセスや経過、判断や行動を細かく識別、把握する • 小さな失敗をたくさん見つけて情報を得る • 個人の責任、自分の作業を完遂する → チームの責任、全体で価値を完成する • 人は人、仕方ない → 人はつながり、変化する

Slide 169

Slide 169 text

アジャイルを “やってみる”

Slide 170

Slide 170 text

Unlearn 脱学習

Slide 171

Slide 171 text

Unlearn / 脱学習 / まなびほぐし • アジャイルに限らず、今までのやり方を変えるときに必要 • 今までのやり方＝今までに学んだことを、いったん脱ぎ捨てる • うまくいくかわからなくても、やってみる • うまくいかないとわかっていても、やってみる • 過程を精緻に分析し、知見を得る • 結果はあまり気にしない • 結果の良し悪しより、予想とのズレに注目する • 新たな学びに向け、今までの知識を壁にしない

Slide 172

Slide 172 text

超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル / イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ • 「プラクティスは難しい」を忘れずに

Slide 173

Slide 173 text

チームに任せる • 環境を与える • 場所、空間、オフィス • 機材、インフラ • 支援を与える • 他からの介入を防ぐ • 問題・課題を解消する • 信頼する • 放っておく！

Slide 174

Slide 174 text

組織を変えるか組織を作るか • 既存の組織、ルール、人の考え方、文化を変えるのは大変 • 新たに組織を作る方が簡単(な場合もある) • 出島的な部署 • 別会社 • オフィスも別にする • ゼロベースで新しいやり方に取り組めるような環境 • フルタイム • 十分な権限 • 報告させない、マイクロマネジメントしない、我慢して任せる

Slide 175

Slide 175 text

組織を変えるか組織を作るか • いまある組織を変えたい • 小さく始めて育てる • 1つのプラクティスを小規模に始める • チーム単位(3～10名程度) • 1人では続かない • 周囲が邪魔しないよう守り育てる • あなたも邪魔しないように • 成果が上がってから少しずつ広げる • 『Fearless Change』を参考に

Slide 176

Slide 176 text

メンローイノベーションズに学ぶ • 社長が最強のビジョンを持つ • XPとデザイン思考(IDEO)をベースとする • やるべきことを決め、できる人を集め、徹底的にやる • そこから新たな工夫、実験、失敗からの学びを繰り返す • 何年もかけて上手になっていく • 情熱 • 権限 • 時間

Slide 177

Slide 177 text

ユーザー価値に集中する • プロダクトの価値とエンドユーザーが得る価値を整える • 自分たちの行動、ルール、プロセスを再検討する • ユーザー価値の観点から • 「その仕事はユーザーにどう役立つの？」 • ユーザーを理解する • 観察(ハイテク人類学) • 直接会って話を聞く • ペルソナ

Slide 178

Slide 178 text

フィードバック • エンドユーザーの反応、要望、ニーズを最優先する • それ以外は調整すべき利害関係者(ステークホルダー) • エンドユーザーからチームが直接情報を得る • 行動分析 • インタビュー • ベータテスター • 情報を持ったチーム自身が決断し行動する • 自身が判断し、行動し、結果を見て、改善する • 上司・マネージャ・他部門・アナリストなどのせいにしない

Slide 179

Slide 179 text

開発技術の更改 • アジャイル20年の歴史は開発技術の進歩と表裏一体 • アジャイルなソフトウェア開発に最低限必須な技術を導入する • イテレーション単位で開発ができるスキルとテクノロジーを修得する

Slide 180

Slide 180 text

すでに常識の開発定番技法 • バージョン管理システム • ビルド自動化 • コードの共同所有 • テストの自動化 • 継続的インテグレーション(CI) • 開発環境の標準化 • コンテナ • DevOps

Slide 181

Slide 181 text

すでに常識の開発定番技法 • バージョン管理システム – 1982年(昭和57年) RCS • ビルド自動化 – 1976年(昭和51年) Make • コードの共同所有 – 1960年代(昭和40年頃) 『プログラミングの心理学』のエピソード • テストの自動化 – 1989年(平成元年) SUnit • 継続的インテグレーション(CI) – 1997年(平成9年) XP • 開発環境の標準化 – 2010年(平成22年) Vagrant • コンテナ – 2000年(平成12年) FreeBSD Jail • DevOps – 2009年(平成21年)

Slide 182

Slide 182 text

(ちょっとだけ)新しめの当たり前の技術たち • 分散バージョン管理システム – 2005年 Git • ビルド自動化システム – 2011年 Jenkins • コードの共同所有 – 2008年 GitHub • E2Eテストの自動化 – 2004年 Selenium • 継続的デリバリー(CD) – 2010年書籍”Continuous Delivery” • 開発環境の標準化 – 2010年 Vagrant • コンテナ – 2013年 Docker • DevOps – 2009年

Slide 183

Slide 183 text

変更可能な設計 • イテレーション単位で機能を完成する • ほぼすべての開発は改修・変更 • 包括的な設計・アーキテクチャ → 変更容易な設計・アーキテクチャ • 要素技術 • オブジェクト指向設計 • ドメインドリブンデザイン(DDD) • クリーンアーキテクチャ • マイクロサービス(MSA)

Slide 184

Slide 184 text

テスト自動化 • 常に変更するコードの品質を担保し続ける • 手動テストでは早期に破綻する • ソフトウェアの正しさを動作で検証する • レビューなどの手法も併用すべき • 自動化すべき領域を識別する詳しくはこちらも（宣伝) 講演動画もあります https://youtu.be/vrbMKbdV6xY https://speakerdeck.com/yattom/tesutofalsezi-dong-hua-totesutoqu-dong-kai-fa

Slide 185

Slide 185 text

継続的デリバリー • 開発作業から本番リリースまでの過程を自動化し、継続実行する • 属人性(人の作業や確認)を減らす • 手順書 → 自動化する • チェックシート → 自動化する • レビュー → 機械的チェックや正しさの確認は自動化する • テスト → 手順で進めるテストは自動化する • リリース作業 → ワンタッチで完結するよう自動化する • 人間性を生かす作業に時間を使う • 議論する • もっとよいアイデア、設計、手法を見つける • 不要な機能、手順、プロセスを削減する • 思いもよらない問題、バグを探索する https://www.amazon.co.jp/dp/B074BQQ96X

Slide 186

Slide 186 text

技術やツールの権限を与える • チーム自身が、ユーザー価値に最適な技術やツールを選定する • 会社ルール、取引先都合、新しもの好きの誰かなどに振り回されない • 新しい技術やツールに工数を確保する • 調査、学習、実験する時間 • 既存コードを適合させる時間 • うまくいかなかったとき切り戻す時間 • チームの挑戦と成長に価値をおく • 長い目でユーザー価値につながる

Slide 187

Slide 187 text

いきいきと働く • ユーザー価値に集中する • 大局的プロダクト価値を目標とする • ツール、プロセス、プラクティスに挑戦し、習熟する • 個々人が自律的に能動的に働く • チームとして個人の能力の総和以上の結果を出す • 他からの介入は最低限 • 仕事に「Joy」があふれる

Slide 188

Slide 188 text

No content

Slide 189

Slide 189 text

individuals and interactions

Slide 190

Slide 190 text

2001年ごろアジャイルと出会い、開発者、チームリーダー、トレーナー、導入支援と多様な立場で関わってきた。(株)永和システムマネジメントにて2010年頃からアジャイルコーチを主軸として活動。2014年独立。プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング現場導入支援スクラムマスター支援ふりかえりアジャイルコーチ (ものづくり面) モブプログラミングテスト駆動開発テスト自動化学びのゲームをデザイン、製作、デリバリー宝探しアジャイルゲームカンバンゲーム心理的安全性ゲーム tsutomu.yasui@gmail.com twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ) アジャイルコーチに手伝ってもらう

Slide 191

Slide 191 text

質問への回答 • Mentimeterのほうに書き込んでください

Slide 192

Slide 192 text

おすすめ書籍など • 『アジャイル開発とスクラム第2版』平鍋健児野中郁次郎及部敬雄 https://is.gd/qOh1f5 • アジャイル開発やスクラムの概要や全体像、企業から見てどういうメリットがあるのか • 『アジャイルサムライ』Jonathan Rasmusson https://is.gd/K9zZf4 • アジャイル開発を実際に始める方法 • 『スクラムブートキャンプTHE BOOK』西村、永瀬、吉羽 https://is.gd/zmKM7q • スクラムの実際のやりかたについて気軽に学べる • 『アジャイルな見積りと計画づくり』Mike Cohn https://is.gd/lBZ6aN • 価値を生み出す計画をアジャイルに作り、進める方法 • 『レガシーコードからの脱却』 David Scott Bernstein https://is.gd/6vAgjt • 技術的側面からアジャイルに必須の技法を解説

Slide 193

Slide 193 text

アンケート: なにをやりたくなりましたか？ • 以上の話を踏まえて、いまやりたいこと、やってみたくなったことを自由に書いてください。複数回答できます(送信したあと追加で回答できます) • 時間が余ったら好きな音楽や動画、テレビや映画について書いてください • 録画視聴の方も、手元に書き出してみてください