このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。

はじめに

拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。

この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。

しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。

拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。

本記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで働く力学が同質のものであることを示しながら、技術的負債現象が引き起こる機序をより高い解像度で理解するための一つの考察です。

そして、このテーマはエンジニアリング組織論への招待の第6章の一部になる構想だったのですが、一定の難解さと説明の煩雑さがあるため割愛しました。

アーキテクチャってなんだろう

アーキテクチャという言葉はわかるようでわからない曖昧な言葉です。建築やソフトウェアにおける「構造」をさしていて、何らかの基礎となる仕組みや大まかな形、”つくり”を意味しているように思われます。

ですが、アーキテクチャにはどのような目的があり、どのような性質があるのかと問われると非常にやっかいで理解しづらいものです。

ここでは、法学者のローレンスレッシグの定義をうまく採用して、理解を深めていきたいと思います。彼は「CODE―インターネットの合法・違法・プライバシー 」において人間の行動を制約するもの（権力）の１種類として「アーキテクチャ」をあげました。

その中で、「ある選択肢を選びやすくする」「ある行動が不快になるようにする」という性質を環境に与えることで、人々が自発的・自律的に特定の行動を促すようにするものを「アーキテクチャ」と呼びました。それらは社会のそこかしこに、あるいは卑近にWebサービスの中にもあるものです。

たとえば、Amazonのレコメンドシステムはユーザーに対して以前購入したものと同じような書籍を購入しやすくすることで、より消費をすることを促すようになります。

たとえば、公園や高速道路の下に置かれた排除型ベンチや排除型アートと呼ばれるものは、公園で眠るホームレスを寄せ付けにくく、行政の手間を下げるように作られており、批判を浴びることになりました。

たとえば、Ruby on RailsなどWeb Application Frameworkは、Webサービスを作りやすくする代わりに、様々な制約を課します。このような制約を遵守する限りにおいて、特定の種類のサービスを作りやすくしています。

このように「しやすさ・しにくさ」を提供し、「ある方向に」人々を導く構造のことをアーキテクチャとして理解すると曖昧だった言葉が少しだけクリアになりました。

では、この定義によるとシステム全体をめぐるアーキテクチャは果たして、ソフトウェアアーキテクチャだけなのでしょうか？

たとえば、「ビヨンドソフトウェアアーキテクチャ」においては、ビジネスやユーザーの振る舞いに対するアーキテクチャを『マーケテクチャ（Market + Architecture）』とよび、いま風にいうのであれば、プロダクトマネージャの仕事を『マーケテクト』と呼びました。

同じように、ソフトウェアを描くチームと技術的な市場変化に対してのアーキテクチャを『ターキテクチャ(Tech + Architecture)』と呼び、今風にいうのであればエンジニアリングマネージャやテックリードの役割のことを『ターキテクト』と呼びました。

これらの区別は非常に重要な示唆です。アーキテクチャというとどうしても「技術上の話」だけだと捉えてしまいがちなのですが、そこには「導かれる人々」がいて、「導かれる方向」が存在するのです。そして、どちらもその意味ではアーキテクチャには違いないのです。

これらはUXの文脈や認知心理学の文脈で言うところの「アフォーダンス」と言う概念もまたアーキテクチャと類似する概念だと言えます。つまり、何かをしやすく、あるいはしにくくする誘発性をどのように理解するかということです。

デザインつまり設計という概念がアーキテクチャと切っても切れない理由はこのあたりにありそうです。

「エンジニアリング組織論への招待」においても、何かをしやすく・しにくくするもの、そして見えない坂道のように知らず知らずに人を一方向に動かすものが組織に働いていることを言及しました。

このような視点で見ると、あるシステムの中には：

• ビジネスのアーキテクチャ
• ソフトウェアのアーキテクチャ
• デザインのアーキテクチャ
• 組織のアーキテクチャ

など複数のアーキテクチャが混在しているように思えます。

選択肢と権力と依存

