Power Theory of Software Architecture

今日の講演の趣旨：

ソフトウェアアーキテクチャというと、もしかしたら技術的で高度に専門的な事柄であるように聞こえる。
そのため、「要素技術」に詳しい人が「アーキテクチャ」を作るという誤解をしているケースがある。

また、プロジェクトマネジメント・プロダクトマネジメント・ピープルマネジメントのそれぞれが
アーキテクチャとは無関係であると誤解されているケースがある。

今回の公演では、
これらは有機的に絡み合っていて、不可分であるという点を強調したい。

そのために、
「アーキテクチャ」という概念を次のように定義したい
何かをしやすくしたり、しにくくしたりする構造。
この何かをしやすくしたり、しにくくしたりする力を「権力」と呼ぶ。

この権力は、「他の選択肢」を選べないという時に生まれる。
この選択肢と依存のネットワークから生まれる権力の構造を「アーキテクチャ」と規定すると、
ソフトウェアの交換可能性や依存関係のことをソフトウェアアーキテクチャと呼ぶことがイメージしやすくなる。

Transcript

1. © rector,inc ソフトウェアアーキテクチャの 組織力学 広木 大地 @hiroki_daichi
2. © rector,inc 自己紹介 2008年度に新卒第1期としてミクシィに入社。 メディア統括部部長、開発部部長、サービス本部長執行役 員。組織改革の戦略・実行を行う。2015年同社を退社。 2016年「CTOのノウハウを広く世の中に還元する」ことを 目指し、レクターを創業。 2018年2月エンジニアリング組織論への招待上梓。 第6回ブクログ大賞ビジネス書部門大賞受賞。 ITエンジニアに読んでもらいたい技術書2019大賞。 広木 大地(ひろき だいち)
3. © rector,inc 自己紹介 EMFM Podcast エンジニアリングマネージャのためのポッドキャスト。 13エピソード公開中で、現在、20000再生を突破。 EMFM Meetupという公開収録イベントで200人の会場が即 日で集まった。 Qiita エンジニアリングに関するノウハウを集めるサイトQiita において、2019年現在、第2位。 トータル39記事で41800いいね/20000ブクマ。 その他パブリック活動
4. ビジネス書大賞と技術書大賞の２つを 受賞した初めての書籍
5. ソフトウェアエンジニアリングも 組織設計もビジネスの一部。 この二つは不可分だ。
6. © rector,inc 私のテーマ：２つのDX Developer eXperience DX (開発者体験) Digital transformation DX (企業のデジタル化) ＝
7. 今回のテーマは アーキテクチャと組織
8. アーキテクチャという概念はわかりにくい
9. © rector,inc ローレンスレッシグのCODEでは 「ある選択肢を選びやすくする」 「ある行動が不快になるようにする」 という性質を環境に与えることで、人々が自発的・自律的に特 定の行動を促すようにするものを「アーキテクチャ」と呼びまし た。 それらは社会のそこかしこに、あるいは卑近にWebサービスの 中にもあるものです。 たとえば、Amazonのレコメンドシステムはユーザーに対して以 前購入したものと同じような書籍を購入しやすくすることで、より 消費をすることを促すようになります。 権力の一種としてのアーキテクチャ
10. © rector,inc ビヨンドソフトウェアアーキテクチャでは： “

