Tweet
Tweet

Slide 1

Slide 1 text

コンウェイの法則と アジャイル ソフトウェア開発 ソフトウェアとそれを産み出す組織のソーシャル構造について 株式会社永和システムマネジメント 株式会社チェンジビジョン 平鍋健児 1

Slide 2

Slide 2 text

平鍋健児 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO (株)Scrum Inc. Japan 取締役 アジャイル開発を推進し、国内外で、 モチベーション中⼼チームづくり、ア ジャイル開発の普及に努める。ソフト ウェアづくりの現場をより⽣産的に、 協調的に、創造的に、そしてなにより、 楽しく変えたいと考えている。 アジャイルジャパン初代実⾏委員⻑。 第⼆版

Slide 3

Slide 3 text

◎ 本社／福井市 WeWork 沖縄 •⾦融、医療、組込み(⾃動⾞) •Web/Cloud、アジャイル開発 •社員 220名エンジニア集団

Slide 4

Slide 4 text

共創・共育で利⽤するプラクティス 4 モブプログラミング ● ⼀つのPCとディスプレイ ● 同じ課題にみんなで⽴ち向かう ● 知識伝搬が早い ● レビューも同時に⾏うことで効率的 スプリント （1〜4週間） ふりかえり ● 毎週（スプリント毎）実施 ● ⾃分たちの課題を出し合い改善策を探る ● チームワークを⽣み出す効果も 開発はすべてアジャイル

Slide 5

Slide 5 text

顧客の看板の下にチーム 5

Slide 6

Slide 6 text

150社2,000名が⾒学

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

8 2022 松⾕先⽣との出会い

Slide 9

Slide 9 text

9 線形代数の緒概念が、直感的に⼿に取るように把握できます。 機械学習の線形代数の章があります︕ ReLU による空間分割、損失関数、畳み込み、勾配降下など

Slide 10

Slide 10 text

10 https://anagileway.com/202 0/06/04/prof-gilbert-strang- linear-algebra/

Slide 11

Slide 11 text

11

Slide 12

Slide 12 text

12

Slide 13

Slide 13 text

ソフトウェア デザイン チーム デザイン 13 ?

Slide 14

Slide 14 text

今⽇のお話の地図 14

Slide 15

Slide 15 text

15

Slide 16

Slide 16 text

The Art of Readable Code 16

Slide 17

Slide 17 text

The Art of Readable Code 鍵となるアイディア • コードは理解しやすくなければならない • 他⼈が短時間で理解できるように • 第1章 理解しやすいコード 18

Slide 18

Slide 18 text

第 I 部 表⾯上の改善 • 2章 名前に情報を詰め込む • 3章 誤解されない名前 • 4章 美しさ • 5章 コメントすべきことを知る • 6章 コメントは正確で簡潔に 19

Slide 19

Slide 19 text

名前に情報を詰め込む • 類語辞典(Thesaurus)でもっとカラフルな （意図を明確に伝えられる）名前を探す 単語 代替案 send deliver, dispatch, announce, distribute, route find search, extract, locate, recover start launch, create, begin, open make create, setup, build, generate, compose, add, new 鍵となるアイディア • 明確で正確な情報密度の⾼い名前を探す努⼒を 惜しまない。 20

Slide 20

Slide 20 text

21

Slide 21

Slide 21 text

第II部 ループとロジックの単純化 • 7章 制御フローを読みやすくする • 8章 巨⼤な式を分割する • 9章 変数と読みやすさ 26

Slide 22

Slide 22 text

第III部 コードの再構成 • 10章 無関係の下位問題を抽出する • 11章 ⼀度にひとつのことを • 12章 コードに思いをこめる • 13章 短いコードを書く • 14章 テストと読みやすさ 27

Slide 23

Slide 23 text

あわせて読みたい 29 Classic Classic Classic Classic

Slide 24

Slide 24 text

30 Alexander の影響

Slide 25

Slide 25 text

Design Patterns Elements of Reusable Object-Oriented Software 31 Classic

Slide 26

Slide 26 text

Design Patterns Elements of Reusable Object-Oriented Software • ソフトウェア分野のベストセラー (1995) by GoF(Gang of Four)/Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, foreword by Grady Booch. • 建築家、Christopher Alexander の「パターン⾔語」 をWard Cunningham/Kent Beck/Grady Booch らが 最初に先導(Hillside Group)。 • 後のアジャイル(XP, Scrum)にもつながる。 • 厳格なフォーマット（いくつか流儀がある）に則って いる。 • 過去に繰り返し使われた、典型的な設計解を、「⽂ 脈」(Context)「問題」(Problem)「解決策」 (Solution)の組みにして、名前(Name)をつけたもの。 32

Slide 27

Slide 27 text

建築の⽅をチラ⾒ 33

Slide 28

Slide 28 text

100 歩⾏者道路 という名前 想起させる、写 真・もしくは絵 34

Slide 29

Slide 29 text

前述のパターンを ⽰し、⽂脈を提⽰ 課題を提⽰ ⾃然と外で⼈々 が肩が触れ合う くらいの社交的 な場が必要。 35

Slide 30

Slide 30 text

解決策を提⽰ 建物が「歩⾏者道 路」を形作るよう に配置。⼆階へも 直接上がれるよう に階段を。 36

Slide 31

Slide 31 text

