スクラムフェス大阪2022基調講演「クリーンスクラム―基本に立ち戻れ―」

74.5K Views

June 17, 22

スライド概要

https://confengine.com/conferences/scrum-fest-osaka-2022/proposal/16830

シェア

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

各ページのテキスト
1.

クリーンスクラム ―基本に立ち戻れ― 2022年6月17日 スクラムフェス大阪 2022 ワイクル株式会社 角征典 (かど まさのり) @kdmsnr kado.masanori@waicrew.com

2.

大事なことは最初に アンクルボブの新刊も是非読んでみてください! 翻訳版がでるよ 2

3.

アンクルボブ is 誰? 3

4.

アンクルボブ is 誰? https://en.wikipedia.org/wiki/Robert_C._Martin

5.

アンクルボブ is 誰? I went on to develop a twoday ScrumMaster course, the rst of which was conducted at ObjectMentor in Chicago in 2002. 私(ケン)は2日間のスクラム Robert C. Martin マスターのコースを開発し た。最初のコースは2002年に シカゴのObjectMentor(ア ンクルボブの会社)で実施さ れた。 https://www.scrum.org/about fi 5

6.

自己紹介 ‣ ‣ 角 征典(@kdmsnr) • 技術書の翻訳・執筆 • 「スクラムガイド」の翻訳 ワイクル株式会社 代表取締 • ‣ 東京工業大学 環境・社会理工学院 特任講師 • ‣ アジャイル開発/リーンスタートアップの導入支援 エンジニアのためのデザイン思考 カンファレンスの講演は滅多にやらないです 💦 6

7.

ひさしぶりのスクラムの講演 🏉 7

8.

テーマ 「基本に立ち戻れ」 8

9.

今日お話すること「基本に立ち戻れ」 1. なぜスクラムはうまくいくのか? 2. スクラムガイドに書かれていない大事なこと 3. 規律とクラフトマンシップ TODO: スライドのURLを貼る 9

10.

1. なぜスクラムはうまくいくのか?

11.

行動経済学の死 https://www.thebehavioralscientist.com/articles/the-death-of-behavioral-economics Japanese: https://gist.github.com/technohippy/68c8634700e681b5da6db01aa9996149 関連記事:https://note.com/fromdusktildawn/n/nbecfb941b31e 11

12.

再現性の危機(2010s〜) 91%が「危機的な状況にある」 出典:Nature Japan Nature ダイジェスト Vol. 13 No. 8 News Feature 「再現性の危機」はあるか?−調査結果− 12

13.

再現性の危機(?) スクラム導入の58%が失敗している。 58% of Scrum implementations fail. by Je Sutherland https://www.scruminc.com/better-scrum-with-essence/ ff 13

14.

そもそもスクラムとは? 複雑な問題に対応する 適応型のソリューションを通じて、 人々、チーム、組織が価値を生み出すための 軽量級フレームワークである。 14

15.

プロジェクトの複雑性 1. 構造的複雑性 | 規模、依存関係、短納期 2. 社会政治的複雑性 | 利害関係者との人間関係、政治、権力 3. 創発的複雑性 | 想定していなかったリスク Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. 15

16.

「基本に立ち戻れ」 16

17.

なぜスクラムはうまくいくのか? 17

18.

なぜスクラムはうまくいくのか? * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. 18

19.

なぜスクラムはうまくいくのか? * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. 19

20.

さっきの複雑性を当てはめると? ▶計画と制御で対応 構造的複雑性 ▶関係づくりで対応 社会政治的複雑性 創発的複雑性 ▶適応性で対応 * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. * Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. 20

21.

スクラムの要素を当てはめると? ▶計画と制御で対応 スプリントプランニング プロダクトバックログ 構造的複雑性 スプリントレトロスペクティブ ▶関係づくりで対応 社会政治的複雑性 スプリントレビュー スプリントプランニング プロダクトバックログ インクリメント スクラムチーム 創発的複雑性 スプリント PO SM ▶適応性で対応 デイリースクラム スプリントバックログ * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. * Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. * Schwaber, K., & Sutherland, J. (2020). The scrum guide. 21

22.