11. 要素技術に詳しい人が アーキテクトになるという誤解
12. 組織マネジメントと アーキテクチャは関係がないという誤解
13. ビジネスマネジメントと アーキテクチャは関係ないという誤解
14. © rector,inc ビジネスモデル 組織構造 プロジェクト アーキテクチャ アーキテクチャを構成する様々なパースペクティブ
15. © rector,inc アーキテクチャとはなにものなのだろうか？ アーキテクチャとは、何かをしにくくする代わりに、何かをしやす くする構造 ソフトウェアを作るということは、同時に何かを捨てていくことで す。Web開発のフレームワークは、Web以外の開発が難しくな ります。そのかわり、Web開発をしやすくするのです。 左図のようなベンチは、寝にくく、三人が座わりやすくするような アーキテクチャがしかけられています。 何かをしやすく/何かをしにくくする ホームレス排除の hostile architectureの例
16. 社会をとりまく 目に見えない力を生み出す構造 ＝アーキテクチャ
17. © rector,inc よくすることができる＝交換可能 選択肢を持つ側と選択される側の関係には、一方向には権力 が、その反対には依存という関係が成り立ちます。 より良いものに交換できる側であれば、選択肢を持たない側に 対して「権力」を発揮できます。逆に選択肢を持たないと、「依 存」が生まれ結果的に理不尽を受け入れます。しやすくする力、 しにくくする力はこうして発生する。 この依存による理不尽が技術的負債の正体で、交換可能であ るというメリットがアーキテクチャの正体です。 依存することで理不尽が生まれる。 依存 権力 選択肢を持つ側 選択肢を持たない側
18. © rector,inc 選択肢を持つ方が強く、持たない方が弱い。 モテる異性との恋愛 属人化した業務 エンジニア求人
19. © rector,inc 1 2 3 理不尽はいつも選択肢の少ない方にかかる 美男美女でとてもモテる人との恋愛は大 変です。その相手が、モテない場合、交 換可能になってしまうかもしれません。 経済的自立が難しい専業主婦にDV被害 が及ぶのも権力構造の乱用です。 美男美女との恋愛 十分な需要があり、交換可能でない場 合、値上げをする権力が生まれます。 たとえば、配送業者や近年のビル建設業 者などに起きていることは、需要と供給 のくずれによる関係性の変化です。 料金の値上げをする配送業者 平均的なエンジニアですら、７倍近い有効 求人倍率があります。優秀なレベルのエ ンジニアであれば、入社する会社は選び 放題です。そのため、待遇だけでなく、環 境や福利厚生、そしてその会社で働く社 会的意義などから選ぶ側になっていま す。 求職者優位の労働環境
20. アーキテクチャとは、 依存関係(交換可能性)のうむ権力構造
21. © rector,inc ソフトウェアアーキテクチャにおいて交換可能性が重要 自動テストや、カナリアリリースなどのデリバリーのパイプライ ンは、それ自体がある抽象度での交換可能性を上げるための 試みになる。 自動テストが存在しない状況だと、コードを修正するために多 大なリソースが必要となる。 ユニットテストが存在すれば、そのモジュールはユニットテスト を満たす限りにおいて、新しいものに交換できる。 これはAPI仕様を満たすテストを書けば、サービス自体の交換 可能性を高める。 自動テストとデリバリパイプライン サービスコンポーネントが自動的に構築可能で、かつ状態を持 たずに廃棄可能・再構築可能だった時、そのインフラの交換可 能性は高いと言える。 そのため、インフラの要素をコードで記述したり、高速に再構築 可能にすることが良いプラクティスとされる。 交換可能性という補助線を引くと、良いアーキテクチャとそうで ないアーキテクチャが自明に見えてくる。 Infra as Code/Disposable Component
22. プロジェクトマネジメントと アーキテクチャ
23. © rector,inc プロジェクトマネジメントの本質的複雑性 それは２つの依存関係があり、 クリティカルパスが存在するから。 N人のメンバーがいます。 M個のL時間づつかかるタスクがあります。 このプロジェクトは何時間で終わりますか？ （なお見積りは正確であるものとする ） という問題の答えが： 必要な時間 = ( M * L )/ N (時間) とならないのはなぜか。 問題 前の仕事が終わらないと次の仕事ができない 前後依存性 その人でないとある仕事ができない リソース依存性
24. © rector,inc ソフトウェアプロジェクトの依存関係は自明ではない ソフトウェアプロジェクトにおいては、 • 同じものをほとんど作ることはない • 依存関係が建築等ほど自明ではない • 見積りの分散が大きい などの理由から、単純な進捗管理ではほとんど価値を生み出さ ない。 依存性や困難性に対して、常に選択肢を持ち続けるようにアー キテクティングするのがプロジェクトマネジメントの仕事。 プロマネの仕事は進捗確認ではない 前の仕事が終わらないと次の仕事ができない => モックサーバやインタフェース設計 前後依存性 その人でないとある仕事ができない？ => 教育やフレームワークの導入、ツール化 リソース依存性 タスクごとの見積りの誤差が大きく違う => バッファマネジメント、不確実性に基づく優先 順位設計、プランBの用意 見積り不確実性
25. © rector,inc プロジェクトとプロダクトの依存関係は相似形になる プロジェクトの依存関係 プロダクトの依存関係 プロジェクトは、タスク同士の前後依存関係を持つ。これは時 系列に対しての依存関係になる。全ての依存関係が当初から 明らかなわけではない。 進めるにつれ、徐々に明らかになる。 プロダクトは、抽象と具体の間に依存関係があり、それをモ ジュールの依存関係として記述している。プロジェクトは最終的 にモジュールの記述を行うから緩やかに依存関係が相似する 時間 具体 抽象
26. © rector,inc 計画主義的プロセスと漸進的プロセス 計画主義的プロセスでは、プロジェクト初期に全依存関係を発 見する。これによって、プロジェクト実装フェーズの並列実行性 を高めてリリースまでの期間を短くする。一時的に要員が増え る。設計能力の必要な人員が相対的に少なくて良い。自明性 の高い抽象構造のプロジェクトに向く。 抽象構造を先に発見するプロセス 漸進的プロセスでは、各フェーズで要件を満たすような最低限 の設計と実装を繰り返す。抽象構造は初期に発見できるとは 限らないとして、リファクタリングを繰り返しながら、よい抽象構 造を発見する。自明でない仮説検証が必要なプロダクトに向い ている。 抽象構造を後から発見するプロセス 要件定義 設計 実装 テスト 全依存関係の洗出 リファクタリング
27. © rector,inc プロジェクトの変化に連動し抽象構造のパラダイムも変化 存在論的な抽象（オントロジ） 目的論的な抽象（テレオロジ） ・自明性が高い関係の発見 ・Abstract Class / Inheritance ・<犬>と<うさぎ>は<動物> ・ツリー構造、計画的 ・再利用性 ・事後発見される仮説と目的の記述 ・Composition/ Structural subtyping/Mixin ・<さんま>と<ぶたにく>は<メインディッシュ> ・セミラティス構造、自生的秩序 ・交換可能性 ＊これらは造語。オントロジの本来の意味と情報技術における意味ぐらい違う。 いい言葉が見つからない。。。
28. © rector,inc オントロジ的抽象の割合を下げられる設計論 ドメイン駆動設計 クリーンアーキテクチャ DCIアーキテクチャ
29. © rector,inc 進化的アーキテクチャ=組織論としてのアーキテクチャに 進化的アーキテクチャは、継続的なリファクタリングとリリースの 繰り返しを前提に、要求に対しての適応度の高い方に漸進的に 変化していくことを進化的アルゴリズムのアナロジーで捉えてい る。 概念的にはこれまで技術的負債と呼んでいたものを適応度の 低いアーキテクチャとしてとらえ直している。 また、継続して進化させるための組織文化を重要視しており、 組織論とアーキテクチャの連動を前提としている。 継続的なコードリリースを前提に
30. 組織構造とアーキテクチャ
31. 組織構造とソフトウェア システムを設計する組織は、その情報伝達の構 造をまねた設計を生み出してしまう｡ メルヴィンコンウェイ “