1 ⾃⽴地域 2 町の分布 3 フィンガー状の都市と⽥園 4 農業渓⾕ 5 レース状の⽥園道路 6 ⽥舎町 7 ⽥園 8 モザイク状のサブカルチャー 9 仕事場の分散 10 都市の魔⼒ 11 地区交通区域 12 7000⼈のコミュニティ 13 サブカルチャーの境界 14 ⾒分けやすい近隣 15 近隣の境界 16 公共輸送網 17 環状道路 18 学習のネットワーク 19 商店網 20 ミニバス 21 4階建の制限 22 9パーセントの駐⾞場 23 平⾏道路 24 聖地 25 ⽔への近接 26 ライフサイクル 27 男と⼥ 28 中⼼をはずれた核 29 密度のリング 30 活動の節点 31 プロムナード 32 買物道路 33 ナイトライフ 34 乗りかえ地点 35 世帯の混合 36 公共度の変化 37 住宅クラスター 38 連続住宅 39 段状住宅 40 どこにも⽼⼈ 41 仕事コミュニティ 42 ⼯業の帯 43 市場のような⼤学 44 地区タウンホール 45 コミュニティ活動の輪 46 多店舗マーケット 47 保健センター 48 あいだの家 49 ループ状の地区道路 50 T字路 51 緑路 52 ⼈と⾞のネットワーク 53 ⼤きな⾨⼝ 54 横断道路 55 ⼩⾼い歩道 56 ⾃転⾞路と置場 57 都市の⼦供 58 カーニバル 59 静かな奥 60 ⼿近な緑 61 ⼩さな広場 62 ⼩⾼い場所 63 街頭の踊り 64 池と⼩川 65 出産所 66 聖域 67 共有地 68 つながった遊び場 69 公共⼾外室 70 墓地 71 泳げる⽔ 72 地区スポーツ 73 冒険遊び場 74 動物 75 家族 76 ⼩家族の家 77 ふたりの家 78 ひとりの家 79 ⾃分だけの住まい 80 ⾃主管理の作業場とオフィス 81 形式ぬきの⼩さな窓⼝ 82 事務室のつながり 83 師匠と弟⼦ 84 ⼗代の社会 85 店先学校 86 ⼦供の家 87 個⼈商店 88 路上カフェ 89 ⾓の⽇⽤店 90 ビアホール 91 旅⼈の宿 92 バス停 93 屋台 94 ⼈前の居眠り パタン⾔語（町） 37

Slide 32

Slide 32 text

95複合建物 96 階数 97 ⾒えない駐⾞場 98 段階的な動線領域 99 おも屋 100 歩⾏者道路 101 通りぬけ街路 102 ⾒分けやすい⼊り⼝ の集まり 103 ⼩さな駐⾞場 104 敷地の修復 105 南向きの屋外 106 正の屋外空間 107 光の⼊る棟 108 つながった建物 109 細⻑い家 110 正⾯⽞関 111 ⾒えがくれの庭 112 ⼊⼝での転換 113 ⾞との接続 114 段階的な屋外空間 115 ⽣き⽣きとした中庭 116 カスケード状の屋根 117 守りの屋根 118 屋上庭 119 アーケード 120 歩⾏路と⽬標 121 歩⾏路の形 122 建物の正⾯ 123 歩⾏者密度 124 ⼩さな⼈だまり 125 座れる階段 126 ほぼ中央の焦点 127 親密度の変化 128 屋内の陽光 129 中⼼部の共域 130 ⽞関室 131 通りぬけ部屋 132 短い廊下 133 舞台のような階段 134 禅窓 135 明暗のタピストリー 136 夫婦の領⼟ 137 ⼦供の領⼟ 138 東まくら 139 農家⾵キッチン 140 街路を⾒おろすテラス 141 ⾃分だけの部屋 142 くつろぎ空間の連続 143 ベッド・クラスター 144 ⼊浴室 145 ⼤物倉庫 146 柔軟な事務空間 147 会⾷ 148 ⼩さな作業集団 149 親しみやすい受付 150 待ち合わせ場所 151 ⼩さな集会室 152 半私的な事務室 153 貸せる部屋 154 ⼗代の離れ 155 ⽼⼈の離れ 156 腰をすえた仕事 157 家庭ワークショップ 158 ⻘空階段 159 どの部屋も⼆⾯採光 160 建物の外縁 161 ⽇のあたる場所 162 北の⾯ 163 ⼾外室 164 道路にむかう窓 165 街路への開⼝ 166 外廊 167 ⼀間バルコニー 168 ⼤地へのなじみ 169 段上の斜⾯ 170 果樹 171 ⽊のある場所 172 野⽣の庭 173 庭囲い 174 格⼦棚の散歩道 175 温室 176 庭の腰掛 177 菜園 178 コンポスト 179 アルコーブ 180 窓のある場所 181 炉⽕ 182 ⾷事の雰囲気 183 作業空間の囲い 184 台所のレイアウト 185 くるま座 186 ざこ寝 187 ふたりのベッド 188 ベッド・アルコーブ 189 着がえ室 190 天井⾼の変化 191 屋内空間の形 192 ⽣活を⾒おろす窓 193 半開の壁 194 室内窓 195 階段の容積 196 隅のドア 197 厚い壁 198 部屋ざかいのクロゼット 199 ⽇のあたるカウンター 200 浅い棚 201 腰⾼の棚 202 造りつけの腰掛 203 ちびっ⼦のほら⽳ 204 開かずの間 パタン⾔語（建物） 38

Slide 33

Slide 33 text