誰かが「何かをしやすく・何かをしにくくする」ということについて考えるのであれば、「選ぶ」と言うことについて考えてみる必要があるでしょう。社会交換理論や権力依存論を援用しながら「選ぶ」こととアーキテクチャについて考えてみましょう。

私がたとえば、今日の夕食を考えるとして、

• 近所のラーメン屋
• 遠くの高級火鍋

という選択肢があるとしましょう。

このとき、すごく寒い日であれば、火鍋という選択肢はとても魅力的に移ります。しかし、寒い中を移動する必要があります。さらに高級店なので値段も高いのです。近くのラーメン屋であれば、手軽でリーズナブルです。そこそこ体も暖かくなるでしょう。

このような状況の中で、たとえばUberEatsのような宅配サービスが登場し、しかもキャンペーン中であったため、格安で遠くの火鍋が自宅に届けられることになったとします。宅配サービスでは近所のラーメン屋は選べませんでした。これより価格と距離という２つの選択を妨げるアーキテクチャが変更され、私は火鍋を食べることを自然と選ぶようになりました。

このように選択肢の優先順位が変わったり、他の選択肢が見えなくなったりすることで、個人の自由意志で選んでいるはずが、知らず知らずに選ば"される"ようになってしまいました。

さて、その後、私は高級火鍋を頻繁に食べるようになります。体も温まり味も美味しいので、値段はともかく食べたいと思うようになりました。このようなおり、宅配サービスはキャンペーンが終わり値上げをするようになります。いつの間にか火鍋の刺激に慣れてしまった自分は、値段が上がったとしても宅配サービスを利用するようになっていきました。これはある種の依存です。

実は、この依存というものは、ソフトウェア設計においても非常に重要な概念であるだけでなく、アーキテクチャと選択肢の関係を考えるためにも重要な概念なのです。

アーキテクチャが何か１つの方向に人々を導く背景には、「見えない力」が働くからです。そしてそれは、「選ぶ側」から「選ばれる側」に対して働くことになります。

言い換えるなら、「選択肢を持たないもの」は、「選択肢を持つもの」よりも理不尽な目に遭いやすいということです。このような力のことを「権力」と言います。

たとえば、絶世の美男美女との恋愛を考えてみましょう。彼ら/彼女らにとってパートナーの選択肢は無数にいます。そのため、多少のわがままも許されるでしょう。かぐや姫のストーリーなどまさにそのようなものです。

たとえば、DVを行う夫がいる妻を考えてみましょう。女性の経済的自立が難しい社会や離婚が社会的に是認されていない社会においては、残念なことにその夫が唯一の選択肢に見えます。その結果、理不尽な暴力に晒されやすく、権力の影響を受けやすくなってしまうのです。

たとえば、現在のエンジニアの求職状況を見てみましょう。ソフトウェアエンジニアは、平均求人倍率が8倍程度あり、都内で働く優秀なWebエンジニアであれば10倍~20倍は超えるでしょう。このような状況では、求職者は『選ぶ側』になります。そのため、権力は求職者に宿ります。結果的に待遇や環境はよくなっていくことになります。最近の働き方改革などのムーブメントはこのような求人が増えてきたことと無関係ではないでしょう。

一方、求人倍率の低い時代、また労働流動性の低い時代であれば、会社に従業員が尽くすといったロイヤリティを求めることがあります。これは、「権力」が会社側に存在しているからだと理解することができます。

このようにして、「選択肢を豊富に持つ側」から「選択肢を持たない側」に対して何らかの力学、「権力」が働くことになるのです。

これにより、権力を持つ側は、持たない側に対して、望まない理不尽な選択肢を選ばせることができてしまいます。このような望まない理不尽を受け入れざるを得ないような状態を「依存」といいます。

