結局スクラムってなんなの?

アジャイルひよこクラブ 2017年12月定例イベント講演資料

1. 結局スクラムって何なの? Kiro Harada Attractor Inc. アジャイルひよこクラブ 2017/12/21
3. New New Product Development Game (1986) https://hbr.org/1986/01/the-new-new-product-development-game/ar/1
4. Japan as Number 1 - 1979
6. DOD-2167A - 1988
7. 1989年 1.日本興業銀行 2.住友銀行 3.富士銀行 4.第一勧業銀行 5.三菱銀行
8. 2016年 1.Apple 2.Alphabet 3.Microsoft 4.Amazon 5.Facebook
9. “The principal object of management should be to secure the maximum prosperity for the employer, coupled with the maximum property for each employee” マネジメントの第一の目的は、 雇用者の最大限の繁栄と同時に 従業員の最大限の繁栄を確保することである。
10. “The important object of both the workmen and the management should be the training and development of each individual in the establishment, so that he can do (at his fastest pace and with the maximum of efficiency) the highest class of work for which his natural abilities fit him.” マネジメントと従業員共通の重要な目標は、 各個人の訓練と成長でなければならない。 そうすれば従業員は、自信の能力に合った 最高の仕事を(最速のペースで、最良の効率で) 成し遂げることができる。
11. 科学的マネジメント 科学的手法をプロセスのエンジ ニアリングとマネジメントに適用 することにより、 経済的効率性、とくに労働生産 性を改善する。 フレデリック・テイラー
12. 生産性を気にするようになったのは いつからか? ずっと試行錯誤を繰り返してきた。 改善を考え始めたのはいつ?
13. 1900年代初頭 生産性の向上のため専門化を推し進めた: Thinkers and Doers 考える人とやる人
14. マネージャーとワーカー
15. 製造ライン
16. マネージャにもマネージャ つけたらいいんじゃね?
17. マネジメント階層 http://commons.wikimedia.org/wiki/File:Tabulating_Machine_Co_Organization_Chart.jpg
18. めちゃくちゃ 上手くいった
19. ホーソン実験 (1924-1932) http://en.wikipedia.org/wiki/Hawthorne_effect
20. 生産性は 何で決まるのか? http://www.library.hbs.edu/hc/hawthorne/
21. 非公式組織
22. 人間関係論のはじまり
23. 組織的怠惰
24. 日本語版出ました
25. “The great majority of workmen still believe that if they were to work at their best speed they would be doing a great injustice to the whole trade by throwing a lot of men out of work.” ほとんどの労働者は、最高のスピードで仕事を すると同僚に大迷惑をかけることになると、いま だに信じている。同僚の仕事を奪ってしまうと考 えているのだ。 The principles of scientific management - Frederick Taylor
26. 自己管理-自己組織化 自律について考えはじめたのはいつ?
27. 無停止杼換式豊田自動織機 (1924) http://commons.wikimedia.org/wiki/File:1924_Non-Stop_Shuttle_Change_Toyoda_Automatic_Loom,_Type_G_1.jpg
28. この織機が特別な理由: たて糸やよこ糸が切れたときは、自動的に停止する 良品しか製造しない 一人で60台の自動織機を扱えるようになった。 従来の織機は、1台につき一人の職人を必要とした
29. The Machine that Changed the World (1990) 世界を変えた機械 Toyota’s Secret Weapon in the Global Car Wars Based on IMVP Phase 2 study (1984-1990)
30. 1990年
31. リーン生産方式 いかなる理由でも最終顧客の価値に直結し ないリソースの利用はムダであり、撤廃の目 標である。 the expenditure of resources in any aspect other than the direct creation of value for the end customer to be wasteful, and thus a target for elimination.
32. 7 Wastes - Muda 無駄 Transportation(運搬) Inventory(在庫) Over-Processing (加工しすぎ) Motion(動作) Over-Production (作りすぎ) Waiting(待ち) Defects(欠陥)
33. トヨタ生産システム Figure curtesy of Satoshi Kuroiwa
34. 多能工星取表 訓練予定付きのスキルマトリクス
35. TPSは、実は 製造の話ではない, むしろ 人を育てる話である。
36. TPSは どうやって生まれたか?
37. 無停止杼換式豊田自動織機 (1924) http://commons.wikimedia.org/wiki/File:1924_Non-Stop_Shuttle_Change_Toyoda_Automatic_Loom,_Type_G_1.jpg
38. トヨタは 破産寸前であった 1950年頃、 労働争議の結果、実質的な創業者の豊田喜一郎も辞任 を余儀なくされた。 機械、製造ライン、パーツを買いそろえる資金もなく、 マネージャーを雇う資金もなかった。
39. TWI (Training Within Industry)プログラム (1940 - 1945)
41. To make your work あなたの仕事を、 Easier and Safer より簡単により安全に
42. Council's Committee on Work in Industry, of which Dr. Lawrence J. Henderson, Director of the Fatigue Laboratory a t H a r v a r d University, was made chairman. This committee made a n extensive rt1pol.t which called attention to three problems : (1) selection of supervisors, ( 2 ) training and development of supervisors, and ( 3 ) intensified problems of supervision arisillg from the emergency situation. I n connection with supervisory development, the committee recommended that training be directed toward "improving and accelerating the training of supervisors in handling the human situations under their charge so a s to secure maximum cooperation." When this report was received by Mr. Hillman? he asked Training Within Industry t o formulate such a training plan. Job Relations / 仕事における人間関係 T W O YEARS OF JOB RELATIONS DEVELOPMENT T W I Headquarters obtained the services of F. J. Roethlisberger and J o h n B. Fox of Harvard University and L. J. O'Rourke of the Civil Service Commission, to work with Walter Dietz, Associate Director of TWI, and other Headquarters staff nlembers i n determining a method of attack and making preliminnry plans for experimental work. Determining Supervisory Needs I n August 1941 TWI sent out a questionnaire on supervisory needs to several hundred supervisors and their own bosses. When replies to t h e supervisory questionnaire were receired i t was found t,hat
43. 戦後、TWIは 日本に導入される
44. NUMMI (現在はTesla)
45. 新たな職業: プログラマ Ada Lovelace
46. Management the Development of Large Software Systems a.k.a. ウォーターフォール
47. ソフトウェア開発を 製造工場のように http://en.wikipedia.org/wiki/KUKA#mediaviewer/File:BMW_Leipzig_MEDIA_050719_Download_Karosseriebau_max.jpg
48. うまくいかなかった Successful 14% Challenged 54% Cancelled 32% Chaos Report / 1994
49. I ANALYSIS ウィンストンロイスは PROGRAM DESIGN 何と言っていたのか? I SYSTEM I coo,.o コンセプトは I TESTING すばらしいが、 実施するには I I OPER リスクが高く Implementation steps to develop a large computer program失敗を招く for delivery to a customer. ANALYSIS PROGRAM DESIGN coo,.o TESTING Figure 2. I OPERATIONS Figure 2. Implementation steps to develop a large computer program for delivery to a customer. I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for timing,concept, storage, input/output but transfers, the etc., are experienced as distinguished from I believe inwhich this implementation described above is risky and invites failure. The analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various oblem is illustrated Figure The testing which external constraints, in then invariably a major4. redesign is required. A simple octal phase patch or redo of some isolated occurs at the end of the development cycle is the code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the Winston W. Royce (1970). "Managing the Development of Large Software st event for which timing, storage, input/output transfers, etc., areSystems" experienced asof Western distinguished from in: In: Technical Papers Electronic Show and Convention software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect (WesCon) August 25–28, 1970, Los Angeles, USA. in 1970 alyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partia and/or costs. the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule One might note that there has been a skipping-over of the analysis and code phases. One cannot, of
50. ソフトウェア危機 The Oregon Experiment (1975) , Christopher Alexander
51. クリストファー アレグザンダー
52. パターン ランゲージ (1977)
53. 時を超えた 建築の道 (1979)
54. "At the core... is the idea that people should design for themselves their own houses, streets and communities. This idea... comes simply from the observation that most of the wonderful places of the world were not made by architects but by the people". Christopher Alexander et al., A Pattern Language, front bookflap
55. "中心にあるのは、、、人々が自分で設計するというアイデアで す。自分の家を、通りを、コミュニティを。このアイデアがう まれたのは、世界にあるすばらしい場所のほとんどは、建築家 によってではなく、人々によって作り上げられているという観 察からです。". Christopher Alexander et al., A Pattern Language, front bookflap
56. パターンランゲージ
57. 盈進学園 東野高等学校
58. Nature of Order (2004)
59. 生命の現象
60. ソフトウェア開発にも パターンランゲージを? (1993)
61. Wiki Wiki Web
62. Hillside Group
63. Pattern Language of Programs (PLoP)
65. 組織パターン
66. 組織パターン WORK QUEUE INFORMAL LABOR PLAN DEVELOPER CONTROLS PROCESS SOMEONE ALWAYS MAKES PROGRESS COMMUNITY OF TRUST INTERRUPTS UNJAM BLOCKING PROGRAMMING EPISODE NAMED STABLE BASES ENGAGE CUSTOMERS TAKE NO SMALL SLIPS SURROGATE CUSTOMER ENGAGE QUALITY ASSURANCE GROUP VALIDATION COMPLETION HEADROOM RECOMMITMENT MEETING SCENARIOS DEFINE PROBLEM TEAM PRIDE FIREWALLS SIZE THE ORGANIZATION SELF SELECTING TEAM UNITY OF PURPOSE 3 TO 7 HELPERS PER ROLE PATRON ROLE PRODUCERS IN THE MIDDLE FEW ROLES PRODUCER ROLES ORGANIZATION FOLLOWS LOCATION HOLISTIC DIVERSITY COUPLING DECREASES LATENCY DISTRIBUTE WORK EVENLY MOVE RESPONSIBILITIES RESPONSIBILITES ENGAGE SHAPING CIRCULATION REALMS
67. コンウェイの法則 (広い意味で)システムを設計する組織 は、自身のコミュニケーション構造と同 じ構造を持つ設計を生み出してしまう。 —M. Conway
68. 組織のアーキテクチャと 製品のアーキテクチャ
69. OODA ループ - 1976 http://en.wikipedia.org/wiki/OODA_loop
70. 制御理論
71. 経験的プロセス
72. New New Product Development Game (1986) https://hbr.org/1986/01/the-new-new-product-development-game/ar/1
73. New New Product Development Game (1986) Built-in instability Self-organizing project teams Overlapping development phases Multilearning Subtle control Organizational transfer of learning https://hbr.org/1986/01/the-new-new-product-development-game/ar/1
74. 知識創造企業 - 1995 How Japanese Companies Create the Dynamics of Innovation
75. SECI プロセス SECI, Ba and Leadership: a United Model of Dynamic Knowledge Creation Ikujiro Nonaka, Ryoko Toyama and Noboru Konno
76. 場としての コミュニティ
77. “A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.” -Robert A. Heinlein
78. “人間はなんでもできるべきだ−おむつを取り替え、 侵略をもくろみ、豚を解体し、船の操舵を指揮し、 ビルを設計し、ソネットを作り、貸借を清算し、 壁を築き、骨をつぎ、死にかけている者をなぐさ め、命令を受け、命令を与え、協力し、単独で行 動し、方程式を解き、新しい問題を分析し、肥料 をまき、コンピュータをプログラミングし、うま い食事を作り、能率的に戦い、勇敢に死んでいく こと。専門分化は昆虫のためにあるものだ。” R.A.ハインライン
79. 専門化を止めて 生産性品質を改善しよう 人々はもともと多能工である 人々の小集団の力 改善マインド
80. Scrum 1990’s EASEL Company (Jeff Sutherland) ADM Company (Ken Schwaber) 1995 OOPSLA Paper 2002 Agile Project Management with Scrum (Ken and Mike Beedle)
81. Scrum: 順序づけられたバックログ 固定されたタイムボックス Demo or Die スウォーミング
82. Agile Manifesto We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items onthe right, we value the items on the left more.
83. The Toyota Way (2003)
84. ScrumPLoP (2010- )
87. http://qz.com/196200/toyota-is-becoming-more-efficient-by-replacing-robots-with-humans/
88. スクラム より良い手法を探し、うまく行った実績のある手法 を取り込んできた結果、このような姿に スクラムは、何が正しいかを伝えはしない スクラムは、あなたがチームと一緒により良い方法 を見つけるのを助ける仕組み
89. これからのScrum Scrumがあなたに求めること: 他から学び続けましょう。実践・練習を続けましょう 学びを他の人に伝えましょう 再利用可能な知識を生み続け、製品、プロセス、組織、チーム、 そして自分自身を改善し続けましょう。より生成的に、より生き 生きと。 スクラムはこのように作られたし、今後も、そうやって改善されて 行くはず
No comments...
アジャイルコーチ、ドメインモデラ、サプライチェーンコンサルタント。認定スクラムプロフェッショナル。 外資系消費財メーカーの研究開発を経て、2004年よりスクラムによる開発を実践。ソフトウェアのユーザーの業務、ソフトウェア開発・運用の業務の両方を、より楽に安全にする改善に取り組んでいる。