205 ⽣活空間に したがう構造 206 無駄のない構造 207 ふさわしい材料 208 順に固める構造 209 部屋の割り付け 210 床と天井の割り付け 211 外壁の厚み 212 隅の柱 213 補強柱の配分 214 根のような基礎 215 ⼀階の床版 216 ボックス柱 217 がわ梁 218 構造膜 219 床・天井ヴォールト 220 屋根ヴォールト 221 ⾃然なドアと窓 222 低い窓台 223 深い窓枠 224 低い⼾⼝ 225 厚い縁どりの枠 226 柱のある場所 227 柱の接合部 228 階段ヴォールト 229 配管スペース 230 輻射暖房 231 屋根窓 232 屋根飾り 233 床⾯ 234 重ね張りの外壁 235 柔らかい内壁 236 いっぱいに開く窓 237 ⼩窓つきの厚いド ア 238 柔らげた光 239 ⼩割りの窓ガラス 240 半インチの⾒切り 縁 241 腰掛の位置 242 ⽞関先のベンチ 243 座れるさかい壁 244 キャンバス屋根 245 さわれる花 246 つる植物 247 すき間だらけの舗⽯ 248 柔らかいタイルと レンガ 249 装飾 250 暖かい⾊ 251 まちまちの椅⼦ 252 明かりだまり 253 ⾃分を語る⼩物 パタン⾔語(施⼯) 39

Slide 34

Slide 34 text

• プロムナード、⼩⾼い歩道、、、 町 • 歩⾏者道路、ちびっこのほら⽳ 建物 • 座れるさかい壁、明かりだまり 施⾏ パタン⾔語 40

Slide 35

Slide 35 text

41

Slide 36

Slide 36 text

42

Slide 37

Slide 37 text

•Pattern Oriented Software Design(POSA) •Clean Architecture, Domain Driven Design アーキテクチャ •Analysis Patterns, Real-Time UML(3rd) 分析 •Design Patterns(GoF), Real-Time Design Patterns 設計 •Smalltalk Best Practice Patterns, Advanced C＋＋, CODE COMPLETE, Programming Pearls, Test-Driven Development, Refactoring • Readable Code, Clean Code, Pragmatic Programmers, Test-Driven Development, Test-Driven Development in Embedded C コードレベル ソフトウェアのパターンの書籍は多い（粒度⼤→粒度⼩） • Classics / Modern / Embedded 43

Slide 38

Slide 38 text

Design Patterns Elements of Reusable Object-Oriented Software 44 Classic

Slide 39

Slide 39 text

デザインパターンの形式 項⽬ 内容 名前 パターンの名前．および後述するカテゴリ ⽬的 解こうとしてる「問題」と「解決」の原理 別名 良く知られた別名 動機 どのような状況で問題が発⽣するか具体例やストーリ 適⽤可能性 どのような状況で適⽤できるか 構造 パターンの構造を⽰すクラス図 構成要素 クラス・オブジェクトの責任分担 協調関係 構成要素がどのように強調するか 結果 パターンが問題の解決にどう貢献するか．トレードオフ 実装 実装にす場合の注意点 サンプル コード コードの例⽰ 使⽤例 実際のシステムで利⽤されている例 関連するパ ターン 他の密接に関連するパターン 45

Slide 40

Slide 40 text

例: Singleton • 「⽬的」 “あるクラスに対してインスタンスが１つしか存在しないことを保証し，そ れにアクセスするためのグローバルな⽅法を提供する．” ここには，「クラスに対してインスタンスが１つしか存在しないことを保証す るには， どうしたらよいか」という問題が書かれている．しかし，このよう な問題の記述は抽象的であることが多く， パターンによっては理解するのが 難しい場合もある．「問題」の理解を助けるのが， 「動機」の記述である． 「動機」は，実際にそのような問題が起こる状況， すなわち⽂脈が，具体的 な例を伴って書かれている． • 「動機」 そのような状況の説明、その例として，プリンタスプーラ，ファイルシス テム， ウィンドウマネージャ，などの例が挙げられている． まず「⽬的」と「動機」を読み， そのパターンが解こうとしている「問題」 とそれが発⽣する「⽂脈」を理解する． そして，そのような状況に⾃分が置 かれたときに， このパターンを思い出せるようにしておく必要がある． 46

Slide 41

Slide 41 text

47 http://p-monster.hatenablog.com/archive/category/デザインパターン Singleton (例︓ウィンドウマネジャ) たった⼀つのインスタンスを保証 • Singleton Class • インスタンスが１個しか存在しないことをプログラム 上で表現するには、コンストラクタをプライベートに し、外部でnewできなくする。 • ⾃分⾃⾝のインスタンスをstaticで持ち、コンストラク タを⾮公開にする。Singleton の getInstance() で、 staticでたった⼀つのインスタンスへの参照をクライア ントに返す。 • [⽬的] あるクラスに対してインスタンスが１ つしか存在しないことを保証し，それにアク セスするためのグローバルな⽅法を提供する．

Slide 42

Slide 42 text

23 パターンの分類 48

Slide 43

Slide 43 text

デスクトップのファイルを例に • ファイル、フォルダ(ディレクトリ)、 ショートカット、アプリケーション • 「⽊構造」を持つもの「代理」として機 能するもの 49

Slide 44

Slide 44 text

50 Proxy パターン (例︓ファイルとショートカット) 軽い代理を⽴てる

Slide 45

Slide 45 text

