Power Theory of Software Architecture

今日の講演の趣旨：

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

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

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

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

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

Transcript

1. © rector,inc
   ソフトウェアアーキテクチャの
   組織力学
   広木 大地 @hiroki_daichi
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. © rector,inc
   私のテーマ：２つのDX
   Developer eXperience
   DX (開発者体験)
   Digital transformation
   DX (企業のデジタル化)
   ＝
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

10. © rector,inc
    ビヨンドソフトウェアアーキテクチャでは：
    “

    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. © rector,inc
    ビジネスモデル 組織構造
    プロジェクト
    アーキテクチャ
    アーキテクチャを構成する様々なパースペクティブ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. © rector,inc
    選択肢を持つ方が強く、持たない方が弱い。
    モテる異性との恋愛 属人化した業務 エンジニア求人
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

28. © rector,inc
    オントロジ的抽象の割合を下げられる設計論
    ドメイン駆動設計 クリーンアーキテクチャ DCIアーキテクチャ
    

    View Slide

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

    View Slide

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

    View Slide

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

    

    View Slide

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

    View Slide

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

    組織構造
    システム
    

    View Slide

34. © rector,inc
    そのため、悪い組織構造は悪いシステムを生み出す
    組織構造
    システム
    バグ 技術的負債
    見える 見えない
    プ
    ラ
    ス
    の
    価
    値
    マ
    イ
    ナ
    ス
    の
    価
    値
    新機能 アーキテクチャ
    

    View Slide

35. © rector,inc
    組織構造とシステムが似通ってしまう理由
    取引コスト理論
    　取引コスト理論は、アメリカの経済学者であるロナ
    ルドコース(1910-2013)によって、提唱された経済学
    の理論です。

    取引相手を見つけるために支払うコスト 

    探索のコスト

    取引相手と交渉を行うために発生するコスト 

    交渉コスト

    取引相手が契約した取引を履行するように監督と矯
    正を行うコスト

    監督コスト

    

    View Slide

36. © rector,inc
    取引コストによって、会社・組織の境界線が決まる
    ある経営上のリソースを市場から手に入れるのか(取
    引コスト)、それとも企業内部に構築するのか(内部化
    コスト)を取引コスト理論の観点で見てみると、会社組
    織の境界線を決めるラインが見えてきます。 

    　内部化コストが高く、取引コストが安いものについて
    は、企業外部から調達し、取引コストが高く、内部化コ
    ストが低いものは、企業内部に構築することが望まし
    いということがわかります。 

    　この構図は、エンジニアリング機能を必要とする組
    織にとっては、「何を外注し、何を内製するのか」を決
    定づける構図であると理解することができます。 

    　

    内部化コスト > 取引コスト
    取引コスト > 内部化コスト
    市場取引

    長期取引

    戦略連携

    組織取引

    企
    業
    外
    部
    企
    業
    内
    部
    

    View Slide

37. © rector,inc
    組織設計とアーキテクチャの関係
    技術的負債
    プ
    ラ
    ス
    の
    価
    値

    マ
    イ
    ナ
    ス
    の
    価
    値

    アーキテクチャ
    組織
 システム

    取引コストが低く
    情報処理能力が高い
    組織
    取引コストが高く
    情報処理能力が低い
    組織
    コンウェイの法則が示すように、組織の構
    造とシステムの構造が相似形になってし
    まうのであれば、プラスの価値のある組
    織からは優れたアーキテクチャが生ま
    れ、逆にマイナスの価値を持った組織か
    らは技術的負債が生まれるようになると
    いうことが導けると思います。 

    

    また、その逆に優れたシステムの構造
    が、良い組織構造を生み出すことも起こり
    得ますし、同様に技術的負債が組織の悪
    しき硬直性を生み出すことも起こり得るの
    です。その意味で、組織とアーキテクチャ
    には密接な相互関係があります。 

    

    View Slide