3つの複雑性を さらに解消してみる 22

23.

スクラムの要素を当てはめると? ▶計画と制御で対応 スプリントプランニング プロダクトバックログ 構造的複雑性 スプリントレトロスペクティブ ▶関係づくりで対応 社会政治的複雑性 スプリントレビュー スプリントプランニング プロダクトバックログ インクリメント スクラムチーム 創発的複雑性 スプリント PO SM ▶適応性で対応 デイリースクラム スプリントバックログ * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. * Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. * Schwaber, K., & Sutherland, J. (2020). The scrum guide. 23

24.

「社会政治的複雑性」はたぶんもっと複雑 ‣ 一緒に計画したりレビューしたりするだけで、解消されると思う? • おそらく無理では? スクラムでは不十分では?🤔 24

25.

「社会政治的複雑性」はたぶんもっと複雑 ‣ 一緒に計画したりレビューしたりするだけで、解消されると思う? • おそらく無理では? スクラムでは不十分では?🤔 ‣ スクラムが日本の文化に合っていない可能性が指摘されている: • > スクラムの3本柱のひとつ「透明性」は、日本の「和」を乱す危険性がある。 日本では、明瞭さよりも調和や面子が優先される。たとえば、明示的に 「ノー」を言わずに、沈黙や間接的な表現で「ノー」を伝える。 「次の会議で回答する」と約束しておきながら、いざ予定を立てようとする と、いつまでたっても都合がつかない。 25

26.

「社会政治的複雑性」はたぶんもっと複雑 • > 会議は決定を発表する場であり、議論する場ではない。決定は日本の園芸 技術「根回し」で行われる。日本人は決断を急がされることを嫌う。 • > 根回しの合意は現実性と柔軟性を兼ね備えており、書き換え可能である。 契約交渉や計画に従うことよりも、長期的な人間関係が重要なのである。 • > だが、こうした人間関係重視の古い考え方は「昭和」と呼ばれ、若い世代 はより多くの自由、余暇、経験を求めている。 Califano, G., & Spinks, D. (2021). Adopting Agile Across Borders. Apress. 26

27.

スクラムの要素を当てはめると? ▶計画と制御で対応 スプリントプランニング プロダクトバックログ 構造的複雑性 スプリントレトロスペクティブ ▶関係づくりで対応 社会政治的複雑性 スプリントレビュー 根回し スプリントプランニング プロダクトバックログ インクリメント スクラムチーム マネジメントが関与しない技術力? 創発的複雑性 スプリント PO SM ▶適応性で対応 デイリースクラム スプリントバックログ * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. * Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. * Schwaber, K., & Sutherland, J. (2020). The scrum guide. 27

28.

「反応性」を測定する 4 Key Metrics で評価するとよさそう ‣ デプロイの頻度 | 組織による正常な本番環境へのリリースの頻度 ‣ 変更のリードタイム | commit から本番環境稼働までの所要時間 ‣ 変更障害率 | デプロイが原因で本番環境で障害が発生する割合(%) ‣ サービス復元時間 | 組織が本番環境での障害から回復するのにかかる時間 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance 28

29.

スクラムの要素を当てはめると? ▶計画と制御で対応 スプリントプランニング プロダクトバックログ 構造的複雑性 スプリントレトロスペクティブ ▶関係づくりで対応 社会政治的複雑性 スプリントレビュー 根回し スプリントプランニング プロダクトバックログ インクリメント スクラムチーム 創発的複雑性 スプリント PO SM ▶適応性で対応 デイリースクラム スプリントバックログ 4 Key Metrics * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. * Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. * Schwaber, K., & Sutherland, J. (2020). The scrum guide. 29

30.

「継続的改善」の判断基準 パターン#91. 幸福指標(Happiness Metric) • 改善活動が増えることで、チームの仕事に対する情熱が薄れてしまうので あれば、チームの情熱が高い順に優先順位をつける。 「昭和」の “自己犠牲的” はNG ※幸福は定義も測定も扱いも難しい 30

31.

