Power Theory of Software Architecture

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© rector,inc 自己紹介 2008年度に新卒第1期としてミクシィに入社。メディア統括部部長、開発部部長、サービス本部長執行役員。組織改革の戦略・実行を行う。2015年同社を退社。 2016年「CTOのノウハウを広く世の中に還元する」ことを目指し、レクターを創業。 2018年2月エンジニアリング組織論への招待上梓。第6回ブクログ大賞ビジネス書部門大賞受賞。 ITエンジニアに読んでもらいたい技術書2019大賞。広木大地(ひろきだいち)

Slide 3

Slide 3 text

© rector,inc 自己紹介 EMFM Podcast エンジニアリングマネージャのためのポッドキャスト。 13エピソード公開中で、現在、20000再生を突破。 EMFM Meetupという公開収録イベントで200人の会場が即日で集まった。 Qiita エンジニアリングに関するノウハウを集めるサイトQiita において、2019年現在、第2位。トータル39記事で41800いいね/20000ブクマ。その他パブリック活動

Slide 4

Slide 4 text

ビジネス書大賞と技術書大賞の２つを受賞した初めての書籍

Slide 5

Slide 5 text

ソフトウェアエンジニアリングも組織設計もビジネスの一部。この二つは不可分だ。

Slide 6

Slide 6 text

Slide 7

Slide 7 text

今回のテーマはアーキテクチャと組織

Slide 8

Slide 8 text

アーキテクチャという概念はわかりにくい

Slide 9

Slide 9 text

© rector,inc ローレンスレッシグのCODEでは「ある選択肢を選びやすくする」「ある行動が不快になるようにする」という性質を環境に与えることで、人々が自発的・自律的に特定の行動を促すようにするものを「アーキテクチャ」と呼びました。それらは社会のそこかしこに、あるいは卑近にWebサービスの中にもあるものです。たとえば、Amazonのレコメンドシステムはユーザーに対して以前購入したものと同じような書籍を購入しやすくすることで、より消費をすることを促すようになります。権力の一種としてのアーキテクチャ

Slide 10

Slide 10 text

Slide 11

Slide 11 text

要素技術に詳しい人がアーキテクトになるという誤解

Slide 12

Slide 12 text

組織マネジメントとアーキテクチャは関係がないという誤解

Slide 13

Slide 13 text

ビジネスマネジメントとアーキテクチャは関係ないという誤解

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© rector,inc アーキテクチャとはなにものなのだろうか？アーキテクチャとは、何かをしにくくする代わりに、何かをしやすくする構造ソフトウェアを作るということは、同時に何かを捨てていくことです。Web開発のフレームワークは、Web以外の開発が難しくなります。そのかわり、Web開発をしやすくするのです。左図のようなベンチは、寝にくく、三人が座わりやすくするようなアーキテクチャがしかけられています。何かをしやすく/何かをしにくくするホームレス排除の hostile architectureの例

Slide 16

Slide 16 text

社会をとりまく目に見えない力を生み出す構造＝アーキテクチャ

Slide 17

Slide 17 text

© rector,inc よくすることができる＝交換可能選択肢を持つ側と選択される側の関係には、一方向には権力が、その反対には依存という関係が成り立ちます。より良いものに交換できる側であれば、選択肢を持たない側に対して「権力」を発揮できます。逆に選択肢を持たないと、「依存」が生まれ結果的に理不尽を受け入れます。しやすくする力、しにくくする力はこうして発生する。この依存による理不尽が技術的負債の正体で、交換可能であるというメリットがアーキテクチャの正体です。依存することで理不尽が生まれる。依存権力選択肢を持つ側選択肢を持たない側

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© rector,inc 1 2 3 理不尽はいつも選択肢の少ない方にかかる美男美女でとてもモテる人との恋愛は大変です。その相手が、モテない場合、交換可能になってしまうかもしれません。経済的自立が難しい専業主婦にDV被害が及ぶのも権力構造の乱用です。美男美女との恋愛十分な需要があり、交換可能でない場合、値上げをする権力が生まれます。たとえば、配送業者や近年のビル建設業者などに起きていることは、需要と供給のくずれによる関係性の変化です。料金の値上げをする配送業者平均的なエンジニアですら、７倍近い有効求人倍率があります。優秀なレベルのエンジニアであれば、入社する会社は選び放題です。そのため、待遇だけでなく、環境や福利厚生、そしてその会社で働く社会的意義などから選ぶ側になっています。求職者優位の労働環境