51 Composite パターン (例︓ファイルとフォルダ) 中⾝と容器の同⼀視

Slide 46

Slide 46 text

52 組み合わせた例

Slide 47

Slide 47 text

53

Slide 48

Slide 48 text

54

Slide 49

Slide 49 text

SOLID Principles 55 Classic

Slide 50

Slide 50 text

Pictures by Derick Bailey https://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/ 56

Slide 51

Slide 51 text

SOLID • Single Responsibility Principle SRP • Open-Closed Principle OCP • Liskov Substitution Principle LSP • Interface Segregation Principle ISP •Dependency Inversion Principle DIP By Robert C. Martin 57

Slide 52

Slide 52 text

58

Slide 53

Slide 53 text

SRP(Single Responsibility Principle) 定義 クラスに変更が起こる理由は、⼀つである べき。(A class should have only one reason to change.) ※元々は、「責務が1つ」であるべきの意味で「凝集度が⾼い」モジュールになる。 現代的には、より具体的に「変更のソース」が2つ以上あるなら、分離せよということ。 59

Slide 54

Slide 54 text

60

Slide 55

Slide 55 text

OCP(Open/Close Principle) 定義 クラスは、変更することなく振る舞いを拡 張できなくてはらない(You should be able to extend a classes behavior, without modifying it.) 61 クラスの継承と、多態性をつかうことでクラスを拡張できるしくみ。 Bertrand Meyerの「オブジェクト指向⼊⾨」 が初出。

Slide 56

Slide 56 text

typedef struct { int x, y; } Point; typedef struct { Point p1, p2; } Line; typedef enum { LINE, POINT } Kind; typedef union { Point* point; Line* line; } ShapeUnion; typedef struct { Kind kind; ShapeUnion of; } Shape; void draw(Shape* shape) { switch(shape->kind) { case LINE: /* draw line (shape->of->line.p1 ---- shape->of->line.p2) */ break; case POINT: /* draw point (shape->of->point)*/ break; } } コードを変更しないと拡張できないコード 62

Slide 57

Slide 57 text

// shape.h class Shape { public: virtual void draw() const = 0; }; コードを変更しなくても（再コンパイルもなしで）拡張できるコード ※ただし、LSPを満たしていることが条件（”Line” is-a “Shape”) // point.h #include “shape.h” class Point : public Shape { int x, y; public: void draw() const { /* draw point (x,y) */ } }; // line.h #include “shape.h” class Line : public Shape { Point p1, p2; public: void draw() const { /* draw line p1-p2 */ } }; 63

Slide 58

Slide 58 text

64

Slide 59

Slide 59 text

LSP(Liskov Substitution Principle) 定義 派⽣クラスは、それを利⽤するコードから みて基底クラスと交換可能でなければなら ない (Derived classes must be substitutable for their base classes.) ※基底クラスが型指定してある変数の場所には、将来、そのどの派⽣クラスのイン スタンスが⼊ってきても正しく動作するように、クラス継承の意味を正しく維持し なくてはならない。 65

Slide 60

Slide 60 text

#include “shape.h” void drawAllShapes (const vector& shapes) { for (const Shape *s: shapes) s->draw(); } このコードは、Shape の派⽣クラスのどんなものが渡ってきても、その知識なしに 動作しなければならない。そのように、Shape とその派⽣クラスは設計されて いなければならない。 ※どのような派⽣クラスがShapeに追加されようが、この関数は再コンパイル なしで動作する。（C++/Javaでは、プログラマが設計したクラス階層をコンパイ ラが補助する。） 66

Slide 61

Slide 61 text

67

Slide 62

Slide 62 text

