Conway's law and Agile development - software design and team design

As the business environment changes so fast and becomes turbulent, most of the business innovations are now relying on software centric. Now Agile is the key concept of software engineering, moving its main focus from the software structure to the social (team) structure which produces the softwaret. I will start with software engineering concepts and show parallelism in the social (Agile) concepts, and the motivation for
applying Conway’s law.

ソフトウェア開発において，ウォーターフォール型の開発からアジャイル開発へと大きなパラダイムシフ
トが起きました．イノベーションがソフトウェアを中心に起こるようになり，ソフトウェア工学が，ソフトウェアそのものの設計から，ソフトウェアを生み出す組織とそのコミュニケーション構造も含めたチームづくりにフォーカスを移しています．その経緯や意味も含め，コンウェイの法則の現代的な意味について考察します．

Transcript

1. コンウェイの法則と アジャイル ソフトウェア開発 ソフトウェアとそれを産み出す組織のソーシャル構造について 株式会社永和システムマネジメント 株式会社チェンジビジョン 平鍋健児 1
2. 平鍋健児 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO (株)Scrum Inc. Japan 取締役 アジャイル開発を推進し、国内外で、 モチベーション中⼼チームづくり、ア ジャイル開発の普及に努める。ソフト ウェアづくりの現場をより⽣産的に、 協調的に、創造的に、そしてなにより、 楽しく変えたいと考えている。 アジャイルジャパン初代実⾏委員⻑。 第⼆版
3. ◎ 本社／福井市 WeWork 沖縄 •⾦融、医療、組込み(⾃動⾞) •Web/Cloud、アジャイル開発 •社員 220名エンジニア集団
4. 共創・共育で利⽤するプラクティス 4 モブプログラミング • ⼀つのPCとディスプレイ • 同じ課題にみんなで⽴ち向かう • 知識伝搬が早い • レビューも同時に⾏うことで効率的 スプリント （1〜4週間） ふりかえり • 毎週（スプリント毎）実施 • ⾃分たちの課題を出し合い改善策を探る • チームワークを⽣み出す効果も 開発はすべてアジャイル
5. 顧客の看板の下にチーム 5
6. 150社2,000名が⾒学
8. 8 2022 松⾕先⽣との出会い
9. 9 線形代数の緒概念が、直感的に⼿に取るように把握できます。 機械学習の線形代数の章があります︕ ReLU による空間分割、損失関数、畳み込み、勾配降下など
10. 10 https://anagileway.com/202 0/06/04/prof-gilbert-strang- linear-algebra/
13. ソフトウェア デザイン チーム デザイン 13 ?
14. 今⽇のお話の地図 14
16. The Art of Readable Code 16
17. The Art of Readable Code 鍵となるアイディア • コードは理解しやすくなければならない • 他⼈が短時間で理解できるように • 第1章 理解しやすいコード 18
18. 第 I 部 表⾯上の改善 • 2章 名前に情報を詰め込む • 3章 誤解されない名前 • 4章 美しさ • 5章 コメントすべきことを知る • 6章 コメントは正確で簡潔に 19
19. 名前に情報を詰め込む • 類語辞典(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
21. 第II部 ループとロジックの単純化 • 7章 制御フローを読みやすくする • 8章 巨⼤な式を分割する • 9章 変数と読みやすさ 26
22. 第III部 コードの再構成 • 10章 無関係の下位問題を抽出する • 11章 ⼀度にひとつのことを • 12章 コードに思いをこめる • 13章 短いコードを書く • 14章 テストと読みやすさ 27
23. あわせて読みたい 29 Classic Classic Classic Classic
24. 30 Alexander の影響
25. Design Patterns Elements of Reusable Object-Oriented Software 31 Classic
26. 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
27. 建築の⽅をチラ⾒ 33
28. 100 歩⾏者道路 という名前 想起させる、写 真・もしくは絵 34
29. 前述のパターンを ⽰し、⽂脈を提⽰ 課題を提⽰ ⾃然と外で⼈々 が肩が触れ合う くらいの社交的 な場が必要。 35
30. 解決策を提⽰ 建物が「歩⾏者道 路」を形作るよう に配置。⼆階へも 直接上がれるよう に階段を。 36
31. 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
32. 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
33. 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
34. • プロムナード、⼩⾼い歩道、、、 町 • 歩⾏者道路、ちびっこのほら⽳ 建物 • 座れるさかい壁、明かりだまり 施⾏ パタン⾔語 40
37. •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
38. Design Patterns Elements of Reusable Object-Oriented Software 44 Classic
39. デザインパターンの形式 項⽬ 内容 名前 パターンの名前．および後述するカテゴリ ⽬的 解こうとしてる「問題」と「解決」の原理 別名 良く知られた別名 動機 どのような状況で問題が発⽣するか具体例やストーリ 適⽤可能性 どのような状況で適⽤できるか 構造 パターンの構造を⽰すクラス図 構成要素 クラス・オブジェクトの責任分担 協調関係 構成要素がどのように強調するか 結果 パターンが問題の解決にどう貢献するか．トレードオフ 実装 実装にす場合の注意点 サンプル コード コードの例⽰ 使⽤例 実際のシステムで利⽤されている例 関連するパ ターン 他の密接に関連するパターン 45
40. 例: Singleton • 「⽬的」 “あるクラスに対してインスタンスが１つしか存在しないことを保証し，そ れにアクセスするためのグローバルな⽅法を提供する．” ここには，「クラスに対してインスタンスが１つしか存在しないことを保証す るには， どうしたらよいか」という問題が書かれている．しかし，このよう な問題の記述は抽象的であることが多く， パターンによっては理解するのが 難しい場合もある．「問題」の理解を助けるのが， 「動機」の記述である． 「動機」は，実際にそのような問題が起こる状況， すなわち⽂脈が，具体的 な例を伴って書かれている． • 「動機」 そのような状況の説明、その例として，プリンタスプーラ，ファイルシス テム， ウィンドウマネージャ，などの例が挙げられている． まず「⽬的」と「動機」を読み， そのパターンが解こうとしている「問題」 とそれが発⽣する「⽂脈」を理解する． そして，そのような状況に⾃分が置 かれたときに， このパターンを思い出せるようにしておく必要がある． 46
41. 47 http://p-monster.hatenablog.com/archive/category/デザインパターン Singleton (例︓ウィンドウマネジャ) たった⼀つのインスタンスを保証 • Singleton Class • インスタンスが１個しか存在しないことをプログラム 上で表現するには、コンストラクタをプライベートに し、外部でnewできなくする。 • ⾃分⾃⾝のインスタンスをstaticで持ち、コンストラク タを⾮公開にする。Singleton の getInstance() で、 staticでたった⼀つのインスタンスへの参照をクライア ントに返す。 • [⽬的] あるクラスに対してインスタンスが１ つしか存在しないことを保証し，それにアク セスするためのグローバルな⽅法を提供する．
42. 23 パターンの分類 48
43. デスクトップのファイルを例に • ファイル、フォルダ(ディレクトリ)、 ショートカット、アプリケーション • 「⽊構造」を持つもの「代理」として機 能するもの 49
44. 50 Proxy パターン (例︓ファイルとショートカット) 軽い代理を⽴てる
45. 51 Composite パターン (例︓ファイルとフォルダ) 中⾝と容器の同⼀視
46. 52 組み合わせた例
49. SOLID Principles 55 Classic
50. Pictures by Derick Bailey https://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/ 56
51. 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
53. SRP(Single Responsibility Principle) 定義 クラスに変更が起こる理由は、⼀つである べき。(A class should have only one reason to change.) ※元々は、「責務が1つ」であるべきの意味で「凝集度が⾼い」モジュールになる。 現代的には、より具体的に「変更のソース」が2つ以上あるなら、分離せよということ。 59
55. OCP(Open/Close Principle) 定義 クラスは、変更することなく振る舞いを拡 張できなくてはらない(You should be able to extend a classes behavior, without modifying it.) 61 クラスの継承と、多態性をつかうことでクラスを拡張できるしくみ。 Bertrand Meyerの「オブジェクト指向⼊⾨」 が初出。
56. 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
57. // 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
59. LSP(Liskov Substitution Principle) 定義 派⽣クラスは、それを利⽤するコードから みて基底クラスと交換可能でなければなら ない (Derived classes must be substitutable for their base classes.) ※基底クラスが型指定してある変数の場所には、将来、そのどの派⽣クラスのイン スタンスが⼊ってきても正しく動作するように、クラス継承の意味を正しく維持し なくてはならない。 65
60. #include “shape.h” void drawAllShapes (const vector<const Shape*>& shapes) { for (const Shape *s: shapes) s->draw(); } このコードは、Shape の派⽣クラスのどんなものが渡ってきても、その知識なしに 動作しなければならない。そのように、Shape とその派⽣クラスは設計されて いなければならない。 ※どのような派⽣クラスがShapeに追加されようが、この関数は再コンパイル なしで動作する。（C++/Javaでは、プログラマが設計したクラス階層をコンパイ ラが補助する。） 66
62. ISP(Interface Segregation Principle) 定義 利⽤者は⾃分が使わないメソッドに依存す ることを強制されない(Clients should not forced to depend on methods that they don't use.) ※インターフェイスを太らせてはいけない、別⽤途のインターフェイスは分離せよ。 C++では多重継承もしくは別のアダプタクラス、Java では interface を利⽤。 68
63. インターフェイスを 分離したシンプルな例 さらにアダプタで 分離した例 69
65. DIP(Dependency Inversion Principle) 定義 実装の具体に依存してはならない。抽象に 依存せよ (Depend on abstractions, not on concretions.) ※特にフレームワークの設計などでは、「呼び出しの⽅向」と「依存の⽅向」が逆転 することがあります。現代的には、テスト容易性を⾼めるために、”Inversion of Control”や”Dependency Injection”といった⼿法が使われます。昔は、関数ポインタ を渡すことで下位のレイヤから上位のモジュールを「コールバック」してもらう、と いう⼿法がよく取られました。現代では、Observerパターンでインターフェイス（こ こでいう抽象）に依存させて呼び出しと依存の向きを反転させます。 ちなみに、コールバックはJavaではListener、C#ではdelegateと呼ばれます。 71
67. Design Analysis Architecture 73
68. Analysis Patterns 74 Classic
69. 責任関係(Accountability) Person（個⼈）とOrganization(法⼈)が持っている 情報が同じことが多い。（ダブリを感じる） Partyの導⼊ 75
70. さまざまな契約・責任関係で利⽤ 76
71. その他にも…Header-Detail https://areyoumodeling.com/2015/02/20/uml_header_detail/ 77
73. Design Analysis Architecture 79
74. Architecture Patterns(POSA) 80 Classic
75. • Model-View-Controllerアーキテクチャパターン （MVC）は，対話型アプリケーションを3つのコンポー ネントに分割する．モデルコンポーネントは，アプリ ケーションの中核機能とデータを含むコンポーネントで ある．ビューコンポーネントは，情報をユーザに表⽰す るコンポーネントである．そして，コントローラは， ユーザの⼊⼒を取り扱うコンポーネントである．ユーザ インタフェースを実現するのは，ビューコンポーネント とコントローラコンポーネントである．更新伝播のメカ ニズムによって，ユーザインターフェースとそのモデル との⼀貫性を保証することできる． • 適⽤例 Smalltalk, MFC, ET++, …(さらにWebで多い) Model-View-Controller 81
76. Model-View-Controller 82
77. Blackboard • Blackboardアーキテクチャパターンは， 決定論的な解決戦略が分かっていない課 題に対して有効である．複数のサブシス テムが持つそれぞれの知⾒を組み合わせ ることによって，部分的，もしくは近似 的に妥当な解を得ることができる． • 適⽤例 HEARSAY-Ⅱ⾳声認識システム 83
78. Blackboard 84
79. Pipes and Filters • Pipes and Filtersアーキテクチャパターンは， データをストリームとして扱うシステムのため の構造を提供する． 個々の処理ステップは，1 つのフィルタコンポーネントにカプセル化され， データはこれらの隣接するフィルタ間をパイプ コンポーネントを介して引き渡される． フィル タの組み合わせを換えることにより，機能の類 似した⼀連のシステムを作成することができる． • 適⽤例 UNIX のコマンドとパイプ、テキスト 85
80. Pipes and Filters 86
82. 構造化分析・設計 オブジェクト指向 分析・設計 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 プログラミング⾔語 分析・設計⼿法
83. ソフトウェア開発の進化は、 マシンから⼈へ、⼈からチームへ 機械語 アセンブラ COBOL C Java C# Ruby UML アジャイル 当初、コンピュータのリソースを 操作するために、プログラミング ⾔語が作られてきた。 徐々に名前付け、抽象化ができるよう になり、⼈間の思考に近いレベルの概 念を取り扱えるように進化してきた。 名前 関数 構造体 ユーザ定義型 クラス モジュール 設計レベルや開発プロセスレベルでも、 可視化によるコミュニケーションをサポー トするようになってきた。 DSL 89
84. 変わっていない重要な 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
85. 変わっていない重要な デザインコンセプト(Evergreen) 70s 70s-80s 80s-90s-2000s 構造化プログラミング 構造設計設計 オブジェクト指向設計 main fun fun fun 関⼼事が分離され、凝集度が ⾼い⼿続きモジュールが、結 合度低く結びついて、データ を処理、更新する。他⼈には 内部の情報を知らせない（情 報隠蔽︓変更が伝搬しないよ うに）。 データと操作がカプセル化 されたクラス。クラスは継 承構造をもつ。クラスから、 オブジェクトが⽣成され、 それらが、メソッドを呼び 合って、ユースケースを成 し遂げる。 91
86. 「情報隠蔽」のエピソード • OSを開発していたチームが、メモリをファイルシ ステムに吐き出す必要があり、ファイルシステム のチームにファイルのレイアウトを聞いた。 • ファイルシステムのチームは、まだレイアウトが 決まっていなかったが、（今で⾔う）open(), close(), read(), write() 関数のエントリーポイント とレジスタに積む・返す値だけ教えた。 • これ以上の知識を与えない⽅が、後々の変更が彼 らの仕事に影響しないだろう、と考えた。 ーDavid Parnas 93
87. 96 https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html 英語 https://www.slideshare.net/hiranabe/software-design-and-team-design ⽇本語
88. Object-Oriented Designを学ぶなら 97 Classic Classic Classic Classic Classic
90. 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
91. ソフトウェアのチームの構造 100 https://anagileway.wordpress.com/2016/05/25/inverse-conway-maneuver-and-devops-microservices-and-agile/
93. Agile 102
94. 103 なぜ、 アジャイルか?
95. 104 市場 ビジネス IT 市場分析 発注 納品 リリース 半年から３年 ミッション・リスク分割型ビジネスと ウォーターフォール型開発（従来型）
96. 105 従来型の問題＝要求の劣化 !"#$%機能%利用度 全,使./01 234 5678使./0 1 9:4 ;<=使> 9?4 1@A使> B4 C,使> 9D4 • Standish group study report in 2000 chaos report
97. 106 市場 IT 1週間から半年 ミッション・リスク共有型ビジネスと Agile型開発 ビジネス 市場 ビジネスとITが⼀体になった 「OneTeam」を作り、ミッション とリスクを共有する。 やってみて、結果から戦略を 作りながら進む。
98. 108 プロセスとしてのAgile • 短いサイクルで、分析、設計、実装、テストを並列に⾏う • タイムボックス型、進化型開発 分析 設計 実装 テスト 時間 時間 要求(スコープ) 要求(スコープ) Waterfall Agile Beck 2000 Royce 1970 最後に動くものができる 動くものが徐々に できあがり、成⻑する
99. 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
100. 110 アジャイルと 事前アーキテクチャ 開発時間 事前設計とリスク解決の時間 修正時間（⽋陥の修正、書き直し、間違い） 全体のプロジェクト時間 備考: 事前設計に使った時間は開発を加 速し修正作業の時間を減らす Barry Boehm: The ROI of Systems Engineering: Some Quantitative Results 2007 Michael Keeling: “Design It!” (Design It! プログラマのためのアーキテクティング⼊⾨ 2017)
101. sweet spot アーキテクチャ設計とリスク解決のための時間 全体に追加された時間 アーキテクチャ設計 修正作業 アジャイルと 事前アーキテクチャ
102. Barry Boehm et. al : Architected Agile Solutions for Software-Reliant Systems
103. アジャイ ル適正 経験メンバの割合 要求変化 企業⽂化 メンバ数 クリティカルさ 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)
104. Agile Manifesto 114
105. 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, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 重要 超重要!
106. https://www.slideshare.net/fkino/brief-history-of-agile-movement-2017 116
109. アジャイルの原則 • 顧客価値の優先 • 変化に対応 • 短期のリリース • 全員同席 • モチベーションと信頼 • 会話 • 動くソフトウェア • 持続可能なペース • 技術的卓越性 • シンプル • ⾃⼰組織的チーム • ふりかえりと改善 119
110. Scrum 120
111. 121 スクラムの流れ
112. 123 スクラムでの役割
113. Agile Practices 125
114. 126 https://www.agile-studio.jp/agile-practice-ma アジャイルプラクティスマップ 実践 （プラクティス）
115. ⾼速に⽯橋を 叩いて渡る 「開発環境」 協働でゴールに 向かう 「チーム環境」 ビジネス価値、 顧客満⾜、市場創造 XPのプラクティス 継続的インテグレーション(CI) 継続的デリバリ(CD) ⾃動化された「ビルド」 ⾃動化された「回帰テスト」 ⾃動化された「デプロイ」 チケット、バージョン管理 テスト駆動開発、リファクタリング スクラム、 プロジェクトファシリテーション ⾒える化、透明化 ふりかえり イテレーションを回す 朝会、タスクかんばん バーンダウンチャート いきいきとした現場づくり アジャイルの レフトウィング アジャイルの ライトウィング アジャイルのゴール ソーシャルプラクティス 技術プラクティス
116. Agile Practices 128
117. Test-Driven Development ※テスト駆動開発は、Refactoring を前提としている。ちなみに、テス ト駆動開発はXPの1つのプラクティスだが、XPの本が出た年と Refactoringが出た年は同じ(1999)。両⽅の参照⽂献に両⽅が載ってい る。（相互依存関係） 129 Classic
118. 130 • Write a test • Watch it fail • Make it pass • Refactor (improve) • Repeat until done T D D •テストを書く •失敗することを確認 •通過させる •リファクタリング（改善） •繰り返す
119. ⾼速に⽯橋を 叩いて渡る 「開発環境」 協働でゴールに 向かう 「チーム環境」 ビジネス価値、 顧客満⾜、市場創造 XPのプラクティス 継続的インテグレーション(CI) 継続的デリバリ(CD) ⾃動化された「ビルド」 ⾃動化された「回帰テスト」 ⾃動化された「デプロイ」 チケット、バージョン管理 テスト駆動開発、リファクタリング スクラム、 プロジェクトファシリテーション ⾒える化、透明化 ふりかえり イテレーションを回す 朝会、タスクかんばん バーンダウンチャート いきいきとした現場づくり アジャイルの レフトウィング アジャイルの ライトウィング アジャイルのゴール ソーシャルプラクティス 技術プラクティス
120. 132 アジャイル開発 の現場
121. 133 ⾒える化/透明性 l 「最新の正の情報」が、「⼀箇所に」、「⼤きく」書かれ ていて、それを、「両チームのメンバー」、「審判」、「観 客」が⾒ている。 「次の⾏動」を誘発する。 全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源 POINT
122. タスクかんばん • 作業の見える化 – ToDo(未実施) Doing(実施中) Done(完了) で管理。 – 各自の作業を指示しなく ても、毎朝自発的に 作業開始。 – フォーマットは徐々に カイゼン。 タスクかんばんの例 ※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 作業の見える化は、「タスクかんばん」で行なう。 POINT (協力：チェンジビジョンastah* チーム） 134
123. ⽇本からも海外へ発信 135
124. “Kanban, Successful Evolutionary Change for Your Technology Business” http://www.agilemanagement.net 136
125. http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/ Corey Ladas
126. （協力：ヤマハモーターソリューショ ン） 138
127. ポータブルかんばん 「かんばん-nano」スーツにもベストフィット！ POINT (協力：CCS 佐藤竜一さん） 139
128. バーンダウンチャート • 進捗の見える化 – バーンダウン（下向き） – タスクかんばんと連動 – 中間成果物で は計測しない。 – メールでエクセルシート を配布したり、 サーバに置いたから 見てね、はナシ。 バーンダウンチャートの 例 全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり POINT (協力：永和システムマネジメント：チーム角谷） 140
129. 朝会 • 作業の明確化 –⾃発的なサインアップ –昨⽇やったこと、 今⽇やること、 問題点、の３点のみ。 –かんばんの前 で、⾏なう。 –朝の仕事はじめが 重要︕ –スタンドアップで１５分． –定時刻、定位置、短時間 朝会の例(協力：チェンジビジョンastah* チーム） 毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。 POINT PF実践編：朝会ガイド http://www.ObjectClub.jp/community/pf/ 141
130. ふりかえり(1) • カイゼンの気づき – Keep(良い点) Problem(悪い点) Try(次回挑戦) を出す。 – 全員で意⾒を出し、 暗黙知の共同化と 形式知化を⾏なう。「名前付け」 – 「課題－解決リスト」、とは違う。 – とにかく、カジュアルな雰囲気で 全員発⾔することで、チームの 安全性を確保する。 – 「問題vs私たち」の構図になるように。 ふりかえりシートの例 カイゼンの「気づき」を「ふりかえり」で得る。 POINT 実践編：ふりかえりガイド http://www.ObjectClub.jp/community/pf/ 142
131. ふりかえり(2) • Keep/Problem/Try（KPT） –Keepは定着する。 –ProblemはTryを ⽣み出す。 –Tryは、Keepか Problemに移動する。 –定着したものには、 「名前づけ」を。 ふりかえりがカイゼンを導く Keep Problem Try 新しい問題！ 新しいアイディア！ 解決法 やってみて うまく行った うまく行かない 定着 イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT 143
133. 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, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
134. ソフトウェアと⼈は切り離せない 153 Classic Classic Classic Classic
139. Scrumと野中郁次郎 158
141. 最初のスクラムの本 • “Agile Software Development with Scrum” (by Ken Schwaber, Mike Beedle) の最初の⼀ ⾏は次の引⽤で始まっている。 今⽇では新製品開発の動きが速く、競争率の⾼い世界では、速度 と柔軟性がとても重要である。企業は、新製品開発に直線的な 開発⼿法は古く、この⽅法では簡単に仕事を成し遂げることが できないことを徐々に認識し始めている。⽇本やアメリカの企 業では、ラグビーにおいて、チーム内でボールがパスされなが らフィールド上を⼀群となって移動するかのように、全体論的 な⽅法を⽤いている。 -- “The New New Product Development Game”
142. https://hbr.org/1986/01/the-new-new-product-development-game
144. 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
145. http://www.publickey1.jp/blog/11/10_innovation_sprint_2011.html Innovation Sprint 2011 Jeff Sutherland Ikujiro Nonaka me
148. • 知識はどこから来る︖ • 暗黙知(1) • 形式知(2) • SECI モデル • 知識を”実践する”には︖ • 実践知(3) • それを誰が作る︖
149. 身体・五感を駆使、 直接経験を通じた 暗黙知の獲得、 共有、創出（共感） 組織的知識創造の⾏為 - 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
150. 学びを組織で共有する 169 「マルチ学習」で触れたように、学びは多層に（個⼈からグループへ）、多能 ⼒に（複数の専⾨領域へ）積み重ねられるが、この学習をさらにグループを越 えて伝え、共有していく活動が⾒られる…組織は、⾃然と成功したやり⽅を標 準化して制度化する⽅向へと向かう。ただし、これが⾏き過ぎると逆に危険だ 。外部環境が安定している場合には、過去の成功を「先⼈の知恵」として⾔葉 で伝えたり、成功事例を元に標準を確⽴したりすることはうまくいく。しかし 、外部の環境変化が速いと、このような教訓は逆に⾜かせになることがある。 多くの場合、過去の成功体験を捨て去ることは難しく、外部環境の変化によっ て強制的に捨てることになる。しかし、いくつかの組織では意識的にその努⼒ をしていた。
151. 170 スクラムとは、会社を機能単位に分割し た階層や組織ではなく、どこをとっても 会社のビジョンに向かった判断・行動パ ターンを共有するフラクタルな知識創造 活動であり、それを実践する人々である。
152. 171 平鍋君、会社はどこに存在すると思うかね︖ 取締役会︖ 本社︖ それとも組織図︖ …
153. 172 会社は、そこ・ここに起こる会話にある。