Slide 20

Slide 20 text

アーキテクチャとは、依存関係(交換可能性)のうむ権力構造

Slide 21

Slide 21 text

© rector,inc ソフトウェアアーキテクチャにおいて交換可能性が重要自動テストや、カナリアリリースなどのデリバリーのパイプラインは、それ自体がある抽象度での交換可能性を上げるための試みになる。自動テストが存在しない状況だと、コードを修正するために多大なリソースが必要となる。ユニットテストが存在すれば、そのモジュールはユニットテストを満たす限りにおいて、新しいものに交換できる。これはAPI仕様を満たすテストを書けば、サービス自体の交換可能性を高める。自動テストとデリバリパイプラインサービスコンポーネントが自動的に構築可能で、かつ状態を持たずに廃棄可能・再構築可能だった時、そのインフラの交換可能性は高いと言える。そのため、インフラの要素をコードで記述したり、高速に再構築可能にすることが良いプラクティスとされる。交換可能性という補助線を引くと、良いアーキテクチャとそうでないアーキテクチャが自明に見えてくる。 Infra as Code/Disposable Component

Slide 22

Slide 22 text

プロジェクトマネジメントとアーキテクチャ

Slide 23

Slide 23 text

© rector,inc プロジェクトマネジメントの本質的複雑性それは２つの依存関係があり、クリティカルパスが存在するから。 N人のメンバーがいます。 M個のL時間づつかかるタスクがあります。このプロジェクトは何時間で終わりますか？（なお見積りは正確であるものとする）という問題の答えが：必要な時間 = ( M * L )/ N (時間) とならないのはなぜか。問題前の仕事が終わらないと次の仕事ができない前後依存性その人でないとある仕事ができないリソース依存性

Slide 24

Slide 24 text

© rector,inc ソフトウェアプロジェクトの依存関係は自明ではないソフトウェアプロジェクトにおいては、 ● 同じものをほとんど作ることはない ● 依存関係が建築等ほど自明ではない ● 見積りの分散が大きいなどの理由から、単純な進捗管理ではほとんど価値を生み出さない。依存性や困難性に対して、常に選択肢を持ち続けるようにアーキテクティングするのがプロジェクトマネジメントの仕事。プロマネの仕事は進捗確認ではない前の仕事が終わらないと次の仕事ができない => モックサーバやインタフェース設計前後依存性その人でないとある仕事ができない？ => 教育やフレームワークの導入、ツール化リソース依存性タスクごとの見積りの誤差が大きく違う => バッファマネジメント、不確実性に基づく優先順位設計、プランBの用意見積り不確実性

Slide 25

Slide 25 text

© rector,inc プロジェクトとプロダクトの依存関係は相似形になるプロジェクトの依存関係プロダクトの依存関係プロジェクトは、タスク同士の前後依存関係を持つ。これは時系列に対しての依存関係になる。全ての依存関係が当初から明らかなわけではない。進めるにつれ、徐々に明らかになる。プロダクトは、抽象と具体の間に依存関係があり、それをモジュールの依存関係として記述している。プロジェクトは最終的にモジュールの記述を行うから緩やかに依存関係が相似する時間具体抽象

Slide 26

Slide 26 text

© rector,inc 計画主義的プロセスと漸進的プロセス計画主義的プロセスでは、プロジェクト初期に全依存関係を発見する。これによって、プロジェクト実装フェーズの並列実行性を高めてリリースまでの期間を短くする。一時的に要員が増える。設計能力の必要な人員が相対的に少なくて良い。自明性の高い抽象構造のプロジェクトに向く。抽象構造を先に発見するプロセス漸進的プロセスでは、各フェーズで要件を満たすような最低限の設計と実装を繰り返す。抽象構造は初期に発見できるとは限らないとして、リファクタリングを繰り返しながら、よい抽象構造を発見する。自明でない仮説検証が必要なプロダクトに向いている。抽象構造を後から発見するプロセス要件定義設計実装テスト全依存関係の洗出リファクタリング

Slide 27

Slide 27 text