ISP(Interface Segregation Principle) 定義 利⽤者は⾃分が使わないメソッドに依存す ることを強制されない(Clients should not forced to depend on methods that they don't use.) ※インターフェイスを太らせてはいけない、別⽤途のインターフェイスは分離せよ。 C++では多重継承もしくは別のアダプタクラス、Java では interface を利⽤。 68

Slide 63

Slide 63 text

インターフェイスを 分離したシンプルな例 さらにアダプタで 分離した例 69

Slide 64

Slide 64 text

70

Slide 65

Slide 65 text

DIP(Dependency Inversion Principle) 定義 実装の具体に依存してはならない。抽象に 依存せよ (Depend on abstractions, not on concretions.) ※特にフレームワークの設計などでは、「呼び出しの⽅向」と「依存の⽅向」が逆転 することがあります。現代的には、テスト容易性を⾼めるために、”Inversion of Control”や”Dependency Injection”といった⼿法が使われます。昔は、関数ポインタ を渡すことで下位のレイヤから上位のモジュールを「コールバック」してもらう、と いう⼿法がよく取られました。現代では、Observerパターンでインターフェイス（こ こでいう抽象）に依存させて呼び出しと依存の向きを反転させます。 ちなみに、コールバックはJavaではListener、C#ではdelegateと呼ばれます。 71

Slide 66

Slide 66 text

72

Slide 67

Slide 67 text

Design Analysis Architecture 73

Slide 68

Slide 68 text

Analysis Patterns 74 Classic

Slide 69

Slide 69 text

責任関係(Accountability) Person（個⼈）とOrganization(法⼈)が持っている 情報が同じことが多い。（ダブリを感じる） Partyの導⼊ 75

Slide 70

Slide 70 text

さまざまな契約・責任関係で利⽤ 76

Slide 71

Slide 71 text

その他にも…Header-Detail https://areyoumodeling.com/2015/02/20/uml_header_detail/ 77

Slide 72

Slide 72 text

78

Slide 73

Slide 73 text

Design Analysis Architecture 79

Slide 74

Slide 74 text

Architecture Patterns(POSA) 80 Classic

Slide 75

Slide 75 text

• Model-View-Controllerアーキテクチャパターン （MVC）は，対話型アプリケーションを3つのコンポー ネントに分割する．モデルコンポーネントは，アプリ ケーションの中核機能とデータを含むコンポーネントで ある．ビューコンポーネントは，情報をユーザに表⽰す るコンポーネントである．そして，コントローラは， ユーザの⼊⼒を取り扱うコンポーネントである．ユーザ インタフェースを実現するのは，ビューコンポーネント とコントローラコンポーネントである．更新伝播のメカ ニズムによって，ユーザインターフェースとそのモデル との⼀貫性を保証することできる． • 適⽤例 Smalltalk, MFC, ET++, …(さらにWebで多い) Model-View-Controller 81

Slide 76

Slide 76 text

Model-View-Controller 82

Slide 77

Slide 77 text

Blackboard • Blackboardアーキテクチャパターンは， 決定論的な解決戦略が分かっていない課 題に対して有効である．複数のサブシス テムが持つそれぞれの知⾒を組み合わせ ることによって，部分的，もしくは近似 的に妥当な解を得ることができる． • 適⽤例 HEARSAY-Ⅱ⾳声認識システム 83

Slide 78

Slide 78 text

Blackboard 84

Slide 79

Slide 79 text

Pipes and Filters • Pipes and Filtersアーキテクチャパターンは， データをストリームとして扱うシステムのため の構造を提供する． 個々の処理ステップは，1 つのフィルタコンポーネントにカプセル化され， データはこれらの隣接するフィルタ間をパイプ コンポーネントを介して引き渡される． フィル タの組み合わせを換えることにより，機能の類 似した⼀連のシステムを作成することができる． • 適⽤例 UNIX のコマンドとパイプ、テキスト 85

Slide 80

Slide 80 text

Pipes and Filters 86

Slide 81

Slide 81 text

87

Slide 82

Slide 82 text

構造化分析・設計 オブジェクト指向 分析・設計 RUP(96) Waterfall Agile Manifesto(01) 構造化プログラミング オブジェクト指向プログラミング 関数型プログラミング LISP(58) FORTRAN(57) COBOL(59) Java(95) Ruby(95) Perl(87) Python(91) Pascal(70) Ada(80) C(70) Smalltalk(72) Scala(03) C#(00) Haskell(90) Erlang(86) C++(83) Clojure(07) F#(02) Simula(67) Go(09) ⼿続型 オブジェクト指向 関数型 アーキテクチャ J2EE(01) RubyOnRails(04) Map/Reduce KVS ⼤型計算機-端末 クライアント サーバ インターネット/ ブラウザ クラウド UML(95) Booch OMT OOSE デザインパターン(95) Yordon DeMarco DFD アナリシスパターン(96) リファクタリング(00) Linux(91) 構造化分析・設計 オブジェクト指向 分析・設計 XP(99) Scrum(95) 1970年代 1980年代 1990年代 2000年代 2010年代 ソフトウェア開発の歴史 Agile 開発⼿法 LeanSD(03) LeanStartup(11) Microservice Multi-core GPU Swift(10) Kotlin(11) AI プログラミング⾔語 分析・設計⼿法

Slide 83

Slide 83 text

ソフトウェア開発の進化は、 マシンから⼈へ、⼈からチームへ 機械語 アセンブラ COBOL C Java C# Ruby UML アジャイル 当初、コンピュータのリソースを 操作するために、プログラミング ⾔語が作られてきた。 徐々に名前付け、抽象化ができるよう になり、⼈間の思考に近いレベルの概 念を取り扱えるように進化してきた。 名前 関数 構造体 ユーザ定義型 クラス モジュール 設計レベルや開発プロセスレベルでも、 可視化によるコミュニケーションをサポー トするようになってきた。 DSL 89

Slide 84

Slide 84 text

変わっていない重要な Design Concepts(Evergreen) 70s 70s-80s 80s-90s-2000s 構造化プログラミング 構造設計設計・分析 オブジェクト指向設計 E.Wdijkstra Harlan Mills Hoare Larry Constantine Ed Yordon David Parnus Tom Demarco Bertrand Meyer Grady Booch James Rambaugh Ivar Jacobson DFD, ERD UML(統⼀された) • “GOTO harmfull” • TOP-down design （現在も層構造とし て） • Divide by Structure • Divide and Conquer • Separation of Concerns(関⼼事の分離) • Information Hiding （情報隠蔽） • Abstraction(抽象化) • High Cohesion/ Low Coupling （結合度と凝集度） • Divide by Responsibility • Module→ADT(→Class) • Encapsulation (カプセル化) • Class and Object • Polymorphism(多態性) • Inheritance/Subtyping （継承/サブタイプ） • Use Case • Domain Model • Software Patterns ※2000以降についてはアジャイルで詳述（Divide by Value、テスト性)など 90

Slide 85

Slide 85 text