スクラムの要素を当てはめると? ▶計画と制御で対応 スプリントプランニング プロダクトバックログ 構造的複雑性 スプリントレトロスペクティブ 幸福指標 ▶関係づくりで対応 社会政治的複雑性 スプリントレビュー 根回し スプリントプランニング プロダクトバックログ インクリメント スクラムチーム 創発的複雑性 スプリント PO SM ▶適応性で対応 デイリースクラム スプリントバックログ 4 Key Metrics * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. * Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. * Schwaber, K., & Sutherland, J. (2020). The scrum guide. 31

32.

まとめ ‣ プロジェクトの3つの複雑性 • 構造的複雑性、社会政治的複雑性、創発的複雑性 ‣ スクラムには3つの複雑性に対応する要素が含まれている • ただし、スクラムだけではうまくいかない可能性がある ‣ たとえば、以下の3要素を追加してみてはどうか? • 根回し、4 Key Metrics、幸福指標 ‣ スクラムに適さない「昭和」感をどれだけ排除することができるか? 32

33.

2. スクラムガイドに 書かれていない大事なこと

34.

2015年〜 東京工業大学EDP 34

35.

東京工業大学EDP E/エンジニアリング D/デザイン P/プロジェクト フィールドリサーチ 製作 プロトタイピング プロダクトスケッチ プロジェクト活動 35

36.

2021年度EDP「ひーたんす」 Panasonic + KOMATSU: 災害と日常が隣り合う未来で、「災害に備えない」製品体験をデザインせよ https://medium.com/titech-eng-and-design/3c906733ad42 36

37.

2021年度EDP「窓のキャンバス」 YKKAP: 自宅での働くと暮らすを健やかにする窓体験をデザインせよ https://medium.com/titech-eng-and-design/ee9813b2caee 37

38.

東工大EDPの授業デザイン ‣ 多様性のあるチームづくり • 東工大生(M1/融合理工学系)、美術系大学生、社会人受講生 ‣ 2週間スプリントでデザイン思考の5ステップを全部やる • 共感、定義、発想、プロトタイプ、テスト • 成果物(ユーザーテストが終わったプロトタイプ)を発表 ‣ 自律的なチームとメンタリング(教員 + パートナー企業) • Discordでいつでも相談可能 38

39.

【宣伝】今年度のパートナー企業募集中 https://edp.esd.titech.ac.jp/partners/ 39

40.

さっきの図をもういちど ▶計画と制御で対応 スプリントプランニング プロダクトバックログ 構造的複雑性 スプリントレトロスペクティブ 幸福指標 ▶関係づくりで対応 社会政治的複雑性 スプリントレビュー 根回し スプリントプランニング プロダクトバックログ インクリメント スクラムチーム 創発的複雑性 スプリント PO SM ▶適応性で対応 デイリースクラム スプリントバックログ 4 Key Metrics * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. * Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. * Schwaber, K., & Sutherland, J. (2020). The scrum guide. 40

41.

「自己組織化」という包括的な概念 ※スクラムガイドでは「自己管理型」に変更された "集団が自己組織化能力を持つのは「自律性」「自己超越」「異種交配」の 3つの条件が備わったときである。" [Takeuchi & Nonaka, 1986] ‣ 自律性 | チームが自由に方向性を決める ‣ 自己超越 | 限界を探究して、目標をさらに高める ‣ 異種交配(多様性) | 専門分野、思考、行動様式が異なるメンバー Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard business review, 64(1), 137-146. 41

42.

創造性を「殺す」には 同質的なチームを編成すればいい😈 Amabile, T. M. (1998). How to kill creativity. Harvard Business Review on breakthrough thinking, 1-29. 42

43.

「基本に立ち戻れ」 43

44.

複雑な問題を扱うスクラムのチームに 創造性を発揮する「多様性」はあるか? 44

45.

多様性と不確実性 ‣ 機能的多様性は、チームパフォーマンスに正の影響を与える ‣ 属性的多様性は、チームパフォーマンスと有意に関連しない Horwitz, S. K., & Horwitz, I. B. (2007). The effects of team diversity on team outcomes: A meta-analytic review of team demography. Journal of management, 33(6), 987-1015. ‣ プロジェクトの不確実性が高いほど、 多様性→創造性の影響が大きくなる Dayan, M., Ozer, M., & Almazrouei, H. (2017). The role of functional and demographic diversity on new product creativity and the moderating impact of project uncertainty. Industrial Marketing Management, 61, 144-154. 45