© rector,inc プロジェクトの変化に連動し抽象構造のパラダイムも変化存在論的な抽象（オントロジ）目的論的な抽象（テレオロジ）・自明性が高い関係の発見・Abstract Class / Inheritance ・<犬>と<うさぎ>は<動物> ・ツリー構造、計画的・再利用性・事後発見される仮説と目的の記述・Composition/ Structural subtyping/Mixin ・<さんま>と<ぶたにく>は<メインディッシュ> ・セミラティス構造、自生的秩序・交換可能性＊これらは造語。オントロジの本来の意味と情報技術における意味ぐらい違う。いい言葉が見つからない。。。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© rector,inc 進化的アーキテクチャ=組織論としてのアーキテクチャに進化的アーキテクチャは、継続的なリファクタリングとリリースの繰り返しを前提に、要求に対しての適応度の高い方に漸進的に変化していくことを進化的アルゴリズムのアナロジーで捉えている。概念的にはこれまで技術的負債と呼んでいたものを適応度の低いアーキテクチャとしてとらえ直している。また、継続して進化させるための組織文化を重要視しており、組織論とアーキテクチャの連動を前提としている。継続的なコードリリースを前提に

Slide 30

Slide 30 text

組織構造とアーキテクチャ

Slide 31

Slide 31 text

組織構造とソフトウェアシステムを設計する組織は、その情報伝達の構造をまねた設計を生み出してしまう｡メルヴィンコンウェイ “ 

Slide 32

Slide 32 text

© rector,inc 組織構造はコミュニケーション構造そのもの組織構造というと、ラインを構成するハイアラーキだけをイメージしがちであるが、ある仕事がどこから生まれて、どこに引き渡されていくか、誰と交流していくことによって成り立つかから作られる交流のネットワークが組織構造。それは明示的なもの・暗黙的なもの・非公式なものも含む。組織の成果と誰が何をしているかを知っているというトランザクティブメモリーが生産性に寄与することが知られている。誰が誰と交流して仕事が成り立つか

Slide 33

Slide 33 text

© rector,inc 組織とソフトウェアは同じ構造に変化しやすいシステムにおける問題は、組織構造上の問題が多く潜んでいる。この長らくソフトウェアエンジニアから支持されていた経験則は、実証的研究からも多くの証拠が見つかっている。たとえば、関わる人々の地理的関係からソフトウェアのバグの発生しやすい箇所を特定するなどコンウェイの法則システムを設計する組織は、その情報伝達の構造をまねた設計を生み出してしまう｡メルヴィンコンウェイ “  組織構造システム

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© rector,inc 取引コストによって、会社・組織の境界線が決まるある経営上のリソースを市場から手に入れるのか(取引コスト)、それとも企業内部に構築するのか(内部化コスト)を取引コスト理論の観点で見てみると、会社組織の境界線を決めるラインが見えてきます。   　内部化コストが高く、取引コストが安いものについては、企業外部から調達し、取引コストが高く、内部化コストが低いものは、企業内部に構築することが望ましいということがわかります。   　この構図は、エンジニアリング機能を必要とする組織にとっては、「何を外注し、何を内製するのか」を決定づける構図であると理解することができます。   　  内部化コスト > 取引コスト取引コスト > 内部化コスト市場取引  長期取引  戦略連携  組織取引  企業外部企業内部

Slide 37

Slide 37 text

© rector,inc 組織設計とアーキテクチャの関係技術的負債プラスの価値  マイナスの価値  アーキテクチャ組織  システム  取引コストが低く情報処理能力が高い組織取引コストが高く情報処理能力が低い組織コンウェイの法則が示すように、組織の構造とシステムの構造が相似形になってしまうのであれば、プラスの価値のある組織からは優れたアーキテクチャが生まれ、逆にマイナスの価値を持った組織からは技術的負債が生まれるようになるということが導けると思います。     また、その逆に優れたシステムの構造が、良い組織構造を生み出すことも起こり得ますし、同様に技術的負債が組織の悪しき硬直性を生み出すことも起こり得るのです。その意味で、組織とアーキテクチャには密接な相互関係があります。  

Slide 38

Slide 38 text