変わっていない重要な デザインコンセプト(Evergreen) 70s 70s-80s 80s-90s-2000s 構造化プログラミング 構造設計設計 オブジェクト指向設計 main fun fun fun 関⼼事が分離され、凝集度が ⾼い⼿続きモジュールが、結 合度低く結びついて、データ を処理、更新する。他⼈には 内部の情報を知らせない（情 報隠蔽︓変更が伝搬しないよ うに）。 データと操作がカプセル化 されたクラス。クラスは継 承構造をもつ。クラスから、 オブジェクトが⽣成され、 それらが、メソッドを呼び 合って、ユースケースを成 し遂げる。 91

Slide 86

Slide 86 text

「情報隠蔽」のエピソード • OSを開発していたチームが、メモリをファイルシ ステムに吐き出す必要があり、ファイルシステム のチームにファイルのレイアウトを聞いた。 • ファイルシステムのチームは、まだレイアウトが 決まっていなかったが、（今で⾔う）open(), close(), read(), write() 関数のエントリーポイント とレジスタに積む・返す値だけ教えた。 • これ以上の知識を与えない⽅が、後々の変更が彼 らの仕事に影響しないだろう、と考えた。 ーDavid Parnas 93

Slide 87

Slide 87 text

96 https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html 英語 https://www.slideshare.net/hiranabe/software-design-and-team-design ⽇本語

Slide 88

Slide 88 text

Object-Oriented Designを学ぶなら 97 Classic Classic Classic Classic Classic

Slide 89

Slide 89 text

98

Slide 90

Slide 90 text

Conway’s Law “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” — M. Conway ”組織の構造がソ フトウェアの構 造に反映する“ であれば、よい組織構造をつくろう。 （Inverse Conway Maneuver) 99

Slide 91

Slide 91 text

ソフトウェアのチームの構造 100 https://anagileway.wordpress.com/2016/05/25/inverse-conway-maneuver-and-devops-microservices-and-agile/

Slide 92

Slide 92 text

101

Slide 93

Slide 93 text

Agile 102

Slide 94

Slide 94 text

103 なぜ、 アジャイルか?

Slide 95

Slide 95 text

104 市場 ビジネス IT 市場分析 発注 納品 リリース 半年から３年 ミッション・リスク分割型ビジネスと ウォーターフォール型開発（従来型）

Slide 96

Slide 96 text

105 従来型の問題＝要求の劣化 !"#$%機能%利用度 全,使./01 234 5678使./0 1 9:4 ;<=使> 9?4 1@A使> B4 C,使> 9D4 • Standish group study report in 2000 chaos report

Slide 97

Slide 97 text

106 市場 IT 1週間から半年 ミッション・リスク共有型ビジネスと Agile型開発 ビジネス 市場 ビジネスとITが⼀体になった 「OneTeam」を作り、ミッション とリスクを共有する。 やってみて、結果から戦略を 作りながら進む。

Slide 98

Slide 98 text

108 プロセスとしてのAgile • 短いサイクルで、分析、設計、実装、テストを並列に⾏う • タイムボックス型、進化型開発 分析 設計 実装 テスト 時間 時間 要求(スコープ) 要求(スコープ) Waterfall Agile Beck 2000 Royce 1970 最後に動くものができる 動くものが徐々に できあがり、成⻑する

Slide 99

Slide 99 text

109 分割の仕⽅ • 顧客に分かる機能で切る。 • 層で切らない。 • ビジネスの価値が分かる。 “These days we do not program software module by module; We program software feature by feature.” —Mary Poppendieck by Akiyah “Divide by Value” —Tom Gilb

Slide 100

Slide 100 text

110 アジャイルと 事前アーキテクチャ 開発時間 事前設計とリスク解決の時間 修正時間（⽋陥の修正、書き直し、間違い） 全体のプロジェクト時間 備考: 事前設計に使った時間は開発を加 速し修正作業の時間を減らす Barry Boehm: The ROI of Systems Engineering: Some Quantitative Results 2007 Michael Keeling: “Design It!” (Design It! プログラマのためのアーキテクティング⼊⾨ 2017)

Slide 101

Slide 101 text

sweet spot アーキテクチャ設計とリスク解決のための時間 全体に追加された時間 アーキテクチャ設計 修正作業 アジャイルと 事前アーキテクチャ

Slide 102

Slide 102 text

Barry Boehm et. al : Architected Agile Solutions for Software-Reliant Systems

Slide 103

Slide 103 text

アジャイ ル適正 経験メンバの割合 要求変化 企業⽂化 メンバ数 クリティカルさ 35 30 25 20 15 0 10 20 30 40 (1B%) (L2,3 %) (変更/⽉(%)) 1 5 10 30 50 90 70 50 30 10 3 10 30 100 300 (⽋陥による損害) 快適さ 限定額 巨額 ⼀⽣命 多数の⽣命 計画型 アジャイル “Get Ready for Agile Methods – With Care” (Barry Boehm, IEEE Computer, January 2001)

Slide 104

Slide 104 text

Agile Manifesto 114

Slide 105

Slide 105 text

115 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツール よりも 個人と対話を、 包括的なドキュメント よりも 動くソフトウェアを、 契約交渉 よりも 顧客との協調を、 計画に従うこと よりも 変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 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 © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 重要 超重要!

Slide 106

Slide 106 text

https://www.slideshare.net/fkino/brief-history-of-agile-movement-2017 116

Slide 107

Slide 107 text

117

Slide 108

Slide 108 text

118

Slide 109

Slide 109 text