46.

2021年度EDP「窓のキャンバス」の多様性 YKKAP: 自宅での働くと暮らすを健やかにする窓体験をデザインせよ 東工大生 社会人 美大生 東工大生 東工大生 https://medium.com/titech-eng-and-design/ee9813b2caee 46

47.

多様性と知識創造スパイラル ‣ チームで多様性を生むには、個人単位での「知識創造」が必要 • 知識創造と言えば「SECIモデル」 ‣ SECIモデルなので「共同化」から始まるが「内面化」のほうが先では? • > 新しい知識はいつも個人から始まり (snip)組織全体にとって大事な知識 に変換される • > 独自のアイデアが自律的な個人から 生まれ、チームの中に広まり、 やがて組織全体のアイデアとなる 野中郁次郎, 竹内弘高. (1996). 知識創造企業. 東洋経済新報社. 47

48.

内面化をうまくやるには? ‣ 「グっとくる」ものを見つける(DS:どうかしている) ‣ 検索しても「出てこない言葉」で名前をつける ‣ 自分を洗脳する • 自分なくし、無駄な努力 • 「〜ブーム」「〜プレイ」をつける • 不安タスティック!、でも やるんだよっ! 48

49.

野中郁次郎とみうらじゅんを 結び付けたのは世界で私だけでは? 49

50.

DS(どうかしている)人がいると チームに多様性が生まれ SM(スクラムマスター)が必要になる 50

51.

【協力募集】SMの研究してます https://research.kdmsnr.com/ 51

52.

チームコーチングの理論 Hackman, J. R., & Wageman, R. (2005). A theory of team coaching. Academy of management review, 30(2), 269-287. 52

53.

コーチングのタイミング コーチングの3つの機能には、それぞれ最も効果を発揮するタイミングがある ‣ 開始時 | 動機付けのコーチング(場の設定) ‣ 中間地点 | 戦略のコーチング(コンサルティング) ‣ 終了時 | 教育のコーチング(知識とスキルの向上) 人工的に「開始〜中間〜終了」のタイミングを作り、 活動のペースとコーチングの機会を生み出すべき スクラムにはスプリントがある Hackman, J. R., & Wageman, R. (2005). A theory of team coaching. Academy of management review, 30(2), 269-287. 53

54.

なぜスクラムがうまくいくのか? ▶計画と制御で対応 スプリントプランニング プロダクトバックログ 構造的複雑性 スプリントレトロスペクティブ 幸福指標 ▶関係づくりで対応 社会政治的複雑性 スプリントレビュー 根回し スプリントプランニング プロダクトバックログ インクリメント スクラムチーム DS、多様性 スプリント 開始・中間・終了 PO SM 創発的複雑性 スプリント ▶適応性で対応 デイリースクラム スプリントバックログ 4 Key Metrics * Verwijs, C., & Russo, D. (2021). A theory of scrum team effectiveness. arXiv preprint arXiv:2105.12439. * Maylor, H. R., Turner, N. W., & Murray-Webster, R. (2013). How hard can it be?: Actively managing complexity in technology projects. Research-Technology Management, 56(4), 45-51. * Schwaber, K., & Sutherland, J. (2020). The scrum guide. 54

55.

まとめ ‣ 東工大EDPというものづくり授業を7年以上やっている • 多様性、2週間スプリント、自律性 ‣ スクラムの祖父が言う「自己組織化」は包括的な概念 • 自律性、自己超越性、多様性 ‣ チームの多様性を上げるには、個人の内面化(知識創造)が起点になる • グッとくるDSものを見つけて、自分を洗脳し、行動による学習 ‣ チームに多様性があるからスクラムマスターが必要になる(そこに多様性はあるか?) • チームのタイミングを考慮したコーチングをすべき 55

56.

3. 規律とクラフトマンシップ

57.