もし、別によい選択肢を持っていれば、また別の選択肢を提供する仕組みがあれば、依存は発生しません。ブラック企業に勤めている人であっても、他の条件のいい転職先があれば（そしてあることに気がつければ）、理不尽を受け入れることなく転職していくでしょう。理不尽な暴力に苦しむ女性も、経済的自立や助けを求める手段があれば、依存から逃れることができるでしょう。

一方、選択肢が他にない、つまりは交換不能な依存関係のことをソフトウェアにおいては、「結合」と呼びます。理不尽は結合から生まれるのです。

このようなとりうる選択肢（オプション）の不均衡が、社会的な意味での「依存」と「権力」を生み出します。社会的な関係性の明晰な記述に過ぎないソフトウェアアーキテクチャにおいてもこの関係は成り立つのは当然のことだと言えます。

あるシステムを作る時、そのパーツを交換可能で「他に選択肢がある」ように維持するということはアーキテクチャを考える上で重要な視点です。たとえば、GoFのストラテジーパターンなどをつかって、複雑なアルゴリズムや処理をコンポジションによってあとから差し替え可能に設計することは、あるパーツを交換可能に維持するための工夫の１つです。

これはテストを書くことやインタフェースに依存することも同じです。何かを良くするためには、異なるものに「交換できる」という条件が必要不可欠です。ユニットテストやインターフェースは、つまりはある用途を満たすコードを別のより良いコードに交換するために必要な条件です。

そのため、テスタビリティが高いコードは、疎結合になりやすいといった現象やDIコンテナを用いたコードがテストしやすいという現象が発生します。これらはどちらも交換可能であるということを維持し、結合に伴う権力の作用を避けることができるからです。

システムのコントローラビリティ

このような「交換可能である」がゆえに良いものにできるという関係性は、ソフトウェアの一部だけでなく、そのシステムをとりまく価値のすべてにおいて成り立ち得ます。

システムの一部や部分の「変化」を受け止めるためには、その変化に見合った一部または全部を交換する必要があります。しかし、交換可能な部分が少なければ少ないほど、コントロールが効かなくなります。

たとえば、20年前に作られて今なお現役で動いているシステムを考えてみましょう。

社内には誰も担当者や外部仕様すら正確に知っている人がいない、その上、ソースコードも管理されていない。自動テストもなく、受注側の企業の担当者もすでに離職している。こんなとき、このシステムを部分的に交換しようとするのはとても難しいことです。受注側もリスクの割に実入りが少なければ、あまり受けたい仕事ではないでしょう。このようになると、交換が非常に難しいシステムになります。

一方、同じ２０年間動いていても、社内の同じチームや近い位置に意思決定者もデザイナーもエンジニアもおり、頻繁に修正をかけながら、自動テストやサービスの分割、継続的デリバリーの進んでいるシステムであればどうでしょう。部分的な要求変化に対して、素早く高い生産性が出せるでしょう。

これは、システムの一部を常に別の選択肢へと「交換しやすいアーキテクチャ」を手に入れるために、マーケティング、チーム文化、セキュリティ、プロセス・プロジェクトマネジメント、ソフトウェア設計、テスト品質管理、運用監視、意思決定フローなどバリューチェーンの全てにおいて余分な依存や結合を排除してきたことから生まれる生産性です。

コントローラビリティの喪失とホールドアップ

ある取引関係において、「他に代替手段がない」ということから、理不尽な要求をうけてざるを得なくなってしまうことを経営学的にはホールドアップ状態といいます。このような状況では通常より高い料金を受け入れたり、理不尽な要求を飲んだりする必要があるため、避けなければならない事態です。

特定のベンダー製品に依存していて、別の製品に置き換える時に非常にコストがかかるため、その手段が取れないことを指して、「ベンダーロックイン」と表現することがあります。ホールドアップ状態というのは、ベンダーロックインと同一線上にある状態です。

システムの開発において、徐々に別の選択を選ぶコストが高くなっていき、最終的には全てを入れ替えなければならなくなるという現象を我々はよく知っています。それを技術的負債と呼ぶのです。技術的負債という現象をミクロに捉えるとソースコードレベルの理解を要求するものですが、マクロに捉えると、非常にありふれた経済現象なのです。