32. © rector,inc 組織構造はコミュニケーション構造そのもの 組織構造というと、ラインを構成するハイアラーキだけをイメー ジしがちであるが、ある仕事がどこから生まれて、どこに引き渡 されていくか、誰と交流していくことによって成り立つかから作ら れる交流のネットワークが組織構造。 それは明示的なもの・暗黙的なもの・非公式なものも含む。組 織の成果と誰が何をしているかを知っているというトランザク ティブメモリーが生産性に寄与することが知られている。 誰が誰と交流して仕事が成り立つか
33. © rector,inc 組織とソフトウェアは同じ構造に変化しやすい システムにおける問題は、組織構造上の問題が多く潜んでい る。この長らくソフトウェアエンジニアから支持されていた経験 則は、実証的研究からも多くの証拠が見つかっている。たとえ ば、関わる人々の地理的関係から ソフトウェアのバグの発生しやすい箇所を特定するなど コンウェイの法則 システムを設計する組織は、その情報伝達 の構造をまねた設計を生み出してしまう｡ メルヴィンコンウェイ “
 組織構造 システム
34. © rector,inc そのため、悪い組織構造は悪いシステムを生み出す 組織構造 システム バグ 技術的負債 見える 見えない プ ラ ス の 価 値 マ イ ナ ス の 価 値 新機能 アーキテクチャ
35. © rector,inc 組織構造とシステムが似通ってしまう理由 取引コスト理論 　取引コスト理論は、アメリカの経済学者であるロナ ルドコース(1910-2013)によって、提唱された経済学 の理論です。
 取引相手を見つけるために支払うコスト 
 探索のコスト
 取引相手と交渉を行うために発生するコスト 
 交渉コスト
 取引相手が契約した取引を履行するように監督と矯 正を行うコスト
 監督コスト