アイデアがダメになる「3i」の流れ ‣ 最初に、他の人が気づかないようなチャンスを見 つける「イノベーター」がやってくる ‣ 次に、イノベーターを真似する「イミテーター (模倣者)」がやってくる ‣ 最後に、「イディオット(アホ)」がやってき て、革新的な技術を台なしにしてしまう。 https://hbr.org/2008/10/wisdom-of-warren-buffet-on-imi https://en.wikipedia.org/wiki/Warren_Buffett 57

58.

台なしにしない「知の規範」が必要 ‣ カオスから秩序(知識)が有機生命体組織のように生ま れてくる、というアイデアでいけるかというと、必ずし もそうではありません。そこにはある種の訓戒、規律 (Discipline)、マナーなど意思に裏づけられた知の規 範が必要になってきます。 野中郁次郎; 紺野登. 知識経営のすすめ―ナレッジマネジメントとその時代 (ちくま新書) 58

59.

プログラマーの規範とは? ‣ 規律 • テスト駆動開発、リファクタリング、シンプルな設計、 協力的プログラミング(ペア + モブ)、受け入れテスト ‣ 基準 サークルオブライフ • 生産性、品質、勇気 ‣ 倫理 • プログラマーの誓い(十戒) • 有害、誠実、チームワーク 59

60.

どうして規範が必要なのか? 8 log210 ≈ 27 75 ÷ 27 ≈ 2.8 プログラマーの人数 数億人(10^8)▶ ▼ 約3年で プログラマーが倍!? ▼ チューリングから75年▲ 常に半数が #駆け出しエンジニア Clean Coder (Clean Coders Video Series) by Robert C. Martin 60

61.

#駆け出し〜だけではない ‣ VW社が競合他社に比べて簡素な排ガス対策装置で対応でき ていたことに、かねて疑問を抱いていたからだ。疑問の答 えは、優れた技術にあったわけではなく、「いかさま」だっ た。排ガス対策装置の作動を弱める「デフィート・ソフ ト」を使い、公式試験のときにだけ、「ジェッタ」などに 搭載する排気量2.0Lのディーゼルエンジンの排ガス成分が 規制値内に収まるようにした。通常の走行時は、規制値を 大幅に超える有害な排ガス物質を垂れ流す。 https://xtech.nikkei.com/dm/atcl/news/16/080808697/ 61

62.

「基本に立ち戻れ」 62

63.

プログラマーの誓い コンピュータープログラマーの職業の名誉を守り、維持するために、 私は自分の能力と判断の限りにおいて、以下のことを約束する。 1. 私は、有害なコードを作らない。 2. 私が作るコードは、常に私の最高傑作である。振る舞いや構造に欠陥のあるコードを故意に残すことはしない。 3. 私は、コードが正常に動作する証拠をリリースごとに用意する。それは、迅速で、確実で、再現可能な証拠である。 4. 私は、誰かの進捗を妨げないように、小さく何度もリリースする。 5. 私は、あらゆる機会において、恐れることなく執拗に私の作品を改善する。決して作品を劣化させることはしない。 6. 私は、私や誰かの生産性を高めるために、できる限りのことをする。決して生産性を落とすようなことはしない。 7. 私は、他の人が私をカバーできるように、私が他の人をカバーできるように努める。 8. 私は、規模と精度の両方を正直に見積もる。合理的な確実性がないときには約束をしない。 9. 私は、仲間のプログラマーの倫理、基準、規律、スキルを尊重する。その他の属性や特性を尊重の要因にすることはしない。 10. 私は、私の技術の学習と向上を怠らない。 『Clean Craftsmanship』Bob C. Martin 63

64.

約束1:有害なコードを作らない ‣ フォルクスワーゲンのプログラマーが破ったのはこのルールだ。 ‣ 彼らのソフトウェアは雇用主(フォルクスワーゲン)に利益をもたらしたかも しれない。だが、社会一般には害をもたらした。 ‣ 我々プログラマーは、そのようなことを決してやってはならない。 『Clean Craftsmanship』Bob C. Martin 64

65.