ある取引関係において、ホールドアップリスクを避けたければ、もっともシンプルな手段は、取引コストをゼロにする戦略が考えられます。それが内部化です。これはシステムにおいても同様です。

このようにある組織がシステムを持つ場合、より良くするためには、一部または全部をより良いものに交換するという選択を持つ必要があります。このシステムに対しての交換可能性（コントローラビリティ）は、大雑把には５つの段階が考えられます。

レベル１：制御不能レベル

どこで、どのように動いているのか、そして何を要求して何が満たされているのか、見当がつかない状態。担当者が丸投げした上に退職し、契約書も残っていないなど、信じられないかもしれませんがこのようなシステムは数多く存在します。

誤解をしないようにしたいのは、この制御不能レベルにあるソフトウェアのコードの品質が高いか低いかは関係がないということです。仮に非常に高い品質のエンジニアが書いたとしても、その企業がまったく理解していなかったら、どんなことが起こるのかわからない爆弾になってしまいます。

レベル２：外部仕様レベル

発注者が優秀で、要求事項がすべてドキュメントで残っており、最新に維持されています。そして、変更のたびに検収のプロセスを多重に動かしているため、「何を求めて」「何が出来上がったか」については、かなりコントロール下にあるというレベルです。

しかし、プロジェクトマネジメントの主体やソースコード、要件レベルの内部ドキュメントは、自社に存在しないという状態です。

これらの要求レベルのドキュメントがあれば、最悪、別のシステムとしてを作り直すのは至難の技ではありますが、不可能ではありません。しかし、システムの中身自体を理解しているのは特定の外部業者という状態です。このとき、ソフトウェアの大きさが大きくなればなるほど、全体を交換するのにコストが巨大になります。こういったことから、その外部業者を別の業者に交換することが徐々に難しくなってしまいます。

レベル３：ソースコードレベル

複数のベンダーまたは、フリーランサー、自社人材で編成されたチームによって、

• 要件レベルのドキュメント
• プロジェクトマネジメント
• ソースコードのバージョン管理
• デプロイ自動化
• モニタリング
• 開発プロセス

などがマネージされている状態です。

この状態であれば、ホールドアップリスクとして顕在化する前段階の、技術的負債に自社として気がつくことができます。そもそもレベル１、２では経営的危機として顕在化するまで、技術的負債の存在にすら気がつけないのです。

システムの内製化について取りざたされる時、たとえばSIやSESの業態で働く人々の品質問題として語られることが多いのですが、実際にはどの業態であっても優秀な人も優秀でない人もいます。

内製化とは、自社で何も理解していない状態でコアコンピタンスとなる事業のシステムのコントロール権を喪失してしまうことを避けるための手段に過ぎません。むしろ、事業のコアコンピタンスでないのであれば、外部業者を利用することは合理的な選択肢です。

カレー屋さんはお米は自分で作らず買ってきますが、カレールーは自分で作ったほうがいいでしょう。何が事業価値の源泉かを特定して、そこに資源を集中するのが経営の基本です。

レベル４：アーキテクチャレベル

レベル３の段階に加えて、ビジネスとシステムの両面の理解をもった人物が、次のような抽象的な構造をビジネスとシステムの中に見出し、アーキテクチャレベルでコントロールが効いている状態：

• 戦略的技術選定
• レイヤードアーキテクチャ
• コアドメインの抽出
• システムのセグリゲーション
• インフラ自動化・デプロイ自動化
• 継続的インテグレーション
• ソースコード品質のモニタリング
• コードレビューガイドライン
• プロジェクトマネジメントの成熟

これらが満たされていると、しばらく長い間システムはコントロールできているように見えます。実際には、卓越したアーキテクトの仕事がそのプロジェクトで一時的に機能していただけのケースに過ぎないかもしれないのです。