アジャイルの原則 • 顧客価値の優先 • 変化に対応 • 短期のリリース • 全員同席 • モチベーションと信頼 • 会話 • 動くソフトウェア • 持続可能なペース • 技術的卓越性 • シンプル • ⾃⼰組織的チーム • ふりかえりと改善 119

Slide 110

Slide 110 text

Scrum 120

Slide 111

Slide 111 text

121 スクラムの流れ

Slide 112

Slide 112 text

123 スクラムでの役割

Slide 113

Slide 113 text

Agile Practices 125

Slide 114

Slide 114 text

126 https://www.agile-studio.jp/agile-practice-ma アジャイルプラクティスマップ 実践 （プラクティス）

Slide 115

Slide 115 text

⾼速に⽯橋を 叩いて渡る 「開発環境」 協働でゴールに 向かう 「チーム環境」 ビジネス価値、 顧客満⾜、市場創造 XPのプラクティス 継続的インテグレーション(CI) 継続的デリバリ(CD) ⾃動化された「ビルド」 ⾃動化された「回帰テスト」 ⾃動化された「デプロイ」 チケット、バージョン管理 テスト駆動開発、リファクタリング スクラム、 プロジェクトファシリテーション ⾒える化、透明化 ふりかえり イテレーションを回す 朝会、タスクかんばん バーンダウンチャート いきいきとした現場づくり アジャイルの レフトウィング アジャイルの ライトウィング アジャイルのゴール ソーシャルプラクティス 技術プラクティス

Slide 116

Slide 116 text

Agile Practices 128

Slide 117

Slide 117 text

Test-Driven Development ※テスト駆動開発は、Refactoring を前提としている。ちなみに、テス ト駆動開発はXPの1つのプラクティスだが、XPの本が出た年と Refactoringが出た年は同じ(1999)。両⽅の参照⽂献に両⽅が載ってい る。（相互依存関係） 129 Classic

Slide 118

Slide 118 text

130 • Write a test • Watch it fail • Make it pass • Refactor (improve) • Repeat until done T D D •テストを書く •失敗することを確認 •通過させる •リファクタリング（改善） •繰り返す

Slide 119

Slide 119 text

⾼速に⽯橋を 叩いて渡る 「開発環境」 協働でゴールに 向かう 「チーム環境」 ビジネス価値、 顧客満⾜、市場創造 XPのプラクティス 継続的インテグレーション(CI) 継続的デリバリ(CD) ⾃動化された「ビルド」 ⾃動化された「回帰テスト」 ⾃動化された「デプロイ」 チケット、バージョン管理 テスト駆動開発、リファクタリング スクラム、 プロジェクトファシリテーション ⾒える化、透明化 ふりかえり イテレーションを回す 朝会、タスクかんばん バーンダウンチャート いきいきとした現場づくり アジャイルの レフトウィング アジャイルの ライトウィング アジャイルのゴール ソーシャルプラクティス 技術プラクティス

Slide 120

Slide 120 text

132 アジャイル開発 の現場

Slide 121

Slide 121 text

133 ⾒える化/透明性 l 「最新の正の情報」が、「⼀箇所に」、「⼤きく」書かれ ていて、それを、「両チームのメンバー」、「審判」、「観 客」が⾒ている。 「次の⾏動」を誘発する。 全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源 POINT

Slide 122

Slide 122 text