36. © rector,inc 取引コストによって、会社・組織の境界線が決まる ある経営上のリソースを市場から手に入れるのか(取 引コスト)、それとも企業内部に構築するのか(内部化 コスト)を取引コスト理論の観点で見てみると、会社組 織の境界線を決めるラインが見えてきます。 
 　内部化コストが高く、取引コストが安いものについて は、企業外部から調達し、取引コストが高く、内部化コ ストが低いものは、企業内部に構築することが望まし いということがわかります。 
 　この構図は、エンジニアリング機能を必要とする組 織にとっては、「何を外注し、何を内製するのか」を決 定づける構図であると理解することができます。 
 　
 内部化コスト > 取引コスト 取引コスト > 内部化コスト 市場取引
 長期取引
 戦略連携
 組織取引
 企 業 外 部 企 業 内 部
37. © rector,inc 組織設計とアーキテクチャの関係 技術的負債 プ ラ ス の 価 値
 マ イ ナ ス の 価 値
 アーキテクチャ 組織
 システム
 取引コストが低く 情報処理能力が高い 組織 取引コストが高く 情報処理能力が低い 組織 コンウェイの法則が示すように、組織の構 造とシステムの構造が相似形になってし まうのであれば、プラスの価値のある組 織からは優れたアーキテクチャが生ま れ、逆にマイナスの価値を持った組織か らは技術的負債が生まれるようになると いうことが導けると思います。 
 
 また、その逆に優れたシステムの構造 が、良い組織構造を生み出すことも起こり 得ますし、同様に技術的負債が組織の悪 しき硬直性を生み出すことも起こり得るの です。その意味で、組織とアーキテクチャ には密接な相互関係があります。 

38. © rector,inc 逆コンウェイ作戦とマイクロサービシズ 技術的負債 プ ラ ス の 価 値
 マ イ ナ ス の 価 値
 アーキテクチャ 組織
 システム
 取引コストが低く 情報処理能力が高い 組織 取引コストが高く 情報処理能力が低い 組織 コンウェイの法則が示すように、組織の構 造とシステムの構造が相似形になってし まうのであれば、プラスの価値のある組 織からは優れたアーキテクチャが生ま れ、逆にマイナスの価値を持った組織か らは技術的負債が生まれるようになると いうことが導けると思います。 
 
 また、その逆に優れたシステムの構造 が、良い組織構造を生み出すことも起こり 得ますし、同様に技術的負債が組織の悪 しき硬直性を生み出すことも起こり得るの です。その意味で、組織とアーキテクチャ には密接な相互関係があります。 
 コンウェイの法則 逆コンウェイ作戦 microservices