© rector,inc 逆コンウェイ作戦とマイクロサービシズ技術的負債プラスの価値  マイナスの価値  アーキテクチャ組織  システム  取引コストが低く情報処理能力が高い組織取引コストが高く情報処理能力が低い組織コンウェイの法則が示すように、組織の構造とシステムの構造が相似形になってしまうのであれば、プラスの価値のある組織からは優れたアーキテクチャが生まれ、逆にマイナスの価値を持った組織からは技術的負債が生まれるようになるということが導けると思います。     また、その逆に優れたシステムの構造が、良い組織構造を生み出すことも起こり得ますし、同様に技術的負債が組織の悪しき硬直性を生み出すことも起こり得るのです。その意味で、組織とアーキテクチャには密接な相互関係があります。   コンウェイの法則逆コンウェイ作戦 microservices

Slide 39

Slide 39 text

© rector,inc 組織に働く認知的な力：ゲシュタルト原則近接地理的に近い集団を仲間だと思う似ている種類の集まりを仲間と思う近接した複数の要素をグループ化して捉えるという人間の特性があります。これはデザインだけでなく組織においても同じで、地理的な近接を仲間と思うような特性があります。類同類似した性質＝情報的な距離が小さい集団を仲間と思います。たとえば、同業種の人同士が交流することが増えるというような特性です。そして人には仲間じゃないと思うものを排除しようとする本能があります。

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

ただ、古いシステムのことを技術的負債と呼ぶのではない。組織が必要な速度で変更できる能力を失うことが負債

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

ビジネス構造とアーキテクチャ

Slide 47

Slide 47 text

© rector,inc ペースレイヤリングという思想スチュアートブランドは、自然や文化のように緩やかにしか変化しない事柄と、つどつどの流行のように変化しやすい事柄が変化のペースによって、階層化されていて、土台がゆらぐとその上も大きく揺らぎ、土台がしっかりしているとその上の変化も受け入れられる適応性の高い構造になることを論じた。デザインや、ソフトウェア設計にとっても同様で、変化の多さで依存関係の階層構造を作ることをペースレイヤリングと呼ぶ。参考：思想としてのペースレイヤリング http://ekrits.jp/2015/03/403/ 変化の緩やかさ・速さ

Slide 48

Slide 48 text

© rector,inc ビジネスのペースレイヤリング＝目的管理ビジネスにおけるアーキテクチャを有効に機能させようとしたら、ビジネスのスケールに対して、変わりにくいものを代わりにくく、変わりやすいものを代わりやすくする必要があります。また、目的のために手段をよくするものですから、目的と手段の連鎖（抽象のはしご）に合わせてソフトウェア設計をすると、ビジネスの変動に対してロバストな設計になります。目的より手段の方が変わりやすい抽象的具体的固定的変動的手段目的 Mission Vision Strategy Plan 　 Action 手段目的手段目的手段目的

Slide 49

Slide 49 text

© rector,inc ビジネスにおける目的と手段の抽象のはしご手段目的ミッションは最終到達の理想状態を表現します Mission ビジョンはミッションに向かう３年以内に到達する具体的な状態を書きます Vision ストラテジーはビジョンのための１年以内に達成する戦略目標を書きます Strategy プランはストラテジー実行のための３ヶ月後の戦術的施策や習慣を書きます。 Plan アクションはプランになるための１週間継続できる行動を書きます　 Action 手段目的手段目的手段目的

Slide 50

Slide 50 text

© rector,inc ソフトウェアアーキテクチャにおける依存と交換可能のはしご交換可能依存 Strategy Scope Structure Skelton 　 Surface 交換可能依存交換可能依存交換可能依存抽象的/安定的抽象依存原則 (ADP) 安定依存原則 (SDP) 具体的/変動的 SoI SoE SoR ビジネスの構造を表現するユーザの行動、ストーリーを表現するドメイン知識を表現するユーザが見る情報の階層や流れを表現する変化しやすいニーズやバリエーションを表現する

Slide 51

Slide 51 text

© rector,inc コンウェイの法則とアーキテクチャ：目的に対して手段を交換可能に維持する交換可能依存 Strategy Scope Structure Skelton 　 Surface 交換可能依存交換可能依存交換可能依存手段目的 Mission Vision Strategy Plan 　 Action 手段目的手段目的手段目的抽象的/安定的抽象依存原則 (ADP) 安定依存原則 (SDP) 具体的/変動的 SoI SoE SoR

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

社会をとりまく目に見えない力を生み出す構造＝アーキテクチャ