そのアーキテクトが退職してはじめて、彼がSPoF（単一障害点）であったことに気がつきます。交換不能な存在だった彼に対しての依存度が高くなってしまい、アンタッチャブルな存在になってしまったり、英雄的犠牲を彼に強いてしまったりということもままある話です。このような歪な関係のもと、システムが腐らずに済んでいる状態とも言えます。

レベル５：チーム文化レベル

最終段階のレベル５は、中長期にわたって、レベル４で実現する品質を維持したり、より良くしていくことができるチーム文化や組織風土のレベルでシステムをコントロールできている状態です。

• ADR(Architecture Decision Records)の記録
• TDD・モブプログラミング
• 機能横断型チーム・全体論的多様性
• 学習する組織
• 継続的デプロイメント
• トランクベースの開発
• 多能工・T型人材
• 進化的アーキテクチャ
• DevOps
• シフトレフト
• 心理的安全性の高さ

この状態になると、「システムが満たしたい目的」に対して、時代の変化や技術的背景の変化などがあっても、チームのレベルでそれを吸収し、より目的に合致したシステムに変更していくことができるようになります。事業も、ある瞬間のシステムのスナップショットを提供するのではなく、継続的に価値を提供するソフトウェアサービスを提供することになります。

つまり、よくできた買い切りのパッケージ製品がレベル４のシステムであれば、継続して改善されていくサブスクリプション型のSaaSがレベル５のシステムだと言えます。

その意味では、ソフトウェアサービスとは、ある機能を提供しているのではなく、継続的にその目的を果たしつづける組織やチーム文化を提供しているビジネスと言い換えることができるのです。

モダンアジャイルやDevOpsの潮流というのは、取るに足らない流行り廃りではなく、ビジネス環境がより継続的なソフトウェア価値の提供を求めるようになったというマーケットの変化に呼応したものなのです。

ハードウェアをソフトにしたものか、ウェットウェアをハードにしたものか

ソフトウェアシステムのコントローラビリティを上げていき、より良いものに交換可能な状態を維持しようとすると、自然とチーム内のコミュニケーションや文化といった無形の資産の蓄積が不可欠になってきます。

エンジニアリングマネージメントが注目を集めはじめた最大の理由は、ソフトウェアを作りっぱなしではなく、継続的に機能提供をしていくことの難しさと価値に対して、ソフトウェアとそれを作るチームというものを構築する必要性があったからと言えます。

多くの旧来的なソフトウェアの価値観は、ハードウェアの付随品として、設備投資と同じように提供できるものだと認識されていたように思います。つまり、ハードウェアを少し柔らかく変化させやすくしたものという理解がされているように思います。この世界観では、一度投資したら、ほぼほぼずっと使い続けられるものであるように見えます。

ですが、実際にソフトウェアサービスを提供している感触としては、ハードを柔らかくしたものではなく、チームやビジネス上の暗黙知として存在するウェットウェアをより明晰にハードにしたものだと見えています。この世界観では、継続的・持続的に提供するチームが、企業内部に入り込む形で作られるものであるように見えます。

変わりやすいもの/変わりにくいもの

ソフトウェアにしても、ビジネスにしてもその外的な条件から、「変わりやすいもの」と「変わりにくいもの」が存在します。たとえば、人類がうまい食べ物を必要としているということは、あと１００年くらいはそのままな気がします。でも、チーズダッカルビを食べたいと思うのは、ここ数年くらいのものでしょう。

ペースレイヤリング

このような変わりやすさと変わりにくさに注目して、それを建築の分野に取り入れたのが全地球カタログでも有名なスチュアートブランドでした。

彼は、「How Buildings Learn」の中で、ペースレイヤリングと呼ばれる概念を創出しました。それは建物の変化と時の流れがどのような関係を持つかを示したものです。

５つの階層が建物の変化には存在していて、変化のスピードがそれぞれ異なるということを