タスクかんばん • 作業の見える化 – ToDo(未実施) Doing(実施中) Done(完了) で管理。 – 各自の作業を指示しなく ても、毎朝自発的に 作業開始。 – フォーマットは徐々に カイゼン。 タスクかんばんの例 ※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 作業の見える化は、「タスクかんばん」で行なう。 POINT (協力：チェンジビジョンastah* チーム） 134

Slide 123

Slide 123 text

⽇本からも海外へ発信 135

Slide 124

Slide 124 text

“Kanban, Successful Evolutionary Change for Your Technology Business” http://www.agilemanagement.net 136

Slide 125

Slide 125 text

http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/ Corey Ladas

Slide 126

Slide 126 text

（協力：ヤマハモーターソリューショ ン） 138

Slide 127

Slide 127 text

ポータブルかんばん 「かんばん-nano」スーツにもベストフィット！ POINT (協力：CCS 佐藤竜一さん） 139

Slide 128

Slide 128 text

バーンダウンチャート • 進捗の見える化 – バーンダウン（下向き） – タスクかんばんと連動 – 中間成果物で は計測しない。 – メールでエクセルシート を配布したり、 サーバに置いたから 見てね、はナシ。 バーンダウンチャートの 例 全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり POINT (協力：永和システムマネジメント：チーム角谷） 140

Slide 129

Slide 129 text

朝会 • 作業の明確化 –⾃発的なサインアップ –昨⽇やったこと、 今⽇やること、 問題点、の３点のみ。 –かんばんの前 で、⾏なう。 –朝の仕事はじめが 重要︕ –スタンドアップで１５分． –定時刻、定位置、短時間 朝会の例(協力：チェンジビジョンastah* チーム） 毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。 POINT PF実践編：朝会ガイド http://www.ObjectClub.jp/community/pf/ 141

Slide 130

Slide 130 text

ふりかえり(1) • カイゼンの気づき – Keep(良い点) Problem(悪い点) Try(次回挑戦) を出す。 – 全員で意⾒を出し、 暗黙知の共同化と 形式知化を⾏なう。「名前付け」 – 「課題－解決リスト」、とは違う。 – とにかく、カジュアルな雰囲気で 全員発⾔することで、チームの 安全性を確保する。 – 「問題vs私たち」の構図になるように。 ふりかえりシートの例 カイゼンの「気づき」を「ふりかえり」で得る。 POINT 実践編：ふりかえりガイド http://www.ObjectClub.jp/community/pf/ 142

Slide 131

Slide 131 text

ふりかえり(2) • Keep/Problem/Try（KPT） –Keepは定着する。 –ProblemはTryを ⽣み出す。 –Tryは、Keepか Problemに移動する。 –定着したものには、 「名前づけ」を。 ふりかえりがカイゼンを導く Keep Problem Try 新しい問題！ 新しいアイディア！ 解決法 やってみて うまく行った うまく行かない 定着 イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT 143

Slide 132

Slide 132 text

151

Slide 133

Slide 133 text

152 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツール よりも 個人と対話を、 包括的なドキュメント よりも 動くソフトウェアを、 契約交渉 よりも 顧客との協調を、 計画に従うこと よりも 変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 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 © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

Slide 134

Slide 134 text

ソフトウェアと⼈は切り離せない 153 Classic Classic Classic Classic

Slide 135

Slide 135 text

No content

Slide 136

Slide 136 text

No content

Slide 137

Slide 137 text

156

Slide 138

Slide 138 text

157

Slide 139

Slide 139 text

Scrumと野中郁次郎 158

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

最初のスクラムの本 • “Agile Software Development with Scrum” (by Ken Schwaber, Mike Beedle) の最初の⼀ ⾏は次の引⽤で始まっている。 今⽇では新製品開発の動きが速く、競争率の⾼い世界では、速度 と柔軟性がとても重要である。企業は、新製品開発に直線的な 開発⼿法は古く、この⽅法では簡単に仕事を成し遂げることが できないことを徐々に認識し始めている。⽇本やアメリカの企 業では、ラグビーにおいて、チーム内でボールがパスされなが らフィールド上を⼀群となって移動するかのように、全体論的 な⽅法を⽤いている。 -- “The New New Product Development Game”

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

No content

Slide 144

Slide 144 text

Toyota Production System Lean Lean Software Development Kanban Lean Startup Agile Scrum XP The New New Product Development Game Four steps to the epiphany Agile and Lean Startup Patterns Manufacturing Industry in Japan 2013 Yasunobu Kawaguchi 1 2

Slide 145

Slide 145 text

http://www.publickey1.jp/blog/11/10_innovation_sprint_2011.html Innovation Sprint 2011 Jeff Sutherland Ikujiro Nonaka me

Slide 146

Slide 146 text

165

Slide 147

Slide 147 text

166

Slide 148

Slide 148 text

• 知識はどこから来る︖ • 暗黙知(1) • 形式知(2) • SECI モデル • 知識を”実践する”には︖ • 実践知(3) • それを誰が作る︖

Slide 149

Slide 149 text

身体・五感を駆使、 直接経験を通じた 暗黙知の獲得、 共有、創出（共感） 組織的知識創造の⾏為 - SECIモデル 「どう知るか」 - 暗黙知 暗黙知 形式知 形式知 暗黙知 暗黙知 形式知 形式知 I = 個人 G = 集団 O = 組織 E = 環境 形式知を行動を 通じて具現化、 新たな暗黙知として 理解・学習（実践） 対話・思索･比喩によ る概念・図像・仮説の 創造(概念化） 形式知の組み合わせ による情報活用と知 識の体系化（分析） 1.組織内外の活動によ る現実直感 2.感情移入・気づき・予 知の獲得 3.暗黙知の伝授、移転 9.反省的実践を通じた 形式知の体化 10.目標-成果の持続的 追求、自己超越 4.自己の暗黙知の 言語化 5.言語から概念・仮説･ 原型の 創造 6.概念間の関係生成と モデル化 7.形式知の伝達、普及・ 共有 8.形式知の編集・操作 化、IT化 共同化(S) 表出化(E) 内面化(I) 連結化(C) O G E G G G G Org. I Environment Individual I I I I I Group I E E I O © Nonaka I. & H. Takeuchi

Slide 150

Slide 150 text

学びを組織で共有する 169 「マルチ学習」で触れたように、学びは多層に（個⼈からグループへ）、多能 ⼒に（複数の専⾨領域へ）積み重ねられるが、この学習をさらにグループを越 えて伝え、共有していく活動が⾒られる…組織は、⾃然と成功したやり⽅を標 準化して制度化する⽅向へと向かう。ただし、これが⾏き過ぎると逆に危険だ 。外部環境が安定している場合には、過去の成功を「先⼈の知恵」として⾔葉 で伝えたり、成功事例を元に標準を確⽴したりすることはうまくいく。しかし 、外部の環境変化が速いと、このような教訓は逆に⾜かせになることがある。 多くの場合、過去の成功体験を捨て去ることは難しく、外部環境の変化によっ て強制的に捨てることになる。しかし、いくつかの組織では意識的にその努⼒ をしていた。

Slide 151

Slide 151 text

170 スクラムとは、会社を機能単位に分割し た階層や組織ではなく、どこをとっても 会社のビジョンに向かった判断・行動パ ターンを共有するフラクタルな知識創造 活動であり、それを実践する人々である。

Slide 152

Slide 152 text

171 平鍋君、会社はどこに存在すると思うかね︖ 取締役会︖ 本社︖ それとも組織図︖ …

Slide 153

Slide 153 text

172 会社は、そこ・ここに起こる会話にある。