約束5:執拗に作品を改善する ‣ 約束5には「作品」という言葉が使われている。プログラマーが作成するのは コードだけではない。設計、ドキュメント、スケジュール、計画なども作成す る。これらも継続的に改善すべき「作品」である。 ‣ どうするのか? 作品に対して「親切な行為」をすればいい。 ‣ ボーイスカウトの規則: 「チェックインするコードはチェックアウトしたときよりも美しく」 『Clean Craftsmanship』Bob C. Martin 65

66.

約束7:他の人が私をカバーできるように、 私が他の人をカバーできるように努める。 ‣ チーム全体に知識を広げよう。 ‣ 知識を広げる最善の方法は、一緒に(ペアかモブで)働くことである。 ‣ 車を運転しているときに他のドライバーを怒鳴りつけたことはないだろうか? これは「フロントガラス効果」と呼ばれる。フロントガラスを挟むと、他人の ことをバカ、マヌケ、敵だと見なすようになる。 ‣ フロントガラス効果を回避するには、1年に数回は物理的な部屋に集まる必要 がある。 『Clean Craftsmanship』Bob C. Martin 66

67.

約束10:技術の学習と向上を怠らない ‣ プログラマーは学習をやめてはならない。学ぶべき領域は事実上無限だ。我々 の業界は過去何十年かけて急速に変化している。これからもその変化はしばら く続くだろう。あなたはそれに追いつく必要がある。 ‣ 書籍やブログを読み続けよう。ビデオを観続けよう。カンファレンスやユー ザーグループに参加し続けよう。研修に行き続けよう。学習を続けよう。 ‣ 過去の偉大な作品に注目しよう。1960年代、1970年代、1980年代に書かれ た書籍は、素晴らしい洞察と情報があふれている。 『Clean Craftsmanship』Bob C. Martin 67

68.

我々が世界を支配している 社会はまだそのことを理解していない。 我々プログラマーもそのことを理解していない。 『Clean Craftsmanship』Bob C. Martin 68

69.

クラフトマンシップが求められる ‣ 「クラフトマン」とは、特定の分野に関する高度なスキルを持ち、物事を成し 遂げる人である。道具や業界に精通しており、仕事に誇りを持ち、仕事に対す る尊厳とプロ意識を持って行動できると信頼されている人である。 『Clean Craftsmanship』Bob C. Martin 69

70.

TDDはプロの前提条件 TDDを実践していなければ、プロのソフトウェア開発者になれない。 私は本気だ。というより、それが真実になりつつある。 『Clean Craftsmanship』Bob C. Martin 70

71.

年下からも学ぶ姿勢 ‣ はじめて聞いたときは懐疑的だった。みんなもそうだったはずだ。ユニットテ ストを先に書けだって?誰がそんなバカなことをするんだ? ‣ というわけで、1999年にオレゴン州メドフォードへ向かい、直接ケントから 規律を学ぶことにした。ここでの体験は衝撃的だった! ‣ Uncle Bob: 47歳?、Kent Beck:38歳? 『Clean Coder』Bob C. Martin 71

72.

クラフトマンシップとアジャイル ‣ 多くの組織では、アジャイルとスクラムが同義語になっている。 ‣ アジャイルコーチは、テクニカルプラクティスをコーチできるほどの技術スキ ルを持っていない。エンジニアリングについて話すこともほとんどない。 ‣ アジャイルと開発者はお互いに離れようとしている。 ‣ だが、どちらも高品質で高価値な成果を提供し、どちらもプロフェッショナリ ズムを求めている。この2つのムーブメントは分けるべきではない。 『Clean Agile』Bob C. Martin, Sandro Mancuso 72

73.

まとめ ‣ 自己組織化チームを作るだけでは足りない • いつか「アホ」がやってくるぞ! ‣ プログラマーの規範(規律、基準、倫理)が必要 • サークルオブライフ、プログラマーの誓い ‣ ソフトウェア開発者の社会的責任が大きくなっている • クラフトマンシップ、常に学び続ける、アジャイルの開発者離れを回避 73

74.

「基本に立ち戻れ」 私の好きな言葉です 74

75.

【宣伝】来週はXPについて話します https://uzabase-tech.connpass.com/event/249180/ 75

76.

大事なことは最後に アンクルボブの新刊も是非読んでみてください! 翻訳版がでるよ 76