38. © rector,inc
    逆コンウェイ作戦とマイクロサービシズ
    技術的負債
    プ
    ラ
    ス
    の
    価
    値

    マ
    イ
    ナ
    ス
    の
    価
    値

    アーキテクチャ
    組織
 システム

    取引コストが低く
    情報処理能力が高い
    組織
    取引コストが高く
    情報処理能力が低い
    組織
    コンウェイの法則が示すように、組織の構
    造とシステムの構造が相似形になってし
    まうのであれば、プラスの価値のある組
    織からは優れたアーキテクチャが生ま
    れ、逆にマイナスの価値を持った組織か
    らは技術的負債が生まれるようになると
    いうことが導けると思います。 

    

    また、その逆に優れたシステムの構造
    が、良い組織構造を生み出すことも起こり
    得ますし、同様に技術的負債が組織の悪
    しき硬直性を生み出すことも起こり得るの
    です。その意味で、組織とアーキテクチャ
    には密接な相互関係があります。 

    コンウェイの法則
    逆コンウェイ作戦
    microservices
    

    View Slide

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

    View Slide

40. © rector,inc
    「両利き」の経営：専門化とイノベーションのつまみ
    知
    の
    探
    索
    知の深化
    市場環境の変化が乏しい
    (持続的イノベーションが
    差別化)
    市場環境の変化が激しい
    (破壊的イノベーションが
    差別化)
    職能型組織
    全体論的多様性チーム
    

    View Slide

41. © rector,inc
    急な変化はコミュニケーション上の対立を産みやすいが、理解も進む
    知
    の
    探
    索
    知の深化
    全体論的多様性のあるチームは
    イノベーションを引き起こしやすい。
    大人数ではマネジメントしづらい。
    同質性の高いチームは、特定の職能を深
    めていく力があるが、組織対立を招く。
    コンピテンシートラップ
    

    View Slide

42. © rector,inc
    専門化が進むと部門対立が生まれる。
    知
    の
    探
    索
    知の深化
    しかし、成長が鈍化してくるとゼロサムゲームだと
    捉えるようになり、原因を相互に押し付けあう。
    成長は全てを癒すのではなく、成長は全ての不安を
    覆い隠す。
    競争環境が固定的で、連続的なイノベーションが要
    求されるステージでは、「知の深化」をもたらす
    職能別組織が効果を発揮する。e.g. エンジン開発
    

    View Slide

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

    View Slide

44. © rector,inc
    組織文化と技術的負債の関係はこちらから
    DevLOVE X での講演内容
    https://speakerdeck.com/hirokidaichi/cultural-capital-t
    heory-in-software-engineering
    

    View Slide

45. © rector,inc
    System Control Level：システムのコントローラビリティレベル
    Culture チーム文化レベル
    Architecture アーキテクチャレベル
    Code ソースコードレベル
    Spec 外部仕様レベル
    Chaos 制御不能レベル
    5
    4
    3
    2
    1
    機能横断チームの壁
    内製人材比率の壁
    発注者能力の壁
    生産性（高）
    相互理解の壁
    生産性（低）
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

52. © rector,inc
    ビジネス要求とソフトウェアアーキテクチャのオニオンモデルの相似
    要求工学のオニオンモデル
    https://www.ipa.go.jp/files/000005375.pdf
    クリーンアーキテクチャのオニオンモデル
    https://www.amazon.co.jp/dp/B07FSBHS2V/
    

    View Slide

53. © rector,inc
    ビジネスの不確実性の波を”プリズム”のように周波数分解する
    交換可能
    依存
    Strategy
    Scope
    Structure
    Skelton
    　 Surface
    交換可能
    依存
    交換可能
    依存
    交換可能
    依存
    ビジネスの不確実性の波
    

    View Slide

54. © rector,inc
    ビジネスモデル 組織構造
    プロジェクト
    アーキテクチャ
    アーキテクチャを構成する様々なパースペクティブ
    

    View Slide

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

    View Slide

56. © rector,inc
    ご静聴ありがとうございました
    広木 大地 @hiroki_daichi
    

    View Slide