39. © rector,inc 組織に働く認知的な力：ゲシュタルト原則 近接 地理的に近い集団を仲間だと思う 似ている種類の集まりを仲間と思う 近接した複数の要素をグループ化して捉えるという人間の 特性があります。 これはデザインだけでなく組織においても同じで、地理的 な近接を仲間と思うような特性があります。 類同 類似した性質＝情報的な距離が小さい集団を仲間と思いま す。たとえば、同業種の人同士が交流することが増えると いうような特性です。そして人には仲間じゃないと思うも のを排除しようとする本能があります。
40. © rector,inc 「両利き」の経営：専門化とイノベーションのつまみ 知 の 探 索 知の深化 市場環境の変化が乏しい (持続的イノベーションが 差別化) 市場環境の変化が激しい (破壊的イノベーションが 差別化) 職能型組織 全体論的多様性チーム
41. © rector,inc 急な変化はコミュニケーション上の対立を産みやすいが、理解も進む 知 の 探 索 知の深化 全体論的多様性のあるチームは イノベーションを引き起こしやすい。 大人数ではマネジメントしづらい。 同質性の高いチームは、特定の職能を深 めていく力があるが、組織対立を招く。 コンピテンシートラップ
42. © rector,inc 専門化が進むと部門対立が生まれる。 知 の 探 索 知の深化 しかし、成長が鈍化してくるとゼロサムゲームだと 捉えるようになり、原因を相互に押し付けあう。 成長は全てを癒すのではなく、成長は全ての不安を 覆い隠す。 競争環境が固定的で、連続的なイノベーションが要 求されるステージでは、「知の深化」をもたらす 職能別組織が効果を発揮する。e.g. エンジン開発
43. ただ、古いシステムのことを 技術的負債と呼ぶのではない。 組織が必要な速度で 変更できる能力を失うことが負債
44. © rector,inc 組織文化と技術的負債の関係はこちらから DevLOVE X での講演内容 https://speakerdeck.com/hirokidaichi/cultural-capital-t heory-in-software-engineering
45. © rector,inc System Control Level：システムのコントローラビリティレベル Culture チーム文化レベル Architecture アーキテクチャレベル Code ソースコードレベル Spec 外部仕様レベル Chaos 制御不能レベル 5 4 3 2 1 機能横断チームの壁 内製人材比率の壁 発注者能力の壁 生産性（高） 相互理解の壁 生産性（低）
46. ビジネス構造とアーキテクチャ
47. © rector,inc ペースレイヤリングという思想 スチュアートブランドは、自然や文化のように緩やかにしか変化 しない事柄と、つどつどの流行のように変化しやすい事柄が変 化のペースによって、階層化されていて、土台がゆらぐとその上 も大きく揺らぎ、土台がしっかりしているとその上の変化も受け 入れられる適応性の高い構造になることを論じた。 デザインや、ソフトウェア設計にとっても同様で、変化の多さで 依存関係の階層構造を作ることをペースレイヤリングと呼ぶ。 参考：思想としてのペースレイヤリング http://ekrits.jp/2015/03/403/ 変化の緩やかさ・速さ
48. © rector,inc ビジネスのペースレイヤリング＝目的管理 ビジネスにおけるアーキテクチャを有効に機能させようとした ら、ビジネスのスケールに対して、変わりにくいものを代わりにく く、変わりやすいものを代わりやすくする必要があります。 また、目的のために手段をよくするものですから、目的と手段の 連鎖（抽象のはしご）に合わせてソフトウェア設計をすると、ビジ ネスの変動に対してロバストな設計になります。 目的より手段の方が変わりやすい 抽象的 具体的 固定的 変動的 手段 目的 Mission Vision Strategy Plan 　 Action 手段 目的 手段 目的 手段 目的
49. © rector,inc ビジネスにおける目的と手段の抽象のはしご 手段 目的 ミッションは最終到達の理想状態を表現します Mission ビジョンはミッションに向かう３年以内に到達する具体的な状態を書きます Vision ストラテジーはビジョンのための１年以内に達成する戦略目標を書きます Strategy プランはストラテジー実行のための３ヶ月後の戦術的施策や習慣を書きます。 Plan アクションはプランになるための１週間継続できる行動を書きます 　 Action 手段 目的 手段 目的 手段 目的
50. © rector,inc ソフトウェアアーキテクチャにおける依存と交換可能のはしご 交換可能 依存 Strategy Scope Structure Skelton 　 Surface 交換可能 依存 交換可能 依存 交換可能 依存 抽象的/安定的 抽象依存原則 (ADP) 安定依存原則 (SDP) 具体的/変動的 SoI SoE SoR ビジネスの構造を表現する ユーザの行動、ストーリーを表現する ドメイン知識を表現する ユーザが見る情報の階層や流れを表現する 変化しやすいニーズやバリエーションを表現する
51. © rector,inc コンウェイの法則とアーキテクチャ：目的に対して手段を交換可能に維持する 交換可能 依存 Strategy Scope Structure Skelton 　 Surface 交換可能 依存 交換可能 依存 交換可能 依存 手段 目的 Mission Vision Strategy Plan 　 Action 手段 目的 手段 目的 手段 目的 抽象的/安定的 抽象依存原則 (ADP) 安定依存原則 (SDP) 具体的/変動的 SoI SoE SoR
52. © rector,inc ビジネス要求とソフトウェアアーキテクチャのオニオンモデルの相似 要求工学のオニオンモデル https://www.ipa.go.jp/files/000005375.pdf クリーンアーキテクチャのオニオンモデル https://www.amazon.co.jp/dp/B07FSBHS2V/
53. © rector,inc ビジネスの不確実性の波を”プリズム”のように周波数分解する 交換可能 依存 Strategy Scope Structure Skelton 　 Surface 交換可能 依存 交換可能 依存 交換可能 依存 ビジネスの不確実性の波
54. © rector,inc ビジネスモデル 組織構造 プロジェクト アーキテクチャ アーキテクチャを構成する様々なパースペクティブ
55. 社会をとりまく 目に見えない力を生み出す構造 ＝アーキテクチャ
56. © rector,inc ご静聴ありがとうございました 広木 大地 @hiroki_daichi