用地（Site）は、建物よりも長く永遠に近い期間持続するもの。そしてのその上に建物(Structure)が建てられて、数十年から数百年は持続する。外装(Skin)は10年程度で、リフォームされ、その中にあるキッチンやエアコンなどの設備は5,6年で老朽化していきます。どんな風に部屋を使うか(Space Plan)は1年や2年は同じだけど、日用品 (Stuff)は毎週変わったりします。

ここで重要なのは、依存は常に「変わりにくいもの」に対してのみ行われるということです。「変わりやすいもの」に「変わりにくいもの」が依存するようになると、全て丸ごと交換する必要が出てきます。

たとえば、部屋の中であれば、インテリアや日用品のラインナップと同じ周期で引っ越したり、建物を立て替えるような人はいません。でも、床色やインテリアに合わせて、日用品を選ぶことはあります。

不動産屋さんに言わせると、他の不満はなんとかできるけど、立地の不満だけはなんともできないことが多いから、まずは立地から決めていくことが多いそうです。これも一種のペースレイヤリングです。

ペースレイヤリングという考え方は、建築だけでなく、Webシステムにおける情報アーキテクチャやUXの5Sへと転用されていくことになります。

また詳しくは、「思想としてのペースレイヤリング」という大変素晴らしい記事がありましたので、こちらをご参照ください。

ソフトウェアにおけるペースレイヤリング

ソフトウェアにおけるペースレイヤリングとして有名なのは、ガートナーのSoR/SoE/SoIの議論です。システムの変動性に合わせて:

• SoR( System Of Record　 )
• SoE( System Of Engagement )
• SoI( System Of Innovation )

という三階層に分割でき、それぞれが異なる開発サイクルを持つという発想です。ガートナーの分類は、ここからさらに踏み込んで、開発プロセスや開発手段とが階層ごとに異なるやり方が適切であるといういささか我田引水がすぎる主張をしているきらいがあります。

しかし、ペースレイヤリングという観点をアーキテクチャに持ち込むのは非常に重要な論点だと思っています。むしろ、ペースレイヤリングの重要性が導かれるのは、その抽象性と依存という関係からです。

ソフトウェアの設計原則に、抽象依存の原則(ADP:Abstraction Dependency Principle )というものがあります。依存するならば、より抽象的なものに依存しろという原則です。

また、もう一つ重要な原則に、安定依存の原則(SDP:Stable Dependency Principle )というものがあります。依存するならば、安定しているものに依存しろという原則です。

たとえば、配列をソートする関数があったとします。このとき、利用する側は、ソートするという目的を果たせればいいので、ソートアルゴリズムはそこまで気にしません。より、抽象的なものに依存してコードを書くようにすれば、ソートのアルゴリズムが変わっても利用側のコードを変える必要はありません。

このように、より抽象的(より目的に近い）コードに依存し、より具体的（手段に近い）コードを交換可能にしておくことで、ソフトウェアは変化に強く設計できるようになります。逆に、特定の手段を変更するときに引っ張られて、広い範囲に影響してしまうと修正にたくさんの時間をようすることになります。

これは、抽象的な目的の方が変化しにくく、具体的な手段の方が変化しやすいという性質から導かれているのです。これは、クリーンアーキテクチャやオニオンアーキテクチャと呼ばれる階層型のアーキテクチャが生まれた機序と同じものです。

ですので、アーキテクチャ設計をする際には、変化しにくい部分を抽象構造として見つけ出し、それを抽出する必要があります。これが、コアドメインオブジェクトの抽出や蒸留と呼ばれるような設計上の重要な視点になります。

ビジネスアーキテクチャ：ゴール設定と抽象のはしご

さて、私たちがビジネスを組織やチームで行うとき、ミッションやビジョンを設定することがあるかと思います。あるいは、戦略を決めて、行動に落としていくというように、より不確実で、抽象的で複数の手段を取りうる「目的」から、より具体的で選択肢の少ない手段へと落としていくことでビジネスを展開していきます。

これらは、つまりはペースレイヤリングであり、ビジネスのアーキテクチャなのです。

たとえば、「世界を平和にする」というミッションがあったとします。これは、組織の存在理由なので、なかなか変化する事はないでしょう。しかし、これだけでは抽象的すぎて、どんなときに使ったら良いかわかりません。

これをさらに、数年後のビジョンを考えます。到達したいと思うある未来の状況をよりクリアに伝えるのがビジョンです。一緒にゴールのタイムマシンに乗り込むことがビジョンです。

その数年後のビジョンを達成するにはどうしたらいいのでしょう。より具体的な筋道を考えていく必要があります。この筋道、どんな道を通っていくかが戦略です。

その戦略を実現するための作戦があり、そしてそれが個々の行動へとつながっていきます。

しかし、これらは下の階層に行くほど、目的に対して、手段という関係なので、無数に選択肢が存在するため、変動しやすくなります。組織におけるゴール設定については、また別の記事で詳しく述べます。

いずれにせよ重要なのは、目的の方がより変わりにくく、手段の方がより変わりやすいという階層構造を持っている事です。

そして、目的に対して手段が交換可能でなければ、それは悪い依存として、組織の目的を果たして行くのに支障がててくるという事です。

アーキテクチャのフーリエ変換と不確実性の波

目的と手段、抽象と具体という階層構造における交換可能性がアーキテクチャと呼ばれるものの正体でした。交換しにくければ、それは理不尽な権力となって無駄を生み出します。

そして、これは、外的なマーケット環境に潜む不確実性から織り成されるものです。不確実性は波のようなものです。複数の激しい周波数成分の波とゆっくりとしか変化しない波があります。これらは、いつもは折り重なっているので、その１つ１つを抽出する事は難しいのですが、アーキテクトはこれらを見極め、段階的にこの構造を構築して行く必要があります。

これはあたかも、プリズムが白色光を七色に分解するようなもので、数学的にはフーリエ変換のようなものです。異なる周波数成分に分解し、レイヤリングすることで変化に対して必要最低限のアクションで対応できるようになります。

コンウェイの法則の成り立つ背景と相互作用

コンウェイの法則が成り立つ背景には、ビジネスとソフトウェアの２つアーキテクチャが同じ不確実性の波に向き合っていることがあります。そのため、意図せず類似する構造を持つようになるのです。

また、ビジネスのアーキテクチャに従属して、組織構造が作られるので、組織構造に合わせたソフトウェアの設計がされがちですし、ソフトウェアのアーキテクチャのつくりによって、実現しやすい仮説検証とそうでないものが決まってしまうため、ソフトウェアアーキテクチャに合わせて組織が作られることも起こりえます。

組織の構造とシステムの構造が相似形になってしまうのであれば、プラスの価値のある組織からは優れたアーキテクチャが生まれ、逆にマイナスの価値を持った組織からは技術的負債が生まれるようになるということが導けると思います。

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

これは、抽象と具体、目的と手段の構造が本質的に同じ１つの階層構造に同居しているはずだからです。にもかかわらず、アーキテクトとビジネスオーナーという情報が非対称である二人の頭の中にだけ存在していることが多いものなのです。

そのため、エンジニアリング組織論への招待では、技術的負債という言葉がそもそも取りざたされるのは、この情報の非対称性にこそあり、技術的負債現象自体に拘泥すると本質を見失うのではないかという論を展開したのです。

あわせて読みたい

• スケールする要求を支える仕様の「意図」と「直交性」

参考図書

• クリーンアーキテクチャ
• アジャイルソフトウェア開発の奥義
• 権力の予期理論
• How Buildings Learn
• 選択しないという選択
• 交換と権力―社会過程の弁証法社会学
• Hatch組織論

おわりに

結構、長い話を短く納めたので、わかりにくところが多いと思います。
補講をちょっとずつ足したいな。